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_at_gmail.com> To: BLock_at_dvfs.com 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