From oracle-l-bounce@freelists.org Fri Oct 15 15:52:27 2004 Return-Path: Received: from air189.startdedicated.com (root@localhost) by orafaq.com (8.11.6/8.11.6) with ESMTP id i9FKqQK18123 for ; Fri, 15 Oct 2004 15:52:26 -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 i9FKqQI18118 for ; Fri, 15 Oct 2004 15:52:26 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 5D6D072E45D; Fri, 15 Oct 2004 15:58:34 -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 18428-55; Fri, 15 Oct 2004 15:58:34 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id B95E872E45C; Fri, 15 Oct 2004 15:58:33 -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: The Outcome: High oracle cpu on Windows 2000 w/ FailSafe 3.1.2 after patch applied for Security Alert #64 Date: Fri, 15 Oct 2004 13:56:48 -0700 Message-ID: <63A70CA32CEF354892F78EADB13D3297032631C2@seaems005c> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The Outcome: High oracle cpu on Windows 2000 w/ FailSafe 3.1.2 after patch applied for Security Alert #64 Thread-Index: AcStg217DUWFKywxQY+2n7xof6ryawAB11+gALxgxqAAnxiEQA== From: "Mark Strickland" To: X-OriginalArrivalTime: 15 Oct 2004 20:56:48.0694 (UTC) FILETIME=[7CFF8D60:01C4B2F9] X-archive-position: 11190 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: mstrickland@drugstore.com Precedence: normal Reply-To: mstrickland@drugstore.com X-list: oracle-l X-Virus-Scanned: by amavisd-new at freelists.org Thanks to Jeffrey Beckstrom's sharing of a similar experience, we appear to have identified a bug and a workaround. I turned off Dead Connection Detection and the problem automagically went away. The psychotic thread never showed up in v$process or v$bgprocess, so I must conclude that it was a DCD thread. For some reason, applying patch #3820881 on a FailSafe 3.1.2 cluster with Oracle 8.1.7.4 is a bad combination. Thanks Jeffrey! Mark Strickland Seattle, WA -----Original Message----- From: Mark Strickland=20 Sent: Tuesday, October 12, 2004 10:02 AM To: 'oracle-l@freelists.org' Subject: RE: High oracle cpu on Windows 2000 w/ FailSafe 3.1.2 after patch applied for Security Alert #64 I installed qslice on the server and I can see which thread within the oracle process is consuming the cpu. However, I can't match it to an Oracle session within the database. That one thread is consuming 24% of the cpu right now and the consumption will grow over the next couple of days until the server is hosed. I searched MetaLink. Here's the query I'm using: select to_char(p.spid,'XXXX') "Thread ID", b.name "Background Process", s.username "User Name", s.osuser "OS User", s.status "STATUS",=20 s.sid "Session ID",=20 s.serial# "Serial No.",=20 s.program "OS Program" =20 from v$process p,=20 v$bgprocess b,=20 v$session s =20 where s.paddr =3D p.addr and=20 b.paddr(+) =3D p.addr; Any ideas? Perhaps it is a thread related to FailSafe? We may backout the patch to see if things return to normal. I have an open TAR and the analyst hasn't reported any hairballs with regards to applying the patch in a FailSafe environment. Thx! Mark -----Original Message----- From: Mark Strickland=20 Sent: Friday, October 08, 2004 4:12 PM To: oracle-l@freelists.org Subject: High oracle cpu on Windows 2000 w/ FailSafe 3.1.2 after patch applied for Security Alert #64 I'm trying to figure out why the oracle process on a Windows 2000 server is consuming 98% of the cpu. Patch #3820881 for Oracle Security Alert #68 was recently applied. This is a 2-node FailSafe 3.1.2 cluster running Oracle 8.1.7.4. Wait events are all "idle" events for the Oracle background processes and "SQL*Net message from client" (with one "to client") for the user sessions. Unfortunately, timed_statistics is set to false in this database so I can't see which sessions are consuming cpu. Once I get the server to respond so I can issue a query in SQL*Plus, query results come back quickly. Navigating within Windows between SQL*Plus and, say, Task Manager, is glacially slow. Ideas? Mark Strickland Seattle, WA -- http://www.freelists.org/webpage/oracle-l