Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Shutdown Abort

RE: Shutdown Abort

From: Robert Freeman <robertgfreeman_at_yahoo.com>
Date: Tue, 3 Jul 2007 11:48:49 -0600
Message-ID: <KEEDIPJOJLCHPPAIDPDOMEAFECAA.robertgfreeman@yahoo.com>


>> I am not trying to start an argument here
No argument, just dialogue! :-)

>> Shutdown abort does not check file status, checkpoint status,
transactions, or anything else.
No.. but so what? Instance/crash recovery is built to deal with these issues. Thats it's job and it better work, reliably, or I'm getting another database. That is the way the database is built. I will say that I always recommend (as have others) that you do a checkpoint before you do a shutdown abort. This can reduce the time it takes to cycle the database.

There were some odd issues in the past that might occur with a startup that followed a shutdown abort. For example, if you tried to truncate a table in 8.x and < while a transaction was being rolled back in the background, you would get an ORA-0600 ... thats been fixed though.

>> until Oracle endorses it as the standard method to shutdown an instance,
its a good idea to avoid it.

Looking in the Admin guide I find each method of shutting down the database described. It says to use shutdown to shutdown the database in "Normal" situations.... anyone ever use just shutdown??? Also, a hung shutdown in 10g will timeout after an hour. One could infer from this document that shutdown is the normally accepted and recommended way of taking down an Oracle database. *chuckle*

Immediate shutdowns have *specific* criteria listed, including the creation of unattended backups. Still, I've seen a lot of times when shutdown immediate hangs. Not a good situation for scripted stuff, since the whole script ends up hanging (unless you add more complex scripting that checks for hangs, etc). So, technically, this is not a generally recommended means of shutting down the database according to the docs. I will say that on default Oracle installs on Win, that oradim will setup the service to do a shutdown immediate, so this may be an indirect endorsement by Oracle of shutdown immediate.

There is no real criteria defined in the docs for shutdown transactional.

Shutdown abort seems right out in the docs. The docs say one should only perform a shutdown abort in three specific situations: imminent power loss, applications that are not behaving properly or problems starting the instance. I would add that another criteria is that the database has to be back up and running in two minutes or less.

So, the docs do not seem to mimic reality here...

Looking through metalink for "shutdown abort", one finds a number of articles that essentially seem to lead to the conclusion that shutdown abort is the better way to go. There are a number of bulletins that indicate that shutdown immediate will hang here, or hang there (some bugs, some expected behavior). In these cases, Oracle recommends shutdown abort. To me this indicates they clearly have confidence in the shutdown abort command. If shutdown immediate is going to hang, your SLA's are going out the window. If shutdown abort will consistently work, then your SLA's seem to be safe.

As others have echo'd, and as men greater than I (not a hard thing) have said before, shutdown abort has worked for us since > 7.x, without a problem. It's use has allowed us to meet SLA's with a greater level of assurance, whereas shutdown or shutdown immediate does not.

As always, YMMV...

RF

Robert G. Freeman
Oracle Consultant/DBA/Author
Principal Engineer/Team Manager
The Church of Jesus Christ of Latter-Day Saints Father of Five, Husband of One,
Author of various geeky computer titles
from Osborne/McGraw Hill (Oracle Press)
Oracle Database 11g New Features Now Available for Pre-sales on Amazon.com! Sig V1.1

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Jul 03 2007 - 12:48:49 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US