| 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
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.
> >
> **********************************************************************
> >
> >
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).Received on Thu Jul 25 2002 - 03:53:22 CDT
 |
 |