預計閱讀時間：11分鐘

在Oracle中，10053事件可以創建優化器的trace，因此也叫優化器跟蹤文件(Optimizer trace file)，這個文件，告訴你Oracle為什麼選擇這種，而不是另一種執行計劃，相應的成本值等一系列信息，讓你更加了解CBO的選擇。眾所周知，10053事件的trace文件可以通過alter session set event來創建，但前提是必須真正執行這條SQL，題外話是，這也是為什麼10053，能得到這條語句，對應的真實執行計劃。

1. 關於10053的相關知識，可以參考《探索索引的奧秘 - 10053事件》。

2. 有哪些方法可以得到SQL真實執行計劃，可以參考《一個執行計劃異常變更的案例 - 外傳之查詢執行計劃的幾種方法》。

如下步驟，是10053常見的一種創建過程，tracefile_identifier是為了標識10053的跟蹤文件名，說白了，就是USER_DUMP_DEST變數指定的路徑中好找。要想退出100053，一種是示例中操作的使用alter session ... context off，另一種是可以直接退出會話，

問題：

是否有其他方法，可以創建10053的跟蹤文件？

11g豐富了診斷事件的架構，提供了很多種debug輸出的級別，可以控制SQL的編譯，oradebug命令可以展示這些級別，

如上10053創建過程，可以改為，

無論哪種方法，最大的缺點就是，依賴於兩個前提：

1. 你必須執行SQL文本。

2. 執行過硬解析，即經歷了真實SQL編譯過程。

問題：

是否可以不用執行語句，得到一個已經執行並且還在游標緩存中的SQL語句10053跟蹤文件？

之所以這麼說，因為有些場景，不具備以上操作的條件，例如幾頁的SQL語句，執行起來困難，或者你沒有用戶密碼，但又需要10053。

11g下，DBMS_SQLDIAG包有個存儲過程DUMP_TRACE，可以實現此功能。原理是系統會自動觸發一次語句的硬解析以創建跟蹤文件。

The procedure will automatically trigger a hard parse of the statement to generate the trace.

但是，DUMP_TRACE並未寫入DBMS_SQLDIAG包的官方文檔中。Greg Rahn寫過一篇文章，並且在$ORACLE_HOME/rdbms/admin/dbmsdiag.sql有dump_trace的介紹和定義，

從上面介紹的debug級別以及dump_trace定義可知，p_component可以接收SQL_Compiler或者SQL_Optimizer兩個事件，p_file_id則是和tracefile_identifier相同，表示trace文件標識符，用於快速定位。

上面得到10053的四個步驟，僅需要執行這一個存儲過程，即可完成，

使用這種方法，生成的10053跟蹤文件，注釋部分會增加/* SQL Analyze(1443,0) */，表示是用DBMS_SQLDIAG.DUMP_TRACE創建的，而且是由Oracle，自動做了一次硬解析，

需要注意的是，每次存儲過程的執行，都會觸發一次硬解析操作，因此頻繁的執行，對於系統的影響程度，就需要你來了解和控制了。

參考文獻：

1. 《Capturing 10053 trace files continued》

https://blogs.oracle.com/optimizer/capturing-10053-trace-files-continued

2. 《Creating Optimizer Trace Files》

http://structureddata.org/2011/08/18/creating-optimizer-trace-files/

如果您覺得本文有幫助，歡迎關注轉發：bisal的個人雜貨鋪

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！