凌晨两点，业务群里有人说：系统刚才卡了十分钟，现在又好了。你登录数据库，CPU已经落下去，锁也释放了，眼前一切正常。如果系统没有留下历史，DBA能做的往往只剩下猜。报告时代的意义，就是让数据库第一次有机会回答一句话：刚才那段时间，到底发生了什么？

一条来自亲历者的时间线

数据库性能监控与可视化专家凯尔·海利²（Kyle Hailey），曾整理和回顾他从Oracle 6时代一路参与和观察性能工具演进的经历。在海利的时间线里，Oracle 6被放在1988年，Utlbstat/Utlestat被放在1989年；他保存的一份脚本修订记录还写着“Martin 02/22/89 - Creation”。他把这一代工具的优点和毛病概括为三组词：Intrusive、Overwhelming、Ratios & Averages——有侵入性，信息多得压人，严重依赖比率和平均值。

这三个评价听起来很不客气，但很准确。早期动态性能视图提供的多是实例启动以来不断累加的计数器。你在凌晨两点查到一千万次逻辑读，并不知道其中多少发生在刚才那十分钟。Utlbstat/Utlestat做了一件今天看来朴素、当时却很关键的事：在问题窗口前后各拍一张快照，再计算差值。数据库终于不只展示“现在累计到多少”，而开始留下“这段时间增加了多少”。

图1：海利将Utlbstat/Utlestat概括为“侵入性、信息过载、比率与平均值”。

如果你去翻看Oracle数据库早期的文档，会发现Oracle 8中写着“Utlbstat会在SYS账户下建立起始快照表，Utlestat建立结束快照并生成报告”；Oracle 9i中把它们称为应当长期归档的“最低限度”数据库活动记录。可以说，Utlbstat/Utlestat的价值不只是多了一份脚本，而是把临时现场变成了可重复、可比较的证据。从Oracle 8i开始，UTL脚本进化为Statspack工具包。

² 凯尔·海利（Kyle Hailey）是数据库性能监控与可视化领域专家。1990年进入Oracle后，他先后从事技术支持、Oracle 6移植、基准测试和性能工作；后来参与Oracle Enterprise Manager 10g性能页面重构，将等待时间与平均活跃会话数（AAS）等方法转化为更直观的监控界面。他是OakTable成员、Oracle ACE/ACE Director，长期讲授等待事件、平均活动会话（AAS）与活动会话历史（ASH）等主题。离开Oracle后，他曾任职于Embarcadero、Delphix和Amazon。

两张快照，怎样变成一份report.txt

这组脚本后来也常被简称为BSTAT/ESTAT。测量开始时，Utlbstat把V$SYSSTAT、V$SYSTEM_EVENT、V$ROWCACHE、V$LIBRARYCACHE、V$LATCH、回滚段和数据文件等视图的值复制进一组STATS$BEGIN表；工作负载运行一段时间后，再执行Utlestat取得结束值，计算区间差值，按区间秒数折算速率，最后在当前目录生成report.txt。

假设数据库02:00时逻辑读为100万，02:30变成190万，那么这半小时的逻辑读增量就是90万，平均500次/秒。底层逻辑可以写成一行：【区间工作量 = 结束计数 - 开始计数】。Oracle今天的性能指南仍强调，分析累积统计时应关注目标时段的变化（delta）；Statspack、AWR乃至许多监控平台，至今依旧建立在“采样、做差、归一化”这套基本动作上。

图2：两张累计计数快照做差，得到指定时间窗口的工作量。

要注意，它保存的是两个时点之间的总量，不是连续录像。只要记住这一点，后面许多优点和缺陷就都能解释：它能告诉你半小时内一共发生了什么，却很难告诉你第十三分钟发生了什么。

一份典型报告会列出缓冲区活动、解析和执行次数、redo、排序、回滚段、数据文件I/O、数据字典缓存、library cache、latch以及系统等待事件。它像一份很厚的体检单：红细胞、肝功能、血脂都在，但医生仍要结合症状判断哪一项与这次不舒服有关。

