Rajesh, There are unknowns with every feature. ABORT is a feature just as IMMEDIATE is. In version 7, I encountered a bug with IMMEDIATE that required recovery from a backup, and eventually manual BBED'ing of the SYSTEM datafile by Oracle BDE. SO maybe we shouldn't use immediate either. I'll just call all the users and ask them to log off. "Hello? My name is is Jeremiah from Amazon.com, and I was wondering if you could stop buying books right now..."
I would submit that ABORT is one of the most tested features of Oracle 8 and 9 - not at Oracle, but at customer sites - because it is one of the most used. No serious HA site is still using IMMEDIATE on a consistent basis, because it is unreliable. Consistent performance requires the use of ABORT for reliable shutdowns and for cluster failovers. Oracle even recommends it in their FailSafe manual. So my advice is to cite the exact circumstances, test case and number of your bug for those few still using version 7. Many features were screwed in V.7. I would submit that in your case, with an unresponsive instance, you may have had problems outside your database that contributed to the need for recovery, and are mistakenly fingering ABORT as the cause. Since Oracle 7.3.4, I have not heard reliable accounts of any problems with ABORT. This is mainly because transactions are transactions, and they have to have a response from the O/S and recorded their redo before a COMMIT is returned to the application. That makes them recoverable as soon as they are considered successful by the app. -- Jeremiah Wilton http://www.speakeasy.net/~jwilton On Mon, 3 Feb 2003, Rajesh Dayal wrote: > I totally agree................ > > I am witness of one of these untested combination resulting in "true > disaster" . > > And the combination was shutdown immediate to an extremely database > (with no response), followed by shutdown abort and all the data > files got corrupted. We could not recover that big production > database from that corruption of all the datafiles and we had to go > back to Old and valid set of backup. That was Oracle 7.3.4 running > telecom database around a year back. > > Sine then I am too shaky on using shutdown abort, I avoid it unless > it is as extreme urgency and if at all I have to use it, I never do > it after shutdown immediate !!!! > > -----Original Message----- > > I have to say that I still have an emotional > response to 'shutdown abort', despite knowing > that logically it ought to be perfectly safe. > > The reason for this is the lack of stress testing > that goes on at Oracle Corp. In most (if not > all) cases, the only blanket stress test that > the software gets is from production end-users. > > How many millions of times per day is the > message passing mechanism for parallel > query tested ? And it still has bugs. > > How many times per day is shutdown abort > tested - how many possible combinations of > events coinciding with a shutdown abort have > not yet received a single test ? > > I find it very hard to shake the feeling that > somewhere there is a code path that will > eventually result in a big problem for someone > once they switch to a regular shutdown abort. -- 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).
