關于Oracle數據庫latch: cache buffers chains等待事件

latch: cache buffers chains等待事件的原理

當一個數據塊讀入到sga中時，該塊的塊頭(buffer header)會放置在一個hash bucket的鏈表(hash chain)中。該內存結構由一系列cache buffers chains子latch保護(又名hash latch或者cbc latch)。對Buffer cache中的塊，要select或者update、insert,delete等，都得先獲得cache buffers chains子latch，以保證對chain的排他訪問。若在過程中發生爭用，就會等待latch:cache buffers chains事件。

latch: cache buffers chains等待事件產生原因

我們先看看Oracle官方對latch:cache buffers chains等待事件的說明：

latch: cache buffers chains：

"latch: cache buffers chains" contention is typically encountered because SQL statements read more buffers than they need to and multiple sessions are waiting to read the same block.

If you have high contention, you need to look at the statements that perform the most buffer gets and then look at their access paths to determine whether these are performing as efficiently as you would like.

Typical solutions are:-

?Look for SQL that accesses the blocks in question and determine if the repeated reads are necessary. This may be within a single session or across multiple sessions.

?Check for suboptimal SQL (this is the most common cause of the events) - look at the execution plan for the SQL being run and try to reduce the gets per executions which will minimize the number of blocks being accessed and therefore reduce the chances of multiple sessions contending for the same block.

1. 低效率的SQL語句(主要體現在邏輯讀過高)

在某些環境中，應用程序打開執行相同的低效率SQL語句的多個并發會話，這些SQL語句都設法得到相同的數據集，每次執行都帶有高BUFFER_GETS(邏輯讀取)的SQL語句是主要的原因。相反，較小的邏輯讀意味著較少的latch get操作，從而減少鎖存器爭用并改善性能。注意v$sql中BUFFER_GETS/EXECUTIONS大的語句。

2.Hot block熱點塊

當多個會話重復訪問一個或多個由同一個子cache buffers chains鎖存器保護的塊時，熱塊就會產生。當多個會話爭用cache buffers chains子鎖存器時，就會出現這個等待事件。有時就算調優了SQL，但多個會話同時執行此SQL，那怕只是掃描特定少數塊，也是也會出現HOT BLOCK的。

如果是存在熱點塊，那么介紹兩種找出熱點塊的方法。

找出熱點塊方法一：

--首先找出p1raw

[SQL] syntaxhighlighter_viewsource syntaxhighlighter_copycodeselect p1, p1raw

from v$session_wait

where event = 'latch: cache buffers chains';

--再根據p1raw找到對象

[SQL] syntaxhighlighter_viewsource syntaxhighlighter_copycodeSELECT /*+ RULE */

E.OWNER || '.' || E.SEGMENT_NAME SEGMENT_NAME,

E.PARTITION_NAME,

E.EXTENT_ID EXTENT#,

X.DBABLK - E.BLOCK_ID + 1 BLOCK#,

X.TCH,

L.CHILD#

FROM SYS.V$LATCH_CHILDREN L, SYS.X$BH X, SYS.DBA_EXTENTS E

WHERE X.HLADDR = '00000003576EE324' --p1raw

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;

找出熱點塊方法二：

--直接找出熱點塊

[SQL] syntaxhighlighter_viewsource syntaxhighlighter_copycodeSELECT OBJECT_NAME, SUBOBJECT_NAME

FROM DBA_OBJECTS

WHERE DATA_OBJECT_ID IN

(SELECT DATA_OBJECT_ID

FROM (SELECT OBJ DATA_OBJECT_ID, FILE#, DBABLK, CLASS, STATE, TCH

FROM X$BH

WHERE HLADDR IN (SELECT ADDR

FROM (SELECT ADDR

FROM V$LATCH_CHILDREN

ORDER BY (GETS + MISSES + SLEEPS) DESC)

WHERE ROWNUM < 10)

ORDER BY TCH DESC)

WHERE ROWNUM < 10);

分析latch: cache buffers chains，查找邏輯讀較多的SQL進行分析:

Problem: Database is slow and 'latch: cache buffers chains' is high in the waits in AWR.

Start with Top 5 Waits:

Top 5 Timed Events? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ???Avg? ? %Total

~~~~~~~~~~~~~~~~~~? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ???wait? ?Call

Event? ?? ?? ?? ?? ?? ?? ?? ???Waits? ?? ???Time (s)? ? (ms)? ?Time? ?Wait Class

