Missing redo logs in oracle

1. Missing Redo Logs – Scenario
Filed under: Oracle,RMAN,Redo Logs — Vikram @ 11:39 pm
Tags: Oracle, Redo Logs, RMAN
Consider a scenario where you have lost your redo logs on a DB instance. It is
possible to recreate them. It is also possible to recover the database with no data loss in
certain situations. Let’s jump to action immediately. But first we need to know different
ways of redo loss and which category we fit in.
A Redo log is a journal of events happening in the DB at any given time. Redo logs are
the most crucial part of the database after the controlfile. The documentation defines the
redo logs as follows:
The online redo log is a set of operating system files that record all changes made to any
database block, including data, index, and rollback segments, whether the changes are
committed or uncommitted. All changes to Oracle blocks are recorded in the online log.
A redo log, at the time of being deleted, will be in one of the below scenarios:
1) The redo log is not CURRENT and archived
2) The redo log is not CURRENT but not archived
3) The redo log is CURRENT (DB was shut down cleanly)
4) The redo log is CURRENT (DB was not shut down cleanly)
Identify which scenario fits you. In all the scenarios except (1) we will need to open the
database using OPEN RESETLOGS option. You may use the below SQL to find the above
details:
SQL> select a.group#, b.member, a.archived, a.status
2 from v$log a, v$logfile b where a.group#=b.group#;
GROUP# MEMBER ARC STATUS
---------- ---------------------------------------- --- ----------------
3 D:VIKRAMORADATATESTTESTREDO03.LOG YES INACTIVE
2 D:VIKRAMORADATATESTTESTREDO02.LOG YES UNUSED
1 D:VIKRAMORADATATESTTESTREDO01.LOG NO CURRENT
Remember: RESETLOGS is compulsory when there is an incomplete recovery.
1) Redo log is not CURRENT and archived
If a redo log file is already archived, its loss can safely be ignored. Since all the changes
in the DB are now archived and the online log file is only waiting for its turn to be re-
written by LGWR (redo log files are written circularly) the loss of the redo log file doesnt
matter much. It may be re-created using the command
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE CLEAR LOGFILE GROUP <group#>;

2. This will re-create all groups and no transactions are lost. The database can be opened
normally after this.
2) Redo log is not CURRENT and not archived
If the redo log is lost before it is archived then there are a few transactions in the redo log
that are lost too. Since a crash recovery is no more possible, a media recovery is required.
The DB needs to be restored from a previous backup and recovered until the last
available archive log is applied. The reason I say crash recovery is not possible is that by
definition a crash recovery should need only online redo logs to recover the database to a
consistent state. If a recovery needs a log file that is not online (like archive logs) then the
recovery is no more a crash recovery. It becomes media recovery. In our current case
since we are applying the archives and using the previous backup to restore it is not a
crash recovery.
Also since we cannot recover database completely as some data is lost in the redo log
files before being archived, this becomes an incomplete recovery too. The DB needs to be
opened up in RESETLOGS mode. The steps to recover are below:
-- Restore the DB from previous backup and open the DB in mount state.
SQL> RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;
-- Apply all the archives available
SQL> ALTER DATABASE OPEN RESETLOGS;
In a similar scenario an RMAN restore will be as below:
RMAN> RESTORE CONTROLFILE FROM '<backup tag location>';
RMAN> ALTER DATABASE MOUNT;
RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE UNTIL TIME "to_date('MAR 05 2009 19:00:00','MON
DD YYYY HH24:MI:SS')";
RMAN> ALTER DATABASE OPEN RESETLOGS;
The above commands can also be used in a normal recovery scenario from Production to
Test with a few modifications. The actual plan of steps that I had followed can be found
here. There is a metalink note 1044466.6 that discusses this recovery in greater detail.
3) Redo log is CURRENT (DB was shut down cleanly)
If the CURRENT redo log is lost and if the DB is closed consistently, OPEN RESETLOGS
can be issued directly without any transaction loss. It is advisable to take a full backup of
DB immediately after the STARTUP.
4) Redo log is CURRENT (DB was not shut down cleanly)
When a current redo log is lost, the transactions in the log file are also lost before making
to archived logs. Since a DB startup can no more perform a crash recovery (since all the
now-available online log files are not sufficient to startup the DB in consistent state), an
incomplete media recovery is the only option. We will need to restore the DB from a

3. previous backup and restore to the point just before the lost redo log file. The DB will
need to be opened in RESETLOGS mode. There is some transaction loss in this scenario.
RMAN> RESTORE CONTROLFILE FROM '<backup tag location>';
RMAN> ALTER DATABASE MOUNT;
RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE UNTIL TIME "to_date('MAR 05 2009 19:00:00','MON
DD YYYY HH24:MI:SS')";
RMAN> ALTER DATABASE OPEN RESETLOGS;
Here we come to an end of all the scenarios in which a redo log can be lost.
There is a simpler way to restore the deleted current redo log file on Unix/Linux
platforms too. The procedure to do it will be mentioned in my subsequent posts.
Meanwhile, I would love to hear from you any suggestions or additions to this post.
Thank you.
Possibly related posts: (automatically generated)
• Archived Redo Log Files
Ads by Google
2010 SIEM Magic Quadrant
View complimentary copy of Gartner SIEM MQ Report from
LogLogic.
LogLogic.com/GartnerSIEM
Comments (5)
5 Comments »
1. Thanks for the input, I just blew away my redo logs testing backup/restore
scenarios and this post helped point me in the right direction!!
Comment by Free Games Gallery — April 3, 2009 @ 2:08 pm
2. Great Post!Can you please let us know the simpler method of restoring the deleted
logfiles.Keep up the good work:)

4. Comment by monto — July 21, 2009 @ 9:10 am
3. Hello Monto,
On Unix/Linux platforms one can retrieve a missing datafile or a redo logfile
using the file descriptor. Instructions for this can be found in this metalink note:
444749.1 – Retrieve deleted files on Unix / Linux using File Descriptors
Happy playing around!
Comment by Vikram — July 24, 2009 @ 9:47 pm
4. I’d mv’d my redo logs instead of copying them, doing a clone. Obviously the
clone was OK, my prod was not, there had been no transactions applied so I
copied them back, obviously they were now out of sync. Used one of the
scenarios you’ve listed. Fingers crossed. Thanks.
Comment by James — August 15, 2009 @ 11:00 am
5. [...] we test this solution please refer to this link VN:F [1.9.1_1087]please wait…
Rating: 0.0/5 (0 votes cast)VN:F [1.9.1_1087]Rating: 0 (from 0 [...]