ASH 能诊断一切，但它天生不适合做数据库中控

在 Oracle 数据库领域，ASH（Active Session History）几乎是无可争议的分析基石。
无论是性能瓶颈定位，还是历史故障回溯，ASH 都提供了极其宝贵的观测视角。多年来，DBA 围绕 ASH 写下了大量脚本、报表和分析工具，这些实践极大提升了问题定位效率。

但一个经常被忽略的问题是：

ASH 再强，也始终只是“诊断工具”，而不是“中控系统”的一部分。

这不是实现水平的问题，而是工程定位的问题。

一、诊断工具与中控系统，从来不是一条进化路线

在实际讨论中，很多人默认一个前提：

“既然 ASH 能把问题分析得这么清楚，那是不是再往前一步，就能做自动治理？”

这个前提本身就是错的。

诊断系统和中控系统解决的是两类完全不同的问题：

ASH 的使命，是把复杂问题暴露给人；
中控系统的使命，是在问题扩大前替系统挡住风险。

这两者不是“成熟度不同”，而是工程范式不同。

二、为什么 ASH 脚本在工程上进不了中控

1. ASH 没有裁决权

无论一个 ASH 脚本写得多复杂，它本质上只做三件事：

• 聚合历史数据

• 统计出现频次

• 把“看起来最可疑的对象”展示出来

但它永远不会说：

• 现在是否必须阻断

• 哪条 SQL 不允许继续执行

• 是否需要强制降级

没有裁决权的系统，不可能站在控制链路上。

2. ASH 的输出天然是非确定性的

同一份 ASH 结果：

• DBA A 认为是 SQL 设计问题

• DBA B 认为是 IO 子系统瓶颈

• DBA C 认为是参数或版本问题

这种“解释空间”，在诊断工具中是合理的，甚至是必须的。

但中控系统不能接受：

同一状态，得出不同结论。

中控系统必须满足：
同一输入状态 → 同一裁决结果，否则就无法审计、无法复盘、也无法担责。

3. ASH 没有“失败定义”

ASH 脚本永远不会失败：

• 结果为空，只是“没看出来”

• 结果很乱，只是“信息很多”

但中控系统必须明确知道：

• 什么情况下必须拒绝执行

• 什么情况下宁可停服务也不能继续

• 什么是不可接受状态

一个不知道“什么时候必须停”的系统，不允许参与控制。

4. ASH 的时间语义不对

ASH 是采样数据，是历史记录，本质是：

After-the-fact（事后视角）

而中控系统面对的是：

• 正在发生

• 尚未完全展开

• 仍有干预空间

能把“已经发生的问题”分析得再清楚，也不等于能在“问题发生时”挡住风险。

三、真正能进中控的，只能是“最小 ASH 子集”

如果一定要问：

ASH 里有没有一小部分“有资格”进入中控？

答案是：有，但必须被残酷裁剪。

能进入中控的，不再是“分析视图”，而是被压缩成可裁决的状态证据。

1. 可以留下的字段（极少）

• session_state（ON CPU / WAITING）

• 少数 wait_class（Concurrency、Cluster、Commit 等）

• 白名单事件（明确有工程后果的 event）

• SQL_ID（只作为责任锚点，而非分析对象）

这些字段的共同特点是：

能被转成“是 / 否 / 是否超阈值”的判定条件。

2. 必须剔除的字段（即便 DBA 很爱）

• Top N 排序

• object_id

• module / program

• 执行计划

• 各类“看起来很详细”的统计维度

它们非常适合人类分析，但会直接破坏：

• 裁决确定性

• 规则稳定性

• 行为可审计性

3. 中控真正关心的不是“发生了什么”

而是三个问题：

1. 是否触发裁决

2. 是否允许继续执行

3. 是否进入降级或阻断态

在这个语境下，ASH 的角色已经不再是“分析工具”，而只是裁决证据的一部分。

四、为什么很多“智能运维 / AIOps”会卡在这里

很多所谓的智能运维系统，问题并不在算法，而在工程边界判断上：

• 舍不得放弃分析能力

• 既想解释问题，又想做自动决策

• 最终既不敢真阻断，也无法真担责

结果就是：

看起来什么都懂，实际上什么都不敢动。

结语

ASH 依然是数据库领域最重要的诊断工具之一，这一点毫无疑问。
但它的使命，是帮助人理解系统，而不是替系统做决定。

真正的中控系统，必须建立在：

• 明确的裁决权

• 确定性的输出

• 清晰的责任边界

之上。

这条线一旦跨不过去，
再复杂的 ASH 分析，也只能停留在“旁观者”的位置。