Recovering After the Loss of Online Redo Log Files
If a media failure has affected the online redo logs of a database, then the appropriate recovery procedure depends on the following considerations:
The configuration of the online redo log: mirrored or non-mirrored
The type of media failure: temporary or permanent
The types of online redo log files affected by the media failure: current, active, unarchived, or inactive
Table 30-3 displays V$LOG status information that can be crucial in a recovery situation involving online redo logs.
Table 30-3 STATUS Column of V$LOG
| Status | Description |
|---|---|
| UNUSED |
The online redo log has never been written to. |
| CURRENT |
The online redo log is active, that is, needed for instance recovery, and it is the log to which the database is currently writing. The redo log can be open or closed. |
| ACTIVE |
The online redo log is active, that is, needed for instance recovery, but is not the log to which the database is currently writing. It may be in use for block recovery, and may or may not be archived. |
| CLEARING |
The log is being re-created as an empty log after an ALTER DATABASE CLEAR LOGFILE statement. After the log is cleared, then the status changes to UNUSED. |
| CLEARING_CURRENT |
The current log is being cleared of a closed thread. The log can stay in this status if there is some failure in the switch such as an I/O error writing the new log header. |
| INACTIVE |
The log is no longer needed for instance recovery. It may be in use for media recovery, and may or may not be archived. |
Recovering After Losing a Member of a Multiplexed Online Redo Log Group
You can recover after losing a member of a multiplexed online redo log group. The database continues to function as usual during the following conditions:
If the online redo log of a database is multiplexed, and if at least one member of each online redo log group is not affected by the media failure, then the database continues functioning as usual, but error messages are written to the log writer trace file and the alert_SID.log of the database.
You can resolve the problem of a missing member of a multiplexed online redo log group by taking one of the following actions:
If the hardware problem is temporary, then correct it. The log writer process accesses the previously unavailable online redo log files as if the problem never existed.
If the hardware problem is permanent, then drop the damaged member and add a new member by using the following procedure.
Note:
The newly added member provides no redundancy until the log group is reused.Locate the file name of the damaged member in V$LOGFILE. The status is INVALID if the file is inaccessible:
SELECT GROUP#, STATUS, MEMBER FROM V$LOGFILE WHERE STATUS='INVALID'; GROUP# STATUS MEMBER ------- ----------- --------------------- 0002 INVALID /disk1/oradata/trgt/redo02.log
Drop the damaged member. For example, to drop member redo02.log from group 2, issue the following statement:
ALTER DATABASE DROP LOGFILE MEMBER '/disk1/oradata/trgt/redo02.log';
Add a new member to the group. For example, to add redo02.log to group 2, issue the following statement:
ALTER DATABASE ADD LOGFILE MEMBER '/disk1/oradata/trgt/redo02b.log' TO GROUP 2;
If the file that you want to add exists, then it must be the same size as the other group members, and you must specify the REUSE option. For example:
ALTER DATABASE ADD LOGFILE MEMBER '/disk1/oradata/trgt/redo02b.log' REUSE TO GROUP 2;
Recovering After Losing All Members of an Online Redo Log Group
丢失online redo 日志组