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