深入理解latch: cache buffers chains

事件背景：   
一個客戶的資料庫發生了當機事件，檢視了資料庫的awr報告，原來是由於出現大量的latch: cache buffers chains等待事件導致系統消耗量大量的CPU，最終導致系統hang住；

說明：   
要理解latch: cache buffers chains並解決這個問題，就需要深入的瞭解Buffer Cache及其原理。
1、Buffer Cache概述：   
Buffer Cache是SGA的一部分，Oracle利用Buffer Cache來管理data block，Buffer Cache的最終目的就是儘可能的減少磁碟I/O。Buffer Cache中主要有3大結構用來管理Buffer Cache：Hash Bucket、Hash Chain List、LRU List；   
Hash Bucket & Hash Chain List ：Hash Bucket與Hash Chain List用來實現data block的快速定位。   
LRU List ：掛載有指向具體的free buffer, pinned buffer以及還沒有被移動到 write list的dirty buffer 等資訊。所謂的free buffer就是指沒有包含任何資料的buffer，所謂的pinned buffer，就是指當前正在被訪問的buffer。   
Write(Dirty)List ：掛載有指向具體的 dirty block的資訊。所謂的dirty block，就是指在 buffer cache中被修改過但是還沒有被寫入到磁碟的block。

2、Hash Bucket的原理：   
如果所有的Buffer Cache中所有的Buffer都透過同一個結構管理，當需要確定某個Block在Buffer中是否存在時，將需要遍歷整個結構，效能會相當低下；   
為了提高效率，Oracle引入了Bucket的資料結構，Oracle把管理所有的Buffer透過一個內部的Hash演算法運算後，存放到不同Hash Bucket中，這樣透過Hash Bucket進行分割之後，眾多的Buffer被分佈到一定數量的Bucket之中，當使用者需要在Buffer中定位資料是否存在是，只需要透過同樣的演算法獲得Hash值，然後到相應的Bucket中查詢少量的Buffer即可確定。每個Buffer存放的Bucket由Buffer的資料塊地址運算決定；（這個演算法從ORACLE官方得到的資訊很少，可以用索引的知識去理解）Bucket內部，透過Cache Buffer Chain將所有的Buffer透過Buffer Header資訊聯絡起來； 
為了保護Bucket中的資料，每次訪問的時候都需要先在記憶體中獲取latches後才能訪問，整個訪問的結構如圖： 
使用者記憶體中讀資料的順序：
a) 對該Block運用Hash演算法，得到Hash值。
b）獲得獲得cache buffers chains latch

c) 到相應的Hash Bucket中搜尋相應Buffer Header
b）獲得cache buffers chains latch；
d) 如果找到相應的Buffer Header，然後判斷該Buffer的狀態，看是否需要構造CR Block，或者Buffer處於pin的狀態，最後讀取。e) 如果找不到，就從磁碟讀入到Buffer Cache中。

3、latch:cache buffers chains等待事件     
在Oracle9i以前，如果其它使用者程式已經獲得了這個latch，那麼新的程式就必須等待，直到該使用者程式搜尋完畢(搜尋完畢之後就會釋放該latch)。從Oracle9i開始 cache buffers chains latch可以只讀共享，也就是說使用者程式A以只讀(select)的方式訪問Block，這個時候獲得了該latch，同時使用者程式B也以只讀的方式訪問Block，那麼這個時候由於是隻讀的訪問，使用者程式B也可以獲得該latch。但是，如果使用者程式B要以獨佔的方式訪問Block，那麼使用者程式B就會等待使用者程式A釋放該latch，這個時候Oracle就會對使用者程式B標記一個latch:cache buffers chains的等待事件。

4、latch:cache buffers chains出現的原因   
4.1 不夠最佳化的SQL。   
大量邏輯讀的SQL語句就有可能產生非常嚴重的latch:cache buffers chains等待，因為每次要訪問一個block，就需要獲得該latch，由於有大量的邏輯讀，那麼就增加了latch:cache buffers chains爭用的機率。   對於正在執行的SQL語句，產生非常嚴重的latch:cache buffers chains爭用，可以利用下面SQL檢視執行計劃，並設法最佳化SQL語句。
select * from table(dbms_xplan.display_cursor('sql_id',sql_child_number));   
如果SQL已經執行完畢，我們就看AWR報表裡面的SQL Statistics->SQL ordered by Gets->Gets per Exec，試圖最佳化這些SQL。

