"gc buffer busy" wait during RAC Benchmark ?

From: VIVEK_SHARMA <VIVEK_SHARMA_at_infosys.com>
Date: Tue, 27 Feb 2007 18:26:42 +0530
Message-ID: <BBD944BCAC3AB4499DFBAFB1D8AF302002A4996E@BLRKECMSG11.ad.infosys.com>

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?

Top 5 Timed Events
Avg %Total

---

wait Call

Event                                            Waits    Time (s)

(ms) Time

• ------------ ----------- ------ ------

CPU time                                                     6,557

44.7

gc buffer busy                                 188,726       3,845

20 26.2

gc current block busy                           46,827       1,213

26 8.3

enq: TX - index contention                      34,055       1,094

32 7.5

gc current block 2-way                         451,989         360

1 2.5

---

Configuration

10gR2

Solaris 10

Veritas CFS 5.0

Banking Product

Will Share Statspack etc with anybody

Cheers

• CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** -- http://www.freelists.org/webpage/oracle-l

Received on Tue Feb 27 2007 - 06:56:42 CST