<?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: Cardinality feedback to resolve a Cache buffers chains latch contention issue</title>
	<atom:link href="http://orainternals.wordpress.com/2009/01/02/cardinality-feedback-to-resolve-a-cache-buffers-chains-latch-contention-issue/feed/" rel="self" type="application/rss+xml" />
	<link>http://orainternals.wordpress.com/2009/01/02/cardinality-feedback-to-resolve-a-cache-buffers-chains-latch-contention-issue/</link>
	<description>Discussions about Oracle performance tuning, RAC, Oracle internal &#38; E-business suite.</description>
	<lastBuildDate>Sun, 19 May 2013 12:13:20 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: http://mensengagementrings.ca</title>
		<link>http://orainternals.wordpress.com/2009/01/02/cardinality-feedback-to-resolve-a-cache-buffers-chains-latch-contention-issue/#comment-1351</link>
		<dc:creator><![CDATA[http://mensengagementrings.ca]]></dc:creator>
		<pubDate>Sun, 18 Mar 2012 21:07:19 +0000</pubDate>
		<guid isPermaLink="false">http://orainternals.wordpress.com/?p=240#comment-1351</guid>
		<description><![CDATA[I am glad to be one of the visitants on this outstanding web site (:, thank you for putting up.]]></description>
		<content:encoded><![CDATA[<p>I am glad to be one of the visitants on this outstanding web site (:, thank you for putting up.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alexwebmaster</title>
		<link>http://orainternals.wordpress.com/2009/01/02/cardinality-feedback-to-resolve-a-cache-buffers-chains-latch-contention-issue/#comment-222</link>
		<dc:creator><![CDATA[Alexwebmaster]]></dc:creator>
		<pubDate>Tue, 03 Mar 2009 12:38:26 +0000</pubDate>
		<guid isPermaLink="false">http://orainternals.wordpress.com/?p=240#comment-222</guid>
		<description><![CDATA[Hello webmaster 
I would like to share with you a link to your site 
write me here preonrelt@mail.ru]]></description>
		<content:encoded><![CDATA[<p>Hello webmaster<br />
I would like to share with you a link to your site<br />
write me here <a href="mailto:preonrelt@mail.ru">preonrelt@mail.ru</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: orainternals</title>
		<link>http://orainternals.wordpress.com/2009/01/02/cardinality-feedback-to-resolve-a-cache-buffers-chains-latch-contention-issue/#comment-154</link>
		<dc:creator><![CDATA[orainternals]]></dc:creator>
		<pubDate>Wed, 07 Jan 2009 14:54:05 +0000</pubDate>
		<guid isPermaLink="false">http://orainternals.wordpress.com/?p=240#comment-154</guid>
		<description><![CDATA[Hello lascoltodelvenerdi
   
   Thanks for reading my blog. 
   
   Core of this blog entry is concentrating on root cause analysis for latch contention. SQL plan change is the root cause and cardinality feedback comes in to picture to answer why CBO chose a different plan.

   Yes, we were fortunate enough to have older plan for a quick comparison. Of course, there are other ways to achieve this result i.e. reviewing 10053 trace, export/import of older statistics to development, review of statspack plans, comparing real cardinality and estimates etc.

   Hypothetically speaking, If a short-table has grown to bigger one [ and caused this issue], then we would have resolved it a) by importing older statistics [ and thereby relieving immediate pressure upon us] b) then, analyzing this SQL further in the production copy for a permanent solution. 

Cheers
Riyaj]]></description>
		<content:encoded><![CDATA[<p>Hello lascoltodelvenerdi</p>
<p>   Thanks for reading my blog. </p>
<p>   Core of this blog entry is concentrating on root cause analysis for latch contention. SQL plan change is the root cause and cardinality feedback comes in to picture to answer why CBO chose a different plan.</p>
<p>   Yes, we were fortunate enough to have older plan for a quick comparison. Of course, there are other ways to achieve this result i.e. reviewing 10053 trace, export/import of older statistics to development, review of statspack plans, comparing real cardinality and estimates etc.</p>
<p>   Hypothetically speaking, If a short-table has grown to bigger one [ and caused this issue], then we would have resolved it a) by importing older statistics [ and thereby relieving immediate pressure upon us] b) then, analyzing this SQL further in the production copy for a permanent solution. </p>
<p>Cheers<br />
Riyaj</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: lascoltodelvenerdi</title>
		<link>http://orainternals.wordpress.com/2009/01/02/cardinality-feedback-to-resolve-a-cache-buffers-chains-latch-contention-issue/#comment-151</link>
		<dc:creator><![CDATA[lascoltodelvenerdi]]></dc:creator>
		<pubDate>Wed, 07 Jan 2009 13:55:29 +0000</pubDate>
		<guid isPermaLink="false">http://orainternals.wordpress.com/?p=240#comment-151</guid>
		<description><![CDATA[Well, the key to the problem, seams to be the use of old development environment.

If you were not so lucky...the work would be a bit harder. You should check e estimate (from the analyze) and real cardinality of all the tables in query.

Am I right?

Another problem could have been a short-table that become a &quot;big&quot; one. In which case you have to rework the query or rethink some Oracle parameters.

Am I right?]]></description>
		<content:encoded><![CDATA[<p>Well, the key to the problem, seams to be the use of old development environment.</p>
<p>If you were not so lucky&#8230;the work would be a bit harder. You should check e estimate (from the analyze) and real cardinality of all the tables in query.</p>
<p>Am I right?</p>
<p>Another problem could have been a short-table that become a &#8220;big&#8221; one. In which case you have to rework the query or rethink some Oracle parameters.</p>
<p>Am I right?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
