ORACLE性能AWR報(bào)告的使用和分析

ORACLEAWR報(bào)告的使用和分析為滿足業(yè)務(wù)的運(yùn)行要求，高性能要求是目前IT系統(tǒng)普遍面臨的最麻煩問題，尤其是客戶面對著數(shù)據(jù)庫方向又是其中的重要一環(huán)，本文將針對ORACLE中常用的性能診斷工具AWR報(bào)告，進(jìn)展分析說明。一、ORACLEORACLE9iStatspack10gORACLE建議越來越自動(dòng)化，不過能夠生疏并把握ORACLE的相關(guān)性能診斷工具的使用，仍對性能問題的ORACLE動(dòng)態(tài)性能視圖動(dòng)態(tài)性能視圖是ORACLE中最常用，也是最簡潔的一種工具。無論何種性能問題，都能在10gv$sessionv$session_waitv$processv$sqlv$lockv$latchv$sysstatv$system_event、v$sgastat。Statspackstatspack是Oracle9i之前使用的一個(gè)數(shù)據(jù)庫收集工具，收集了數(shù)據(jù)庫全面信息，包括負(fù)載概覽、前五個(gè)等待大事、高速緩存的大小、共享池中SQLI/O、庫高速緩存、SGAAWRADDMAWR是10g以后供給的一個(gè)工具，Oracle建議用戶用這個(gè)取代Statspack，它采集與ADDM〔自動(dòng)數(shù)據(jù)庫診斷監(jiān)控〕報(bào)告，為用戶供給數(shù)據(jù)庫性能診斷分析建議。SQLSQLORACLESQLSQL二、生成AWR以下，本文將針對oracle10gAWR，依此來描述和分析數(shù)據(jù)庫的性能點(diǎn)和優(yōu)化建議。AWR由ORACLE自動(dòng)產(chǎn)生，默認(rèn)30分鐘采集一次，保存5天的記錄。但是也可以通過DBMS_WORKLOAD_REPOSITORYawrrpt.sqlawrrpti.sqlAWR$ORACLE_HOME/rdbms/adminHTMLAWRsqlplussys/sys@/scmisassysdbasqlplussys/sys@/scmisassysdbaSQL>@c:/oracle/product/10.2.4/db_1/RDBMS/ADMIN/awrrpt.sqlreport_type的值:html〔注：確定報(bào)告的格式〕輸入num_days的值:1〔注：選擇快照的天數(shù)〕輸入begin_snap的值:425〔注：起始快照〕輸入end_snap的值:427 〔注：完畢快照〕輸入report_name的值:d:\scmis-awr-2011-10-29.html 〔注：報(bào)告生成的名稱和位置〕三、AWRAWR報(bào)告頭記錄了數(shù)據(jù)庫名稱和起始快照時(shí)間，報(bào)告頭中主要分析Elapsed〔總時(shí)間〕和DBTime〔DB〕，DBTime/Elapsed比值較大，說明數(shù)據(jù)庫系統(tǒng)壓力較大，例如以下圖中系統(tǒng)包括16CPU(2*8核)，每個(gè)cpu耗時(shí)26.7min，負(fù)載為26.7/60.03=44.5%，說明數(shù)據(jù)庫效勞器存在較大的負(fù)荷?！睺op5TimedEvents 狀況。緩存尺寸〔CacheSizes〕BufferCacheSGASharedPoolSize，SGA是ORACLESGASharedpool〔librarycache〕和數(shù)據(jù)字典緩存〔dictionarycache〕。Librarycache存放了最近執(zhí)行的SQL則存放了在執(zhí)行SQLSQL負(fù)載性能〔LoadProfile〕Logons1~2Hardparses大于每秒100，SQL代碼中排序操作，或調(diào)整排序空間。數(shù)據(jù)庫效率〔InstanceEfficiencyPercentages〕Oracle最重要指標(biāo)的命中率。緩沖區(qū)未等待率(buffernowait%)：指在緩沖區(qū)中獵取buffer100buffercache。redo(redonowait%)：指在redobuffer10021〕onlineredolog沒有足夠的空間；2〕log緩沖區(qū)命中率(bufferhit%)：指數(shù)據(jù)塊在數(shù)據(jù)緩沖區(qū)中的命中率。該指標(biāo)的值通常應(yīng)在cache內(nèi)存排序率(in-memorysort%)：指排序操作在內(nèi)存中進(jìn)展的比率。該指標(biāo)的值應(yīng)接近100%，假設(shè)指標(biāo)的值較低，則表示消滅了大量排序時(shí)的磁盤i/o操作，可考慮加大sort_area_sizecursor_sharing軟解析的百分比(softparse%oraclesql95sql閂鎖命中率(latchhit%latchlatch應(yīng)接近100%，假設(shè)低于99%，需要分析閂鎖競爭，明確是應(yīng)用鎖、數(shù)據(jù)字典鎖、內(nèi)存掌握鎖的哪一種。通過進(jìn)一步分析LatchStatistics章節(jié)或動(dòng)態(tài)性能視圖v$session_wait,v$latch,v$latch_children。sql(executetoparse%)：指sqlsession_cached_cursors共享池統(tǒng)計(jì)〔SharedPoolStatistics〕記錄了在采集點(diǎn)時(shí)刻，共享池〔 sharepool〕內(nèi)存被使用的比例。這個(gè)指標(biāo)的值應(yīng)保持在共享池外部的組件老化，假設(shè)sql語句被再次執(zhí)行，則就會(huì)發(fā)生硬分析。其中執(zhí)行次數(shù)大于1的sql比率〔SQLwithexecutions>1〕，假設(shè)此值太小，說明需要在應(yīng)用中更多使用綁定變量，避開過多SQL解析。TOP5大事〔Top5TimedEvents 〕這個(gè)局部也是AWR報(bào)告中格外重要的局部，從這里可以看出等待時(shí)間在前五位的是什么大事，根本上就可以推斷出性能瓶頸在什么地方。通常，在沒有問題的數(shù)據(jù)庫中，CPUtime總是列在第一個(gè)，其他幾類重要影響性能的大事分析如下。緩沖區(qū)忙(bufferbusy)：當(dāng)一個(gè)會(huì)話想要訪問緩存中的某個(gè)塊，而這個(gè)塊正在被其它會(huì)話使用時(shí)，將會(huì)產(chǎn)生該等待大事。這時(shí)候，其它會(huì)話可能正在從數(shù)據(jù)文件向緩存中的這這個(gè)等待大事比較顯著，則需要依據(jù)等待大事發(fā)生在緩存中的哪一塊〔如字段頭部、回退段頭部塊、回退段非頭部塊、數(shù)據(jù)塊、索引塊等〕，實(shí)行相應(yīng)的優(yōu)化方法。文件分散讀取(dbfilescatteredread是被放入內(nèi)存中進(jìn)展的進(jìn)展的，通常狀況下它不行能被放入連續(xù)的緩沖區(qū)中，所以就散布在緩沖區(qū)的緩存中。假設(shè)這個(gè)等待大事比較顯著，可能說明對于某些全表掃描的表，沒有創(chuàng)立索引或沒有創(chuàng)立適宜的索引。盡管在特定條件下執(zhí)行全表掃描可能比索引掃描更有效，但假設(shè)消滅這種等待時(shí)，最好檢查一下這些全表掃描是否必要。文件挨次讀取(dbfilesequentialread)：該等待大事通常與單個(gè)數(shù)據(jù)塊相關(guān)的讀取操作有關(guān)。假設(shè)這個(gè)等待大事比較顯著，可能表示在多表連接中，表的連接挨次存在問題，或者可能不適宜地使用了索引。對于大量事務(wù)處理、調(diào)整良好的系統(tǒng)，這一數(shù)值大多是很正常的，但在某些狀況下，它可能示意著系統(tǒng)中存在問題。應(yīng)檢查索引掃描，以保證每個(gè)掃描都是必要的，并檢查多表連接的連接挨次。另外db_cache_size?也是這些等待消滅頻率的打算因素。隊(duì)列(enqueue)：隊(duì)列是一種保護(hù)共享資源的鎖定機(jī)制。該鎖定機(jī)制保護(hù)共享資源，如enqueueenqueue保護(hù)系統(tǒng)全局區(qū)域(sga)中共享內(nèi)存構(gòu)造。該等待大事意味著進(jìn)程正在等待其他進(jìn)程已持latchlatch1〕sharepoollatcholtplatch2〕librarycachelatch：同樣的sqllatch日志文件同步(logfilesync)：這個(gè)等待大事是指當(dāng)一個(gè)會(huì)話完成一個(gè)事務(wù)〔提交或者回滾數(shù)據(jù)〕lgwrredocommitlgwr一次寫日志的時(shí)間太長〔logiosize太大〕，可調(diào)整_log_io_size。SQL〔SQLStatistics〕SQLSQLorderedbyElapsedTimeSQL，記錄的是監(jiān)控范圍內(nèi)CPU〔CPUTime〔Executions〕SQLSQLSQLorderedbyCPUTime CPUSQLCPUSQL。SQLorderedbyGetsbuffergets(規(guī)律IOSQL，查找總的緩沖區(qū)獵取比較高的SQL，并依據(jù)平均每次執(zhí)行緩沖區(qū)獵取的數(shù)量推斷優(yōu)化的余地有多大。SQLCPUSQLorderedbyReadsIO)SQL，查找總的物理讀比較高的SQL，并依據(jù)平均每次執(zhí)行物理讀的數(shù)量推斷優(yōu)化的余地有多大。優(yōu)化這些SQLI/OCPUSQLordere