愛華網(wǎng)在數(shù)據(jù)為日常維護(hù)過程中，出現(xiàn)性能問題我們通常會(huì)取數(shù)據(jù)庫的AWR報(bào)告進(jìn)行分析，今天在metalink上看到AWR學(xué)習(xí)專題，記錄一下自己學(xué)習(xí)過程！
一、如何主動(dòng)避免問題發(fā)生及做好診斷信息的收集
有些問題是無法預(yù)見的，但大部分其它的問題如果及早發(fā)現(xiàn)一些征兆其實(shí)是可以避免的。同時(shí)，如果問題確實(shí)發(fā)生了，那么收集問題發(fā)生時(shí)的信息就非常重要。有關(guān)于如何主動(dòng)避免問題及診斷信息的收集，請(qǐng)參見：
Document 1482811.1 Best Practices: Proactively Avoiding Database and QueryPerformance IssuesDocument 1477599.1 Best Practices Around Data Collection For PerformanceIssues有興趣的朋友可以通過metalink看看，不過今天我們的目的是如何分析AWR報(bào)告，我們繼續(xù)往下看，AWR報(bào)告系統(tǒng)默認(rèn)是一個(gè)小時(shí)收集一次，默認(rèn)保留7天，11g中默認(rèn)保留八天，為了維護(hù)和分析方便，我們?nèi)WR報(bào)告時(shí)最好取一小時(shí)的，同時(shí)收集正常時(shí)的AWR報(bào)告做成基線，方便以后出問題了進(jìn)行對(duì)比，這樣可以加快分析速度，Toad里面有一個(gè)AWR對(duì)比的功能，有興趣的朋友可以查一下相關(guān)的資料，關(guān)于如何取AWR報(bào)告，詳見：Document 1363422.1 Automatic Workload Repository (AWR) Reports - StartPoint取AWR進(jìn)行分析前最好先看看對(duì)應(yīng)時(shí)段的ADDM報(bào)告，ADDM報(bào)告已經(jīng)針對(duì)該時(shí)段內(nèi)的問題給出了指導(dǎo)建議，幫助比較大，有朋友可能會(huì)說，這樣通過命令取太不方便了，的確如此，但是TOAD可以很方便很容易查看這些報(bào)告，但是查看這些報(bào)告需要較高版本的TOADFOR ORACLE 11G是一個(gè)比較不錯(cuò)的版本二、AWR分析重點(diǎn)關(guān)注事項(xiàng)拿到AWR報(bào)告后第一件事是判斷當(dāng)時(shí)數(shù)據(jù)庫負(fù)載是否很高，判斷方法詳見：http://blog.sina.com.cn/s/blog_61cd89f60102ecsv.html方法很多，不唯一，僅供參考 Top 5Events部分包含了一些跟Events（事件）相關(guān)的信息。它記錄了這期間遇到的等待的總次數(shù)，等待所花費(fèi)的總時(shí)間，每次等待的平均時(shí)間；這一部分是按照每個(gè)Event占總體calltime的百分比來進(jìn)行排序的。根 據(jù)Top 5Events部分的信息的不同，接下來我們需要檢查AWR報(bào)告的其他部分，來驗(yàn)證發(fā)現(xiàn)的問題或者做定量分析。等待事件需要根據(jù)報(bào)告期的持續(xù)時(shí)間和當(dāng)時(shí)數(shù)據(jù)庫中的并發(fā)用戶數(shù)進(jìn)行評(píng)估。如：10分鐘內(nèi)1000萬次的等待事件比10個(gè)小時(shí)內(nèi)的1000萬等待更有問題；10個(gè)用戶引起的1000萬次的等待事件比10,000個(gè)用戶引起的相同的等待要更有問題。三、TOP 5部分Top5Events部分包含了一些跟Events（事件）相關(guān)的信息。它記錄了這期間遇到的等待的總次數(shù)，等待所花費(fèi)的總時(shí)間，每次等待的平均時(shí)間；這一部分是按照每個(gè)Event占總體calltime的百分比來進(jìn)行排序的 根據(jù)Top 5Events部分的信息的不同，接下來我們需要檢查AWR報(bào)告的其他部分，來驗(yàn)證發(fā)現(xiàn)的問題或者做定量分析。等待事件需要根據(jù)報(bào)告期的持續(xù)時(shí)間和當(dāng)時(shí)數(shù)據(jù)庫中的并發(fā)用戶數(shù)進(jìn)行評(píng)估。如：10分鐘內(nèi)1000萬次的等待事件比10個(gè)小時(shí)內(nèi)的1000萬等待更有問題；10個(gè)用戶引起的1000萬次的等待事件比10,000個(gè)用戶引起的相同的等待要更有問題。
就像上面的例子，將近60%的時(shí)間是在等待IO相關(guān)的事件。
其他20%的時(shí)間是花在使用或等待CPUtime上。過高的CPU使用經(jīng)常是性能不佳的SQL引起的（或者這些SQL有可能用更少的資源完成同樣的操作）；對(duì)于這樣的SQL，過多的IO操作也是一個(gè)癥狀。關(guān)于CPU使用方面，我們會(huì)在之后討論。在以上基礎(chǔ)上，我們將調(diào)查是否這個(gè)等待事件是有問題的。若有問題，解決它；若是正常的，檢查下個(gè)等待事件。
過多的IO相關(guān)的等待一般會(huì)有兩個(gè)主要的原因：
Top 5 Events部分的顯示的信息會(huì)幫助我們檢查：
我們還可以在AWR報(bào)告"Tablespace IO Stats"部分得到更詳細(xì)的信息
這部分我們關(guān)注的是AvRd(ms)的指標(biāo)。如果它高于20ms并且同時(shí)有很多讀操作的，我們可能要開始從OS的角度調(diào)查是否有潛在的IO問題。
注：對(duì)于一些比較空閑的tablespace/files,我們可能會(huì)得到一個(gè)比較大的AvRd(ms)值；對(duì)于這樣的情況，我們應(yīng)該忽略這樣的tablespace/files;因?yàn)檫@個(gè)很大的值可能是由于硬盤自旋(spin)引起的，沒有太大的參考意義。比如對(duì)于一個(gè)有1000萬次讀操作而且很慢的系統(tǒng)，引起問題的基本不可能是一個(gè)只有10次read的tablespace/file以下的文檔可以幫助我們進(jìn)一步調(diào)查IO方面的問題：Note:223117.1Troubleshooting I/O-related waits雖然高"db file scattered read"和"dbfile sequentialread"等待可以是I/O相關(guān)的問題，但是很多時(shí)候這些等待也可能是正常的；實(shí)際上，對(duì)一個(gè)已經(jīng)性能很好的數(shù)據(jù)庫系統(tǒng)，這些等待事件往往在top5等待事件里，因?yàn)檫@意味著您的數(shù)據(jù)庫沒有那些真正的“問題”。怎么判斷是否有問題呢？
我們只能能夠評(píng)估引起這些等待的語句是否使用了最優(yōu)的訪問路徑。如果"db file scatteredread"比較高，那么相關(guān)的SQL語句可能使用了全表掃描而沒有使用索引（也許是沒有創(chuàng)建索引，也許是沒有合適的索引）；相應(yīng)的，如果"dbfile sequentialread"過多，則表明也許是這些SQL語句使用了selectivity不高的索引從而導(dǎo)致訪問了過多不必要的索引塊或者使用了錯(cuò)誤的索引。這些等待可能說明SQL語句的執(zhí)行計(jì)劃不是最優(yōu)的，接下來就需要通過AWR來檢查這些topSQL是否可以進(jìn)一步的調(diào)優(yōu)，我們可以查看AWR報(bào)告中 SQLStatistics的部分.
上面的例子顯示了20%的時(shí)間花在了等待或者使用CPU上，我們也需要檢查 SQLstatistics 部分來進(jìn)一步的分析。需要注意，接下來的分析步驟取決于我們在TOP5部分的發(fā)現(xiàn)。在上面的例子里，3個(gè)top wait event表明問題可能與SQL語句執(zhí)行計(jì)劃不好有關(guān)，所以接下來我們要去分析"SQLStatistics"部分。同樣的，因?yàn)槲覀儾]有看到latch相關(guān)的等待，latch在我們這個(gè)例子里并沒有引發(fā)嚴(yán)重的性能問題；那么我們接下來就完全不需要分析latch相關(guān)的信息。一般來講，如果數(shù)據(jù)庫性能很慢，TOP5等待事件里"CPU"， "db file sequential read" 和"db file scattered read"比較明顯（不管它們之間的順序如何），我們總是需要檢查Top SQL (by logical and physicalreads)部分；調(diào)用SQL TuningAdvisor或者手工調(diào)優(yōu)這些SQL來確保它們是有效率的運(yùn)行。
三、SQLStatistics部分AWR包含了一些不同的SQL統(tǒng)計(jì)值：
根據(jù)Top 5 部分的Top Wait Event不同，我們需要檢查不同的SQLstatistic，在我們這個(gè)例子里，Top Wait Event是"db file scattered read"，"db filesequential read"和"CPU"；我們最需要關(guān)心的是SQL orderedby CPU Time, Gets and Reads,我們要從"SQL ordered bygets"入手，因?yàn)橐鸶遙uffer gets的SQL語句一般是需要調(diào)優(yōu)的對(duì)象
對(duì)這些Top SQL,可以手工調(diào)優(yōu)，也可以調(diào)用SQL TuningAdvisor簡稱STA，具體使用方法可以參照：
Document 271196.1 Automatic SQL Tuning - SQL Profiles.
Document 262687.1 How to use the Sql Tuning Advisor.
Document 276103.1 PERFORMANCE TUNING USING ADVISORS ANDMANAGEABILITY FEATURES: AWR, ASH,andADDM and Sql TuningAdvisor.
分析：
Other SQL Statistic Sections
就像之前提到的那樣，AWR報(bào)告中有很多不同的部分用來分析各種不同的問題。如果特定的問題并沒有出現(xiàn)，那么分析AWR報(bào)告的這些部分并不能有很大的幫助，面提到了一些可能的問題：四、Load Profile部分
根據(jù)Top5等待事件的不同，"Load Profile"可以提供一些有用的背景資料或潛在問題的細(xì)節(jié)信息。
在這一部分，我們重點(diǎn)關(guān)注，hard parse的次數(shù)要少于soft parse，如果mutex等待事件比較嚴(yán)重，如"librarycache: mutex X"，那么查看所有parse的比率會(huì)更有用，此時(shí)最有效的方法就是把LoadProfile部分跟正常時(shí)候的AWR報(bào)告做比較會(huì)更有用，比較redo size, users calls, 和parsing
五、Instance Efficiency部分
InstanceEfficiency部分更適用于一般性的調(diào)優(yōu)，而不是解決某個(gè)具體問題（除非等待事件直接指向這些指標(biāo)）。
從我們的這個(gè)例子來看，最有用的信息是99.69%Non-ParseCPU，它表明幾乎所有的CPU都消耗在了Execution而不是Parse上。98.04％ 的soft parse比率顯示hardparse的比例很小，這是可取的。Execute to Parse57.31%很一般，說明cursor沒有被很好的重用了。我們總是期望這里的值都是接近100%,但是因?yàn)閼?yīng)用的不同，如果這個(gè)部分的參數(shù)的某些值很小，也是可以認(rèn)為沒有問題的；如在數(shù)據(jù)倉庫環(huán)境，hardparse因?yàn)槭褂昧宋锘晥D或histogram而變得很高。所以，重要的是，我們需要把這部分信息和正常時(shí)候的AWR報(bào)告做比較來判斷是否有問題。
六、LatchActivity 部分
在我們這個(gè)例子里，我們并沒有看到很高的latch相關(guān)的等待，所以這部分的信息可以忽略，但是如果latch相關(guān)的等待很嚴(yán)重，我們需要查看LatchSleep Breakdown 部分sleeps很高的latch
這里toplatch是cache buffers chains. Cache Buffers Chains latches是用來保護(hù)buffercaches中的buffers。在我們讀取數(shù)據(jù)時(shí)，這個(gè)latch是正常需要獲得的。Sleep的數(shù)字上升代表session在讀取buffers時(shí)開始等待這個(gè)latch。爭用通常來自于不良的SQL要讀取相同的buffers在我們這個(gè)例子里，雖然讀取buffer的操作發(fā)生了10億次，但是只sleep了970次，可以認(rèn)為是比較低的。AvgSlps/Miss（Sleeps/ Misses）也比較低。這表明當(dāng)前Server有能力處理這樣多的數(shù)據(jù)，所以沒有發(fā)生CacheBuffers Chains latch的爭用,關(guān)于其他的latch free等待，請(qǐng)參照以下文檔：
其他潛在的CPU相關(guān)的問題：
八、'Log file sync'waits當(dāng) 一個(gè)user session commit或rollback時(shí)，log writer進(jìn)程會(huì)把redo從logbuffer中寫入redologfile文件，AWR報(bào)告會(huì)幫助我們來確定是否存在這方面的問題，并且確認(rèn)是否是由物理IO引起。如果”log filesync”事件比較嚴(yán)重，下面的文檔詳細(xì)描述了如何來處理:
Document 1376916.1 Troubleshooting: "Log File Sync" Waits
Note:34592.1WAITEVENT: "log file sync"
九、Buffer busywaits
當(dāng)一個(gè)session從buffercache讀取一個(gè)buffer時(shí)，如果這個(gè)buffer處于busy的狀態(tài)（由于其它session正在向其中讀取數(shù)據(jù)，或者是由于這個(gè)buffer被其它的session以不兼容模式持有），那么這個(gè)session就會(huì)等待這個(gè)事件。參照下面文檔來找出哪個(gè)block處于busy狀態(tài)和為什么：
Document 155971.1 Resolving Intense and "Random" Buffer BusyWait Performance
Problems:Note:34405.1WAITEVENT: "buffer busy waits"
九、診斷其他問題
關(guān)于其他性能問題，請(qǐng)參照文檔:
Document 1377446.1 Troubleshooting Performance Issues十、其他的AWR參考文章當(dāng)閱讀AWR報(bào)告的其他部分時(shí)，可以參照下面的一些文檔:
Document 786554.1 How to Read PGA Memory Advisory Section inAWR and Statspack ReportsDocument 754639.1 How to Read Buffer Cache Advisory Section inAWR and Statspack Reports
Document 1301503.1 Troubleshooting: AWR Snapshot Collectionissues
Document 1363422.1 Automatic Workload Repository (AWR) Reports- Start Point 以上只是學(xué)習(xí)AWR的專題的一個(gè)開始，只是一個(gè)簡單的概述，要想完全搞懂AWR還有很長很長的路要走，需要堅(jiān)持多看、多總結(jié)，以后會(huì)有更多的AWR專題，分析不當(dāng)之處還望各位高手批評(píng)指點(diǎn)，謝謝！
