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文件损坏的示例分析”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。