Re: Killing pmon service - does Oracle backout?

"Barker, Tony" wrote:

> Hi!!,
>
> I recently hosed our test system and could not get into any utility
> applications (SQLPLUS, SVRMGRL, ..) and I needed to bring down some hung
> instances. (The system is Sun Solaris release 2.6 using Oracle 8.1.6) I
> ended up canceling the PMON task of the various instances to get them to
> come down. They all terminated and I was sure that I was going to have to
> do a recovery to get them to come back up. To my surprise all the instances
> came up fine after getting everything functionable.
>
> Does anyone know what happens when you cancel PMON that allowed this
> to happen? Did SMON clean things up before the instances terminated? I
> hope I don't have a false sense of comfort!?
>
> Thanks in advance for your input!!!
>
> Tony Barker
> DBA - State of Indiana
> tbarker_at_doit.state.in.us (317)232-0719
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Barker, Tony
> INET: tbarker_at_doit.state.in.us
>

Tony,

    I would have found 'shutdown abort' cleaner than killing PMON. You didn't have any recovery to do because it's automatic ... Very briefly the redo log files contain the delta between memory, where everything happens, and datafiles, the 'persistent' part of your DB - at least as far as committed transactions are concerned. You need to do a recovery when the delta is MORE than the current redo log files, for instance because you had to restore an old copy of one of your datafiles, in which case Oracle will ask you to provide all the redo log files since then. In a 'normal' case, i.e. shutting down 'abort', killing pmon, unplugging the computer, Oracle is big enough to make sense of current files. However, when there is a lot of stuff in the current redo logs, applying them to the datafiles can take some time, which delays the availability of your database to your users. IMHO, if it was fast in your case it was just by luck - the synchronisation of memory and datafiles (checkpoint) was not too far off.

Regards, Received on Tue Jan 16 2001 - 13:24:41 CST