Re: Interpreting global cache waits

Alec,

        In version 8i (not sure about 9 or 10), if you are using OPS for 
anything other than failover (only 1 instance running at a time), then you 
have to very carefully design your application.  It is very expensive to 
handle locking and latching across nodes.  Read Oracle Parallel Server 
concepts, chapter 5 Parallel Cache management (the cost of locks and 
coordination of locking mechanisms by DLM are 2 good sections).  The 2 
solutions you mention may help to alleviate some of the contention, but if 
the application isn't specifically designed for this (minimize users 
updating the same table from more than 1 instance), you are fighting the 
laws of physics.


HTH,
Mike



"Finkelstein, Alec" <AFinkelstein@xxxxxxxxxxxxxxx> 
Sent by: oracle-l-bounce@xxxxxxxxxxxxx
10/28/2004 09:51 AM
Please respond to
AFinkelstein@xxxxxxxxxxxxxxx


To
<oracle-l@xxxxxxxxxxxxx>
cc

Subject
Interpreting global cache waits






Hello,

We have 2-node OPS cluster (8.1.7.4), mostly OLTP. The system is
(predictably) susceptible to high CPU saturations. From the 10046
traces I see PCM lock contention for indexes of hot (high
updates/inserts tables):

global cache lock null to x
buffer busy due to global cache
global cache lock open x

I'm planning to tackle this by doing hash partitioning and splitting
the sequence ranges on the nodes. But my question is as follows: how
do I prove that the "problem" is the system being starved of CPU / DLM
resources (ie not storage)? That is to say, are the waits indication
of storage waits, slow cluster interconnect, or saturated CPUs? E.g.
when DLM is waiting to convert consistent read PCM lock to exclusive
("global cache lock null to x"), presumably it's waiting for the other
instance to release the block. But what is taking the time - high CPU=20
queues or the fact that the other instance is waiting on something else?

Thanks!

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


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

Other related posts: