从我92年开始使用Oracle，已经三十多年了，不过前些年的时候使用Oracle，就像盲人摸象一样，第一次觉得自己更加了解Oracle是看到了一个工具utlbstat/utlestat。这是Oracle 7.3.4开始支持OWI之后，Oracle为运维人员提供的一个了解OWI数据的接口。到了Oracle 8.0，一个划时代的工具出现了，那就是AWR的前身-statspack报告。后来Oracle又提供了一种方法，让statspack报告能够在7.3版本上使用。

我可能是国内最早一批使用statspack报告的人，90年代末我就开始使用statspack报告为用户分析故障和性能问题，那时候甚至Oracle原厂的工程师都不习惯使用这个利器。我也曾经给我的客户推荐这个工具，不过他们似乎对此不太感冒。那时候的AWR还比较简陋，主要是罗列数据。正是这些枯燥的数据吸引我不断去探究Oracle内部的原理，因为这些枯燥的数字背后都是十分专业的原理。Oracle 10g的statspack报告有了巨大的提升，不过实际上Oracle 10g开始，Oracle推出了一个更强大的工具-AWR报告。我第一次给用户优化10g数据库的时候，要求用户安装statspack报告，用户不知道这玩意是干啥的，不过既然优化需要，那就装上吧。直到用户拿了一份AWR报告让我帮忙分析，我才知道自己当了一把土老帽。

现在AWR已经成为每个DBA工作中最好的帮手，不会看AWR报告都不好意思说自己干过DBA了。不过AWR报告的内容十分丰富，240多个表格，上万数据都集中在这份报告里。想要把AWR看懂真的也是一门大学问。O记MOS上的How to Use AWR Reports to Diagnose Database Performance Issues (Doc ID 1359094.1)是一篇较为全面介绍AWR分析的文章，不过“全面”也只是相对而言的，实际上这篇文章介绍的内容只是AWR数据的冰山一角。

这些年我阅读过无数AWR报告，目的是为了从中抽丝剥茧，找出问题的关键，打开解决问题的大门。最近突发奇想，想开发一个工具。经过和公司同事商量，大家都同意把AWR报告的解析工具放到BIC-QA这个开源插件里，向广大DBA提供免费的AWR报告解析服务。

现在这个工具已经开发得差不多了，内测一下就准备上传到GITHUB和GITEE上。不过我写的后台解析工具还在不断优化中。目前这个工具有10000多行Python代码，核心分析功能借助了QWEN大语言模型。我主要是把自己解读AWR的方法写成提示词模板，让LLM依据AWR数据和我的阅读方法去解读数据。目前通用性的解读已经初步完成，不过这个工具的开发可能会持续数年，因为除了通用性的专业解读，实际上这个工具要想变得更加有效，输出的结果更加稳定，需要不断加入专业经验。很多经验在我脑子里，不过暂时被遗忘了，我需要一点点回忆出来，甚至有些问题需要遇到类似案例的时候才能回忆起来。

这是一个样例，目前报告输出支持中英日法德等语言。我们计划下周把BIC-QA 1.0.7的代码上传到GITHUB上，下载最新代码，覆盖到以前的1.0.6的目录上就可以升级，配置信息都不会被覆盖。AWR智能解读的结果中大体上还是对DBA有帮助的，不过里面可能还是会存在一定的幻觉。利用LLM，如果分析一个十分精确的案例，可以让幻觉消除到很小的范围，对于有上万数据，里面存在各种各样亚健康状态的AWR报告，哪怕是专家多次阅读，感受都会有所不同，想要让LLM生成出完全准确，没有幻觉的报告，难度太大了，目前阶段可能还做不到。不过通过解析报告再去分析问题，会更加清晰，也更加简单。相当于你让一个水平不错的助手帮你先把AWR报告认真分析一遍，把发现的问题都标注出来，设置优先级，然后你粗略的过一下结果。

我昨天也和几个国产数据库厂商聊起这个事情，他们对Oracle的AWR报告能从中读出这么多有价值的信息都感到羡慕。有个国产数据库厂商的朋友和我说，很巧，他们发现现在的AWR报告功能十分鸡肋，所以已经着手重新开发这个功能了。当初做这个功能完全是凑热闹，根本没弄明白这个报告能干什么。最近他们的产品卖得很好，售后服务压力很大，他们希望能够像Oracle一样，利用AWR来减轻售后服务的压力，提高售后服务的质量。

之前我多次吐槽国产数据库的AWR是各样子货，除了能看看TOP SQL之外没啥用处。很多数据库厂商的朋友不服气，觉得能看TOP SQL，AWR的价值就足够了。可能是目前他们的售后压力都在应用开发商身上，还没有切实的感受吧。我觉得只有国产数据库的AWR真正有用了，国产数据库的售后服务的体系化才有了一个核心支撑。现在的国产数据库售后服务完全靠运气，某些问题正好这个人遇到过，就能解决，否则基本上只能依靠原厂研发了。如果研发处理不过来，很多问题就成为悬案了。