白鱔的洞穴
首先我們看故障最嚴重的時段的top event，排在第一位的是row cache objects閂鎖，佔到等待事件的49.1%。實際上上周五群友發出這個awr報告的時候我也簡單的看了一下，排在第一位的row cache objects閂鎖的平均等待時間是5毫秒。row cache objects是sga中管理row cache的閂鎖，主要是用於資料字典的序列化訪問，這個閂鎖在2023年左右做dba的人裡，十分著名，當時因為sga比較小，伺服器效能也較差，因此一旦這個閂鎖出問題，很容易耗盡cpu資源，導致資料庫故障。不過從經驗上看，目前這個閂鎖的平均等待時間並不大，而且其他的共享池相關的等待事件指標都還算不錯，還不足以讓資料庫系統出現特別嚴重的問題。下面我們來看看系統資源的使用情況：
每秒6800k左右的redo，916.8萬的邏輯讀，8900+的執行，408的事務，對這種88個物理核（懷疑是4路至強伺服器，cpu可能是e8 gold 6238t或者e5-2699）的伺服器來說，這點負載不算太高。從命中率看：
library hit比較呆，軟解析比例94.57%有點低，不過還可以接受，從no-parse cpu看，parse消耗了12%左右的cpu，算是比較高了，不過也不是不可以接受的，因為cpu資源本身並不存在瓶頸。所以從這份報告上看，似乎這套系統雖然出現了一些row cache objects閂鎖的爭用，本身並沒有出現十分嚴重的故障。當時也就沒有深入去分析了。昨天下午，這位群友把分析報告發出來後，老白看了一眼報告，感到最終定位為oracle的乙個bug，似乎理由不是很充分。正好這份報告裡的附件十分完整，還包含了awr對比報告，因此就稍微分析了一下相關的資料。同時這份報告寫的十分規範，報告的背景分析裡提到了乙個現象引起了我的注意：
統計分析未正常結束往往是引起一些sql執行計畫錯誤的重要原因。因此馬上對比了平均每秒邏輯讀的指標，在故障期間，大概是900萬+/秒，而正常時段是300萬+，差了3倍。這種情況很可能是sql的執行計畫出現了問題，於是直接跳到top sql buffer gets：
從上面可以看出，存在一些sql，在正常時段沒有出現在top sql中，而這份報告**現了，開銷十分大。而在這份對比報告中，正常時段存在而本報告中不存在的sql比較少。
而從執行時間較長的top sql的對比分析上看，二者執行時間的差異並不大，說明row cache objects雖然對系統有影響，但是對sql的執行時長的影響還不至於引起如此大的效能問題。於是我建議那位朋友，對於存在嚴重效能問題的應用執行的sql，做乙個awrsqlrpt,從而分析一下，是什麼因素導致的效能問題。如果不出意料，這些sql在邏輯讀上，對比正常時段，都有較大的差異，從執行計畫上來看，有可能會存在多個執行計畫，其中乙個是錯誤的（或者只存在乙個錯誤的執行計畫）。因為在故障期間的排名top 3的一條sql裡，我已經從兩份報告中看到了不同的執行開銷：
在問題最嚴重的10分鐘裡，這條sql執行了19次，平均每次的buffer gets超過4000萬，而同一天稍後的乙個40分鐘的awr報告中：
這條sql的buffer gets是104萬期間相差了40倍，這是十分典型的sql執行計畫錯誤的表現。實際上這個案例分析的方法一旦掌握了，再分析類似問題就會比較容易。從這個案例可以看出，有很多種方式都可以去解說某個故障，不過很多種解說中最多隻可能有乙個是正確的，甚至有可能所有的解釋都是錯誤的。而從錯綜複雜的問題表象中抽絲剝繭，找到正確的問題原因，僅僅依靠資料分析是不夠的。因為從資料分析上看那份報告也解釋的通。真正定位問題的關鍵是專家的經驗。以老白二十多年的運維經驗，清楚cursor_sharing/session_cached_cursors這些引數在什麼場景下能發揮作用，清楚row cache objects閂鎖在什麼情況下才能對系統造成致命的影響，因此就會把這條診斷路徑的優先順序設定為較低，因此才能十分精準的找到更加適合的診斷路徑，更容易定位問題。這也是「運維知識自動化」體系建設中的關鍵，除了資料分析，專家經驗或者說知識庫的水平，才真正決定了自動化分析工具的水平。
Oracle資料庫效能分析工具介紹
最近在做乙個效能監控的專案，主要是監控主機和資料庫的基本效能，主機採用jni方式採集，資料通過各種方式進行採集 根據不同的資料庫使用不同的方式 主要以jdbc方式為主其他資料庫分析工具輔助。做專案的過程中對oracle的statspack有一定的了解，這個工具將對各種原因造成的資料庫效能問題做乙個簡...
oracle資料庫效能
效能檢視v 開頭 v system event 正在等待的資源的系統資訊 v session event 會話累計發生的等待事件 v session wait 會話正在等待或者曾經等待的詳細時間資訊 v session 正在等待或者曾經等待的會話資訊 v metricname 檢視快取記憶體命中率 ...
使用AWR報告分析Oracle資料庫效能
awr全稱automatic workload repository，自動負載資訊庫，是oracle 10g版本後推出的一種效能收集和分析工具，提供了乙個時間段內整個系統的報表資料。通過awr報告，可以分析指定的時間段內資料庫系統的效能。awr預設每小時對資料庫記憶體中統計資訊進行取樣一次，並將資訊...