OGG 同步奇案：医疗数据 “消失” 之谜
惊魂时刻：病房数据的诡异断层
“救命！B 应用的新增病例数据又丢了！” 凌晨两点，医疗客户的数据库管理员在电话里带着哭腔。我们为这家三甲医院部署的 Oracle OGG 同步系统，正上演着离奇一幕：A 应用录入的门诊数据能实时同步到备库，可 B 应用的住院登记数据，却像被无形黑洞吞噬，同一张表的insert操作，A应用的可以被同步，B应用则不行，备端始终空空如也。
主责工程师已经熬了一个通宵。他调出 OGG 挖掘进程的 logdump 日志，一行行排查 trail 文件，结果令人毛骨悚然 —— 那些消失的 insert 语句，根本没被 ext 进程捕获。更诡异的是，用 logmnr 解析归档日志时，这些 “幽灵数据” 却清晰地躺在那里，仿佛在嘲笑我们的无能。
初查线索：缺失的 trandata
清晨的阳光透过百叶窗，在白板上投下斑驳的光影。团队围着故障时序图梳理线索：源库有记录（logmnr 可见），ext 进程未捕获，这指向一个经典嫌疑问题 —— 表级 trandata 配置。
“对，trandata！” 主责工程师猛地拍桌，调出上周的检查记录。截图显示，故障表的 trandata 状态果然是 “未配置”。OGG 要捕获 DML，必须依赖这个元数据标记，就像给数据装了追踪器。
当晚，工程师紧急执行add trandata命令，看着配置成功的提示，大家都以为这起 “失踪案” 就此告破。
迷雾再起：补药失效的怪象
第二天一早，坏消息接踵而至：B 应用的新数据依旧 “查无此人”。
“不可能！” 我盯着监控大屏，A 应用的同步曲线平稳上扬，B 应用的曲线却像被拦腰斩断。相同的表，相似的insert 语句，为何命运迥异？
我们决定启动 “复刻实验”：在备端新建 rep_test 进程，只同步故障表到新表 TMP_PATIENT；将同步起点锁定在故障时段的 trail 文件（130130-130135）。
alter replicat rep_test, extseqno 130130
start rep_test
启动进程后，所有人都屏住呼吸盯着新表 —— B应用的数据依旧空空如也。
ext 进程到底发生了什么？
惊天反转：重建的 ext 进程
“难道是 OGG 出 bug 了？” 实习生小声嘀咕，没人反驳。我咬咬牙，决定放大招：重建 ext 进程。
新进程 ext_test 只保留故障表的挖掘配置，起始时间设为 2025-08-04 05:00—— 正是 B 应用开始批量录入数据的时刻。
alter extract ext_test tranlog begin 2025-08-04 05:00:00
备端目标表 truncate 干净，rep_test 重新衔接...
结果像一盆冰水浇透全身：目标表还是没有 B 应用的数据。
会议室陷入死寂。归档日志明明有记录，ext 进程却视而不见，这违背了 OGG 的工作原理。我死死盯着 ext_test 的参数文件，逐行默念，突然，一行配置像闪电劈中我的神经：
tranlogoptions excludeuser admin
“B 应用用什么账号连接数据库？” 我猛地抬头问客户。
“admin... 因为老系统兼容问题，一直没换...” 主责工程师的声音越来越小。
真相大白：被拦截的 “特殊访客”
原来如此！上周补加 trandata 后，ext 进程确实开始工作，但excludeuser admin这条配置，像个尽职的门卫，把admin 用户的所有操作拦在了门外。A 应用用的是 appuser 账号，自然畅通无阻。
最后一轮测试，我们注释掉那条配置，重置 ext_test 的起始时间。当 B 应用的测试数据一行行出现在目标表时，工程师们不约而同地长出一口气。
结案启示
这起持续三天的 “数据失踪案”，最终定格为一个血淋淋的教训：
技术排查就像侦探破案，最致命的线索往往藏在最显眼的地方。OGG 的参数文件里，每个配置都可能是问题的关键，而我们却常常忽略它。在医疗数据这类容不得半点差池的场景里，对配置文件的敬畏心，就是对生命的敬畏心。
