【恢复,1】 redo 日志恢复的各种情况,redo日志
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.
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$LOGFILEand 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:
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 ,日志没有归档:
Failure of CLEAR LOGFILE Operation
失败的清除日志文件操作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. 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:
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:
很简单 进入rman
redolog file文件的丢失:
shutdown immediate;
starup mount;
alter database resetlogs;(这一步可能会出现问题 则在这之前加上一句
recover database until cancel;
并且所有步骤重新再在sqlplus中来一遍)
不过这个方法使用了resetlogs,有可能造成数据损失
百度搜吧,不行的话你多换搜索引擎吧,或者多换关键词搜索,google学术里面应该有的,你自己去找吧