海利在他的演讲PPT中没有解释某一行指标，而是把整份文本拼成一堵“墙”（如图3所示）。这张图很直观——报告把数据库内部系统地摊在DBA面前，也制造了新的困难：字段多、缩写多、口径不完全一致，重要信号与背景噪声挤在同一层级。对DBA熟手来说，这是矿山，能挖出很多有价值的东西；但对刚接手系统的新人，常常只是一大片让人眼花缭乱的数字。

图3：性能报告可以包含大量细节，也可以把真正的问题埋在细节里。

老DBA可能还会补一句：“只看数据库报告不够。”因为Oracle 8i文档明确建议，在同一时间窗口运行vmstat、sar、iostat等操作系统工具。原因很简单——数据库知道自己发出了多少I/O请求，却未必知道磁盘队列为何变长；它知道进程在等CPU，却不能单凭实例统计说明CPU被谁占了。

这也形成了数据库监控的一条早期规则：证据必须同窗。数据库快照与主机采样如果不在同一时间窗口，两边都是事实，拼在一起却可能成为错案。今天常说的“统一时间线”，源头并不神秘，就是当年的手工对表被平台化了。

图4：数据库快照与主机采样只有覆盖同一时间窗口，才能拼成完整现场。

报告最常见的数据大致分三类。计数器回答“做了多少”，例如执行次数、逻辑读和物理读；速率回答“做得多快”，例如每秒事务数；比率和平均值则把多个计数压成一个便于比较的分数。三者都值得看，但顺序很重要：先看绝对增量，再看区间长度和业务吞吐，最后才看比率。反过来读，很容易被漂亮数字带偏。

以缓冲区命中率为例，简化公式是【1 - 物理读/逻辑读】。工作负载A做100万次逻辑读，其中1万次需要物理读，命中率是99%。工作负载B仍然只有1万次物理读，却因为一条糟糕SQL把逻辑读放大到1000万次，命中率反而升到99.9%。如果只盯命中率，B看起来更健康；实际上数据库多做了九倍逻辑工作，CPU和响应时间都可能更差。

图5：分母膨胀可以让命中率更漂亮，却让数据库做更多工作。

这不是说命中率没有用。命中率能提示缓存与访问模式的变化，问题是不能把它当裁决书。Oracle今天的文档仍然提醒：低命中率不等于扩大缓存一定有效，高命中率也可能错误地暗示缓存配置合理；重复扫描和糟糕SQL甚至会改变分母。因此，看任何比率，都要把分子、分母和业务结果重新摊开。

再看平均值。假设一个30分钟窗口里，29分钟的物理读都是每分钟1000次，只有02:13那一分钟冲到10万次。报告会给出每分钟4300次的平均值。这个数字没有算错，却把一次足以拖慢交易的尖峰摊薄成了看似温和的波动。

图6：区间平均值只有4,300次/分钟，但其中一分钟的峰值达到100,000次。

平均等待时间也有同样的问题。一次10秒等待和一万次1毫秒等待可以被压成一个数字，用户感受却完全不同。报告还会丢掉事件在区间内的先后关系：先出现日志切换，还是先出现提交延迟？先有全表扫描，还是先有缓存压力？没有时间序列，因果链很容易倒着讲。

第一是区间盲。窗口越长，尖峰越容易被平均；窗口越短，采集和人为操作越频繁。

第二是归因弱。早期报告以实例级汇总为主，告诉你“发生了很多物理读”，却未必直接告诉你是哪条SQL、哪个会话、哪个对象造成的。

第三是依赖人工。开始快照没跑、结束快照晚了、期间实例重启，报告就可能失去意义。

第四是观测成本。海利称它“intrusive”，不是说跑一次一定把库拖垮，而是提醒我们：建表、查询大量动态视图、生成长报告都不是零成本，采得越频繁，越要考虑监控本身对现场的扰动。

