<?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: gc buffer busy waits</title>
	<atom:link href="http://orainternals.wordpress.com/2010/09/27/gc-buffer-busy-waits/feed/" rel="self" type="application/rss+xml" />
	<link>http://orainternals.wordpress.com/2010/09/27/gc-buffer-busy-waits/</link>
	<description>Discussions about Oracle performance tuning, RAC, Oracle internal &#38; E-business suite.</description>
	<lastBuildDate>Sat, 11 May 2013 07:29:27 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Gc Buffer Busy Nightmare &#124; Emmanuel&#039;s Blog</title>
		<link>http://orainternals.wordpress.com/2010/09/27/gc-buffer-busy-waits/#comment-2008</link>
		<dc:creator><![CDATA[Gc Buffer Busy Nightmare &#124; Emmanuel&#039;s Blog]]></dc:creator>
		<pubDate>Tue, 26 Feb 2013 18:24:54 +0000</pubDate>
		<guid isPermaLink="false">http://orainternals.wordpress.com/?p=759#comment-2008</guid>
		<description><![CDATA[[...] http://orainternals.wordpress.com/2010/09/27/gc-buffer-busy-waits/ [...]]]></description>
		<content:encoded><![CDATA[<p>[...] <a href="http://orainternals.wordpress.com/2010/09/27/gc-buffer-busy-waits/" rel="nofollow">http://orainternals.wordpress.com/2010/09/27/gc-buffer-busy-waits/</a> [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Balaji</title>
		<link>http://orainternals.wordpress.com/2010/09/27/gc-buffer-busy-waits/#comment-1447</link>
		<dc:creator><![CDATA[Balaji]]></dc:creator>
		<pubDate>Wed, 23 May 2012 15:24:09 +0000</pubDate>
		<guid isPermaLink="false">http://orainternals.wordpress.com/?p=759#comment-1447</guid>
		<description><![CDATA[We are using ASSM and still see lots of header block contention (block class# 4) for a highly transactional table. What would be the reason for  the segment header block on an ASSM tablespace is involved in &quot;gc buffer busy acquire&quot; waits?

select count(*), current_block#, p3 from sys.wrh$_active_session_history
where snap_id between 50103 and 50111 and event_id=1912606394 and current_obj#=264167
group by  current_block#, p3
order by 1 desc

23673	30962		4
1715	39895560	9
610	38864392	9
398	30961		9

this is on a 6 node RAC and as you said the free blocks may not be evenly distributed and we don&#039;t have a way to add free extents to each instance( we tried to run allocate extents from each instance and not sure whether that is working or not)

Free blocks info Before the test
~~~~~~~~~~~~~~~~~~~~~~~~
&#124; total_bl&#124; total_by&#124; unused_bl&#124; unused_by&#124; last_used_extent_file_id&#124;last_used_extent_block_id&#124; last_used_block
&#124;  3971456&#124;325341675&#124;    131072&#124;1073741824&#124;                        9&#124;80230912&#124;            8192
.
&#124; unformatted_blocks&#124; unformatted_bytes&#124; fs1_bl&#124; fs1_by&#124; fs2_bl&#124; fs2_by&#124; fs3_bl&#124;fs3_by&#124; fs4_bl&#124; fs4_by&#124; full_bl&#124; full_by
&#124;             555440&#124;        4550164480&#124;      0&#124;      0&#124;   1158&#124;9486336&#124;144596&#124;1184530&#124; 321973&#124;2637602&#124; 2812972&#124;23043866

After the test
~~~~~~~~~~

&#124; total_bl&#124; total_by&#124; unused_bl&#124; unused_by&#124; last_used_extent_file_id&#124;last_used_extent_block_id&#124; last_used_block
&#124;  3971456&#124;325341675&#124;    131072&#124;1073741824&#124;                        9&#124;80230912&#124;            8192
.
&#124; unformatted_blocks&#124; unformatted_bytes&#124; fs1_bl&#124; fs1_by&#124; fs2_bl&#124; fs2_by&#124; fs3_bl&#124;fs3_by&#124; fs4_bl&#124; fs4_by&#124; full_bl&#124; full_by
&#124;             551824&#124;        4520542208&#124;      0&#124;      0&#124;    835&#124;6840320&#124;58187&#124;4766679&#124; 241664&#124;1979711&#124; 2983629&#124;24441888



As you can see the unused blocks has not changed in this case, but around 3600 unformatted blocks were formatted. When the blocks are formatted the ASSM would need to reset its LHWM? and that would need to modify the segment header block?


TIA
Balaji.]]></description>
		<content:encoded><![CDATA[<p>We are using ASSM and still see lots of header block contention (block class# 4) for a highly transactional table. What would be the reason for  the segment header block on an ASSM tablespace is involved in &#8220;gc buffer busy acquire&#8221; waits?</p>
<p>select count(*), current_block#, p3 from sys.wrh$_active_session_history<br />
where snap_id between 50103 and 50111 and event_id=1912606394 and current_obj#=264167<br />
group by  current_block#, p3<br />
order by 1 desc</p>
<p>23673	30962		4<br />
1715	39895560	9<br />
610	38864392	9<br />
398	30961		9</p>
<p>this is on a 6 node RAC and as you said the free blocks may not be evenly distributed and we don&#8217;t have a way to add free extents to each instance( we tried to run allocate extents from each instance and not sure whether that is working or not)</p>
<p>Free blocks info Before the test<br />
~~~~~~~~~~~~~~~~~~~~~~~~<br />
| total_bl| total_by| unused_bl| unused_by| last_used_extent_file_id|last_used_extent_block_id| last_used_block<br />
|  3971456|325341675|    131072|1073741824|                        9|80230912|            8192<br />
.<br />
| unformatted_blocks| unformatted_bytes| fs1_bl| fs1_by| fs2_bl| fs2_by| fs3_bl|fs3_by| fs4_bl| fs4_by| full_bl| full_by<br />
|             555440|        4550164480|      0|      0|   1158|9486336|144596|1184530| 321973|2637602| 2812972|23043866</p>
<p>After the test<br />
~~~~~~~~~~</p>
<p>| total_bl| total_by| unused_bl| unused_by| last_used_extent_file_id|last_used_extent_block_id| last_used_block<br />
|  3971456|325341675|    131072|1073741824|                        9|80230912|            8192<br />
.<br />
| unformatted_blocks| unformatted_bytes| fs1_bl| fs1_by| fs2_bl| fs2_by| fs3_bl|fs3_by| fs4_bl| fs4_by| full_bl| full_by<br />
|             551824|        4520542208|      0|      0|    835|6840320|58187|4766679| 241664|1979711| 2983629|24441888</p>
<p>As you can see the unused blocks has not changed in this case, but around 3600 unformatted blocks were formatted. When the blocks are formatted the ASSM would need to reset its LHWM? and that would need to modify the segment header block?</p>
<p>TIA<br />
Balaji.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: an</title>
		<link>http://orainternals.wordpress.com/2010/09/27/gc-buffer-busy-waits/#comment-947</link>
		<dc:creator><![CDATA[an]]></dc:creator>
		<pubDate>Wed, 21 Dec 2011 18:15:38 +0000</pubDate>
		<guid isPermaLink="false">http://orainternals.wordpress.com/?p=759#comment-947</guid>
		<description><![CDATA[Is there an email where I can ask you more detail questions?]]></description>
		<content:encoded><![CDATA[<p>Is there an email where I can ask you more detail questions?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: sql wildcard,sql wildcards,sql rollback,rollback sql,sql copy table,sql sum,sql mirroring,sum sql,sql cluster,sql server performance,truncate in sql,backup sql,backup sql database,backup sql server,sql performance,date functions in sql,sql over,truncate s</title>
		<link>http://orainternals.wordpress.com/2010/09/27/gc-buffer-busy-waits/#comment-766</link>
		<dc:creator><![CDATA[sql wildcard,sql wildcards,sql rollback,rollback sql,sql copy table,sql sum,sql mirroring,sum sql,sql cluster,sql server performance,truncate in sql,backup sql,backup sql database,backup sql server,sql performance,date functions in sql,sql over,truncate s]]></dc:creator>
		<pubDate>Sun, 25 Sep 2011 15:10:47 +0000</pubDate>
		<guid isPermaLink="false">http://orainternals.wordpress.com/?p=759#comment-766</guid>
		<description><![CDATA[&lt;strong&gt;sql wildcard,sql wildcards,sql rollback,rollback sql,sql copy table,sql sum,sql mirroring,sum sql,sql cluster,sql server performance,truncate in sql,backup sql,backup sql database,backup sql server,sql performance,date functions in sql,sql over,trunc...&lt;/strong&gt;

[...]gc buffer busy waits &#171; Oracle database internals by Riyaj[...]...]]></description>
		<content:encoded><![CDATA[<p><strong>sql wildcard,sql wildcards,sql rollback,rollback sql,sql copy table,sql sum,sql mirroring,sum sql,sql cluster,sql server performance,truncate in sql,backup sql,backup sql database,backup sql server,sql performance,date functions in sql,sql over,trunc&#8230;</strong></p>
<p>[...]gc buffer busy waits &laquo; Oracle database internals by Riyaj[...]&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: orainternals</title>
		<link>http://orainternals.wordpress.com/2010/09/27/gc-buffer-busy-waits/#comment-724</link>
		<dc:creator><![CDATA[orainternals]]></dc:creator>
		<pubDate>Thu, 07 Jul 2011 20:43:37 +0000</pubDate>
		<guid isPermaLink="false">http://orainternals.wordpress.com/?p=759#comment-724</guid>
		<description><![CDATA[Hello Sri
    High GC buffer busy waits means that there is higher concurrency at a buffer level. So, ASSM avoids just one type of gc buffer busy wait, which is freelists/freelist group based waits. 
    I may have to review an AWR report during when you have gc buffer busy waits to proceed further. If you don&#039;t mind, you can send me that, of course, you can block out machine name etc.

Thanks
Riyaj]]></description>
		<content:encoded><![CDATA[<p>Hello Sri<br />
    High GC buffer busy waits means that there is higher concurrency at a buffer level. So, ASSM avoids just one type of gc buffer busy wait, which is freelists/freelist group based waits.<br />
    I may have to review an AWR report during when you have gc buffer busy waits to proceed further. If you don&#8217;t mind, you can send me that, of course, you can block out machine name etc.</p>
<p>Thanks<br />
Riyaj</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: sri</title>
		<link>http://orainternals.wordpress.com/2010/09/27/gc-buffer-busy-waits/#comment-723</link>
		<dc:creator><![CDATA[sri]]></dc:creator>
		<pubDate>Thu, 07 Jul 2011 20:36:39 +0000</pubDate>
		<guid isPermaLink="false">http://orainternals.wordpress.com/?p=759#comment-723</guid>
		<description><![CDATA[We have ASSM but still it has high GC buffer busy waits.
Not sure what we can do about it as we already have ASSM, tried to increase freelists but it doesnt work with ASSM.]]></description>
		<content:encoded><![CDATA[<p>We have ASSM but still it has high GC buffer busy waits.<br />
Not sure what we can do about it as we already have ASSM, tried to increase freelists but it doesnt work with ASSM.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Lorea</title>
		<link>http://orainternals.wordpress.com/2010/09/27/gc-buffer-busy-waits/#comment-709</link>
		<dc:creator><![CDATA[Lorea]]></dc:creator>
		<pubDate>Tue, 07 Jun 2011 13:40:19 +0000</pubDate>
		<guid isPermaLink="false">http://orainternals.wordpress.com/?p=759#comment-709</guid>
		<description><![CDATA[Excellent. Thanks a lot for sharing.]]></description>
		<content:encoded><![CDATA[<p>Excellent. Thanks a lot for sharing.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: orainternals</title>
		<link>http://orainternals.wordpress.com/2010/09/27/gc-buffer-busy-waits/#comment-673</link>
		<dc:creator><![CDATA[orainternals]]></dc:creator>
		<pubDate>Wed, 02 Feb 2011 00:56:57 +0000</pubDate>
		<guid isPermaLink="false">http://orainternals.wordpress.com/?p=759#comment-673</guid>
		<description><![CDATA[Hello Justin
   Agreed. Licensing is one of the reason not to be able to use hash partitioning technique. 
   Yep, it is the cost/benefit justification that will decide, if the site doesn&#039;t have partitioning option licensed: &quot;Would you want to pay more partitioning options or live with the ill-effects of reverse key indexes?&quot; is a good question. 
   
Cheers
Riyaj]]></description>
		<content:encoded><![CDATA[<p>Hello Justin<br />
   Agreed. Licensing is one of the reason not to be able to use hash partitioning technique.<br />
   Yep, it is the cost/benefit justification that will decide, if the site doesn&#8217;t have partitioning option licensed: &#8220;Would you want to pay more partitioning options or live with the ill-effects of reverse key indexes?&#8221; is a good question. </p>
<p>Cheers<br />
Riyaj</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Justin Cave</title>
		<link>http://orainternals.wordpress.com/2010/09/27/gc-buffer-busy-waits/#comment-672</link>
		<dc:creator><![CDATA[Justin Cave]]></dc:creator>
		<pubDate>Tue, 01 Feb 2011 22:34:01 +0000</pubDate>
		<guid isPermaLink="false">http://orainternals.wordpress.com/?p=759#comment-672</guid>
		<description><![CDATA[When you say &quot;there aren’t many reasons to use reverse key indexes in 10g,&quot; isn&#039;t that overlooking a rather large cost issue?  In order to partition the index, you would need to have licensed the partitioning option which is quite expensive.  At least in my experience, the databases that are experiencing this sort of issue are OLTP systems where organizations are unlikely to have already licensed partitioning.

From a purely technical perspective, I&#039;d certainly rather have a hash-partitioned index than a reverse key index.  But for most systems, I&#039;d be hard pressed to come up with a cost/benefit justification for licensing partitioning rather than using a reverse key index.]]></description>
		<content:encoded><![CDATA[<p>When you say &#8220;there aren’t many reasons to use reverse key indexes in 10g,&#8221; isn&#8217;t that overlooking a rather large cost issue?  In order to partition the index, you would need to have licensed the partitioning option which is quite expensive.  At least in my experience, the databases that are experiencing this sort of issue are OLTP systems where organizations are unlikely to have already licensed partitioning.</p>
<p>From a purely technical perspective, I&#8217;d certainly rather have a hash-partitioned index than a reverse key index.  But for most systems, I&#8217;d be hard pressed to come up with a cost/benefit justification for licensing partitioning rather than using a reverse key index.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: State of Data Last Week &#8211; Oct 02 &#171; Dr Data&#039;s Blog</title>
		<link>http://orainternals.wordpress.com/2010/09/27/gc-buffer-busy-waits/#comment-571</link>
		<dc:creator><![CDATA[State of Data Last Week &#8211; Oct 02 &#171; Dr Data&#039;s Blog]]></dc:creator>
		<pubDate>Sun, 03 Oct 2010 20:36:32 +0000</pubDate>
		<guid isPermaLink="false">http://orainternals.wordpress.com/?p=759#comment-571</guid>
		<description><![CDATA[[...] to read the same block another node is writing at the same time processed in Oracle RAC – the “gc buffer busy waits” and the tactics to address it really explained [...]]]></description>
		<content:encoded><![CDATA[<p>[...] to read the same block another node is writing at the same time processed in Oracle RAC – the “gc buffer busy waits” and the tactics to address it really explained [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
