昨天，我们BIC-QA平台的DM8/DM8 DSC AWR报告分析功能终于上线了。对于BIC-QA 1.2及以上版本的用户来说，无需升级即可直接上传达梦AWR报告进行分析，现在工具的选项里多出了一个“达梦”的选型。
目前这个功能尚处于Beta阶段，工具本身是完整的，但我们对达梦AWR报告的解读经验还在持续积累中。
这个与Oracle AWR分析工具几乎同期启动的项目，上线时间却晚了半年。相比之下，启动更晚的KingbaseES KWR分析工具都已经上线四个月了。为什么会这样？问题的核心在于数据。
在开发过程中，我们与包括达梦原厂朋友在内的多方进行过交流，但能获取到的有效资料相当有限。处理报告数据时，我们遇到了多处数据不一致的问题。如果依赖AI大模型来处理，经常会因为错误理解而导致分析结果飘忽不定。由于近期团队工作任务繁重，这个工具的开发一度被搁置。
最近，有几位用户询问达梦AWR分析工具为何还没上线。正好我最近跑客户比较多，手头开发任务不重，于是决定尝试继续完善它。
在AI时代开发工具，最关键的是理解数据和编写知识库，而非编写复杂的业务逻辑。事实上，BIC-QA服务端工具的所有逻辑分析都依赖于大模型。阅读AWR报告一直是我的一个业余爱好，无论是Oracle还是其他数据库的，我都喜欢探究那些数据背后隐藏的系统运行状态。
经过一番梳理，我搞清楚了60多张表格、上千个数据点。这些数据与数据库运行状态之间的关系，至少被编织成了一张网。初步测试时，我发现输出极不稳定。检查后发现，原来是很多数据之间并不对齐——常常出现一个指标指向I/O问题，而另一个指标的指向却完全相反。
如果由人来分析这些数据，经验极其丰富的专家或许能凭借自己的判断，外加一些外部数据采集手段，做出相对准确的诊断。但水平稍逊的DBA，可能就很难从中得出准确结论了。
于是，我花了大量时间加强了对这些数据的分析逻辑。遇到数据无法对齐的情况，就利用其他数据来补充分析，直至获得一致的判断。经过一系列修正，输出结果终于变得比较稳定了。接下来，其实需要从用户那里获取一些真实的报告进行仔细验证，进一步修订知识库，才能让工具正式上线。
我找了几个客户，希望能拿到几份AWR报告来分析。回想当年开发Oracle AWR分析工具时，我们从十多个客户那里收集了报告，确保分析结果基本靠谱后才上线。但这次，我遇到了一个奇怪的现象：我问过的达梦用户几乎都没有收集过AWR报告。甚至有些用户反馈，达梦的售后人员曾说AWR报告“没什么用，数据不准确”，不建议他们开启采集功能。
这有点出乎我的意料。接手这个工具后，我仔细阅读了达梦的AWR报告，觉得其中的数据在国产数据库中算是不错的。报告中的数据项显然是针对一线运维场景设计的，并不像某些数据库那样完全照搬Oracle。会话分析、会话历史、VM数据、内存池数据等，都是围绕达梦数据库的内核特性展开的，而这也正是用户遇到问题时难以自行分析的领域。
虽然数据的准确性和全局一致性确实存在不少问题——比如发现某个会话有问题，却无法从会话历史中找到它，从而无法进一步定位问题程序——但要说它“没啥用”，我就无法理解了。至于其他数据，如果连这些来自v$sysstat或v$sessions等常用视图的数据都不准确，那么达梦可观测性的基础岂不是出了问题？我想应该不至于如此。
中间的曲折暂且不提。上线测试时，我突然发现了一个问题：因为达梦AWR的数据结构比Oracle简单，所以分析时间略短，大概5-7分钟就能完成一份报告。然而一看Token账单，我愣住了——成本居然比Oracle高了一倍，分析一份报告要花1毛5，而分析Oracle报告基本能控制在一毛钱以内。
昨天在一个技术群里聊到这件事，一位朋友的话让我茅塞顿开：正是因为达梦AWR报告的数据质量不如Oracle，我们才必须花费更大的代价去解决数据本身的问题。在传统开发模式下，这意味着要编写大量代码来处理低质量数据。而在AI时代，这直接转化为了算力成本的差异。一个企业如果拥有高质量的数据，就意味着其算力成本远低于同行，从而获得更强的竞争力。
前阵子AI热潮时，很多企业希望用“大模型”解决所有问题，但很快他们就发现，除了花大价钱购买设备和Token，实际获得的收益远低于预期。无论AI技术发展得多迅猛，做好自身的数据治理，始终是一件极具价值的工作。欢迎大家在云栈社区交流更多数据库性能分析与数据治理的经验。
发表于 2 小时前
|
查看: 3|
回复: 0
