Re: Shutdown Immediate Command

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/