<?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: Index Rebuilds</title>
	<atom:link href="http://jonathanlewis.wordpress.com/2010/12/27/index-rebuilds-3/feed/" rel="self" type="application/rss+xml" />
	<link>http://jonathanlewis.wordpress.com/2010/12/27/index-rebuilds-3/</link>
	<description>Just another Oracle weblog</description>
	<lastBuildDate>Thu, 23 May 2013 12:47:17 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: DEL_LF_ROWS Index Rebuild Criteria ? (Codex) &#171; Richard Foote&#8217;s Oracle Blog</title>
		<link>http://jonathanlewis.wordpress.com/2010/12/27/index-rebuilds-3/#comment-40548</link>
		<dc:creator><![CDATA[DEL_LF_ROWS Index Rebuild Criteria ? (Codex) &#171; Richard Foote&#8217;s Oracle Blog]]></dc:creator>
		<pubDate>Sun, 22 May 2011 11:01:31 +0000</pubDate>
		<guid isPermaLink="false">http://jonathanlewis.wordpress.com/?p=5252#comment-40548</guid>
		<description><![CDATA[[...] In fact, if you want to avoid some nonsensical  index rebuild criteria based on DEL_LF_ROWS, all you need to do is simply delete yet more rows, as so wonderfully here explained by Jonathan Lewis. [...]]]></description>
		<content:encoded><![CDATA[<p>[...] In fact, if you want to avoid some nonsensical  index rebuild criteria based on DEL_LF_ROWS, all you need to do is simply delete yet more rows, as so wonderfully here explained by Jonathan Lewis. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jonathan Lewis</title>
		<link>http://jonathanlewis.wordpress.com/2010/12/27/index-rebuilds-3/#comment-38886</link>
		<dc:creator><![CDATA[Jonathan Lewis]]></dc:creator>
		<pubDate>Mon, 27 Dec 2010 19:51:31 +0000</pubDate>
		<guid isPermaLink="false">http://jonathanlewis.wordpress.com/?p=5252#comment-38886</guid>
		<description><![CDATA[Charles,

I&#039;ve just used the feedback page on Doc Id 989093.1 to point out the ambiguity in the phrasing of the note at that point. A better introductory line would have been something like: &quot;The most common claims used to justify rebuilding indexes are:&quot;... The next paragraph starting &quot;In fact ... &quot; then flows more readily as the correction to the claims.

Doc ID 989186.1 is pretty good - it seems to have taken a copy of a pair of scripts I published around August/September 2004, added a couple of enhancements, and folded them into a PL/SQL framework.  (See: http://www.jlcomp.demon.co.uk/index_efficiency.html and http://www.jlcomp.demon.co.uk/index_efficiency_2.html )  (The URLs also feature in the list of &quot;Pages&quot; to the right as: &quot;Index Efficiency 3&quot; and &quot;Index Sizing&quot;.)

I&#039;m not keen on the idea of using the &lt;em&gt;&lt;strong&gt;sys_op_lbid&lt;/strong&gt;&lt;/em&gt; scan on every index in a schema/database, though - it&#039;s a bit brutal on I/O and CPU.]]></description>
		<content:encoded><![CDATA[<p>Charles,</p>
<p>I&#8217;ve just used the feedback page on Doc Id 989093.1 to point out the ambiguity in the phrasing of the note at that point. A better introductory line would have been something like: &#8220;The most common claims used to justify rebuilding indexes are:&#8221;&#8230; The next paragraph starting &#8220;In fact &#8230; &#8221; then flows more readily as the correction to the claims.</p>
<p>Doc ID 989186.1 is pretty good &#8211; it seems to have taken a copy of a pair of scripts I published around August/September 2004, added a couple of enhancements, and folded them into a PL/SQL framework.  (See: <a href="http://www.jlcomp.demon.co.uk/index_efficiency.html" rel="nofollow">http://www.jlcomp.demon.co.uk/index_efficiency.html</a> and <a href="http://www.jlcomp.demon.co.uk/index_efficiency_2.html" rel="nofollow">http://www.jlcomp.demon.co.uk/index_efficiency_2.html</a> )  (The URLs also feature in the list of &#8220;Pages&#8221; to the right as: &#8220;Index Efficiency 3&#8243; and &#8220;Index Sizing&#8221;.)</p>
<p>I&#8217;m not keen on the idea of using the <em><strong>sys_op_lbid</strong></em> scan on every index in a schema/database, though &#8211; it&#8217;s a bit brutal on I/O and CPU.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jonathan Lewis</title>
		<link>http://jonathanlewis.wordpress.com/2010/12/27/index-rebuilds-3/#comment-38885</link>
		<dc:creator><![CDATA[Jonathan Lewis]]></dc:creator>
		<pubDate>Mon, 27 Dec 2010 19:42:29 +0000</pubDate>
		<guid isPermaLink="false">http://jonathanlewis.wordpress.com/?p=5252#comment-38885</guid>
		<description><![CDATA[Sync,

I don&#039;t like describing a complex issue in a single sentence - it makes it too easy for people to jump to the wrong conclusions.

It is often the case that (a) rebuilds are a waste of time and (b) when they are not a waste of time then a &lt;em&gt;&lt;strong&gt;coalesce&lt;/strong&gt;&lt;/em&gt; is a more sensible option than a rebuild - but if you&#039;re thinking about changing every line of code that reads &lt;em&gt;&quot;alter index ... rebuild&quot;&lt;/em&gt; to use a coalesce instead, take a close look at the penultimate line of the MOS note (my emphasis): &lt;i&gt;&quot;it is strongly advised not to rebuild indexes on a regular basis but instead &lt;b&gt;use proper diagnostics&lt;/b&gt;.&quot; &lt;/i&gt;


If you follow the &quot;Further reading on rebuilding indexes&quot; link at the end of the article you will find a note I have made about the cost of the coalesce command.]]></description>
		<content:encoded><![CDATA[<p>Sync,</p>
<p>I don&#8217;t like describing a complex issue in a single sentence &#8211; it makes it too easy for people to jump to the wrong conclusions.</p>
<p>It is often the case that (a) rebuilds are a waste of time and (b) when they are not a waste of time then a <em><strong>coalesce</strong></em> is a more sensible option than a rebuild &#8211; but if you&#8217;re thinking about changing every line of code that reads <em>&#8220;alter index &#8230; rebuild&#8221;</em> to use a coalesce instead, take a close look at the penultimate line of the MOS note (my emphasis): <i>&#8220;it is strongly advised not to rebuild indexes on a regular basis but instead <b>use proper diagnostics</b>.&#8221; </i></p>
<p>If you follow the &#8220;Further reading on rebuilding indexes&#8221; link at the end of the article you will find a note I have made about the cost of the coalesce command.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Charles Hooper</title>
		<link>http://jonathanlewis.wordpress.com/2010/12/27/index-rebuilds-3/#comment-38883</link>
		<dc:creator><![CDATA[Charles Hooper]]></dc:creator>
		<pubDate>Mon, 27 Dec 2010 14:51:51 +0000</pubDate>
		<guid isPermaLink="false">http://jonathanlewis.wordpress.com/?p=5252#comment-38883</guid>
		<description><![CDATA[Sync,

Metalink (MOS) Doc ID 122008.1 was mentioned in a recently release book that I reviewed.  My book review included the following regarding that mention:
&quot;Page 726 states to check Metalink (MOS) Doc ID 122008.1 for “the officially authorized script to detect indexes that benefit from rebuilding.”  That Metalink article states that the criteria is not valid and the script has been revised to meet “current standards and functionality.”  That means that the suggested criteria for rebuilding that is printed in the book regarding 20% or more of deleted index entries or a depth of more than 4 levels is invalid, as had previously been pointed out to the book author as invalid in a couple of OTN discussion threads (reference1 reference2 reference3)&quot;
One of Jonathan&#039;s comments in June 2008 apparently played a role in the removal of the original version of Doc ID 122008.1, see:
http://forums.oracle.com/forums/thread.jspa?messageID=4505978

I think that Doc ID 989093.1 contains potentially misleading information if someone were to quickly read that Doc ID - I think that the maintainer should better clarify that the common reasons for rebuilding indexes &quot;Indexes are often rebuilt on a regular basis&quot;, &quot;clustering factor becomes out of sync&quot;, &quot;index becomes fragmented&quot; are in fact refuted by the Doc ID and not listed as justifications for rebuilding indexes.

Doc ID 989186.1 is a bit interesting as it does not use the ANALYZE INDEX command.  Maybe I need to spend a little more time looking at that script to determine the usefulness of the script.]]></description>
		<content:encoded><![CDATA[<p>Sync,</p>
<p>Metalink (MOS) Doc ID 122008.1 was mentioned in a recently release book that I reviewed.  My book review included the following regarding that mention:<br />
&#8220;Page 726 states to check Metalink (MOS) Doc ID 122008.1 for “the officially authorized script to detect indexes that benefit from rebuilding.”  That Metalink article states that the criteria is not valid and the script has been revised to meet “current standards and functionality.”  That means that the suggested criteria for rebuilding that is printed in the book regarding 20% or more of deleted index entries or a depth of more than 4 levels is invalid, as had previously been pointed out to the book author as invalid in a couple of OTN discussion threads (reference1 reference2 reference3)&#8221;<br />
One of Jonathan&#8217;s comments in June 2008 apparently played a role in the removal of the original version of Doc ID 122008.1, see:<br />
<a href="http://forums.oracle.com/forums/thread.jspa?messageID=4505978" rel="nofollow">http://forums.oracle.com/forums/thread.jspa?messageID=4505978</a></p>
<p>I think that Doc ID 989093.1 contains potentially misleading information if someone were to quickly read that Doc ID &#8211; I think that the maintainer should better clarify that the common reasons for rebuilding indexes &#8220;Indexes are often rebuilt on a regular basis&#8221;, &#8220;clustering factor becomes out of sync&#8221;, &#8220;index becomes fragmented&#8221; are in fact refuted by the Doc ID and not listed as justifications for rebuilding indexes.</p>
<p>Doc ID 989186.1 is a bit interesting as it does not use the ANALYZE INDEX command.  Maybe I need to spend a little more time looking at that script to determine the usefulness of the script.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: sync</title>
		<link>http://jonathanlewis.wordpress.com/2010/12/27/index-rebuilds-3/#comment-38881</link>
		<dc:creator><![CDATA[sync]]></dc:creator>
		<pubDate>Mon, 27 Dec 2010 11:01:08 +0000</pubDate>
		<guid isPermaLink="false">http://jonathanlewis.wordpress.com/?p=5252#comment-38881</guid>
		<description><![CDATA[Hi, Jonathan

It&#039;s cool, learned it.

Notes 122008.1, 989093.1, 989186.1 are available for Oracle&#039;s idea about rebuilding index.
I have a question after reading note 989093.1: as long as the blevel for particular index is not high, we can always use &quot;coalesce&quot; to pack the space never reused. Is it correct?

Thanks
Sync]]></description>
		<content:encoded><![CDATA[<p>Hi, Jonathan</p>
<p>It&#8217;s cool, learned it.</p>
<p>Notes 122008.1, 989093.1, 989186.1 are available for Oracle&#8217;s idea about rebuilding index.<br />
I have a question after reading note 989093.1: as long as the blevel for particular index is not high, we can always use &#8220;coalesce&#8221; to pack the space never reused. Is it correct?</p>
<p>Thanks<br />
Sync</p>
]]></content:encoded>
	</item>
</channel>
</rss>
