From oracle-l-bounce@freelists.org Thu Oct 28 08:47:20 2004 Return-Path: Received: from air189.startdedicated.com (root@localhost) by orafaq.com (8.11.6/8.11.6) with ESMTP id i9SDlKR13805 for ; Thu, 28 Oct 2004 08:47:20 -0500 X-ClientAddr: 206.53.239.180 Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180]) by air189.startdedicated.com (8.11.6/8.11.6) with ESMTP id i9SDlJI13798 for ; Thu, 28 Oct 2004 08:47:19 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 1D9C672E14E; Thu, 28 Oct 2004 08:53:31 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14093-75; Thu, 28 Oct 2004 08:53:31 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 7FE2872E11C; Thu, 28 Oct 2004 08:53:30 -0500 (EST) x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Subject: Interpreting global cache waits Date: Thu, 28 Oct 2004 09:51:48 -0400 Message-ID: <68A6331009FE4D428649E96192C1DAA306EBFF@corpwinexcl1.lifelinesys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Interpreting global cache waits Thread-Index: AcS89UVE5fJiSHStToWodCLyhHcDaw== From: "Finkelstein, Alec" To: X-archive-position: 11633 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: AFinkelstein@lifelinesys.com Precedence: normal Reply-To: AFinkelstein@lifelinesys.com X-list: oracle-l X-Virus-Scanned: by amavisd-new at freelists.org 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