面试宝典:介绍下Oracle数据库动态性能视图 V$HANG_STATISTICS

好的，我们来对 Oracle 19C 数据库中的 V$HANG_STATISTICS 动态性能视图进行一次全面而深入的解析。这个视图提供了不同于 V$HANG_INFO 和 V$HANG_SESSION_INFO 的独特视角，专注于挂起事件的统计和模式分析。

---

1. 作用与概述

V$HANG_STATISTICS 视图用于记录和展示数据库实例中检测到的挂起（Hang）事件的统计信息和历史记录。它不像 V$HANG_INFO 那样展示一次分析的快照，而是持续累积各种挂起相关的指标，用于观察趋势和模式。

• 核心目的： 提供一种历史性和聚合性的视角来审视数据库中的挂起问题。它回答了“数据库在运行生命周期中，发生过多少次挂起？哪种类型的挂起最常见？平均持续时间是多久？”等问题。
• 数据性质： 该视图中的数据是持久性的统计计数器（自实例启动以来累计），直到实例重启才会重置。它记录了多次挂起事件聚合后的结果。
• 监控方式： 其数据来源包括：
  1. 数据库后台诊断进程（DIAG）自动检测到的潜在挂起。
  2. 用户手动执行 ORADEBUG HANGANALYZE 命令。
  3. 其他内部机制触发的挂起分析。

2. 使用场景

此视图主要用于长期监控和趋势分析，而非实时故障诊断：

1. 容量规划与性能基线建立：

   • 长期监控 TOTAL_HANGS_DETECTED，了解系统在特定负载下的稳定性。如果该数值持续增长，表明系统可能存在潜在的资源瓶颈或设计问题。

2. 识别反复出现的挂起模式：

   • 通过分析 HANG_CLASS 和 HANG_REASON 的分布，可以发现某些特定类型的挂起（如特定的锁争用、闩锁争用）是否频繁发生，从而进行针对性优化。

3. 评估优化措施的有效性：

   • 在实施了某项优化（如调整初始化参数、修改应用逻辑）后，观察特定 HANG_REASON 的 TOTAL_OCCURRENCES 是否下降，从而验证优化是否生效。

4. Proactive（主动）健康检查：

   • 定期检查此视图，可以在用户感受到严重的性能问题之前，发现挂起频率上升的苗头，从而主动介入调查。

3. 字段含义详解

V$HANG_STATISTICS 的字段围绕挂起事件的分类和统计指标。

字段名称	数据类型	含义说明
HANG_CLASS	VARCHAR2(64)	挂起事件的大类分类。提供了挂起原因的高级分组。例如： • Lock： 由锁争用引起的挂起。 • Latch： 由闩锁争用引起的挂起。 • System： 系统内部问题引起的挂起。 • Other： 其他未分类的挂起。
HANG_REASON	VARCHAR2(64)	挂起事件的具体原因。这是更细粒度的分类，是诊断的核心。例如： • enq: TX - row lock contention • latch: shared pool • buffer busy waits • library cache: mutex X
TOTAL_OCCURRENCES	NUMBER	自实例启动以来，该类型挂起事件发生的总次数。这是最重要的指标之一，用于识别热点挂起原因。
TOTAL_DURATION	NUMBER	该类型所有挂起事件的总持续时间（单位：秒）。
AVG_DURATION	NUMBER	该类型挂起事件的平均持续时间（单位：秒）。由 TOTAL_DURATION / TOTAL_OCCURRENCES 计算得出。
MIN_DURATION	NUMBER	该类型挂起事件的最短持续时间（单位：秒）。
MAX_DURATION	NUMBER	该类型挂起事件的最长持续时间（单位：秒）。用于发现最严重的异常事件。
FIRST_DETECTION_TIME	TIMESTAMP	该类型挂起事件第一次被检测到的时间。
LAST_DETECTION_TIME	TIMESTAMP	该类型挂起事件最后一次被检测到的时间。
DETECTION_COUNT	NUMBER	检测到该类型挂起的次数（可能与 TOTAL_OCCURRENCES 计算方式略有不同）。
CON_ID	NUMBER	所属容器的ID。在多租户环境中，标识该统计信息属于哪个PDB。

