通過AWR報告處理故障一次心得

故障現象
5:00-5:05期間，負載突然上升，隨機查詢程式發現來自192.168.30.69伺服器
 
 
     
5:05-5:10期間，把192.168.130.69應用重啟後，負載在5分鐘之內恢復正常 
 




AWR報告資訊如下
1．併發有增加


2．硬解析很多
 

3．整個15分鐘期間的CPU使用率並不高（因為負載一上來就馬上去關閉應用了，所以負載滿核的時候大概就3分鐘左右，CPU核數16 *4*60=2880秒左右，比DB TIME小一點）


4．兩個SQL的CPU和其他SQL的CPU不是一個數量級的，差距10倍以上（195秒不到2880秒的十分之一） 


5．某表的邏輯讀的佔用位元別突出
 




分析
1． 通過以上AWR的資訊，第一印象就是感覺硬解析引起的大量等待引起的CPU暴漲，查詢下來也確實發現太多沒有繫結變數的SQL，而且還發現邏輯讀高的表UF_KQ_HRANALYZE_DT2沒有繫結變數的SQL就達500多條。自以為找到了原因，通知開發去繫結變數（從DBA的角度看，一般不建議改引數cursor_sharing值，怕引發其他問題）。
2． 誰知第二天負載又開始上來，不過不是5分鐘內暴漲，而是爬升（30分鐘內從30%達到100%狀態），期間資料庫連上去可以抓取耗CPU百分百程式SPID對應的SQL了（昨天暴漲，資料庫都連不上），發現SQL就是昨天AWR報告裡面的那段insert的SQL，細查下來發現insert那段就是share_fordoc儲存過程裡面的一部分。再抓取幾分鐘內的AWR報告（顯示insert居然78分鐘都沒有跑完），AWR報告中TOP SQL和抓取CPU百分百程式SPID對應的SQL一致。就是insert那段SQL慢導致整個儲存過程慢，insert慢要麼是insert的資料量太大或IO太慢，要麼是insert後面的select太慢，具體查下來發現insert後面的select有死迴圈，至此找到原因，通知開發修改程式，徹底搞定。
 
抓取SPID對應的SQL的語句如下
select s.sid,s.serial#,p.spid,s.terminal,s.LOGON_TIME,s.status,s.PROGRAM,s.CLIENT_IDENTIFIER,s.machine,s.action,s.PROCESS "客戶端機器程式號",s.osuser from v$session s,v$process p where  s.paddr=p.addr and p.spid=XX

select username,sid,SERIAL#,LOGON_TIME,status,PROGRAM,CLIENT_IDENTIFIER,machine,action,PROCESS "客戶端機器程式號",osuser,sql_text from v$session a,v$sqltext_with_newlines b

  where DECODE(a.sql_hash_value, 0, prev_hash_value, sql_hash_value)=b.hash_value and a.sid=&sid order by piece;



總結
1． 資料庫出現效能問題，一般都在三個地方，io，記憶體，cpu，這三個又是息息相關的，當io負載增大時，肯定需要更多的記憶體來存放，同時也需要cpu花費更多的時間來過濾這些資料，相反，cpu時間花費多的話，有可能 是解析sql語句，也可能是大量邏輯讀過濾太多的資料，到不一定是和io或記憶體有關係
2． 有的時候等待事件是最好的入手點，但是引發等待事件的原因有很多，遇到突然異常的情況下，最簡單粗暴的方法還是去看TOP SQL，看哪些SQL特別突出
3． 出現異常苗頭時，一定要及時去建立快照，抓取短暫的5分鐘或10分鐘都可以，檢視這幾分鐘內的AWR基本都可以定位到故障。一旦資料庫hang住了，1小時的預設自動建立快照動作都不會執行的，這樣後續故障現象的一手資料都會拿不到
exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/30126024/viewspace-2136914/，如需轉載，請註明出處，否則將追究法律責任。