如今，Utlbstat/Utlestat虽然已经退出主流视野，但它留下的阅读方法并没有过时。AWR更丰富，监控平台更实时，误判方式却常常还是老样子。

• 先确认时间窗。开始和结束是否覆盖故障？期间是否重启、切换或修改过统计配置？不确认这一点，后面的精确数字都可能没有意义。

• 先看总量，再看比率。把执行次数、DB Time、逻辑读、物理读、redo和提交数列出来，再判断命中率、每事务开销和平均等待是否真的异常。

• 把分母写在旁边。任何百分比都要带原始分子和分母。99.9%不是结论，只是一个压缩后的结果。

• 数据库与主机必须同窗。数据库快照、业务延迟、CPU、I/O队列、网络和变更记录要使用同一时区、同一粒度或可校准的时间戳。

• 比较相似的工作负载。周一高峰与周日凌晨没有可比性。建立基线时，应尽量选择业务量、数据规模和并发模式相近的时段，并核对版本与配置是否发生变化。脱离了这些背景，“比昨天高30%”通常只是一句废话。

把报告时代的四个硬伤放到今天看，会发现现代平台并没有抛弃快照思想，而是把它扩展成了连续证据链。以zCloud或Bethune X³为例：对变化快、业务影响大的指标提高采集频率，对容量等慢变量降低频率；既保留趋势，又控制存储和采集扰动。这正是对“窗口太长看不见尖峰、窗口太短又怕打扰现场”的现代回答。

³ zCloud是云和恩墨自研的多元数据库智能管理平台，主要面向数据库实例规模大、DBA团队分工细、运维流程要求更完整的企业级场景，覆盖数据库全生命周期管理能力，支持30余种数据库深度纳管，并通过多智能体团队提升复杂场景下的分析、诊断与处置效率。Bethune X则定位为轻量级智能监控巡检平台，更适合中小规模团队或希望快速建立数据库监控、巡检、诊断能力的客户；平台支持快速接入、快速使用，聚焦智能问答与问题诊断，帮助用户以更低门槛获得智能化运维能力。

更关键的是，区间汇总不再是终点。zCloud和Bethune X的性能分析可以先在时间轴上识别异常时段，再下钻到TOP SQL、TOP Event和TOP Session，并把异常时段与历史时段比较；对于活动会话数据，还可用历史90分位线建立基线，标出被平均值掩盖的性能波峰（如图7所示）。报告时代留下的“先取区间差值”，于是继续演化为“定位时段—建立基线—多维归因”。更重要的是，zCloud和Bethune X将以Oracle为代表的先进数据库监控思想、方法变成了通用能力，在开源和国产数据库中实现了同样的落地。

图7：zCloud以活动会话历史的90分位线建立基线，识别被区间平均值掩盖的性能波峰。

Oracle 8.1.6引入Statspack，用永久表保存多个快照、采集高资源SQL，并把采集与报告分离。它没有推翻报告逻辑，而是把一次性报告变成了可以积累、回看和比较的资料库：报告时代开始修补自己的区间盲、归因弱和人工依赖。

回望这一阶段，数据库监控完成的关键跨越是证据开始有了明确的时间边界：两次快照之间的增量、同一窗口里的主机采样、比率背后的分子与分母。它让“刚才发生了什么”不再完全依赖记忆，也让性能判断第一次有了可以复核的起点。

但报告也留下一个持久的警告：数据越多，不等于判断越好。比率会掩盖工作量，平均值会抹平尖峰，实例总量会藏住责任主体。无论是Utlbstat/Utlestat、AWR，还是今天zCloud或Bethune X这样的统一管理平台，真正有价值的监控都在做同一件事——把指标组织成有时间、有对象、有上下文的证据。报告时代的遗产，不是一摞report.txt，而是一套至今仍在生长的证据方法。