昨晚網友發來一份awr報告，希望幫忙分析一下。由於其他信息都沒有，僅僅只有一份awr，鑒於目前有大多的朋友還不太熟悉或者說不知道如何去進行awr的分析。我這里就拿這個awr來進行分析，當拋磚引玉了。首先申請，網上分析awr的文章不少，大家也都可以參考一下。
首先來看awr前面部分信息，了解下系統的版本，以及大概判斷下系統負載如何。
從上面信息我們可以得出如下結論：
—-數據庫是一套11.2.0.2的RAC
—-Solaris 64bit環境，48c
—-每個cpu 的可用處理時間是3591.6 s, 2518.79/(59.86*48)=0.876，說明系統負載還是有些高的，但是連接數卻不多。
從下面的load profile來看，邏輯讀、物理讀都不算太高、軟解析也很低。
下面重點來看下top 5 event：
從top 5 等待來看，絕大多數event表現為IO類的等待，而且平均等待時間都比較高，均超過100ms，最高的為197ms。從這里，我們可以粗略的判斷，系統IO問題較為嚴重，結合top 5來看，主要集中在direct path read等待，關於direct path read，主要表現為如下集中可能的情況：
—–parallel query
—-大量的disk排序
—-table 預讀取操作
這個等待跟direct path write是不同的，direct path write主要表現為直接路徑加載，parallel dml等操作。其次top 5 里的direct path read temp 主要表現為大量的disk temp 排序操作。
這里補充一點的是，在11gR2里面，部分全表掃描操作會被direct path read(簡稱DPR)所替代，當table大小超過5倍_small_table_threshold 大小時，oracle將自動決定是否使用direct path read去替代傳統的全表掃描。另外其實還有一個參數_very_large_object_threshold，當表的大小超過這個參數的0.8倍時，oracle也會自動決定使用使用DPR去代替傳統的全表掃描。下面是我們11gR2版本的關於這2個參數設置和描述：
_small_table_threshold —單位是block,11.2中默認是287.
_very_large_object_threshold —單位是MB，默認是500m
下面我們繼續，由於這是一套rac，所以我們也關注下rac相關的信息，如下：
從上面來看，可以看到rac interconnect 交互比較低的，從buffer access信息來看，從disk中的讀取比例有些高了，為39.07%，這也是前面direct path read/read temp的一個表現。
下面是ges/gcs的具體指標。
這里，我們重點關注receive和send的部分，通常來講小於5ms認為是比較好的，小於20ms都算是可以接受的，這些信息其實沒有一個明確的指標，都是根據經驗來的，白鱔的dba日記中曾經提到過一些具體的指標，不過其中是參考的9i的rac文檔。我從一份oracle internal的rac文檔中找到了如下一些指標：
從這里來看，對於CR block小於5ms 認為是不錯的，上限是10ms左右。而current block
一般在3ms和8ms被認為不錯，當超過20ms則被視為異常或不可能接受了。反過來講，如果這里指比較高，那么top 5 event里面比如會有gc相關的等待。
如果這里看到cr或current block 接受或send有異常，你可以看awr中rac相關的具體細節部分，例如如下部分：
由於這里沒什么問題，所以我就不多說了，繼續分析這個awr。
由於前面我們已經清楚的看到，問題集中在IO上，那么我們就來看看IO方面的細節：
可以看到1小時內，所讀的block達到了1.5T，太大了。其中絕大部分是集中在對datafile的訪問，tmepfile的操作有一些，相對來講算是比較少的了。
這樣來看，問題集中在應用層面了，我們來看看SQL部分。
可以看到，主要是就那幾個parallel query的SQL導致的大量IO，從sql 部分信息，我沒有看到Top SQL with event的信息，所以從這來看，前面單從top 5event中的direct path read懷疑可能是11gR2的特性 當表超過5倍_small_table_threshold 大小而是用direct path read來代替全表掃描是不正確的。從這里來看，就是那幾個parallel query導致的direct path read，而且direct path read temp應該也是這個導致，因為sql包含大量的排序了。
剛剛網友說，他們這個庫目前是每天下午6~7點都會down機，目前已經調整了應用了。我想，問題應該已經解決了，拭目以待了。
最后補充下IO類相關幾個event的一些指標，比如平均等待時間超過多少ms，我們就認為有問題了。
可以參考如下表格：
說明：awr報告中還有很多其他的內容，就不說明了，例如：
例如instance activity statistics，我們可以通過里面的數據去判斷數據中是否有表存在行鏈接或行遷移，再或者看系統回滾率是否正常、一些參數設置是否合理等等。buffer pool statistics和advisory statistics部分信息是從來判斷oracle sga和pga中內存組件設置是否合理的，當然這個僅僅是參考值，而且最好是采集多份awr包括進行綜合分析。后面的undo/latch/dictionary等信息就不多說了，回頭有具體的案例涉及到在進行分析描述。這次就先到這里吧。轉：http://www.killdb.com/2012/08/17/%e4%b8%80%e4%bb%bd11gr2-rac-awr%e6%8a%a5%e5%91%8a%e7%9a%84%e7%ae%80%e5%8d%95%e5%88%86%e6%9e%90.html