4.2熱點塊爭用  
 1）查詢資料庫是否存在latch的爭用
select sid,event,p1text,p1raw from v$session_wait where event='latch: cache buffers chains';   

2)下面查詢查出Top 5 的爭用的latch address。
select * from( select CHILD#,ADDR,GETS ,MISSES,SLEEPS from v$latch_children where name = 'cache buffers chains' and misses>0 and sleeps>0 order by 5 desc, 1, 2, 3) where rownum<6; 

3)然後利用下面查詢找出Hot block。    
 select /*+ RULE */       e.owner ||'.'|| e.segment_name  segment_name,       e.extent_id  extent#,       x.dbablk - e.block_id + 1  block#,       x.tch, /* sometimes tch=0,we need to see tim */x.tim ,l.child#     from       v$latch_children  l,       x$bh  x,       dba_extents  e     where       x.hladdr  = '&ADDR' and       e.file_id = x.file# and       x.hladdr = l.addr and       x.dbablk between e.block_id and e.block_id + e.blocks -1     order by x.tch desc ;       e.owner ||'.'|| e.segment_name  segment_name,       e.extent_id  extent#,       x.dbablk - e.block_id + 1  block#,       x.tch, /* sometimes tch=0,we need to see tim */x.tim ,l.child#     from       v$latch_children  l,       x$bh  x,       dba_extents  e     where       x.hladdr  = '&ADDR' and       e.file_id = x.file# and       x.hladdr = l.addr and       x.dbablk between e.block_id and e.block_id + e.blocks -1     order by x.tch desc ; 

4.3 Hash Bucket太少   需要更改_db_block_hash_buckets隱含引數。其實在Oracle9i之後，我們基本上不會遇到這個問題了，除非遇到Bug。所以這個是不推薦的，記住，在對Oracle的隱含引數做修改之前一定要諮詢Oracle Support。 

5、latch:cache buffers chains的模擬測試
5.1 建立表
SQL> create table john (no int,object_name varchar2(50)); 

5.2  插入資料S
QL> declare i int;beginfor i in 1..5 loopinsert into john  select  rownum as no,object_name from dba_objects;end loop;end;/ 

5.3 建立儲存過程SQL> create or replace procedure p_john isi int;icount int;beginfor i in 1..1000 loopselect count(*) into icount from john;end loop;end;/ 

5.4 模擬20併發全表掃描
SQL> var job_no number;S
QL> beginfor idx in 1..20 loopdbms_job.submit(:job_no,'p_john;');commit;end loop ;end;/ 

5.5檢視爭用情況
SQL> select sid,event,p1text,p1raw from v$session_wait where event='latch: cache buffers chains';
顯示存大量的latch等待；

 5.6  latch: cache buffers chains等待事件在awr報告中的特徵  

 

 

總結以上的特徵：
a)  佔用大量的CPU資源；
b)  邏輯讀比正常情況要多很多；
c)  等待事件裡面肯定有latch: cache buffers chains
d)  Latch的命中率一般在95%以下，嚴重的在90%以下；

6、latch:cache buffers chains的個人解決方法很多時候應用的問題，其實是由於SQL質量導致的，很多DBA吐槽：DBA和開發是不同的部門，所以要讓開發配合起來進行SQL調優難度較大，可行性較小。對於這種觀點本人表示不贊同：當系統出現大的問題的時候，會導致系統效能下降，甚至當機，那麼如果這個系統重要的話，那麼DBA完全可以把問題的原因及解決方法傳送給開發人員，並抄送公司領導，並說明原因及解決的方法，由於這個時候DBA是唯一知道問題的根源及解決方法的，所以領導也會支援你的；另外：SQL調優是最有效的調優方法，建議DBA別從系統的角度去進行處理，避免填了一個坑又冒出一個坑；

 

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

本文作者：JOHN

ORACLE技術部落格：ORACLE 獵人筆記               資料庫技術群：367875324 （請備註ORACLE管理 ）  

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++