暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

记一次存储故障导致数据库无法启动修复过程【简】

DigOps 2019-01-21
645


引发原因

        一套HDS的G800多控制器都出现问题,导致存储故障,Oracle数据库数据都放在了这上面。在存储修复以后无法将数据库拉起,报控制文件不一致。

如何解决?

        由于是存储端引起的问题,我们只是看到在启库时,控制文件的不一致,和掉电有点类似,但存储端毕竟是还存在控制器CACHE问题,CACHE的丢失,对数据的一致性多多少少都会影响,因此就要做好充足的心里准备,那就是丢数据。我们通过Oracle自身的RMAN完全恢复及不完全恢复技术来解决问题。

理清思路!

        了解故障发生的原因同时,也要将目前生产涉及的数据库情况了解清楚,哪些是开归档进行如何备份的,哪些是非归档无备份的,都要调查清楚。

    ==>对于开归档有备份的情况

恢复起来比较简单,根据不同的损坏程度,来有策略性的恢复。

  • a.单控制文件损坏,恢复控制文件,利用现有的redo、arch完全恢复数据,此时基本不会丢失数据(最简单);

  • b.控制文件+REDO损坏,恢复控制文件,利用arch及部分可用redo进行不完全恢复,此时会丢失一小部分最近数据,丢失多少取决于业务繁忙及redo大小;

  • c.控制文件+REDO损坏+最近归档丢失,使用上一次备份+归档追加方式恢复到最近的可恢复时间;

  • d.c+数据文件损坏,不用考虑了,直接恢复上一次备份。

    ==>对于非归档无备份的情况

恢复归结为天命,要么一条命令就可以恢复出来,要么就经历非常痛苦的过程,进行不一致恢复

  • a.控制文件丢失,重建控制文件,执行recover database,进行完全恢复。

  • b.控制文件+REDO损坏,重建控制文件,执行recover database,会出现system表空间不一致,此时需要可考虑scn的推进、设置resetlogs隐含参数、BBED等非常规方法来开库。


解决过程

    ==>针对开归档有备份

Step1 校验数据文件是否有坏块

方法一、RMAN VALIDATE


方法二、DBV VALIDATE


Step2 数据文件、在线日志scn一致性检查

  • 通过v$logfile、v$log查看在线日志

  • 通过v$datafile_header、v$datafile查看数据文件


Step3 控制文件恢复

  1. 对于多个控制文件,若出现不一致,使用最大version先进行恢复,若不可以,再使用其他version进行恢复。所有控制文件不可用,进行第二步。

  2. 若有控制文件的自动备份,可以通过自动备份的控制文件进行恢复,在没有自动备份的情况,从备份中恢复控制文件。

    注:默认位置为:$ORACLE_HOME/dbs下,对于RAC,一般会更改到共享存储上。

  3. 更换数据库控制文件


Step4 数据库恢复


注:此时若redo log没有顺坏、恢复过程没有报错,则直接进行开库;若redo log损坏,则通过备份进行不完全恢复;


Step5 开库

    ==>针对非归档无备份

Step1 数据文件、在线日志scn一致性检查

  • 通过v$logfile、v$log查看在线日志

  • 通过v$datafile_header、v$datafile查看数据文件


Step2 控制文件恢复

  1. 对于多个控制文件,若出现不一致,使用最大version先进行恢复,若不可以,再使用其他version进行恢复。所有控制文件不可用,进行第二步。

  2. 若有控制文件的自动备份,可以通过自动备份的控制文件进行恢复,在没有自动备份的情况,从备份中恢复控制文件。

    注:默认位置为:$ORACLE_HOME/dbs下,对于RAC,一般会更改到共享存储上。

  3. 更换数据库控制文件


Step3 数据库恢复


注:此时若redo log没有顺坏、恢复过程没有报错,则直接开库,若redo log损坏或所需恢复的scn不在redo log中,则要进行非常规恢复(以下重点说明)



在Rman恢复时,需要恢复数据文件1,此时因为没有开归档,无法进行一致性恢复,因此只能采用非常规方式进行开库

1)尝试一、oradebug poke 对scn进行推进

        选择合适的scn值进行推进,要合理进行计算。参考

poke方法

2)尝试二、设置_allow_resetlogs_corruption=true

        如果采用这种方式直接开库会引起回滚段问题,且库无法打开:


         解决方法是通过尝试一,合理poke,但可能会遭遇ORA-00600 [4194]

        此时完全转化UNDO问题,只要通过restrict模式开库,重建undo即可解决。


3)终极尝试三、BBED修改底层文件头,强行推进

如果以上两种方式都已经尝试,并且采用resetlogs方式依然无法开库(resetlogs已经生效),则只能采取此种方法进行解决。

修改的偏移量有:



参考文档

  • Step by step to resolve ORA-600 4194 4193 4197 on database crash (文档 ID 1428786.1)

  • ORA-01503 ORA-01189 When trying to Recreate Controlfile (文档 ID 1918706.1)

  • Open Database failed - DATAFILE NEEDS MORE RECOVERY TO BE CONSISTENT ORA-1194 ORA-1547 ORA-1110 (文档 ID 1528788.1)


文章转载自DigOps,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论