前九篇，我们聊了表名长度、数据类型、前镜像后镜像、物理日志和逻辑日志、单线程、堆实例、大事务 OOM、长事务回滚、SCN 追不上。

今天的第十个坑，我更愿意叫它"

原因很简单：它依赖的东西——

多实例、多日志线程、日志切换

——在单机上基本不存在。所以单机跑得挺稳的方案，一上 RAC，问题就集中冒出来了。

一个跑了 4 节点 RAC 的核心库，用 Flink CDC 往数据平台抽数。前几个月一切正常。

某天开始，任务反复报错。报错信息长这样：

io.debezium.DebeziumException: Online REDO LOG files or archive log files 
do not contain the offset scn 17220098076542. Please perform a new snapshot.


排查了两天。一开始怀疑网络、怀疑连接池、怀疑是数据库版本升级导致的。最后定位到：

某个实例的归档日志，没有被采集端加进解析列表里。

不是配置写错了那么简单——是"要加的文件"这件事本身，在 RAC 下就变成了一个极其容易出错的动作。

二、先搞懂一件事：RAC 的日志是"多份"的

。4 节点 RAC，就是 4 条线程在同时往日志里写。

这里有两个关键点，值得单独拎出来说：

第一，SCN 全局递增，但日志是交错的。

每条线程里的日志，是一条"局部时间线"。thread 1 里可能记录着"逻辑上晚于" thread 2 里某个事务的变更——SCN 看着像交错的，但逻辑先后关系并不按 thread 排列。

第二，要拼出全局顺序，必须拿到所有线程的日志。

这一点 Debezium 官方在 2025 年 7 月的一篇博客里说得很直白：

只采到一部分线程的日志，你拿到的就是"一半的真相"，而且是错乱的。

指定的时间 / SCN 范围内，不是所有的日志文件都被加进了列表。

三、坑一：LogMiner 必须"显式点名"

这是 LogMiner 设计上的一个硬性前提——

你得一个一个地把日志文件"喂"给它：

BEGIN
  DBMS_LOGMNR.ADD_LOGFILE('/arch/thread1/1_1234_987654321.arc', DBMS_LOGMNR.ADDFILE);
  DBMS_LOGMNR.ADD_LOGFILE('/arch/thread2/2_1187_987654321.arc', DBMS_LOGMNR.ADDFILE);
  ...
END;
/


的序列。漏一个文件，就丢一段数据——而且这个动作，是工具替你去加的，你未必知道它加全了没有。

四、坑二：日志切换时，上下文容易"掉线"

redo log 是循环写的：一个日志组写满了，就切换到下一个组——这就是 

在 Flink CDC / Debezium 这条链路上，

Debezium 从 2.7 开始，专门加了一道 

Redo Thread Consistency（重做线程一致性检查）

 来兜这个底。触发时会报这样的错：

Redo Thread 1 is inconsistent; an archive log with sequence 12345 is not available


每条 thread 的归档序号必须连续、不能有洞。

如果机制本身是可靠的，为什么还需要专门加一道一致性校验？

答案就在校验本身：因为它确实容易出洞。

五、坑三：加进去的日志，解析时可能已经"没了"

这是最阴的一个，也是最容易被忽略的。

而归档日志，是会被备份 / 清理策略定期删除的。

ADD 的时候文件还在，真正查询的时候已经被清了。

ORA-00308: cannot open archive log '/path/to/archive/log/...'
ORA-27037: unable to obtain file status


社区里有同行实测过这个场景：日志量大的时候，第 2 步加进去的归档日志，在第 5 步查询时已经过期被删了——中间那几十秒到几分钟的时间差，就是"事故窗口"。

有人会问：那把归档保留期设长一点不就行了？

，治标不治本。日志长得越快，你要留的越多；留得越多，成本越高。问题并没有消失。

把上面三条叠加起来，就是 RAC 场景下最难受的几个点：

直接读二进制日志这条路，天然少了"点名"这个动作。

第一，不用 ADD 列表，直接读文件。

 那套接口，而是直接把磁盘 / ASM 上的日志文件当数据读。没有"列表"，也就没有"漏加一个"。

可以读取多个实例的日志，通过每个实例的日志和 SCN 来保证交易顺序的准确性——多线程的日志，由解析引擎自己拼。

RAC 环境大量使用 ASM，直读 ASM 是基本功。

第四，多线程处理，与日志切换无强耦合。

在线日志、归档日志都能读，不需要"等切换、等归档完、再加进来"。日志在切换，解析照样在推。

我们团队在做 TLA 的时候，RAC 支持就是按这个思路实现的。目前 Oracle 版本已经跑通了，后续 MySQL、PG 和国产数据库的支持也在推进中。

一提"RAC 下丢数据"，很多人第一反应是——网络问题、脑裂、实例间通信异常。

更常见的根因是"归档日志没配全"这种配置层面的静默失败。

它不产生告警，不产生监控曲线上的抖动，只产生一个安静的后果：

而这恰恰是 RAC 带来的"附加复杂度"——单实例时你只有一条线程要管，RAC 下是 N 条。N 越大，出错的概率越大。

RAC 下日志切换导致的丢数据，本质上不是"LogMiner 不够强"，而是

它的工作方式决定了它需要一个你很难保证完整的输入

需要你显式列出所有日志文件、需要你覆盖所有实例所有线程、需要在切换时刻接住上下文——这三件事，随便哪一件出点差错，结果都是"丢一段"。

裸日志解析的不同，不在于"更快"，而在于

它把这个最脆弱的环节从链路上拿掉了

：不点名、不等归档、不依赖你手工把文件列全。

这是「LogMiner vs 裸日志解析」系列的第十篇。后面继续聊剩下的坑——多租户 PDB、ASM 存储、备库读取、DDL 演进……

LogMiner vs 裸日志解析（十）：RAC 下的日志切换，LogMiner 为什么容易"漏一段"？

数据库

后端

运维

RAC环境下LogMiner解析日志易漏数据，因需显式添加所有实例的redo线程日志，切换时上下文易丢失，归档可能被清理，导致ORA-01291或静默丢段。裸日志解析直读磁盘文件，免去手动添加、原生支持多实例，规避此坑，确保数据完整性。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

LogMiner vs 裸日志解析（十）：RAC 下的日志切换，LogMiner 为什么容易"漏一段"？

LogMiner vs 裸日志解析（十）：RAC 下的日志切换，LogMiner 为什么容易"漏一段"？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