RE: re SHUTDOWN ABORT -- was RE: Debate on rc commands Solaris an

Just to add another aspect: I had a problem once with a 7.3.4 database when we performed a shutdown abort. Now this database was in the middle of a complete refresh of a rather large Table from another database. The shutdown abort occurred properly, but the db took its sweet time to come up while it rolled back all the snapshot data....

The key to this issue, as with any other aspect of DB admin: Know thy application, Know thy database!

John Kanagaraj
Oracle Applications DBA
DBSoft Inc
(W): 408-970-7002

I don't know what the future holds for me, but I do know who holds my future!

• The opinions and statements above are entirely my own and not those of my employer or clients **

> -----Original Message-----
> From: Jeremiah Wilton [mailto:jwilton_at_speakeasy.net]
> Sent: Friday, February 07, 2003 1:59 PM
> To: Multiple recipients of list ORACLE-L
> Subject: RE: re SHUTDOWN ABORT -- was RE: Debate on rc
> commands Solaris
> an
>
>
> Hi Robert,
>
> For problem 1, you mean transaction recovery, i.e. rollback, right?
> Did this problem happen only with fast start parallel rollback or also
> with normal version 7-on background TX rollback? How about user
> rollbacks (user 1 rolls back large transaction, user 2 truncates the
> table in the mean time). In other words, does it really have anything
> specifically to do with ABORT? Also, do you have a bug number for
> that?
>
> For problem 2, do you have a version where you have experienced this
> problem, or a bug number? As you know, the redologs also contain
> entries for the changes to the controlfile, so partial write or not,
> instance recovery should repair a partial write to the controlfile.
>
> Finally, I'm pretty sure you can be certain you have checkpointed at
> any given time. If you haven't, the database will soon run out of
> online redologs and stop until a checkpoint does complete!
>
> Forcing a checkpoint is a great idea -- for speeding up instance
> recovery -- but it doesn't make ABORT any more or less safe.
>
> My motto is: Shutdown abort is not shutdown abhorrent!
>
> :-)
>
> --
> Jeremiah "Shutdown Abort" Wilton
> http://www.speakeasy.net/~jwilton
>
> On Thu, 6 Feb 2003, Robert Freeman wrote:
>
> > RE: re SHUTDOWN ABORT -- was RE: Debate on rc commands
> Solaris andLet me
> > throw in my 2 cents worth on this topic. There are two problems with
> > SHUTDOWN ABORT that I have experienced in the past.
> >
> > 1. Before 9i (it appears to be fixed in 9i) if you inserted
> data in a table,
> > then did a shutdown abort, if after restarting the
> database, you tried to
> > truncate the table while the database was performing
> recovery on that table,
> > the database would crash.
> >
> > 2. Assume that you have applications that are dynamically
> doing things like
> > adding and dropping tablespaces. WHat happens if the app is
> in the middle of
> > such an operation and it's in the middle of writing new
> records to the
> > control file. What is the result if you shutdown abort in
> the middle of this
> > write, before it's complete. We experienced a situation
> like this earlier
> > this week.
> >
> > I've always been opposed to shutdown abort unless you are
> certain that you
> > have checkpointed and that there are no user sessions
> operating on the
> > database.
> >
> > -----Original Message-----
> > From: root_at_fatcity.com [mailto:root_at_fatcity.com]On Behalf
> Of Jamadagni,
> > Rajendra
> >
> > When we do cold backups, our script issues 'shutdown
> immediate', if within
> > 3 minutes the db is not shut down, we cancel and issue
> 'shutdown abort'. In
> > either case, we (again issue) startup/shutdown to make it
> clean before
> > taking backup.
> >
> > We don't worry about users connecting, as during cold
> backup window, the
> > listeners are shutdown. For us it is a circus (kind of) because our
> > production DBs talk to each other, so we have to follow a
> specific seq of
> > shutdown/startup.
> >
> > So far we haven't encountered any major issues because of
> 'shutdown abort'
> > ... (heavily knocking on the wood !!)
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Jeremiah Wilton
> INET: jwilton_at_speakeasy.net
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: John Kanagaraj
  INET: john.kanagaraj_at_hds.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).