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 <[EMAIL PROTECTED]> 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 PROTECTED]
> 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@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@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@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@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@86YY(&%T=&%C:&UE;G0@=&\@=&AI<R!E+6UA:6P@:&%S
M(&)E96X@<W=E<'0@9F]R('9I<G5S97,N("!792!A8V-E<'0@;F\@;&EA8FEL
M:71Y(&9O<B!A;GD@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: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
