故障处理：偶遇Oracle备份与还原的未知重大BUG

我们的文章会在微信公众号IT民工的龙马人生和博客网站( www.htz.pw )同步更新，欢迎关注收藏，也欢迎大家转载，但是请在文章开始地方标注文章出处，谢谢！

由于博客中有大量代码，通过页面浏览效果更佳。

运气爆棚，一套运行了差不多7年的数据库环境在今天遇到2个BUG，一个是Oracle BUG，一个是Linux操作系统的BUG，接下来就和大家先看看Oracle这个未知的重大BUG，因为时间紧，也没有详细去分析到底是什么原因触发的BUG，下面大概的描述一下过程。

环境介绍

数据库的版本为Oracle 11.2.0.4 PSU为2018年上线时最新的PSU，架构为单机的主从架构。这个环境的操作系统、数据库、硬件和迁移都是我在2018年一条龙服务弄的，是一个医院的环境。整个环境运行非常的稳定，曾经在某年早上9点业务高峰期故障时，仅用了2分钟（系统上线时就已经实现一键容灾切换和浮动IP地址的一键切换），就完成了数据库切换和业务系统的恢复。这里多说一句，对医院行业中单机环境可能比RAC的稳定性更高，故障恢复时间更短，并且成本可以做到很低。就如这家医院用不到15万的硬件费用购买2台X86服务器替换了原来的基于小机的HA和存储双活的架构。

操作过程

前面提到客户当前的架构为一主一从，其实最开始设计的是一主二从的架构，其中有一台服务器放到另外一栋楼的容灾机房，实现双数据中心数据库的容灾，但后来因为网络整改后出现网络异常，容灾机房的服务器就下线了。后来客户想把容灾机房的数据库同步恢复，由于就有了这次的需求，重新搭建DG环境。

这里没有采用常规的duplicate方式来搭建DG，而是通过将备库中最近一次全备及后面的增量备份和归档日志备份的RMAN备份文件复制到容灾机房服务器上，通过RMAN的restore和recover命令来恢复。

数据库恢复完成，启动实时同步，但是alert日志中报需要135的归档日志，这个就尴尬了，135那个时候的归档还在2018年，感觉非常的奇怪。于是查询数据文件头的信息，查询信息如下：

set lines 300

alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss';

col checkpoint_change# for 99999999999999 ;

select file#,checkpoint_time,checkpoint_change# from v$datafile_header;

  FILE# CHECKPOINT_TIME     CHECKPOINT_CHANGE#

------- ------------------- ------------------

      8 2025-08-13 00:50:02     37045059023994

     11 2025-08-13 00:50:02     37045059023994

     10 2025-08-13 00:50:02     37045059023994

      9 2025-08-13 00:50:02     37045059023994

     33 2023-03-07 15:45:31     36758410072244

     23 2018-08-07 18:22:89              82399

这里看到数据文件23的checkpoint的信息还是2018年，scn的值也是非常的。这个不应该啊，RMAN备份文件是最近一次的备份，并且整个restore过程中没有报错。查询v$datafile控制文件中的SCN信息是正常的。

但是由于时间紧急，没有过多去分析原因，于是在重新执行了一次数据文件的还原：

restore datafile 23,33;

recover datafile 23,33;

通过利用同一份备份集文件在进行一次数据文件还原后数据文件的SCN的信息正常了。

不知道是什么BUG

由于后续的变更都需要依赖这套环境，所以也没有过多的去分析原因，但是可以肯定的是第一次restore database时是没有报错的，出现这个现象是真的很奇怪，最少目前没有发现任何已知的BUG。

这里提示大家，数据库一个有效的备份系统是由正确的备份策略、可还原的备份集和可还原的技术方案三部分组成，别以为只做了备份就有一个有效的备份系统了。

------------------作者介绍-----------------------

姓名：黄廷忠

现就职：Oracle中国高级服务团队

曾就职：OceanBase、云和恩墨、东方龙马等

电话、微信、QQ：18081072613

个人博客: (http://www.htz.pw)

CSDN地址: (https://blog.csdn.net/wwwhtzpw)

博客园地址: (https://www.cnblogs.com/www-htz-pw)