That is correct. TX recovery was done in the background and foreground (if a user would hit a transaction that needed to be rollback, but wasn't yet by the background).
Anjo. ----- Original Message ----- To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Saturday, February 08, 2003 1:38 AM > 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). > -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Anjo Kolk 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).
