Re: help: high "gc busy buffer"

From: onedbguru <>
Date: Tue, 11 Jan 2011 19:03:15 -0800 (PST)
Message-ID: <>

On Jan 11, 5:15 pm, charles <> wrote:
> Dear group,
> We are using Oracle 10g on linux RAC with 4 nodes.  We have a small
> table, no more than 300 rows,  but most people will update/delete/
> insert on it during load testing.  And ASH report shows it is the
> cause of this contention.
> EVENT                                 CNT
> ------------------------------ ----------
> gc current retry                        4
> gc current grant 2-way                 31
> gc current request                     47
> gc cr request                          66
> gc cr multi block request              69
> gc current block busy                  79
> gc cr grant 2-way                      81
> gc current grant busy                 113
> gc current block 2-way                416
> gc cr block busy                      420
> gc cr block 2-way                     568
> gc buffer busy                       6448
> All the "gc buffer busy" points to one small table, no index/triggers
> on this table, which 2000 update, 1800 insert, 1600 select.  The table
> is created in a ASSM tablespace, so i guess freelist is not going to
> help here.
> Could somebody give me some advice?
> Thanks

The first question to ask yourself, is the load testing a realistic load test. Some of the win-runners and other load testing software cannot (IMProfessionalO) accurately simulate real-life day to day workloads.

What was the timeframe for these statistics? 1 minute? 1hr? I am curious as to how you have a 300 row table that does 1800 inserts. 2000 updates - again what timeframe. As for the number, it does not seem that bad to me... What is the effect of these buffer busy waits? Are users actually waiting for a response in the app?

If there are at most 300 rows with 1800 delete/inserts and 2000 updates, you may want to do another transactional analysis and ask the question as to why are you doing it this way and is there a better way to achieve the end goal - whatever that may be. Received on Tue Jan 11 2011 - 21:03:15 CST

Original text of this message