Re: Monitor contention

I think this may be a case of correlation without causation. Changing an index from logging to nologging would have no affect on conventional inserts. 

To quote the documentation:
http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14231/tables.htm#sthref2199
<quote>
The NOLOGGING clause also specifies that subsequent direct loads using SQL*Loader and direct load INSERT operations are not logged. Subsequent DML statements (UPDATE, DELETE, and conventional path insert) are unaffected by the NOLOGGING attribute of the table and generate redo. 
</quote>

Regards,

Greg Rahn
http://structureddata.org

-------- Original Message --------
Subject: Monitor contention
From: "Ethan Post" <post.ethan@xxxxxxxxx>
To: BLock@xxxxxxxx
Date: 5/15/2007 8:44 AM
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


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

Other related posts: