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_at_vmsinfo.com
--
http://www.freelists.org/webpage/oracle-l
Received on Tue Feb 27 2007 - 15:54:18 CST
