RE: High oracle cpu on Windows 2000 w/ FailSafe 3.1.2 after patch applied for Security Alert #64
- From: "Mark Strickland" <mstrickland@xxxxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 12 Oct 2004 10:01:33 -0700
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@xxxxxxxxxxxxx
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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
