詳細(xì)分析ORACLEAWR報告

........專業(yè)資料精心整理專業(yè)資料精心整理....專業(yè)資料精心整理詳細(xì)分析詳細(xì)分析ORACLEAWR報告AWR是Oracle10g版本推出的新特性，全稱叫AutomaticWorkloadRepository-自動負(fù)載信息庫,AWR是通過對比兩次快，照(snapshot)收集到的統(tǒng)計信息，來生成報表數(shù)據(jù)，生成的報表包括多個部分。WORKLOADREPOSITORYreportforDBNameDBIdInstanceInstnumReleaseRACHostICCI1314098396ICCI1.0YESHPGICCI1SnapIdSnapTimeSessionsCursors/SessionBeginSnap:267825-Dec-0814:04:50241.5EndSnap:268025-Dec-0815:23:37261.5Elapsed:78.79(mins)DBTime:mins)11.05(DBTime不包括Oracle后臺進(jìn)程消耗的時間。如果DBTime遠(yuǎn)遠(yuǎn)小于Elapsed時間，說明數(shù)據(jù)庫比較空閑。dbtime=cputime+waittime（不包含空閑等待）（非后臺進(jìn)程）說白了就是dbtime就是記錄的服務(wù)器花在數(shù)據(jù)庫運(yùn)算(非后臺進(jìn)程)和等待(非空閑等待)上的時間DBtime=cputime+allofnonidlewaiteventtime在79分鐘里（其間收集了3次快照數(shù)據(jù)），數(shù)據(jù)庫耗時11分鐘，RDA數(shù)據(jù)中顯示系統(tǒng)有8個邏輯CPU（4個物理CPU），平均每個CPU耗時1.4分鐘，CPU利用率只有大約2%（1.4/79）。說明系統(tǒng)壓力非常小。列出下面這兩個來做解釋：ReportA:SnapIdSnapTimeSessionsCurs/Sess---------------------------------------------BeginSnap:461024-Jul-0822:00:546819.1EndSnap:461224-Jul-0823:00:25171.7Elapsed:59.51(mins)DBTime:466.37(mins)ReportB:SnapIdSnapTimeSessionsCurs/Sess---------------------------------------------BeginSnap:309813-Nov-0721:00:373913.6EndSnap:310213-Nov-0722:00:154016.4Elapsed:59.63(mins)DBTime:19.49(mins)服務(wù)器是AIX的系統(tǒng)，4個雙核cpu,共8個核:/sbin>bindprocessor-qTheavailableprocessorsare:01234567先說ReportA,在snapshot間隔中，總共約60分鐘，cpu就共有60*8=480分鐘，DBtime為466.37分鐘，則：cpu花費(fèi)了466.37分鐘在處理Oralce非空閑等待和運(yùn)算上(比方邏輯讀)也就是說cpu有466.37/480*100%花費(fèi)在處理Oracle的操作上，這還不包括后臺進(jìn)程看ReportB，總共約60分鐘，cpu有19.49/480*100%花費(fèi)在處理Oracle的操作上很顯然，2中服務(wù)器的平均負(fù)載很低。從awrreport的Elapsedtime和DBTime就能大概了解db的負(fù)載。可是對于批量系統(tǒng)，數(shù)據(jù)庫的工作負(fù)載總是集中在一段時間內(nèi)。如果快照周期不在這一段時間內(nèi)，或者快照周期跨度太長而包含了大量的數(shù)據(jù)庫空閑時間，所得出的分析結(jié)果是沒有意義的。這也說明選擇分析時間段很關(guān)鍵，要選擇能夠代表性能問題的時間段。ReportReportSummaryCacheSizesBeginEndBufferCache:3,344M3,344MStdBlockSize:8KSharedPoolSize:704M704MLogBuffer:14,352K顯示SGA中每個區(qū)域的大?。ㄔ贏MM改變它們之后），可用來與初始參數(shù)值比較。sharedpool主要包括librarycache和dictionarycache。librarycache用來存儲最近解析（或編譯）后SQL、PL/SQL和Javaclasses等。librarycache用來存儲最近引用的數(shù)據(jù)字典。發(fā)生在librarycache或dictionarycache的cachemiss代價要比發(fā)生在buffercache的代價高得多。因此sharedpool的設(shè)置要確保最近使用的數(shù)據(jù)都能被cache。LoadProfilePerSecondPerTransactionRedosize:918,805.72775,912.72Logicalreads:,521.7732,974.06Blockchanges:,817.9511,535.22Physicalreads:68.2657.64Physicalwrites:362.59306.20Usercalls:326.69275.88Parses:38.6632.65Hardparses:0.030.03Sorts:Sorts:0.610.51Logons:0.010.01Executes:354.34299.23Transactions:1.18%BlockschangedperRead:51.62RecursiveCall%:51.72Rollbackpertransaction%:85.49RowsperSort:########顯示數(shù)據(jù)庫負(fù)載概況，將之與基線數(shù)據(jù)比較才具有更多的意義，如果每秒或每事務(wù)的負(fù)載變化不大，說明應(yīng)用運(yùn)行比較穩(wěn)定。單個的報告數(shù)據(jù)只說明應(yīng)用的負(fù)載情況，絕大多數(shù)據(jù)并沒有一個所謂“正確”的值，然而Logons大于每秒1~2個、Hardparses大于每秒100、全部parses超過每秒300表明可能有爭用問題。Redosize：每秒產(chǎn)生的日志大小(單位字節(jié))，可標(biāo)志數(shù)據(jù)變更頻率,數(shù)據(jù)庫任務(wù)的繁重與否。Logicalreads：每秒/每事務(wù)邏輯讀的塊數(shù).平?jīng)Q每秒產(chǎn)生的邏輯讀的block數(shù)。LogicalReads=ConsistentGets+DBBlockGetsBlockchanges：每秒/每事務(wù)修改的塊數(shù)Physicalreads：每秒/每事務(wù)物理讀的塊數(shù)Physicalwrites：每秒/每事務(wù)物理寫的塊數(shù)Usercalls：每秒/每事務(wù)用戶call次數(shù)Parses：SQL解析的次數(shù).每秒解析次數(shù)，包括fastparse，softparse和hardparse三種數(shù)量的綜合。軟解析每秒超過300次意味著你的"應(yīng)用程序"效率不高，調(diào)整session_cursor_cache。在這里，fastparse指的是直接在PGA中命中的情況（設(shè)置了session_cached_cursors=n）；softparse是指在sharedpool中命中的情形；hardparse則是指都不命中的情況。Hardparses：其中硬解析的次數(shù)，硬解析太多，說明SQL重用率不高。每秒產(chǎn)生的硬解析次數(shù),每秒超過100次，就可能說明你綁定使用的不好，也可能是共享池設(shè)置不合理。這時候可以啟用參數(shù)cursor_sharing=similar|force，該參數(shù)默認(rèn)值為exact。但該參數(shù)設(shè)置為similar時，存在bug，可能導(dǎo)致執(zhí)行計劃的不優(yōu)。Sorts：每秒/每事務(wù)的排序次數(shù)Logons：每秒/每事務(wù)登錄的次數(shù)Executes：每秒/每事務(wù)SQL執(zhí)行次數(shù)Transactions：每秒事務(wù)數(shù).每秒產(chǎn)生的事務(wù)數(shù)，反映數(shù)據(jù)庫任務(wù)繁重與否。BlockschangedperRead：表示邏輯讀用于修改數(shù)據(jù)塊的比例.在每一次邏輯讀中更改的塊的百分比。RecursiveCall：遞歸調(diào)用占所有操作的比率.遞歸調(diào)用的百分比，如果有很多PL/SQL，那么這個值就會比較高。Rollbackpertransaction：每事務(wù)的回滾率.看回滾率是不是很高，因為回滾很耗資源,如果回滾率過高,可能說明你的數(shù)據(jù)庫經(jīng)歷了太多的無效操作,過多的回滾可能還會帶來UndoBlock的競爭該參數(shù)計算公式如下:Round(Userrollbacks/(usercommits+userrollbacks),4)*100%。RowsperSort：每次排序的行數(shù)注:Oracle的硬解析和軟解析提到軟解析(softprase)和硬解析(hardprase)，就不能不說一下Oracle對sql的處理過程。當(dāng)你發(fā)出一條sql語句交付Oracle，在執(zhí)行和獲取結(jié)果前，Oracle對此sql將進(jìn)行幾個步驟的處理過程：語法檢查(syntaxcheck)檢查此sql的拼寫是否語法。語義檢查(semanticcheck)諸如檢查sql語句中的訪問對象是否存在及該用戶是否具備相應(yīng)的權(quán)限。對sql語句進(jìn)行解析(prase)利用內(nèi)部算法對sql進(jìn)行解析，生成解析樹(parsetree)及執(zhí)行計劃(executionplan)。執(zhí)行sql，返回結(jié)果(executeandreturn)其中，軟、硬解析就發(fā)生在第三個過程里。Oracle利用內(nèi)部的hash算法來取得該sql的hash值，然后在librarycache里查找是否存在該hash值；假設(shè)存在，則將此sql與cache中的進(jìn)行比較；假設(shè)“相同”，就將利用已有的解析樹與執(zhí)行計劃，而省略了優(yōu)化器的相關(guān)工作。這也就是軟解析的過程。誠然，如果上面的2個假設(shè)中任有一個不成立，那么優(yōu)化器都將進(jìn)行創(chuàng)建解析樹、生成執(zhí)行計劃的動作。這個過程就叫硬解析。創(chuàng)建解析樹、生成執(zhí)行計劃對于sql的執(zhí)行來說是開銷昂貴的動作，所以，應(yīng)當(dāng)極力避免硬解析，盡量使用軟解析。InstanceEfficiencyPercentages(Target100%)BufferNowait%:BufferNowait%:100.00RedoNoWait%:100.00BufferHit%:98.72In-memorySort%:99.86LibraryHit%:99.97SoftParse%:99.92ExecutetoParse%:89.09LatchHit%:99.99ParseCPUtoParseElapsd%:7.99%Non-ParseCPU:99.95本節(jié)包含了Oracle關(guān)鍵指標(biāo)的內(nèi)存命中率及其它數(shù)據(jù)庫實例操作的效率。其中BufferHitRatio也稱CacheHitRatio，LibraryHitratio也稱LibraryCacheHitratio。同LoadProfile一節(jié)相同，這一節(jié)也沒有所謂“正確”的值，而只能根據(jù)應(yīng)用的特點(diǎn)判斷是否合適。在一個使用直接讀執(zhí)行大型并行查詢的DSS環(huán)境，20%的BufferHitRatio是可以接受的，而這個值對于一個OLTP系統(tǒng)是完全不能接受的。根據(jù)Oracle的經(jīng)驗，對于OLTP系統(tǒng)，BufferHitRatio理想應(yīng)該在90%以上。BufferNowait表示在內(nèi)存獲得數(shù)據(jù)的未等待比例。在緩沖區(qū)中獲取Buffer的未等待比率。BufferNowait的這個值一般需要大于99%。否則可能存在爭用，可以在后面的等待事件中進(jìn)一步確認(rèn)。bufferhit表示進(jìn)程從內(nèi)存中找到數(shù)據(jù)塊的比率，監(jiān)視這個值是否發(fā)生重大變化比這個值本身更重要。對于一般的OLTP系統(tǒng)，如果此值低于80%，應(yīng)該給數(shù)據(jù)庫分配更多的內(nèi)存。數(shù)據(jù)塊在數(shù)據(jù)緩沖區(qū)中的命中率，通常應(yīng)在95%以上。否則，小于95%，需要調(diào)整重要的參數(shù)，小于90%可能是要加db_cache_size。一個高的命中率，不一定代表這個系統(tǒng)的性能是最優(yōu)的，比如大量的非選擇性的索引被頻繁訪問，就會造成命中率很高的假相（大量的dbfilesequentialread），但是一個比較低的命中率，一般就會對這個系統(tǒng)的性能產(chǎn)生影響，需要調(diào)整。命中率的突變，往往是一個不好的信息。如果命中率突然增大，可以檢查topbuffergetSQL，查看導(dǎo)致大量邏輯讀的語句和索引，如果命中率突然減小，可以檢查topphysicalreadsSQL，檢查產(chǎn)生大量物理讀的語句，主要是那些沒有使用索引或者索引被刪除的。RedoNoWait表示在LOG緩沖區(qū)獲得BUFFER的未等待比例。如果太低（可參考90%閥值），考慮增加LOGBUFFER。當(dāng)redobuffer達(dá)到1M時，就需要寫到redolog文件，所以一般當(dāng)redobuffer設(shè)置超過1M，不太可能存在等待buffer空間分配的情況。當(dāng)前，一般設(shè)置為2M的redobuffer，對于內(nèi)存總量來說，應(yīng)該不是一個太大的值。libraryhit表示Oracle從LibraryCache中檢索到一個解析過的SQL或PL/SQL語句的比率，當(dāng)應(yīng)用程序調(diào)用SQL或存儲過程時，Oracle檢查LibraryCache確定是否存在解析過的版本，如果存在，Oracle立即執(zhí)行語句；如果不存在，Oracle解析此語句，并在LibraryCache中為它分配共享SQL區(qū)。低的libraryhitratio會導(dǎo)致過多的解析，增加CPU消耗，降低性能。如果libraryhitratio低于90%，可能需要調(diào)大sharedpool區(qū)。STATEMENT在共享區(qū)的命中率，通常應(yīng)該保持在95%以上，否則需要要考慮：加大共享池；使用綁定變量；修改cursor_sharing等參數(shù)。LatchHit：Latch是一種保護(hù)內(nèi)存結(jié)構(gòu)的鎖，可以認(rèn)為是SERVER進(jìn)程獲取訪問內(nèi)存數(shù)據(jù)結(jié)構(gòu)的許可。要確保LatchHit>99%，否則意味著SharedPoollatch爭用，可能由于未共享的SQL，或者LibraryCache太小，可使用綁定變更或調(diào)大SharedPool解決。要確保>99%，否則存在嚴(yán)重的性能問題。當(dāng)該值出現(xiàn)問題的時候，我們可以借助后面的等待時間和latch分析來查找解決問題。ParseCPUtoParseElapsd：解析實際運(yùn)行時間/(解析實際運(yùn)行時間+解析中等待資源時間)，越高越好。計算公式為：ParseCPUtoParseElapsd%=100*(parsetimecpu/parsetimeelapsed)。即：解析實際運(yùn)行時間/(解析實際運(yùn)行時間+解析中等待資源時間)。如果該比率為100%，意味著CPU等待時間為0，沒有任何等待。Non-ParseCPU：SQL實際運(yùn)行時間/(SQL實際運(yùn)行時間+SQL解析時間)，太低表示解析消耗時間過多。計算公式為：%Non-ParseCPU=round(100*1-PARSE_CPU/TOT_CPU),2)。如果這個值比較小，表示解析消耗的CPU時間過多。與PARSE_CPU相比，如果TOT_CPU很高，這個比值將接近100%，這是很好的，說明計算機(jī)執(zhí)行的大部分工作是執(zhí)行查詢的工作，而不是分析查詢的工作。ExecutetoParse：是語句執(zhí)行與分析的比例，如果要SQL重用率高，則這個比例會很高。該值越高表示一次解析后被重復(fù)執(zhí)行的次數(shù)越多。計算公式為：ExecutetoParse=100*(1-Parses/Executions)。本例中，差不多每execution5次需要一次parse。所以如果系統(tǒng)Parses>Executions，就可能出現(xiàn)該比率小于0的情況。該值<0通常說明sharedpool設(shè)置或者語句效率存在問題，造成反復(fù)解析，reparse可能較嚴(yán)重,或者是可能同snapshot有關(guān)，通常說明數(shù)據(jù)庫性能存在問題。In-memorySort：在內(nèi)存中排序的比率，如果過低說明有大量的排序在臨時表空間中進(jìn)行?？紤]調(diào)大PGA(10g)。如果低于95%，可以通過適當(dāng)調(diào)大初始化參數(shù)PGA_AGGREGATE_TARGET或者SORT_AREA_SIZE來解決，注意這兩個參數(shù)設(shè)置作用的范圍時不同的，SORT_AREA_SIZE是針對每個session設(shè)置的，PGA_AGGREGATE_TARGET則時針對所有的sesion的。SoftParse：軟解析的百分比（softs/softs+hards），近似當(dāng)作sql在共享區(qū)的命中率，太低則需要調(diào)整應(yīng)用使用綁定變量。sql在共享區(qū)的命中率，小于<95%,需要考慮綁定，如果低于80%，那么就可以認(rèn)為sql基本沒有被重用。SharedPoolStatisticsBeginEndMemoryUsage%:47.1947.50%SQLwithexecutions>1:88.4879.81%MemoryforSQLw/exec>1:79.9973.52MemoryUsage%：對于一個已經(jīng)運(yùn)行一段時間的數(shù)據(jù)庫來說，共享池內(nèi)存使用率，應(yīng)該穩(wěn)定在75%-90%間，如果太小，說明SharedPool有浪費(fèi)，而如果高于90，說明共享池中有爭用，內(nèi)存不足。這個數(shù)字應(yīng)該長時間穩(wěn)定在75%～90%。如果這個百分比太低，表明共享池設(shè)置過大，帶來額外的管理上的負(fù)擔(dān)，從而在某些條件下會導(dǎo)致性能的下降。如果這個百分率太高，會使共享池外部的組件老化，如果SQL語句被再次執(zhí)行，這將使得SQL語句被硬解析。在一個大小合適的系統(tǒng)中，共享池的使用率將處于75%到略低于90%的范圍內(nèi).SQLwithexecutions>1：執(zhí)行次數(shù)大于1的sql比率，如果此值太小，說明需要在應(yīng)用中更多使用綁定變量，避免過多SQL解析。在一個趨向于循環(huán)運(yùn)行的系統(tǒng)中，必須認(rèn)真考慮這個數(shù)字。在這個循環(huán)系統(tǒng)中，在一天中相對于另一部分時間的部分時間里執(zhí)行了一組不同的SQL語句。在共享池中，在觀察期間將有一組未被執(zhí)行過的SQL語句，這僅僅是因為要執(zhí)行它們的語句在觀察期間沒有運(yùn)行。只有系統(tǒng)連續(xù)運(yùn)行相同的SQL語句組，這個數(shù)字才會接近100%。MemoryforSQLw/exec>1：執(zhí)行次數(shù)大于1的SQL消耗內(nèi)存的占比。這是與不頻繁使用的SQL語句相比，頻繁使用的SQL語句消耗內(nèi)存多少的一個度量。這個數(shù)字將在總體上與%SQLwithexecutions>1非常接近，除非有某些查詢?nèi)蝿?wù)消耗的內(nèi)存沒有規(guī)律。在穩(wěn)定狀態(tài)下，總體上會看見隨著時間的推移大約有75%～85%的共享池被使用。如果Statspack報表的時間窗口足夠大到覆蓋所有的周期，執(zhí)行次數(shù)大于一次的SQL語句的百分率應(yīng)該接近于100%。這是一個受觀察之間持續(xù)時間影響的統(tǒng)計數(shù)字。可以期望它隨觀察之間的時間長度增大而增大。小結(jié)：通過ORACLE的實例有效性統(tǒng)計數(shù)據(jù)，我們可以獲得大概的一個整體印象，然而我們并不能由此來確定數(shù)據(jù)運(yùn)行的性能。當(dāng)前性能問題的確定，我們主要還是依靠下面的等待事件來確認(rèn)。我們可以這樣理解兩部分的內(nèi)容，hit統(tǒng)計幫助我們發(fā)現(xiàn)和預(yù)測一些系統(tǒng)將要產(chǎn)生的性能問題，由此我們可以做到未雨綢繆。而wait事件，就是表明當(dāng)前數(shù)據(jù)庫已經(jīng)出現(xiàn)了性能問題需要解決，所以是亡羊補(bǔ)牢的性質(zhì)。Top5TimedEventsEventEventWaitsTime(s)AvgWait(ms)%TotalCallTimeWaitClassCPUtime51577.6SQL*Netmoredatafromclient,319276429.7Networklogfileparallelwrite5,4974797.1SystemI/Odbfilesequentialread7,9003545.3UserI/Odbfileparallelwrite4,8063475.1SystemI/O這是報告概要的最后一節(jié)，顯示了系統(tǒng)中最嚴(yán)重的5個等待，按所占等待時間的比例倒序列示。當(dāng)我們調(diào)優(yōu)時，總希望觀察到最顯著的效果，因此應(yīng)當(dāng)從這里入手確定我們下一步做什么。例如如果‘bufferbusywait’是較嚴(yán)重的等待事件，我們應(yīng)當(dāng)繼續(xù)研究報告中BufferWait和File/TablespaceIO區(qū)的內(nèi)容，識別哪些文件導(dǎo)致了問題。如果最嚴(yán)重的等待事件是I/O事件，我們應(yīng)當(dāng)研究按物理讀排序的SQL語句區(qū)以識別哪些語句在執(zhí)行大量I/O，并研究Tablespace和I/O區(qū)觀察較慢響應(yīng)時間的文件。如果有較高的LATCH等待，就需要察看詳細(xì)的LATCH統(tǒng)計識別哪些LATCH產(chǎn)生的問題。一個性能良好的系統(tǒng)，cputime應(yīng)該在top5的前面，否則說明你的系統(tǒng)大部分時間都用在等待上。在這里，logfileparallelwrite是相對比較多的等待，占用了7%的CPU時間。通常，在沒有問題的數(shù)據(jù)庫中，CPUtime總是列在第一個。更多的等待事件，參見本報告的WaitEvents一節(jié)。RACRACStatisticsBeginEndNumberofInstances:22GlobalCacheLoadProfilePerSecondPerTransactionGlobalCacheblocksreceived:4.163.51GlobalCacheblocksserved:5.975.04GCS/GESmessagesreceived:408.47344.95GCS/GESmessagessent:258.03217.90DBWRFusionwrites:0.050.05EstdInterconnecttraffic(KB)211.16GlobalCacheEfficiencyPercentages(Targetlocal+remote100%)Bufferaccess-localcache%:Bufferaccess-localcache%:98.60Bufferaccess-remotecache%:0.12Bufferaccess-disk%:Bufferaccess-disk%:1.28GlobalCacheandEnqueueServices-WorkloadCharacteristicsAvgglobalenqueuegettime(ms):Avgglobalenqueuegettime(ms):0.1Avgglobalcachecrblockreceivetime(ms):1.1Avgglobalcachecurrentblockreceivetime(ms):0.8Avgglobalcachecrblockbuildtime(ms):0.0Avgglobalcachecrblocksendtime(ms):0.0Globalcachelogflushesforcrblocksserved%:3.5Avgglobalcachecrblockflushtime(ms):3.9Avgglobalcachecurrentblockpintime(ms):0.0Avgglobalcachecurrentblocksendtime(ms):0.0Globalcachelogflushesforcurrentblocksserved%:0.4Avgglobalcachecurrentblockflushtime(ms):3.0GlobalCacheandEnqueueServices-MessagingStatisticsAvgmessagesentqueuetime(ms):0.0Avgmessagesentqueuetime(ms):0.0Avgmessagesentqueuetimeonksxp(ms):0.3Avgmessagereceivedqueuetime(ms):0.5AvgGCSmessageprocesstime(ms):0.0AvgGESmessageprocesstime(ms):0.0%ofdirectsentmessages:14.40%ofindirectsentmessages:77.04%offlowcontrolledmessages:8.56MainReport??WaitEventsStatistics?SQLStatistics?InstanceActivityStatistics?IOStats?BufferPoolStatistics?AdvisoryStatistics?WaitStatistics?UndoStatistics?LatchStatistics?SegmentStatistics?DictionaryCacheStatistics?LibraryCacheStatistics?MemoryStatistics?StreamsStatistics?ResourceLimitStatistics?init.oraParametersWaitEventsStatistics??TimeModelStatistics?WaitClass?WaitEvents?BackgroundWaitEvents?OperatingSystemStatistics?ServiceStatistics?ServiceWaitClassStatsBacktoTop/*oracle等待事件是衡量oracle運(yùn)行狀況的重要依據(jù)及指示，等待事件分為兩類：空閑等待事件和非空閑等待事件,TIMED_STATISTICS=TRUE那么等待事件按等待的時間排序，=FALSE那么事件按等待的數(shù)量排序。運(yùn)行statspack期間必須session上設(shè)置TIMED_STATISTICS=TRUE，否則統(tǒng)計的數(shù)據(jù)將失真。空閑等待事件是oracle正等待某種工作，在診斷和優(yōu)化數(shù)據(jù)庫時候，不用過多注意這部分事件，非空閑等待事件專門針對oracle的活動，指數(shù)據(jù)庫任務(wù)或應(yīng)用程序運(yùn)行過程中發(fā)生的等待，這些等待事件是我們在調(diào)整數(shù)據(jù)庫應(yīng)該關(guān)注的。對于常見的等待事件，說明如下：dbfilescatteredread文件分散讀取該事件通常與全表掃描或者fastfullindexscan有關(guān)。因為全表掃描是被放入內(nèi)存中進(jìn)行的進(jìn)行的，通常情況下基于性能的考慮，有時候也可能是分配不到足夠長的連續(xù)內(nèi)存空間，所以會將數(shù)據(jù)塊分散(scattered)讀入BufferCache中。該等待過大可能是缺少索引或者沒有合適的索引(可以調(diào)整optimizer_index_cost_adj)。這種情況也可能是正常的，因為執(zhí)行全表掃描可能比索引掃描效率更高。當(dāng)系統(tǒng)存在這些等待時，需要通過檢查來確定全表掃描是否必需的來調(diào)整。因為全表掃描被置于LRU(LeastRecentlyUsed，最近最少適用)列表的冷端(coldend)，對于頻繁訪問的較小的數(shù)據(jù)表，可以選擇把他們Cache到內(nèi)存中，以避免反復(fù)讀取。當(dāng)這個等待事件比較顯著時，可以結(jié)合v$session_longops動態(tài)性能視圖來進(jìn)行診斷，該視圖中記錄了長時間(運(yùn)行時間超過6秒的)運(yùn)行的事物，可能很多是全表掃描操作(不管怎樣，這部分信息都是值得我們注意的)。關(guān)于參數(shù)OPTIMIZER_INDEX_COST_ADJ＝n：該參數(shù)是一個百分比值，缺省值為100，可以理解為FULLSCANCOST/INDEXSCANCOST。當(dāng)n%*INDEXSCANCOST<FULLSCANCOST時，oracle會選擇使用索引。在具體設(shè)置的時候，我們可以根據(jù)具體的語句來調(diào)整該值。如果我們希望某個statement使用索引，而實際它確走全表掃描，可以對比這兩種情況的執(zhí)行計劃不同的COST，從而設(shè)置一個更合適的值。dbfilesequentialread文件順序讀取整代碼,特別是表連接：該事件說明在單個數(shù)據(jù)塊上大量等待，該值過高通常是由于表間連接順序很糟糕（沒有正確選擇驅(qū)動行源），或者使用了非選擇性索引。通過將這種等待與statspack報表中已知其它問題聯(lián)系起來(如效率不高的sql),通過檢查確保索引掃描是必須的，并確保多表連接的連接順序來調(diào)整。bufferbusywait緩沖區(qū)忙增大DB_CACHE_SIZE,加速檢查點(diǎn),調(diào)整代碼：當(dāng)進(jìn)程需要存取SGA中的buffer的時候，它會依次執(zhí)行如下步驟的操作：當(dāng)緩沖區(qū)以一種非共享方式或者如正在被讀入到緩沖時,就會出現(xiàn)該等待。該值不應(yīng)該大于1%。當(dāng)出現(xiàn)等待問題時，可以檢查緩沖等待統(tǒng)計部分(或V$WAITSTAT)，確定該等待發(fā)生在什么位置：如果等待是否位于段頭(SegmentHeader)。這種情況表明段中的空閑列表（freelist）的塊比較少?？梢钥紤]增加空閑列表(freelist，對于Oracle8iDMT)或者增加freelistgroups(在很多時候這個調(diào)整是立竿見影的(altertabletablenamestrorage(freelists2))，在8.1.6之前，這個freelists參數(shù)不能動態(tài)修改;在8.1.6及以后版本，動態(tài)修改feelists需要設(shè)置COMPATIBLE至少為8.1.6)。也可以增加PCTUSED與PCTFREE之間距離（PCTUSED-to-pctfreegap），其實就是說降低PCTUSED的值，盡快使塊返回freelist列表被重用。如果支持自動段空間管理（ASSM），也可以使用ASSM模式，這是在ORALCE920以后的版本中新增的特性。如果這一等待位于undoheader，可以通過增加回滾段(rollbacksegment)來解決緩沖區(qū)的問題。如果等待位于undoblock上，我們需要增加提交的頻率，使block可以盡快被重用；使用更大的回滾段；降低一致讀所選擇的表中數(shù)據(jù)的密度；增大DB_CACHE_SIZE。如果等待處于datablock，表明出現(xiàn)了hotblock，可以考慮如下方法解決：①將頻繁并發(fā)訪問的表或數(shù)據(jù)移到另一數(shù)據(jù)塊或者進(jìn)行更大范圍的分布(可以增大pctfree值，擴(kuò)大數(shù)據(jù)分布，減少競爭)，以避開這個"熱點(diǎn)"數(shù)據(jù)塊。②也可以減小數(shù)據(jù)塊的大小，從而減少一個數(shù)據(jù)塊中的數(shù)據(jù)行數(shù)，降低數(shù)據(jù)塊的熱度，減小競爭；③檢查對這些熱塊操作的SQL語句，優(yōu)化語句。④增加hotblock上的initrans值。但注意不要把initrans值設(shè)置的過于高了，通常設(shè)置為5就足夠了。因為增加事務(wù)意味著要增加ITL事務(wù)槽，而每個ITL事務(wù)槽將占用數(shù)據(jù)塊中24個字節(jié)長度。默認(rèn)情況下，每個數(shù)據(jù)塊或者索引塊中是ITL槽是2個，在增加initrans的時候，可以考慮增大數(shù)據(jù)塊所在的表的PCTFREE值，這樣Oracle會利用PCTFREE部分的空間增加ITLslot數(shù)量，最大達(dá)到maxtrans指定。如果等待處于indexblock，應(yīng)該考慮重建索引、分割索引或使用反向鍵索引。為了防止與數(shù)據(jù)塊相關(guān)的緩沖忙等待，也可以使用較小的塊，在這種情況下，單個塊中的記錄就較少，所以這個塊就不是那么"繁忙"。或者可以設(shè)置更大的PCTFREE,使數(shù)據(jù)擴(kuò)大物理分布，減少記錄間的熱點(diǎn)競爭。在執(zhí)行DML(insert/update/delete)時，Oracle向數(shù)據(jù)塊中寫入信息，對于多事務(wù)并發(fā)訪問的數(shù)據(jù)表，關(guān)于ITL的競爭和等待可能出現(xiàn)，為了減少這個等待，可以增加initrans，使用多個ITL槽。在Oracle9i中，可以使用ASSM這個新特性O(shè)racle使用位圖來管理空間使用，減小爭用?！井?dāng)進(jìn)程需要存取SGA中的buffer的時候，它會依次執(zhí)行如下步驟的操作：1.獲得cachebufferschainslatch，遍歷那條bufferchain直到找到需要的bufferheader2.根據(jù)需要進(jìn)行的操作類型(讀或?qū)?，它需要在bufferheader上獲得一個共享或獨(dú)占模式的bufferpin或者bufferlock3.若進(jìn)程獲得bufferheaderpin，它會釋放獲得的cachebufferschainslatch，然后執(zhí)行對bufferblock的操作4.若進(jìn)程無法獲得bufferheaderpin，它就會在bufferbusywaits事件上等待進(jìn)程之所以無法獲得bufferheaderpin，是因為為了保證數(shù)據(jù)的一致性，同一時刻一個block只能被一個進(jìn)程pin住進(jìn)行存取，因此當(dāng)一個進(jìn)程需要存取buffercache中一個被其他進(jìn)程使用的block的時候，這個進(jìn)程就會產(chǎn)生對該block的bufferbusywaits事件。截至Oracle9i，bufferbusywaits事件的p1,p2,p3三個參數(shù)分別是file#,block#和id，分別表示等待的bufferblock所在的文件編號，塊編號和具體的等待原因編號，到了Oracle10g，前兩個參數(shù)沒變，第3個參數(shù)變成了塊類型編號，這一點(diǎn)可以通過查詢v$event_name視圖來進(jìn)行驗證：PHPcode:Oracle9iSQL>selectparameter1,parameter2,parameter3fromv$event_namewherename='bufferbusywaits'PARAMETER1PARAMETER2PARAMETER3------------------------------------------------------------------------file#block#idOracle10gPARAMETER1PARAMETER2PARAMETER3------------------------------------------------------------------------file#block#class#在診斷bufferbusywaits事件的過程中，獲取如下信息會很有用：1.獲取產(chǎn)生bufferbusywaits事件的等待原因編號，這可以通過查詢該事件的p3參數(shù)值獲得2.獲取產(chǎn)生此事件的SQL語句，可以通過如下的查詢獲得：selectsql_textfromv$sqlt1,v$sessiont2,v$session_waitt3wheret1.address=t2.sql_addressandt1.hash_value=t2.sql_hash_valueandt2.sid=t3.sidandt3.event='bufferbusywaits';3.獲取等待的塊的類型以及所在的segment，可以通過如下查詢獲得：PHPcode:select'SegmentHeader'class,a.segment_type,a.segment_name,a.partition_namefromdba_segmentsa,v$session_waitbwherea.header_file=b.p1anda.header_block=b.p2andb.event='bufferbusywaits'unionselect'FreelistGroups'class,a.segment_type,a.segment_name,a.partition_namefromdba_segmentsa,v$session_waitbwherea.header_file=b.p1andb.p2betweena.header_block+1and(a.header_block+a.freelist_groups)anda.freelist_groups>1andb.event='bufferbusywaits'unionselecta.segment_type||'block'class,a.segment_type,a.segment_name,a.partition_namefromdba_extentsa,v$session_waitbwherea.file_id=b.p1andb.p2betweena.block_idanda.block_id+a.blocks-1andb.event='bufferbusywaits'andnotexists(select1fromdba_segmentswhereheader_file=b.p1andheader_block=b.p2);查詢的第一部分：如果等待的塊類型是segmentheader，那么可以直接拿bufferbusywaits事件的p1和p2參數(shù)去dba_segments視圖中匹配header_file和header_block字段即可找到等待的segment名稱和segment類型，進(jìn)行相應(yīng)調(diào)整查詢的第二部分：如果等待的塊類型是freelistgroups，也可以在dba_segments視圖中找出對應(yīng)的segment名稱和segment類型，注意這里的參數(shù)p2表示的freelistgroups的位置是在segment的header_block+1到header_block+freelistgroups組數(shù)之間，并且freelistgroups組數(shù)大于1查詢的第三部分：如果等待的塊類型是普通的數(shù)據(jù)塊，那么可以用p1、p2參數(shù)和dba_extents進(jìn)行聯(lián)合查詢得到block所在的segment名稱和segment類型對于不同的等待塊類型，我們采取不同的處理辦法：1.datasegmentheader：進(jìn)程經(jīng)常性的訪問datasegmentheader通常有兩個原因：獲取或修改processfreelists信息、擴(kuò)展高水位標(biāo)記，針對第一種情況，進(jìn)程頻繁訪問processfreelists信息導(dǎo)致freelist爭用，我們可以增大相應(yīng)的segment對象的存儲參數(shù)freelist或者freelistgroups；若由于數(shù)據(jù)塊頻繁進(jìn)出freelist而導(dǎo)致進(jìn)程經(jīng)常要修改freelist，則可以將pctfree值和pctused值設(shè)置較大的差距，從而避免數(shù)據(jù)塊頻繁進(jìn)出freelist；對于第二種情況，由于該segment空間消耗很快，而設(shè)置的nextextent過小，導(dǎo)致頻繁擴(kuò)展高水位標(biāo)記，解決的辦法是增大segment對象的存儲參數(shù)nextextent或者直接在創(chuàng)建表空間的時候設(shè)置extentsizeuniform2.datablock：某一或某些數(shù)據(jù)塊被多個進(jìn)程同時讀寫，成為熱點(diǎn)塊，可以通過如下這些辦法來解決這個問題：(1)降低程序的并發(fā)度，如果程序中使用了parallel查詢，降低paralleldegree，以免多個parallelslave同時訪問同樣的數(shù)據(jù)對象而形成等待降低性能(2)調(diào)整應(yīng)用程序使之能讀取較少的數(shù)據(jù)塊就能獲取所需的數(shù)據(jù)，減少buffergets和physicalreads(3)減少同一個block中的記錄數(shù)，使記錄分布于更多的數(shù)據(jù)塊中，這可以通過若干途徑實現(xiàn)：可以調(diào)整segment對象的pctfree值，可以將segment重建到blocksize較小的表空間中，還可以用altertableminimizerecords_per_block語句減少每塊中的記錄數(shù)(4)若熱點(diǎn)塊對象是類似自增id字段的索引，則可以將索引轉(zhuǎn)換為反轉(zhuǎn)索引，打散數(shù)據(jù)分布，分散熱點(diǎn)塊3.undosegmentheader：undosegmentheader爭用是因為系統(tǒng)中undosegment不夠，需要增加足夠的undosegment，根據(jù)undosegment的管理方法，若是手工管理模式，需要修改rollback_segments初始化參數(shù)來增加rollbacksegment，若是自動管理模式，可以減小transactions_per_rollback_segment初始化參數(shù)的值來使oracle自動增多rollbacksegment的數(shù)量4.undoblock：undoblock爭用是由于應(yīng)用程序中存在對數(shù)據(jù)的讀和寫同時進(jìn)行，讀進(jìn)程需要到undosegment中去獲得一致性數(shù)據(jù)，解決辦法是錯開應(yīng)用程序修改數(shù)據(jù)和大量查詢數(shù)據(jù)的時間小結(jié)：bufferbusywaits事件是oracle等待事件中比較復(fù)雜的一個，其形成原因很多，需要根據(jù)p3參數(shù)對照Oracle提供的原因代碼表進(jìn)行相應(yīng)的診斷，10g以后則需要根據(jù)等待的block類型結(jié)合引起等待時間的具體SQL進(jìn)行分析，采取相應(yīng)的調(diào)整措施】4)latchfree：當(dāng)閂鎖丟失率高于0.5%時，需要調(diào)整這個問題。詳細(xì)的我們在后面的LatchActivityforDB部分說明。latch是一種低級排隊機(jī)制，用于保護(hù)SGA中共享內(nèi)存結(jié)構(gòu)。latch就像是一種快速地被獲取和釋放的內(nèi)存鎖。用于防止共享內(nèi)存結(jié)構(gòu)被多個用戶同時訪問。如果latch不可用，就會記錄latch釋放失敗(latchfreemiss)。有兩種與閂有關(guān)的類型:■立刻?！隹梢缘却＜偃缫粋€進(jìn)程試圖在立刻模式下獲得閂，而該閂已經(jīng)被另外一個進(jìn)程所持有，如果該閂不能立可用的話，那么該進(jìn)程就不會為獲得該閂而等待。它將繼續(xù)執(zhí)行另一個操作。大多數(shù)latch問題都與以下操作相關(guān):沒有很好的是用綁定變量(librarycachelatch)、重作生成問題(redoallocationlatch)、緩沖存儲競爭問題(cachebuffersLRUchain)，以及buffercache中的存在"熱點(diǎn)"塊(cachebufferschain)。通常我們說，如果想設(shè)計一個失敗的系統(tǒng)，不考慮綁定變量，這一個條件就夠了，對于異構(gòu)性強(qiáng)的系統(tǒng)，不使用綁定變量的后果是極其嚴(yán)重的。另外也有一些latch等待與bug有關(guān)，應(yīng)當(dāng)關(guān)注Metalink相關(guān)bug的公布及補(bǔ)丁的發(fā)布。當(dāng)latchmissratios大于0.5%時，就應(yīng)當(dāng)研究這一問題。Oracle的latch機(jī)制是競爭，其處理類似于網(wǎng)絡(luò)里的CSMA/CD，所有用戶進(jìn)程爭奪latch，對于愿意等待類型(willing-to-wait)的latch,如果一個進(jìn)程在第一次嘗試中沒有獲得latch,那么它會等待并且再嘗試一次,如果經(jīng)過_spin_count次爭奪不能獲得latch,然后該進(jìn)程轉(zhuǎn)入睡眠狀態(tài)，持續(xù)一段指定長度的時間，然后再次醒來，按順序重復(fù)以前的步驟.在8i/9i中默認(rèn)值是_spin_count=2000。如果SQL語句不能調(diào)整，在8.1.6版本以上，Oracle提供了一個新的初始化參數(shù):CURSOR_SHARING可以通過設(shè)置CURSOR_SHARING=force在服務(wù)器端強(qiáng)制綁定變量。設(shè)置該參數(shù)可能會帶來一定的副作用，對于Java的程序，有相關(guān)的bug，具體應(yīng)用應(yīng)該關(guān)注Metalink的bug公告。***Latch問題及可能解決辦法------------------------------LibraryCacheandSharedPool(未綁定變量---綁定變量,調(diào)整shared_pool_size)每當(dāng)執(zhí)行SQL或PL/SQL存儲過程,包,函數(shù)和觸發(fā)器時,這個Latch即被用到.Parse操作中此Latch也會被頻繁使用.RedoCopy(增大_LOG_SIMULTANEOUS_COPIES參數(shù))重做拷貝Latch用來從PGA向重做日志緩沖區(qū)拷貝重做記錄.RedoAllocation(最小化REDO生成,避免不必要提交)此Latch用來分配重做日志緩沖區(qū)中的空間,可以用NOLOGGING來減緩競爭.RowCacheObjects(增大共享池)數(shù)據(jù)字典競爭.過度parsing.CacheBuffersChains(_DB_BLOCK_HASH_BUCKETS應(yīng)增大或設(shè)為質(zhì)數(shù))"過熱"數(shù)據(jù)塊造成了內(nèi)存緩沖鏈Latch競爭.CacheBuffersLruChain(調(diào)整SQL，設(shè)置DB_BLOCK_LRU_LATCHES,或使用多個緩沖區(qū)池)掃描全部內(nèi)存緩沖區(qū)塊的LRU(最近最少使用)鏈時要用到內(nèi)存緩沖區(qū)LRU鏈Latch.太小內(nèi)存緩沖區(qū)、過大的內(nèi)存緩沖區(qū)吞吐量、過多的內(nèi)存中進(jìn)行的排序操作、DBWR速度跟不上工作負(fù)載等會引起此Latch競爭。5)Enqueue隊列是一種鎖，保護(hù)一些共享資源，防止并發(fā)的DML操作。隊列采用FIFO策略，注意latch并不是采用的FIFO機(jī)制。比較常見的有3種類型的隊列：ST隊列，HW隊列，TX4隊列。STEnqueue的等待主要是在字典管理的表空間中進(jìn)行空間管理和分配時產(chǎn)生的。解決方法：1）將字典管理的表空間改為本地管理模式2）預(yù)先分配分區(qū)或者將有問題的字典管理的表空間的nextextent設(shè)置大一些。HWEnqueue是用于segment的HWM的。當(dāng)出現(xiàn)這種等待的時候，可以通過手工分配extents來解決。TX4Enqueue等待是最常見的等待情況。通常有3種情況會造成這種類型的等待：1）唯一索引中的重復(fù)索引。解決方法：commit或者rollback以釋放隊列。2）對同一個位圖索引段（bitmapindexfragment）有多個update，因為一個bitmapindexfragment可能包含了多個rowid，所以當(dāng)多個用戶更新時，可能一個用戶會鎖定該段，從而造成等待。解決方法同上。3）有多個用戶同時對一個數(shù)據(jù)塊作update，當(dāng)然這些DML操作可能是針對這個數(shù)據(jù)塊的不同的行，如果此時沒有空閑的ITL槽，就會產(chǎn)生一個block-level鎖。解決方法：增大表的initrans值使創(chuàng)建更多的ITL槽；或者增大表的pctfree值，這樣oracle可以根據(jù)需要在pctfree的空間創(chuàng)建更多的ITL槽；使用smallerblocksize，這樣每個塊中包含行就比較少，可以減小沖突發(fā)生的機(jī)會。AWR報告分析--等待事件-隊列.docFreeBuffer釋放緩沖區(qū)：這個等待事件表明系統(tǒng)正在等待內(nèi)存中的可用空間，這說明當(dāng)前Buffer中已經(jīng)沒有Free的內(nèi)存空間。如果應(yīng)用設(shè)計良好，SQL書寫規(guī)范，充分綁定變量，那這種等待可能說明BufferCache設(shè)置的偏小，你可能需要增大DB_CACHE_SIZE。該等待也可能說明DBWR的寫出速度不夠，或者磁盤存在嚴(yán)重的競爭，可以需要考慮增加檢查點(diǎn)、使用更多的DBWR進(jìn)程，或者增加物理磁盤的數(shù)量,分散負(fù)載，平衡IO。Logfilesinglewrite：該事件僅與寫日志文件頭塊相關(guān)，通常發(fā)生在增加新的組成員和增進(jìn)序列號時。頭塊寫單個進(jìn)行，因為頭塊的部分信息是文件號，每個文件不同。更新日志文件頭這個操作在后臺完成，一般很少出現(xiàn)等待，無需太多關(guān)注。logfileparallelwrite：從logbuffer寫redo記錄到redolog文件，主要指常規(guī)寫操作(相對于logfilesync)。如果你的Loggroup存在多個組成員，當(dāng)flushlogbuffer時，寫操作是并行的，這時候此等待事件可能出現(xiàn)。盡管這個寫操作并行處理，直到所有I/O操作完成該寫操作才會完成(如果你的磁盤支持異步IO或者使用IOSLAVE，那么即使只有一個redologfilemember,也有可能出現(xiàn)此等待)。這個參數(shù)和logfilesync時間相比較可以用來衡量logfile的寫入成本。通常稱為同步成本率。改善這個等待的方法是將redologs放到I/O快的盤中，盡量不使用raid5，確保表空間不是處在熱備模式下，確保redolog和data的數(shù)據(jù)文件位于不同的磁盤中。logfilesync：當(dāng)一個用戶提交或回滾數(shù)據(jù)時，LGWR將會話的redo記錄從日志緩沖區(qū)填充到日志文件中，用戶的進(jìn)程必須等待這個填充工作完成。在每次提交時都出現(xiàn)，如果這個等待事件影響到數(shù)據(jù)庫性能，那么就需要修改應(yīng)用程序的提交頻率,為減少這個等待事件，須一次提交更多記錄，或者將重做日志REDOLOG文件訪在不同的物理磁盤上，提高I/O的性能。當(dāng)一個用戶提交或回滾數(shù)據(jù)時，LGWR將會話期的重做由日志緩沖器寫入到重做日志中。日志文件同步過程必須等待這一過程成功完成。為了減少這種等待事件，可以嘗試一次提交更多的記錄(頻繁的提交會帶來更多的系統(tǒng)開銷)。將重做日志置于較快的磁盤上，或者交替使用不同物理磁盤上的重做日志，以降低歸檔對LGWR的影響。對于軟RAID，一般來說不要使用RAID5，RAID5對于頻繁寫入得系統(tǒng)會帶來較大的性能損失，可以考慮使用文件系統(tǒng)直接輸入/輸出，或者使用裸設(shè)備(rawdevice)，這樣可以獲得寫入的性能提高。logbufferspace：日志緩沖區(qū)寫的速度快于LGWR寫REDOFILE的速度,可以增大日志文件大小，增加日志緩沖區(qū)的大小，或者使用更快的磁盤來寫數(shù)據(jù)。當(dāng)你將日志緩沖(logbuffer)產(chǎn)生重做日志的速度比LGWR的寫出速度快，或者是當(dāng)日志切換(logswitch)太慢時，就會發(fā)生這種等待。這個等待出現(xiàn)時，通常表明redologbuffer過小，為解決這個問題，可以考慮增大日志文件的大小，或者增加日志緩沖器的大小。另外一個可能的原因是磁盤I/O存在瓶頸，可以考慮使用寫入速度更快的磁盤。在允許的條件下設(shè)置可以考慮使用裸設(shè)備來存放日志文件，提高寫入效率。在一般的系統(tǒng)中，最低的標(biāo)準(zhǔn)是，不要把日志文件和數(shù)據(jù)文件存放在一起，因為通常日志文件只寫不讀，分離存放可以獲得性能提升。logfileswitch：通常是因為歸檔速度不夠快。表示所有的提交(commit)的請求都需要等待"日志文件切換"的完成。LogfileSwitch主要包含兩個子事件:logfileswitch(archivingneeded)這個等待事件出現(xiàn)時通常是因為日志組循環(huán)寫滿以后，第一個日志歸檔尚未完成，出現(xiàn)該等待。出現(xiàn)該等待，可能表示io存在問題。解決辦法:①可以考慮增大日志文件和增加日志組；②移動歸檔文件到快速磁盤；③調(diào)整log_archive_max_processes。logfileswitch(checkpointincomplete)當(dāng)日志組都寫完以后，LGWR試圖寫第一個logfile，如果這時數(shù)據(jù)庫沒有完成寫出記錄在第一個logfile中的dirty塊時(例如第一個檢查點(diǎn)未完成)，該等待事件出現(xiàn)。該等待事件通常表示你的DBWR寫出速度太慢或者IO存在問題。為解決該問題，你可能需要考慮增加額外的DBWR或者增加你的日志組或日志文件大小，或者也可以考慮增加checkpoint的頻率。DBFileParallelWrite：文件被DBWR并行寫時發(fā)生。解決辦法：改善IO性能。處理此事件時，需要注意dbfileparallelwrite事件只屬于DBWR進(jìn)程。緩慢的DBWR可能影響前臺進(jìn)程。大量的dbfileparallelwrite等待時間很可能是I/O問題引起的。（在確認(rèn)os支持異步io的前提下，你可以在系統(tǒng)中檢查disk_asynch_io參數(shù)，保證為TRUE。可以通過設(shè)置db_writer_processes來提高DBWR進(jìn)程數(shù)量，當(dāng)然前提是不要超過cpu的數(shù)量。）DBWR進(jìn)程執(zhí)行經(jīng)過SGA的所有數(shù)據(jù)庫寫入，當(dāng)開始寫入時，DBWR進(jìn)程編譯一組臟塊（dirtyblock），并且將系統(tǒng)寫入調(diào)用發(fā)布到操作系統(tǒng)。DBWR進(jìn)程查找在各個時間內(nèi)寫入的塊，包括每隔3秒的一次查找，當(dāng)前臺進(jìn)程提交以清除緩沖區(qū)中的內(nèi)容時：在檢查點(diǎn)處查找，當(dāng)滿足_DB_LARGE_DIRTY_QUEUE、_DB_BLOCK_MAX_DIRTY_TARGET和FAST_START_MTTR_TARGET閥值時，等等。雖然用戶會話從來沒有經(jīng)歷過dbfileparallelwrite等待事件，但這并不意味著它們不會受到這種事件的影響。緩慢的DBWR寫入性能可以造成前臺會話在writecompletewaits或freebufferwaits事件上等待。DBWR寫入性能可能受到如下方面的影響：I/O操作的類型（同步或異步）、存儲設(shè)備（裸設(shè)備或成熟的文件系統(tǒng)）、數(shù)據(jù)庫布局和I/O子系統(tǒng)配置。需要查看的關(guān)鍵數(shù)據(jù)庫統(tǒng)計是當(dāng)dbfileparallelwrite、freebufferwaits和writecompletewaits等待事件互相關(guān)聯(lián)時，系統(tǒng)范圍內(nèi)的TIME_WAITED和AVERAGE_WAIT。如果dbfileparallelwrite平均等待時間大于10cs（或者100ms），則通常表明緩慢的I/O吞吐量。可以通過很多方法來改善平均等待時間。主要的方法是使用正確類型的I/O操作。如果數(shù)據(jù)文件位于裸設(shè)備（rawdevice）上，并且平臺支持異步I/O，就應(yīng)該使用異步寫入。但是，如果數(shù)據(jù)庫位于文件系統(tǒng)上，則應(yīng)該使用同步寫入和直接I/O（這是操作系統(tǒng)直接I/O）。除了確保正在使用正確類型的I/O操作，還應(yīng)該檢查你的數(shù)據(jù)庫布局并使用常見的命令監(jiān)控來自操作系統(tǒng)的I/O吞吐量。例如sar-d或iostat-dxnC。當(dāng)dbfileparallelwrite平均等待時間高并且系統(tǒng)繁忙時，用戶會話可能開始在freebufferwaits事件上等待。這是因為DBWR進(jìn)程不能滿足釋放緩沖區(qū)的需求。如果freebufferwaits事件的TIME_WAITED高，則應(yīng)該在高速緩存中增加緩沖區(qū)數(shù)量之前說明DBWRI/O吞吐量的問題。高dbfileparallelwrite平均等待時間的另一個反響是在writecompletewaits等待事件上的高TIME_WAITED。前臺進(jìn)程不允許修改正在傳輸?shù)酱疟P的塊。換句話說，也就是位于DBWR批量寫入中的塊。前臺的會話在writecompletewaits等待事件上等待。因此，writecompletewaits事件的出現(xiàn)，一定標(biāo)志著緩慢的DBWR進(jìn)程，可以通過改進(jìn)DBWRI/O吞吐量修正這種延遲。DBFileSingleWrite：當(dāng)文件頭或別的單獨(dú)塊被寫入時發(fā)生，這一等待直到所有的I/O調(diào)用完成。解決辦法：改善IO性能。DBFILEScatteredRead：當(dāng)掃描整個段來根據(jù)初始化參數(shù)db_file_multiblock_read_count讀取多個塊時發(fā)生，因為數(shù)據(jù)可能分散在不同的部分，這與分條或分段）相關(guān)，因此通常需要多個分散的讀來讀取所有的數(shù)據(jù)。等待時間是完成所有I/O調(diào)用的時間。解決辦法：改善IO性能。這種情況通常顯示與全表掃描相關(guān)的等待。當(dāng)數(shù)據(jù)庫進(jìn)行全表掃時，基于性能的考慮，數(shù)據(jù)會分散(scattered)讀入BufferCache。如果這個等待事件比較顯著，可能說明對于某些全表掃描的表，沒有創(chuàng)建索引或者沒有創(chuàng)建合適的索引，我們可能需要檢查這些數(shù)據(jù)表已確定是否進(jìn)行了正確的設(shè)置。然而這個等待事件不一定意味著性能低下，在某些條件下Oracle會主動使用全表掃描來替換索引掃描以提高性能，這和訪問的數(shù)據(jù)量有關(guān)，在CBO下Oracle會進(jìn)行更為智能的選擇，在RBO下Oracle更傾向于使用索引。因為全表掃描被置于LRU（LeastRecentlyUsed，最近最少適用）列表的冷端（coldend），對于頻繁訪問的較小的數(shù)據(jù)表，可以選擇把他們Cache到內(nèi)存中，以避免反復(fù)讀取。當(dāng)這個等待事件比較顯著時，可以結(jié)合v$session_longops動態(tài)性能視圖來進(jìn)行診斷，該視圖中記錄了長時間（運(yùn)行時間超過6秒的）運(yùn)行的事物，可能很多是全表掃描操作（不管怎樣，這部分信息都是值得我們注意的）。DBFILESequentialRead：當(dāng)前臺進(jìn)程對數(shù)據(jù)文件進(jìn)行常規(guī)讀時發(fā)生，包括索引查找和別的非整段掃描以及數(shù)據(jù)文件塊丟棄等待。等待時間是完成所有I/O調(diào)用的時間。解決辦法：改善IO性能。如果這個等待事件比較顯著，可能表示在多表連接中，表的連接順序存在問題，沒有正確地使用驅(qū)動表；或者可能索引的使用存在問題，并非索引總是最好的選擇。在大多數(shù)情況下，通過索引可以更為快速地獲取記錄，所以對于編碼規(guī)范、調(diào)整良好的數(shù)據(jù)庫，這個等待事件很大通常是正常的。有時候這個等待過高和存儲分布不連續(xù)、連續(xù)數(shù)據(jù)塊中部分被緩存有關(guān)，特別對于DML頻繁的數(shù)據(jù)表，數(shù)據(jù)以及存儲空間的不連續(xù)可能導(dǎo)致過量的單塊讀，定期的數(shù)據(jù)整理和空間回收有時候是必須的。需要注意在很多情況下，使用索引并不是最佳的選擇，比如讀取較大表中大量的數(shù)據(jù)，全表掃描可能會明顯快于索引掃描，所以在開發(fā)中就應(yīng)該注意，對于這樣的查詢應(yīng)該進(jìn)行避免使用索引掃描。DirectPathRead：一般直接路徑讀取是指將數(shù)據(jù)塊直接讀入PGA中。一般用于排序、并行查詢和readahead操作。這個等待可能是由于I/O造成的。使用異步I/O模式或者限制排序在磁盤上，可能會降低這里的等待時間。與直接讀取相關(guān)聯(lián)的等待事件。當(dāng)ORACLE將數(shù)據(jù)塊直接讀入會話的PGA（進(jìn)程全局區(qū)）中，同時繞過SGA（系統(tǒng)全局區(qū)）。PGA中的數(shù)據(jù)并不和其他的會話共享。即表明，讀入的這部分?jǐn)?shù)據(jù)該會話獨(dú)自使用，不放于共享的SGA中。在排序操作(orderby/groupby/union/distinct/rollup/合并連接)時，由于PGA中的SORT_AREA_SIZE空間不足，造成需要使用臨時表空間來保存中間結(jié)果，當(dāng)從臨時表空間讀入排序結(jié)果時，產(chǎn)生directpathread等待事件。使用HASH連接的SQL語句，將不適合位于內(nèi)存中的散列分區(qū)刷新到臨時表空間中。為了查明匹配SQL謂詞的行，臨時表空間中的散列分區(qū)被讀回到內(nèi)存中(目的是為了查明匹配SQL謂詞的行)，ORALCE會話在directpathread等待事件上等待。使用并行掃描的SQL語句也會影響系統(tǒng)范圍的directpathread等待事件。在并行執(zhí)行過程中，directpathread等待事件與從屬查詢有關(guān)，而與父查詢無關(guān)，運(yùn)行父查詢的會話基本上會在PXDeq:ExecuteReply上等待，從屬查詢會產(chǎn)生directpathread等待事件。直接讀取可能按照同步或異步的方式執(zhí)行，取決于平臺和初始化參數(shù)disk_asynch_io參數(shù)的值。使用異步I/O時，系統(tǒng)范圍的等待的事件的統(tǒng)計可能不準(zhǔn)確，會造成誤導(dǎo)作用。17)directpathwrite：直接路徑寫該等待發(fā)生在，系統(tǒng)等待確認(rèn)所有未完成的異步I/O都已寫入磁盤。對于這一寫入等待，我們應(yīng)該找到I/O操作最為頻繁的數(shù)據(jù)文件(如果有過多的排序操作，很有可能就是臨時文件)，分散負(fù)載，加快其寫入操作。如果系統(tǒng)存在過多的磁盤排序，會導(dǎo)致臨時表空間操作頻繁，對于這種情況，可以考慮使用Local管理表空間，分成多個小文件，寫入不同磁盤或者裸設(shè)備。在DSS系統(tǒng)中，存在大量的directpathread是很正常的，但是在OLTP系統(tǒng)中，通常顯著的直接路徑讀（directpathread）都意味著系統(tǒng)應(yīng)用存在問題，從而導(dǎo)致大量的磁盤排序讀取操作。直接路徑寫（directpahtwrite）通常發(fā)生在Oracle直接從PGA寫數(shù)據(jù)到數(shù)據(jù)文件或臨時文件，這個寫操作可以繞過SGA。這類寫入操作通常在以下情況被使用：·直接路徑加載；·并行DML操作；·磁盤排序；·對未緩存的“LOB”段的寫入，隨后會記錄為directpathwrite(lob)等待。最為常見的直接路徑寫，多數(shù)因為磁盤排序?qū)е?。對于這一寫入等待，我們應(yīng)該找到I/O操作最為頻繁的數(shù)據(jù)文件（如果有過多的排序操作，很有可能就是臨時文件），分散負(fù)載，加快其寫入操作。18)controlfileparallelwrite：當(dāng)server進(jìn)程更新所有控制文件時，這個事件可能出現(xiàn)。如果等待很短，可以不用考慮。如果等待時間較長，檢查存放控制文件的物理磁盤I/O是否存在瓶頸。多個控制文件是完全相同的拷貝，用于鏡像以提高安全性。對于業(yè)務(wù)系統(tǒng)，多個控制文件應(yīng)該存放在不同的磁盤上，一般來說三個是足夠的，如果只有兩個物理硬盤，那么兩個控制文件也是可以接受的。在同一個磁盤上保存多個控制文件是不具備實際意義的。減少這個等待，可以考慮如下方法:①減少控制文件的個數(shù)(在確保安全的前提下)。②如果系統(tǒng)支持，使用異步IO。③轉(zhuǎn)移控制文件到IO負(fù)擔(dān)輕的物理磁盤。controlfilesequentialreadcontrolfilesinglewrite：控制文件連續(xù)讀/控制文件單個寫對單個控制文件I/O存在問題時，這兩個事件會出現(xiàn)。如果等待比較明顯，檢查單個控制文件，看存放位置是否存在I/O瓶頸。librarycachepin該事件通常是發(fā)生在先有會話在運(yùn)行PL/SQL,VIEW,TYPES等object時,又有另外的會話執(zhí)行重新編譯這些object,即先給對象加上了一個共享鎖,然后又給它加排它鎖,這