ORA-26693报错，规则集删掉了但出错了，远程帮忙修复故障过程

用户那边打电话过来，说是在清理数据库的时候遇到了一个麻烦事，报错代码是ORA-26693，这个错误我有点印象，通常跟Oracle的流复制（Streams Replication）有关，用户说他们之前设置过一个规则集，后来觉得用不上了，就动手把它给删了，结果这一删，非但没清理干净，反而捅了篓子，系统开始不停地报这个26693的错误，像牛皮糖一样甩不掉，影响了正常操作,所以急着找我们远程帮忙处理。

我连上他们的系统后，第一件事就是先看看现场情况，根据Oracle官方文档的说明（来源：Oracle Database Error Messages, 19c版本，ORA-26693），这个错误的大致意思是“应用进程遇到了一个属于已删除规则集的事务”，说白了就是，系统里可能还有一些“尾巴”没清理干净，有些之前根据那个规则集该处理的数据变动（事务）还在排队等着，或者被卡住了，但现在规则集这个“指挥部”没了，它们就找不到方向,开始报错了。

光看错误代码不够，得找到具体的“案发现场”，我让用户帮忙查一下是哪个具体的进程在报错，他们从告警日志里找到了线索，报错信息里提到了一个具体的应用进程的名字，比如叫“APPLY_XXX”这样的,找到这个具体的进程是关键一步。

我得检查一下这个出问题的应用进程当前是什么状态，在SQL*Plus里，我查询了DBA_APPLY视图（来源：Oracle Database Data Replication Guide），看看这个进程是不是还处于运行状态，或者是不是已经因为错误停掉了，果然，它的状态显示是ABORTED（异常中止）,就是因为规则集被删这个事导致的。

处理这种问题，常规思路是先尝试停止这个应用进程，但这里有个坑：因为规则集已经没了，直接用DBMS_APPLY_ADM包里的STOP_APPLY过程去停，很可能会失败，系统会抱怨找不到相关的规则，所以不能硬来，我采取了一个更稳妥的办法：先尝试把这个应用进程给删除掉，用的命令是DBMS_APPLY_ADM.DROP_APPLY(apply_name => '刚才查到的那个进程名')，执行这个命令的目的，就是希望把引发问题的这个“残骸”彻底从系统里清出去。

执行删除命令后，我立刻再去查DBA_APPLY视图，确认一下那个应用进程的记录是不是真的不见了，如果视图里已经找不到它了，那说明清理掉了一部分，事情往往没这么简单，这种由规则集删除引发的问题，有时候会在系统内部留下一些更深层次的“垃圾数据”,比如一些残留的队列消息或者事务上下文。

果然，用户反馈说虽然进程看不到了，但过一阵子类似的错误日志还是偶尔会冒出来，这说明还有隐藏的问题，这时候就需要更深度的清理了，我检查了流复制的相关队列表（比如DBA_STREAMS_MESSAGE_CONSUMERS这类视图，来源：Oracle Database Data Replication Guide），看看有没有那些标记为属于已删除规则集、但又没被成功处理掉的“孤魂野鬼”一样的老消息，如果发现有，可能需要联系有更高权限的DBA，在非常谨慎的情况下，手动清理这些特定的消息，这一步风险很高，因为删错了可能会影响数据一致性，所以必须非常小心,通常要有充分的备份和回滚计划。

在确认主要的应用进程和可能的残留消息都处理掉之后，还有一个重要的步骤：重启相关的数据库组件，一些错误信息会缓存在内存里，我让用户配合，重启了与流复制相关的数据库日志挖掘进程（LogMiner）或者整个流复制后台进程组（通过ALTER SYSTEM命令），这个重启操作相当于给相关模块做了一个“刷新”，能把内存里一些陈旧的、无效的缓存信息清掉,避免它们再引发无关的报错。

重启完成后，我们持续观察了数据库的告警日志和与流复制相关的监控视图很长一段时间（比如半小时以上），确认再也没有新的ORA-26693错误出现，其他所有的数据同步和应用进程也都运行正常了,这才算真正把问题解决了。

我跟用户总结了一下：以后要删除像规则集这样比较核心的配置对象时，最好先确保没有任何活跃的事务或进程还在依赖它，标准的操作步骤应该是：先停掉依赖这个规则集的应用进程，然后再去删除规则集本身，最后再视情况决定是否要删除应用进程，这样按顺序来，就能避免这种“人走了，茶还凉不了”的尴尬局面，防止再次踩到同一个坑里，整个远程支援花了大概一个多小时,主要是排查隐藏问题和观察稳定状态比较费时间。