使用擴展SQL跟蹤數據來了解是什麼在耗費這麼長的時間。
假如有一天你開車去上班，但最後還是沒能及時參加一個重要會議。你無法將你的革命性的想法呈現給客戶，所以他們也不會采用。你的拖拖拉拉使你感到沮喪，你發誓決不再犯同樣的錯誤。那麼，為了不再發生類似情況，你怎麼判斷問題的原因呢？按照下面這個列表進行檢查怎麼樣？
檢查汽車外表是否有缺陷，因為外表有缺陷會使汽車的最高速度降低1%或更多。
檢查車輪定位，因為外傾角、後傾角或前束角不合適都會導致汽車的操縱不靈活並且耗費時間。
檢查發動機，以確保達到額定馬力的99%或更高。如果不是這樣，則要考慮重裝或更換發動機。
不，你可能不會采用這種檢查方法；那樣太可笑了。你可能會以完全不同的方式來判斷問題之所在，可能只是問你自己一個簡單的問題：什麼事情讓我花了這麼長時間？
從這個角度出發，問題就迎刃而解了。如果開車需要40分鐘，而你在會議開始前20分鐘才動身，那麼下次就要提前30分鐘動身。如果因為交通擁堵浪費了20分鐘，那麼，下次要麼再早一些動身，換條路線，要麼更仔細地查看早7點的路況報告。如果是你迷了路，結果浪費了20分鐘去兜圈子，那麼下次你大概就要事先看看地圖。如此等等。
我感到奇怪的是，那些擅長解決日常性能優化問題的數據庫專業人員在工作中卻使用完全不同的方法來解決數據庫性能問題。許多數據庫"調優人員"從來不問，"是什麼讓這個程序運行了這麼長時間？"相反，他們會參考檢查內容清單，並試圖阻止錯誤發生：
檢查所有Oracle塊請求是否都由數據庫緩存提供服務
檢查是否有全表掃描
檢查所有排序是否都在內存中進行
檢查重做日志是否與其他所有數據庫文件進行了適當的隔離
等等。
對於某些工作來說，使用檢查內容清單也許很好。但是對於判斷性能問題這樣的工作，試圖確定理論上可能會出錯的每一件事，從而對這個問題進行處理的做法的效率會很低。更有效的方法就是找到這個簡單問題的答案：
是什麼花了這麼長時間？
用於優化Oracle程序的好的策略就如同日常生活中用到的策略。就像這樣：
1. 使用專門的儀器來測定程序的性能，從而監視運行速度慢的程序。
2. 為運行慢的程序創建資源描述，把程序的響應時間細分為幾種有用的類型。
3. 通過首先處理響應時間最長的部分來縮短程序的響應時間。
當你了解了若干技術細節之後，這個方法就非常簡單了。如果你真的這樣做，那麼每次你都能獲得一個有用的方法，久而久之，你將能在進行性能改進之前預知其結果。
跟蹤
如果你有用於收集程序中每個執行步驟的時間統計信息的高級工具，那就用吧。但只收集匯總數據（如通過對系統全局區[SGA]或其基礎共享存儲段采樣獲得的數據）的工具對於某些類型的問題就不適合。
使用昂貴的監控工具時最常見的匯總錯誤是它們會跨整個Oracle數據庫實例來匯總某一給定時間間隔內資源的使用情況。但是，運行速度慢的程序實際上可能不受資源爭用問題的影響，而這個問題卻完全控制著系統中一些不太重要的程序的性能。
即便是那些在Oracle數據庫會話級上匯總信息的工具在診斷一些重要的問題類型時也存在著缺陷。例如，假設一個程序運行10分鐘，調用了10000次Oracle SQL*Net message from client 這一"等待事件"，會話等待該事件的總用時為8.3分鐘。這意味著會話對SQL*Net message from clIEnt事件的等待時間平均為3秒。但是單從匯總數據看，你無法知道這10000次調用是否每次都用3秒，還是這些調用中也許有一個用了5分鐘，而其余9999次調用每次只用0.02秒。這兩種情況需要進行完全不同的處理。
在這種情況下最能為你提供幫助的診斷數據是Oracle的擴展SQL跟蹤數據。擴展SQL跟蹤文件按時間順序顯示了Oracle數據庫內核在指定時間內所完成工作的逐條記錄。收集擴展SQL跟蹤數據幾乎是免費的。最大的花銷是存儲每一個需要引起注意的跟蹤文件所需磁盤空間（很少超過幾兆字節）的費用。
跟蹤自己的代碼。如果能訪問程序的源代碼，則打開其擴展SQL跟蹤就非常容易。首先必須確保會話的TIMED_STATISTICS和MAX_DUMP_ FILE_SIZE參數設置正確：
CODE:
alter session set timed_statistics=true;
alter session set max_dump_file_size=unlimited;
如果沒有設置TIMED_STATISTICS=TRUE，則數據庫內核將把0值而不是真正的持續時間發送到跟蹤文件中。如果對MAX_DUMP_ FILE_SIZE嚴加限制，則會在跟蹤文件中生成下面這樣的消息，而不是你想要的時間數據：
*** DUMP FILE SIZE IS LIMITED TO 1048576 BYTES ***
接下來是激活跟蹤。有幾種方法可以采用。過去的方法是使用ALTER SESSION命令，如下所示：
CODE:
alter session set events '10046 trace name context forever, level 12'
/* code to be traced goes here */
alter session set events '10046 trace name context off'
更好的方法是使用DBMS_SUPPORT包來激活擴展SQL跟蹤：
CODE:
dbms_support.start_trace(waits=>true, binds=>true)
/* code to be traced goes here */
dbms_support.stop_trace()
請注意DBMS_SUPPORT 沒有文檔說明，可能也不是數據庫默認安裝的一部分。要了解DBMS_SUPPORT的信息，請參考MetaLink ( metalink.Oracle.com)。
跟蹤別人的代碼。如果你想跟蹤沒有讀/寫權限的代碼，則激活擴展SQL跟蹤就有點麻煩了。但也不會難很多。你首先要獲得你想跟蹤的會話的V$SESSION.SID和V$SESSION.SERIAL#值。然後使用下面的過程調用，可以設置所選會話的TIMED_STATISTICS和MAX_DUMP_FILE_SIZE參數：
CODE:
dbms_system.set_bool_param_in_session(
sid => 42,
serial# => 1215,
parnam => 'timed_statistics',
bval => true)
dbms_system.set_int_param_in_session(
sid => 42,
serial# => 1215,
parnam => 'max_dump_file_size',
intval => 2147483647)
（對於Oracle8 8.1.6以前的版本，你可以用ALTER SYSTEM命令處理這些參數。）
接下來要激活跟蹤。有幾種方法可以采用，包括下面兩個：
方法一是使用DBMS_SUPPORT：
CODE:
dbms_support.start_trace_in_session(
sid => 42,
serial# => 1215,
waits => true,
binds => true)
/* code to be traced executes during this time window */
dbms_support.stop_trace_in_session(
sid => 42,
serial => 1215)
若想激活擴展SQL跟蹤，請不要使用名為SET_SQL_TRACE_IN_SESSION的DBMS_SUPPORT過程。該過程不允許在跟蹤文件中指定等待和綁定的數據。
第二種方法更為精致，但在Oracle數據庫10g之前的版本中並不支持這種方法。 DBMS_MONITOR包的引入解決了許多復雜診斷數據收集問題，這些問題是由連接共享和多線程操作所引起的。你可以在Oracle數據庫10g中指定要跟蹤的服務、模塊或行動，而不指定要跟蹤的Oracle數據庫會話：
CODE:
dbms_monitor.serv_mod_act_trace_enable(
service_name => 'APPS1',
module_name => 'PAYROLL',
action_name => 'PYUGEN',
waits => true,
binds => true,
instance_name => null)
/* code to be traced executes during this time window */
dbms_monitor.serv_mod_act_trace_disable(
service_name => 'APPS1',
module_name => 'PAYROLL',
action_name => 'PYUGEN')
利用DBMS_MONITOR包，Oracle可為要跟蹤的特定的業務操作提供完全支持激活或停止診斷數據收集的方法。
測試擴展SQL跟蹤。試一試吧。查看第一個跟蹤文件只需使用一個簡單的SQL*Plus會話，就如同下面這樣：
CODE:
alter session set timed_statistics=true;
alter session set max_dump_file_size=unlimited;
alter session set tracefile_identifIEr='Hello';
/* only in Oracle Database 8.1.7and later */
alter session set events '10046 trace name context forever, level 12';
select 'Howdy, it is '||sysdate from dual;
exit;
然後在由USER_DUMP_DEST實例參數的值命名的目錄中尋找文件名中包含字符串"Hello"的最新寫入的.trc文件。用你最喜歡的文本編輯器打開它。 閱讀Oracle MetaLink注釋39817.1或（Optimizing Oracle Performance，《優化Oracle性能》）一書，以便大概了解原始跟蹤文件中有些什麼。一定要運行跟蹤文件上的tkprof，並研究其輸出，但也不要由於有了tkprof就不再看原始的跟蹤文件。跟蹤文件中還有許多tkprof沒有向你展示的內容。
如果你不僅需要一個由簡單的SELECT from DUAL 生成的跟蹤文件，還需要一個更感興趣的跟蹤文件，那麼需要跟蹤下面這條SQL語句：
CODE:
select object_type, owner, object_name from dba_objects;
由此得到的跟蹤數據會讓你感到很滿意，因為Oracle數據庫內核替你完成了驚人的工作量。
創建資源描述了正確而詳細的診斷數據之後，你需要以摘要的形式對其進行查看，這有助於你以最快的速度做出響應。至少是從20世紀70年代開始，計算機程序員使用的摘要格式就是資源描述。資源描述只是一張表，它將所用時間分解為若干有用的子集，並按各子集所用時間降序排列。下面是一個資源描述的例子：
CODE:
Response Time Component Duration
-------------------------- ----------
Freeway at <50% speed limit 28.3m 59%
Finding a parking spot 7.2m 15%
Waiting at traffic lights 5.2m 11%
Freeway at ≥50% speed limit 4.0m 8%
Other 3.1m 6%
-------------------------- ----------
Total 47.8m 100%
這個資源描述說明買一輛速度更快的車不會使你能夠更快地到達工作地點。
要從跟蹤文件創建資源描述，有兩種方法可以采用。
自己動手。《Optimizing Oracle Performance》一書中有所說明。
使用別人的工具。Oracle的tkprof和trcanalyzer（跟蹤分析器）工具可為你完成一部分工作，但不是全部。
對數據做出響應
有了詳細的診斷數據及其要點，就要決定對所看到的東西如何做出響應。對資源描述做出響應的經驗做法非常可靠且相當簡單：首先減少花費時間最長的部分，方法是減少調用它的次數。
這種方法幾乎總是正確的。理解減少給定組件的調用次數的方法，需要對不同等待事件名稱的含義有所了解。例如，當被跟蹤的Oracle會話等待"buffer busy waits"這個等待事件時，該會話會向跟蹤文件發送會生成足夠多的信息，並顯示正在等待哪一個緩沖區以及為什麼要等待。當一個會話等待SQL*Net message from clIEnt事件時，跟蹤文件中生成的數據的位置會告訴你執行過的數據庫調用哪個是多余的。
在Oracle9i第2版中，有350多個不同的等待事件。在Oracle數據庫10g中，幾乎有700個等待事件。但不必擔心：你根本不必知道它們都是什麼意思。你只需知道你的重要程序花費大部分時間所等待的那些事件是什麼意思。
看看你能做些什麼
有了合適的診斷數據，你就能迅速解決相應的問題，或者證明這些問題不值得解決。
下面給出診斷數據能夠解決的一部分問題清單：
整個系統的問題以及個別用戶（業務）操作的具體問題
查詢錯誤，包括寫得不好的SQL語句、有問題的索引以及數據密度問題
A應用程序錯誤，包括解析過度、不使用數組運算等等在內的應用程序
串行化錯誤，包括不必要的頻繁發生或費時的鎖定、鎖存或存儲緩沖區活動
網絡錯誤，如選擇的協議不當、網絡設備有問題
磁盤輸入/輸出錯誤，如高速緩存大小不適當、負載不平衡以及配置不當
容量不足，如交換、分頁和CPU占用過多
使用Oracle的擴展SQL跟蹤數據以及提出"什麼如此費時？"這種問題的方法能帶來的最好結果是在開始診斷和解決問題之前你將不必再猜測性能問題會是什麼。
