Problem is that can not reproduce on demand.  Yesterday, we were doing the wrap up for PO G patches, i.e. generate messagess, flexfields, etc.  Experienced the problem, tried redoing the same tasks and worked. 
 
Then after bringin up concurrent manager, lots of compile flexfield requests started (we had upped number of standard managers from 6 to 30).  Since CPU at 100%, kept lowering number of standard managers from 30 to 20 and eventually back to 6.  When requests done noticed cpu at 50%.  Stopped everything and still at 50% due to a thread. 
 
Have been running 8.1.7.3.2 on another dev database for about a month with no problems, but there also had the problem but don't recall when since at the time thought it was a fluke.  Did not get concerned until happened again (couple times) on another server and that's when openned the TAR. 
 
Therefore, don't know how to reproduce but getting leary of moving it to production.
 
Jeffrey Beckstrom
Database Administrator
Greater Cleveland Regional Transit Authority
1240 W. 6th Street
Cleveland, Ohio 44113
(216) 781-4204

>>> [EMAIL PROTECTED] 6/6/02 7:31:32 PM >>>
If you cannot tie that thread to v$process then it is likely a problem with a background thread.
 
If you are using sqlnet expire time it creates 2 threads for each connection, the timer thread will not show up in v$process. There are also a few other threads that will not show up related to process management.
 
One approach:
Once you have a database instance with this problem that you are willing to crash you can attach to it with a debugger to get a look at what is up. The simple way to do this with little expertise is to use:
drwtsn32 -p <oracle.exe_pid#>
This will generate a dump file (given that you haven't reconfigured dr watson) that support can review (well, the BDE group can) for content. They'll need to know the EXACT version of the database you have as well as the OS version (including service packs and hot fixes) to get the right dbg symbols in place.

Regards,

Michael Sale
Author: Oracle9i for Windows(R) 2000 Tips & Techniques
http://www.amazon.com/exec/obidos/ASIN/0072194626

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jeffrey Beckstrom
Sent: Thursday, June 06, 2002 2:05 PM
To: Multiple recipients of list ORACLE-L
Subject: runaway oracle.exe thread on NT / W2K

This has now happened on 3 separeate boxes.  This has happened while putting on an Oracle Applications patch or in the last case, after starting the concurrent managers for 11i with a lot of requests scheduled to compile all of the flex fields.  In every instance, the thread id does not match anything in oracle.
 
We notice that box is using 50-100% cpu even though nothing is running.  Stop concurrent managers.  Terminate web sessions.  Exit all sqlplus sessions. 
 
Use pslist from sysinternals.com and it shows a running thread of oracle.exe using lots of user and kernal time.  This thread id is not shown in v$session/process!!!!
 
Oracle has not been of much help to date.
 
Even after doing a shutdown immediate, cpu is still high and thread is running.  Have to stop the service to get rid of it all.
 
We had been on 8.1.7.1.5 but upgraded to 8.1.7.3.2 since minimum for our Oracle Apps patches was 8.1.7.2.x just went to the latest and greatest since know eventually would be required.
 
Has anyone else seen anything like this.
 
Jeffrey Beckstrom
Database Administrator
Greater Cleveland Regional Transit Authority
1240 W. 6th Street
Cleveland, Ohio 44113
(216) 781-4204
p

Reply via email to