[[204528]]

對(duì)于數(shù)據(jù)庫(kù)整體的性能問(wèn)題，AWR的報(bào)告是一個(gè)非常有用的診斷工具。

一般來(lái)說(shuō)，當(dāng)檢測(cè)到性能問(wèn)題時(shí)，我們會(huì)收集覆蓋了發(fā)生問(wèn)題的時(shí)間段的AWR報(bào)告-但是***只收集覆蓋1個(gè)小時(shí)時(shí)間段的AWR報(bào)告-如果時(shí)間過(guò)長(zhǎng)，那么AWR報(bào)告就不能很好的反映出問(wèn)題所在。

還應(yīng)該收集一份沒(méi)有性能問(wèn)題的時(shí)間段的AWR報(bào)告，作為一個(gè)參照物來(lái)對(duì)比有問(wèn)題的時(shí)間段的AWR報(bào)告。這兩個(gè)AWR報(bào)告的時(shí)間段應(yīng)該是一致的，比如都是半個(gè)小時(shí)的，或者都是一個(gè)小時(shí)的。[[204529]] 

Interpretation

在處理性能問(wèn)題時(shí)，我們最關(guān)注的是數(shù)據(jù)庫(kù)正在等待什么。

當(dāng)進(jìn)程因?yàn)槟承┰虿荒苓M(jìn)行操作時(shí)，它需要等待。花費(fèi)時(shí)間最多的等待事件是我們最需要關(guān)注的，因?yàn)榻档退?，我們能夠獲得***的好處。

AWR報(bào)告中的"Top 5 Timed Events"部分就提供了這樣的信息，可以讓我們只關(guān)注主要的問(wèn)題。

Top 5 Timed Events

正如前面提到的，"Top 5 Timed Events"是AWR報(bào)告中最重要的部分。它指出了數(shù)據(jù)庫(kù)的sessions花費(fèi)時(shí)間最多的等待事件，如下：

Top 5 Events部分包含了一些跟Events(事件)相關(guān)的信息。它記錄了這期間遇到的等待的總次數(shù)，等待所花費(fèi)的總時(shí)間，每次等待的平均時(shí)間;這一部分是按照每個(gè)Event占總體call time的百分比來(lái)進(jìn)行排序的。

根據(jù)Top 5 Events部分的信息的不同，接下來(lái)我們需要檢查AWR報(bào)告的其他部分，來(lái)驗(yàn)證發(fā)現(xiàn)的問(wèn)題或者做定量分析。等待事件需要根據(jù)報(bào)告期的持續(xù)時(shí)間和當(dāng)時(shí)數(shù)據(jù) 庫(kù)中的并發(fā)用戶數(shù)進(jìn)行評(píng)估。如：10分鐘內(nèi)1000萬(wàn)次的等待事件比10個(gè)小時(shí)內(nèi)的1000萬(wàn)等待更有問(wèn)題;10個(gè)用戶引起的1000萬(wàn)次的等待事件比 10,000個(gè)用戶引起的相同的等待要更有問(wèn)題。

就像上面的例子，將近60%的時(shí)間是在等待IO相關(guān)的事件。

• 事件"db file scattered read"一般表明正在做由全表掃描或者index fast full scan引起的多塊讀。
• 事件"db file sequential read"一般是由不能做多塊讀的操作引起的單塊讀(如讀索引)

其他20%的時(shí)間是花在使用或等待CPU time上。過(guò)高的CPU使用經(jīng)常是性能不佳的SQL引起的(或者這些SQL有可能用更少的資源完成同樣的操作);對(duì)于這樣的SQL，過(guò)多的IO操作也是一個(gè)癥狀。關(guān)于CPU使用方面，我們會(huì)在之后討論。

在以上基礎(chǔ)上，我們將調(diào)查是否這個(gè)等待事件是有問(wèn)題的。若有問(wèn)題，解決它;若是正常的，檢查下個(gè)等待事件。

過(guò)多的IO相關(guān)的等待一般會(huì)有兩個(gè)主要的原因：

• 數(shù)據(jù)庫(kù)做了太多的讀操作
• 每次的IO讀操作都很慢

Top 5 Events部分的顯示的信息會(huì)幫助我們檢查：

• 是否數(shù)據(jù)庫(kù)做了大量的讀操作：

上面的圖顯示了在這段時(shí)間里兩類讀操作都分別大于1000萬(wàn)，這些操作是否過(guò)多取決于報(bào)告的時(shí)間是1小時(shí)或1分鐘。我們可以檢查AWR報(bào)告的elapsed time

如果這些讀操作確實(shí)是太多了，接下來(lái)我們需要檢查AWR報(bào)告中 SQL Statistics 部分的信息，因?yàn)樽x操作都是由SQL語(yǔ)句發(fā)起的。

• 是否是每次的IO讀操作都很慢：

上面的圖顯示了在這段時(shí)間里兩類讀操作平均的等待時(shí)間是小于8ms的

至于8ms是快還是慢取決于底層的硬件設(shè)備;一般來(lái)講小于20ms的都可以認(rèn)為是可以接受的。

我們還可以在AWR報(bào)告"Tablespace IO Stats"部分得到更詳細(xì)的信息

如上圖，我們關(guān)心Av Rd(ms)的指標(biāo)。如果它高于20ms并且同時(shí)有很多讀操作的，我們可能要開(kāi)始從OS的角度調(diào)查是否有潛在的IO問(wèn)題。

