RE: hanging shutdowns (addressing the requirement for a UNIX reboot)
- From: Boris Dali <boris_dali@xxxxxxxx>
- To: john.kanagaraj@xxxxxxx, roger_xu@xxxxxxxxxxx, "Oracle-L@Freelists" <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 1 Mar 2006 14:32:51 -0500 (EST)
John,
> This is because once you initiate a 'shutdown
> immediate' and 'control-c'ed out of it, then you
> will never be able to login since any
> new attaches will complain that a shutdown is in
> progress, and the only way out is to kill the
> backend processes.
This must be platform specific. Here's for instance
how it works for me in Oracle 9.2.0.6 on Linux:
SQL> sho release
release 902000600
SQL> shutdown immediate; -- and Ctrl-C
ORA-01013: user requested cancel of current operation
SQL> shutdown abort; -- no problem to abort
ORACLE instance shut down.
I can also open a separate sqlplus session after
Ctrl-C-ed shutdown immediate, connect as sys and
abort. Sometimes I get some funny errors like
"SP-0614: Sever version too low for this feature", but
shutdown abort still works like a charm.
In fact I think the only time I couldn't connect as
sys (or internal before 9i) was due to too many
ora-4031 errors.
While I also quite often go for a checkpoint;startup
force restrict; combination, I had two cases where
this caused me some grief. Both on AIX. The first was
on 4.3.2 / Oracle 7.2 timeframe, where I had to abort
the instance after waiting for more than 10min on a
shutdown immediate and upon startup we got multiple
data corruptions (no, not only in indexes), so I had
to go back to the last night's backup. Wasn't very
pleasant. I had to host our vendor's DBA, who flew
over to investigate on site, we had TAR opened,
eventually we even got IBM specialist on site (support
contemplated that it might be a JFS issue, despite any
lack of errors in errpt or anything else)... still
don't know what the problem was.
Recently, less than a year ago in fact (so I can still
see my TAR on metalink) we had to add JServer to one
of the development DBs 9.2.0.6 on AIX 5.2. DB was
restarted 6 times during the day (for different
reasons - we didn't have enough memory on the box and
plenty of other dev DBs (some already up and running,
others still to come shortly), so first shared pool
was too small, than java pool...). At the end
everything seemed to work nicely. No problems in
alert.log, udump, dba_registry, shutdown, startup,
etc... except complains from our SA the very next day
that paging space utilization started to increase
rapidly. So we had to go back and this how it looked
like:
>> ps -ef | grep pmon_xxxxxx
(slightly formated to fit the screen)
oracle 983050 1 0 Feb 28 - 0:04 ora_pmon_xxxxxx
oracle 1134640 1 0 Feb 26 - 0:08 ora_pmon_xxxxxx
oracle 1405000 1 0 Feb 28 - 0:04 ora_pmon_xxxxxx
oracle 1487016 1 0 Feb 28 - 0:04 ora_pmon_xxxxxx
oracle 1937444 1 0 Feb 28 - 0:04 ora_pmon_xxxxxx
oracle 1945646 1 0 Feb 28 - 0:04 ora_pmon_xxxxxx
(I replace SID with xxxxx). Same appplied to smon or
any other background processes.
>> ipcs -a
... (formated here)
IPC status from /dev/mem as of Tue Mar 1 16:27:44 EST
2005
Shared Memory:
m 131088 0xffffffff D-rw-r----- 6 143409152
m 7208984 0xffffffff D-rw-r----- 6 143409152
m 5505049 0xffffffff D-rw-r----- 6 143409152
m 5636122 0xffffffff D-rw-r----- 6 143409152
m 27 0xffffffff D-rw-r----- 6 76300288
m 393245 0xb2eb0d10 --rw-r----- 11 114049024
>> sysresv
IPC Resources for ORACLE_SID "xxxxxx" :
Shared Memory:
ID KEY
393245 0xb2eb0d10
Oracle Instance alive for sid "xxxxx"
So the last shared memory segment belonged to a
real/last/"actively running" instance, while the other
5 belonged to some "phantom" instances, still
(according to our SA) consuming resources
Looking back at the TAR - it was escalated to Advanced
Resolution team, which responded that haven't
previously seen this ... and advised to bounce the
box. Still don't know exactly what the problem was
Thanks,
Boris Dali.
__________________________________________________________
Find your next car at http://autos.yahoo.ca
--
//www.freelists.org/webpage/oracle-l
Other related posts:
