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:[EMAIL PROTECTED]] > > > > 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
