Today browse Metalink, see this article interpreting Raw Sql_trace, older an article, but really useful, so decided to roughly translate it.
We know there are several ways to get a TRACE file in the background of an SQL statement execution, one with Sql_trace, one with a Dbms_support package or Dbms_system package, and one that uses the 10046 event directly.
The method for using 10046 event is as follows:
Alter session SET Events ' 10046 Trace name context forever, Level ';<br>
Your SQL statement ...
Alter session SET Events ' 10046 Trace name context off ';
The level has 1,4,8,12 several options, of which 1 is equivalent to the result of setting Sql_trace=true, 4 includes 1 results and the actual value of the bound variable, 8 includes 1 results and waiting events, and 12 contains the result of 1, the actual value of the binding variable, and the waiting event situation , so you can say level 12 is the most verbose trace.
We also know that for trace results, Oracle provides the TKPROF utility to format the trace file to provide a more readable trace result.
So why do you want to read the trace file directly? Most importantly, the result of the tkprof is that it does not contain the value of the binding variable, and does not include the actual SQL execution order, while the trace file lets you see the parse,binds,executes,fetch in chronological order and so on, which is useful in a certain western situation. And there is, if you can directly read these Ching trace, there will be a very cool, very great sense of the master:-)
Of course, if we were to sort the SQL in trace based on some criteria, such as CPU length, disk reads, and so on, then tkprof is our only option, and we can refer to Coolyl's Tkprof tool introduction and analysis.
The following is the general translation of this article in Metalink, most nouns in English instead of the imposition of translation, I believe we can understand. Of course, is also lazy reason:-)
The text summarizes the contents of the trace results original output file.
Dep:recursive depth of the cursor, the current recursive depth of the SQL statement, if 0 is the user-submitted SQL, and 1 is the SQL that causes Oracle to run itself in the background because of user SQL, 2 is the next level of SQL that is continued to be induced by Level 1 SQL.
Uid:schema User ID of parsing user
oct:oracle command type.
Lid:privilege User ID.
Tim:timestamp. Before oracle9i, the unit is 1/100 seconds, and the 9i is 1/1,000,000 seconds. This value allows you to calculate how long an SQL has been executed. This value is the value of the database V$timer view when the current row is written to the trace file.
Hv:hash ID.
The address of the Ad:sqltext Address,sqltext is equal to the value of the Addresses field in V$sqlarea and V$sqltext views.
<statement>: The actual SQL statement being parsed.
The "DB file sequential read" Wait event was experienced on cursor 1, waiting for 0.04 seconds, reading the block at file 4,block 1224
For the meaning of each waiting event and the meaning of P1,P2,P3, refer to the Oracle Wait Events section of the Oracle Database reference documentation.
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.