<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: Usage Stats</title>
	<atom:link href="http://jonathanlewis.wordpress.com/2013/01/24/usage-stats/feed/" rel="self" type="application/rss+xml" />
	<link>http://jonathanlewis.wordpress.com/2013/01/24/usage-stats/</link>
	<description>Just another Oracle weblog</description>
	<lastBuildDate>Fri, 24 May 2013 13:27:07 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Martin Maletinsky</title>
		<link>http://jonathanlewis.wordpress.com/2013/01/24/usage-stats/#comment-53256</link>
		<dc:creator><![CDATA[Martin Maletinsky]]></dc:creator>
		<pubDate>Tue, 29 Jan 2013 15:34:02 +0000</pubDate>
		<guid isPermaLink="false">http://jonathanlewis.wordpress.com/?p=10461#comment-53256</guid>
		<description><![CDATA[Hello Jonathan,

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&#039;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:
[sourcecode]
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
[/sourcecode]
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. 

[sourcecode]
-- 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 = &#039;a&#039;;                                       and pad = &#039;a&#039;;                                    and pad = &#039;a&#039;;                     
[/sourcecode]
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):
[sourcecode]
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
[/sourcecode]
Index with high clustering factor (on ID2):
[sourcecode]
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
[/sourcecode]
full table scan
[sourcecode]
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
[/sourcecode]

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 &quot;buffer is not pinned count&quot; + &quot;buffer is pinned count&quot; 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 &quot;buffer is not pinned count&quot;, &quot;buffer is pinned count&quot; 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]]></description>
		<content:encoded><![CDATA[<p>Hello Jonathan,</p>
<p>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.</p>
<p>For better readability I don&#8217;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 &#8211; the following excerpt  from DBA_INDEXES depicts this:</p>
<pre class="brush: plain; title: ; notranslate">
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
</pre>
<p>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. </p>
<pre class="brush: plain; title: ; notranslate">
-- 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';                     
</pre>
<p>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.</p>
<p>Index with low clustering factor (on ID1):</p>
<pre class="brush: plain; title: ; notranslate">
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
</pre>
<p>Index with high clustering factor (on ID2):</p>
<pre class="brush: plain; title: ; notranslate">
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
</pre>
<p>full table scan</p>
<pre class="brush: plain; title: ; notranslate">
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
</pre>
<p>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.<br />
Also the sum of &#8220;buffer is not pinned count&#8221; + &#8220;buffer is pinned count&#8221; 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).<br />
As a side remark, I noticed that &#8220;buffer is not pinned count&#8221;, &#8220;buffer is pinned count&#8221; 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.</p>
<p>kind regards<br />
Martin</p>
]]></content:encoded>
	</item>
</channel>
</rss>
