- 博客(62)
- 收藏
- 关注
RSS订阅原创 LogMiner vs 裸日志解析（三十四）：日志里没有时间戳，审计要的“几点几分”从哪来
审计来要一句话："这笔改动是几点发生的？翻日志的人往往会愣一下。因为日志里没有这一项。
2026-11-10 08:33:12
130
原创 LogMiner vs 裸日志解析（三十三）：带 CLOB 的那条记录，日志里为什么找不到那串文字
本文揭示LogMiner解析CLOB字段时“文字消失”的真相：大字段数据不存于表行，而位于独立的LOB段，日志中仅记录定位器与块变更。解析需跨段追踪、按chunk拼接，且受BasicFile/SecureFile存储差异影响。关键在于判断下游是否真需完整值——若仅需变更通知，可跳过复杂处理。组件设计应支持按需开启LOB解析，避免无谓开销。核心提醒：日志是物理变更流水，非自描述文档，大字段解析依赖字典与规则，细节决定成败。
2026-11-09 10:01:20
206
原创 LogMiner vs 裸日志解析（三十二）：一次 INSERT，日志里为什么冒出一堆“不是这张表”的变更
一次INSERT在redo日志中会触发多个数据块变更，包括表、索引、undo及段头块等。由于LogMiner基于块级日志解析，而日志本身不记录“表”概念，仅通过对象号（obj#/dataobj#）关联逻辑表。若字典版本与日志SCN不匹配，或对象号因分区操作发生变更，会导致过滤失效，出现“不是这张表”的误判。静默漏判风险高，需自主维护字典快照与对象号映射，实现按事务合并、副作用块识别，才能准确还原逻辑变更。
2026-11-06 09:15:33
338
原创 LogMiner vs 裸日志解析（二十八）：日志里那个 DBA，到底指向磁盘上的哪个字节？
系列第 28 篇。上一篇讲了操作码——记录在说什么。这一篇讲地址——它改的那块数据，到底在磁盘的什么位置。
2026-11-05 08:36:40
60
原创 LogMiner vs 裸日志解析（三十）：一个 NUMBER 在 redo 里到底是怎么存的
不是数据库当前的 NLS 设置。道理很直白：这条变更可能是三年前写进 redo 的，当时的库是 ZHS16GBK，现在的库是 AL32UTF8；今天连上去查。
2026-11-04 09:04:23
135
原创 LogMiner vs 裸日志解析（二十九）：归档日志和在线日志，解析难度差了一个数量级
系列第 29 篇。前两篇拆了记录结构、讲了地址定位。这一篇讲"你要读的那个文件本身"——它现在是死的，还是活的。
2026-11-03 08:50:02
146
原创 LogMiner vs 裸日志解析（二十八）：日志里那个 DBA，到底指向磁盘上的哪个字节？
系列第 28 篇。上一篇讲了操作码——记录在说什么。这一篇讲地址——它改的那块数据，到底在磁盘的什么位置。
2026-11-02 11:08:06
199
原创 LogMiner vs 裸日志解析（二十八）：日志里那个 DBA，到底指向磁盘上的哪个字节？
系列第 28 篇。上一篇讲了操作码——记录在说什么。这一篇讲地址——它改的那块数据，到底在磁盘的什么位置。
2026-11-02 11:04:29
103
原创 LogMiner vs 裸日志解析（二十七）：redo 里的操作码，150 多种你其实只用得上 10 个
系列第 27 篇。前面二十六篇都在讲"用起来哪里疼"。从这篇开始换个角度——把日志文件拆开，看里面到底写了什么。第一站不是数据，是每条记录开头的那个字节：操作码。
2026-10-30 10:57:20
7
原创 LogMiner vs 裸日志解析（二十六）：只想采个 Oracle 日志，却要先搭一套分布式集群？
系列第 26 篇，也是这条主线问题清单的最后一篇。前面聊了"准不稳""稳不稳""贵不贵"，这一篇聊最基础的：你为了采一个库，到底要先养多少东西。
2026-10-29 10:28:53
46
原创 LogMiner vs 裸日志解析（二十五）：采个数据，凭什么占我数据库的会话？
本文揭示日志解析中“采数据却占数据库会话”的痛点：传统LogMiner依赖库内解析，每任务占用会话资源，多任务并发加剧争抢，易触发ORA-00018/ORA-00020错误。核心矛盾在于解析与业务争抢有限会话额度，扩容需重启、难横向扩展。解决方案是将解析移至旁路（如自研TLA组件），实现零会话占用、无资源竞争，真正支持多任务并行，从根本上解决“解析抢饭吃”问题。
2026-10-28 08:42:03
159
原创 LogMiner vs 裸日志解析（二十四）：拿今天的字典去翻昨天的日志，能不错位吗？
系列第 24 篇。上一篇聊"历史日志留不住"，这一篇聊一个更阴的：日志还在，字典却已经不是当时那一本了。
2026-10-27 10:31:32
137
原创 LogMiner vs 裸日志解析（二十三）：半年前改过的那笔数据，现在还能查回来吗？
半年前的数据变更还能查吗？看似简单的需求，实则常因归档策略短（通常7-30天）、备份覆盖快而无解。LogMiner依赖数据库承认的日志，一旦归档被清理或库下线，历史即永久消失。真实场景中，审计、对账、补数等需求频发，却常因“日志留不住”被迫依赖业务记录反推，结果“原因不明”。关键在于：日志应脱离数据库生命周期管理。裸日志解析技术将日志视为独立文件，可长期存于对象存储，任意时点重解析，真正实现“历史由你决定留多久”。
2026-10-26 10:35:29
215
原创 LogMiner vs 裸日志解析（二十二）：redo 坏了、备份也没有，数据还能捞回来吗？
系列第 22 篇。前面聊了"改不了""等排期""赌运气"，这一篇聊一个谁都不愿意碰、但碰上了就得面对的场面：源库真的出事了你怎么办。
2026-10-23 11:10:13
301
原创 LogMiner vs 裸日志解析（二十一）：数据库一升级，同步链路就开始“赌运气“
系列第 21 篇。前面聊了"改不了""等排期"，这一篇聊一个更像"定时炸弹"的问题：源库一升级，链路就可能被动出问题。
2026-10-22 09:20:37
196
原创 LogMiner vs 裸日志解析（二十）：你的需求，排在别人的 Roadmap 后面
"这个功能，社区说'以后可能会加'。""以后"是多久？没人知道。你只知道，你的业务等不起。一个团队的需求其实很具体：只解析指定 PDB 里的某几张表，再把变更输出成他们内部系统要的一种 JSON 格式。听起来不复杂。但用开源 CDC 方案一对：于是他们提了个 Feature Request。社区的回复很客气："欢迎贡献，优先级我们会评估。"翻译过来就是：先排队。这不是社区不友好，是开源的天然逻辑：翻一翻真实项目，这类需求几乎家家都有：换个前提，如果解析引擎是你自己的："通用"听起来是优点——功能多、适配广。
2026-10-20 09:04:57
212
原创 LogMiner vs 裸日志解析（十九）：明知道问题在哪，却改不了
系列第 19 篇。上一篇从合规角度聊了"控制权归谁"，这一篇聊一个更日常、也更磨人的痛点：出了问题，你修不了。
2026-10-19 09:02:37
163
原创 LogMiner vs 裸日志解析（十八）：你依赖的，其实是别人手里的一段闭源内核
系列第 18 篇。前面几篇一直在讲技术上的"为什么不行"。这一篇换个视角——从合规与自主可控的角度，看看这条链路真正握在谁手里。
2026-10-16 09:44:17
188
原创 LogMiner vs 裸日志解析（十七）：老系统里那张没主键的表，为什么采不动？
系列第 17 篇。前一篇聊了采集反噬生产库，这一篇聊个更"死角"的问题：那些结构不规整的老表，到底怎么采。
2026-10-15 08:54:07
290
原创 LogMiner vs 裸日志解析（十六）：采集任务，为什么会把生产库拖出 ORA-04036？
系列第 16 篇。前一篇聊了 schema 一变就出问题，这一篇退回到更"伤身"的一层：采集这件事，为什么会反噬生产库。
2026-10-14 14:30:00
270
原创 LogMiner vs 裸日志解析（十五）：给表中间加一列，为什么能把同步链路搞挂？
系列第 15 篇。前一篇聊了"接入前要先改生产库的配置"，这一篇聊一件更日常的事：schema 一变，链路就可能出问题。
2026-10-13 09:28:21
239
原创 LogMiner vs 裸日志解析（十四）：为了采数据，为什么要先“动“生产库的配置？
系列第 14 篇。前一篇聊了"从备库采"为什么走不通，这一篇聊一个更靠前的问题：代码还没写，数据库就得先改。
2026-10-10 09:48:38
311
原创 LogMiner vs 裸日志解析（十三）：想从备库采数，LogMiner 为什么非要你“动“容灾？
等你采集完、再转回物理备库，这段时间备库上的所有本地变更会被丢弃，这段窗口里主库发生了故障，你的备库是"落后"的。所以当有人说"能不能从备库采"的时候，答案不是"技术上做不到"，而是：用 LogMiner 做不到；基于 LogMiner 的 Oracle CDC，架构上就是为"可写的主库"设计的，不是只读备库。从它身上采数据，理论上是对生产库"零打扰"的。想法非常合理：主库在跑生产，备库闲着，从备库采数据，既不影响业务，又安全。Data Guard 的备库，是主库的一份实时副本，数据是一致的；
2026-10-10 09:45:17
93
原创 ogMiner vs 裸日志解析（十二）：上了全闪 ASM，日志解析为什么还是快不起来？
你把盘换成了顶配，但你读盘的那条线，还是十年前的姿势。ASM 是被设计来"同时伺候很多请求"的；LogMiner 只会一个个来。这不是调优能解决的问题，是"用几条线读"的架构问题。往期回顾（七）大事务把内存撑爆：OOM 是怎么来的（八）长事务与回滚，一致性埋雷（九）SCN 越跑越快，LogMiner 越追越远（十）RAC 下的日志切换，为什么容易"漏一段"（十一）只想采一个 PDB，却要牵连整个 CDB（十二）存储堆到顶配，为什么还是慢 ← 本篇。
2026-10-10 09:42:32
280
原创 LogMiner vs 裸日志解析（十）：RAC 下的日志切换，LogMiner 为什么容易“漏一段“？
本文为「LogMinervs裸日志解析」系列第10篇，揭示RAC环境下LogMiner的“放大器”陷阱：因多实例、多日志线程与日志切换，易出现静默丢数据。核心问题在于需手动显式添加所有thread归档日志，任一遗漏即导致SCN断层，引发ORA-01291/ORA-00308或无报错丢失变更。相较之下，裸日志解析直读二进制日志，无需点名、原生支持RAC多线程拼序、抗切换，从根本上规避配置疏漏风险，是RAC场景下更稳定的数据捕获方案。
2026-10-08 09:54:05
345
原创 LogMiner vs 裸日志解析（八）：长事务与回滚，数据一致性埋雷
前面聊了性能、内存、数据类型这些“看得见”的问题。今天聊一个更隐蔽、但后果更严重的坑——这个问题隐蔽在哪？它不报错，不崩溃，任务看起来跑得好好的。但下游拿到的数据，可能有一小部分是“不该存在”的。等发现的时候，数据已经错了。
2026-09-30 08:49:46
297
原创 LogMiner vs 裸日志解析（七）：大事务直接把内存撑爆
大事务易引发内存溢出（OOM），根源在于LogMiner与Debezium需在内存中缓存完整事务直至提交，导致内存随事务规模线性增长，最终崩溃。即使增加堆内存也仅延缓问题，无法根治。相比之下，流式裸日志解析（如TLA）通过边读边处理、仅维护事务状态而非全量数据，实现内存占用稳定，彻底规避此坑。根本矛盾在于“原子性”要求与内存限制的冲突，唯有机制革新才能破解。
2026-09-29 07:51:41
310
原创 LogMiner vs 裸日志解析（六）：想提速，只能“堆实例”，结果把源库拖垮
前面聊了单线程限制——LogMiner解析速度上限就在1万到1.5万条/秒，日志量越大性能越差。那怎么办？总不能业务等着你慢慢解析吧。一个库开好几套采集实例，一个实例采一批表，每个实例独立解析自己负责的那部分日志。听起来很合理对吧？横向扩展嘛。但实际效果往往跟预期完全相反。
2026-09-28 09:12:30
269
原创 LogMiner vs 裸日志解析（五）：性能被卡在“单线程”上
聊了表名限制、数据类型、前镜像后镜像、物理日志和逻辑日志的区别。这些是“能不能用”的问题。今天聊一个更现实的问题——
2026-09-24 11:53:41
186
原创 为什么说redo log是“物理日志”？跟binlog的“逻辑日志”差在哪
数据块的结构、事务的管理、回滚段的机制，都是Oracle自己控制的。Oracle的redo log是物理日志，解析难度高，所以大部分方案选择套壳LogMiner——省事，但受制于LogMiner的所有限制。块怎么变的，就怎么改回去。redo log是物理日志，binlog是逻辑日志——这个分类听起来只是个学术概念，但它直接决定了两者的解析难度和CDC方案的复杂度。这就像一个记账员，记录的是“张三的工资从5000改成了8000”，而不是“账本第37页第5行的数字从5000改成了8000”。
2026-09-21 09:47:55
206
原创 LogMiner vs 裸日志解析（三）：Oracle日志解析中的“前镜像”和“后镜像”，到底怎么用？
和。第一次听到这两个词的时候，很多人会以为是什么高深的概念。但问题在于——这篇文章把这件事聊透。
2026-09-20 08:27:35
213
原创 【无标题】一个COMMIT在redo里长什么样？你可能猜错了
在高并发场景下，Oracle可能先把COMMIT标记写进redo，然后再写其他Change Vector。或者反过来，先写其他Change Vector，最后写COMMIT标记。
2026-09-20 08:21:21
159
原创 LogMiner vs 裸日志解析（二）：明明是很常见的数据类型，却抓不到
UDT底层有对应的类型定义，redo里记录的是按照UDT结构编码的二进制数据。解析器需要先解析UDT的类型定义，然后按定义逐字段解码。
2026-09-16 10:07:25
156
原创 从redo log到数据变更：中间隔了多少层转换？
从Oracle redo log到数据变更，需经历五层转换：物理块→Redo Record（在线日志读写冲突）、Redo Record→Change Vector（格式闭源、版本差异）、碎片→完整事务（大事务内存管理）、体→数据变更（类型多样、依赖字典）、变更→输出格式（顺序、重复、过滤）。每层均存风险，套壳方案仅覆盖部分，受限于LogMiner（如30字符限制、不支持复杂类型、大事务OOM）。自研链路全掌控，可突破限制，保障高并发、复杂场景下数据一致性与稳定性。
2026-09-14 10:02:20
166
原创 SCN、RBA、XID：读懂这三个缩写，就读懂了Oracle日志
第一次接触的时候，很多人会搞混。它们都跟“位置”有关，但“位置”的含义完全不同。把这三个东西搞清楚了，redo log的解析逻辑基本就通了一大半。
2026-09-11 10:04:50
166
原创 Change Vector不是向量，是Oracle日志的最小拼图
在Oracle的术语体系里，“Vector”这个词的意思是“载体”或“承载单元”——它承载的是一次变更的描述信息。你可以把它理解为一个“变更信封”，里面装的是“改哪个块、改成了什么样”。
2026-09-10 09:03:15
190
原创 redo log里到底藏了多少秘密？一个DBA的逆向工程笔记
聊到Oracle的redo log，很多DBA都能说出个大概——记录数据变更、用于恢复、归档日志……但再往下问，能答上来的人就不多了。redo log文件在磁盘上到底是怎么存的？一个UPDATE语句会产生什么样的二进制记录？事务开始和提交在日志里怎么体现？这些年做数据库日志解析，对着二进制数据看了不知道多少遍。把一些笔记整理出来，跟同行分享一下。
2026-09-07 11:01:08
169
原创 TLA之后：数据库日志解析组件应该往哪个方向演进？
聊数据库日志解析组件的未来，先看一个变化。2026年，CDC（Change Data Capture）正在经历一个根本性的身份转变——。前几年聊CDC，大家还在讨论“要不要用”。2026年聊CDC，问题已经变成了“不用的话，架构还怎么支撑业务”。这个转变背后，是整个数据集成行业的结构性重构。传统ETL的定时全量扫描模式有三个硬伤：延迟高、资源消耗大、难以扩展。
2026-09-04 08:20:05
199
原创 MySQL、PG、国产数据库的日志解析，和Oracle有什么不同？
聊到数据库日志解析，很多人第一反应就是Oracle那套复杂的redo log体系。但如果你同时要处理MySQL、PostgreSQL或者国产数据库，会发现每个库的日志机制完全是另一套逻辑。这篇文章不聊虚的，直接从底层对比一下不同数据库的日志解析到底差在哪。
2026-09-02 13:09:29
240
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人