Although I am enjoying the guessing game, I would suggest using the _prelim connection and direct access. I didn't test on your version, so you might have to mess with it a bit.
To get a hanganalyze on a completely hung system: $ sqlplus /nolog SQL> set _prelim on SQL> connect / as sysdba SQL> oradebug setorapname pmon SQL> oradebug dump hanganalyze 1In the above example, you can specify any process that is getting CPU. You can find that with top or ps, and you can also specify it by O/S pid (oradebug setospid 12345).
You could also dump the contents of the wait interface or the ASH buffer to get information on the hang.
$ sqlplus /nolog SQL> set _prelim on SQL> connect / as sysdba SQL> oradebug setmypid SQL> oradebug direct_access enable trace SQL> oradebug direct_access disable reply SQL> oradebug direct_access set content_type = 'text/plain' SQL> oradebug direct_access select * from x$ksles SQL> oradebug direct_access select * from x$ash SQL> oradebug tracefile_nameFeel free to share to contents of either of these tracefiles from during a hang.
Jeremiah Wilton Blue Gecko, Inc. http://www.bluegecko.net On May 19, 2009, at 8:09 AM, Saad Khan wrote:
1) The oracle version is 10.2.0.12) The machine is up for 87 days. [Tao:Not sure if the bug applies here or no] 3) The Alert file was last updated on Apr. 11. And the last messages were normal logswitches and other stuff. Nothing very alarming4) I dont think the audit was ever turned on.5) There is plenty of space (in GBs) available in filesystems particularly ORACLE_HOME6) changePerm.sh is already run.