ORA-31435清理操作出错了，远程帮忙修复故障的那些事儿

ORA-31435清理操作出错了，远程帮忙修复故障的那些事儿

这事儿得从一个深夜的紧急电话说起，那天我刚准备休息，手机就响了，屏幕上显示的是一个陌生号码，但归属地是外地，接起来一听，对方语气非常焦急，自称是某家公司负责数据库运维的王工，他上来就直接说：“老师，我们这边遇到一个ORA-31435的错误，流复制的清理作业（Cleanup）失败了，数据库现在有告警，我们几个搞了半天没头绪，能远程帮忙看看吗？”（来源：基于常见的DBA求助场景描述）

我一听ORA-31435，心里大概就有了谱，这个错误在Oracle的流复制（Streams Replication）环境里不算罕见，但处理起来确实需要点耐心和技巧，我让他别急,先把错误日志的完整信息发给我看看。

通过远程桌面连上去之后，我首先查看了数据库的告警日志（alert log），果然，里面清晰地记录着ORA-31435错误的详细信息，通常还会伴随一些关于“无法清除应用于删除的LCR”或者“清理进程遇到意外错误”之类的描述。（来源：Oracle官方文档对ORA-31435错误的典型描述）就是流复制架构中，负责清理已经应用过的历史数据的那个后台进程（名叫CLEANUP）卡住了，或者试图清理一些它认为不该清理、或者无法正常清理的数据,于是就报了错。

王工他们之前尝试过重启清理作业，甚至重启了相关的数据库进程，但错误依旧，这说明问题不是简单的“临时抽风”，而是有更深层次的原因，我让他们先别乱动,我开始一步步排查。

第一步，我查询了流复制的相关数据字典视图，比如DBA_STREAMS_MESSAGE_TRACKING（如果配置了跟踪的话）、DBA_APPLY_ERROR等，想看看是不是有应用错误（Apply Error）堆积，导致清理进程无法安全地清理掉这些有问题的数据。（来源：处理流复制问题的标准排查思路）检查后发现，应用器（Apply Process）那边倒是挺干净，没有积压的应用错误,这就排除了一个常见原因。

第二步，我把重点放在了清理进程本身和它的规则集（Rule Set）上，流复制的清理行为是由一系列规则精密控制的，规则定义了哪些数据可以被清理，我仔细检查了分配给清理进程的规则，特别是那些关于“负面规则”（Negative Rule）的部分——也就是告诉清理进程“哪些情况不要清理”。（来源：Oracle Streams概念指南中关于规则和清理的章节）果然，我发现有一条规则的逻辑可能有点问题，它可能在某些边界条件下，错误地阻止了清理进程对一批LCR（逻辑变更记录）进行清理，而这批LCR又确实已经被成功应用了，这种“该清又不能清”的矛盾状态，很可能就是导致清理进程“罢工”并抛出ORA-31435的根源。

找到疑点后，我没有贸然去修改生产环境的规则，我让王工找来了他们最初的流复制配置文档，对比了一下当前的规则设置，经过仔细比对，我们发现，当前规则集和文档记载的确实有一个细微的差异，很可能是之前某次不完整的配置变更留下的“尾巴”。（来源：实际运维中常见的配置漂移问题）

问题根源基本锁定，接下来就是修复了，这种规则问题，通常的解决方法是先停止流复制的捕获（Capture）、传播（Propagation）和应用（Apply）进程，然后谨慎地调整清理规则，最后再按顺序重新启动各个进程，我向王工详细解释了这个方案和潜在风险，比如在停止应用进程期间,目标端的数据会暂时停止更新。

王工和他们的团队评估后，决定在接下来的业务低峰期窗口进行操作,我远程指导他们完成了以下步骤：

1. 依次停止了应用进程、传播进程和捕获进程。
2. 根据分析，对那条有歧义的清理规则进行了修正,使其逻辑更加清晰和准确。
3. 确认规则修改无误后，再按相反顺序（捕获->传播->应用）重新启动各个进程。
4. 密切监控清理进程（CLEANUP）的日志和状态。

当看到清理进程顺利启动，并且不再报ORA-31435错误，开始正常清理历史数据时，电话那头的王工明显松了一口气，我们又观察了半个小时，确认整个流复制链路数据流动正常,这次故障才算真正解决。

事后复盘，王工感慨地说，他们之前光盯着应用错误和进程状态，没想到是规则集这个“幕后黑手”在捣鬼，我也提醒他，对于流复制这种比较精细的架构，任何配置变更都要有严格的记录和复核机制，并且要充分测试,否则一个不起眼的小改动就可能埋下隐患。

这次远程支援的经历，再次印证了处理数据库故障的一个道理：不能只看错误代码本身，更要深入理解其背后的机制，ORA-31435只是一个症状，真正的病因可能隐藏在配置、规则或者数据的细节之中，耐心、细致的排查，以及对系统原理的深刻理解，才是解决问题的关键。（来源：对本次故障处理过程的总结和反思）