现在我排查问题，越来越多交给 AI 跑，形成了极大依赖。最近测试环境有人报这台 175.186 的库  /arch 撑到 95%，我本来得自己 ssh 上去、一条条查视图、算缺口、写删除脚本。这次我把活全丢给 AI 了——它写诊断脚本、跑命令、读视图、算文件缺口，我基本只动嘴。

省事是真的省事。但过程又一次证明：**AI 没经验、有误区，关键判断还得人拍板。**不过也同时说明以后我还是会这样去做的。

一、AI 上场：它替我把脏活全干了

环境是 175.186（源库 STG19C，一个 19c CDB，挂着十几个 PDB），归档目录  /arch。我贴了一段 RMAN 现场： crosscheck archivelog all 只校验出 15005~15023 共 19 个归档，想删老归档又被  RMAN-08137: needed for standby or upstream capture process 拦住；而  ls /arch 看到的文件是 3 月份的 14184~14190 和 9 月份的 15005 往后，中间断了 813 个。

我让 AI 上机诊断。它一口气干了这些：

• 写了 4 个诊断脚本，逐个 scp 上去执行；
• 查  v$database、 v$archive_dest_status、 v$managed_standby、 dba_capture、 dba_registered_archived_log、 v$archived_log、 v$session；
• 在 OS 层  ls /arch 统计文件数、算序列缺口、看 crontab 找清理脚本；
• 把"假缺口"和"真孤儿"区分开，把 OGG 所在机器定位出来（这里其实不是他知道有OGG，是因为我知道有OGG。我们自己做的我们知道）。

这些重复劳动它干得又快又稳， 我不用再一条条敲命令。但一涉及"该怎么判断、能动哪块"，它就开始露怯了。

二、AI 的第一次跑偏：把 RMAN-08137 的 “standby” 当真

现场最唬人的一句是： RMAN-08137: needed for standby or upstream capture process。字面上写着 “standby”，再加上归档之间"断了一大段"，第一反应很容易是—— “有 Data Guard 从库，而且从库落后了 / GAP 了，得修 DG。”

AI 也顺着这条线查了  log_archive_dest_2、 fal_server/fal_client、 v$archive_gap。但我让它去 核实到底有没有从库，结果一查就翻案：

-- log_archive_dest_2 是空的，fal_server/fal_client/log_archive_config 全空-- v$managed_standby 里只有 ARCH(CLOSING) 和 DGRD，没有 MRP、没有 RFS-- 根本没有挂载的备库

那 08137 里的 “standby” 是 误读——真正的拦路虎是  OGG 集成捕获进程。我在 186 上查  v$session，一堆捕获会话的来源清清楚楚：

MACHINE   = stg-ogg-175187
PROGRAM   = extract@stg-ogg-175187 (TNS V1-V3)
USERNAME  = C##OGG

OGG 服务端根本不在这台库，而在  175.187。10 个  OGG$CAP_EX* 捕获进程，以  C##OGG 连过来，在  dba_registered_archived_log 里注册了  43649 条记录——这才是 RMAN 不敢删归档的原因。

这一步如果没人把关，AI 会一路去"排查 Data Guard 缺口"，越查越偏。 专家的价值就在这：先确认"到底有没有从库"，而不是被报错字面带着走。

三、AI 的第二次跑偏：想用 RMAN 一把清，险些误删在用日志

确诊是归档堆积后，最朴素的想法是： “那不就 RMAN 删归档嘛，DELETE ARCHIVELOG ALL 一把清。”

AI 的第一版方案也往这靠。但我让它先把"能删 / 不能删"算清楚，一对就发现这条路走不通，而且有雷：

第一，孤儿文件 RMAN 根本删不掉。  control_file_record_keep_time=7，控制文件里归档记录的保留期只有 7 天，是循环复用的——老记录早被顶掉了。所以  /arch 里 13310~14190 那 601 个文件，在控制文件里已经是  deleted=YES / status=D， Oracle 已经"忘记"它们，RMAN 看不见，自然删不掉。

第二，在用日志删了会出大事。 15005~15023 这 19 个，是 OGG 捕获还注册占用的（08137 保护）， DELETE 删不动。但更要命的是—— 绝不能  DELETE FORCE 强删。强删会让还在注册的 OGG 捕获报  ORA-01292 找不到 logminer 文件 而 abend。这正是我们 9-15 在 146.86 上踩过的同一个坑。

所以正确的做法不是 RMAN，是  OS 层  rm 只删孤儿：

