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
VIVEK_SHARMA wrote:
Folks
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
begin:vcard
fn:Mladen Gogala
n:Gogala;Mladen
email;internet:mgogala@xxxxxxxxxxx
tel;work:(212) 329-5201
x-mozilla-html:TRUE
version:2.1
end:vcard
Other related posts:
