Before thinking about the use of the undocumented parameter "_allow_resetlogs_corruption" all other avenues of database recovery must have been exhausted (eaten). Because this parameter forces the opening of the datafiles even if their SCNs do not match up. Then at the next checkpoint the old SCN values are over-written. This could leave the database in an unknown state as far as concurrency.
For that reason, you must export and rebuild your database after using this recovery method Most of the time, this recovery method is required when a data file has been left in hot backup mode through several backup cycles without an intervening shutdown and startup. Upon shutdown and startup the database will complain that a file (usually file id#1 the SYSTEM tablespace) needs more recovery and asks for logs past all available archive logs and online logs.
An other scenario could be that the database is recovered from a hot backup and the above scenario occurs, or, the database asks for an archive log that is before any that are available (usually for the ROLLBACK segment tablespace datafiles.)
In the Course of doing this... you may come up with Issues
ORA-01194: file 1 needs more recovery to be consistent ORA-01110: data file 1: '/u01/oradata/ORCL/system01.dbf'
or
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below ORA-01194: file 12 needs more recovery to be consistent ORA-01110: data file 12: '/u12/oradata/ORCL/data01.dbf'
If all available archive logs are applied and all available online redo logs applied and the error is not corrected, only then should use of the parameter "_allow_resetlogs_corruption" be considered. Make sure a good backup of the database in a closed state (all files) is taken before attempting recovery using "_allow_resetlogs_corruption".
I collected it from "Pavan Kumar N"'s . I very much liked his description.
thanks Pavan Kumar N.
For that reason, you must export and rebuild your database after using this recovery method Most of the time, this recovery method is required when a data file has been left in hot backup mode through several backup cycles without an intervening shutdown and startup. Upon shutdown and startup the database will complain that a file (usually file id#1 the SYSTEM tablespace) needs more recovery and asks for logs past all available archive logs and online logs.
An other scenario could be that the database is recovered from a hot backup and the above scenario occurs, or, the database asks for an archive log that is before any that are available (usually for the ROLLBACK segment tablespace datafiles.)
In the Course of doing this... you may come up with Issues
ORA-01194: file 1 needs more recovery to be consistent ORA-01110: data file 1: '/u01/oradata/ORCL/system01.dbf'
or
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below ORA-01194: file 12 needs more recovery to be consistent ORA-01110: data file 12: '/u12/oradata/ORCL/data01.dbf'
If all available archive logs are applied and all available online redo logs applied and the error is not corrected, only then should use of the parameter "_allow_resetlogs_corruption" be considered. Make sure a good backup of the database in a closed state (all files) is taken before attempting recovery using "_allow_resetlogs_corruption".
I collected it from "Pavan Kumar N"'s . I very much liked his description.
thanks Pavan Kumar N.
No comments:
Post a Comment