Oracle-L: RE: shutdown abort / startup restrict / shutdown vs. shutdown imm

From: April Wells <awells_at_csedge.com>
Date: Wed, 24 Jul 2002 15:08:14 -0800
Message-ID: <F001.004A1B74.20020724150814@fatcity.com>

I'm not committed to the premise that shutdown abort caused the corruption... only shutdown abort with a dead EMN0 process, when restarted, had redo log corruption. I have used shutdown abort in several hundred circumstances when there is something hanging around out there preventing a normal shutdown. In this case it appears that the set of circumstances has made something unstable... could it be that dead background process???... and it caused corruption.

-----Original Message-----
To: Multiple recipients of list ORACLE-L Sent: 7/24/02 5:43 PM

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.
>

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).

Received on Wed Jul 24 2002 - 18:08:14 CDT