-
Hi,
Something odd happened to one of our databases. Someone started up an old instance that has a history of running fine. The same day the instance was started, I received a complaint that the pmon process was taking close to three-quarters of the Unix server's CPU capacity. Has anyone had this happen? I looked in the alert log...nothing. I looked for any .trc files ... no files. Why could this be happening? Could the instance have been started abnormally and pmon feels the need to go overtime in cleaning up stuff on the server?
Thanks,
Zoey
-
Hi,
If u have shutdown the database in abort command,then naturally SMON process will perform instance recovery.PMON comes into the picture only when there is abnormal termination of the user processes.PMON will take some time cleaning up the resources,rolling back the uncomitted transactions.....
I dont think why PMON is taking so much time.Mostly instance recovery is done by SMON.
In case of nay help please be free to ask me at [email protected]
Regards,
Rohit Nirkhe,Oracle DBA,OCP 8i
[email protected]
-
investigate
Hi, 27th May 2001 21:01 hrs chennai
Please query this from your instance which had problem and let me have a look in this thread
SELECT * FROM V$SYSTEM_EVENT ORDER BY TIME_WAITED;
Cheers
Padmam
-
Hi
look at Doc ID: 114343.1 on the metalink.
The database has the following qualities:
-- fairly large number of concurrent transactions
-- audit_trail = db
-- some of the shadow processes are dying (cleaning up dead processes) This
can occur because session idle time is timing out.
The only way to get things going again is to do a shutdown abort and restart
the instance.
Solution Description
--------------------
This is [BUG:559734]. This is fixed in 8.0.6.
The workaround given for this issue is to set audit_trail = none.
hope this helps
