I did a little test on a 11.2.0.3.0 DB to see the effect of the clustering factor on the number of logical IOs and pinned buffer usage and how this is visible in the session statistics and latches.

For better readability I don’t list the entire sequence of actions in SQL. I created a table (LIO_TEST) with two indexed columns ID1 and ID2. I filled the table with 4000 rows such that the index on ID1 had a very low clustering factor and the index on ID2 had a very high clustering factor – the following excerpt from DBA_INDEXES depicts this:

INDEX_NAME DISTINCT_KEYS NUM_ROWS BLEVEL LEAF_BLOCKS CLUSTERING_FACTOR LIO_TEST#ID1#I 3999 3999 1 8 122 LIO_TEST#ID2#I 3999 3999 1 9 3961

Than I ran the following queries to read 1001 out of the 3999 table rows through the respective index (and with a fulll table scan for comparison). I used a hint to make Oracle use the index and checked an additional (non-indexed) table column to enforce access to the table blocks.

-- index with low clustering factor -- index with high clustering factor -- full table scan select /*+ index(lio_test) */ * select /*+ index(lio_test) */ * select /*+ no_index(lio_test) */ * from lio_test from lio_test from lio_test where id1 between 1000 and 2000 where id2 between 1000 and 2000 where id1 between 1000 and 2000 and pad = 'a'; and pad = 'a'; and pad = 'a';

I used V$SESSTAT to view the statistics and I used V$LATCH to see the latch activity. Besides the actual test there was very little activity on the database. Therefore I conclude that most of the observed latch activity was actually caused by the test itself.

Index with low clustering factor (on ID1):

diff Statistic session logical reads : 35 diff Statistic consistent gets : 35 diff Statistic consistent gets - examination : 1 diff Statistic buffer is not pinned count : 33 diff Statistic buffer is pinned count : 1970 diff Statistic table fetch by rowid : 1001 diff Statistic no buffer to keep pinned count : 0 diff Latch cache buffers chains : 80 diff Latch cache buffer handles : 0

Index with high clustering factor (on ID2):

diff Statistic session logical reads : 1000 diff Statistic consistent gets : 1000 diff Statistic consistent gets - examination : 1 diff Statistic buffer is not pinned count : 997 diff Statistic buffer is pinned count : 1006 diff Statistic table fetch by rowid : 1001 diff Statistic no buffer to keep pinned count : 0 diff Latch cache buffers chains : 2211 diff Latch cache buffer handles : 0

full table scan

diff Statistic session logical reads : 136 diff Statistic consistent gets : 136 diff Statistic consistent gets - examination : 0 diff Statistic buffer is not pinned count : 0 diff Statistic buffer is pinned count : 0 diff Statistic table fetch by rowid : 0 diff Statistic no buffer to keep pinned count : 0 diff Latch cache buffers chains : 285 diff Latch cache buffer handles : 0

With the high clustering factor you notice almost one logical read per row, where as with the low clustering factor every index and table block is read only once, with the resulting difference in cache buffers chains gets.

Also the sum of “buffer is not pinned count” + “buffer is pinned count” is constant (2003). I believe this is the number of block visits (index leaf blocks and table blocks), where the (presumably 2) index leaf blocks were pinned after the first visit (in both cases).

As a side remark, I noticed that “buffer is not pinned count”, “buffer is pinned count” is 0 in the full table scan, which I interprete as Oracle reporting only block visits where there is a chance that the block might be pinned in these statistics.

kind regards

Martin