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
RESETLOGSoption. 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:\VIKRAM\ORADATA\TEST\TEST\REDO03.LOG YES INACTIVE
2 D:\VIKRAM\ORADATA\TEST\TEST\REDO02.LOG YES UNUSED
1 D:\VIKRAM\ORADATA\TEST\TEST\REDO01.LOG NO CURRENT

Remember: RESETLOGSis 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#>;

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 RESETLOGScan 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 previous backup and restore to the point just before the lost redo log file. The DB will need to be
opened in RESETLOGSmode. 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.