Re: shutdown abort

On Wed, 08 Dec 1999 08:40:39 -0500, Kenneth C Stahl <BlueSax_at_Unforgettable.com> wrote:

>Joel Garry wrote:
>>
>> 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.
>>
>
>There are also a lot of dba's who do not understand how to write rc2.d and
>rc0.d entries to ensure that the database is taken down properly. What
>makes this even worse is that the dbshut which is provided by oracle
>assumes a "shutdown normal" and that is almost never correct on a
>production system.
>

In general, most administrators I have seen, learns to write shutdown, startup scripts. Some might not learn to change the shutdown script from Oracle.

I will recommend not to shutdown Oracle abort.

In my previous job I had 3 larger Oracel DB's. All 7.2.3.0.0. The biggest had a SGA of 700 MB. It took in general 30 sec-60 sec to shutdown immediate. Only if it hung for strange reasons, it was aborted (after sufficient time to shutdown immediate).

After startup after an abort (and immediate) I alwasy checked the alert log carefully, and shtudown immediate follow by startup, to ensure it could function normal (again).

Now, at this site, there are a bigger Oracle, current 7.3.4.0.0, that have an SGA of 400 MB. It take in general 20-25 sec to shutdown immediate and I have not (yet) had to abort it. There are heavy activity in the DB but it run smootly as silk and I have a very very boring alert log with almost only messages of backup mode on/off.

It will be converted to an 8.1.5 (8i) soon (export, import - not! migrate)

Finally I will say that I have a very nice situation regarding backup.

I can make a cold backup of the Oracle database (8 GB currently - adding 2 GB/month) in 1 min! Yes, you read right, and the same with hot backup. According to specification I will be able to do the same when the DB is 1 TB.

This is possible because of soem external disk devices (NFS mounted hard) that can make snapshot of themselves, very quickly.

An PS: I really like to be able to do a hot backup and know it work., but don't like if the backup prevent the database from starting in case of a crash.

I have experienced this problem when I had a database in backup mode and crashing because of failty hardware (memory error) - it would not start automatic again (7.2.3.0.0). I don't know if that still is a problem in newer versions of Oracle.

Bent Mathiesen, bm_at_superusers.dk

PS: Do always follow up on ORA-00600 errors! Received on Wed Dec 22 1999 - 14:33:14 CST