Re: Unable to shutdown the database

| On Mon, 05 Nov 2012 20:41:00 -0800, zigzagdna wrote:
|
|
| > I can give you 10 different links which say there is nothing wrong with
| > shutdown abort. I agree that one should try shutdown immediate first;
| > but sometimes it takes forever!!!
|
| It doesn't matter what your "10 different links" say. It matters what the
| manual says. And the manual says to use "shutdown immediate". If it takes
| forever, it's probably an old version or a bug of some kind and you
should
| work with Oracle support to resolve it. If shutdown immediate is taking
| forever, there is a problem. Your "10 different links" will not resolve
| it. Oracle support might.
|

Oracle Corporation has claimed for years that you can pull the plug on the server and if the machine restarts the database will recover quite happily. This is why a "shutdown abort" should be perfectly safe. (For the speed readers, go back and look at the word SHOULD).

The fact that very few DBAs will deliberately do frequent shutdown aborts means that there are code paths that there are probably circumstances where a recovery after instance failure has not been tested - and that's why you should avoid frequency shutdown aborts, especially if you are using some of the exciting newer features of Oracle.

Nevertheless there may be cases where the application code makes it impossible to do a clean shutdown within the required time frame and you need to do an abort. To minimise the frequency with which you need to abort you could use your favourite scripting language to do as I did many years ago:
a) Check sum(used_urec) from v$transaction - if the result is "very large" (interpretation is system dependent) then shutdown abort b) Spawn a watching process that sleeps for N minutes c) Initiate a shutdown immediate

If the watching process wakes up and finds the database still up, then it issues a shutdown abort. Either way it terminates itself The driving process will either get a "succesful shutdown", or "instance died" - so it can tell how the database went down.

If you really feel it's necessary, you can always startup restrict / shutdown immediate after an abort.

By the way - since a startup SHOULD (note that word again) be successful after any type of instance failure, then there SHOULD be no need to startup and shutdown after an abort - it's the database is going to survive it's going to startup whether you start it 10 seconds or three hours later. The only reason why you might want to get to a "clean shutdown" state is if you follow up with a backup strategy that doesn't copy the online redo logs.

Bottom line - shutdown abort SHOULD always be safe, but for statistical reasons DBAs don't want to assume that the instance recovery code-path is perfect in every way: so we only do aborts if we really have to (which means the recovery code-path doesn't get very much field-testing).

-- 

Regards

Jonathan Lewis
http://jonathanlewis.wordpress.com/all-postings