RE: DATABASE HANGS WITH SHUTDOWN IMMEDIATE
- From: "Powell, Mark D" <mark.powell@xxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 28 Apr 2006 09:20:07 -0400
We had multiple hanging problems on 9.2.0.4 RAC running on AIX 5.2.
9.2.0.5 and later 9.2.0.6 were better though we have had a hang or two.
I can only remember the details for two of the three separate bugs that
we hit and which support identified as the cause of our hung database.
The first seems unlikely since you are using one-node RAC. In a RAC
environment if too many sessions attempt to log on too concurrently the
database can develop a problem trying to access the sequence generator
behind v$session.audsid. Just increase the cache size from 20 to 1,000.
(Support recommended 10k but that seems a little like overkill)
The second was identified as not being a bug but a deadlock occurred on
the rdbms base tables. Oracle is apparently unable to identify this
condition like it can for user table access so it does not kill one of
the sessions and roll it back automatically. However, you can however
see the problem in the hang analyze dump.
We hit at least one other identified bug but I do not remember the
details at all.
Next time before issuing any shutdown command run a hang analyze which
will give you something to look at. If you cannot spot the problem in
the trace then you upload the trace to support to give them something to
work with.
HTH -- Mark D Powell --
________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Ahmed Ullah
Sent: Thursday, April 27, 2006 6:36 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: DATABASE HANGS WITH SHUTDOWN IMMEDIATE
Hello all:
We have Oracle 9.2.0.5 database ( single Note RAC ). There were
some heavy batch jobs running which cuased the db hang ( only sys
connection was working ).
We tried to bring down the database after cleaning all sessions.
It did not go down with SHUTDOWN IMMEDIATE. We had to abort it. I tried
to bring down the DB three times with SHUTDOWN IMMEDIATE it never went
down.
SMON was trying to cleanup the used extents ( Metalink Note -
1076161.6 ) as we could see in the alert log file - Waiting for smon to
disable tx recovery.
SQL> select count(block#) from fet$;
COUNT(BLOCK#)
-------------
38
fet$ - free extents
SQL> select count(block#) from uet$;
COUNT(BLOCK#)
-------------
52905
uet$ - used extents
We can share the alert log and system level 10 trace files if
anyone wants. These traces were generated when db hung.
Appreciate your help.
Thanks,
-ahmed
_____________________________________________
"If we knew what it was we were doing, it wouldn't
be called research, would it?" --Albert Einstein
________________________________
New Yahoo! Messenger with Voice. Call regular phones from your
PC
<http://us.rd.yahoo.com/mail_us/taglines/postman5/*http://us.rd.yahoo.co
m/evt=39666/*http://messenger.yahoo.com> and save big.
Other related posts:
