re SHUTDOWN ABORT -- was RE: Debate on rc commands Solaris and

Comparing the shutdown scenarios with what would happen if someone were to "pull the plug" on the server is the best way to explain the behaviour of Oracle.
What if

1. Someone switched-off the server [there's a power failure and the UPS doesn't kick in] ?
2. The server crashes with a Unix Panic well, the Oracle instance dies and yet, [as long as the disks are still good, even if you have to do an "fsck"] there's Instance Recovery which goes through successfully. So what's the problem with SHUTDOWN ABORT ? Its about the same thing, but not as bad.

I consistently use SHUTDOWN ABORT, STARTUP RESTRICT, SHUTDOWN NORMAL on Production, Mission-Critical databases. I've never had a problem with a SHUTDOWN ABORT.
Even a clone of an ABORTed instance can work if the online redo logs and current
control-file are also cloned !

I have seen SHUTDOWN IMMEDIATE hang very many times [particularly when DBMS_JOB jobs are running or the un-intelligent Intelligent Agent is connected].

Hemant

At 05:29 PM 31-01-03 -0800, you wrote:
>Dan,
>
>If you look at Rama Velpuri's most famous treatise on B & R - namely
>'Oracle8 Backup & Recovery Handbook' (Oracle Press), you will see the path
>that the various shutdown options take. [Page 43, Chapter 2: The Oracle
>Architecture and Configuration]. I belive this is the closest that we could
>come to a published look under the covers. Some one mentioned a switch
>logfile prior to the shutdown abort. In any case, a shutdown abort would not
>be as bad as someone pulling the plug on the juice (as in Cleaning lady: 'I
>need to plug in my hoover... aaah - here's a socket I can use). The instance
>goes down not-so-gracefully, but the disk is still safe as long as the
>server stays up.
>
>Just my $0.02.
>John Kanagaraj
>Oracle Applications DBA
>DBSoft Inc
>(W): 408-970-7002
>
>I don't know what the future holds for me, but I do know who holds my
>future!
>
>** The opinions and statements above are entirely my own and not those of my
>employer or clients **
>
>
> > -----Original Message-----
> > From: Fink, Dan [mailto:Dan.Fink_at_mdx.com]
> > Sent: Thursday, January 30, 2003 8:10 AM
> > To: Multiple recipients of list ORACLE-L
> > Subject: RE: Debate on rc commands Solaris and Oracle
> >
> >
> > I know I am going to catch major grief for this, but I avoid
> > shutdown abort
> > when possible. Shutdown immediate can take some time, as it will do
> > transaction rollback in serial (where recovery at startup can do it in
> > parallel and as needed). The main reason I avoid it is that
> > there are known
> > bugs that will cause the database to be unrecoverable when a
> > shutdown abort
> > is done while a kernel transaction is being performed.
> > Granted, I have not
> > personally encountered this, and the chances of encountering
> > it are slight,
> > but why take the risk?
> >
> > <Ducking and running for cover>
> > Dan Fink
> >
> > -----Original Message-----
> > Sent: Thursday, January 30, 2003 6:15 AM
> > To: Multiple recipients of list ORACLE-L
> >
> >
> >
> > I'll echo that sentiment.
> >
> > 'shutdown abort', 'startup restrict' was a regular part of my
> > shutdown scripts beginning in 1994 with 7.0.16, as
> > 'shutdown immediate' wasn't all that reliable, even in situations
> > where it should have worked.
> >
> > Jared
> >
> > On Wednesday 29 January 2003 15:53, John Kanagaraj wrote:
> > > Rao,
> > >
> > > And where did you read that 'shutdown abort' is not
> > recommended? This is
> > > another myth that has been busted a while ago. A shutdown
> > abort followed
> > by
> > > a startup restrict and a normal shutdown is the way to go
> > when dealing
> > with
> > > rogue sessions that open a connection and never shutdown.
> > In such cases, a
> > > shutdown immediate will _never_ return (certainly not
> > within your 5 to 10
> > > minutes). I have been using this method for more than 8 years now -
> > > starting at 7.0.16 fyi. The trick in this case is to script
> > it into the rc
> > > commands.
> > >
> > > John Kanagaraj
> > > Oracle Applications DBA
> > > DBSoft Inc
> > > (W): 408-970-7002
> > >
> > > I don't know what the future holds for me, but I do know
> > who holds my
> > > future!
> > >
> > > ** The opinions and statements above are entirely my own
> > and not those of
> > > my employer or clients **
> > >
> > >
> > > -----Original Message-----
> > > Sent: Wednesday, January 29, 2003 11:49 AM
> > > To: Multiple recipients of list ORACLE-L
> > >
> > >
> > > Paula,
> > >
> > > Shutdown abort is not recommended as the file checkpointing
> > is not done
> > > during shutdown abort. If you need to perform shutdown
> > abort, then, it is
> > > preferred to bring up the db with startup restrict (so that
> > the users
> > > wouldn't connect) and then, cleanly shutdown the db and
> > bring it up again.
> > >
> > > Tell to your sys admins. that shutdown immediate would take
> > some time
> > > (about 5 to 10 minutes) depending on the activity on your
> > db. They would
> > > have to wait for that much time before calling a DBA during
> > system boots.
> > >
> > > Rao
> > >
> > > -----Original Message-----
> > > Sent: Wednesday, January 29, 2003 11:30 AM
> > > To: Multiple recipients of list ORACLE-L
> > >
> > >
> > >
> > > System Administrator says he doesn't trust that the rc
> > commands will stop
> > > if the database doesn't want to shutdown and even if it
> > does would want to
> > > shutdown with scripts beforehand so that a DBA could
> > connect and resolve
> > > the issue. Other DBA says this is all wrong and rc commands should
> > include
> > > shutdown immediate of database. In the past I had setup 2
> > processes in
> > the
> > > system scripts for the sys admin - shutdown immediate -
> > wait .... shutdown
> > > abort - on a read-only DSS system which of course allows
> > some room for
> > this
> > > type of activity. I kind of would want to know if a
> > database was going to
> > > be shutdown with an abort esp. in OLTP system and do it myself.
> > >
> > >
> > >
> > > - any ideas
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.net
> > --
> > Author: Jared Still
> > INET: jkstill_at_cybcon.com
> >
> > Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> > San Diego, California -- Mailing list and web hosting services
> > ---------------------------------------------------------------------
> > To REMOVE yourself from this mailing list, send an E-Mail message
> > to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> > the message BODY, include a line containing: UNSUB ORACLE-L
> > (or the name of mailing list you want to be removed from). You may
> > also send the HELP command for other information (like subscribing).
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.net
> > --
> > Author: Fink, Dan
> > INET: Dan.Fink_at_mdx.com
> >
> > Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> > San Diego, California -- Mailing list and web hosting services
> > ---------------------------------------------------------------------
> > To REMOVE yourself from this mailing list, send an E-Mail message
> > to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> > the message BODY, include a line containing: UNSUB ORACLE-L
> > (or the name of mailing list you want to be removed from). You may
> > also send the HELP command for other information (like subscribing).
> >
>--
>Please see the official ORACLE-L FAQ: http://www.orafaq.net
>--
>Author: John Kanagaraj
> INET: john.kanagaraj_at_hds.com
>
>Fat City Network Services -- 858-538-5051 http://www.fatcity.com
>San Diego, California -- Mailing list and web hosting services
>---------------------------------------------------------------------
>To REMOVE yourself from this mailing list, send an E-Mail message
>to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
>the message BODY, include a line containing: UNSUB ORACLE-L
>(or the name of mailing list you want to be removed from). You may
>also send the HELP command for other information (like subscribing).

Hemant K Chitale
My web site page is : http://hkchital.tripod.com

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Hemant K Chitale
  INET: hkchital_at_singnet.com.sg

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).