Re: Monitor contention

During some recent RAC scalability testing we saw a lot of GC type waits during our transaction performance runs after adding a 4'th node into the cluster. The issue turned out to be a lot of contention on an index for a very high insert table (logging). We turned the logging feature off and it all went away. Performance papers suggest tuning the index storage parameters to allow for fewer entries per block so that the nodes are not all going after the same block. It is interesting that the problem did not show up until the 4'th node came on, and the problem was very immediate and severe, I guess is has something to do with the mechanics of the interconnect and more than 3 nodes.

I think there is some benefit to taking your top N SQL's and knowing what the average elapsed time per execute is. If a problem shows up it can be beneficial to examine this data. I think the other responses are right on, but I have always found great benefit in having a lot of historical data on hand for analysis.

• E

On 5/11/07, BLock_at_dvfs.com <BLock_at_dvfs.com> wrote:
>
>
> What kinds of contention do we still need to look for in a RAC and SAN
> environment?
>
>
> Thanks
>
> Brian Lock
> DBA - East Campus
>
>

--
http://www.freelists.org/webpage/oracle-l