罩这套 Java 监控系统太香了！我连夜给项目加上了A

环境介绍

数据库的版本为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。

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