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, p |
- runaway oracle.exe thread on NT / W2K Jeffrey Beckstrom
- RE: runaway oracle.exe thread on NT / W2K Reardon, Bruce (CALBBAY)
- RE: runaway oracle.exe thread on NT / W2K Michael P Sale
- RE: runaway oracle.exe thread on NT / W2K Jeffrey Beckstrom
- Jeffrey Beckstrom