昨晚網友發來乙份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等資訊就不多說了，回頭有具體的案例涉及到在進行分析描述。這次就先到這裡吧。
乙份軟體專案的失敗報告
乙份軟體專案的失敗報告 就像某人說的失敗並不可怕，可怕的是不知道從失敗中吸取教訓。前言一 計畫偏差 如果是設計優秀的軟體，在模組開發上花的時間應該是頁面開發所花時間的n倍 視軟體的大小與複雜度 簡單的給這兩個部分一周時間不太合理。實際的情況也是這樣，到專案結束的時候，很多模組都只完成了基本的部分，即...
乙份b2b系統分析報告
目前的中國網路發展的規模決定了其市場容量和商業機會的有限。中國現有不到600萬的網路人口中，真正具有消費實力並能形成購買力的群體，依然遠不足以與現實生活中的傳統商業模式相匹敵，同時，目前網路人口的結構也決定了只有少數商品可能馬上在網路上銷售。要開展b2b電子商務，主要有以下功能 1 商管理，btob...
國外案例 乙份有趣的營銷投入趨勢報告
2007年，美國marketingprofs公司和forrester research公司聯合做了乙個題為 2008年b2b型企業市場營銷 策略與投入趨勢 的調研 原標題為 b to b marketing in 2008 trends in strategies and spending 在調研取...