我們大家都知道Oracle Sql Trace與10046 event是診斷Oracle數據庫性能的常用工具。但是level超過1的10046事件時一般被稱為extended sql trace，其主要作用是用於診斷確定的單個SQL、存儲過程或會話的性能問題，具有如下的幾個優點：
可以得到SQL執行時實際的執行計劃。
可以得到SQL執行時所花時間的具體分布，CPU消耗了多長時間，多塊讀消耗了多長時間等等。
可以得到SQL執行時的各種與性能相關的統計數據，邏輯讀、物理讀、fetch次數、parse次數等等。
不僅能夠用於性能測試，同時能夠用於診斷正在執行的SQL或存儲過程的性能。
有很多的工具用於格式化生成的trace文件，除了Oracle自帶的TKPROF、Metalink Note 224270.1 Trace Analyzer，以及第三方的免費工具如orasrp，《Troubleshooting Oracle Performance》作者開發的TVD$XTAT，甚至還有商業化的軟件Hotsos Profiler等。
不過前段時間在用10046事件診斷一個性能問題的時候，卻讓生成的結果誤導了。後來仔細檢查發現，在會話開啟Oracle sql trace的情況下，SQL語句會重新解析，導致開啟sql trace之後與開啟之前相比，執行計劃可能發生了變化，導致sql trace的結果不能真實地反映會話執行SQL的情況，在分析時容易發生偏差。
下面是一個測試：
測試的環境是Oracle 10.2.0.1 for Windows，不過前面提到的案例，是發生在Oracle 9i下的，所以9i和10g都有這個問題，而11g目前還沒有測試過，有興趣的朋友可以在11g上進行測試。
首先創建一個sql文件，內容為：
- select /*+ testsql */ sum(value) from t1 where flag=:v_flag;
創建一個列上數據有傾斜的表：
- SQL> create table t1 (value number ,flag number,pad varchar2(2000));
表已創建。
- SQL> insert into t1 select rownum,mod(rownum,2000),lpad('x',1000,'x') from dba_objects;
已創建49796行。
- SQL> commit;
提交完成
- SQL> insert into t1 select rownum,3000,lpad('x',1000,'x') from dba_objects where rownum<=10000;
已創建10000行
- SQL> commit;
提交完成。
- SQL> create index t1_idx on t1(flag);
索引已創建
- SQL> exec dbms_stats.gather_table_stats(ownname=>user,tabname=>'T1
',cascade=>true,method_opt=>'for all indexed columns');
Oracle SQL trace時需要注意：PL/SQL 過程已成功完成。
- SQL> select column_name,num_distinct,num_buckets from user_tab_columns where table_name='T1';
- COLUMN_NAME NUM_DISTINCT NUM_BUCKETS
- VALUE
- FLAG 2030 75
- PAD
- select /*+ testsql */ sum(value) from t1 where flag=:v_flag;
創建一個列上數據有傾斜的表：
- SQL> create table t1 (value number ,flag number,pad varchar2(2000));
表已創建
- SQL> insert into t1 select rownum,mod(rownum,2000),lpad('x',1000,'x') from dba_objects;
已創建49796行
- SQL> commit;
提交完成。
- SQL> insert into t1 select rownum,3000,lpad('x',1000,'x') from dba_objects where rownum<=10000;
已創建10000行。
- SQL> commit;
