使用擴(kuò)展SQL跟蹤數(shù)據(jù)來了解是什么在耗費這么長的時間。假如有一天你開車去上班，但最后還是沒能及時參加一個重要會議。你無法將你的革命性的想法呈現(xiàn)給客戶，所以他們也不會采用。你的拖拖拉拉使你感到沮喪，你發(fā)誓決不再犯同樣的錯誤。那么，為了不再發(fā)生類似情況，你怎么判定問題的原因呢？ 檢查汽車外表是否有缺陷，因為外表有缺陷會使汽車的最高速度降低1%或更多。 檢查車輪定位，因為外傾角、后傾角或前束角不合適都會導(dǎo)致汽車的操縱不靈活并且耗費時間。 檢查發(fā)動機(jī)，以確保達(dá)到額定馬力的99%或更高。假如不是這樣，則要考慮重裝或更換發(fā)動機(jī)。 不，你可能不會采用這種檢查方法；那樣太可笑了。你可能會以完全不同的方式來判定問題之所在，可能只是問你自己一個簡單的問題：什么事情讓我花了這么長時間？ 從這個角度出發(fā)，問題就迎刃而解了。假如開車需要40分鐘，而你在會議開始前20分鐘才動身，那么下次就要提前30分鐘動身。假如因為交通擁堵浪費了20分鐘，那么，下次要么再早一些動身，換條路線，要么更仔細(xì)地查看早7點的路況報告。假如是你迷了路，結(jié)果浪費了20分鐘去兜圈子，那么下次你大概就要事先看看地圖。如此等等。 我感到希奇的是，那些擅長解決日常性能優(yōu)化問題的數(shù)據(jù)庫專業(yè)人員在工作中卻使用完全不同的方法來解決數(shù)據(jù)庫性能問題。許多數(shù)據(jù)庫'調(diào)優(yōu)人員'從來不問，'是什么讓這個程序運行了這么長時間？'相反，他們會參考檢查內(nèi)容清單，并試圖阻止錯誤發(fā)生： 檢查所有Oracle塊請求是否都由數(shù)據(jù)庫緩存提供服務(wù); 檢查是否有全表掃描; 檢查所有排序是否都在內(nèi)存中進(jìn)行; 檢查重做日志是否與其他所有數(shù)據(jù)庫文件進(jìn)行了適當(dāng)?shù)母綦x等等。 對于某些工作來說，使用檢查內(nèi)容清單也許很好。但是對于判定性能問題這樣的工作，試圖確定理論上可能會出錯的每一件事，從而對這個問題進(jìn)行處理的做法的效率會很低。更有效的方法就是找到這個簡單問題的答案：是什么花了這么長時間？ 用于優(yōu)化Oracle程序的好的策略就如同日常生活中用到的策略。就像這樣： 1. 使用專門的儀器來測定程序的性能，從而監(jiān)視運行速度慢的程序。 2. 為運行慢的程序創(chuàng)建資源描述，把程序的響應(yīng)時間細(xì)分為幾種有用的類型。 3. 通過首先處理響應(yīng)時間最長的部分來縮短程序的響應(yīng)時間。 當(dāng)你了解了若干技術(shù)細(xì)節(jié)之后，這個方法就非常簡單了。假如你真的這樣做，那么每次你都能獲得一個有用的方法，久而久之，你將能在進(jìn)行性能改進(jìn)之前預(yù)知其結(jié)果。 跟蹤 假如你有用于收集程序中每個執(zhí)行步驟的時間統(tǒng)計信息的高級工具，那就用吧。但只收集匯總數(shù)據(jù)（如通過對系統(tǒng)全局區(qū)[SGA]或其基礎(chǔ)共享存儲段采樣獲得的數(shù)據(jù)）的工具對于某些類型的問題就不適合。 使用昂貴的監(jiān)控工具時最常見的匯總錯誤是它們會跨整個Oracle數(shù)據(jù)庫實例來匯總某一給定時間間隔內(nèi)資源的使用情況。但是，運行速度慢的程序?qū)嶋H上可能不受資源爭用問題的影響，而這個問題卻完全控制著系統(tǒng)中一些不太重要的程序的性能。 即便是那些在Oracle數(shù)據(jù)庫會話級上匯總信息的工具在診斷一些重要的問題類型時也存在著缺陷。例如，假設(shè)一個程序運行10分鐘，調(diào)用了10000次Oracle SQL*Net message from client 這一'等待事件'，會話等待該事件的總用時為8.3分鐘。這意味著會話對SQL*Net message from client事件的等待時間平均為3秒。但是單從匯總數(shù)據(jù)看，你無法知道這10000次調(diào)用是否每次都用3秒，還是這些調(diào)用中也許有一個用了5分鐘，而其余9999次調(diào)用每次只用0.02秒。這兩種情況需要進(jìn)行完全不同的處理。 在這種情況下最能為你提供幫助的診斷數(shù)據(jù)是Oracle的擴(kuò)展SQL跟蹤數(shù)據(jù)。擴(kuò)展SQL跟蹤文件按時間順序顯示了Oracle數(shù)據(jù)庫內(nèi)核在指定時間內(nèi)所完成工作的逐條記錄。收集擴(kuò)展SQL跟蹤數(shù)據(jù)幾乎是免費的。最大的花銷是存儲每一個需要引起注重的跟蹤文件所需磁盤空間（很少超過幾兆字節(jié)）的費用。 跟蹤自己的代碼。假如能訪問程序的源代碼，則打開其擴(kuò)展SQL跟蹤就非常輕易。首先必須確保會話的TIMED_STATISTICS和MAX_DUMP_ FILE_SIZE參數(shù)設(shè)置正確： Code: [Copy to clipboard]alter session set timed_statistics=true;alter session set max_dump_file_size=unlimited; 假如沒有設(shè)置TIMED_STATISTICS=TRUE，則數(shù)據(jù)庫內(nèi)核將把0值而不是真正的持續(xù)時間發(fā)送到跟蹤文件中。假如對MAX_DUMP_ FILE_SIZE嚴(yán)加限制，則會在跟蹤文件中生成下面這樣的消息，而不是你想要的時間數(shù)據(jù)： ***DUMP FILE SIZE IS LIMITED TO 1048576 BYTES ***接下來是激活跟蹤。有幾種方法可以采用。過去的方法是使用ALTER SESSION命令，如下所示： Code: [Copy to clipboard]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包來激活擴(kuò)展SQL跟蹤： 　 　Code: [Copy to clipboard]dbms_support.start_trace(waits=>true, binds=>true)/* code to be traced goes here */dbms_support.stop_trace()　請注重DBMS_SUPPORT 沒有文檔說明，可能也不是數(shù)據(jù)庫默認(rèn)安裝的一部分。要了解DBMS_SUPPORT的信息，請參考MetaLink ( metalink.oracle.com)。 跟蹤別人的代碼。假如你想跟蹤沒有讀/寫權(quán)限的代碼，則激活擴(kuò)展SQL跟蹤就有點麻煩了。但也不會難很多。你首先要獲得你想跟蹤的會話的V$SESSION.SID和V$SESSION.SERIAL#值。然后使用下面的過程調(diào)用，可以設(shè)置所選會話的TIMED_STATISTICS和MAX_DUMP_FILE_SIZE參數(shù)： Code: [Copy to clipboard]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命令處理這些參數(shù)。） 接下來要激活跟蹤。有幾種方法可以采用，包括下面兩個： 方法一是使用DBMS_SUPPORT： Code: [Copy to clipboard]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) 若想激活擴(kuò)展SQL跟蹤，請不要使用名為SET_SQL_TRACE_IN_SESSION的DBMS_SUPPORT過程。該過程不答應(yīng)在跟蹤文件中指定等待和綁定的數(shù)據(jù)。 第二種方法更為精致，但在Oracle數(shù)據(jù)庫10g之前的版本中并不支持這種方法。 DBMS_MONITOR包的引入解決了許多復(fù)雜診斷數(shù)據(jù)收集問題，這些問題是由連接共享和多線程操作所引起的。你可以在Oracle數(shù)據(jù)庫10g中指定要跟蹤的服務(wù)、模塊或行動，而不指定要跟蹤的Oracle數(shù)據(jù)庫會話： Code: [Copy to clipboard]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可為要跟蹤的特定的業(yè)務(wù)操作提供完全支持激活或停止診斷數(shù)據(jù)收集的方法。測試擴(kuò)展SQL跟蹤。試一試吧。查看第一個跟蹤文件只需使用一個簡單的SQL*Plus會話，就如同下面這樣： Code: [Copy to clipboard]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實例參數(shù)的值命名的目錄中尋找文件名中包含字符串'Hello'的最新寫入的.trc文件。用你最喜歡的文本編輯器打開它。 閱讀Oracle MetaLink注釋39817.1或（Optimizing Oracle Performance，《優(yōu)化Oracle性能》）一書，以便大概了解原始跟蹤文件中有些什么。一定要運行跟蹤文件上的tkprof，并研究其輸出，但也不要由于有了tkprof就不再看原始的跟蹤文件。跟蹤文件中還有許多tkprof沒有向你展示的內(nèi)容。 假如你不僅需要一個由簡單的SELECT from DUAL 生成的跟蹤文件，還需要一個更感愛好的跟蹤文件，那么需要跟蹤下面這條SQL語句： 　 　Code: [Copy to clipboard]select object_type, owner, object_name from dba_objects; 由此得到的跟蹤數(shù)據(jù)會讓你感到很滿足，因為Oracle數(shù)據(jù)庫內(nèi)核替你完成了驚人的工作量。