Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Shutdown Immediate Command

Re: Shutdown Immediate Command

From: David Fitzjarrell <oratune_at_aol.com>
Date: Mon, 15 Jan 2001 21:19:34 GMT
Message-ID: <93vpgt$4h2$1@nnrp1.deja.com>

In our last gripping episode jeremiah_at_wolfenet.com wrote:
> In article <93ve7n$prn$1_at_nnrp1.deja.com>, David Fitzjarrell
> <oratune_at_aol.com> wrote:
>
> > The 'shutdown immediate' command is probably your best bet at this
> > point. There are other 'options', namely 'shutdown abort', however
 I
> > would not recommend such a drastic act as 'shutdown abort' does
> > absolutely no 'bookkeeping' or 'cleanup' whatsoever which could
 leave
> > your instance in an unusable (unrecoverable) state.
>
> I don't understand the specific scenario you envision in which
 shutdown
> abort could "leave your instance in an unusable (unrecoverable)
 state."
> I don't believe this is, in fact, the case. One of Oracle's greatest
> features is its robustness, and the "commit writes redo" rule. This
> rule allows you to walk up to a running server, unplug it from the
 wall,
> plug it back in, and have all the data that was committed before the
> crash available after the crash.
>
> 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.
>
> 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.
>
> --
> Jeremiah
>
> > In our last gripping episode craig wilson <craig_d_wilson_at_yahoo.com>
> > wrote:
> > > I have an Oracle Server running Oracle8i on a Solaris Box.
> > >
> > > Due to a problem with the redo log, which I do not want to get
 into
> > > right now,
> > > the Oracle Server will "hang" on occassion.
> > >
> > > When this occurs I am expected to stop and start the Oracle
 server.
> > >
> > > I have been provided instructions to take in these cases.
> > > The instructions say to issue a "shutdown immediate;" command
 after
 I
> > > have done a "connect internal" command.
> > >
> > > The "shutdown immediate;" command appears to hang and do nothing.
> > > Any other ideas on how to do this.
> > >
> > > I'm really an NT/2000/Netware Administrator, so please speak
 slowly
 and
> > > clearly since I am a little out of my league on this one :>
>
> Sent via Deja.com
> http://www.deja.com/
>

They could take much longer -- you have been fortunate. I have used 'shutdown abort' when necessary and there have been times, albeit few and far between, where the instance would not restart after a shutdown abort. True, there were other circumstances in conjunction with the aborted shutdown that created the unusable instance however I do shy away from flagrant use of 'shutdown abort'. I would much rather err on the side of safety. There are also issues with this situation you failed to recognise, as the redo log problems the original poster commented upon. With unresolved redo log problems this instance could very well end up unusable.

Yes, your post is correct in its assessment of the shutdown mechanism, however you should read, think and comprehend before you post such information. The mechanism that resolves uncommitted transactions is, in this particular case, the same mechanism that is causing the instance to be shut down.

--
David Fitzjarrell
Oracle Certified DBA


Sent via Deja.com
http://www.deja.com/
Received on Mon Jan 15 2001 - 15:19:34 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US