Re: Shutdown Immediate Command

I suppose, in this case, if one supposes that the problem with the redo log is one of corruption that is occuring after the commit completes, and that Oracle is not picking up on the corruption, that if you shutdown abort and then startup the database, that instance recovery could fail because of said corruption. You would end up with an inconsistent database and would have to use one of the fun _* parameters to force it open!

I've seen problems with SHUTDOWN ABORTS in 7, but then only with databases in NOARCHIVELOG mode. I know that Oracle in Oracle8 will not allow you to overwrite a online redo log in which the dirty buffers related to the RBA of the log, even in ARCHIVELOG mode. This protects the online redo logs and ensures that instance recovery is possible. I'm not sure if this was the case in 7 because I have seen shutdown aborts in 7 cause the database to become unrecoverable.

I've never seen a problem with databases in ARCHIVELOG mode in terms of SHUTDOWN ABORT, as long as archived redo logs and online redo logs are available.

Robert

In article <942qdd$nrt$1_at_nnrp1.deja.com>,   jeremiah_at_wolfenet.com wrote:
> I don't need anyone to "prove" anything. All I would like to hear is
> one persuasive argument that suggests any scenario in which shutdown
> abort could "harm" a database as is purported to happen.
>
> In thousands of shutdowns on some of the most heavily transacted OLTP
> systems in the world, across four operating systems, I have never
> encountered any problem with crash recovery on Oracle.
>
> So, what's the scenario? I don't want proof, I want a reason other
 than
> speculation. What does having "enough transactions" have to do with
 it?
>
> commit = redo record successfully written = guaranteed recoverability
>
> --
> Jeremiah
>
> In article <3A63E10D.BF3817F5_at_ese.washington.edu>,
> Ion Manea <imanea_at_ese.washington.edu> wrote:
> > If he has enough transactions going on at once he won't have to wait
 very long.
> > Only use SHUTDOWN ABORT when nothing else will work. In other words
 ... after
> > KILL -9 and killing sessions has failed. After the shutdown
 immediately bring
> > the database back up and perform a normal shutdown.
> >
> > Daniel A. Morgan
> >
> > >
> > > This is one of those things that nobody can "prove" to your
> > > satisfaction. But if you routinely use shutdown abort, one of
 these
 days
> > > you will be sorry you did.
> > >
> > > Van
> > >
> > > <jeremiah_at_wolfenet.com> wrote in message
 news:93vogg$3gn$1_at_nnrp1.deja.com...
> > > > 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/
> >
> >
>
> Sent via Deja.com
> http://www.deja.com/
>

Sent via Deja.com
http://www.deja.com/ Received on Wed Jan 17 2001 - 17:30:07 CST