10046是一個Oracle的內部事件(event)，通過設置這個事件可以得到Oracle內部執行系統解析、調用、等待、綁定變量等詳細的trace信息，即幫助我們解析一條/多條SQL、PL/SQL語句的運行狀態，這些狀態包括：Parse/Fetch/Execute三個階段中遇到的等待事件、消耗的物理和邏輯讀、CPU時間、執行計劃等。它不僅為我們揭示了一條、多條SQL的運行情況，同時還能幫我們分析一些DDL維護命令的內部工作原理，RMAN、Data Pump Expdp/impdp等工具緩慢問題。對于SQL性能優化、分析系統的性能有著非常重要的作用。

10053：我們可以通過10046事件看到一個SQL的執行的統計信息，以及執行計劃，但是我們只看到了CBO最終告訴我們的執行結果，卻并不知道CBO為什么要這么選擇，那么就可以通過10053事件來生成SQL分析的整個過程到trace文件中，通俗點講10053跟蹤選路過程，10046產生結果。(10053可參考鏈接：https://blog.51cto.com/5073392/1308900)

10046最常用的操作步驟(10053步驟類似，把事件改成10053就行，但是10053 TRC不能通過tkprof格式化)

1.開啟10046跟蹤事件

alter session set events '10046 trace name context forever, level 12';

如果想更容易標識trace文件，在開啟事件之前，可以先設置trace的標識

alter session set tracefile_identifier='lych';

2.執行要跟蹤的sql語句(對應的trace文件中有SQL的執行情況)

select * from lych;

3.停止10046事件跟蹤

alter session set events '10046 trace name context off';

4.定位此次生成的trace文件

select distinct(m.sid),p.pid,p.tracefile from v$mystat m,v$session s,v$process p where m.sid=s.sid and s.paddr=p.addr;

5.用tkprof工具格式化文件輸出

tkprof /source.trc /new.trc aggregate=yes sys=yes wait=yes sort=fchela

explain：參數格式為explain=username/password@server_name 或者explain=username/password，這個參數是通過執行explain plan語句來做到的，在trace文件中找到每個sql語句，提供一個執行計劃。一般不是必要情況，指定這個參數并不可取，一旦指定了無效的信息，在輸出的文件就會出現error。

table：table參數只和explain參數一起使用，用來指定某個表被explain plan語句使用來生成執行計劃，通常盡量避免使用table參數，這里就不詳細說明不常用的參數了，大家想要了解的話，可以查看oracle的官方聯機文檔。

print：參數用來限制輸出文件生成的sql語句的數量，默認是無限制的。eg：只輸出10個sql語句，則參數指定print=10，一般和sort參數一起使用才具有一定的意義。

insert：生成sql腳本，腳本可以用來把數據存儲到數據庫中。eg：insert=load_data.sql 。

sys：參數執行sys用戶下運行的sql語句是否寫入到輸出文件，默認為yes。可設置為no，避免輸出不必要的信息，這個看情況而定吧。

sort：排序的意思，指定輸出文件里面的sql語句的順序，默認是trace源文件里面的sql順序。你可以指定根據cpu時間，物理讀的塊數，調用次數等進行排序，eg：sort=elapsed,disk —多個排序用逗號隔開。

aggregate：參數指定是否合并相同的sql，默認為yes，設置為no，輸出文件就會列出每個sql的消耗情況等信息。用得比較多的一般是sys和aggregate參數。

實操記錄：

昨天生產其中一個PDB出現很奇怪的現象，庫中每個表，視圖查詢都很慢，經過多次查詢，發現不管什么SQL執行都超過3秒，利用explain plan for打印執行計劃的時候，明顯能感覺出來，SQL解析非常慢，第一想法猜測是數據字典出現問題，才沒打印其他日志信息的時候 ，在SYS下執行了以下兩個包：1 exec dbms_stats.gather_dictionary_stats 2 exec dbms_stats.gather_fixed_objects_stats,之后發現依然還是有問題。之后執行一些經過緩存的SQL發現執行非常快，沒有對應的異常現象，這個時候我就已經猜到肯定是解析的時候出現的ORACLE內置遞歸操作出現了問題，于是根據推測打印了10046 TRC，發現其中一條遞歸SQL執行了3秒多，相當于這個庫任何一條SQL，只要是沒緩存的，起步時間都是3秒起步。查閱MOS資料后發現這是12c 12.1.0.2新特性“optimizer_adaptive_features”,默認是打開的，這個特性會在執行sql的時候自動收集統計信息.關閉對應參數后 system set optimizer_adaptive_features=false scope=both sid='*'一切恢復正常; 也可以通過關閉隱含參數實現：

alter system set "_OPTIMIZER_DSDIR_USAGE_CONTROL"=0 SCOPE=BOTH SID='*',當然這是一個BUG，也可以打補丁實現，Oracle Database 12c 版本1的自適應特性的建議 (Adaptive Features, Adaptive Statistics 以及 12c SQL 性能) (文檔 ID 2297986.1)