4. 相关视图与基表

• 相关动态性能视图：

  • V$HANG_INFO / V$HANG_SESSION_INFO： 这是最直接的关联视图。V$HANG_STATISTICS 中的统计信息，正是基于多次 V$HANG_INFO 分析结果的聚合。前者看“森林”（趋势），后者看“树木”（单次详情）。
  • V$SYSTEM_EVENT： 也包含等待事件的聚合信息，但视角不同。V$SYSTEM_EVENT 统计所有等待，而 V$HANG_STATISTICS 只统计那些严重到被诊断为“挂起”的等待。
  • V$LATCH / V$LOCK： 当 HANG_REASON 是闩锁或锁时，可以关联这些视图查看更详细的资源争用情况。
  • DBA_HIST_HANG_STATISTICS (AWR)： 是 V$HANG_STATISTICS 的历史快照，存储在AWR仓库中，用于跨时间范围的历史趋势分析（需要Diagnostic Pack）。

• 基表（Underlying Base Table）：

  • **X$KGCHS\ast \ast ：这是‘V$HANG_STATISTICS` 所依赖的底层内存结构（基表）。它存储了挂起统计信息的累积计数器。
  • 与 V$HANG_INFO 的动态快照不同，X$KGCHS 是一个持久性的内存结构，其内的计数器会随着挂起事件的发生而不断累加，直到实例关闭。
  • 重要提示： 这是一个内部的、未公开的X$表，严禁直接查询。
  • 视图定义查询：

    SELECT view_definition FROM v$fixed_view_definition WHERE view_name = 'GV$HANG_STATISTICS';
    

5. 底层详细原理

1. 统计信息的收集与更新机制：

   • 每当数据库的挂起检测机制（无论是自动的还是手动的）确认并记录了一次挂起事件（例如，生成了 V$HANG_INFO 的记录），它就会同时更新 X$KGCHS 中的统计计数器。
   • 更新流程：
     1. 分析挂起事件，确定其 HANG_REASON（如 enq: TX - row lock contention）并归入相应的 HANG_CLASS（如 Lock）。
     2. 在 X$KGCHS 中找到对应的 HANG_REASON 记录。
     3. 将 TOTAL_OCCURRENCES 计数器加 1。
     4. 将本次挂起的持续时间加到 TOTAL_DURATION 上。
     5. 更新 MIN_DURATION 和 MAX_DURATION。
     6. 更新 LAST_DETECTION_TIME（如果是新原因，则同时设置 FIRST_DETECTION_TIME）。

2. 自动检测与手动触发的贡献：

   • DIAG 进程： 持续监控系统状态。如果发现会话等待时间异常长，超过了内部阈值，它可能会自动触发一个轻量级的分析，如果确认是挂起，就会更新统计信息。
   • 手动分析 (ORADEBUG): 用户手动触发的分析结果也会被统计进来。
   • 因此，V$HANG_STATISTICS 反映了数据库自身对“挂起”的认知，可能与外界感知不完全一致（例如，一个持续30秒的锁等待可能被应用用户认为是“挂起”，但数据库可能直到60秒阈值才将其记录为一次挂起）。

3. 与等待事件统计的区别：

   • V$SYSTEM_EVENT 统计所有的等待，无论其持续时间长短。
   • V$HANG_STATISTICS 只统计那些持续时间长、严重性高、被数据库内部诊断框架认定为“挂起” 的等待子集。它是一个“严重等待”的超集。

6. 相关知识点介绍

• 挂起（Hang） vs. 等待（Wait）：

  • 等待： 是数据库正常的操作机制。会话等待一个资源（如磁盘I/O、锁）是可接受的，只要等待时间在合理范围内。
  • 挂起： 通常指异常或过长的等待，导致会话无法继续执行，进而可能引发连锁反应，导致系统部分或整体性能雪崩、失去响应。

• 诊断进程（DIAG）：

  • 这是Oracle数据库的一个后台进程，负责挂起检测、死锁检测（与LMON协作）和其他诊断功能。
  • 它负责维护 V$HANG_STATISTICS 的底层数据。

• AWR 与历史数据：

  • 由于 V$HANG_STATISTICS 在实例重启后重置，对于长期性能趋势分析，DBA_HIST_HANG_STATISTICS AWR表更为重要。AWR快照会定期将 V$HANG_STATISTICS 的内容持久化到磁盘。

7. 常用查询 SQL

1. 查看所有挂起事件的统计摘要（按发生次数排序）

SELECT hang_class,
       hang_reason,
       total_occurrences,
       avg_duration,
       max_duration,
       first_detection_time,
       last_detection_time
FROM v$hang_statistics
ORDER BY total_occurrences DESC;

2. 查找持续时间最长的挂起类型

SELECT hang_class, hang_reason, max_duration, total_occurrences
FROM v$hang_statistics
WHERE max_duration > 60 -- 查找最长持续时间超过1分钟的挂起
ORDER BY max_duration DESC;

3. 监控最近的挂起活动

SELECT hang_reason, last_detection_time, total_occurrences
FROM v$hang_statistics
WHERE last_detection_time > SYSDATE - 1/24 -- 查询最近1小时内发生的挂起
ORDER BY last_detection_time DESC;

4. 关联 V$SYSTEM_EVENT，比较挂起与普通等待

SELECT hs.hang_reason,
       hs.total_occurrences AS hang_count,
       se.total_waits AS total_waits,
       se.time_waited_micro/1000000 AS total_wait_secs,
       ROUND((hs.total_occurrences / se.total_waits) * 100, 4) AS hang_to_wait_ratio
FROM v$hang_statistics hs
JOIN v$system_event se ON hs.hang_reason = se.event
WHERE se.total_waits > 0
ORDER BY hang_to_wait_ratio DESC;
-- 这个比率可以显示某种等待事件演变成挂起的“概率”。

5. 在AWR历史中分析挂起趋势（需要Diagnostic Pack）

SELECT hhs.snap_id,
       TO_CHAR(sn.begin_interval_time, 'YYYY-MM-DD HH24:MI') AS snap_time,
       hhs.hang_reason,
       hhs.total_occurrences,
       hhs.max_duration
FROM dba_hist_hang_statistics hhs
JOIN dba_hist_snapshot sn ON hhs.snap_id = sn.snap_id AND hhs.instance_number = sn.instance_number
WHERE sn.begin_interval_time > SYSDATE - 7 -- 查询最近7天
AND hhs.hang_reason = 'enq: TX - row lock contention' -- 以行锁争用为例
ORDER BY sn.begin_interval_time;

---

总结

V$HANG_STATISTICS 动态性能视图提供了从宏观统计和长期趋势角度审视数据库挂起问题的能力。它与提供微观快照的 V$HANG_INFO 相辅相成，共同构成了Oracle数据库挂起分析的完整体系。

通过此视图，您可以：

• 量化 数据库的稳定性和健康状况，建立性能基线。
• 识别 反复发生的、模式化的性能瓶颈根源。
• 评估 系统优化和变更的实际效果。
• 实现 从“被动救火”到“主动预防”的运维模式转变。

将 V$HANG_STATISTICS 的统计趋势与 V$HANG_INFO 的详细快照结合使用，能够让DBA对系统的并发性和稳定性有更深刻、更全面的理解，是进行高端性能管理和容量规划的重要工具。

欢迎关注我的公众号《IT小Chen》