ORA-16799报错导致Redo Apply停止，远程排查修复思路分享

（引用来源：知乎专栏“Oracle数据库运维实战” - 《记一次棘手的DataGuard故障：ORA-16799》）

ORA-16799这个错误，是Oracle DataGuard环境中一个比较让人头疼的问题，当你在主库上忙活了一阵，比如修改了一个重要的参数文件（pfile或spfile），或者对数据库的某些结构做了改动，然后高高兴兴地想去看看备库的状态时，可能会惊讶地发现，备库的Redo Apply（就是那个负责把主库传过来的日志应用到备库的进程）停掉了。 alert日志里就会明明白白地告诉你，遇到了ORA-16799错误，后面通常会跟着一句提示,说数据库的检查点SCN或者数据文件检查点SCN对不上。

这个错误就像是主库和备库这两个双胞胎兄弟，在同步成长的过程中，突然发现他们俩的“进度条”对不上了，主库说：“我已经跑到1000米了”，而备库的某个数据文件却说：“不对啊，我这才记录到800米呢”，这种不一致导致备库不敢再继续应用日志了，因为它怕把数据给应用乱了,造成更严重的损坏。

（引用来源：CSDN博客“DBA手记” - 《远程解决DataGuard ORA-16799报错全过程记录》）

当我们需要远程排查这个问题时，手头能用的工具基本上就是命令行，思路一定要清晰，第一步，绝对不是急着去重启进程或者盲目操作，首先要做的,是确认问题的详细情况。

1. 查看详细的错误信息：光知道ORA-16799还不够，我们需要看alert日志里完整的报错内容，通常它会明确指出是哪个数据文件（File #）的检查点SCN和备库当前的重做日志SCN不匹配，把这个文件号和数据文件名记下来，命令很简单，就是tail -f alert_<SID>.log,然后找到报错的那几行。

2. 对比主备库的数据文件头信息：这是最关键的一步，我们需要分别在主库和备库上查询那个出问题的数据文件头里的检查点SCN，在主库上，执行： SQL> select file#, name, checkpoint_change# from v$datafile_header where file# = <报错的文件号>; 在备库上，同样执行这个命令，绝大多数情况下，你会发现主库上这个文件的checkpoint_change#值要比备库上的大，这就证实了备库的这个文件确实“落后”了。

3. 分析原因：为什么会出现这种落后？常见的原因有几种，一是可能主库做过不完全恢复，或者有数据文件被离线然后又在线，但备库没有完全跟上这个操作，二是我开头提到的，主库修改了spfile并重启了，这个改动可能涉及到了某些与控制文件、数据文件结构相关的隐含参数，导致检查点信息发生变化，三是在某些极端情况下,存储层面或网络问题可能导致数据文件写入不完整。

   

（引用来源：知乎专栏“Oracle数据库运维实战” - 《记一次棘手的DataGuard故障：ORA-16799》）

知道了原因，修复思路就相对明确了，我们的目标是把备库那个落后的数据文件“推”到和主库一样的检查点位置，最直接、最常用的方法就是对这个文件进行增量备份恢复。

1. 在主库创建增量备份：这个增量备份不是随便备份的，它必须是从备库数据文件头检查点SCN开始备份,具体步骤如下：

   • 在备库上，查询到的那个出问题的数据文件的checkpoint_change#，我们记它为SCN_BACKUP。
   • 在主库上，使用RMAN，从这个SCN_BACKUP开始，为那个特定的数据文件做一个增量备份。 RMAN> BACKUP INCREMENTAL FROM SCN <SCN_BACKUP> DATAFILE <报错的文件号> FORMAT '/tmp/incr_%U.bkp'; 这个命令的意思是，只备份该数据文件从SCN_BACKUP到当前时间点之间发生变化的数据块,非常高效。

2. 将备份文件传输到备库：通过scp等工具,将这个增量备份文件拷贝到备库服务器的指定位置。

   

3. 在备库上应用增量备份：

   • 确保备库的MRP进程是停止状态 (ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;)。
   • 在备库的RMAN中，注册这个备份片，然后恢复那个数据文件。 RMAN> CATALOG BACKUPPIECE '/path/to/incr_xxxx.bkp'; RMAN> RECOVER DATAFILE <报错的文件号>;
   • 这个过程相当于把主库上该文件变化的数据块“补”到了备库上。

4. 重新启动同步：应用完成后，再次查询备库上该数据文件头的检查点SCN，应该已经和主库一致了，这时，就可以放心地重新启动Redo Apply进程了： SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

（引用来源：CSDN博客“DBA手记” - 《远程解决DataGuard ORA-16799报错全过程记录》）

也有一些特殊情况，如果出问题的文件是系统表空间的文件（比如file#1），或者上述增量备份方法因为某些原因失败，可能需要考虑更激进的方法，比如基于SCN的重复（RMAN DUPLICATE）或者甚至重建备库，但在大多数情况下，增量备份恢复法都是最快、对业务影响最小的选择。

远程排查这种事，最忌讳心慌，一步一步来，先精准定位问题根源（是哪个文件，SCN差多少），再选择最合适的工具和方法（RMAN增量备份），最后谨慎操作，每次处理完这样的问题，最好简单记录一下原因和步骤，下次再遇到类似的报错，心里就更有底了，毕竟，DataGuard的报错代码虽然多,但排查问题的逻辑往往是相通的。