How To Collect 10046 Trace (SQL_TRACE) Diagnostics for Performance Issues (Doc ID 376442.1)

In this Document

Purpose

Questions and Answers

Gathering 10046 trace

Community Discussions

References

---

APPLIES TO:

Oracle Database - Enterprise Edition - Version 8.1.5.0 and later
Information in this document applies to any platform.

PURPOSE

This article outlines various procedures to effectively gather 10046 trace for use with Query Performance issues.
For use by DBAs, Developers and Support personnel

QUESTIONS AND ANSWERS

Gathering 10046 trace

Event 10046 is the standard method of gathering extended sql_trace information for Oracle sessions.
For details of the event see:

Document 21154.1  EVENT: 10046 "enable SQL statement tracing (including binds/waits)"

For Query Performance issues the typical requirement is to record wait and bind variable information for queries. This is achieved using 10046 with level 12. The following examples outline how to set the event in various scenarios:

• Trace Location
• Session Tracing
• Tracing a process after it has started
• Instance wide tracing
• Initialisation parameter setting
• Tracing sessions via a logon trigger
• Collecting Trace with SQLT
• Tracing with DBMS_MONITOR
• Alternative Trace Possibilities for Specific Scenarios
• Trace Interpretation

• Trace Location 
  
  11g R1 and above:
  
  With the introduction of the new diagnosability infrastructure introduced in Oracle Database 11g Release 1, traces and core files are placed in a location controlled by the DIAGNOSTIC_DEST initialization parameter. 
  To show the location of the DIAGNOSTIC_DEST, the following command can be used:
    SQL> show parameter diagnostic_dest
  
  Pre 11g R1:
  
  Event 10046 tracing will produce a trace file in the <Parameter user_dump_dest> for user processes and <Parameter background_dump_dest> for background processes.
  To show the location of the user_dump_dest, the following command can be used:
    SQL> show parameter user_dump_dest
  
  
  Note: Some examples include setting a 'tracefile_identifier' to assist with finding the resultant trace output.
  
  
• Session Tracing 
  
  This tracing can be used where the session is accessible to the user prior to the start of the statement(s) to be traced.
  To gather 10046 trace at the session level:
  
  alter session set tracefile_identifier='10046'; 
  
  alter session set timed_statistics = true;
  alter session set statistics_level=all;
  alter session set max_dump_file_size = unlimited;
  
  alter session set events '10046 trace name context forever,level 12';
  
  -- Execute the queries or operations to be traced here --
  
  select * from dual;
  exit;
  If the session is not exited then the trace can be disabled using:
  
  alter session set events '10046 trace name context off';
  Note that if the session is not closed cleanly and tracing is disabled, then important trace information may be missing from the trace file. 
  
  Note: "statistics_level=all" is set here so as to gather some level of statistics in cases where the parameter has been changed from the default and recommended level of "TYPICAL" (to BASIC). In order to diagnose performance issues, some level of statistics is required. A value of "ALL" may not be absolutely necessary but has been chosen over "TYPICAL" so as to have the most comprehensive information for diagnosis.
  
  
• Tracing a process after it has started 
  
  If trace from an existing session is required then oradebug can be used to attach to the session and initiate 10046 tracing. 
  
  
  1. The first step is to identify the session to be traced by some means: 
     
     For example, in SQL*Plus, start a session to find the OS process id (spid) for the target session:
     
     select p. PID,p. SPID,s.SID
     from v$process p,v$session s
     where s.paddr = p.addr
     and s.sid = &SESSION_ID
     /
     SPID is the operating system Process identifier (os pid)
     PID is the Oracle Process identifier (ora pid) 
     
     If you do not know the Session ID then you can use a select similar to the following to help you identify the target session:
     
     column line format a79
     set heading off
     select 'ospid: ' || p.spid || ' # ''' ||s.sid||','||s.serial#||''' '||
       s.osuser || ' ' ||s.machine ||' '||s.username ||' '||s.program line
     from v$session s , v$process p
     where p.addr = s.paddr
     and s.username <> ' ';
      
     Document For multi threaded processes in 12c, use newly added column stid from v$process to find specific thread, as Oracle combines many processes into a single ospid.  To find the specific thread, use following sytax:
     
     oradebug setospid <spid> <stid> 
     
     
  2. Once the OS process id for the process has been determined then the trace can be initialised as follows: 
     
     Lets assume that the process to be traced has an os pid of 9834. 
     Login to SQL*Plus as a dba and execute the following:
     
     connect / as sysdba
     oradebug setospid 9834
     oradebug unlimit
     oradebug event 10046 trace name context forever,level 12
     Remember to replace the example '9834' value with the actual os pid.
  
  
  Note that it is also possible to attach to a session via oradebug using the ' setorapid'.
  
  In this case the PID (Oracle Process identifier ) would be used (rather than the 'SPID') and the oradebug text would change to:
  
  connect / as sysdba
  oradebug setorapid 9834
  oradebug unlimit
  oradebug event 10046 trace name context forever,level 12
  Remember to replace the example '9834' value with the actual ora pid. 
  
  To disable oradebug tracing once tracing is finished:
  oradebug event 10046 trace name context off

         Document For multi threaded processes in 12c, use newly added column stid from v$process to find specific thread, as Oracle
         combines many processes into a single ospid.  To find the specific thread, use following sytax:

          oradebug setospid <spid> <stid>oradebug unlimit

         The tracefile name will be something like <instance><spid>_<stid>.trc.

