<?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: I Didn&#8217;t Know That 5 &#8211; What is Wrong with this Quote?</title>
	<atom:link href="http://hoopercharles.wordpress.com/2010/12/13/i-didnt-know-that-5-what-is-wrong-with-this-quote/feed/" rel="self" type="application/rss+xml" />
	<link>http://hoopercharles.wordpress.com/2010/12/13/i-didnt-know-that-5-what-is-wrong-with-this-quote/</link>
	<description>Miscellaneous Random Oracle Topics: Stop, Think, ... Understand</description>
	<lastBuildDate>Mon, 13 May 2013 14:10:06 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Jonathan Lewis</title>
		<link>http://hoopercharles.wordpress.com/2010/12/13/i-didnt-know-that-5-what-is-wrong-with-this-quote/#comment-2419</link>
		<dc:creator><![CDATA[Jonathan Lewis]]></dc:creator>
		<pubDate>Mon, 13 Dec 2010 21:16:22 +0000</pubDate>
		<guid isPermaLink="false">http://hoopercharles.wordpress.com/?p=4012#comment-2419</guid>
		<description><![CDATA[Charles,

I&#039;ve just checked my archives - I should have done that before I checked MOS - I sent in the feedback on 3rd June 2008, but took a pdf dump of the note before it was withdrawn.

It really does say: 
Using bigger blocks means more space for key storage in the branch nodes of B*-tree indexes, which reduces index height, which improves the performance of indexed queries.

But it also says:
Large block size is not good for index blocks used in an OLTP type environment, because they increase block contention on the index leaf blocks

And just to give you a warm glow of confidence - it quotes the average disk seek time at 19 milliseconds !]]></description>
		<content:encoded><![CDATA[<p>Charles,</p>
<p>I&#8217;ve just checked my archives &#8211; I should have done that before I checked MOS &#8211; I sent in the feedback on 3rd June 2008, but took a pdf dump of the note before it was withdrawn.</p>
<p>It really does say:<br />
Using bigger blocks means more space for key storage in the branch nodes of B*-tree indexes, which reduces index height, which improves the performance of indexed queries.</p>
<p>But it also says:<br />
Large block size is not good for index blocks used in an OLTP type environment, because they increase block contention on the index leaf blocks</p>
<p>And just to give you a warm glow of confidence &#8211; it quotes the average disk seek time at 19 milliseconds !</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Charles Hooper</title>
		<link>http://hoopercharles.wordpress.com/2010/12/13/i-didnt-know-that-5-what-is-wrong-with-this-quote/#comment-2418</link>
		<dc:creator><![CDATA[Charles Hooper]]></dc:creator>
		<pubDate>Mon, 13 Dec 2010 18:22:58 +0000</pubDate>
		<guid isPermaLink="false">http://hoopercharles.wordpress.com/?p=4012#comment-2418</guid>
		<description><![CDATA[Jonathan,

Thank you for the reply.  I suspect that Doc ID 46757.1 was removed in June 2008 (if I recall correctly, the author of this book thanked you on a couple of occasions for taking the time to file feedback for Metalink documents).  

It is interesting to see the transformation of this paraphrase from Metalink Doc ID 46757.1.  For example, in this blog article http://www.oraclealchemist.com/oracle/hey-guys-does-size-matter/ you will find Doc ID 46757.1 mentioned in the comments, where it appears that Metalink article was comparing indexes in a 2KB block size tablespace with the same index in a 8KB block size tablespace - I do not see any mention of &quot;large&quot; block size tablespaces - that is larger than the default block size.

Just to make certain that we create a little bit of circular reasoning, the OTN thread that I linked to above (http://jonathanlewis.files.wordpress.com/2008/07/ls2.pdf ) includes a link to the above blog article on www.oraclealchemist.com.  And, suprisingly, that particular problem is mentioned on page 537 of the book (see my review).]]></description>
		<content:encoded><![CDATA[<p>Jonathan,</p>
<p>Thank you for the reply.  I suspect that Doc ID 46757.1 was removed in June 2008 (if I recall correctly, the author of this book thanked you on a couple of occasions for taking the time to file feedback for Metalink documents).  </p>
<p>It is interesting to see the transformation of this paraphrase from Metalink Doc ID 46757.1.  For example, in this blog article <a href="http://www.oraclealchemist.com/oracle/hey-guys-does-size-matter/" rel="nofollow">http://www.oraclealchemist.com/oracle/hey-guys-does-size-matter/</a> you will find Doc ID 46757.1 mentioned in the comments, where it appears that Metalink article was comparing indexes in a 2KB block size tablespace with the same index in a 8KB block size tablespace &#8211; I do not see any mention of &#8220;large&#8221; block size tablespaces &#8211; that is larger than the default block size.</p>
<p>Just to make certain that we create a little bit of circular reasoning, the OTN thread that I linked to above (<a href="http://jonathanlewis.files.wordpress.com/2008/07/ls2.pdf" rel="nofollow">http://jonathanlewis.files.wordpress.com/2008/07/ls2.pdf</a> ) includes a link to the above blog article on <a href="http://www.oraclealchemist.com" rel="nofollow">http://www.oraclealchemist.com</a>.  And, suprisingly, that particular problem is mentioned on page 537 of the book (see my review).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kumar</title>
		<link>http://hoopercharles.wordpress.com/2010/12/13/i-didnt-know-that-5-what-is-wrong-with-this-quote/#comment-2414</link>
		<dc:creator><![CDATA[Kumar]]></dc:creator>
		<pubDate>Mon, 13 Dec 2010 15:13:32 +0000</pubDate>
		<guid isPermaLink="false">http://hoopercharles.wordpress.com/?p=4012#comment-2414</guid>
		<description><![CDATA[Hi Charles
With my limited understanding, this is my thought. Please correct me if I am not right
&gt; Larger block sizes do not mean that you dont have row chaining or migrations. It depends on the amount of DML performed on the tables and the size of the rows (and pct free) and also the data type of columns (long columns, long raw etc).
&gt; From my reading and understanding in Richard Foote&#039;s blog about Indexes, Indexes are always height balanced and it does not make a difference. Again it depends on the type of activity on the index. More rows may be packed per block initially but as there is more DML, then it the &#039;bigger&#039; index blocks can also become sparsely populated.
&gt; Large blocks give more data transfer per I/O call: If there are lot of empty blocks and inserts using Direct loads then you may not really achieve this.

Thank you
Kumar]]></description>
		<content:encoded><![CDATA[<p>Hi Charles<br />
With my limited understanding, this is my thought. Please correct me if I am not right<br />
&gt; Larger block sizes do not mean that you dont have row chaining or migrations. It depends on the amount of DML performed on the tables and the size of the rows (and pct free) and also the data type of columns (long columns, long raw etc).<br />
&gt; From my reading and understanding in Richard Foote&#8217;s blog about Indexes, Indexes are always height balanced and it does not make a difference. Again it depends on the type of activity on the index. More rows may be packed per block initially but as there is more DML, then it the &#8216;bigger&#8217; index blocks can also become sparsely populated.<br />
&gt; Large blocks give more data transfer per I/O call: If there are lot of empty blocks and inserts using Direct loads then you may not really achieve this.</p>
<p>Thank you<br />
Kumar</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jonathan Lewis</title>
		<link>http://hoopercharles.wordpress.com/2010/12/13/i-didnt-know-that-5-what-is-wrong-with-this-quote/#comment-2413</link>
		<dc:creator><![CDATA[Jonathan Lewis]]></dc:creator>
		<pubDate>Mon, 13 Dec 2010 15:11:42 +0000</pubDate>
		<guid isPermaLink="false">http://hoopercharles.wordpress.com/?p=4012#comment-2413</guid>
		<description><![CDATA[I think the most important detail of Oracle&#039;s official position on My Oracle Support (formerly Metalink) is the Warranties and Disclaimers section of the Terms of Use (all capitals are from the original):

&quot;THE INFORMATION, SOFTWARE, PRODUCTS AND SERVICES CONTAINED IN MY ORACLE SUPPORT MAY BE OUT OF DATE OR INCLUDE OMISSIONS, INACCURACIES OR OTHER ERRORS.  THE INFORMATION, SOFTWARE, PRODUCTS AND SERVICES CONTAINED IN MY ORACLE SUPPORT, INCLUDING THE MATERIALS, ARE PROVIDED &quot;AS IS&quot; AND WITHOUT WARRANTY.  ORACLE DOES NOT WARRANT THAT THE INFORMATION IN THE MATERIALS IS UP TO DATE OR ERROR-FREE.&quot;

Users of My Oracle Support (Metalink) may also be aware that there is an option to supply feedback on the information available on the system. I have taken advantage of this on several occasions, and the administrators have, in the past, withdrawn a couple of notes on the basis of the errors I have pointed out.  

In fact I can&#039;t, at present, find note 46757.1 on My Oracle Support and I think it may be one of the ones that I suggested they withdraw or rewrite because of its potential for misleading people and causing performance problems.]]></description>
		<content:encoded><![CDATA[<p>I think the most important detail of Oracle&#8217;s official position on My Oracle Support (formerly Metalink) is the Warranties and Disclaimers section of the Terms of Use (all capitals are from the original):</p>
<p>&#8220;THE INFORMATION, SOFTWARE, PRODUCTS AND SERVICES CONTAINED IN MY ORACLE SUPPORT MAY BE OUT OF DATE OR INCLUDE OMISSIONS, INACCURACIES OR OTHER ERRORS.  THE INFORMATION, SOFTWARE, PRODUCTS AND SERVICES CONTAINED IN MY ORACLE SUPPORT, INCLUDING THE MATERIALS, ARE PROVIDED &#8220;AS IS&#8221; AND WITHOUT WARRANTY.  ORACLE DOES NOT WARRANT THAT THE INFORMATION IN THE MATERIALS IS UP TO DATE OR ERROR-FREE.&#8221;</p>
<p>Users of My Oracle Support (Metalink) may also be aware that there is an option to supply feedback on the information available on the system. I have taken advantage of this on several occasions, and the administrators have, in the past, withdrawn a couple of notes on the basis of the errors I have pointed out.  </p>
<p>In fact I can&#8217;t, at present, find note 46757.1 on My Oracle Support and I think it may be one of the ones that I suggested they withdraw or rewrite because of its potential for misleading people and causing performance problems.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Charles Hooper</title>
		<link>http://hoopercharles.wordpress.com/2010/12/13/i-didnt-know-that-5-what-is-wrong-with-this-quote/#comment-2411</link>
		<dc:creator><![CDATA[Charles Hooper]]></dc:creator>
		<pubDate>Mon, 13 Dec 2010 13:38:35 +0000</pubDate>
		<guid isPermaLink="false">http://hoopercharles.wordpress.com/?p=4012#comment-2411</guid>
		<description><![CDATA[Alistair,

Thank you for the reply.

----------------

Can anyone confirm that the Metalink (MOS) Doc ID referenced by the book states that (paraphrased) &quot;Indexes like big blocks&quot;?

Also, what are &quot;Oracle metal-level customers&quot; - is it possibly Oracle Corporation customers who are running Oracle Database on (Oracle) Sun servers?  Does Doc ID 46757.1 only apply to customers running Oracle Database on  (Oracle) Sun servers?]]></description>
		<content:encoded><![CDATA[<p>Alistair,</p>
<p>Thank you for the reply.</p>
<p>&#8212;&#8212;&#8212;&#8212;&#8212;-</p>
<p>Can anyone confirm that the Metalink (MOS) Doc ID referenced by the book states that (paraphrased) &#8220;Indexes like big blocks&#8221;?</p>
<p>Also, what are &#8220;Oracle metal-level customers&#8221; &#8211; is it possibly Oracle Corporation customers who are running Oracle Database on (Oracle) Sun servers?  Does Doc ID 46757.1 only apply to customers running Oracle Database on  (Oracle) Sun servers?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alistair Wall</title>
		<link>http://hoopercharles.wordpress.com/2010/12/13/i-didnt-know-that-5-what-is-wrong-with-this-quote/#comment-2406</link>
		<dc:creator><![CDATA[Alistair Wall]]></dc:creator>
		<pubDate>Mon, 13 Dec 2010 09:40:29 +0000</pubDate>
		<guid isPermaLink="false">http://hoopercharles.wordpress.com/?p=4012#comment-2406</guid>
		<description><![CDATA[It cites a metalink note about the advantages of large [single] block sizes, not multiple block sizes.

From Tom Kyte, there is an overhead for providing different memory areas for different block sizes. The feature is provided so you can transport tablespaces from databases with different block sizes.]]></description>
		<content:encoded><![CDATA[<p>It cites a metalink note about the advantages of large [single] block sizes, not multiple block sizes.</p>
<p>From Tom Kyte, there is an overhead for providing different memory areas for different block sizes. The feature is provided so you can transport tablespaces from databases with different block sizes.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
