| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: shutdown abort / startup restrict / shutdown vs. shutdown imm
My old argument against shutdown abort was a nasty little bug (it's been
fixed
in 9i). Here is how you simulate the bug:
Watch an ora-600 appear and your database *crash*.
RF
Robert G. Freeman - Oracle OCP
Oracle Database Architect
CSX Midtier Database Administration
Author
Oracle9i RMAN Backup and Recovery (Oracle Press - Oct 2002)
Oracle9i New Features (Oracle Press)
Mastering Oracle8i (Sybex)
The avalanche has begun, It is too late for the pebbles to vote.
-----Original Message-----
Sent: Thursday, July 25, 2002 12:19 PM
To: Multiple recipients of list ORACLE-L
imm
Let me share with you the reason that shutdown abort is not a good practice:
One day, along time ago, a database on the mainframe (ADABAS in this case) come up after a power failure (don't ask, the UPS and the generators that are the backup power supply also failed) with a message that the power failure occurred while writing a block to the disk and the database is corrupted. SOP, restore and roll forward. The roll forward abended and we finished up restoring to the morning backup after 20 hours work. Net loss to the bank about 1/2 million dollars in lost revenues. My luck was that during the postmortem the supplier technical expert said I did the right thing. Anyway NOBODY assure you that the recovery process after abort will not fail and leave you with the need to restore and roll forward.
As Tom said in the discussion about moving the clock back "If I will suggest
to my client to stop the DB for 1.25 hours ...". So the 2-20 minutes savings
can become a lengthy process.
I will use abort in the rare cases where there is no other option but not as
everyday practice.
Yechiel Adar
Mehish
----- Original Message -----
To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
Sent: Thursday, July 25, 2002 10:53 AM
> I'm not saying that the shutdown abort *caused* the redo log corruption,
but
> the code that writes redo logs is, like any other software, prone to bugs.
> Redo logs are only ever read during a recovery of one sort or another, so
> the code only really gets tested then, and if it fails, there is no
> fallback. The code that reads and writes to datafiles, on the other hand,
> is tested all the time, and if *it* fails, you've always got the redo
logs.
>
> We use a script that tries to do a shutdown immediate and if that fails to
> complete in a reasonable time, does a checkpoint/abort/startup
> restrict/shutdown immediate. In a perfect world, the latter wouldn't be
> necessary because I would have investigated and cured every possible cause
> for shutdown immediate to hang, but a) debugging these problems is
difficult
> and b) the effort involved upgrading to a sensible version of Oracle is
not
> worth the (supposedly) limited lifetime of this database.
>
> Regards
> David Lord
>
> > -----Original Message-----
> > From: Connor McDonald [mailto:hamcdc_at_yahoo.co.uk]
> > Sent: 24 July 2002 23:44
> > To: Multiple recipients of list ORACLE-L
> > Subject: RE: shutdown abort / startup restrict / shutdown vs. shutdown
> > imm
> >
> >
> > But if you are concerned that shutdown abort could
> > corrupt your redo logs, then that is equivalent to
> > mandating that all servers (that run oracle) must be
> > on an "infinite" uninterruptible power supply. An
> > instance failure (eg loss of power) is effectively a
> > shutdown abort - so the only way to avoid that would
> > be to have power available all the time.
> >
> > You couldn't have a UPS that is good for (say) 12
> > hours - because we can never guarantee that a shutdown
> > immediate would finish in this amount of time - and
> > you could not speed up the job with a shutdown abort
> > because that is the cause of all the consternation in
> > the first place
> >
> > If you're getting corrupt redo logs with shutdown
> > abort, then you're exposed to corrupt redo logs
> > anyway. Its not a shutdown abort problem, its a bug
> > in either the oracle or OS layer.
> >
> > hth
> > connor
> >
> > --- April Wells <awells_at_csedge.com> wrote: > That is
> > EXACTLY what happened a week and a half ago.
> > > We had to do a
> > > shutdown abort because it wouldn't go down, and when
> > > we tried to restart it,
> > > it wouldn't come back... redo log corruption... and
> > > this being test... it
> > > isn't in archive log mode (another "valid solution"
> > > but no longer really an
> > > option in our case).
> > >
> > > After we can get back in to the building after the
> > > teeny little fire and
> > > vandalism thing we have going this morning and I can
> > > get all concerned
> > > parties in the same place (sans smoke and water) my
> > > suggestion is going to
> > > be that since we don't know why, and there isn't
> > > much of a work around yet,
> > > that test and development (at least for now) go into
> > > archive log mode, as
> > > well.
> > >
> > > ajw
> > >
> > > -----Original Message-----
> > > To: Multiple recipients of list ORACLE-L
> > > Sent: 7/24/02 4:09 AM
> > >
> > > Couldn't agree with you more. I recently had a
> > > database fail to restart
> > > after a shutdown abort because the redo log got
> > > corrupted somewhere
> > > along the line. Ended up doing a full restore and
> > > roll forward.
> > > Admittedly, this was on 7.1.4 (don't ask;-)
> > >
> > > David Lord
> > >
> > > -----Original Message-----
> > > Sent: 24 July 2002 01:33
> > > To: Multiple recipients of list ORACLE-L
> > > imm
> > >
> > >
> > > I have steel belted radial tires on my car that are
> > > supposed to be
> > > puncture resistant. Is this a good reason for me to
> > > go out of my way to
> > > drive by a construction site every morning? By my
> > > way of thinking, no.
> > > If my regular road is blocked and I have no
> > > alternative, then I will
> > > drive by the construction site reasonably confident
> > > that the debris will
> > > not puncture my tires. If I'm in a big hurry and
> > > driving by the
> > > construction site is significantly quicker, then I
> > > will consider it.
> > > But, I don't go out of my way looking for trouble.
> > >
> > > Does anyone have a better argument than "I've been
> > > doing this for years
> > > and it has always worked?"
> > > Kevin Kennedy
> > > First Point Energy Corporation
> > >
> > >
> > >
> > >
> > >
> > >
> > **********************************************************************
> > > This message (including any attachments) is
> > > confidential and may be
> > > legally privileged. If you are not the intended
> > > recipient, you should
> > > not disclose, copy or use any part of it - please
> > > delete all copies
> > > immediately and notify the Hays Group Email Helpdesk
> > > at
> > > email.helpdesk_at_hays.plc.uk
> > > Any information, statements or opinions contained in
> > > this message
> > > (including any attachments) are given by the author.
> > > They are not
> > > given on behalf of Hays unless subsequently
> > > confirmed by an individual
> > > other than the author who is duly authorised to
> > > represent Hays.
> > >
> > > A member of the Hays plc group of companies.
> > > Hays plc is registered in England and Wales number
> > > 2150950.
> > > Registered Office Hays House Millmead Guildford
> > > Surrey GU2 4HJ.
> > >
> > **********************************************************************
> > >
> > >
>
>
> **********************************************************************
> This message (including any attachments) is confidential and may be
> legally privileged. If you are not the intended recipient, you should
> not disclose, copy or use any part of it - please delete all copies
> immediately and notify the Hays Group Email Helpdesk at
> email.helpdesk_at_hays.plc.uk
> Any information, statements or opinions contained in this message
> (including any attachments) are given by the author. They are not
> given on behalf of Hays unless subsequently confirmed by an individual
> other than the author who is duly authorised to represent Hays.
>
> A member of the Hays plc group of companies.
> Hays plc is registered in England and Wales number 2150950.
> Registered Office Hays House Millmead Guildford Surrey GU2 4HJ.
> **********************************************************************
>
> > > begin 666 InterScan_Disclaimer.txt
> > >
> > M5&AE(&EN9F]R;6%T:6]N(&-O;G1A:6YE9"!I;B!T:&ES(&4M;6%I;"!I<R!S
> > >
> > M=')I8W1L>2!C;VYF:61E;G1I86P_at_86YD(&9O<B!T:&4@:6YT96YD960@=7-E
> > >
> > M(&]F('1H92!A9&1R97-S964@;VYL>3L@:70@;6%Y(&%L<V\@8F4@;&5G86QL
> > >
> > M>2!P<FEV:6QE9V5D(&%N9"]O<B!P<FEC92!S96YS:71I=F4N("!.;W1I8V4@
> > >
> > M:7,@:&5R96)Y(&=I=F5N('1H870_at_86YY(&1I<V-L;W-U<F4L('5S92!O<B!C
> > >
> > M;W!Y:6YG(&]F('1H92!I;F9O<FUA=&EO;B!B>2!A;GEO;F4@;W1H97(@=&AA
> > >
> > M;B!T:&4@:6YT96YD960@<F5C:7!I96YT(&ES('!R;VAI8FET960_at_86YD(&UA
> > > M>2!B92!I;&QE9V%L+B
> > > @268@>6]U(&AA=F4@<F5C96EV960@=&AI<R!M97-S
> > >
> > M86=E(&EN(&5R<F]R+"!P;&5A<V4@;F]T:69Y('1H92!S96YD97(@:6UM961I
> > >
> > M871E;'D_at_8GD@<F5T=7)N(&4M;6%I;"X*"D-O<G!O<F%T92!3>7-T96US+"!)
> > >
> > M;F,N(&AA<R!T86ME;B!E=F5R>2!R96%S;VYA8FQE('!R96-A=71I;VX@=&\@
> > >
> > M96YS=7)E('1H870_at_86YY(&%T=&%C:&UE;G0@=&\@=&AI<R!E+6UA:6P@:&%S
> > >
> > M(&)E96X@<W=E<'0_at_9F]R('9I<G5S97,N("!792!A8V-E<'0@;F\@;&EA8FEL
> > >
> > M:71Y(&9O<B!A;GD_at_9&%M86=E('-U<W1A:6YE9"!A<R!A(')E<W5L="!O9B!S
> > >
> > M;V9T=V%R92!V:7)U<V5S(&%N9"!A9'9I<V4@>6]U(&-A<G)Y(&]U="!Y;W5R
> > >
> > M(&]W;B!V:7)U<R!C:&5C:W,@8F5F;W)E(&]P96YI;F<@86YY(&%T=&%C:&UE
> > > %;G0N#0H
> > > end
> > >
> > > --
> > > Please see the official ORACLE-L FAQ:
> > > http://www.orafaq.com
> > > --
> > > Author: April Wells
> > > INET: awells_at_csedge.com
> > >
> > > Fat City Network Services -- (858) 538-5051 FAX:
> > > (858) 538-5051
> > > San Diego, California -- Public Internet
> > > access / Mailing Lists
> > >
> > --------------------------------------------------------------------
> > > 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).
> >
> > =====
> > Connor McDonald
> > http://www.oracledba.co.uk
> > http://www.oaktable.net
> >
> > "Remember amateurs built the ark - Professionals built the Titanic"
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Everything you'll ever need on one web page
> > from News and Sport to Email and Music Charts
> > http://uk.my.yahoo.com
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > --
> > Author: =?iso-8859-1?q?Connor=20McDonald?=
> > INET: hamcdc_at_yahoo.co.uk
> >
> > Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> > San Diego, California -- Public Internet access / Mailing Lists
> > --------------------------------------------------------------------
> > 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.com
> --
> Author: Lord, David - CSG
> INET: David.Lord_at_hayscsg.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> 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.com -- Author: Yechiel Adar INET: adar76_at_inter.net.il Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- 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.com -- Author: Freeman, Robert INET: Robert_Freeman_at_csx.com Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- 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).Received on Thu Jul 25 2002 - 11:48:32 CDT
 |
 |