Closing trace file with ORADEBUG
Was playing with ORADEBUG today and figured out a cool feature - you can actually close trace file using ORADEBUG CLOSE_TRACE. The only way I knew before was to shrink the file. So now after 10046 trace you don’t need to restart the process to close trace file.
If your SMON, PMON, etc. Oracle process is dumping like crazy (kind of abnormal but who needs a DBA anyway if SMON is not dumping regularly?) - you can close this file and actually delete it without bouncing the instance. Never really dealt with Windoracle on that matter but I suspect that removing SMON’s trace file, for instance, is not possible (it’s locked) without stopping Oracle instance UNLESS one uses ORADEBUG CLOSE_TRACE.
How many times you got into situation when dump destination got full and someone (perhaps, you) cleaned it up using something trivial like ‘rm *trc’? Out of those cases how often you noticed that several GB filesystem with single 100 KB alert.log file is still 99% full after “clean up” because SMON and/or whatever other backgroung processes keep inodes open? My bet is - at least 50%.
Now you need simple:
SQL> oradebug setospid
Statement processed.
SQL> oradebug close_trace
Statement processed.
Isn’t that amazing? Just checked - it’s available at least in 9iR2, 10gR1 and 10gR2.
Where did you dig that one? I thought I knew the commands to use in sqlplus
Laurent, I will answer you question with my another favorit ORADEBUG option, which is…. ORADEBUG HELP
Long time ago I wrote white paper about Oradebug.You can still find it on:
http://www.evdbt.com/Oradebug_Modrakovic.pdf
P.S. oradebug poke is cool…
Miladin
This option is very useful if you have deleted a trace file with the session still live and
now you want the session to resume tracing, but a new file doesn’t appear.The reason
why you have a problem under Unix is that the trace file is not closed - even if you set
sql_trace to false.
select spid, pid
from v$process
where addr = (select paddr from v$session where sid = );
oradebug setorapid {the pid above}
or oradebug setospid {the spid above} then
oradebug flush
oradebug close_trace
The close_trace option is that you can do it even after you have deleted the trace file
from the operating system level.
Thanks Miladin. This is exactly why I posted about close_trace.
We have a cron job that deletes all files older than 7 days. Some times it is deleting background process trace files as well. So I am in the process of applying “oradebug close_trace” on all BG proces in the instance. In such a case, what will be the impact on those ones where there is a trace file available (not deleted by the cron job)?
I tried it on one of my test systems, on LMD process, and found that it made a entry in the existing trace file. Not sure what will happen next. Any body tested this scenario?
*** 2009-07-07 22:07:51.182
End DRM(910) for pkey transfer request(s) from 1
*** 2009-07-08 15:36:25.284
Received ORADEBUG command ‘close_trace’ from process Unix process pid: 15348, image:
What’s happening, you genuinely have a great and informative website! I will be bookmarking it for sure! Many thanks.