客戶說數據庫的CPU使用率為100%，應用相應遲緩。
發現是latch: cache buffers chains 作祟
故障分析思路

查看等待事件，判斷故障起因

1 SQL>select * from (select sid,event,p1,p2,p3,p1text,WAIT_TIME,SECONDS_IN_WAIT from v$session_wait where wait_class# <> 6 2 order by wait_time desc) where rownum <=10;

?

確認為latch: cache buffers chains引起的故障后，查看latch的命中率

1 SQL>SELECT name, gets, misses, sleeps, 2 immediate_gets, immediate_misses 3 FROM v$latch 4 WHERE name = 'cache buffers chains';

各列名稱意義如下

?

1 NAME：latch名稱 2 IMMEDIATE_GETS：以Immediate模式latch請求數 3 IMMEDIATE_MISSES：請求失敗數 4 GETS：以Willing to wait請求模式latch的請求數 5 MISSES：初次嘗試請求不成功次數 6 SPIN_GETS：第一次嘗試失敗，但在以后的輪次中成功 7 SLEEP[x]：成功獲取前sleeping次數 8 WAIT_TIME：花費在等待latch的時間

?

?

這里需要注意MISSES/GETS如果在達10%左右，則說明有比較嚴重的latch爭用,也可以通過查詢v$latch_children視圖查看其他latch信息 ，語句如下

?

?

1 SQL> SELECT * 2 FROM (SELECT addr, child#, gets, misses, sleeps, immediate_gets igets, 3 immediate_misses imiss, spin_gets sgets 4 FROM v$latch_children 5 WHERE NAME = 'cache buffers chains' 6 ORDER BY sleeps DESC) 7 WHERE ROWNUM < 11;

?

關于latch的統計信息，主要關注以下幾部分
misses/gets的比率是多少
獲自spinning的misses的百分比是多少
latch請求了多少次
latch休眠了多少次

查看熱點對象和訪問信息，TCH列表示對象被訪問的次數

?

1 SQL> SELECT *2 FROM ( SELECT addr,3 ts#,4 file#,5 dbarfil,6 dbablk,7 tch8 FROM x$bh9 ORDER BY tch DESC) 10 WHERE ROWNUM < 11;

?

通過對象的文件號和塊號查看具體對象信息

1 SQL>select owner, segment_name, partition_name, tablespace_name 2 from dba_extents 3 where relative_fno = &v_dba_rfile 4 and &v_dba_block between block_id and block_id + blocks - 1;

?

也可以通過如下sql查找熱點塊，主要

?

?

1 SELECT * 2 FROM (SELECT O.OWNER, O.OBJECT_NAME, O.OBJECT_TYPE, SUM(TCH) TOUCHTIME 3 FROM X$BH B, DBA_OBJECTS O 4 WHERE B.OBJ = O.DATA_OBJECT_ID 5 AND B.TS# > 0 6 GROUP BY O.OWNER, O.OBJECT_NAME, O.OBJECT_TYPE 7 ORDER BY SUM(TCH) DESC) 8 WHERE ROWNUM <= 10;

?

?

查看引起latch: cache buffers chains的sql

?

1 SQL> select * from (select2 count(*),3 sql_id,4 nvl(o.object_name,ash.current_obj#) objn,5 substr(o.object_type,0,10) otype,6 CURRENT_FILE# fn,7 CURRENT_BLOCK# blockn8 from v$active_session_history ash9 , all_objects o 10 where event like 'latch: cache buffers chains' 11 and o.object_id (+)= ash.CURRENT_OBJ# 12 group by sql_id, current_obj#, current_file#, 13 current_block#, o.object_name,o.object_type 14 order by count(*) desc )where rownum <=10;

?

根據上面得到的sql_id信息查看sql全文

1 SQL>select sql_fulltext from v$sqlarea where sql_id='&sqlid';

?

查看SQL的執行計劃

1 SQL>SELECT * FROM table(DBMS_XPLAN.DISPLAY_CURSOR(('&sql_id',0));

在認為sql執行計劃不準確的情況也可以通過sql_id查看sql的address和hash_value查看sql的實際執行計劃

1 SQL>SELECT address, hash_value FROM v$sql 2 WHERE sql_id='&sql_id'; 3 SQL>SELECT operation, options, object_name, cost FROM v$sql_plan 4 WHERE address = '&addr' AND hash_value = 'hash_v';

?

當某個會話長時間持有latch時，可以通過聯合v$latchholder和v$session視圖查看sql信息

1 SQL>SELECT s.sql_hash_value,s.sql_id,s.address, l.name 2 FROM V$SESSION s, V$LATCHHOLDER l 3 WHERE s.sid = l.sid;

故障處理思路

1、根據sql執行計劃判斷該執行計劃是否正確，sql執行過長往往意味著過長時間的持有latch。
2、優化nested loop join，如果有可能使用hash join代替nested loop join。也可以利用對熱塊索引進行hash分區，或者使用hash簇的方式減緩熱塊現象。
3、調整表的pctfree值，將數據盡可能的分布到多個塊中
4、調整應用

?

聚焦技術與人文，分享干貨，共同成長！

更多內容請關注“數據與人”

總結

以上是生活随笔為你收集整理的latch: cache buffers chains故障处理总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。