Subject:  LOST REDO LOGS AND ARCHIVE LOGS AND NEED TO APPLY MEDIA RECOVERY
Type:  PROBLEM 
Creation Date:  20-JUL-1995 
 
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

Solution: ** INTERNAL ONLY ** CANNOT APPLY MEDIA RECOVERY BECAUSE REDO LOGS ARE LOST

** 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= <replacement for corrupted rollback segment(s)>
 
   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 <rollback segment name>;

**** 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.