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

2015-01-21 12:22:39 · 作者: · 浏览: 13

一.说明:
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字段)。


例子:


SQL> startup mount


ORACLE 例程已经启动。


Total System Global Area? 263639040 bytes


Fixed Size? ? ? ? ? ? ? ? ? 1384012 bytes


Variable Size? ? ? ? ? ? 167772596 bytes


Database Buffers? ? ? ? ? 88080384 bytes


Redo 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:\APP\ORADATA\ORCL\REDO03.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 mount


ORACLE 例程已经启动。


?



Total System Global Area? 263639040 bytes


Fixed Size? ? ? ? ? ? ? ? ? 1384012 bytes


Variable Size? ? ? ? ? ? 167772596 bytes


Database Buffers? ? ? ? ? 88080384 bytes


Redo 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 mount


ORACLE 例程已经启动。


Total System Global Area? 263639040 bytes


Fixed Size? ? ? ? ? ? ? ? ? 1384012 bytes


Variable Size? ? ? ? ? ? 167772596 bytes


Database Buffers? ? ? ? ? 88080384 bytes


Redo 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 WRITE


SQL> select status from v$instance;


STATUS


------------


OPEN


SQL> 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 dataf