Misconception: ‘shutdown abort’ is bad

The best way to shut down a database is to force a checkpoint and then use the ‘shutdown abort’ command. In the few situations such as cold backups and version upgrades where consistent datafiles are required, the shutdown abort can be followed by a ‘startup restrict’ and a ‘shutdown immediate’.

A common misconception holds that ‘shutdown abort’ is somehow more dangerous or reckless than the other shutdown modes, and can result in data being lost. This is not the case. ‘Shutdown abort’ terminates the Oracle background and shadow processes, and removes the shared memory segments, effectively terminating a running instance. This leaves all committed transactions intact in the online redologs, even if the data associated with them has not been written to the datafiles. Upon startup, recovery is applied from the online logs beginning from the time of the most recent checkpoint. When recovery is complete, the database is opened for use. Transaction rollback occurs in the background after startup, so no user’s time is wasted waiting for all uncommitted transactions to roll back.

A common argument against ‘shutdown abort’ is that because instance recovery is necessary after a ‘shutdown abort,’ the total time down will “take as long as if shutdown immediate had been used on the way down.” This argument can be easily overcome. When starting up after a ‘shutdown abort,’ the amount of time spent in instance recovery depends largely upon how recently the last checkpoint was issued. By forcing a checkpoint immediately prior to issuing ‘shutdown abort,’ the redo required to complete crash recovery and bring the database open will be minimal.

The alternative in an active environment to ‘shutdown abort’ is ‘shutdown immediate,’ but immediate shutdowns take too long, rolling back transactions and performing other tasks while precious seconds pass by.

‘Shutdown abort’ can come in handy for very brief downtimes, such as those required to change a non-dynamic initialization parameter. In practice on Oracle instances with very large SGAs, such quick “bounces” can typically take as little as 25 seconds.

In order to expedite planned shutdowns and startups, the same scripts that are devised for reliable and fast startups at machine boot and shutdown should be used for manual shutdowns and startups. The scripts should be used because they can issue commands faster and more accurately than a human typing, and can be designed to resolve potential complications.

Jeremiah Wilton
jwilton@speakeasy.net

5 thoughts on “Misconception: ‘shutdown abort’ is bad

  1. Hello,
    I agree with you. In order to shutdown quickly, dbas first killing processes with kill -9 on the OS side and then issue shutdown immediate, whizh makes him feel ‘Wow, I did not use shutdown abort’.
    This is satisfaction is only a cheat, and that does not solve the abnormality in the process you did. Thus, using the above method is smarter, and makes feel better. And in the alert log what you see is: What really happened.

    Thanks for the article!
    Regards,
    Derya.

  2. Hello, there exists different opinions which have good rationale behind. Excerpt form Burlescon:

    Killing Oracle User Processes
    There are a number of reasons to kill Oracle user processes. (Note: By “killing Oracle processes” I mean killing nonessential database processes.) These nonessential database processes usually consist of terminal sessions that are left connected after real work has been accomplished. These active sessions result in problems when the database has to be shut down for either backup or maintenance operations. As long as there is an active session, a normal-mode shutdown will hang. Coming in on Monday to discover that the database couldn’t shut down, and thus couldn’t be backed up, is a frustrating experience. Oracle has provided the immediate shutdown mode, but this isn’t always reliable and, in some situations, can result in an inconsistent backup. The abort shutdown option will shut down the database, but you then have to restart and perform a normal shutdown before any backup operations, or risk an inconsistent backup. Therefore, it is important for the DBA to know how to kill these processes before operations of this type are accomplished.

  3. Wow, thanks for citing me here. Regarding the Burleson quote, I don’t think this is Don’s most current opinion on the topic. For instance, what is an example of a situation when ‘shutdown immediate’ “can result in an inconsistent backup”? Also, the Burleson citation fails to address the assertion that ‘checkpoint-abort-restrict-immediate’ is much faster than just ‘shutdown immediate’ in a large number of environments (talking 9i and below here).

    As of 10gR2, ‘immediate’ is more reliable in more environments. Now, most people can just use ‘immediate’. YMMV. Also, more troubleshooting/root cause discovery options exist for a slow ‘immediate’ shutdown.

    Jeremiah Wilton
    ORA-600 Consulting
    http://www.ora-600.net

  4. Hi Jeremiah, I believe that your post is talking about database in archivelog mode. May I know how about if the database in noarchivelog mode. Is it required recover database after shutdown abort then startup restrict?

    Thank you in advance

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s