What are the effects of a shutdown abort?

[dbstudent]

My database will not shutdown using the SHUTDOWN IMMEDIATE option It hang with the following error message for about 20 minutes.

OPIRIP: Uncaught error 447. Error stack:
ORA-00447: fatal error in background process
ORA-00604: error occurred at recursive SQL level 2
ORA-01089: immediate shutdown in progress - no operations are permitted
oracle@londata1:/u01/app/oracle/admin/onedbsp1/bdump >

What are the consequences of using the SHUTDOWN ABORT option.

 

[Thargy]

dbstudent,

a shutdown abort is effectively crashing the database.

You may get away with this, but I have found that it usually leaves at least one file needing recovery and restoration.

This is usually whichever temp tablespace happened to be in use when the abort occurred.

Obviously in-flight transactions will likely be lost, and anything that was happening at the time of the abort will also be lost. Buffered and/or cached data may also be lost.

I can't predict all the ramifications, but I'd suggest that once you ge the beastie back up and working, you do get RMAN to do a backup for you.

Regards

T

Grinding away at things Oracular

 

[SantaMufasa]

To comment further from Thargtheslayer's post:

Doing a "shutdown abort" is virtually the same as shutting off the power to the computer...as such, Oracle does not have time to gracefully do a CHECKPOINT and gracefully close the files.

I have found that it usually leaves at least one file needing recovery and restoration...This is usually whichever temp tablespace happened to be in use when the abort occurred.

Following either a power interruption or a SHUTDOWN ABORT, the next time that you startup the database instance, Oracle automatically does a RECOVER DATABASE to place the database at a point where it would be if you had done a graceful SHUTDOWN IMMEDIATE. Unless some damage occurred to a database datafile, you will not need to restore any files.

Obviously in-flight transactions will likely be lost, and anything that was happening at the time of the abort will also be lost. Buffered and/or cached data may also be lost.

All of the above happen during a SHUTDOWN IMMEDIATE, as well. If you shutdown the database before in-flight transactions commit, then their changes are rolledback, either before the shudown as part of a SHUTDOWN IMMEDIATE, or after the next instance STARTUP, as part of a power failure or a SHUTDOWN ABORT.

I'd suggest that once you ge the beastie back up and working, you do get RMAN to do a backup for you.

Backups are always a good thing to do.

Mufasa
(aka Dave of Sandy, Utah, USA)
[I can provide you with low-cost, remote Database Administration services: see our website and contact me via www.dasages.com]

 

[ksbrace]

If you do a alter system checkpoint prior to the shutdown abort, all you need to do is restart the db in restrict mode, then do a shutdown immediate, do what you need to do while it's down and then startup. This is right from metalink/otn. Because sometimes users are logged in and a normal shutdown just won't cut it for you.