Re: DATABASE HANGS WITH SHUTDOWN IMMEDIATE
- From: "Jared Still" <jkstill@xxxxxxxxx>
- To: mln@xxxxxxxxxxxx
- Date: Mon, 1 May 2006 10:07:41 -0700
One more thing: the OP did not mention the platform.
On windows, there's an interesting thing that happens in a CMD window
when doing shutdown immediate.
The shutdown will appear to hang. It may go on quite awhile.
Try hitting the <ENTER> key in this situation.
The CMD window will hang, and will not respond until hitting <ENTER>.
It is not consistent behavior, but is also not unusual (happened to me last
week)
I've read the explanation of why this happens, but cannot recall what it is.
Jared
On 4/29/06, Mogens Nørrgaard <mln@xxxxxxxxxxxx> wrote:
I agree with the other members who responded that probably it's just a
case of SMON having to do a lot of work - and not using old-school
tablespace types. There is one other possibility perhaps: The ugly, old bug
w.r.t. memory leaking and Shutdown immediate just hanging. I think the
usual workaround still works:
event="10262 trace name context forever, level 0"
Again, it's probably just a completely normal thing you're seeing, but it
MIGHT be the bug rearing its head again.
Mogens
Ahmed Ullah wrote:
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.com/evt=39666/*http://messenger.yahoo.com>and
save big.
--
Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist
Other related posts:
- » DATABASE HANGS WITH SHUTDOWN IMMEDIATE
- » Re: DATABASE HANGS WITH SHUTDOWN IMMEDIATE
- » RE: DATABASE HANGS WITH SHUTDOWN IMMEDIATE
- » Re: DATABASE HANGS WITH SHUTDOWN IMMEDIATE
- » Re: DATABASE HANGS WITH SHUTDOWN IMMEDIATE
- » RE: DATABASE HANGS WITH SHUTDOWN IMMEDIATE
- » Re: DATABASE HANGS WITH SHUTDOWN IMMEDIATE
- » Re: DATABASE HANGS WITH SHUTDOWN IMMEDIATE
- » Re: DATABASE HANGS WITH SHUTDOWN IMMEDIATE
- » RE: DATABASE HANGS WITH SHUTDOWN IMMEDIATE
I agree with the other members who responded that probably it's just a case of SMON having to do a lot of work - and not using old-school tablespace types. There is one other possibility perhaps: The ugly, old bug w.r.t. memory leaking and Shutdown immediate just hanging. I think the usual workaround still works:
event="10262 trace name context forever, level 0"
Again, it's probably just a completely normal thing you're seeing, but it MIGHT be the bug rearing its head again.
Mogens
Ahmed Ullah wrote:
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#)
-------------
38fet$ - 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.com/evt=39666/*http://messenger.yahoo.com>and save big.