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 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
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 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
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 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
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 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
RE: shutdown abort / startup restrict / shutdown vs. shutdown imm
long response 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 shutdown abort is not evil -- I'm not one who thinks it is evil, I'm just not convinced
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 reasonablyconfident that the debris will not puncture my tires. If I'm in a big hurry and driving by the construction site issignificantly 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
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
M5AE(EN9F]R;6%T:6]N(-O;G1A:6YE9!I;B!T:ES(4M;6%I;!IR!S
M=')I8W1L2!C;VYF:61E;G1I86P@86YD(9OB!T:4@:6YT96YD960@=7-E
M(]F('1H92!A91R97-S964@;VYL3L@:70@;6%Y(%LV\@8F4@;5G86QL
M2!PFEV:6QE9V5D(%N9]OB!PFEC92!S96YS:71I=F4N(!.;W1I8V4@
M:7,@:5R96)Y(=I=F5N('1H870@86YY(1IV-L;W-UF4L('5S92!OB!C
M;W!Y:6YG(]F('1H92!I;F9OFUA=EO;B!B2!A;GEO;F4@;W1H97(@=AA
M;B!T:4@:6YT96YD960@F5C:7!I96YT(ES('!R;VAI8FET960@86YD(UA
M2!B92!I;QE9V%L+B @268@6]U(AA=F4@F5C96EV960@=AIR!M97-S
M86=E(EN(5RF]R+!P;5AV4@;F]T:69Y('1H92!S96YD97(@:6UM961I
M871E;'D@8GD@F5T=7)N(4M;6%I;X*D-OG!OF%T92!37-T96US+!)
M;F,N(AAR!T86ME;B!E=F5R2!R96%S;VYA8FQE('!R96-A=71I;VX@=\@
M96YS=7)E('1H870@86YY(%T=%C:UE;G0@=\@=AIR!E+6UA:6P@:%S
M()E96X@W=E'0@9F]R('9IG5S97,N(!792!A8V-E'0@;F\@;EA8FEL
M:71Y(9OB!A;GD@9%M86=E('-UW1A:6YE9!AR!A(')EW5L=!O9B!S
M;V9T=V%R92!V:7)UV5S(%N9!A9'9IV4@6]U(-AG)Y(]U=!Y;W5R
M(]W;B!V:7)UR!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).
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
M5AE(EN9F]R;6%T:6]N(-O;G1A:6YE9!I;B!T:ES(4M;6%I;!IR!S
M=')I8W1L2!C;VYF:61E;G1I86P@86YD(9OB!T:4@:6YT96YD960@=7-E
M(]F('1H92!A91R97-S964@;VYL3L@:70@;6%Y(%LV\@8F4@;5G86QL
M2!PFEV:6QE9V5D(%N9]OB!PFEC92!S96YS:71I=F4N(!.;W1I8V4@
M:7,@:5R96)Y(=I=F5N('1H870@86YY(1IV-L;W-UF4L('5S92!OB!C
M;W!Y:6YG(]F('1H92!I;F9OFUA=EO;B!B2!A;GEO;F4@;W1H97(@=AA
M;B!T:4@:6YT96YD960@F5C:7!I96YT(ES('!R;VAI8FET960@86YD(UA
M2!B92!I;QE9V%L+B @268@6]U(AA=F4@F5C96EV960@=AIR!M97-S
M86=E(EN(5RF]R+!P;5AV4@;F]T:69Y('1H92!S96YD97(@:6UM961I
M871E;'D@8GD@F5T=7)N(4M;6%I;X*D-OG!OF%T92!37-T96US+!)
M;F,N(AAR!T86ME;B!E=F5R2!R96%S;VYA8FQE('!R96-A=71I;VX@=\@
M96YS=7)E('1H870@86YY(%T=%C:UE;G0@=\@=AIR!E+6UA:6P@:%S
M()E96X@W=E'0@9F]R('9IG5S97,N(!792!A8V-E'0@;F\@;EA8FEL
M:71Y(9OB!A;GD@9%M86=E('-UW1A:6YE9!AR!A(')EW5L=!O9B!S
M;V9T=V%R92!V:7)UV5S(%N9!A9'9IV4@6]U(-AG)Y(]U=!Y;W5R
M(]W;B!V:7)UR!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).
--
===
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
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
M5AE(EN9F]R;6%T:6]N(-O;G1A:6YE9!I;B!T:ES(4M;6%I;!IR!S
M=')I8W1L2!C;VYF:61E;G1I86P@86YD(9OB!T:4@:6YT96YD960@=7-E
M(]F('1H92!A91R97-S964@;VYL3L@:70@;6%Y(%LV\@8F4@;5G86QL
M2!PFEV:6QE9V5D(%N9]OB!PFEC92!S96YS:71I=F4N(!.;W1I8V4@
M:7,@:5R96)Y(=I=F5N('1H870@86YY(1IV-L;W-UF4L('5S92!OB!C
M;W!Y:6YG(]F('1H92!I;F9OFUA=EO;B!B2!A;GEO;F4@;W1H97(@=AA
M;B!T:4@:6YT96YD960@F5C:7!I96YT(ES('!R;VAI8FET960@86YD(UA
M2!B92!I;QE9V%L+B
@268@6]U(AA=F4@F5C96EV960@=AIR!M97-S
M86=E(EN(5RF]R+!P;5AV4@;F]T:69Y('1H92!S96YD97(@:6UM961I
M871E;'D@8GD@F5T=7)N(4M;6%I;X*D-OG!OF%T92!37-T96US+!)
M;F,N(AAR!T86ME;B!E=F5R2!R96%S;VYA8FQE('!R96-A=71I;VX@=\@
M96YS=7)E('1H870@86YY(%T=%C:UE;G0@=\@=AIR!E+6UA:6P@:%S
M()E96X@W=E'0@9F]R('9IG5S97,N(!792!A8V-E'0@;F\@;EA8FEL
M:71Y(9OB!A;GD@9%M86=E('-UW1A:6YE9!AR!A(')EW5L=!O9B!S
M;V9T=V%R92!V:7)UV5S(%N9!A9'9IV4@6]U(-AG)Y(]U=!Y;W5R
M(]W;B!V:7)UR!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
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
M5AE(EN9F]R;6%T:6]N(-O;G1A:6YE9!I;B!T:ES(4M;6%I;!IR!S
M=')I8W1L2!C;VYF:61E;G1I86P@86YD(9OB!T:4@:6YT96YD960@=7-E
M(]F('1H92!A91R97-S964@;VYL3L@:70@;6%Y(%LV\@8F4@;5G86QL
M2!PFEV:6QE9V5D(%N9]OB!PFEC92!S96YS:71I=F4N(!.;W1I8V4@
M:7,@:5R96)Y(=I=F5N('1H870@86YY(1IV-L;W-UF4L('5S92!OB!C
M;W!Y:6YG(]F('1H92!I;F9OFUA=EO;B!B2!A;GEO;F4@;W1H97(@=AA
M;B!T:4@:6YT96YD960@F5C:7!I96YT(ES('!R;VAI8FET960@86YD(UA
M2!B92!I;QE9V%L+B @268@6]U(AA=F4@F5C96EV960@=AIR!M97-S
M86=E(EN(5RF]R+!P;5AV4@;F]T:69Y('1H92!S96YD97(@:6UM961I
M871E;'D@8GD@F5T=7)N(4M;6%I;X*D-OG!OF%T92!37-T96US+!)
M;F,N(AAR!T86ME;B!E=F5R2!R96%S;VYA8FQE('!R96-A=71I;VX@=\@
M96YS=7)E('1H870@86YY(%T=%C:UE;G0@=\@=AIR!E+6UA:6P@:%S
M()E96X@W=E'0@9F]R('9IG5S97,N(!792!A8V-E'0@;F\@;EA8FEL
M:71Y(9OB!A;GD@9%M86=E('-UW1A:6YE9!AR!A(')EW5L=!O9B!S
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)
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 ofshutdown-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 standardsoftware 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 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 ofshutdown-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 standardsoftware 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 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, transactionsterminated 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 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, transactionsterminated 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 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 immediatetook 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 say5 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 ofshutdown-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 standardsoftware 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 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, transactionsterminated 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
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 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 immediatetook 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 say5 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 ofshutdown-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 standardsoftware 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
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 SNIP 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 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 immediatetook 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 say5 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 ofshutdown-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 standardsoftware 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
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 processor 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 immediatetook 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 say5 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 ofshutdown-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 standardsoftware 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
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 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 reasonablyconfident that the debris will not puncture my
tires. If I'm in a big hurry and driving by the construction site
issignificantly 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 processor 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 immediatetook 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 say5 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
