> 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> 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 (See ora-4031.ora-code.com) 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 -- http://www.freelists.org/webpage/oracle-l
