如题所示的错误发生在使用RMAN恢复数据库后,Open的时候。

具体如下:

造成该问题的原因是:
Control File中记录的SCN与Data File中记录的SCN不一致。
在我的环境中是:
通过restore恢复出来的Control File的SCN比Data File记录的SCN要小。

解决该问题的方法:
1. 以旧的Control File的SCN为主,将Data File恢复到与控制文件的SCN一致。
—> 影响,可想而知,数据一定会不一致,… 也就是会丢失。

2. 以Data File的SCN为主,将Control File的SCN恢复一致。
—> 这时候,就出现了文首的【ORA-01152】的错误
—> 通过:
——> recover database
——> 利用:归档日志
——> 利用:联机日志(redo log)

3. 通过内置参数,跳过一致性检查,启动数据库(不要轻易尝试,操作不好,容易加剧故障)

————————————
一、重现问题
由于解决该问题的时候,是在客户现场,所以以下本文的环境为实验环境中的【复演】

前提条件:
1. 装好了Oracle Database的Linux
2. 已经有一个数据库实例在正常运行

我的环境:

数据库当前的状态信息:

这里,数据库的DBID需要记住,后面的步骤会使用到。

RMAN:备份当前控制文件:

控制文件已经备份到了【/u01/app/oracle/fast_recovery_area/ORCL/backupset/2017_09_21/o1_mf_ncnnf_TAG20170921T080516_dw7o9j26_.bkp】,如下:

模拟数据文件的改变:
向数据库插入数据,以改变数据文件的SCN:
插入数据前,数据文件的SCN

可以看到,当前的CHECKPOINT_CHANGE均为:1026953。

插入几条数据:

再查查数据文件的CHECKPOINT_CHANGE:

好像没变化?

一致性停库:

启动数据库:nomount

RMAN:设置DBID,为之前的DBID【1480402367】

先改变原控制文件的位置,这样ORACLE就认为控制文件不存在了:

利用开始的RMAN备份,恢复控制文件:
备份文件:

RMAN恢复:

延续上面设置DBID的会话操作,不要另开会话执行。

恢复控制文件成功后,查看文件系统状态:

启动数据库:mount

启动数据库:open

这样,文首的错误,就重现了。

发生该错误的时候,ALERT日志的信息如下:
tail -f /u01/app/oracle/diag/rdbms/orcl/orcl/trace/alert_orcl.log

另一个细节,这里也顺便说一下:
如果有心的话,查看RMAN的Incarnation,会发现,当前数据库已经有两个化身了:

——————————————————
本文对于该问题的处理策略为:【以DATA FILE的SCN为主,修复控制文件的SCN,并起库】

两种方式选择:

——————————————————————
WAY 1:

SQLPlus,手动利用归档恢复数据库:

错误提示说找不到归档日志。

ALERT日志的报错信息:

确实没有归档日志:

当前数据库归档模式也没有打开:

利用联机日志恢复:

如上,使用【CURRENT】的REDO LOG做介质恢复。

恢复成功后,就可以打开数据库了:

这个过程的ALERT日志:

查看下此时的数据文件的CHECKPOINT_CHANGE:

这样,数据库就恢复成功了。

细节:
这时候的INCARNATION,已经到了3个:

——————————————————————————
WAY 2:
首先,按照上面的方法重演错误 – 该部分按照上面的步骤操作即可,略过。

这一次,我的控制文件是:【/u01/app/oracle/fast_recovery_area/ORCL/backupset/2017_09_21/o1_mf_ncnnf_TAG20170921T090520_dw7rt1f7_.bkp】

错误信息::

Alert日志:

第二种修复该问题的方法是:利用Rman自动应用归档恢复数据库:

可以看到,数据库已恢复。

——————————————
通过修改隐藏参数的方法,恢复数据库:

首先还是按照上面的方法,将错误重演出来:

这次的控制文件备份是:

错误重现:

这次,通过修改隐藏参数,修复数据库:

查看,并修改隐含参数:【_allow_resetlogs_corruption】

该过程的ALERT日志:

重启数据库,使之生效:

可以看到,隐藏参数,已经生效。

恢复数据库:

Alert日志:

打开数据库:

Alert日志:

然后,退出去,启动数据库:

该过程的ALERT日志:

还原隐藏参数:

查看下测试表的数据是否还在:

可以看到,数据都是存在的,而且是正确的。
至此,ORA-01152的问题,解决。

细节:
RMAN的INCARNATION:

——————————————

推荐的步骤,上面恢复完数据库后,做一个全备份

——————————————
Done。

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

隐藏
变装