Lost Redo Logs And Archive Logs And Need To Apply Media Recovery ** INTERNAL ONLY **

** INTERNAL ONLY **

Problem Description:
====================

You receive the following errors on trying to bring up the database after it
has crashed:

ORA-01194 for file #1, the system datafile.

ORA-01194: “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 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.

When trying to apply media recovery with the following command:

RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL

you receive one of the following errors about redo logs:

ORA-00314: “log %s of thread %s, expected sequence# %s doesn’t
match %s”
Cause: The online log is corrupted or is an old version.
Action: Find and install correct version of log or reset logs.

ORA-00312: “online log %s thread %s: ‘%s’”
Cause: Reporting file name for details of another error
Action: See associated error messages

ORA-00376: “file %s cannot be read at this time”
Cause: attempting to read from a file that is not readable.
Most likely the file is offline.
Action: Check the state of the file. Bring it online

Problem Explanation:
====================

A possible reason you may be getting those errors is that the redo logs have
been misplaced, or removed, or damaged, or the set of redo logs is from an old
backup.

Search Words:
=============

ORA-1194, ORA-314, ORA-312, ORA-376

@== MERGED DOCID:2059306.6 (PUBLISHED/INTERNAL)
@== ** INTERNAL ONLY ** CANNOT APPLY MEDIA RECOVERY BECAUSE REDO LOGS ARE LO

** INTERNAL ONLY **

Solution Description:
=====================

First, look to see if you can find the correct redo logs. They are absolutely
necessary for media recovery. Without them, we cannot apply undo and changes
to bring the database to a point in time consistent state.

If the online redo logs have been deleted, restore from backup and roll
forward with the archive logs.

If you have lost the current redo logs as well as your archive logs, and you
must salvage your data (i.e. a production system) then to force the database
to open, we must corrupt the database.

*******WARNING**********************************************************

The following parameters are to be used with caution, as they do exploit
the database. In addition, the use of these parameters is not supported
and may not work in all circumstances. You should only be using these
parameters with the help of a senior analyst.

The consequences of using these parameters is that they will corrupt the
database and you will be required to rebuild your database.

************************************************************************

After reading and understanding the consequences of the above warnings, do the
following to force the database open:

1. Shutdown the database and take a full backup of the current database

2. Add the following parameter in the init.ora file:

_allow_resetlogs_corruption=TRUE

3. Do:

SVRMGR> Startup mount;

4. Do:

SVRMGR> recover database using backup controlfile until cancel;

5. When prompted, type in the word ‘bogus’ or some other nonsense file
name. Recovery will attempt to find a file with this name and fail.
It may provide an error message and prompt you for another file, or
it may simply fail and terminate the recovery session. Either is OK.

6. If prompted for another logfile, type CANCEL.

7. Do:

SVRMGR> alter database open resetlogs;

**** Note: This step may fail. eg. ora-600 [6856].
If rollback segment(s) are corrupted then do step 8 thru 14.
If other errors other than the corrupted rollback segment
the you will need to investigate the errors produced in
more detail. If the step succeeds, proceed to step 14.

8. Do:

SVRMGR> Shutdown immediate;

9. Remove previous parameter “_allow_resetlogs_corruption=TRUE” from the
init.ora.

Add the following parameter in the init.ora:
_corrupted_rollback_segments=

Following are useful:
event=”10269 trace name context forever, level 10″
event=”10061 trace name context forever, level 10″

10. Remove corrupted rollback segment(s) from the “rollback_segments” parameter

11. Do:

SVRMGR> Startup mount

12. DO:

SVRMGR> Drop rollback segment ;

**** do step 11 for each corrupted rollback segment.

13. DO:

SVRMGR> Alter database open;

14. REBUILD the database by taking a full database export, and then
importing into a new database.

Solution Explanation:
=====================

The reason we need to force the database open is to bypass instance recovery
because we no longer have the information available. Bypassing instance
recovery means we will not roll forward any data from the current online redo
log AND we will not roll back any uncommitted transactions. The result of
this is a database containing inconsistent data. The customer will have to
determine the impact of this inconsistency to their data – we cannot provide
any assistance in this area. The rebuild is required to resolve any potential
inconsistency in the data dictionary.

© 2010, www.oracledatabase12g.com. 版权所有.文章允许转载,但必须以链接方式注明源地址,否则追究法律责任.

相关文章 | Related posts:

1. Lost Redo Logs And Archive Logs And Need To Apply Media Recovery ** INTERNAL ONLY **
2. REDO LOG CORRUPTION – DROPPING REDO LOGS NOT POSSIBLE – CLEAR LOGFILE
3. Reference:Dissecting the Redo Logs
4. How to recover and open the database if the archivelog required for recovery is either missing, lost or corrupted?
5. How to Extract Controlfiles, Datafiles, and Archived Logs from RMAN Backupsets
6. EVENT:10228 trace application of redo by kcocbk
7. gc lost blocks diagnostics
8. RMAN 11G : Data Recovery Advisor – RMAN command line example
9. Know more about redo log buffer and latches
10. 9iRAC Tuning Best Practices (INTERNAL ONLY)