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 |
---|---|
|
The online redo log has never been written to. |
|
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. |
|
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. |
|
The log is being re-created as an empty log after an |
|
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. |
|
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 isINVALID
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 group2
, 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 group2
, 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 日誌組所有成員後恢復
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 damaged online redo log group is current and active, then it is needed for crash recovery; otherwise, it is not. Table 30-4 outlines the various recovery scenarios.
如果損壞的當前日誌組時current和active,那麼需要做故障恢復。
Table 30-4 Recovering After the Loss of an Online Redo Log Group
If the Group Is... | Then... | And You Should... |
---|---|---|
Inactive |
It is not needed for crash recovery |
Clear the archived or unarchived group. |
Active |
It is needed for crash recovery |
Attempt to issue a checkpoint and clear the log; if impossible, then you must either use Flashback Database or restore a backup and perform incomplete recovery up to the most recent available redo log. 試着執行checkpoint和clear日誌,如果不能,那麼你必須要麼使用閃回數據庫要麼使用轉儲備份 執行不完全恢復到最近可用的redo log。 |
Current |
It is the redo log that the database is currently writing to |
Attempt to clear the log; if impossible, then you must either use Flashback Database or restore a backup and perform incomplete recovery up to the most recent available redo log. |
To determine whether the damaged group is active or inactive.
確定損壞的組是否是acitve 或inactive
-
Locate the file name of the lost redo log in
V$LOGFILE
and then look for the group number corresponding to it. For example, enter:SELECT GROUP#, STATUS, MEMBER FROM V$LOGFILE; GROUP# STATUS MEMBER ------- ----------- --------------------- 0001 /oracle/dbs/log1a.f 0001 /oracle/dbs/log1b.f 0002 INVALID /oracle/dbs/log2a.f 0002 INVALID /oracle/dbs/log2b.f 0003 /oracle/dbs/log3a.f 0003 /oracle/dbs/log3b.f
-
Determine which groups are active.
For example, execute the following SQL query (sample output included):
SELECT GROUP#, MEMBERS, STATUS, ARCHIVED FROM V$LOG; GROUP# MEMBERS STATUS ARCHIVED ------ ------- --------- ----------- 0001 2 INACTIVE YES 0002 2 ACTIVE NO 0003 2 CURRENT NO
-
Perform one of the following actions:
-
If the affected group is inactive, then follow the procedure in "Losing an Inactive Online Redo Log Group".
-
If the affected group is active (as in the preceding example), then follow the procedure in "Losing an Active Online Redo Log Group".
-
Losing an Inactive Online Redo Log Group
丟失inactive 日誌組
If all members of an online
redo log group with INACTIVE
status are damaged, then the procedure depends on whether you can fix the media problem that damaged the inactive redo log group. If the failure is temporary, then fix the problem. The log writer
can reuse the redo log group when required. If the failure is permanent, then the damaged inactive online redo log group eventually halts normal database operation. Reinitialize the damaged group manually by issuing the ALTER DATABASE
CLEAR LOGFILE
statement as described in this section.
inactive狀態的日誌組所有成員損壞。那麼程序依賴於你能否定位inactive日誌組的介質問題(日誌文件是否損壞),如果介質故障是臨時的,log writer 能重新使用 日誌組。如果介質故障是永久的,那麼損壞的inactive日誌組最終會停止正常的數據庫操作。通過執行alter database CLEAR LOGFILE語句手動的重新初始化損壞的日誌組。
Clearing Inactive, Archived Redo
清除inactive 已歸檔的日誌
You can clear an inactive redo log group when the database is open or closed. The procedure depends on whether the damaged group has been archived.
數據庫開啓或關閉都能 clear inactive 日誌組。依賴於損壞的日誌組是否歸檔。
To clear an inactive, online redo log group that has been archived:
-
If the database is shut down, then start a new instance and mount the database:
STARTUP MOUNT
-
Reinitialize the damaged log group. For example, to clear redo log group
2
, issue the following statement:ALTER DATABASE CLEAR LOGFILE GROUP 2;
Clearing Inactive, Unarchived Redo
清除 inactive 未歸檔的日誌
Clearing a not-yet-archived redo log allows it to be reused without archiving it. This action makes backups unusable if they were started before the last change in the log, unless the file was taken offline before the first change in the log. Hence, if you need the cleared log file for recovery of a backup, then you cannot recover that backup. Clearing a not-yet-archived-redo-log, prevents complete recovery from backups due to the missing log.
清除的沒有歸檔的日誌允許被被重用。如果日誌的最後一次改變之前開始, 這個操作會導致備份不可用,除非日誌文件在第一次改變之前被置爲offline。此後,如果你需要被清除的日誌去做備份恢復,是不能備份恢復的。
To clear an inactive, online redo log group that has not been archived:
清除一個inactive ,日誌沒有歸檔:
-
If the database is shut down, then start a new instance and mount the database:
SQL> STARTUP MOUNT
-
Clear the log using the
UNARCHIVED
keyword.For example, to clear log group
2
, issue the following SQL statement:SQL> ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 2;
If there is an offline data file that requires the cleared log to bring it online, then the keywords
UNRECOVERABLE
DATAFILE
are required. The data file must be dropped because the redo logs necessary to bring the data file online are being cleared, and there is no copy of it. For example, enter:如果有一個數據文件offline, 需要清除日誌後使數據文件上線,那麼此時需要使用關鍵字UNRECOVERABLE DATAFILE.數據文件必須被刪除因爲
SQL> ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 2 UNRECOVERABLE DATAFILE;
-
Immediately back up all data files in the database with an operating system utility, so that you have a backup you can use for complete recovery without relying on the cleared log group. For example, enter:
立即備份所有的數據文件使用操作系統工具,以至於你有一個不用依賴被清除的日誌組就能做完全恢復的備份,
% cp /disk1/oracle/dbs/*.dbf /disk2/backup
-
Back up the database's control file with the
ALTER
DATABASE
statement. For example, enter:SQL> ALTER DATABASE BACKUP CONTROLFILE TO '/oracle/dbs/cf_backup.f';
The ALTER
DATABASE
CLEAR
LOGFILE
statement
can fail with an I/O error due to media failure when it is not possible to:
alter database clear logfile 語句如果不能做下面的操作 會失敗由於介質故障導致的io錯誤,
-
Relocate the redo log file onto alternative media by re-creating it under the currently configured redo log file name
通過當前配置的日誌文件的名稱重新創建日誌文件 遷移日誌日誌到另外的介質上
-
Reuse the currently configured log file name to re-create the redo log file because the name itself is invalid or unusable (for example, due to media failure)
重新使用當前的配置日誌文件的名稱去重新創建日誌文件因爲他自己的名字是無效的或者不可用。
In these cases, the ALTER
DATABASE
CLEAR
LOGFILE
statement
(before receiving the I/O error) would have successfully informed the control file that the log was being cleared and did not require archiving. The I/O error occurred at the step in which the CLEAR
LOGFILE
statement
attempted to create the new redo log file and write zeros to it. This fact is reflected in V$LOG.CLEARING_CURRENT
.
在這些情況下,alter database clear logfile 語句
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 the operation is successful, then the active redo log becomes inactive, and you can follow the procedure in "Losing
an Inactive Online Redo Log Group". If the operation is unsuccessful, or if your database has halted, then perform one of procedures in this section, depending on the archiving mode.
The current log is the one LGWR
is currently writing to. If a LGWR
I/O operation fails, then LGWR terminates and the instance fails. In this case, you must restore
a backup, perform incomplete recovery, and open the database with the RESETLOGS
option.
Recovering from the Loss of Active Logs in NOARCHIVELOG Mode
In this scenario, the database archiving mode is NOARCHIVELOG
.
To recover from the loss of an active online log group in NOARCHIVELOG mode:
-
If the media failure is temporary, then correct the problem so that the database can reuse the group when required.
-
Restore the database from a consistent, whole database backup (data files and control files). For example, enter:
% cp /disk2/backup/*.dbf $ORACLE_HOME/oradata/trgt/
-
Mount the database:
STARTUP MOUNT
-
Because online redo logs are not backed up, you cannot restore them with the data files and control files. To allow the database to reset the online redo logs, you must first mimic incomplete recovery:
RECOVER DATABASE UNTIL CANCEL CANCEL
-
Open the database using the
RESETLOGS
option:ALTER DATABASE OPEN RESETLOGS;
-
Shut down the database consistently. For example, enter:
SHUTDOWN IMMEDIATE
-
Make a whole database backup.
If the media failure is temporary, then correct the problem so that the database can reuse the group when required. If the media failure is not temporary, then use the following procedure.
Recovering from Loss of Active Logs in ARCHIVELOG Mode
In this scenario, the database archiving mode is ARCHIVELOG
.
To recover from loss of an active online redo log group in ARCHIVELOG mode:
-
Begin incomplete media recovery, recovering up through the log before the damaged log.
-
Ensure that the current name of the lost redo log can be used for a newly created file. If not, then rename the members of the damaged online redo log group to a new location. For example, enter:
ALTER DATABASE RENAME FILE "/disk1/oradata/trgt/redo01.log" TO "/tmp/redo01.log"; ALTER DATABASE RENAME FILE "/disk1/oradata/trgt/redo02.log" TO "/tmp/redo02.log";
-
Open the database using the
RESETLOGS
option:ALTER DATABASE OPEN RESETLOGS;
Note:
All updates executed from the end point of the incomplete recovery to the present must be re-executed.
Loss of Multiple Redo Log Groups
If you have lost multiple groups of the online redo log, then use the recovery method for the most difficult log to recover. The order of difficulty, from most difficult to least difficult, is as follows:
-
The current online redo log
-
An active online redo log
-
An unarchived online redo log
-
An inactive online redo log