Re: "gc buffer busy" wait during RAC Benchmark ?

  • From: Mladen Gogala <mgogala@xxxxxxxxxxx>
  • To: VIVEK_SHARMA@xxxxxxxxxxx
  • Date: Tue, 27 Feb 2007 16:54:18 -0500



During internal 2 Node RAC Benchmark OLTP Nature Transaction Runs, following are the TOP Events from 2 Statspack.

From the *Manual*:-

“The V$|SESSION_WAIT| view to identify objects and data blocks with contention. The gc wait events contain the file and block number for a block request in p1 and p2, respectively. An additional segment statistic, *gc buffer busy*, has been added to quickly determine the "busy" objects without recourse to the query on V$SESSION_WAIT mentioned earlier.”

Qs 1) How can the “gc buffer busy” wait be reduced after identifying the respective “busy” Objects?

Qs 2) Will Table Partitioning help?

Qs 3) Should Transactions be grouped Logically so that Transactions Hit different Data Blocks on the 2 Nodes?

Vivek, "GC" stands for "global cache". The secret is so called "functional partitioning", the practice that groups the applications accessing the same objects on the same node. Oracle 10G is much, much better with synchronization then the OPS was, thanks to BWR, 2 phase recovery introduced in Oracle9i and PI (past images) but it is still much more expensive to acquire lock on a global buffer then to acquire a lock on a local buffer. Dynamic re-mastering will even make the node using a resource (like an object, for instance) a master for that resource, but it will not prevent
delays if the resource is frequently used from other nodes.
The best practice is to group everything that regularly accesses an object to a single node and allow occasional
access from the other nodes.

Mladen Gogala
Sr. Oracle DBA
Video Monitoring Systems
1500 Broadway
New York City, NY 10036
Phone: (212) 329-5201
Email: mgogala@xxxxxxxxxxx

fn:Mladen Gogala
tel;work:(212) 329-5201

Other related posts: