latch: cache buffers chains---AWR實戰分析

一：等待事件原理

    當一個資料塊讀入SGA區，相應的buffer header會被放置到hash列表上，我們稱其是hash chains,chain在中文的意思是連結串列，表達的就是關連性，如果一個程式想要訪問中修改hash chain上的block，它首先要獲得"cache buffers chains" latch。來張原理圖吧

二：等待事件產生原因

    該等待事件的主要原因通常多個session重複訪問一個或多個資料塊，很大程度上和邏輯讀有關，所以要關注v$sql中buffer_gets/executions很大的語句，因數每一個邏輯讀需要一個latch get操作及一個cpu操作，這樣的sql消耗cpu資源比較嚴重，這也是為什麼說常見的表現是CPU使用率較高的原因，原理清楚了，解決起來就簡單多了。說的再直白一點，基本上可以確定是因為效能較差的SQL引起的！

三：怎麼斷定是"latch: cache buffers chains"等待

    方法並不唯一，最直接有效的方法是取系統異常時間的AWR報告或者ASH報告，從AWR上看，如下圖所示

            

    前面我們說了該等待事件的原理，因此在這理，排在第二、四位的等待事件就好理解了，

    從ASH上看：

            

     也可以從v$session_wait上獲取相關等待資訊 

四、怎麼從AWR上去分析

    對於新手而言，拿到AWR報告會看，也能斷定資料庫是否負載較大，但是怎麼根據等待事件去分析是難點，以本案例例說一下分析方法。

    找到邏輯讀較高的SQL：  
    第一條比較顯眼，但是在實際處理過程中，前三條是都需要分析的，找到對應的SQL，檢視訪問的都是那些表，在我的案例中訪問的表分別是：t_approve_process、t_report_contract、t_report_realtime_item，那麼我們就是從AWR上去找邏輯讀較大的對像，如下圖所示
    
    很顯然，正是這幾個表邏輯讀比較大！好了，原因基本上定位了，下面我們來看看如何去解決

五、怎麼去解決

    首先我們要明確一點，處理資料庫相關問題有些是固定的方法，有些需要綜合考慮分析，因此難點就在這種沒有固定解決方案的問題，下面我們分析一下針對此問題的解決方案

1>. 複查應用程式，確認這些SQL多次重複查詢是否有必要，儘量去減少相關查詢次數，但是，在現實環境中，

    這種情況是最難做的，DBA和開發是不同的部門或公司，配合起來多少有些難度，可行性較小

2>. 檢視相關SQL的執行計劃，然後進行優化，有朋友可能會說了，這也要修改應用程式呀，還是比較麻煩，但

    事實並不是這樣的，我們可以通過DBMS_SQLTUNE包進行優化，不修改應用程式的情況下修改SQL執行計劃，

    這個技術我在前面介紹過：http://blog.sina.com.cn/s/blog_61cd89f60102edi3.html 這只是其中的一種

    方法，僅供參考！(此方法可行性較高)

3.> 首先確定是否是因為熱點塊問題造成的，確定方法詳見參考文件

4.> 增加DBWn程式個數，10g預設是2個程式，show parameter db_writer_process

5.> 建立反向索引

6.> 減小buffer cache

    方法很多，目前為止只用到了2、3兩種方法，其它方法有具體案例再和朋友們分享！

六、參考文件：