Oracle AWR 分析 Skill 体系建设实践汇报

一、背景

在 Oracle 数据库性能诊断场景中，AWR 报告一直是问题分析、根因定位和客户交付的重要依据。但在实际项目执行过程中，我们长期面临以下几个典型问题：

• AWR 分析高度依赖少数资深 DBA 的个人经验
• 分析过程缺乏统一方法论，输出质量波动较大
• 从原始 AWR 到客户可交付报告之间存在较多人工整理和反复校对工作
• 多实例、跨时间段、基线对比等复杂场景下，容易出现分析不完整或结论不够严谨的问题
• 即使引入通用 AI，也容易出现“表达流畅但证据不足”的情况，难以直接用于正式交付

基于以上问题，我们尝试将 Oracle AWR 分析经验沉淀为一套可复用的 Codex skill 体系，目标不是单纯让 AI“会分析”，而是让 AI 参与到可控、可复核、可交付的工作流中。

二、项目目标

本次实践的核心目标主要包括以下几个方面：

1. 将 Oracle AWR 分析流程标准化，降低对个人经验的强依赖。
2. 提升 AWR 报告分析与交付效率，减少重复性人工工作。
3. 为 AI 增加明确的流程约束和质量护栏，降低错误结论直接流入客户交付的风险。
4. 形成团队可复用、可维护、可扩展的数据库分析能力资产。

三、我们遇到的关键问题

在将 AWR 分析能力交给 AI 的过程中，我们发现，真正的难点并不在于“让 AI 读懂几个指标”，而在于以下几点：

• 如何准确确定问题发生的核心 AWR 时间窗口
• 如何确保核心窗口与同实例基线、跨天同时间段基线正确配对
• 如何在 RAC 场景下保持实例级别的独立判断，避免错误汇总
• 如何让 ADDM、等待事件、负载、SQL、资源使用形成完整证据链
• 如何保证正文中提到的 SQL 在附录中有完整文本支撑
• 如何保证 Markdown 报告与最终 Word 报告内容一致

如果缺少这些约束，通用 AI 很容易给出“看起来合理”的结论，但这些结论往往不适合直接用于正式交付。

四、解决思路

本次并未采用“一个万能提示词包打天下”的方式，而是将能力拆分为 3 个职责边界明确的 skill，分别对应分析、复核和端到端交付三个层次。

4.1 oracle-awr-analysis

该 skill 负责完成结构化分析，是整个体系中的“分析执行层”。

其主要职责包括：

• 识别问题时间附近的核心 AWR 窗口
• 对核心窗口与基线窗口进行比对
• 覆盖 A-H 全维度分析
• 深入检查 ADDM、慢 SQL、高频 SQL、等待事件和资源指标
• 生成 Markdown 报告，并作为后续 Word 报告生成的基础

这一层的价值在于：把原本依赖人工经验的分析步骤显性化、流程化。

4.2 oracle-awr-result-review

该 skill 负责二次审查，是体系中的“质量控制层”。

其主要职责包括：

• 对分析结果进行怀疑式复核
• 挑出结论中的证据缺口、逻辑跳跃和重大风险
• 识别实例映射错误、基线配对错误、附录缺失等交付级问题
• 判断当前报告是否达到可交付状态

这一层的价值在于：避免 AI 第一版分析结果未经校验就直接对外输出。

4.3 oracle-awr-end-to-end

该 skill 负责串联完整流程，是体系中的“交付编排层”。

其主要职责包括：

• 统一调度结构化产物生成、分析、复核和最终报告输出
• 明确 Markdown 是唯一可编辑真相源
• 规定 Word 报告必须由最终 Markdown 重生成
• 在分析与复核结论冲突时，优先采用更保守、更稳妥的交付策略

这一层的价值在于：把多个局部能力连接成真正可落地的交付链路。

五、为什么要这样拆分

从实践结果看，将能力拆分成“分析、复核、交付编排”三层，有几个明显收益：

• 便于职责隔离，降低一个 skill 过于复杂导致的失控风险
• 便于持续迭代，后续可单独增强分析或复核逻辑，而不影响整体结构
• 便于团队协作，不同角色更容易理解各自关注点
• 便于质量治理，把复核机制前置，避免“错误结论先产出，再返工修补”

这实际上与企业内部成熟的技术交付机制是一致的：分析、审核、交付本就不应完全混在一起。

六、当前阶段的实际价值

从当前落地情况看，这套 skill 体系已经具备以下实际价值：

• 可以沉淀资深 DBA 的分析经验，减少口口相传带来的损耗
• 可以提升标准化分析和文档输出效率
• 可以让 AI 更适合作为“分析助手 + 交付协同工具”，而不是单纯聊天机器人
• 可以为后续批量分析、自动化报告生成和统一质量治理打基础

尤其对于报告量逐步增加、但资深 DBA 人力有限的团队，这种方式更具现实意义。

七、阶段性经验总结

本次实践过程中，有几条经验较为明确：

7.1 不能把 AI 能力等同于交付能力

AI 能够输出一段流畅分析，并不等于它已经具备正式交付能力。对数据库分析这类高专业任务来说，证据链完整性远比表达能力更重要。

7.2 流程约束比“大模型自由发挥”更重要

在 AWR 分析这类场景中，明确输入顺序、强制核对基线、要求附录闭环、区分事实与推断，这些流程约束比单纯增强提示词更有效。

7.3 复核机制必须独立存在

如果没有独立的复核环节，AI 的第一版输出很容易因为语言流畅而掩盖逻辑缺口。把“挑错”设计成单独 skill，是提升可交付质量的关键。

7.4 Markdown 作为唯一真相源非常重要

在报告交付场景下，如果 Markdown 和 Word 各自独立修改，后期极易失配。统一从 Markdown 生成 Word，可以明显降低交付混乱风险。

八、后续建议

结合当前实践，建议下一阶段从以下方向继续推进：

1. 继续补充更细粒度的专项 skill，例如 SQL 深挖、基线异常识别、RAC 专项诊断等。
2. 建立更明确的分析质量评价标准，用于衡量 AI 输出是否达到内部交付要求。
3. 将 skill 使用过程中的典型案例、误判案例和修正经验持续回灌，形成团队知识库。
4. 在条件成熟后，再逐步考虑批量分析、自动交付和内部流程集成能力。

九、总结

本次实践的核心结论是：

对 Oracle AWR 这类高专业度场景，AI 的价值不在于替代专家做一次“聪明回答”，而在于把专家经验结构化、流程化，并沉淀为团队可复用的工作能力。

将能力拆成分析、复核、端到端交付三个层次后，我们获得的不是一个更花哨的 AI，而是一套更接近企业实际交付方式的工作机制。

从这个角度看，本次 skill 建设的意义不仅在于提升单次分析效率，更在于为后续 AI 在数据库运维和性能诊断场景中的长期落地，建立了一个可持续扩展的基础框架。