In-depth understanding of Oracle debugging events: 10046 event details

 The 10046 event is an extension of SQL_TRACE, dubbed "SQL_TRACE on stimulants".
       Effective trace levels:
       
       ① Level 0: SQL_TRACE=FASLE
       ② Level 1: SQL_TRACE=TRUE, which is the default level
       ③ Level 4: Level 1+ Binding variable
       ④ Level 8: Level 4 + wait event
       ⑤ Level 12: Level 4 + Level 8
       
       For 10046 of level 4, if you format it with tkprof, it will hide what every SQL statement is doing and how to do it.
       For level 8 10046, waiting events are scattered everywhere. At this time, we might as well use tkprof to summarize the waiting events.
       Therefore, understanding the format of the extended SQL trace file is an essential skill for every DBA facing performance problems or troubleshooting tasks.
          
       Why do you need it? 10046?
     
          alter session set events for a database user with alter session privilege but not authorized DBA role
          is the only way to start extended SQL trace in his own session
          by including wait events or bind variables in the SQL trace file, Then perform optimization or error diagnosis    
          10046 See the execution process of the statement, know the execution plan of the statement, including various steps, association methods, how much time is spent in which steps, and which waiting events
          are the basis for optimization. Knowing these , you know how to optimize and troubleshoting 2.
          
       
     
       How to get the trc file?


          Here are mainly 3 methods
          
          ① Use tracefile_identifier, such as:
             alter session set tracefile_identifier=\'Think\'


          ② oradebug, please refer to Think's previous blog for details: oradebug


          ③ Use the following script:

 

hr@ORCL> ed
Wrote file afiedt.buf

  1  select
  2         d.value||\'/\'||lower(rtrim(i.instance, chr(0)))||\'_ora_\'||p.spid||\'.trc\' trace_file_name
  3    from
  4         ( select p.spid
  5             from v$mystat m,v$session s,v$process p
  6            where m.statistic# = 1 and s.sid = m.sid and p.addr = s.paddr) p,
  7            ( select t.instance from v$thread  t,v$parameter  v
  8               where v.name = \'thread\' and (v.value = 0 or t.thread# = to_number(v.value))) i,
  9*             ( select value from v$parameter where name = \'user_dump_dest\') d
hr@ORCL> /

TRACE_FILE_NAME
-----------------------------------------------------------------
/u01/app/oracle/admin/orcl/udump/orcl_ora_4012.trc


       (iii) How to read and understand the documents of the 10046 event?
       
       ① The database call

       
       contains 3 sub-categories: parsing, executing and fetching.
       These 3 categories are consistent with running SQL by calling the subroutines DBMS_SQL.PARSE, DBMS_SQL.EXECUTE, DBMS_SQL.FETCH_ROWS.
       
       Parsing and
       parsing are usually in the trace file. By two adjacent entries indicating that
       the first is PARSING IN CURSOR and the second is PARSE

 

 

PARSING IN CURSOR #9 len=28 dep=0 uid=55 oct=2 lid=55 tim=1327904235010505 hv=119728103 ad=\'2fc6ae84\'
insert into t values(\'ooxx\')
END OF STMT
PARSE # 9: c = 52003, e = 65698, p = 0, cr = 30, cu = 0, mis = 1, r = 0, dep = 0, og = 1, tim = 1327904235010494


     

 

 

     

 

       The format of execution and acquisition is the same as that of parsing, so I won't go into details here.

 

       ② commit and rollback and XCTEND entry format

 

XCTEND rlbk=0, rd_only=0


       Oracle does not require the client to explicitly start a transaction, the DBMS automatically opens a transaction after the first data item is modified or a distributed operation is performed.
       For example, a select is performed from a table via dblink
       . The transaction boundary is marked in the trc by an XCTEND entry. , the format is as follows:
       XCTEND rlbk=[0-1],rd_only=[0-1]

 

     

 

      

 

       ③ Execution plan, statistical information and STAT entry format
       
       STAT entry reports the execution plan and statistical information

 

STAT #6 id=1 cnt=0 pid=0 pos=1 obj=18 op=\'TABLE ACCESS BY INDEX ROWID OBJ$ (cr=2 pr=0 pw=0 time=194 us)\'
STAT #6 id=2 cnt=0 pid=1 pos=1 obj=37 op=\'INDEX RANGE SCAN I_OBJ2 (cr=2 pr=0 pw=0 time=95 us)\'
  


       Each row of a set of STAT entries represents the row source that forms the result of the statement. The
       so-called row source refers to the data retrieved from the index or table or the intermediate result of the multi-table join (because the two-table join must be done first)
       
       After 10g, the STAT entry Only written when TIMED_STATISTICS=TRUE, and SQL_TRACE=TRUE
       Please note that TIMED_STATISTICS=FASLE is implicitly set if STATISTICS_LEVEL=BASIC (default is TYPICAL)

 

     

 

     

 

       ④ Wait event and WAIT entry format

 

WAIT #9: nam=\'SQL*Net message to client\' ela= 4 driver id=1650815232 #bytes=1 p3=0 obj#=52523 tim=1327922883350249
WAIT #9: nam=\'SQL*Net message from client\' ela= 301 driver id=1650815232 #bytes=1 p3=0 obj#=52523 tim=1327922883350743

WAIT #11: nam=\'db file sequential read\' ela= 253 file#=1 block#=420 blocks=1 obj#=355 tim=1327923455671258
WAIT #11: nam=\'db file sequential read\' ela= 7073 file#=1 block#=43998 blocks=1 obj#=355 tim=1327923455678537
WAIT #11: nam=\'db file sequential read\' ela= 91 file#=1 block#=43999 blocks=1 obj#=355 tim=1327923455678836
WAIT #11: nam=\'db file sequential read\' ela= 14433 file#=1 block#=53521 blocks=1 obj#=355 tim=1327923455693393


     

 

 

       ⑤ Bind variables and BINDS entry format
       
       The details of the bind variable include the data type and value of the bind variable.
       With this information, we can get the maximum diagnosis.
       For example, the data type of the index column does not match the data type of the bind variable, Causes indexes to fail and CPU usage to increase because there is also an implicit data type conversion
       The structure of a BINDS entry consists of the word BINDS followed by the cursor number and a separate subsection for each bind variable

 

BINDS #9:
kkscoacd
 Bind#0
  oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
  oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0
  kxsbbbfp = b7ee5a5c bln = 22 avl = 02 flg = 05
  value=20
 Bind#1
  oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
  oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0
  kxsbbbfp = b7ee5a38 bln = 24 avl = 02 flg = 05
  value=3


       When associating bind variables with subsections, don't care about numbers, they will be included in the name of the bind variable, e.g. ":B1"

 

     

 

     

 

 

     

 

 

 

hr@ORCL> select dump(employee_id) from employees where rownum=1;

DUMP(EMPLOYEE_ID)
----------------------------------------------------------------------------------------------------
Type = 2 Only = 2: 194.2


       The Type here is the data type number.
       
       Next time, Think will attach the case of optimization or diagnosis. This article is not finished yet.

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325630743&siteId=291194637