REDO文件损坏修复

1 inactive日志组损坏

假如日志组4损坏，状态inactive。解决很简单，重建日志组即可
clear意味着重建group4的文件

alter database clear logfile group 4;

2 current日志组丢失

本例日志组1状态是CURRENT状态的，现在模拟当前日志组损坏

SQL> select group#,member from v$logfile;
[oracle@bpxtest]$ rm /路径/redo01.log
SQL> alter system switch logfile;   切换几次，触动它一下。

告警日志会记录有关信息
暂时好像没有什么问题发生，继续切换，当current 又转会到group1时，session死！
当前日志损坏的问题比较复杂，见上图可以分以下几种情况讨论

1）数据库没有崩溃

第一步，可以做一个完全检查点，将db buffer中的所有dirty buffer全部刷新到磁盘上。

SQL> alter system checkpoint;

第二步，尝试数据库在打开状态下进行不做归档的强制清除。

SQL> alter database clear unarchived logfile group n;

数据库此时为打开状态，这步若能成功，一定要做一个新的数据库全备，因为当前日志无法归档，归档日志sequence已无法保持连续性。全备的目的就是甩掉之前的归档日志。

2）数据库已经崩溃，只能做传统的基于日志的不完全恢复或使用闪回数据库。

SQL> recover database until cancel;
SQL> alter database open resetlogs;

3）如果之前没有可用的备份，或问题严重到任何方法都不能resetlogs打开数据库，为了抢救数据，考虑最后一招使用Oracle的隐含参数：_allow_resetlogs_corruption=TRUE

Oracle不推荐使用这个隐含参数
该参数的含义是：允许数据库在不致性的情况下强制打开数据库。
在不一致状态下强行打开了数据库后，建议做一个逻辑全备。

--查询隐含参数
col ksppinm for a50
col ksppstvl for a50
col ksppdesc for a50
SELECT ksppinm, ksppstvl, ksppdesc
FROM x$ksppi x, x$ksppcv y
WHERE x.indx = y.indx AND ksppinm like '%_optimizer_ansi_rearchitecture%';

3 active日志组损坏

做检查点切换，如成功，按照inactive损坏处理。否则，按current损坏处理。

备份恢复Lesson 12. Performing Recovery II