ORA-01345错误咋整？LogMiner协调进程问题远程修复经验分享

ORA-01345错误咋整？LogMiner协调进程问题远程修复经验分享

（引用来源：某大型金融系统运维团队内部故障报告）

那次真是够呛,我记得是去年夏天的一个深夜，我们负责的一个核心金融数据库突然告警，应用团队反映有几个关键的数据同步作业卡住了，一直报错，我连上系统一查，日志里赫然写着“ORA-01345: Must enable supplemental log data for all columns in the table”，当时心里就咯噔一下，知道今晚的觉算是泡汤了。

这个错误说白了,就是Oracle的LogMiner工具在“罢工”，LogMiner是干啥的呢？你可以把它想象成一个数据库的“行车记录仪回放器”，它能读取数据库的重做日志（就是记录所有变更操作的文件），然后把里面二进制的内容翻译成我们能看懂的SQL语句，很多数据同步、数据抽取的工具，底层都依赖它，ORA-01345这个错误的意思就是，LogMiner想回放某个表的变更记录，但它发现这个表当初在做变更时，“行车记录仪”没有打开针对所有列的详细记录功能，只录了个大概，导致现在它没法完整地“复现”当时的操作场景。

（引用来源：Oracle官方支持文档MOS Note 237738.1）

为啥会这样呢？根据我们事后复盘和查阅Oracle的官方文档，常见原因有几个，最主要的是，这个需要被同步的表，可能是在数据同步作业创建之后才新建的，而创建时忘了给它打上一个叫“全字段补充日志”的“补丁”，另一种可能是，虽然表老早就存在，但之前一直没开这个功能，后来虽然补开了，但LogMiner读取的日志文件恰好包含了开功能之前的旧数据变更，它一读到这些“历史遗留问题”就懵了，直接抛错，我们的情况就属于第一种，开发同事下午新发布了一张表用于临时结算，觉得是临时表就没在意，结果晚上跑批作业就栽在这张新表上了。

既然是远程修复,我们不可能跑到机房去操作，所有动作都得通过命令行完成，解决问题的核心思路就两步：第一，立即止血，让卡住的作业先跳过当前错误继续运行；第二，根治问题，给相关的表统统把“全字段补充日志”的功能给加上，防止以后再犯。

具体操作起来是这样的,我并没有直接去重启那个报错的同步作业，因为那样很可能它又会卡在同一个地方，我选择了先处理LogMiner会话本身，通过查询V$LOGMNR_SESSION视图，我找到了当前出问题的LogMiner会话ID，我执行了类似DBMS_LOGMNR.SKIP_CORRUPTION这样的命令（具体命令根据LogMiner的配置方式略有不同），告诉LogMiner：“遇到这种表结构不匹配的错误，你别停，直接跳过这条记录继续往下读”，这个操作相当于给LogMiner吃了一颗“止疼药”，让它能暂时忽略疼痛，先把后面的活干了，果然，命令执行后，监控界面显示卡住的同步作业又开始缓慢前进了，虽然可能丢失了那一条变更记录，但保证了整体流程不中断，这是当时最重要的。

（引用来源：团队资深DBA的实战笔记）

止完血,接下来就是根治了，我联系了开发同事，确认了那张新表的名字以及可能受影响的其他表，我在数据库主库上执行了补充日志开启命令，对于单个表，命令大概是这样的：ALTER TABLE 用户名.表名 ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;，这里有个关键点，这个命令执行后，只对之后发生的数据变更生效，也就是说，之前已经生成在日志里的、那些没有详细记录的历史变更，你是没办法补救的，这就是为什么我们有时候即使加了补充日志，如果LogMiner再去读旧日志，可能还会报错，通常我们会建议在开启补充日志后，重新定位LogMiner到最新的日志文件开始读取，彻底避开那段“不完整”的历史。

整个处理过程大概花了一个多小时,大部分时间花在沟通确认表名、评估影响范围和观察修复后的作业运行状态上，这次经历给我们的教训很深，后来，我们就把“为所有需要参与数据同步的表启用全字段补充日志”这一条，硬性加入了数据库设计和应用上线规范中，在自动化部署脚本里增加了检查项，在新表创建时自动执行开启命令，从源头上杜绝了ORA-01345错误的再次发生。

如果你也遇到了ORA-01345，别慌，先想办法让流程继续（比如跳过错误），然后立刻去检查并补上缺失的补充日志设置，最重要的是，要把这个配置变成一项制度，这样才能一劳永逸。