Redolog file Recovery
Recovery from missing or corrupted redo log group
Case 1: A multiplexed copy of the missing log is available.
If a redo log is missing, it should be restored from a multiplexed copy, if possible. Here’s an example, where I attempt to startup from SQLPLUS when a redo log is missing:
SQL> startup
ORACLE instance started.
Total System Global Area 131555128 bytes
Fixed Size 454456 bytes
Variable Size 88080384 bytes
Database Buffers 41943040 bytes
Redo Buffers 1077248 bytes
Database mounted.
ORA-00313: open failed for members of log group 3 of thread 1
ORA-00312: online log 3 thread 1: ‘D:ORACLE_DATALOGSORCLREDO03A.LOG’
SQL>
To fix this we simply copy REDO03A.LOG from its multiplexed location on E: to the above location on D:.
SQL> alter database open;
Database altered.
SQL>
That’s it – the database is open for use.
Case 2: All members of a log group lost.
In this case an incomplete recovery is the best we can do. We will lose all transactions from the missing log and all subsequent logs. We illustrate using the same example as above. The error message indicates that members of log group 3 are missing. We don’t have a copy of this file, so we know that an incomplete recovery is required. The first step is to determine how much can be recovered. In order to do this, we query the V$LOG view (when in the mount state) to find the system change number (SCN) that we can recover to (Reminder: the SCN is a monotonically increasing number that is incremented whenever a commit is issued)
–The database should be in the mount state for v$log access
SQL> select first_change# from v$log whnhi….ere group#=3 ;
FIRST_CHANGE#
————-
370255
SQL>
The FIRST_CHANGE# is the first SCN stamped in the missing log. This implies that the last SCN stamped in the previous log is 370254 (FIRST_CHANGE#-1). This is the highest SCN that we can recover to. In order to do the recovery we must first restore ALL datafiles to this SCN, followed by recovery (also up to this SCN). This is an incomplete recovery, so we must open the database resetlogs after we’re done. Here’s a transcript of the recovery session (typed commands in bold, comments in italics, all other lines are RMAN feedback):
C:>rman target /
Recovery Manager: Release 9.2.0.4.0 – Production
Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.
connected to target database: ORCL (DBID=1507972899)
–Restore ENTIRE database to determined SCN
RMAN> restore database until scn 370254;
Starting restore at 26/JAN/05
using channel ORA_DISK_1
using channel ORA_DISK_2
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to D:ORACLE_DATADATAFILESORCLSYSTEM01.DBF
restoring datafile 00004 to D:ORACLE_DATADATAFILESORCLUSERS01.DBF
channel ORA_DISK_2: starting datafile backupset restore
channel ORA_DISK_2: specifying datafile(s) to restore from backup set
restoring datafile 00002 to D:ORACLE_DATADATAFILESORCLUNDOTBS01.DBF
restoring datafile 00003 to D:ORACLE_DATADATAFILESORCLTOOLS01.DBF
channel ORA_DISK_2: restored backup piece 1
piece handle=E:BACKUP13GB14IB_1_1.BAK tag=TAG20050124T171139 params=NUL
channel ORA_DISK_2: restore complete
channel ORA_DISK_1: restored backup piece 1
piece handle=E:BACKUP14GB14IB_1_1.BAK tag=TAG20050124T171139 params=NUL
channel ORA_DISK_1: restore complete
Finished restore at 26/JAN/05
–Recover database
RMAN> recover database until scn 370254;
Starting recover at 26/JAN/05
using channel ORA_DISK_1
using channel ORA_DISK_2
starting media recovery
archive log thread 1 sequence 9 is already on disk as file E:ORACLE_ARCHIVEORCL1_9.ARC
archive log thread 1 sequence 10 is already on disk as file E:ORACLE_ARCHIVEORCL1_10.ARC
archive log thread 1 sequence 11 is already on disk as file E:ORACLE_ARCHIVEORCL1_11.ARC
archive log thread 1 sequence 12 is already on disk as file E:ORACLE_ARCHIVEORCL1_12.ARC
archive log filename=E:ORACLE_ARCHIVEORCL1_9.ARC thread=1 sequence=9
archive log filename=E:ORACLE_ARCHIVEORCL1_10.ARC thread=1 sequence=10
media recovery complete
Finished recover at 26/JAN/05
–open database with RESETLOGS (see comments below)
RMAN> alter database open resetlogs;
database opened
RMAN>
The following points should be noted:
1. The entire database must be restored to the SCN that has been determined by querying v$log.
2. All changes beyond that SCN are lost. This method of recovery should be used only if you are sure that you cannot do better. Be sure to multiplex your redo logs, and (space permitting) your archived logs!
3. The database must be opened with RESETLOGS, as a required log has not been applied. This resets the log sequence to zero, thereby rendering all prior backups worthless. Therefore, the first step after opening a database RESETLOGS is to take a fresh backup. Note that the RESETLOGS option must be used for any incomplete recovery.
Responses