Mark has hit on the crux of the issue. Most of us have expectations from users and management that we will have the databases available as much as possible. Downtime costs money and should be avoided.
That said, we will eventually need downtime for one reason or another. The question becomes how do we minimize it. I use shutdown abort to increase availability. If you 'alter system checkpoint' before you shutdown abort, then automatic crash recovery is extremely fast, since only a few bytes of redo need to be applied. On the other hand, if you shutdown immediate, you may be waiting all day for those temp segments to get deallocated or for that large transaction to get rolled back. With abort, the deallocation doesn't have to happen (it was unnecessary anyway), and the rollback is deferred until after the database is open again and already available to users. So use your test systems, load them up like production, and try both. I bet in 9 out of 10 cases, checkpoint+abort+startup will be much faster than shutdown immediate+startup. Of course, there are cases when you need a consistent database while down. Switching to archivelog mode is one example. For those, checkpoint+abort+startup restict+shutdown immediate should do the trick. This may only be useful if you are running a system that is busy enough to have immediate take a long time. I don't know why I am such a tyrant on this issue. I guess I think it exposes fuzzy thinking. Yes I have driven to work many times without accidents, but comparing this to many succesful aborts is inaccurate. Cars are not designed in a fundamental way not to strike each other. People have to be careful when driving not to hit each other. Oracle, on the other hand, is fundamentally designed to start up after a shutdown abort. I have reason to expect that I may have an accident if I am not careful while driving. But so far, nobody has produced current bug numbers and issues or even solid reasoning that leads me to believe that using shutdown abort is "dangerous" or won't work consistently. If abort is more dangerous than immediate, can we get a list of other fully supported features of Oracle that are considered "dangerous?" We should call support and file a bug, no? It reminds me of instructions for doing something I once found on MetaLink: One of the steps read: "Start up the database carefully." -- Jeremiah Wilton http://www.speakeasy.net/~jwilton On Wed, 2 Apr 2003, Mark Richard wrote: > I don't think the issue is so much about whether Oracle recovery can handle > a database crash or not. I think the issue is whether you want to spend > the time of going through that process. I'm sure recovery can also handle > the server being powered cycled but how many people do that without > shutting down Oracle first? > > Since we had a car analogy already in this thread... I'm confident that > the seat belts in my car work but I'm in no rush to test them out, and even > if they do work I'm likely to end up bruised anyway. > > I guess the bruising my equate to overtime spent recovering the database... > Oh, I hate trying to make really good analogies. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jeremiah Wilton INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- 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).