# 先干跑，列出待删清单并校验不碰在用日志ls -1 /arch/1_*.dbf | awk -F_ '$2+0<=14190' > /tmp/del_arch_list.txt# 校验：清单里混入 15005+ 的数量必须为 0awk -F_ '$2+0>=15005' /tmp/del_arch_list.txt | wc -l   # =0# 确认无误后再删（仅删除控制文件已忘的孤儿）xargs -a /tmp/del_arch_list.txt rm -f

我让 AI 严格按"先 dry-run 校验、再执行"走，删前确认清单混入 15005+ 的数量 =  0。结果：

alter system switch logfile 验证归档生成正常，OGG 在用的那批一个没碰。 这步如果交给 AI 自由发挥，一句  RMAN DELETE ARCHIVELOG ALL 要么删不掉孤儿（白忙），要么撞 08137，最糟还会 FORCE 删用在用日志触发 ORA-01292。

四、AI 的第三次跑偏：没看穿 keep_time 的死结

删完腾出空间，我问了一句： “这是因为没有定期删除归档的机制，而控制文件只保存了近期，只能控制近期导致的对吧？”

AI 第一反应差点顺着答"对，就是没机制"。但再一查 crontab，发现 机制是有的：

0 2 * * * /arch/clean_archivelog.sh

脚本里写的是  DELETE NOPROMPT FORCE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7'。

那问题出在哪？其实我把根因看穿了，AI 只是确认并修复：

保留策略（7 天）恰好等于控制文件可见期（7 天），中间没有缓冲。 文件满 7 天该删，可一旦删除动作稍晚一点，控制文件里的记录已经被顶掉、Oracle 忘了它，RMAN 永远看不见 → 文件永 久脱管，堆在盘上变孤儿。

治法很直接：把  control_file_record_keep_time 从 7 提到 30，让"账本记得久一点"，给删除动作留出缓冲。

alter system set control_file_record_keep_time=30 scope=both;-- 回滚：alter system set control_file_record_keep_time=7 scope=both;

改完  memory 和  spfile 都是 30。现在  keep_time=30 > 保留期 7天，7 天前该删的归档在 30 天窗口内控制文件里仍有记录，RMAN 看得见、能删得动了——原来的死结解了一大半。

这里 AI 的误区在于"看现象下结论"：看到孤儿堆积就说"没机制"。专家看的是机制为什么失效，是"保留期=可见期、无缓冲"这个结构性死结。 这两句话差着一层原理。

五、175.187 我没让 AI 碰

整个过程中，我在 187 上自己确认了"确实有 OGG"，然后明确说： “175.187 情况不清楚，先不要动。”

这正是专家和风险意识的体现。187 是 OGG 服务端，跑着 10 个捕获、连着一堆 PDB 的下游。它和 186 的归档纠缠在一起（08137 的根因有一部分就在 187 的测试捕获）。在没摸清 187 上 Extract/Replicat 状态之前，任何"顺手清理"都可能把同步链路搞挂。

所以这次我只动了 186 的  /arch 孤儿文件 + 参数， 187 一直没碰。

六、还留着的那块（等下再做）

现在  /arch 安全了（61%），但 15005~15023 这 19 个在用日志 暂时仍删不掉——它们被 187 上的测试捕获  OGG$CAP_EXTEST / EXTEST1 / EXTEST2 注册占位。这三个是测试捕获，其中  EXTEST 的  captured_scn 还卡在起点、 applied_scn=0，从起始点就把老归档钉死，是 43649 条注册记录的大头，也是  RMAN-08137 的元凶。

清掉它们，注册记录释放，RMAN 才能正常清理那 19 个日志。但这活牵连 187， 稳妥起见，我们先不做。

七、总结：

用 AI 替自己干活，好处是实打实的：诊断脚本、视图查询、文件缺口计算、干跑校验、实际删除，它全包了， 我不用再劳心劳神地敲命令，甚至有些命令生疏了，我需要从记事本中复制，现在连复制都不用了，把我从重复劳动里解放出来。这才是专家该有的样子——把力气花在判断上。

但它的短板这次也还有有点问题： 遇到"报错字面 vs 实际含义"“RMAN 能删 vs 不能删”"机制存在 vs 机制失效"这类需要原理理解和风险意识的判断，它会顺着最省事的路径走，甚至差点动用在用日志。 尤其是 RMAN-08137 这种把 “standby” 写在脸上的报错，几乎必然把人（和 AI）引向"查 Data Guard"的死胡同，而真正的答案藏在"OGG 捕获注册 + 控制文件健忘"里——这是原理级的理解，搜不出来，只能靠经验和对环境的熟悉。