Redo丢失的4种情况及处理方法

一.说明：
1.以下所说的当前日志指日志状态为CURRENT,ACTIVE,非当前日志指日志状态为INACTIVE
2.不用考虑归档和非归档模式，2种模式下的Redo丢失情况一样。二.丢失Redo的4种情况：
第一种情况：非当前日志，正常关闭。
第二种情况：非当前日志，非正常关闭。
第三种情况：当前日志，正常关闭。
第四种情况：当前日志，非正常关闭。三.处理方法：
第一、二种情况的处理方法一样，直接把日志文件clear即可。
SQL> alter database clear logfile group 3;
SQL> alter database clear unarchived logfile group 3;//如果INACTIVE状态的在线Redo还未归档，增加关键字unarchived完成clear操作。（ACTIVE,INACTIVE都有可能未完成归档，归档是否完成可以查看v$log.archived字段）。RMAN_RAC恢复至单机时Redo日志引发的“恐慌” http://www.linuxidc.com/Linux/2014-10/108695.htmOracle RAC下调节Redo log file 文件大小 http://www.linuxidc.com/Linux/2014-10/107837.htmOracle非关键文件恢复,Redo、临时文件、索引文件、密码文件 http://www.linuxidc.com/Linux/2014-09/107394.htmOracle Redo Log 机制小结 http://www.linuxidc.com/Linux/2014-09/107129.htmOracle Redo log 大小及组数的设置（在线修改日志组数目及组成员个数） http://www.linuxidc.com/Linux/2014-09/106796.htmcurrent online Redo logfile 丢失的处理方法 http://www.linuxidc.com/Linux/2014-08/105979.htm例子：SQL> startup mountORACLE 例程已经启动。Total System Global Area 263639040 bytesFixed Size 1384012 bytesVariable Size 167772596 bytesDatabase Buffers 88080384 bytesRedo Buffers 6402048 bytes数据库装载完毕。
SQL> select group#,thread#,status,archived from v$log; GROUP# THREAD# STATUS ARCHIV---------- ---------- -------------------------------- ------ 1 1 CURRENT NO 3 1 ACTIVE NO 2 1 INACTIVE YES
SQL> alter database clear logfile group 3;alter database clear logfile group 3*第 1 行出现错误:ORA-01624: 日志 3 是紧急恢复实例 orcl （线程 1）所必需的ORA-00312: 联机日志 3 线程 1: "E:APPORADATAORCLREDO03.LOG"
SQL> alter database clear logfile group 2;数据库已更改。第三种情况的处理办法：
SQL>startup mount;
SQL>recover database until cancel;
SQL>alter database open resetlogs;
例子1：
SQL> shutdown immediate数据库已经关闭。已经卸载数据库。ORACLE 例程已经关闭。SQL> startup mountORACLE 例程已经启动。
Total System Global Area 263639040 bytesFixed Size 1384012 bytesVariable Size 167772596 bytesDatabase Buffers 88080384 bytesRedo Buffers 6402048 bytes数据库装载完毕。SQL> alter database open resetlogs;alter database open resetlogs*第 1 行出现错误:ORA-01139: RESETLOGS 选项仅在不完全数据库恢复后有效SQL> recover database until cancel;完成介质恢复。SQL> alter database open resetlogs;数据库已更改。例子2（第三种情况的第二个处理方法）：SQL> shutdown immediate数据库已经关闭。已经卸载数据库。ORACLE 例程已经关闭。SQL> startup mountORACLE 例程已经启动。Total System Global Area 263639040 bytesFixed Size 1384012 bytesVariable Size 167772596 bytesDatabase Buffers 88080384 bytesRedo Buffers 6402048 bytes数据库装载完毕。SQL> select group#,thread#,status,archived from v$log;
GROUP# THREAD# STATUS ARCHIV---------- ---------- -------------------------------- ------ 1 1 CURRENT NO 3 1 INACTIVE YES 2 1 INACTIVE YES
SQL> alter database clear logfile group 2;
数据库已更改。SQL> alter database clear logfile group 3;数据库已更改。SQL> alter database clear unarchived logfile group 3;数据库已更改。这里CURRENT的Redo日志文件组能被clear unarchived。SQL> alter database open;数据库已更改。如果Redo日志文件丢失，clear操作完成之后将在原有位置创建新的Redo日志文件。第四种情况的处理方法：
1.通过备份来还原、恢复数据。
2.通过修改参数文件中的参数
_allow_resetlogs_corruption=TRUE
来强制启动数据库。//虽然能够启动数据库到open状态，但是启动后的数据库数据字典、数据有可能导致不一致的情况出现，故需要在open下把整个数据库export，然后删除库，重建，再将export的数据import到新的数据库中。四.验证数据库是否正常关闭的方法SQL> select open_mode from v$database;OPEN_MODE--------------------READ WRITESQL> select status from v$instance;STATUS------------OPENSQL> select file#,checkpoint_change#,fuzzy from v$datafile_header; FILE# CHECKPOINT_CHANGE# FUZ---------- ------------------ --- 1 1165820 YES 2 1165820 YES 3 1165820 YES 4 1165820 YES FUZZY bit in datafile header means that there may have been writes into a datafile after the last checkpoint. E.g. there may be changes written to datafile with higher SCN than checkpoint_change# stored in datafile header （seen from v$datafile_header.checkpoint_change#）.
FUZYY表示模糊性，意思是，该数据文件处于模糊状态，在最近一次CHECKPOINT后，该文件上的数据可能被修改过了，但没来得及更新到该文件上（或者该文件不知道），需要读取日志信息来判断。SQL> select file#,checkpoint_change#,last_change# from v$datafile; FILE# CHECKPOINT_CHANGE# LAST_CHANGE#---------- ------------------ ------------ 1 1165820 2 1165820 3 1165820 4 1165820由于数据库是打开的状态，所以终止SCN是空，SCN的内容可参考文章：http://www.linuxidc.com/Linux/2014-11/109877.htmSQL> shutdown immediate数据库已经关闭。已经卸载数据库。ORACLE 例程已经关闭。SQL> startup mountORACLE 例程已经启动。Total System Global Area 313860096 bytesFixed Size 1384352 bytesVariable Size 155189344 bytesDatabase Buffers 150994944 bytesRedo Buffers 6291456 bytes数据库装载完毕。SQL> select file#,checkpoint_change#,fuzzy from v$datafile_header; FILE# CHECKPOINT_CHANGE# FUZ---------- ------------------ --- 1 1166324 NO 2 1166324 NO 3 1166324 NO 4 1166324 NO 在正常管理数据库的情况下，FUZZY字段都应该是NO，表示没有模糊不清的SCN存储在数据文件中。SQL> select file#,checkpoint_change#,last_change# from v$datafile; FILE# CHECKPOINT_CHANGE# LAST_CHANGE#---------- ------------------ ------------ 1 1166324 1166324 2 1166324 1166324 3 1166324 1166324 4 1166324 1166324 正常关闭数据库的终止SCN应该和启动SCN相同。FUZZY等于NO，??数据库的终止SCN等于启动SCN等于数据文件SCN，那么可以认为数据库是正常关闭，且在打开数据库之前不需要执行实例恢复或Crash恢复。SQL> alter database open;数据库已更改。SQL> shutdown abortORACLE 例程已经关闭。SQL> startup mountORACLE 例程已经启动。Total System Global Area 313860096 bytesFixed Size 1384352 bytesVariable Size 155189344 bytesDatabase Buffers 150994944 bytesRedo Buffers 6291456 bytes数据库装载完毕。SQL> select file#,checkpoint_change#,fuzzy from v$datafile_header; FILE# CHECKPOINT_CHANGE# FUZ---------- ------------------ --- 1 1166327 YES 2 1166327 YES 3 1166327 YES 4 1166327 YES 非正常关闭数据库实例，FUZZY字段的值是YES。SQL> select file#,checkpoint_change#,last_change# from v$datafile; FILE# CHECKPOINT_CHANGE# LAST_CHANGE#---------- ------------------ ------------ 1 1166327 2 1166327 3 1166327 4 1166327
非正常关闭数据库实例，终止SCN依然为空。那么，在数据库被打开之前必须使用归档Redo日志完成实例恢复或Crash恢复。五.结论：
非正常关闭的当前日志丢失，可能导致数据库启动后的混乱，并可能造成少量数据的丢失。其他情况不会导致数据的丢失。相关文章：《alter system archive log current / all / switch logfile》：http://www.linuxidc.com/Linux/2014-11/109875.htm更多Oracle相关信息见Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx？tid=12本文永久更新链接地址