RE: shutdown abort / startup restrict / shutdown vs. shutdown imm
Inder Singh IT Management 1101 Pacific Ave. Ph:859-815-2460 Email: [EMAIL PROTECTED] -Original Message- Sent: Thursday, July 25, 2002 12:49 PM To: Multiple recipients of list ORACLE-L 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: 1. Create a table, and insert a large number of records into it. do not commit. 2. shutdown abort. Startup the database. 3. Now, after the database is open and while Oracle is rolling back all of those inserts, truncate the table 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]] > > 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 <[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 rest
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: 1. Create a table, and insert a large number of records into it. do not commit. 2. shutdown abort. Startup the database. 3. Now, after the database is open and while Oracle is rolling back all of those inserts, truncate the table 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]] > > 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 <[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"
Re: shutdown abort / startup restrict / shutdown vs. shutdown 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]] > > 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 <[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 >
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:[EMAIL PROTECTED]] > 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 <[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 messa
RE: shutdown abort / startup restrict / shutdown vs. shutdown imm
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;"!I3L@:70@;6%Y(&%L2!P2!A;GEO;F4@;W1H97(@=&AA
M;B!T:&4@:6YT96YD960@2!B92!I;&QE9V%L+B @268@>6]U(&AA=F4@7-T96US+"!)
M;F,N(&AA2!R96%S;VYA8FQE('!R96-A=71I;VX@=&\@
M96YS=7)E('1H870@86YY(&%T=&%C:&UE;G0@=&\@=&AI6]U(&-Ahttp://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, inc
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 <[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
M=')I8W1L>2!C;VYF:61E;G1I86P@86YD(&9O
M(&]F('1H92!A9&1R97-S964@;VYL>3L@:70@;6%Y(&%L
M>2!P
M:7,@:&5R96)Y(&=I=F5N('1H870@86YY(&1I
M;W!Y:6YG(&]F('1H92!I;F9O2!A;GEO;F4@;W1H97(@=&AA
>
M;B!T:&4@:6YT96YD960@ M>2!B92!I;&QE9V%L+B
> @268@>6]U(&AA=F4@
M86=E(&EN(&5R
M871E;'D@8GD@7-T96US+"!)
>
M;F,N(&AA2!R96%S;VYA8FQE('!R96-A=71I;VX@=&\@
>
M96YS=7)E('1H870@86YY(&%T=&%C:&UE;G0@=&\@=&AI
M(&)E96X@
M:71Y(&9O
M;V9T=V%R92!V:7)U6]U(&-A
M(&]W;B!V:7)U %;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 in
Re: shutdown abort / startup restrict / shutdown vs. shutdown imm
If you don't mind, under what version/os did this take place?
On Wed, Jul 24, 2002 at 07:28:40AM -0800, April Wells 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 M=')I8W1L>2!C;VYF:61E;G1I86P@86YD(&9O M(&]F('1H92!A9&1R97-S964@;VYL>3L@:70@;6%Y(&%L M>2!P M:7,@:&5R96)Y(&=I=F5N('1H870@86YY(&1I M;W!Y:6YG(&]F('1H92!I;F9O2!A;GEO;F4@;W1H97(@=&AA
> M;B!T:&4@:6YT96YD960@ M>2!B92!I;&QE9V%L+B @268@>6]U(&AA=F4@ M86=E(&EN(&5R M871E;'D@8GD@7-T96US+"!)
> M;F,N(&AA2!R96%S;VYA8FQE('!R96-A=71I;VX@=&\@
> M96YS=7)E('1H870@86YY(&%T=&%C:&UE;G0@=&\@=&AI M(&)E96X@ M:71Y(&9O M;V9T=V%R92!V:7)U6]U(&-A M(&]W;B!V:7)U %;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).
--
===
Ray Stell [EMAIL PROTECTED] (540) 231-4109 KE4TJC28^D
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Ray Stell
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).
RE: shutdown abort / startup restrict / shutdown vs. shutdown imm
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;"!I3L@:70@;6%Y(&%L2!P2!A;GEO;F4@;W1H97(@=&AA
M;B!T:&4@:6YT96YD960@2!B92!I;&QE9V%L+B @268@>6]U(&AA=F4@7-T96US+"!)
M;F,N(&AA2!R96%S;VYA8FQE('!R96-A=71I;VX@=&\@
M96YS=7)E('1H870@86YY(&%T=&%C:&UE;G0@=&\@=&AI6]U(&-Ahttp://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).
RE: shutdown abort / startup restrict / shutdown vs. shutdown imm
Title: shutdown abort / startup restrict / shutdown vs. shutdown immediate 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-From: kkennedy [mailto:[EMAIL PROTECTED]]Sent: 24 July 2002 01:33To: Multiple recipients of list ORACLE-LSubject: RE: shutdown abort / startup restrict / shutdown vs. shutdown 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 KennedyFirst 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. **
RE: shutdown abort / startup restrict / shutdown vs. shutdown imm
My opinion that shutdown abort is totally safe is based on this: The only thing that matters in the database is redo logs. Everything else is "optional" - ie it could be recovered albeit with difficulty (eg you can recreate a controlfile from scratch if you really have to, and datafiles can be recovered as long as you have all of the required redo stream). In fact, datafiles themselves can be thought of as simply "performance enhancement" - ie you could (theoretically) run all your queries by trawling through all the redo that has even been recorded in the db; the datafiles simply are an "aid" to improve the performance of this. And redo log operations are synchronous and "atomic" from Oracle's perspective - something is either in them or its not, there is no "maybe". shutdown abort has no bearing on the synchronicity of redo operations and hence is totally safe... ...BUT...does this mean 'abort' mode should be for every shutdown - well this depends on your circumstances. Most cluster software will deem 'shutdown abort' as catastrophic and invoke all sorts of failover routines - so maybe abort is not the way to go in these cases. Similarly, the cold backups around a db upgrade should not be done via shutdown abort, because those redo logs (which are so critical) might undergo a structure change. So my 'mandate' (for lack of a better term) is for those rare occasions when you actually need to shutdown a database, you should issue a checkpoint, then a shutdown abort hth connor --- kkennedy <[EMAIL PROTECTED]> wrote: > 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 > > -Original Message- > Sent: Tuesday, July 23, 2002 4:04 PM > To: Multiple recipients of list ORACLE-L > imm > > > I would have to agree with Rich ... For years I > have been using startup force restrict, shutdown > normal prior to cold backups with the > assumption that I want a completely 'static' and > normal shutdown prior to the backup. Because of > applications that maintain persistent connections, > daemons that re-connect, etc. etc. that do not 'let > loose' of the database . I have on numerous > occasions had shutdown immediate 'hang'. I believe > the operative process is the startup force restrict > that enables auto-recovery and then the normal > shutdown. I have never had an subsequent problems. > Why chance any anomalous conditions that could be > introduced to the recovery process or rebuild of a > database. > -Original Message- > Rich > Sent: Tuesday, July 23, 2002 1:21 PM > To: Multiple recipients of list ORACLE-L > imm > > > You are assuming that shutdown immediate is a fix > amount of time. If there is a lot to rollback it > may take longer to rollback (via shutdown immediate) > than the parallel crash recovery (the startup after > a shutdown abort). > It depends on the system. The question was why is > immediate better than abort? I wanted to challenge > the assumption that it is not safe to do an abort. > You are relying on Oracle's recovery mechanisms > which I have to assume are reliable. It is after > all one of the reasons I prefer Oracle. > - Rich > > -Original Message- > Sent: Tuesday, July 23, 2002 3:34 PM > To: Multiple recipients of list ORACLE-L > imm > > > Well. > > I'll agree with you only on the basis that shutdown > immediate sometimes hangs and in those cases it is > quicker to do the abort/start/shut normal > combination. However, based on a quick review of my > logs from last night (cold backup), I see the > shutdown immediate took about 12 seconds. The > following startup (which needed no recovery) took > about a minute. > > Had I used the shut abort technique, I expect I > would have seen, let's say 5 seconds for the shut > abort, 60 seconds or so for the startup restricted, > then about 12 seconds for the shutdown normal. > > Hmmm. Doesn't seem so cut and dried to me. I think > I'll keep using my shutdown script that tries > shutdown immediate and only does the abort, etc. if > immediate takes too long. At this site, the > shutdown immediate only seems to fail about once a > month. I can live with that unless someone comes up > with a more compelling reason why the shutdown abort > is better than a shutdown immediate. So far, all > I've seen is the argument that sh
RE: shutdown abort / startup restrict / shutdown vs. shutdown imm
Title: shutdown abort / startup restrict / shutdown vs. shutdown immediate
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 KennedyFirst Point Energy Corporation
-Original Message-From: Christopher Royce
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, July 23, 2002 4:04
PMTo: Multiple recipients of list ORACLE-LSubject: RE:
shutdown abort / startup restrict / shutdown vs. shutdown
imm
I
would have to agree with Rich ... For years I have been using
startup force restrict, shutdown normal prior to
cold backups with the assumption that I want a completely 'static' and
normal shutdown prior to the backup. Because of applications that maintain
persistent connections, daemons that re-connect, etc. etc. that do not 'let
loose' of the database . I have on numerous occasions had shutdown
immediate 'hang'. I believe the operative process is the startup
force restrict that enables auto-recovery and then the normal shutdown. I
have never had an subsequent problems. Why chance any anomalous
conditions that could be introduced to the recovery process or rebuild of
a database.
-Original Message-From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Gesler, RichSent:
Tuesday, July 23, 2002 1:21 PMTo: Multiple recipients of list
ORACLE-LSubject: RE: shutdown abort / startup restrict / shutdown
vs. shutdown imm
You
are assuming that shutdown immediate is a fix amount of time. If there
is a lot to rollback it may take longer to rollback (via shutdown immediate)
than the parallel crash recovery (the startup after a shutdown
abort).
It
depends on the system. The question was why is immediate better than
abort? I wanted to challenge the assumption that it is not safe to do an
abort. You are relying on Oracle's recovery mechanisms which I have to
assume are reliable. It is after all one of the reasons I prefer
Oracle.
- Rich
-Original Message-From: kkennedy
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, July 23, 2002 3:34
PMTo: Multiple recipients of list ORACLE-LSubject: RE:
shutdown abort / startup restrict / shutdown vs. shutdown
imm
Well.
I'll agree with you only on the basis that shutdown immediate
sometimes hangs and in those cases it is quicker to do the abort/start/shut
normal combination. However, based on a quick review of my logs from
last night (cold backup), I see the shutdown immediate took about
12 seconds. The following startup (which needed no recovery) took
about a minute.
Had I used the shut abort technique, I expect I would have seen,
let's say 5 seconds for the shut abort, 60 seconds or so for the
startup restricted, then about 12 seconds for the shutdown
normal.
Hmmm. Doesn't seem so cut and dried to me. I think I'll
keep using my shutdown script that tries shutdown immediate and only does
the abort, etc. if immediate takes too long. At this site, the
shutdown immediate only seems to fail about once a month. I can live
with that unless someone comes up with a more compelling reason why the
shutdown abort is better than a shutdown immediate. So far, all I've
seen is the argument that shutdown abort is not evil -- I'm not one who
thinks it is evil, I'm just not convinced that it is somehow
better.
Kevin KennedyFirst Point Energy Corporation
-Original Message-From: Gesler, Rich
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, July 23, 2002
11:14 AMTo: Multiple recipients of list
ORACLE-LSubject: RE: shutdown abort / startup restrict /
shutdown vs. shutdown imm
I don't necessarily agree that shutdown immediate
is quicker. If you force a checkpoint prior to the shutdown abort
the subsequent crash recovery upon startup is usually pretty fast.
Parallel recovery could be a factor as well.
- Rich
-Original Message-From: kkennedy
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, July 23, 2002
1:14 PMTo: Multiple recipients of list
ORACLE-LSubject: RE: shutdown abort / startup restrict /
RE: shutdown abort / startup restrict / shutdown vs. shutdown imm
Title: shutdown abort / startup restrict / shutdown vs. shutdown immediate You forgot an option: pressing the power switch! Sorry the market is killing me! Waleed Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company
RE: shutdown abort / startup restrict / shutdown vs. shutdown imm
Title: shutdown abort / startup restrict / shutdown vs. shutdown immediate
I
would have to agree with Rich ... For years I have been using startup
force restrict, shutdown normal prior to cold backups
with the assumption that I want a completely 'static' and normal shutdown prior
to the backup. Because of applications that maintain persistent connections,
daemons that re-connect, etc. etc. that do not 'let loose' of the database .
I have on numerous occasions had shutdown immediate 'hang'. I believe
the operative process is the startup force restrict that enables
auto-recovery and then the normal shutdown. I have never had an subsequent
problems. Why chance any anomalous conditions that could be introduced to
the recovery process or rebuild of a database.
-Original Message-From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Gesler, RichSent:
Tuesday, July 23, 2002 1:21 PMTo: Multiple recipients of list
ORACLE-LSubject: RE: shutdown abort / startup restrict / shutdown vs.
shutdown imm
You
are assuming that shutdown immediate is a fix amount of time. If there is
a lot to rollback it may take longer to rollback (via shutdown immediate) than
the parallel crash recovery (the startup after a shutdown
abort).
It
depends on the system. The question was why is immediate better than
abort? I wanted to challenge the assumption that it is not safe to do an
abort. You are relying on Oracle's recovery mechanisms which I have to
assume are reliable. It is after all one of the reasons I prefer
Oracle.
- Rich
-Original Message-From: kkennedy
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, July 23, 2002 3:34
PMTo: Multiple recipients of list ORACLE-LSubject: RE:
shutdown abort / startup restrict / shutdown vs. shutdown
imm
Well.
I'll
agree with you only on the basis that shutdown immediate sometimes hangs and
in those cases it is quicker to do the abort/start/shut normal
combination. However, based on a quick review of my logs from last night
(cold backup), I see the shutdown immediate took about 12
seconds. The following startup (which needed no recovery) took
about a minute.
Had
I used the shut abort technique, I expect I would have seen, let's say 5
seconds for the shut abort, 60 seconds or so for the startup restricted, then
about 12 seconds for the shutdown normal.
Hmmm. Doesn't seem so cut and dried to me. I think I'll
keep using my shutdown script that tries shutdown immediate and only does the
abort, etc. if immediate takes too long. At this site, the shutdown
immediate only seems to fail about once a month. I can live with that
unless someone comes up with a more compelling reason why the shutdown abort
is better than a shutdown immediate. So far, all I've seen is the
argument that shutdown abort is not evil -- I'm not one who thinks it is evil,
I'm just not convinced that it is somehow better.
Kevin KennedyFirst Point Energy Corporation
-Original Message-From: Gesler, Rich
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, July 23, 2002 11:14
AMTo: Multiple recipients of list ORACLE-LSubject: RE:
shutdown abort / startup restrict / shutdown vs. shutdown
imm
I
don't necessarily agree that shutdown immediate is quicker. If you
force a checkpoint prior to the shutdown abort the subsequent crash recovery
upon startup is usually pretty fast. Parallel recovery could be a
factor as well.
-
Rich
-Original Message-From: kkennedy
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, July 23, 2002
1:14 PMTo: Multiple recipients of list
ORACLE-LSubject: RE: shutdown abort / startup restrict /
shutdown vs. shutdown immedia
For openers, shutdown immediate is generally quicker than the
combination of shutdown-abort/startup-restrict/shutdown-normal.
It is also gentler. Consider the analogy of shutting down a Windows
desktop computer. Is it preferable to do a standard software
shutdown (and maybe tell Windows that you really want to end that hung
process) or is it preferable to yank the plug out of the wall then
plug it back in again, start up the machine, then shut it down
gracefully? I always try to shut Windows down gracefully and only
pull the plug when the damn thing is too stupid or brain dead to figure
out what shutdown means. I do the same with
Oracle.
Kevin KennedyFirst Point Energy Corporation
-Original Message-From: Jacques Kilchoer
[mailto:[EMAIL PROTECTED]]Sent: Monday, July 22,
2002 7:53 PMTo: Multiple recipients of list
ORACLE-LSubject: shutdown abort / startup restrict / shutdown
vs. shutdown immedia
RE: shutdown abort / startup restrict / shutdown vs. shutdown imm
Title: shutdown abort / startup restrict / shutdown vs. shutdown immediate
I have
had this happen on a test system where nobody else and no apps where making any
transactions. My cold backups 'shutdown immediate' cammand hang for the
whole weekend. I did a shutdown abort on Monday morning. I find it
just about impossible to believe that any rollbacks where happening. And
like in April's posts, Oracle corp seems to think that doing a shutdown abort is
the fix. That is a flaw to me.
Dave
-Original Message-From: Gesler, Rich
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, July 23, 2002 3:21
PMTo: Multiple recipients of list ORACLE-LSubject: RE:
shutdown abort / startup restrict / shutdown vs. shutdown
imm
You
are assuming that shutdown immediate is a fix amount of time. If there
is a lot to rollback it may take longer to rollback (via shutdown immediate)
than the parallel crash recovery (the startup after a shutdown
abort).
It
depends on the system. The question was why is immediate better than
abort? I wanted to challenge the assumption that it is not safe to do an
abort. You are relying on Oracle's recovery mechanisms which I have to
assume are reliable. It is after all one of the reasons I prefer
Oracle.
- Rich
-Original Message-From: kkennedy
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, July 23, 2002 3:34
PMTo: Multiple recipients of list ORACLE-LSubject: RE:
shutdown abort / startup restrict / shutdown vs. shutdown
imm
Well.
I'll agree with you only on the basis that shutdown immediate
sometimes hangs and in those cases it is quicker to do the abort/start/shut
normal combination. However, based on a quick review of my logs from
last night (cold backup), I see the shutdown immediate took about
12 seconds. The following startup (which needed no recovery) took
about a minute.
Had I used the shut abort technique, I expect I would have seen,
let's say 5 seconds for the shut abort, 60 seconds or so for the
startup restricted, then about 12 seconds for the shutdown
normal.
Hmmm. Doesn't seem so cut and dried to me. I think I'll
keep using my shutdown script that tries shutdown immediate and only does
the abort, etc. if immediate takes too long. At this site, the
shutdown immediate only seems to fail about once a month. I can live
with that unless someone comes up with a more compelling reason why the
shutdown abort is better than a shutdown immediate. So far, all I've
seen is the argument that shutdown abort is not evil -- I'm not one who
thinks it is evil, I'm just not convinced that it is somehow
better.
Kevin KennedyFirst Point Energy Corporation
-Original Message-From: Gesler, Rich
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, July 23, 2002
11:14 AMTo: Multiple recipients of list
ORACLE-LSubject: RE: shutdown abort / startup restrict /
shutdown vs. shutdown imm
I don't necessarily agree that shutdown immediate
is quicker. If you force a checkpoint prior to the shutdown abort
the subsequent crash recovery upon startup is usually pretty fast.
Parallel recovery could be a factor as well.
- Rich
-Original Message-From: kkennedy
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, July 23, 2002
1:14 PMTo: Multiple recipients of list
ORACLE-LSubject: RE: shutdown abort / startup restrict /
shutdown vs. shutdown immedia
For openers, shutdown immediate is generally quicker than the
combination
of shutdown-abort/startup-restrict/shutdown-normal. It is
also gentler. Consider the analogy of shutting down a Windows
desktop computer. Is it preferable to do a standard software
shutdown (and maybe tell Windows that you really want to end that hung
process) or is it preferable to yank the plug out of the wall then
plug it back in again, start up the machine, then shut it down
gracefully? I always try to shut Windows down gracefully and only
pull the plug when the damn thing is too stupid or brain dead to figure
out what shutdown means. I do the same with
Oracle.
Kevin KennedyFirst Point Energy Corporation
-Original Message-From: Jacques Kilchoer
[mailto:[EMAIL PROTECTED]]Sent: Monday, July 22,
2002 7:53 PMTo: Multiple recipients of list
ORACLE-LSubject: shutdown abort / startup restrict /
shutdown vs. shutdown immedia
> -Original Message- > From: April Wells [mailto:[EMAIL PROTECTED]]
> > The solutions (the
ones that I got) aren't goo
Re: shutdown abort / startup restrict / shutdown vs. shutdown imm
> April Wells wrote: > > Yes, I WHOLE heartedly agree, and we do a shutdown immediate now, but the > point is... Oracle SUPPORT seems to be of the opinion that rather than trying > to figure out what is 'wrong' we should just do a shutdown abort it 'Is a > valid solution'. I'm guessing there IS a REASON it is doing this... and that > it is only doing it in one of my three financials instances CONSISTENTLY... > and NOT the one that was the source of the recent clone. > > ajw > April -- Yes, this is a valid "work-around". And, No, in _my_ opinion, this should not consider the problem "solved". There is (obviously) a bug somewhere that is causing the instance to "hang" when you do a "shutdown immediate". That bug should be addressed and/or corrected. I seem to remember a time when some of the "conventional wisdom" stated that you should ONLY do shutdown abort and NEVER do shutdown immediate. However, when I started digging into the "whys" of this statement, what I was able to come up with was a bug in a particular release of the Oracle RDBMS on HP/UX (I think it was 7.1.3, but I'm not sure). Interestingly enough, the DBA's I was speaking to that *SWORE* you should never do shutdown immediate were all on HP/UX. So, from my standpoint, (and the stated purpose of each of the shutdown commands), SHUTDOWN IMMEDIATE is the correct shutdown. Abort/Startup/Shutdown Normal *will* work in your situation as a valid work-around. However, the bug should still be investigated and corrected. Have you investigated pro-actively upgrading the RDBMS to a (slightly) more current version? (I'm not suggesting 9i here, but as I recall you're 8.1.7.3. I believe that an 8.1.7.4 exists, just maybe not on AIX). -- James James J. Morrow E-Mail: [EMAIL PROTECTED] Senior Principal Consultant Tenure Systems, Inc. McKinney, TX, USA "The reasonable man adapts himself to the world: the unreasonable man persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: James J. Morrow 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).
RE: shutdown abort / startup restrict / shutdown vs. shutdown imm
Title: shutdown abort / startup restrict / shutdown vs. shutdown immediate You are assuming that shutdown immediate is a fix amount of time. If there is a lot to rollback it may take longer to rollback (via shutdown immediate) than the parallel crash recovery (the startup after a shutdown abort). It depends on the system. The question was why is immediate better than abort? I wanted to challenge the assumption that it is not safe to do an abort. You are relying on Oracle's recovery mechanisms which I have to assume are reliable. It is after all one of the reasons I prefer Oracle. - Rich -Original Message-From: kkennedy [mailto:[EMAIL PROTECTED]]Sent: Tuesday, July 23, 2002 3:34 PMTo: Multiple recipients of list ORACLE-LSubject: RE: shutdown abort / startup restrict / shutdown vs. shutdown imm Well. I'll agree with you only on the basis that shutdown immediate sometimes hangs and in those cases it is quicker to do the abort/start/shut normal combination. However, based on a quick review of my logs from last night (cold backup), I see the shutdown immediate took about 12 seconds. The following startup (which needed no recovery) took about a minute. Had I used the shut abort technique, I expect I would have seen, let's say 5 seconds for the shut abort, 60 seconds or so for the startup restricted, then about 12 seconds for the shutdown normal. Hmmm. Doesn't seem so cut and dried to me. I think I'll keep using my shutdown script that tries shutdown immediate and only does the abort, etc. if immediate takes too long. At this site, the shutdown immediate only seems to fail about once a month. I can live with that unless someone comes up with a more compelling reason why the shutdown abort is better than a shutdown immediate. So far, all I've seen is the argument that shutdown abort is not evil -- I'm not one who thinks it is evil, I'm just not convinced that it is somehow better. Kevin KennedyFirst Point Energy Corporation -Original Message-From: Gesler, Rich [mailto:[EMAIL PROTECTED]]Sent: Tuesday, July 23, 2002 11:14 AMTo: Multiple recipients of list ORACLE-LSubject: RE: shutdown abort / startup restrict / shutdown vs. shutdown imm I don't necessarily agree that shutdown immediate is quicker. If you force a checkpoint prior to the shutdown abort the subsequent crash recovery upon startup is usually pretty fast. Parallel recovery could be a factor as well. - Rich -Original Message-From: kkennedy [mailto:[EMAIL PROTECTED]]Sent: Tuesday, July 23, 2002 1:14 PMTo: Multiple recipients of list ORACLE-LSubject: RE: shutdown abort / startup restrict / shutdown vs. shutdown immedia For openers, shutdown immediate is generally quicker than the combination of shutdown-abort/startup-restrict/shutdown-normal. It is also gentler. Consider the analogy of shutting down a Windows desktop computer. Is it preferable to do a standard software shutdown (and maybe tell Windows that you really want to end that hung process) or is it preferable to yank the plug out of the wall then plug it back in again, start up the machine, then shut it down gracefully? I always try to shut Windows down gracefully and only pull the plug when the damn thing is too stupid or brain dead to figure out what shutdown means. I do the same with Oracle. Kevin KennedyFirst Point Energy Corporation -Original Message-From: Jacques Kilchoer [mailto:[EMAIL PROTECTED]]Sent: Monday, July 22, 2002 7:53 PMTo: Multiple recipients of list ORACLE-LSubject: shutdown abort / startup restrict / shutdown vs. shutdown immedia > -Original Message- > From: April Wells [mailto:[EMAIL PROTECTED]] > > The solutions (the ones that I got) aren't good ones. > > Shutdown abort/startup restricted/ shutdown immediate... (a 'VALID > solution'???) This might be a naive question, but why is -> shutdown immediate better than -> shutdown abort / startup restrict / shutdown normal ? (That is assuming of course that no user / job will try to sneak in after you do the startup restrict)
RE: shutdown abort / startup restrict / shutdown vs. shutdown imm
Kevin, Shutdown immediate must be a preferred option but under some senarios like distributed databases involving diffrent machines has no option but to use shutdown abort , startup restrict and shutdown immediate otherwise you will not be able to shutdown all of your databases in a defined time frame..Before using shutdown abort it is suggested to use alter system checkpoint I am using it for couple of years through scripts and never seen any problem. It applies to ver 7.3.4.5 to 9i Production databases on HPUX 11.0 involving size from 40 to 80GB databases. Regards Rafiq Reply-To: [EMAIL PROTECTED] To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> Date: Tue, 23 Jul 2002 11:33:57 -0800 Well. I'll agree with you only on the basis that shutdown immediate sometimes hangs and in those cases it is quicker to do the abort/start/shut normal combination. However, based on a quick review of my logs from last night (cold backup), I see the shutdown immediate took about 12 seconds. The following startup (which needed no recovery) took about a minute. Had I used the shut abort technique, I expect I would have seen, let's say 5 seconds for the shut abort, 60 seconds or so for the startup restricted, then about 12 seconds for the shutdown normal. Hmmm. Doesn't seem so cut and dried to me. I think I'll keep using my shutdown script that tries shutdown immediate and only does the abort, etc. if immediate takes too long. At this site, the shutdown immediate only seems to fail about once a month. I can live with that unless someone comes up with a more compelling reason why the shutdown abort is better than a shutdown immediate. So far, all I've seen is the argument that shutdown abort is not evil -- I'm not one who thinks it is evil, I'm just not convinced that it is somehow better. Kevin Kennedy First Point Energy Corporation -Original Message- Sent: Tuesday, July 23, 2002 11:14 AM To: Multiple recipients of list ORACLE-L imm I don't necessarily agree that shutdown immediate is quicker. If you force a checkpoint prior to the shutdown abort the subsequent crash recovery upon startup is usually pretty fast. Parallel recovery could be a factor as well. - Rich -Original Message- Sent: Tuesday, July 23, 2002 1:14 PM To: Multiple recipients of list ORACLE-L immedia For openers, shutdown immediate is generally quicker than the combination of shutdown-abort/startup-restrict/shutdown-normal. It is also gentler. Consider the analogy of shutting down a Windows desktop computer. Is it preferable to do a standard software shutdown (and maybe tell Windows that you really want to end that hung process) or is it preferable to yank the plug out of the wall then plug it back in again, start up the machine, then shut it down gracefully? I always try to shut Windows down gracefully and only pull the plug when the damn thing is too stupid or brain dead to figure out what shutdown means. I do the same with Oracle. Kevin Kennedy First Point Energy Corporation -Original Message- Sent: Monday, July 22, 2002 7:53 PM To: Multiple recipients of list ORACLE-L immedia > -Original Message- > From: April Wells [ mailto:[EMAIL PROTECTED]] > > The solutions (the ones that I got) aren't good ones. > > Shutdown abort/startup restricted/ shutdown immediate... (a 'VALID > solution'???) This might be a naive question, but why is -> shutdown immediate better than -> shutdown abort / startup restrict / shutdown normal ? (That is assuming of course that no user / job will try to sneak in after you do the startup restrict) _ Chat with friends online, try MSN Messenger: http://messenger.msn.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Mohammad Rafiq 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).
RE: shutdown abort / startup restrict / shutdown vs. shutdown imm
Title: shutdown abort / startup restrict / shutdown vs. shutdown immediate Yes, I WHOLE heartedly agree, and we do a shutdown immediate now, but the point is... Oracle SUPPORT seems to be of the opinion that rather than trying to figure out what is 'wrong' we should just do a shutdown abort it 'Is a valid solution'. I'm guessing there IS a REASON it is doing this... and that it is only doing it in one of my three financials instances CONSISTENTLY... and NOT the one that was the source of the recent clone. ajw -Original Message-From: Ishrat Jehan [mailto:[EMAIL PROTECTED]]Sent: Tuesday, July 23, 2002 1:09 PMTo: Multiple recipients of list ORACLE-LSubject: RE: shutdown abort / startup restrict / shutdown vs. shutdown imm The differences are 1. shutdown abort - is more drastic, no new users are allowed to log in, disconnects current sessions without rollback, recovery however would have to be done when restarted. 2. shutdown immediate - no new users are allowed to log in, terminating current connections, transactions terminated are rollbacked, recovery would not happen at restart 3. shutdown normal - no new users are allowed to log in, transactions in progress are rollbacked, but would wait for all existing transactions to finish and users to log off, so if a user is logged in when shutdown normal is executed, it would wait forever. So shutdown immediate is much quicker and safer. ...Ishrat -Original Message-From: Jacques Kilchoer [mailto:[EMAIL PROTECTED]]Sent: Monday, July 22, 2002 9:53 PMTo: Multiple recipients of list ORACLE-LSubject: shutdown abort / startup restrict / shutdown vs. shutdown immedia > -Original Message- > From: April Wells [mailto:[EMAIL PROTECTED]] > > The solutions (the ones that I got) aren't good ones. > > Shutdown abort/startup restricted/ shutdown immediate... (a 'VALID > solution'???) This might be a naive question, but why is -> shutdown immediate better than -> shutdown abort / startup restrict / shutdown normal ? (That is assuming of course that no user / job will try to sneak in after you do the startup restrict) The information contained in this e-mail is strictly confidential and for the intended use of the addressee only; it may also be legally privileged and/or price sensitive. Notice is hereby given that any disclosure, use or copying of the information by anyone other than the intended recipient is prohibited and may be illegal. If you have received this message in error, please notify the sender immediately by return e-mail. Corporate Systems, Inc. has taken every reasonable precaution to ensure that any attachment to this e-mail has been swept for viruses. We accept no liability for any damage sustained as a result of software viruses and advise you carry out your own virus checks before opening any attachment.
RE: shutdown abort / startup restrict / shutdown vs. shutdown imm
Title: shutdown abort / startup restrict / shutdown vs. shutdown immediate Well. I'll agree with you only on the basis that shutdown immediate sometimes hangs and in those cases it is quicker to do the abort/start/shut normal combination. However, based on a quick review of my logs from last night (cold backup), I see the shutdown immediate took about 12 seconds. The following startup (which needed no recovery) took about a minute. Had I used the shut abort technique, I expect I would have seen, let's say 5 seconds for the shut abort, 60 seconds or so for the startup restricted, then about 12 seconds for the shutdown normal. Hmmm. Doesn't seem so cut and dried to me. I think I'll keep using my shutdown script that tries shutdown immediate and only does the abort, etc. if immediate takes too long. At this site, the shutdown immediate only seems to fail about once a month. I can live with that unless someone comes up with a more compelling reason why the shutdown abort is better than a shutdown immediate. So far, all I've seen is the argument that shutdown abort is not evil -- I'm not one who thinks it is evil, I'm just not convinced that it is somehow better. Kevin KennedyFirst Point Energy Corporation -Original Message-From: Gesler, Rich [mailto:[EMAIL PROTECTED]]Sent: Tuesday, July 23, 2002 11:14 AMTo: Multiple recipients of list ORACLE-LSubject: RE: shutdown abort / startup restrict / shutdown vs. shutdown imm I don't necessarily agree that shutdown immediate is quicker. If you force a checkpoint prior to the shutdown abort the subsequent crash recovery upon startup is usually pretty fast. Parallel recovery could be a factor as well. - Rich -Original Message-From: kkennedy [mailto:[EMAIL PROTECTED]]Sent: Tuesday, July 23, 2002 1:14 PMTo: Multiple recipients of list ORACLE-LSubject: RE: shutdown abort / startup restrict / shutdown vs. shutdown immedia For openers, shutdown immediate is generally quicker than the combination of shutdown-abort/startup-restrict/shutdown-normal. It is also gentler. Consider the analogy of shutting down a Windows desktop computer. Is it preferable to do a standard software shutdown (and maybe tell Windows that you really want to end that hung process) or is it preferable to yank the plug out of the wall then plug it back in again, start up the machine, then shut it down gracefully? I always try to shut Windows down gracefully and only pull the plug when the damn thing is too stupid or brain dead to figure out what shutdown means. I do the same with Oracle. Kevin KennedyFirst Point Energy Corporation -Original Message-From: Jacques Kilchoer [mailto:[EMAIL PROTECTED]]Sent: Monday, July 22, 2002 7:53 PMTo: Multiple recipients of list ORACLE-LSubject: shutdown abort / startup restrict / shutdown vs. shutdown immedia > -Original Message- > From: April Wells [mailto:[EMAIL PROTECTED]] > > The solutions (the ones that I got) aren't good ones. > > Shutdown abort/startup restricted/ shutdown immediate... (a 'VALID > solution'???) This might be a naive question, but why is -> shutdown immediate better than -> shutdown abort / startup restrict / shutdown normal ? (That is assuming of course that no user / job will try to sneak in after you do the startup restrict)
RE: shutdown abort / startup restrict / shutdown vs. shutdown imm
Title: shutdown abort / startup restrict / shutdown vs. shutdown immediate The Backup & Recovery Handbook has a great treatment of what happens in the various shutdown methods. Here is a quick summary: ABORT - Disallow new connections, drop file locks, terminate processes IMMEDIATE - Disallow new connections, terminate current connections and rollback active transactions, flush db block and redo log caches, update file headers, close files, synchronize control files, terminate processes TRANSACTIONAL - Disallow new connections, allow active transactions to complete, terminate current connections, flush db block and redo log caches, update file headers, close files, synchronize control files, terminate processes NORMAL - Disallow new connections, allow current connections to be completed and sessions logged out, flush db block and redo log caches, update file headers, close files, synchronize control files, terminate processes. Obviously, if the users did not log out of the sessions, the db would not come down. If ABORT is used, transactions will be rolled back upon startup (which is why it may take longer to open). In 9i, there was (is?) a known bug where an ABORT would cause the database to not open. Also note that the caches are not flushed. The database will be in an inconsistent state and is not valid for a backup if it is not in archivelog mode (though you may get lucky...). -Original Message-From: Ishrat Jehan [mailto:[EMAIL PROTECTED]]Sent: Tuesday, July 23, 2002 12:09 PMTo: Multiple recipients of list ORACLE-LSubject: RE: shutdown abort / startup restrict / shutdown vs. shutdown imm The differences are 1. shutdown abort - is more drastic, no new users are allowed to log in, disconnects current sessions without rollback, recovery however would have to be done when restarted. 2. shutdown immediate - no new users are allowed to log in, terminating current connections, transactions terminated are rollbacked, recovery would not happen at restart 3. shutdown normal - no new users are allowed to log in, transactions in progress are rollbacked, but would wait for all existing transactions to finish and users to log off, so if a user is logged in when shutdown normal is executed, it would wait forever. So shutdown immediate is much quicker and safer. ...Ishrat -Original Message-From: Jacques Kilchoer [mailto:[EMAIL PROTECTED]]Sent: Monday, July 22, 2002 9:53 PMTo: Multiple recipients of list ORACLE-LSubject: shutdown abort / startup restrict / shutdown vs. shutdown immedia > -Original Message- > From: April Wells [mailto:[EMAIL PROTECTED]] > > The solutions (the ones that I got) aren't good ones. > > Shutdown abort/startup restricted/ shutdown immediate... (a 'VALID > solution'???) This might be a naive question, but why is -> shutdown immediate better than -> shutdown abort / startup restrict / shutdown normal ? (That is assuming of course that no user / job will try to sneak in after you do the startup restrict)
RE: shutdown abort / startup restrict / shutdown vs. shutdown imm
Title: shutdown abort / startup restrict / shutdown vs. shutdown immediate The differences are 1. shutdown abort - is more drastic, no new users are allowed to log in, disconnects current sessions without rollback, recovery however would have to be done when restarted. 2. shutdown immediate - no new users are allowed to log in, terminating current connections, transactions terminated are rollbacked, recovery would not happen at restart 3. shutdown normal - no new users are allowed to log in, transactions in progress are rollbacked, but would wait for all existing transactions to finish and users to log off, so if a user is logged in when shutdown normal is executed, it would wait forever. So shutdown immediate is much quicker and safer. ...Ishrat -Original Message-From: Jacques Kilchoer [mailto:[EMAIL PROTECTED]]Sent: Monday, July 22, 2002 9:53 PMTo: Multiple recipients of list ORACLE-LSubject: shutdown abort / startup restrict / shutdown vs. shutdown immedia > -Original Message- > From: April Wells [mailto:[EMAIL PROTECTED]] > > The solutions (the ones that I got) aren't good ones. > > Shutdown abort/startup restricted/ shutdown immediate... (a 'VALID > solution'???) This might be a naive question, but why is -> shutdown immediate better than -> shutdown abort / startup restrict / shutdown normal ? (That is assuming of course that no user / job will try to sneak in after you do the startup restrict)
RE: shutdown abort / startup restrict / shutdown vs. shutdown imm
Title: shutdown abort / startup restrict / shutdown vs. shutdown immediate I don't necessarily agree that shutdown immediate is quicker. If you force a checkpoint prior to the shutdown abort the subsequent crash recovery upon startup is usually pretty fast. Parallel recovery could be a factor as well. - Rich -Original Message-From: kkennedy [mailto:[EMAIL PROTECTED]]Sent: Tuesday, July 23, 2002 1:14 PMTo: Multiple recipients of list ORACLE-LSubject: RE: shutdown abort / startup restrict / shutdown vs. shutdown immedia For openers, shutdown immediate is generally quicker than the combination of shutdown-abort/startup-restrict/shutdown-normal. It is also gentler. Consider the analogy of shutting down a Windows desktop computer. Is it preferable to do a standard software shutdown (and maybe tell Windows that you really want to end that hung process) or is it preferable to yank the plug out of the wall then plug it back in again, start up the machine, then shut it down gracefully? I always try to shut Windows down gracefully and only pull the plug when the damn thing is too stupid or brain dead to figure out what shutdown means. I do the same with Oracle. Kevin KennedyFirst Point Energy Corporation -Original Message-From: Jacques Kilchoer [mailto:[EMAIL PROTECTED]]Sent: Monday, July 22, 2002 7:53 PMTo: Multiple recipients of list ORACLE-LSubject: shutdown abort / startup restrict / shutdown vs. shutdown immedia > -Original Message- > From: April Wells [mailto:[EMAIL PROTECTED]] > > The solutions (the ones that I got) aren't good ones. > > Shutdown abort/startup restricted/ shutdown immediate... (a 'VALID > solution'???) This might be a naive question, but why is -> shutdown immediate better than -> shutdown abort / startup restrict / shutdown normal ? (That is assuming of course that no user / job will try to sneak in after you do the startup restrict)
RE: shutdown abort / startup restrict / shutdown vs. shutdown imm
Title: shutdown abort / startup restrict / shutdown vs. shutdown immediate Check this out too :) http://www.speakeasy.org/~jwilton/oracle/shutdown-abort-bad.html - Kirti -Original Message-From: kkennedy [mailto:[EMAIL PROTECTED]]Sent: Tuesday, July 23, 2002 12:14 PMTo: Multiple recipients of list ORACLE-LSubject: RE: shutdown abort / startup restrict / shutdown vs. shutdown immedia For openers, shutdown immediate is generally quicker than the combination of shutdown-abort/startup-restrict/shutdown-normal. It is also gentler. Consider the analogy of shutting down a Windows desktop computer. Is it preferable to do a standard software shutdown (and maybe tell Windows that you really want to end that hung process) or is it preferable to yank the plug out of the wall then plug it back in again, start up the machine, then shut it down gracefully? I always try to shut Windows down gracefully and only pull the plug when the damn thing is too stupid or brain dead to figure out what shutdown means. I do the same with Oracle. Kevin KennedyFirst Point Energy Corporation -Original Message-From: Jacques Kilchoer [mailto:[EMAIL PROTECTED]]Sent: Monday, July 22, 2002 7:53 PMTo: Multiple recipients of list ORACLE-LSubject: shutdown abort / startup restrict / shutdown vs. shutdown immedia > -Original Message- > From: April Wells [mailto:[EMAIL PROTECTED]] > > The solutions (the ones that I got) aren't good ones. > > Shutdown abort/startup restricted/ shutdown immediate... (a 'VALID > solution'???) This might be a naive question, but why is -> shutdown immediate better than -> shutdown abort / startup restrict / shutdown normal ? (That is assuming of course that no user / job will try to sneak in after you do the startup restrict)
RE: shutdown abort / startup restrict / shutdown vs. shutdown imm
Title: shutdown abort / startup restrict / shutdown vs. shutdown immediate What I sometimes use is alter system checkpoint startup force restrict shutdown normal -Rich -Original Message-From: Jacques Kilchoer [mailto:[EMAIL PROTECTED]]Sent: Monday, July 22, 2002 10:53 PMTo: Multiple recipients of list ORACLE-LSubject: shutdown abort / startup restrict / shutdown vs. shutdown immedia > -Original Message- > From: April Wells [mailto:[EMAIL PROTECTED]] > > The solutions (the ones that I got) aren't good ones. > > Shutdown abort/startup restricted/ shutdown immediate... (a 'VALID > solution'???) This might be a naive question, but why is -> shutdown immediate better than -> shutdown abort / startup restrict / shutdown normal ? (That is assuming of course that no user / job will try to sneak in after you do the startup restrict)
