我相信_ALLOW_RESETLOGS_CORRUPTION 这个参数一定很多人都熟悉,是redo异常恢复的杀手锏之一,以下文章是来自官方的解释
DB_Parameter _ALLOW_RESETLOGS_CORRUPTION
========================================
This documentation has been prepared avoiding the mention of the complex
structures from the code and to simply give an insight to the 'damage it could
cause'. The usage of this parameter leads to an in-consistent Database with no
other alternative but to rebuild the complete Database. This parameter could
be used when we realize that there are no stardard options available and are
convinced that the customer understands the implications of using the Oracle's
secret parameter. The factors to be considered are ;--
1. Customer does not have a good backup.
2. A lot of time and money has been invested after the last good backup and
there is no possibility for reproduction of the lost data.
3. The customer has to be ready to export the full database and import it
back after creating a new one.
4. There is no 100% guarantee that by using this parameter the database would
come up.
5. Oracle does not support the database after using this parameter for
recovery.
6. ALL OPTIONS including the ones mentioned in the action part of the error
message have been tried.
By setting _ALLOW_RESETLOGS_CORRUPTION=TRUE, certain consistency checks are
SKIPPED during database open stage. This basically means it does not check
the datafile headers as to what the status was before the shutdown and how it
was shutdown. The following cases mention few of the checks that were skipped.
Case-I
------
Verification that the datafile present has not been restored from a BACKUP
taken before the database was opened successfully by using RESETLOGS.
ORA-01190: control file or data file %s is from before the last RESETLOGS
Cause: Attempting to use a data file when the log reset information in
the file does not match the control file. Either the data file or
the control file is a backup that was made before the most recent
ALTER DATABASE OPEN RESETLOGS.
Action: Restore file from a more recent backup.
Case-II
-------
Verification that the status bit of the datafile is not in a FUZZY state.
The datafile could be in this state due to the database going down when the
- Datafile was on-line and open
- Datafile was not closed cleanly (maybe due to OS).
ORA-01194: file %s needs more recovery to be consistent
Cause: An incomplete recover session was started, but an insufficient
number of logs were applied to make the file consistent. The
reported file was not closed cleanly when it was last opened by
the database. It must be recovered to a time when it was not
being updated. The most likely cause of this error is forgetting
to restore the file from a backup before doing incomplete
recovery.
Action: Either apply more logs until the file is consistent or restore the
file from an older backup and repeat recovery.
Case-III
--------
Verification that the COMPLETE recover strategies have been applied for
recovering the datafile and not any of the INCOMPLETE recovery options.
Basically because the complete recovery is one in which we even apply the
ON-LINE redo log files and open the DB without reseting the logs.
ORA-01113: file '%s' needs media recovery starting at log sequence # %s
Cause: An attempt was made to open a database file that is in need of
media recovery.
Action: First apply media recovery to the file.
Case-IV
-------
Verification that the datafile has been recovered through an END BACKUP if the
control file indicates that it was in backup mode.
This is useful when the DB has crashed while in hot backup mode and we lost
all log files in DB version's less than V7.2.
ORA-01195: on-line backup of file %s needs more recovery to be consistent"
Cause: An incomplete recovery session was started, but an insufficient
number of logs were applied to make the file consistent. The
reported file is an on-line backup which must be recovered to the
time the backup ended.
Action: Either apply more logs until the file is consistent or resotre
the database files from an older backup and repeat recovery.
In version 7.2, we could simply issue the ALTER DATABASE DATAFILE xxxx END
BACKUP statement and proceed with the recovery. But again to issue this
statement, we need to have the ON-LINE redo logs or else we still are forced to
use this parameter.
Case-V
------
Verification that the data file status is not still in (0x10) MEDIA recovery
FUZZY.
When recovery is started, a flag is set in the datafile header status flag to
indicate that the file is presently in media recovery. This is reset when
recovery is completed and at times when it has not been reset we are forced to
use this paramter.
ORA-01196: file %s is inconsistent due to a failed media recovery session
Cause: The file was being recovered but the recovery did not terminate
normally. This left the file in an inconsistent state. No more
recovery was successfully completed on this file.
Action: Either apply more logs until the file is consistent or restore the
backup again and repeat recovery.
Case-VI
-------
Verification that the datafile has been restored form a proper backup to
correspond with the log files. This situation could happen when we have
decided that the data file is invalid since its SCN is ahead of the last
applied logs SCN but it has not failed on one of the ABOVE CHECKS.
ORA-01152: file '%s' was not restored from a sufficientluy old backup"
Cause: A manual recovery session was started, but an insufficient number
of logs were applied to make the database consistent. This file is
still in the future of the last log applied. Note that this
mistake can not always be caught.
Action: Either apply more logs until the database is consistent or
restore the database file from an older backup and repeat
recovery.
使用_ALLOW_RESETLOGS_CORRUPTION 参数需谨慎,因为该参数可能导致数据库逻辑不一致,甚至可能把本来很简单的一个恢复弄的非常复杂甚至不可恢复的后果,建议在oracle support支持下使用.另外使用该参数resetlogs库之后,强烈建议通过逻辑方式重建库
