ORA-01194: file 1 needs more recovery to be consistent
– ORA-01110: data file 1: ‘/u01/oracle/oradata/ora11g/system01.dbf’
of redo logs were applied to make the file consistent.
The named file was not closed cleanly when it was last opened by the
The most likely cause of this message is forgetting to restore the
file from a backup before doing incomplete recovery.
Either apply more redo logs until the file is consistent or restore
the file from an older backup and repeat recovery.
if you face this type of error , after appling all redo log and archive log successfuly.you can consider to setup “_allow_resetlogs_corruption” this undocumented parameter .
Before thinking about the use of the undocumented parameter “_allow_resetlogs_corruption” all other avenues of database recovery must have been exhausted. 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 belows 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.)
ORA-01194: file 1 needs more recovery to be consistent ORA-01110: data file 1: ‘…./system01.dbf’
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: …./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”.Example:
2) Second, set or add the below parameter in pfile like “_allow_resetlogs_corruption = true” (without quote)
3) Third, “STARTUP MOUNT pfile=’pfile_location_name’ ” and “ALTER DATABASE OPEN RESETLOGS;”
4) Fourth, If the database asks for recovery, use an UNTIL CANCEL type recovery and apply all available archive and on-line redo logs, then issue CANCEL and reissue the “ALTER DATABASE OPEN RESETLOGS;”
SQL>SHUTDOWN NORMAL (After altered to open the database shutdown it in normal mode)
(Remove the above parameter on pfile.)