ORA-16220报错没找到失败事务，远程帮忙修复故障的那些事儿

ORA-16220报错没找到失败事务，远程帮忙修复故障的那些事儿

这事儿得从一次深夜的紧急电话说起,那天晚上，我睡得正香，手机跟催命符似的响个不停，接起来一听，是合作公司的一位运维小哥，声音都急得变了调，说他们核心的生产数据库出大事了，一个关键的备库死活同步不了主库的数据，日志里刷了一大片“ORA-16220”错误，他们几个人折腾了好几个小时，一点头绪都没有，业务眼看就要受影响。

我一边揉着惺忪的睡眼打开电脑,一边让他别慌，先把具体的报错信息和日志片段发过来，ORA-16220这个错误代码，翻译成大白话就是Data Guard的归档进程（ARCH）在备库上怎么也找不到主库传过来的某个归档日志文件，这就好比主库那边说“我把一箱重要文件（归档日志）通过快递发给你了”，但备库这边翻遍了仓库（指定的归档目录），就是找不到这个快递箱，于是急得直报错。

远程连上去之后,我首先按照常规思路检查了一遍，我让小哥在备库上执行了SELECT * FROM V$ARCHIVED_LOG;，查看已经接收到的归档日志序列号，然后又让他在主库执行了SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG;，确认当前最大的日志序列号，这一对比，问题就显现出来了：备库上最新的日志号比主库落后了大概十几个，这说明有一批日志文件确实“丢失”了，导致备库的应用进程（MRP）卡在中间，无法继续前进。

就是要当个“侦探”，找出这批日志究竟去哪儿了，最直接的怀疑对象就是备库上的归档目标目录，我让小哥用ls -l命令仔细查看了归档目录，果然，目录里的日志文件序列号在某个点之后就直接断档了，中间缺了那关键的十几个文件，文件为什么没传过来呢？

问题可能出在两个地方：要么是主库没成功发出“快递”，要么是网络“快递”路上丢了，或者备库这边“签收”出了问题，我们开始顺藤摸瓜，先检查主库的归档进程状态，是正常的；再看主库的归档日志目录，发现那些缺失的日志文件好端端地躺在那里，这说明主库是正常生成了文件并尝试发送的，焦点就转移到了传输环节。

我们检查了备库的日志接收服务（RFS进程）相关的网络配置和监听状态，似乎也没发现明显异常，这时候，我注意到一个细节：在问题发生的时间点附近，主库所在的主机因为存储空间告急，被他们的运维同事紧急清理过一批文件，我心里“咯噔”一下，赶紧问小哥：“当时清理文件的时候，有没有可能误操作，动了正在传输或者还没传输的归档日志相关的什么东西？”

这一问,小哥也有点含糊了，说当时情况紧急，是好几个人一起操作的，记不清具体细节了，看来，这很可能就是问题的根源——一次不规范的手工干预，意外打断了日志的正常传输链。

原因大致有谱了,解决办法就相对直接了，既然缺失的日志文件还在主库上，最简单的办法就是手动把它们“送”到备库，我们采用了最稳妥的“手动注册归档日志”的方式，具体步骤如下：

1. 手动拷贝文件：我让小哥使用scp命令，将主库上那十几个缺失的归档日志文件，一个一个地复制到备库的正确归档目录下，这个过程得确保文件权限和属主正确。
2. 在备库注册日志：文件拷贝完成后，光放在目录里还不够，需要告诉备库的数据库实例“这些文件是有效的归档日志，你可以用了”，我们使用ALTER DATABASE REGISTER PHYSICAL LOGFILE ‘文件完整路径’;命令，为每一个拷贝过来的日志文件执行了注册操作。
3. 重启应用进程：所有缺失的日志都注册成功后，我让小哥在备库上执行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;，重新启动MRP进程。
4. 验证同步：紧张地盯着屏幕，我们看到MRP进程顺利启动，并且开始依次应用刚才注册的那些日志，通过反复查询SELECT PROCESS, STATUS, SEQUENCE# FROM V$MANAGED_STANDBY;，看到MRP进程的序列号稳步追上了主库的最新位置，那个烦人的ORA-16220错误也不再出现了，至此，备库终于恢复了正常同步。

问题虽然解决了,但事后我们总结，这次故障的根本原因在于运维流程的不规范，在高压环境下，手工清理文件这种操作风险极高，我建议他们之后要加强监控预警，在存储空间达到一定阈值时就提前自动清理非核心数据，并严格规范所有对生产环境的操作流程，避免类似“手滑”事件再次发生，这次远程救援，也算是一次生动的运维规范教育课了。