------------------------------ ------------ ----------- ------ ------ ----------

latch: cache buffers chains? ?? ?? ? 74,642? ?? ?35,421? ? 475? ? 6.1 Concurrenc

CPU time? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ???11,422? ?? ?? ???2.0

log file sync? ?? ?? ?? ?? ?? ?? ?? ?34,890? ?? ? 1,748? ???50? ? 0.3 Commit

latch free? ?? ?? ?? ?? ?? ?? ?? ?? ? 2,279? ?? ?? ?774? ? 340? ? 0.1 Other

db file parallel write? ?? ?? ?? ?? ?18,818? ?? ?? ?768? ???41? ? 0.1 System I/O

-------------------------------------------------------------

High cache buffers chains latch indicates that there is likely to be something reading a lot of buffers. Typically the SQL with the most gets is likely to be that which is contending:

SQL ordered by Gets? ?? ?? ?DB/Inst:??Snaps: 1-2

-> Resources reported for PL/SQL code includes the resources used by all SQL

statements called by the code.

-> Total Buffer Gets:? ?265,126,882

-> Captured SQL account for? ?99.8% of Total

Gets? ?? ?? ?? ?? ? CPU? ?? ?Elapsed

Buffer Gets? ? Executions? ?per Exec? ???%Total Time (s) Time (s)??SQL Id

-------------- ------------ ------------ ------ -------- --------- -------------

256,763,367? ?? ? 19,052? ???13,477.0? ?96.8 ######## ######### a9nchgksux6x2

Module: JDBC Thin Client

SELECT * FROM SALES ....

1,974,516? ?? ?987,056? ?? ?? ? 2.0? ? 0.7? ? 80.31? ? 110.94 ct6xwvwg3w0bv

SELECT COUNT(*) FROM ORDERS ....

The Query with SQL_ID a9nchgksux6x2 is reading 100x more buffers than the 2nd most 'hungry' statement and CPU and Elapsed are off the 'scale' of the report.??This is a prime candidate for the cause of the CBC latch issues.

You can also link this information to the Top??Segments by Logical Reads:

Segments by Logical Reads

-> Total Logical Reads:? ???265,126,882

-> Captured Segments account for? ?98.5% of Total

Tablespace? ?? ?? ?? ?? ?? ?? ? Subobject??Obj.? ?? ? Logical

Owner? ?? ?? ?Name? ? Object Name? ?? ?? ?? ?Name? ???Type? ?? ?? ?Reads??%Total

---------- ---------- -------------------- ---------- ----- ------------ -------

DMSUSER? ? USERS? ?? ?SALES? ?? ?? ?? ?? ?? ?? ?? ?? ?TABLE??212,206,208? ?80.04

DMSUSER? ? USERS? ?? ?SALES_PK? ?? ?? ?? ?? ?? ?? ?? ?INDEX? ?44,369,264? ?16.74

DMSUSER? ? USERS? ?? ?SYS_C0012345? ?? ?? ?? ?? ?? ???INDEX? ? 1,982,592? ???.75

DMSUSER? ? USERS? ?? ?ORDERS_PK? ?? ?? ?? ?? ?? ?? ???INDEX? ?? ?842,304? ???.32

DMSUSER? ? USERS? ?? ?INVOICES? ?? ?? ?? ?? ?? ?? ?? ?TABLE? ?? ?147,488? ???.06

-------------------------------------------------------------

The top object read is SALES and the top SQL is a select from SALES which appears to correlate towards this being a potential problem select.

This SQL should be investigated to see if the Gets per Exec or the Executions figure per hour has changed in any way (comparison to previous reports would show this) and if so the reasons for that change investigated and resolved.

In this case the statement is reading > 10,000 buffers per execution and executing > 15,000 times

so both of these may need to be adjusted to get better performance.

Note: This is a simple example where there is a high likelihood that the 'biggest' query is the culprit but it is not always the 'Top' SQL that causes the problem. For example, contention may occur on a statement with a smaller total if it is only executed a small number of times so that??it may not appear as the top sql. It may still make millions of buffer gets, but will appear lower in the list because other sqls are performing many times, just not contending.

So, if the first SQL is not the culprit then look at the others.

總結

以上是生活随笔為你收集整理的oracle数据库latch,关于Oracle数据库latch: cache buffers chains等待事件的全部內容，希望文章能夠幫你解決所遇到的問題。

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