what is the file ORA_DUMMY_FILE.f in oracle? [message #669568] |
Mon, 30 April 2018 05:52 |
|
tombatossals
Messages: 5 Registered: April 2018
|
Junior Member |
|
|
We have a recently installed database oracle 12.2 on linux that is currently used by a developers team (no real data there).
We have found that when executing any parallel query the next error arises:
ORA-12801: error signaled in parallel query server P001
ORA-01116: error in opening database file 132
ORA-01110: data file 132: '/u02/oradata/ora12c/pdbname/tablespacenaname_ts_1.dbf'
ORA-27077: too many files open
After some investigation we have found this:
As you know, these are the linux processes for the parallel servers in oracle:
ora_p000_ora12c
ora_p001_ora12c
....
ora_p???_ora12c
They can be seen also with the view: gv$px_process. The spid for each parallel server can be obtained from there.
Then I look for the open files associated with te parallel server here:
And I'm obtaining around 65000 file descriptors for several parallel servers equal to this one:
991 -> /u01/app/oracle/admin/ora12c/dpdump/676185682F2D4EA0E0530100007FFF5E/ORA_DUMMY_FILE.f (deleted)
I've checked that the max open files in linux is set to 65536
I've closed them using:
gdb -p <spid>
gdb> p close(<fd_id>
)
(actually I've create a small script for doing it because there are thousands of them)
When the file descriptors are closed the error in parallel queries does no appear any more, but after some hours the file descriptors start being created again (hundreds every day)
If they are not closed then eventually the linux limit is reached and any parallel query throws again the same error.
Does anyone have any idea of how and why this file descriptors are being created, and how to avoid it?.
Some more information that could be useful.
I've tested that when a new PDB is created a directory DATA_PUMP_DIR is created in it (select * from all_directories) that is pointing to
/u01/app/oracle/admin/ora12c/dpdump/<xxxxxxxxxxxxx>
The linux directory is also created. Also one file descriptor is created pointing to ORA_DUMMY_FILE.f in the new dpdump subdirectory like the ones described initially
lsof | grep "ORA_DUMMY_FILE.f (deleted)"
/u01/app/oracle/admin/ora12c/dpdump/<xxxxxxxxxxxxx>/ORA_DUMMY_FILE.f (deleted)
This may be ok, the problem I face is the continuos growing of the file descriptors pointing to ORA_DUMMY_FILE that reach the linux limits.
|
|
|
|
|
|
|
|
|
|
|