John,
In 7.3.4, wasn't background TX recovery already a feature? In other
words, weren't large rollbacks delayed until after the database was
already open and available?
--
Jeremiah Wilton
http://www.speakeasy.net/~jwilton
On Fri, 7 Feb 2003, John Kanagaraj wrote:
> 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!
>
> > -----Original Message-----
> > From: Jeremiah Wilton [mailto:jwilton_at_speakeasy.net]
> >
> > 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!
> >
> > :-)
> >
> > 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).
Received on Fri Feb 07 2003 - 18:38:42 CST