• 雖 然高"db file scattered read"和"db file sequential read"等待可以是I / O相關(guān)的問(wèn)題，但是很多時(shí)候這些等待也可能是正常的;實(shí)際上，對(duì)一個(gè)已經(jīng)性能很好的數(shù)據(jù)庫(kù)系統(tǒng)，這些等待事件往往在top 5等待事件里，因?yàn)檫@意味著您的數(shù)據(jù)庫(kù)沒(méi)有那些真正的“問(wèn)題”。

訣竅是能夠評(píng)估引起這些等待的語(yǔ)句是否使用了***的訪問(wèn)路徑。如果"db file scattered read"比較高，那么相關(guān)的SQL語(yǔ)句可能使用了全表掃描而沒(méi)有使用索引(也許是沒(méi)有創(chuàng)建索引，也許是沒(méi)有合適的索引);相應(yīng)的，如果"db file sequential read"過(guò)多，則表明也許是這些SQL語(yǔ)句使用了selectivity不高的索引從而導(dǎo)致訪問(wèn)了過(guò)多不必要的索引塊或者使用了錯(cuò)誤的索引。這些等待可 能說(shuō)明SQL語(yǔ)句的執(zhí)行計(jì)劃不是***的。

接下來(lái)就需要通過(guò)AWR來(lái)檢查這些top SQL是否可以進(jìn)一步的調(diào)優(yōu)，我們可以查看AWR報(bào)告中 SQL Statistics 的部分.

上面的例子顯示了20%的時(shí)間花在了等待或者使用CPU上，我們也需要檢查 SQL statistics 部分來(lái)進(jìn)一步的分析。

需要注意，接下來(lái)的分析步驟取決于我們?cè)赥OP 5部分的發(fā)現(xiàn)。在上面的例子里，3個(gè)top wait event表明問(wèn)題可能與SQL語(yǔ)句執(zhí)行計(jì)劃不好有關(guān)，所以接下來(lái)我們要去分析"SQL Statistics"部分。

同樣的，因?yàn)槲覀儾](méi)有看到latch相關(guān)的等待，latch在我們這個(gè)例子里并沒(méi)有引發(fā)嚴(yán)重的性能問(wèn)題;那么我們接下來(lái)就完全不需要分析latch相關(guān)的信息。

一般來(lái)講，如果數(shù)據(jù)庫(kù)性能很慢，TOP 5等待事件里"CPU"， "db file sequential read" 和"db file scattered read" 比較明顯(不管它們之間的順序如何)，我們總是需要檢查Top SQL (by logical and physical reads)部分;調(diào)用SQL Tuning Advisor或者手工調(diào)優(yōu)這些SQL來(lái)確保它們是有效率的運(yùn)行。

SQL Statistics

AWR包含了一些不同的SQL統(tǒng)計(jì)值：

根據(jù)Top 5 部分的Top Wait Event不同，我們需要檢查不同的SQL statistic。

在我們這個(gè)例子里，Top Wait Event是"db file scattered read"，"db file sequential read"和CPU;我們最需要關(guān)心的是SQL ordered by CPU Time, Gets and Reads。

我們會(huì)從"SQL ordered by gets"入手，因?yàn)橐鸶遙uffer gets的SQL語(yǔ)句一般是需要調(diào)優(yōu)的對(duì)象。

對(duì)這些Top SQL,可以手工調(diào)優(yōu)，也可以調(diào)用SQL Tuning Advisor。

分析：

• -> Total Buffer Gets: 4,745,943,815

假設(shè)這是一個(gè)一個(gè)小時(shí)的AWR報(bào)告，4,745,943,815是一個(gè)很大的值;所以需要進(jìn)一步分析這個(gè)SQL是否使用了***的執(zhí)行計(jì)劃

• Individual Buffer Gets

上面的例子里單個(gè)的SQL的buffer get非常多，最少的那個(gè)都是8億5千萬(wàn)。這三個(gè)SQL指向了兩個(gè)不同的引起過(guò)多buffers的原因：

注意：對(duì)于某些非常繁忙的系統(tǒng)來(lái)講，以上的數(shù)字可能都是正常的。這時(shí)候我們需要把這些數(shù)字跟正常時(shí)段的數(shù)字作對(duì)比，如果沒(méi)有什么太大差別，那么這些SQL并不是引起問(wèn)題的元兇(雖然通過(guò)調(diào)優(yōu)這些SQL我們?nèi)匀豢梢允芤?

# 單次執(zhí)行buffer gets過(guò)多

   SQL_ID為'5t1y1nvmwp2'和'4at7cbx8hnz'的SQL語(yǔ)句總共被執(zhí)行了168次，但是每次執(zhí)行引起的buffer gets超過(guò)500萬(wàn)。這兩個(gè)SQL應(yīng)該是主要的需要調(diào)優(yōu)的候選者。

# 執(zhí)行次數(shù)過(guò)多

   SQL_ID 'grr4mg7ms81' 每次執(zhí)行只是引起16次buffer gets,減少這條SQL每次執(zhí)行的buffer get可能并不能顯著減少總共的buffer gets。這條語(yǔ)句的問(wèn)題是它執(zhí)行的太頻繁了，6500萬(wàn)次。

   改變這條SQL的執(zhí)行次數(shù)可能會(huì)更有意義。這個(gè)SQL看起來(lái)是在一個(gè)循環(huán)里面被調(diào)用，如果可以讓它一次處理的數(shù)據(jù)更多也許可以減少它執(zhí)行的次數(shù)。