重做日志文件损坏测试
参考：http://blog.chinaunix.net/uid-17143914-id-2824664.html

数据库的所有增、删、改都会记录入重做日志。如果当前激活的重做日志文件损坏，会导致数据库异常关闭。非激活的重做日志最终也会因为日志切换变为激活的重做日志，所以损坏的非激活的重做日志最终也会导致数据库的异常终止。在ipas/mSwitch中每组重做日志只有一个成员，所以在下面的分析中只考虑重做日志组损坏的情况，而不考虑单个重做日志成员损坏的情况。

一、确定损坏的重做日志的位置及其状态：
1. 如果数据库处于可用状态：
select * from v$logfile;
select * from v$log;

2. 如果数据库处于已经异常终止：
startup mount;
select * from v$logfile;
select * from v$log;

其中，logfile的状态为INVALID表示这组日志文件出现已经损坏；log状态为Inactive：表示重做日志文件处于非激活状态；Active：表示重做日志文件处于激活状态；Current：表示是重做日志为当前正在使用的日志文件。

二、损坏的日志文件处于非激活状态：
1. 删除相应的日志组：
alter database drop logfile group 4;

2. 重新创建相应的日志组：
alter database add logfile group 4 ('/oracle/app/oracle/oradata/orcl/redo41.log','/oracle/app/oracle/oradata/orcl/redo42.log') size 50m;
alter database add logfile member '/oracle/app/oracle/oradata/orcl/redo43.log' to group 4;


三、损坏的日志文件处于激活状态且为非当前日志：
1. 清除相应的日志组：
alter database clear unarchived logfile group group_number;
操作后，该日志组状态为“UNUSED”；

如rm日志组中一个文件，切换日志后台日志会报错，将数据库重启到mount状态，clear 后，将自动创建刚才删除的日志文件；

如不做处理，重新启动数据库，会报如下错误，直接退出启动进程；
Tue Apr 12 18:06:00 2016
ARC1 started with pid=21, OS id=18715
USER (ospid: 18711): terminating the instance due to error 313
System state dump requested by (instance=1, osid=18711), summary=[abnormal instance termination].
System State dumped to trace file /oracle/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_diag_18681_20160412180600.trc
Dumping diagnostic data in directory=[cdmp_20160412180600], requested by (instance=1, osid=18711), summary=[abnormal instance termination].
Instance terminated by USER, pid = 18711



四、损坏的日志文件为当前活动日志文件：
用命令清除相应的日志组：
alter database clear unarchived logfile group group_number;
如果清除失败，则只能做基于时间点的不完全恢复。
打开数据库并且用适当的方法进行数据库全备份：
alter database open;


五、归档模式，数据库open状态、当前正在使用的日志文件损坏，并且异常关闭数据库。
创建两个测试表后，
删除当前的redo log;
shutdown abort
startup
报错：

解决办法：
这时候我们有两种办法，一种是使用备份进行恢复，另一种是使用隐含参数。介绍第二种：
该参数是在数据库不一致的情况下，设置后允许数据库启动，然后重置日志文件。
alter system set "_allow_resetlogs_corruption"=true scope=spfile;
恢复默认值：alter system reset "_allow_resetlogs_corruption" scope=spfile;

sys@ORCL> shutdown immediate
ORACLE instance shut down.
sys@ORCL> startup
报错；
sys@ORCL> select status from v$instance;
STATUS
------------
MOUNTED

sys@ORCL> select * from v$log;

alter database open resetlogs;

ORA-01139: RESETLOGS option only valid after an incomplete database recovery

需要这样：
sys@ORCL> recover database until cancel;
ORA-00279: change 2922743 generated at 04/12/2016 17:39:18 needed for thread 1
ORA-00289: suggestion : /oracle/app/oracle/fast_recovery_area/ORCL/archivelog/2016_04_12/o1_mf_1_9_%u_.arc
ORA-00280: change 2922743 for thread 1 is in sequence #9

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/oracle/app/oracle/oradata/orcl/system01.dbf'

ORA-01112: media recovery not started

alter database open resetlogs;

丢失刚才创建当前redolog的测试表；
resetlog后重建redo日志；


重建实例然后使用expdp和impdp，将数据导出在导入数据库
SQL> create directory expdp as '/opt/app/oracle/oradata';

然后导出数据重建数据库，再导入数据。
总结：对于当前正在使用的日志的损坏，一般通过备份来修复，如果不行只能采用第二种设置隐含参数_allow_resetlogs_corruption来恢复。

六、总结，对于不是当前使用的归档日志损坏，归档模式需要使用alter database clear unarchived 命令清空日志组即可。
对于非归档模式需要使用alter system clear日志文件组即可。