Re: shutdown abort

In article <3846E759.C2015FC6_at_wolfenet.com>,   Jeremiah Wilton <jeremiah_at_wolfenet.com> wrote:
> Jeff Hunter wrote:
> >
> > A shutdown abort is a last resort to get your database down.
Uncommitted
> > transactions are not resolved. When the database comes back up,
usually
> > there is some recovery that needs to be performed either manually or
Oracle
> > handles it automatically. This method is not recommeded by Oracle
and I can
> > agree. However, in theory, if you shutdown abort and backup all the
> > database files, recovery would still take place when the database
was
> > brought back up. This is one of those facts that you would like to
know,
> > but shoudn't rely on.
>
> 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.

This is correct as far as it goes, but it does not go far enough. The goof that I've seen with this is with unix system shutdowns. People think that a shutdown abort is the same as just killing off all the processes, and it is. What winds up happening is that operators do a shutdown abort or just shut down the machine without shutting down Oracle. This incorrectly assumes that all things that are considered written to disk actually are. So you wind up with incorrect or undone updates in the header files of the database, and when the recovery process starts up when Oracle is trying to come up, it either is fooled by the disordered roll forward and corrupts the db, or asks for media recovery that is impossible. Much, much more time is wasted until (or in some cases, if) the DBA can figure this out once than all the waiting for a proper shutdowns will ever require. So don't get into any shutdown abort habits.

>
> 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.

I'd say for the general lesser experienced DBA this is very bad advice.

> --
> Jeremiah
>

jg
--
These opinions mine
mailto:joel-garry_at_nospam.home.com
Remove nospam to mail
http://ourworld.compuserve.com/homepages/joel_garry

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Tue Dec 07 1999 - 15:30:23 CST