Sujatha, There is never, ever, ever, ever, a perfect time to use _allow_resetlogs_corruption. Never ever. The results of such an operation may not be known for hours, days or weeks. Look which datafile it is that needs recovery, system01.dbf... which means that if you force open the database you could (could) end up with an inconsistent data dictionary. It gives me the willies everytime someone suggests the use of this parameter. If your recovery strategy is such that you can not conveniently recover your database in cases like this, then it's time to seriously rethink the strategy.
Cheers!! RF -----Original Message----- Madan Sent: Monday, January 27, 2003 6:14 PM To: Multiple recipients of list ORACLE-L Hi, DB: 8.1.5.0.0 O/S: Solaris 2.7 This database is the recovery catalog database. It is in noarchivelog mode and is backed up cold. Unfortunately, something happened on Thursday and the database does not startup. I receive the following errors: SQL> startup ORACLE instance started. Total System Global Area 25410960 bytes Fixed Size 64912 bytes Variable Size 8388608 bytes Database Buffers 16777216 bytes Redo Buffers 180224 bytes Database mounted. ORA-01589: must use RESETLOGS or NORESETLOGS option for database open SQL> recover database; ORA-00283: recovery session canceled due to errors ORA-00354: corrupt redo log block header ORA-00353: log corruption near block 78 change 1113558 time 01/24/03 01:51:40 ORA-00312: online log 2 thread 1: '/nsr/u02/oradata/RCVCATDB/log2a.rdo' SQL> recover database until time '2003-01-24:00:00:00'; ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below ORA-01194: file 1 needs more recovery to be consistent ORA-01110: data file 1: '/nsr/u02/oradata/RCVCATDB/system01.dbf' Is this the "perfect" time where I can use the _allow_resetlogs_corruption parameter??? I know I have the cold backups ... but they have sent the tapes off site and it is going to take a while for the tapes to be located and sent to the data center and we need this catalog database up and running asap. Thanks Sujatha -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Sujatha Madan 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: Robert Freeman 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).
