redo文件损坏的示例分析
这篇文章将为大家详细讲解有关redo文件损坏的示例分析，小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。
第一种情况：
asm存储方式，在数据库open步骤时，提示某个磁盘组无法归档某个在线日志，无法写入文件，此时未归档的redo log刚好是需要启动时归档的日志。
1.确定一下 归档空间是否已经满了
如果alert日志提示，没有可用的目标空间，首先需要考虑这一点
2.如果空间释放后(使用rman进行删除)，仍不能启动
需要把对应的在线日志清空
alter system clear logfile group 2;
或：alter system clear unarchived logfile group2;
3.启动后，全备份数据库
rman>backup database plush archivelog to destination='/oracle/dbbackup';
第二种情况：
普通单实例情况下，服务器重启无法打开，提示某个在线日志找不到无法打开，启动到mount状态后查询v$log发现状态为current：
alert日志有如下错误：
ORA-00313: open failed for members of log group 4 of thread 1
ORA-00312: online log 4 thread 1: '/home/oracle/oradata/orcl/redo04B.log'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
查看对应目录文件，文件确实存在。
alter database open;提示 数据库需要crash recovery;
尝试 关闭数据库 拷贝对应的redo4.log文件，但无法拷贝。
数据库没有备份，需要进行异常恢复。
alter database mount;
recover database until cancel; -- 提示需要使用resetlogs方式打开
alter database open resetlogs; -- 提示datafile 1 需要进一步恢复
recover datafile 1; -- 又回到提示redo04B.log文件无法读取
alter system set "_allow_resetlogs_corruption"=true scope=both;
shutdown immediate;
alter dtabase mount;
recover database until cancel;
recover datafile 1;
alter database open;
此时alert中存在 ORA-00600: internal error code, arguments: [4194]错误，这是因为 undo中数据库与实际数据不一致导致的。
重建-undo可以解决此问题；
create undo tablespace undotbs2 datafile '/u01/oracledata/undotbs201.dbf' size 10G autoextend on next 100M maxsize 20G;
alter system set undo_tablespace=undotbs2 scope=both;
shutdown immediate
startup
--全备份数据库
rman>backup database plush archivelog to destination='/dbbackup/';
此时，数据库可以启动，正常访问，可能有部分数据丢失
如果有些表查询 提示ora-01555错误,可以通过忽略对应回滚段来处理
alter system set "_corrupted_rollback_segments"='_SYSSMU9_1790233411$';
如果提示 初始化参数不能修改,需要执行如下
alter system set "_corrupted_rollback_segments"='_SYSSMU9_1790233411$' scope=spfile;
shutdown immediate
startup
关于"redo文件损坏的示例分析"这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。
