Skip to Main Content
  • Questions

  • Why user trace files are created at bdump instead of udump ignoring USER_DUMP_DEST setting value?

Breadcrumb

Question and Answer

Tom Kyte

Thanks for the question, Michelle.

Asked: November 10, 2011 - 4:22 am UTC

Last updated: November 11, 2011 - 8:51 am UTC

Version: 10.2.0.3

Viewed 1000+ times

You Asked

select
u_dump.value || '/' ||
db_name.value || '_ora_' ||
v$process.spid ||
nvl2(v$process.traceid, '_' || v$process.traceid, null )
|| '.trc' "Trace File"
from
v$parameter u_dump
cross join v$parameter db_name
cross join v$process
join v$session
on v$process.addr = v$session.paddr
where
u_dump.name = 'user_dump_dest' and
db_name.name = 'db_name' and
v$session.audsid=sys_context('userenv','sessionid');




result is /oracle/app/oracle/admin/ORANMS/udump/ORANMS_ora_17757.trc

but, real trace file is located at /oracle/app/oracle/admin/ORANMS/bdump/oranms_s000_177757.trc . The 's000' of trace file is changed to 's001', 's002' ...


and Tom said...

You are using shared server, not dedicated servers.

In shared server, you are using true background processes, processes that belong to the 'server' - not to the client.

In shared server - tracing can be very tricky - your parse might be executed by s000, your first fetch by s001, your second fetch by s002, and your close of that cursor by s003. Your trace information will be spread all over the place.


You would be best off tracing with dedicated server.

If not, you can use dbms_monitor in this fashion.

A) your client application will issue a call to dbms_session.set_identifier( 'some unique session identifier' );

B) before you run your application, you will in some session issue: exec dbms_monitor.client_id_trace_enable( client_id => 'that same unique identifier' )

C) run your application - the trace records for your session will be generated into possibly many s00N trace files - but they will all be tagged now with your unique id.

d) issue exec dbms_monitor.client_id_trace_disable( client_id => 'that unique id' );


e) run from the command line:

trcsess output=/tmp/somefile.trc clientid=<that unique id> *.trc

In the background dump destination. You can now tkprof somefile.trc

Rating

  (1 rating)

Is this answer out of date? If it is, please let us know via a Comment

Comments

disable trace files generation

shah, November 27, 2013 - 11:08 am UTC

We have shared server where We have recently upgraded single instance database to 10.2.0.5 patch set 4 on windows server 2003 64 bit

After upgrading we are facing issue of number of warnings in trace files (bdump)



WARNING:Could not lower the asynch I/O limit to 224 for SQL direct I/O. It is set to -1

According to oracle it is bug which produce useless warnings and can be ignored but these traces are consuming more than 500MB space per day and we are unable to delete trace files as oracle countinously using those file for writting



it is production database kindly suggest solution other than upgrade.



trace files sid_sxxx_XXX.trc



if we set max_dump_file_size to XXXM or G will it resolve our problem?

or is there any way to flush warnings to new file and delete old one but it should not be risky as like oradebug

or can we disable trace files generation we can't bounce DB as it is production.



Please suggest

thanks
more

Connor and Chris don't just spend all day on AskTOM. You can also catch regular content via Connor's blog and Chris's blog. Or if video is more your thing, check out Connor's channel and Chris's channel from their Youtube channels. And of course, keep up to date with AskTOM via the official twitter account.

More to Explore

DBMS_MONITOR

More on PL/SQL routine DBMS_MONITOR here