I was about to add comment on my comments about latch acquisition. As test case cleary shows, the latch acquisition count is almost 2 times of logical reads. This means that Oracle does not release and reacquire the CBCL, but upgrades it. Your explanation clearly proves my assumption.

Really thanks for the awesome explanation!

A little correction. In step 3 above (in your reply to LSCheng) the CBC latch is not released and retaken in exclusive mode, but upgraded to exclusive mode from shared. This is what the “shared hash latch upgrades” statistics show in v$sesstat.

Also, pinning a buffer additionally means estabilishing pointers between session’s db buffer handles and pinned buffer headers. Oracle caches the db buffer handles in SGA (separate handles for each process) and doesn’t close these (nor unpins buffers) immediately after block visit. So, Oracle caches db handles for a call and closes them when a call finishes or the number of already cached handles exceeds a threshold (controlled by _db_handles_cached parameter, 5 by default)

So, the “buffer is already pinned count” statistic

It’s all about simple mathematics. In the above example, the size of both indexes is as following.

TABLE_NAME                    : T1                    
INDEX_NAME                    : T1_N1                 
BLEVEL                        : 1                     
LEAF_BLOCKS                   : 21                    
DISTINCT_KEYS                 : 10000                 
CLUSTERING_FACTOR             : 164                   
SAMPLE_SIZE                   : 10000                 
GLOBAL_STATS                  : YES                   
LAST_ANAL                     : 2009/05/04 20:52:22   
-----------------                                     
TABLE_NAME                    : T1                    
INDEX_NAME                    : T1_N2                 
BLEVEL                        : 1                     
LEAF_BLOCKS                   : 26                    
DISTINCT_KEYS                 : 10000                 
CLUSTERING_FACTOR             : 9934                  
SAMPLE_SIZE                   : 10000                 
GLOBAL_STATS                  : YES                   
LAST_ANAL                     : 2009/05/04 20:52:22   
-----------------                                     

I’ll do very simple mathematics using these values(with some computational errors)

1. For index T1_N1 of good clustering factor

1) Leaf block# = 21
2) So, keys per leaf block = 10000/21 = 476
3) Table block# = 164
4) So, keys per table block = 10000/164 = 61
5) Buffer is pinned by the 2nd visit on the same block.
Next read on the same block is incremented as buffer is pinned count
6) So, buffer is pinned count = (478-1)*21 + (61-1)*164 = 19815

-- index T1_N1(good clustering factor)
NAME                                             DIFF
---------------------------------------- ------------
buffer is pinned count                         19,835

2. For index T1_N2 of bad clustering factor

1) Leaf block# = 26
2) So, keys per leaf block = 10000/26 = 384.6
3) Table block# = 164
4) So, keys per table block = 10000/164 = 61
5) Buffer is pinned by the 2nd visit on the same block.
Next read on the same block is incremented as buffer is pinned count
6) So, buffer is pinned count = (384.6-1)*26 +  = 
9973 + small_value_for_table


-- index T1_N2(bad clustering factor)
NAME                                             DIFF
---------------------------------------- ------------
buffer is pinned count                         10,066

Thank you for the time and patience :-)

The step got modified as following.

1. Acquire CBCL in the shared mode.
2. Walk through the chain and find the buffer to read.
3. Release CBCL.
4. Acquire CBCL in the exclusive mode.
5. Acquire buffer pin for the buffer - shared mode for SELECT, exclusive mode for DML.
6. Release CBCL.
7. Read the buffer.
8. Acquire CBCL in the exclusive mode.
9. Release buffer pin.
10. Release CBCL.
11. Logical Reads done!

The point here is that buffer pin itself is a shared memory object which should be protected by latch. CBCL is used to protect buffer pin.

So to acquire buffer pin, 1) acquire CBCL in exclusive mode 2) acquire buffer pin 3) release CBCL.

And to release buffer pin, 1) acquire CBCL in exclusive mode 2) release buffer pin 3) release CBCL.

And this is why concurrent reads are still blocked by CBCL contention. At the short period during buffer read, we still need to acquire CBCL in exclusive mode.

1, 2, 3, 4, 7, 8, 10,11, 12

Dont understand very well step 5 and 7, arent they the same? Shouldnt the step be 1, 2, 3, 4, 7, 8, 9, 10,11, 12?

So at the end of the day concurrent reads could block each other due to exclusive CBCL (as I thought) no?

Thanks for your time