EVENT: 10046 "enable SQL statement tracing (including binds/waits)" (文档 ID 21154.1)

Event:10046
Text:   enable SQL statement timing
-------------------------------------------------------------------------------
For details of interpreting 10046 output see: Note:39817.1

Explanation:
        This is a special EVENT code. 
        It can be used to signal Oracle to perform SQL_TRACE type actions.

        The 10046 trace is the equivalent of setting SQL_TRACE=TRUE.
        The advantage of using the event is that extra details may be
        output to the trace file depending on the level specified with the
        event.

        As of 11g one can also set the "10046" event type trace using a 
        new event syntax which specifies "sql_trace" as the event.
        eg: alter session set events 'sql_trace wait=false, bind=true';'

For Customers:
    	The event here is often requested to be set by Oracle Support
	when gathering information for specific SQL issues.

        The notes below describe the levels for this event.
        
10046 EVENT levels:  (the new sql_trace values are included in [..])
  These are bit values so can be ORed together to get different mixes
        1  - Enable standard SQL_TRACE functionality (Default)
        4  - As Level 1 PLUS trace bind values           [ bind=true ]
        8  - As Level 1 PLUS trace waits                 [ wait=true ]
             This is especially useful for spotting latch wait etc. 
             but can also be used to spot full table scans and index scans.

  As of 11g these additional bit levels are available:
        16 - Generate STAT line dumps for each execution [ plan_stat=all_executions ]
        32 - Never dump execution statistics             [ plan_stat=never ]

  As of 11.2.0.2 this additional bit level is available:
        64 - Adaptive dump of STAT lines.                [ plan_stat=adaptive ]
             This dumps the STAT information if a SQL took more than about 1 minute thereby 
             giving information for the more expensive SQLs and for different executions of such
             SQLs.

  eg: A common event level is 12 which includes standard SQL_TRACE output, binds, waits and 
        default STAT line tracing.

Notes:
 STAT dumping has been amended in 11g so that they are not aggregated across all executions but are 
 dumped after execution.  This  has been done to address cases where the cursor is not closed and the 
 STAT information is therefore not dumped. Now we guarantee to capture the STAT information 
 following the execution. See the above bit levels to have finer control over STAT lines. 


Example Syntax:

   Session level:
	alter session set events '10046 trace name context forever';
	alter session set events '10046 trace name context forever, level 8';
	alter session set events '10046 trace name context off';

      11g alternatives:
	alter session set events 'sql_trace';
	alter session set events 'sql_trace wait=true';
	alter session set events 'sql_trace off'';


   Init.ora:
	event="10046 trace name context forever,level 4"
        
        WARNING: This will trace ALL database sessions
        

    From oradebug (7.3+):
        oradebug event 10046 trace name context forever, level 4

     11g alternative:
        oradebug event sql_trace bind=true


    From oradbx (pre 7.3):
	event 10046 trace name context forever, level 4


Articles:
     Interpreting RAW 10046 output                            Note:39817.1
     How to enable 10046 for another session using ORADEBUG   Note:1058210.6



EXAMPLES:
~~~~~~~~~
Wait Information:
        nam is what is being waited for
        ela is the elapsed time for the operation
            In Oracle7 / 8 this is in units of hundredths of a second
            In Oracle9i onwards this is in microseconds
        p1 is the file number
        p2 is the block number 
        p3 is the number of blocks read by the operation

Waiting for a Full Table Scan: 
        WAIT #1: nam="db file scattered read" ela= 5 p1=4 p2=1435 p3=25
        WAIT #1: nam="db file scattered read" ela= 7 p1=4 p2=1461 p3=32
        WAIT #1: nam="db file scattered read" ela= 7 p1=4 p2=1493 p3=32

        The first wait indicates a mutliblock read was issued for 25 blocks
        starting at file 4 block 1435. This took 5/100th of a second.
        The next 2 lines also show multiblock reads of 32 blocks (which is
        probably the value of <Parameter:db_file_multiblock_read_count> )

Waiting for an Index Scan:
        WAIT #1: nam="db file sequential read" ela= 4 p1=4 p2=1224 p3=1
        WAIT #1: nam="db file sequential read" ela= 4 p1=4 p2=1788 p3=1

        This is the sort of output you would see on an index scan or an
        individual block access to table block.

REFERENCES

NOTE:1058210.6 - How to Enable SQL_TRACE for Another Session or in MTS Using Oradebug

NOTE:39817.1 - Interpreting Raw SQL_TRACE output



NOTE:199081.1 - SQL_TRACE (10046), TKProf and Explain Plan - Overview Reference

相关内容

产品

• Oracle Database Products > Oracle Database > Oracle Database > Oracle Database - Enterprise Edition > RDBMS