我让 AI 替我排查 OGG：它跑偏三次，我三次把方向盘掰回来

现在我做有些工作，越来越多地让 AI 来替我干活。以前遇到 OGG 链路挂了，我得自己 ssh 上机器、一条条敲 GGSCI、写脚本逐台核对，费时费力还容易手抖。这次 OGG 集成抽取链路重建，我几乎把这些都交给了 AI——它写脚本、跑命令、批量比对，我基本只动嘴。

省事是真的省事。但过程也说明了一件事：AI 没经验、有误区，关键判断还得靠人。 它连续跑偏三次，都是我把方向拉回来的。写下来，给同样想用 AI 替自己干活的同行参考。

一、AI 上场：它替我扛下了所有重复劳动

这次的环境是一套 OGG 双链路，源库 146.86（ycjg），两台目标库 165.163（rpt）、165.159（bsmc），OGG 服务端在 165.160。三条核心链路 EXCOM2BS→BSMC、EXDDZX→DDZX、EXYSZX→YSZX，各带一个 Replicat。

我把活分给 AI 之后，它一口气干了不少苦力：

• 远程 ssh / su 切换、在 GGSCI 里批量查询 INFO ALL、SHOWCH、DETAIL、STATS；
• 写并上传了二十多个 shell 脚本：诊断、杀进程、重启、物理归档检查、行数比对；
• 在源库 expdp 打一致性快照，再 impdp 覆盖两台目标端，并逐表核对行数基线；
• 结构化 grep ggserr.log，把几次 abend 的时间线捋出来。

这些活它干得比我又快又稳，我不用再一条条敲命令了——这一点是真香。但也正因为把"手"交出去了，后面 AI 一跑偏，我必须在"脑"这一层盯死。

二、AI 的第一次误判：死磕"数据字典"

报错演进到后面是这么一句：

OGG-02870 Missing Log File DICTIONARY INITIALIZATION. Read Position SCN: 12146885619839

AI 一看里面有 "DICTIONARY INITIALIZATION"，立刻进入"字典模式"，开始狂查源库的字典构建点：

SELECT first_change#, sequence#, name
FROM v$archived_log
WHERE dictionary_begin='YES' AND standby_dest='NO';

然后它顺着"最近的字典构建点 SCN 12146830540030（2026-07-29）"这条线，写了一堆脚本去 146.86 上 ls 归档物理文件，想验证这些字典归档是不是被删了。它的推论是：7-29 字典点对应的归档缺失，所以 logmining server 没法初始化。

我直接叫停："这和数据字典没关系，别往那个方向发散。"

事实是它这个方向从一开始就是错的。146.86 上最近的归档序列连续无缺口，那个字典点根本不缺文件。AI 把 "DICTIONARY INITIALIZATION" 这句报错当成了"去找字典归档文件"，被关键词带偏了。真正的病灶根本不是"字典文件在不在"，而是 SCN 的用法。

这一下就看出来了：AI 没经验。 它只会顺着报错的字面去查，而人知道这句报错在集成抽取重建的语境里意味着什么。

三、AI 的第二次误判：SCN 找错（最危险的一次）

这次差点把整个重建带沟里。

AI 重建集成抽取时，SCN 取值彻底搞反。它先这么干：

# 错误尝试
ADD EXTRACT EXCOM2BS, INTEGRATED TRANLOG, SCN 12146885619839
REGISTER EXTRACT EXCOM2BS, DATABASE SCN 12146830540030   # 用了旧字典构建点

结果 OGG-02022 Logmining server does not exist，加了 REGISTER 用旧字典点之后，又是 OGG-02870 abend。它又在"当前源库 SCN"和"快照 SCN"之间反复横跳，一度把当前 SCN（12,146,885,xxx,xxx）当成了 ADD 的 SCN，导出快照 SCN 反倒没用上。

我不得不人工把规则钉死：

ADD EXTRACT ... SCN 用的，是「从上游导出数据之前查到的上游 SCN」——也就是导出快照 SCN 12146885619839，不是当前 SCN；REGISTER 用当前 SCN（那个点的归档一定都在）。这跟数据字典无关，不要再重跑物理检查了。

这句话点破了集成抽取重建的核心心智模型：

• REGISTER 是向源库注册 logmining server、从某个点开始建字典。用当前 SCN 最稳——那个点的日志 100% 还在，绝不会 OGG-02870。
• ADD ... SCN 是告诉 Extract"从哪个 SCN 开始抓增量"。这个值必须等于 expdp 覆盖目标端时用的 FLASHBACK_SCN（12146885619839）。目标端数据已被这个快照点覆盖，Extract 从同一点往后抓，增量严丝合缝，不丢不重。
• 两者不能同值，更不能反。AI 把 REGISTER 用了旧字典点、ADD 用了当前 SCN，方向全错。

