Oracle sql_trace 10046事件 10053事件筆記

跟蹤文件的位置

show parameter user_dump_dest

sql_trace分析步驟

1. 啓用跟蹤

alter session set sql_trace=true;

2.執行sql

select * from emp where id='id' ;

3.關閉跟蹤

alter session set sql_trace=false;

4.查閱跟蹤文件

在跟蹤文件的位置找到跟蹤文件,用下面的命令格式化輸出到sql.txt中

C:\>tkprof xxxx.trc sql.txt

格式化後的文件說明
解析（Parse）：此階段是Oracle的優化器爲SQL語句生成執行計劃的階段。
執行（Execute）：此階段是服務器進程按照執行計劃執行語句的階段。
抓取（Fetch）：此階段是服務器進程從表中抓取結果的階段。只有 Select 語句才須要此階段，Update、Insert、Delete等這些DML語句並不須要抓取行。
這個表格一般包括八列，這八列意義以下：
Call：說明了語句執行的每一個階段。
Count：此階段的執行次數。
CPU：完成此階段工做所耗的 CPU時間，單位是毫秒。
Elapsed：完成此階段工做所耗費的 CPU時間再加上等待的時間，單位也是毫秒。
Disk：完成此階段工做所用的物理讀次數。
Query：完成此階段工做所用的一致讀次數。
Current：完成此階段工做所用的當前讀次數。Query 和 Current加起來就是邏輯讀。
Rows：完成此階段工做所操做的行數。
接下來一行：「Misses in library cache during parse:」說明硬解析的次數，本例中語句的執行進行了一次硬解析。
「Optimizer mode」是優化器模式
另外，咱們在目標文件中還會發現大量的其餘語句，注意，咱們在跟蹤其間，只執行了
一條SQL語句，跟蹤文件中其餘的語句，其實就是所謂的遞歸調用。也就是爲了完成咱們的
語句，Oracle內部執行的一些其餘的 SQL語句。
經過觀察跟蹤文件的目標文件，咱們能夠觀察到比較精確的 CPU時間、物理讀邏輯讀等
信息，這有助於咱們瞭解一條 SQL語句是否有效。

跟蹤方法二：10046事件
咱們用10046事件也能完成 SQL跟蹤，只須要將「alter session set sql_trace=true」
換成「alter session set events ‘10046 trace name context forever，level 1’」，
就能夠完成如出一轍的工做，這條語句也是開啓SQL 跟蹤。結束跟蹤的語句是：
alter session set events ‘10046 trace name context off’;

轉 http://www.cnblogs.com/shenfeng/p/oracle_sql_trace.html
轉http://www.cnblogs.com/zhaoguan_wang/p/5127982.html
轉http://luoping.blog.51cto.com/534596/1097826/
轉http://blog.itpub.net/29320885/viewspace-1223962/
轉http://www.eygle.com/archives/2011/02/dba_event_10046_10053.html
轉http://blog.csdn.net/tianlesoftware/article/details/5859027
轉http://www.cnblogs.com/andy6/p/5846943.html
轉http://czmmiao.iteye.com/blog/1497509
轉http://blog.csdn.net/yuzhenhuan01/article/details/5834838
轉http://blog.itpub.net/519536/viewspace-216982/
轉http://www.2cto.com/database/201308/232838.html
轉http://www.docin.com/p-758931828.html
轉http://www.jb51.net/article/39931.htm
轉http://blog.chinaunix.net/uid-26922071-id-4033774.html
轉http://blog.csdn.net/miyatang/article/details/14455275
轉http://blog.itpub.net/17252115/viewspace-751541/