Recovering After the Loss of Online Redo Log Files

Case A: Losing a Member of a Multiplex online Redo log group.
------------------------------------------------------------------------
In this case your redo log file is multiplex that means you have more than one log member within log groups. Now if you have at least one redo log member of the group exist then database continues functional as usual. In alert log error message will be written.
In order to solve the problem,

i)Identify the redo log file that is invalid.
SQL> SELECT GROUP#, STATUS, MEMBER
FROM V$LOGFILE
WHERE STATUS='INVALID';
GROUP# STATUS MEMBER
------- ----------- ---------------------
0002 INVALID /oracle/shaik/redo02.log

ii)Drop the damaged member.
ALTER DATABASE DROP LOGFILE MEMBER '/oracle/shaik/redo02.log/shaik/redo02.log'

iii)Add a new member to the group.
ALTER DATABASE ADD LOGFILE MEMBER '/oracle/shaik/redo02b.log' TO GROUP 1; --FOr example to group 1.

If the file you want to add already exists, you must specify REUSE. For example:
ALTER DATABASE ADD LOGFILE MEMBER '/oracle/shaik/redo02b.log' REUSE TO GROUP 2;

Case B:Recovering After the Loss of All Members of an Online Redo Log Group
-------------------------------------------------------------------------------------
If a media failure damages all members of an online redo log group, then different scenarios can occur depending on the type of online redo log group affected by the failure and the archiving mode of the database.

-If the group is inactive then it is not needed for crash recovery. Clear the archive or unarchived group.

-If the group is active then it is needed for crash recovery. In order to solve the problem attempt to issue a checkpoint and clear the log; if impossible, then you must restore a backup and perform incomplete recovery up to the most recent available redo log.

-If the group is current then it is the log that the database is currently writing. In order to solve the problem attempt to clear the log; if impossible, then you must restore a backup and perform incomplete recovery up to the most recent available redo log.

Troubleshooting:
--------------------

Determine whether the damaged group is active or inactive.

See the file name and corresponding group name of the log file.

SQL>SELECT GROUP#, STATUS, MEMBER FROM V$LOGFILE;

Determine which groups are active.

SQL> SELECT GROUP#, MEMBERS, STATUS, ARCHIVED
FROM V$LOG;
Losing an Inactive Online Redo Log Group
-----------------------------------------------
If the damaged redo log group is inactive and archived then issue,
SQL>ALTER DATABASE CLEAR LOGFILE GROUP 2;
It will reinitialize the damaged log group.

b)If the damaged redo log group is inactive and not yet archived issue,

SQL>ALTER DATABASE CLEAR LOGFILE UNARCHIVED GROUP 2;

If there is an offline datafile that requires the cleared log to bring it online, then the keywords UNRECOVERABLE DATAFILE are required. The datafile and its entire tablespace have to be dropped because the redo necessary to bring it online is being cleared, and there is no copy of it. For example, enter:

SQL>ALTER DATABASE CLEAR LOGFILE UNARCHIVED GROUP 2 UNRECOVERABLE DATAFILE;

Immediately backup full database.

Losing an Active Online Redo Log Group
--------------------------------------------
If the database is still running and the lost active redo log is not the current log, then issue the ALTER SYSTEM CHECKPOINT statement. If successful, then the active redo log becomes inactive.
And follow the procedure above as how you will respond to an inactive online redo log group.

If your ALTER SYSTEM CHEKPOINT statement failed then follow the following procedure.

a)If your database is in noarchivelog state restore database from whole consistent backup and perform incomplete recovery.

$scp .. /oracle/target/*
SQL>STARTUP MOUNT
SQL>RECOVER DATABASE UNTIL CANCEL
CANCEL
SQL>ALTER DATABASE OPEN RESETLOGS

b)If you loss an active online redo log in archivelog mode then follow the following procedure.

ALTER DATABASE RENAME FILE '/oradata/trgt/redo01.log' TO '/tmp/redo01.log';
.
.
ALTER DATABASE OPEN RESETLOGS;