这就是 AI 的认知误区：它不理解这两个 SCN 的语义差异，于是把最关键的参数配反了。而这一步，只有知道"为什么"的人才能配对。

四、AI 的第三次误判：漏了 EXTTRAIL 绑定

AI 按 "STOP→DELETE→REGISTER→ADD→START" 重建，START 之后立刻 abend：

OGG-01044 The trail './dirdat/cb' is not assigned to extract 'EXCOM2BS'.
Assign the trail to the extract with: ADD EXTTRAIL ./dirdat/cb, EXTRACT EXCOM2BS

原因是 DELETE EXTRACT 会连带删掉 EXTTRAIL 绑定，AI 不知道这个联动，删完就直接 START。补一句 ADD EXTTRAIL ./dirdat/cb, EXTRACT EXCOM2BS 就活了。DDZX、YSZX 是同样的坑，三个都补齐后才全部 RUNNING。

这不是 AI 笨，是它没有这类"踩过才知道"的经验。人不写这一句也会栽，但人踩过一次就记住了；AI 不会，除非你告诉它。

五、把原理和正确做法钉下来

OGG-02870 的成因，说穿了就一句话：REGISTER ... DATABASE SCN <x> 指定 logmining server 在 SCN x 做字典初始化。x 若取了很旧、归档已不可达的字典点，初始化就找不到日志。REGISTER 不带 SCN（用当前 SCN）就绝不会缺日志；之后 ADD ... SCN 快照 只决定抓取起点，不碰字典初始化。

正确顺序（照抄即可）：

cd /ogg && ./ggsci
DBLOGIN USERID ogg_capture@146.86/ycjg, PASSWORD ***

STOP EXTRACT EXCOM2BS
DELETE EXTRACT EXCOM2BS                              # 注意：会删掉 EXTTRAIL 绑定

REGISTER EXTRACT EXCOM2BS, DATABASE                  # 不带 SCN，用当前 SCN
ADD EXTRACT EXCOM2BS, INTEGRATED TRANLOG, SCN 12146885619839   # 带快照 SCN
ADD EXTTRAIL ./dirdat/cb, EXTRACT EXCOM2BS           # 重建后必补

START EXTRACT EXCOM2BS

trail：cb→EXCOM2BS、dd→EXDDZX、ys→EXYSZX。Replicat 不用动，会自动跟随新 trail 序号续读，切换时 canceled 0 records，没有重复应用。

顺手还收拾了两个僵尸进程：EXPDB2 / EXWMS 在 INFO ALL 里显示 RUNNING，其实是僵死一年多的假活（STOP 报 OGG-15163 超时）。处理走 OS 层：备份 /ogg/dirpcs/*.pce → kill -9 → 删 pce → 等 Manager 回收，最后变 STOPPED。

六、怎么确认真的好了

AI 也好、我盯也好，最后必须实测，不能只看 Lag=0——那只能说明"追平了"，不代表"以后真能同步"。

我让 AI 在三张代表表上做了一轮真实同步测试：源端各取一行，把非业务字段 UPDATE 成标记值 → 等 20 秒 → 目标端查，三张表都出现了标记值；再源端回滚 → 等 15 秒 → 目标端三张表都还原。双向同步通过，测试数据无残留。 这一步做完，才算真正放心。

七、总结：AI 是"手"，专家是"脑"

三次跑偏，列个表最清楚：

用 AI 替自己干活，好处是实打实的：二十多个脚本、批量 ssh、expdp/impdp 全流程、行数基线比对，它全包了，我不用再劳心劳神地敲命令，把我从重复劳动里解放了出来。这才是专家该有的样子——把力气花在判断上，而不是花在敲键盘上。

但它的短板这次也暴露得彻底：遇到"SCN 该取哪个""什么时候该收敛、什么时候该发散"这种需要业务上下文和经验的判断，它会沿着错误关键词一路狂奔。 尤其是 OGG-02870 这种把 "DICTIONARY" 写在脸上的报错，几乎必然把 AI 引到"查字典归档"的死胡同，而真正的答案藏在"REGISTER 和 ADD 的 SCN 语义差异"里——这是原理级的理解，搜不出来，只能靠经验。

最后你不得不说他帮了我很多，但是你让他无人干预也不行。harness工程也有，loop工程也罢，或者Graph工程，按说都融入进去了，但是还是遇到一些问题。当然这些可能归咎于有些输入不明白或者说知识库不全。如果把我纠正他的内容早早融合进去是不是可以？暂时不知道。我想下一次再出现问题的时候，就可以复现了。