• Instance wide tracing 
  
  
  Note: Please be cautious when setting system wide, as this will impact performance due to every session being traced.
  
  This setting will trace every session that is created after the parameter is set. Existing sessions will not be traced. 
  
  Setting system-wide 10046 tracing can be useful for scenarios where a problem session is known to occur but cannot be identified in advance. 
  In this situation, tracing can be enabled for a short period of time, the problem can then be reproduced and tracing disabled and the resultant traces searched for evidence of the problem. 
  
  System-wide tracing can be enabled as follows:
  
  alter system set events '10046 trace name context forever,level 12';
  The setting can be disabled in all sessions by using the following command:
  
  alter system set events '10046 trace name context off';

• Initialisation parameter setting 
  
  This setting will trace every session in the instance when it is restarted.
  
  event="10046 trace name context forever,level 12"
  The setting can be disabled by removing the parameter and restarting the instance or by using an alter system command as follows:
  
  alter system set events '10046 trace name context off';

• Via a Logon Trigger 
  
  There may be some situations where it is necessary to trace the activity of a specific user. In this case a logon trigger could be used. 
  An example is provided below:
  CREATE OR REPLACE TRIGGER SYS.set_trace
  AFTER LOGON ON DATABASE
  WHEN (USER like '&USERNAME')
  DECLARE
  lcommand varchar(200);
  BEGIN
  EXECUTE IMMEDIATE 'alter session set tracefile_identifier=''From_Trigger'''; 
  EXECUTE IMMEDIATE 'alter session set statistics_level=ALL'; 
  EXECUTE IMMEDIATE 'alter session set max_dump_file_size=UNLIMITED';
  EXECUTE IMMEDIATE 'alter session set events ''10046 trace name context forever, level 12''';
  END se t_trace;
  /
  Note that in order to trace a session, the user executing the trigger 
  needs to have been explicitly granted 'alter session' privileges. i.e.:
  
  

  grant alter session to <USERNAME> ;

• Collecting Trace with SQLT 
  
  Using SQLTXPLAIN with the "Xecute" option produces a 10046 trace as part of the SQLT output. As the name XECUTE implies, SQLT executes the SQL being analyzed, then it produces a set of diagnostics files (including a 10046 trace). See: 
  
  
  Document 215187.1 SQLT (SQLTXPLAIN) - Tool that helps to diagnose SQL statements performing poorly (Doc ID 215187.1)
  
  Trace produced in this way will be included in the SQLT output package in the format:
  sqlt_s 12345_10046_execute.trc
  
  Where 12345 is the SQLT report id 
  
  

• Tracing with DBMS_MONITOR 
  
  Also note that the DBMS_MONITOR package provides a number of methods of enabling trace. For more details see:
  
  
  Document 293661.1 Tracing Enhancements In 10g Using DBMS_MONITOR
  
  Oracle Database PL/SQL Packages and Types Reference
  10g Release 2 (10.2)
  Part Number B14258-02
  Chapter 60 DBMS_MONITOR
• Alternative Trace Possibilities for Specific Scenarios
  
  
  Document 21154.1 EVENT: 10046 "enable SQL statement tracing (including binds/waits)" 
  Document 1274511.1 General SQL_TRACE / 10046 trace Gathering Examples
  
  Document 160124.1 How to Set SQL Trace on with 10046 Event Trace which Provides the Bind Variables
  Document 371678.1 Capture 10046 Traces Upon User Login (without using a trigger)
  
  Document 1102801.1 How to Get 10046 Trace for Parallel Query
  Document 242374.1 Tracing PX session with a 10046 event or sql_trace
  
  Document 258418.1 Getting 10046 Trace for Export and Import
  
  If you are running PL/SQL procedures or packages then use of the PL/SQL profiler can be useful to determine where time goes while using PL/SQL routines.
  Instructions on the use of the profiler can be found in the following article:
  
  
  Document 243755.1 Implementing and Using the PL/SQL Profiler
  
  
  
  
• Trace Interpretation 
  
  
  Document 199081.1 SQL_TRACE (10046), TKProf and Explain Plan - Overview Reference 
  Document 39817.1 Interpreting Raw SQL_TRACE and DBMS_SUPPORT.START_TRACE output 
  
  Document 224270.1 Trace Analyzer TRCANLZR - Interpreting Raw SQL Traces with Binds and/or Waits generated by EVENT 10046 
  
  Document 41634.1 - TKProf Basic Overview 
  Document 32951.1 - TKProf Interpretation (9i and below) 
  Document 760786.1 - TKProf Interpretation (9i and above) 
  Document 214106.1 - Using TKProf to compare actual and predicted row counts 
  
  Document 199083.1 * Master Document SQL Query Performance Overview 
  Document 398838.1 * FAQ: SQL Query Performance - Frequently Asked Questions