Separate user and system trace files in Oracle 11g

oracle

In Oracle 10g, the destinations for system and user generated trace files were controlled by the background_dump_dest and user_dump_dest Oracle parameters.

Starting in 11g these parameters are deprecated, and all trace files are written to the Diag Trace value in v$diag_info.

Is there any way to separate system and user trace files like you could in 10g?

Best Answer

I do not think that you can set the user and background dump destinations in 11g onward. One thing that might help is the TRACEFILE_IDENTIFIER parameter. I set this when I do a trace so that it is easy to find in the trace directory.

For example I setup a trace like this:

alter session set max_dump_file_size = unlimited;
ALTER SESSION SET tracefile_identifier = 'bobbydurrett';
ALTER SESSION SET EVENTS '10053 trace name context forever, level 1';
ALTER SESSION SET EVENTS '10046 trace name context forever, level 8';

My trace file has my name "bobbydurrett" in it so it is easy to search for it.

Bobby

Related Solutions

Oracle 11g Listener not working

The error message means that one (or more) of the shared libraries required for TCP communications to work could not be loaded, perhaps due to o/s package updates? or it can mean that the /tmp/.oracle directory is not writeable by the oracle user (or doesn't exist perhaps because someone did some 'housekeeping' on /tmp . In either case tracing the listener at level 16 as Gaius suggested should reveal the issue.

Setting NLS params in logon trigger don’t work in oracle 11g

Changing the order of the SET seemed to make a difference, as it is working now.

create or replace
TRIGGER schema.django_nls_tr
AFTER logon ON DATABASE
BEGIN
execute immediate 'ALTER SESSION SET NLS_TERRITORY = ''AMERICA'' NLS_DATE_FORMAT = ''YYYY-MM-DD HH24:MI:SS'' NLS_TIMESTAMP_FORMAT = ''YYYY-MM-DD HH24:MI:SS.FF''';
END;

I don't really like this solution, as I still don't understand exactly why changing the order should matter. Perhaps the TERRITORY isn't being set correctly, but it was already the default so we're not TOO worried right now.

Also, django does do a TO_TIMESTAMP. It expects most date fields to be TIMESTAMP(6) but we had it pointed at a legacy db with DATE type fields. The NLS shouldn't matter too dramatically in standard deployments.

Best Answer

Related Solutions

Oracle 11g Listener not working

Setting NLS params in logon trigger don’t work in oracle 11g

Related Question