Buffer Cache Experiment 6:latch:cache buffers LRU chains

1.working set and Latch:cache buffers LRU chain:

Each working set has its own set of LRU and Lruw lists (LRU and Lruw lists always appear to be pairs).

Oracle uses multiple working sets to improve buffer cache performance (large memory)

Each working set is protected by a chain named "Latch:cache buffers LRU Latch," and each LRU Latch corresponds to a working set.

Each buffer header that is loaded into the buffer cache is then hooked up to the working set (included LRU list) in polling mode--。

Each buffer header that is loaded into the buffer cache is hooked up to working set by polling. In other words, when the buffer cache loads a new block of data, its corresponding buffer header will find a usable LRU latch, if not found, then find the next LRU latch until found. If all the LRU latch are not found LRU latch, the process waits for latch free to wait for the event, appears in V$session_wait, and adds "latch misses."

If multiple DBWR daemon processes are enabled, each DBWR process corresponds to a different working set, and each DBWR handles only the working set assigned to it, and no other working set is processed.

Number of 2.cache buffers LRU chain latch:

The number of cache buffers LRU chain latch created by Oracle default is related to CPU number, DBWR number.

DBWR is less than 4, the number is: 4*cpu number

DBWR is greater than 4, the number is: Dbwr*cpu number

Each buffer pool uses its own cache buffers LRU chain LATCH, a database instance can be configured: Default,2kb,4kb,8kb,16kb,32kb,keep,recycle these 8 types of buffer Pool, so the number of cache buffers LRU chain latch is at least 8. See: Click to open the link

or use the following statement to find out the cache buffers LRU chain latch in the buffer cache: --the statement from the Liang Zhou "ORACLE dba Combat Strategy"

This column more highlights: http://www.bianceng.cnhttp://www.bianceng.cn/database/storage/

sys@ bys3>select d.blk_size,c.child#,p.bp_name,c.gets,c.sleeps from X$kcbwds d,v$latch_children c,x$kcbwbpd p where D.set_latch=c.addr and d.set_id between P.bp_lo_sid and P.bp_hi_sid order by c.child#;

Blk_size child# Bp_name GETS sleeps

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

8192 1 KEEP 18 0

8192 3 Recycle 18 0

8192 5 DEFAULT 864096 144

2048 7 DEFAULT 18 0

4096 9 DEFAULT 18 0

8192 DEFAULT 18 0

16384 DEFAULT 18 0

32768 DEFAULT 18 0

In my virtual machine, the CPU is one, in 10G there are 8 LRU LATCH, in 11gr2, is 16 LRU LATCH. See: Http://blog.csdn.net/haibusuanyun/article/details/19084583#t6

3.cache buffers LRU Chain latch Under what circumstances need to be used:

Data block read into buffer cache before need to get cache buffers LRU chain latch--because to find free buffer on LRU

DBWR Scan Lruw linked list needs to obtain cache buffers LRU chain LATCH

Smon to move the free buffer to the LRU auxiliary column, also requires the cache buffers LRU chain LATCH.

4.cache buffers LRU chain latch in which cases the contention occurs:

Simply put, multiple processes are simultaneously retrieving LRU/LRUW.

The specific situation is:-Excessive physical reading causes contention concept high.

Multiple sessions have concurrent access to different tables or indexes, because physical reads can be large--by the above it is known that physical reads need to be LRU to find free buffer

Too many dirty blocks, DBWR write slow (DBWR performance problems, or disk I/O), involve DBWR tuning-not much to discuss here.

Note: CBC latch mainly occurs during logical reading-multiple sessions concurrently accessing the same table or index-the same table or index is concentrated in several identical hash chain.