Depth understanding latch: cache buffers chains
http://blog.itpub.net/12679300/viewspace-1244578/
Event Background:
a customer database downtime incident occurred, view the database awr report, originally due to the emergence of a large number of latch: cache buffers chains waiting for events leading to the consumption of a large amount of system CPU, cause the system to hang final live;
Note:
To understand latch: cache buffers chains and solve this problem, we need in-depth understanding of the Buffer Cache and its principles.
1, Buffer Cache Overview:
Buffer Cache is part of the SGA, Oracle use Buffer Cache to manage the data block, the ultimate goal is to Buffer Cache as much as possible to reduce disk I / O. Buffer Cache There are three major structures are used to manage Buffer Cache: the Hash Bucket, Hash Chain List, the LRU List;
the Hash Bucket & Hash Chain List: Hash Chain List and the Hash Bucket for rapid positioning of the data block.
LRU List: loading specific pointing free buffer, pinned buffer dirty buffer and the like have not been moved to the write list information. Refers to the so-called free buffer buffer does not contain any data, the so-called pinned buffer, refers to the buffer currently being accessed.
Write (Dirty) List: Mount pointing a dirty block of concrete information. The so-called dirty block, refers to the buffer cache is modified but had not yet been written to disk block.
2, Hash Bucket principle:
If all of the Buffer Cache Buffer are all managed by the same structure, when it is necessary to determine whether there is a Block in Buffer, the need to traverse the entire structure, performance will be very low;
in order to improve efficiency, Oracle introduced the Data Bucket structure, Oracle Buffer to manage all the inside through a Hash algorithm operation, stored in different Hash Bucket, followed by dividing this Hash Bucket, many Bucket Buffer is distributed into a number, when the user needs in Buffer whether the present location data is only obtained by the same algorithm Hash value, and to find the appropriate amount of Buffer Bucket can be determined. Each Bucket Buffer storage operation is determined by the data of the block address Buffer; (this algorithm information obtained from the official ORACLE very little can be indexed with the knowledge to understand) inside Bucket, by Cache Buffer Chain by all of the Buffer Buffer Header Information link;
in order to protect data in the Bucket, time per visit will need to obtain in order to access the memory latches, access to the entire structure is shown: 
the order of user memory, read data:
a) using the Block Hash algorithm to obtain a Hash value.
b) get obtain cache buffers chains latch
c) the Bucket search for a corresponding Buffer Header corresponding to the Hash
B) obtained Cache buffers chains LATCH;
D) If a matching Buffer Header, and then determines the status of the Buffer to see whether configured CR Block, or Buffer state of pin, Finally read. e) If not, then read from the disk into the Buffer Cache.
3, latch: cache buffers chains waiting for an event
in Oracle9i before, if the other user processes has earned this latch, then the new process must wait until the user search process is complete (it will release the latch after the search is completed). Starting with Oracle9i can be read-only shared cache buffers chains latch, which means that users with read-only process A (select) way to access Block, this time to get the latch, while the user process B also read-only access Block, then Because this time is read-only access, the user process B can also get the latch. However, if users want to process B with exclusive access Block, then the user process B will wait for the user process A releases the latch, this time Oracle user process B will mark a latch: cache buffers chains of waiting for the event.
4, latch: cache buffers chains reasons appear
4.1 is not optimized SQL.
A large number of logical reads SQL statement is likely to have very serious latch: cache buffers chains wait, because every time you want to access a block, you need to get the latch, due to the large number of logical reads, then it increases the latch: cache buffers chains the probability of contention. For SQL statements running very serious latch: cache buffers chains contention, you can use the following SQL view the execution plan and to try to optimize the SQL statement.
select * from table (dbms_xplan.display_cursor ( ' sql_id', sql_child_number));
if SQL has finished running, we'll look at AWR statements inside SQL Statistics-> SQL ordered by Gets-> Gets per Exec, trying to optimize the SQL.
4.2 contention hot block
1) if the database lookup contention exists latch
select sid, event, p1text, p1raw from v $ session_wait where event = 'latch: cache buffers chains';
query isolated 2) below with the contention 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 ;
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, E DBA_EXTENTS 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 -1 + e.blocks Order by x.tch desc;
4.3 Hash Bucket little need to change _db_block_hash_buckets implicit parameter. In fact, after Oracle9i, we basically will not encounter this problem, unless encountered Bug. So this is not recommended, remember, before making changes to the Oracle hidden parameters must consult Oracle Support.
5, latch: cache buffers chains simulated testing
5.1 Create a table
the SQL> John Create Table (int NO, object_name VARCHAR2 (50));
5.2 insert data S
QL> DECLARE int I; I beginfor in John SELECT INTO 1..5 loopinsert rownum as no, object_name from dba_objects; end loop; end; /
5.3 Create a stored procedure the SQL> Create or Replace Procedure p_john ISI int; int iCount; beginfor I in 1..1000 loopselect COUNT (*) INTO iCount from John; End Loop; End; /
5.4 20 concurrent analog full table scan
SQL> var Number job_no; S
QL> 1..20 loopdbms_job.submit in beginfor IDX (: job_no, 'p_john;'); the commit; End Loop; End; /
5.5 Check contention
SQL> select sid, event, p1text , p1raw from v $ session_wait where event = 'latch : cache buffers chains'; 
display store large volumes latch waits;
5.6 latch: Cache buffers chains waiting feature event report awr
Summing up the above features:
A) take up a lot of CPU resources;
b) logical reads than normal to be a lot more;
there c) wait for the event certainly latch: cache buffers chains
shooting d) Latch is generally 95% or less, serious 90% or less;
6、latch:cache buffers chains的个人解决方法很多时候应用的问题，其实是由于SQL质量导致的，很多DBA吐槽：DBA和开发是不同的部门，所以要让开发配合起来进行SQL调优难度较大，可行性较小。对于这种观点本人表示不赞同：当系统出现大的问题的时候，会导致系统性能下降，甚至宕机，那么如果这个系统重要的话，那么DBA完全可以把问题的原因及解决方法发送给开发人员，并抄送公司领导，并说明原因及解决的方法，由于这个时候DBA是唯一知道问题的根源及解决方法的，所以领导也会支持你的；另外：SQL调优是最有效的调优方法，建议DBA别从系统的角度去进行处理，避免填了一个坑又冒出一个坑；
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
本文作者：JOHN
ORACLE技术博客：ORACLE 猎人笔记 数据库技术群：367875324 （请备注ORACLE管理 ）
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++