好的，我们来对 Oracle 19C 数据库中的 V$HANG_SESSION_INFO 动态性能视图进行最全面、最深入的解析。这个视图是 V$HANG_INFO 的姊妹视图，提供了关于挂起会话的更详细、更底层的诊断信息。
1. 作用与概述
V$HANG_SESSION_INFO 视图用于提供参与挂起或严重阻塞的每个会话的详细状态快照和诊断信息。
- 核心定位： 如果说
V$HANG_INFO提供了阻塞关系的 “组织结构图” （谁阻塞谁），那么V$HANG_SESSION_INFO则提供了图中每个 “员工”的详细人事档案 （每个会话在挂起瞬间在做什么、等什么、有什么）。 - 数据关联： 此视图中的会话通过
CHAIN_ID与V$HANG_INFO中的阻塞链关联。它为V$HANG_INFO中标识出的每个阻塞者和被阻塞者提供了深度的上下文信息。 - 信息深度： 它包含了比
V$SESSION更丰富、更侧重于挂起诊断的信息，例如进程状态、等待事件详情、当前持有的锁和闩锁等，这些都是定位挂起根本原因的关键线索。
2. 使用场景
此视图在以下高级诊断场景中不可或缺：
-
深度根因分析：
- 在
V$HANG_INFO识别出阻塞链的总体结构后，使用本视图深入分析链中每个关键会话的详细状态。例如，查看阻塞者会话正在执行什么SQL、持有什么类型的锁、其进程状态是否正常。
- 在
-
诊断复杂的资源争用：
- 对于非锁引起的挂起（如闩锁、缓冲区忙等待、库缓存争用），此视图提供了会话当前持有的资源信息（
CURRENT_QUEUES,CURRENT_LATCHES），这是判断资源争用热点的直接证据。
- 对于非锁引起的挂起（如闩锁、缓冲区忙等待、库缓存争用），此视图提供了会话当前持有的资源信息（
-
理解会话的完整上下文：
- 它提供了会话在挂起瞬间的“全身照”，包括其操作系统进程ID、程序名、SQL地址、等待历史等，这对于全面理解问题场景至关重要。
-
为Oracle支持收集证据：
- 当需要向Oracle技术支持提交服务请求（SR）时，查询此视图和
V$HANG_INFO的结果是必须提供的关键诊断信息之一。
- 当需要向Oracle技术支持提交服务请求（SR）时，查询此视图和
3. 字段含义详解
V$HANG_SESSION_INFO 的字段非常详尽，涵盖了会话的各个方面。
| 字段类别 | 字段名称 | 数据类型 | 含义说明 |
|---|---|---|---|
| 标识信息 | SESSION_ID | NUMBER | 会话标识符（SID）。 |
| SERIAL# | NUMBER | 会话序列号。与SID共同唯一标识一个会话。 | |
| PROCESS_ID | NUMBER | 操作系统进程标识符（PID）。 | |
| PROCESS_NAME | VARCHAR2(5) | 进程名称（如：ora, java）。 | |
| 阻塞链信息 | CHAIN_ID | NUMBER | 此会话所属的阻塞链的ID。与 V$HANG_INFO.CHAIN_ID 关联。 |
| BLOCKING_SESSION | NUMBER | 直接阻塞此会话的SID。 | |
| BLOCKED_SESSION | NUMBER | 此会话直接阻塞的SID（如果有）。 | |
| 状态信息 | STATUS | VARCHAR2(8) | 会话状态（如：ACTIVE, INACTIVE, KILLED）。 |
| STATE | VARCHAR2(19) | 更详细的会话等待状态（如：WAITING, WAITED UNKNOWN TIME, WAITED SHORT TIME）。 | |
| WAIT_EVENT | VARCHAR2(64) | 会话当前等待的事件名称（如果是等待状态）。 | |
| WAIT_TIME | NUMBER | 已等待的时间（单位：秒）。 | |
| SECONDS_IN_WAIT | NUMBER | 在当前等待事件中已经消耗的秒数。 | |
| 资源信息 | CURRENT_QUEUES | VARCHAR2(128) | 此会话当前持有的队列锁（Enqueue）列表。格式为 类型-ID1-ID2（如：TX-0001000F-00002A74）。这是诊断锁阻塞的关键！ |
| CURRENT_LATCHES | VARCHAR2(128) | 此会话当前持有的闩锁（Latch）列表。 | |
| CURRENT_MUTEXES | VARCHAR2(128) | 此会话当前持有的互斥量（Mutex）列表。 | |
| 执行信息 | SQL_ID | VARCHAR2(13) | 当前正在执行的SQL的ID。 |
| SQL_CHILD_NUMBER | NUMBER | SQL子游标号。 | |
| SQL_ADDRESS | RAW(4 | 8) | SQL语句在内存中的地址。 | |
| SQL_HASH_VALUE | NUMBER | SQL语句的哈希值（较老的方式，与SQL_ID共存）。 | |
| PLSQL_ENTRY_OBJECT_ID | NUMBER | 如果正在执行PL/SQL，则是入口对象（如包、过程）的ID。 | |
| PLSQL_ENTRY_SUBPROGRAM_ID | NUMBER | 入口子程序（如具体的过程、函数）的ID。 | |
| PLSQL_OBJECT_ID | NUMBER | 当前正在执行的PL/SQL对象的ID。 | |
| PLSQL_SUBPROGRAM_ID | NUMBER | 当前正在执行的PL/SQL子程序的ID。 | |
| 上下文信息 | MODULE | VARCHAR2(64) | 应用程序设置的模块名。 |
| ACTION | VARCHAR2(64) | 应用程序设置的动作名。 | |
| CLIENT_IDENTIFIER | VARCHAR2(64) | 客户端标识符。 | |
| PROGRAM | VARCHAR2(48) | 客户端程序名（如：sqlplus@hostname (TNS V1-V3)）。 | |
| PORT | NUMBER | 客户端连接端口。 | |
| 分析信息 | DETECTION_TIME | DATE | 此信息被采集的时间点。 |
| ORIGIN | VARCHAR2(64) | 信息来源（如：ORADEBUG HANGANALYZE）。 |
4. 相关视图与基表
-
相关动态性能视图：
V$HANG_INFO： 最直接的相关视图。通过CHAIN_ID和SESSION_ID进行关联。HANG_INFO展示拓扑，HANG_SESSION_INFO展示节点详情。V$SESSION：V$HANG_SESSION_INFO可以看作是挂起分析时的一个V$SESSION的超集快照，包含了更多诊断细节。V$LOCK：CURRENT_QUEUES字段的信息可以与V$LOCK视图关联，以获取锁的更多属性（如模式、请求时间等）。V$LATCH/V$LATCHHOLDER： 与CURRENT_LATCHES字段相关，用于查看闩锁的详细信息。V$SQL： 通过SQL_ID关联，获取导致问题或正在被阻塞的SQL语句的完整文本。V$PROCESS： 通过PROCESS_ID关联，获取操作系统进程的详细信息。
-
基表（Underlying Base Table）：
- 与
V$HANG_INFO类似，V$HANG_SESSION_INFO没有持久化的基表。 - 它的数据是在执行
ORADEBUG HANGANALYZE命令时，由数据库诊断进程（DIAG）动态捕获并填充到内存中的。 - 诊断进程会遍历所有会话，不仅记录它们的关系，还会为每个会话拍摄一张详细的“状态快照”。这些快照数据被临时存放在SGA的某个区域，并通过
V$HANG_SESSION_INFO视图暴露出来。 - 实例重启或新的 hang analyze 操作会覆盖之前的数据。
- 与
5. 底层详细原理
-
数据捕获机制：
- 当
ORADEBUG HANGANALYZE被触发时，数据库会尝试以一种“冻结”系统状态的方式，快速、一致地收集所有会话的详细信息。 - 这个过程包括：
- 遍历会话列表： 获取每个会话的核心结构（类似于
V$SESSION的内容）。 - 挖掘深层状态： 深入会话结构，提取其当前持有的资源列表（锁、闩锁、互斥量）。这部分信息在常规视图中可能不会直接显示，或者需要关联多个视图才能获得。
- 记录SQL上下文： 捕获SQL地址、哈希值、PL/SQL堆栈等信息。
- 打时间戳： 记录采集所有这一切信息的时间点 (
DETECTION_TIME)。
- 遍历会话列表： 获取每个会话的核心结构（类似于
- 当
-
与 Hang Analyze 流程的集成：
V$HANG_INFO和V$HANG_SESSION_INFO的生成是同一个流程的两个输出。- 步骤一：收集数据。DIAG进程收集所有会话的详细信息（用于填充
V$HANG_SESSION_INFO）。 - 步骤二：分析关系。基于收集到的数据（特别是每个会话的
WAIT_EVENT和CURRENT_QUEUES等信息），分析进程构建阻塞图（用于填充V$HANG_INFO）。 - 步骤三：输出结果。将分析结果和详细数据分别写入两个视图和跟踪文件。
-
信息的价值：
CURRENT_QUEUES： 直接告诉你一个会话持有什么锁。如果看到一个会话持有TX锁（事务锁）且另一个会话在等待enq: TX - row lock contention，那么阻塞关系就铁证如山了。CURRENT_LATCHES： 直接指出会话持有了哪个闩锁，这对于诊断内存结构争用（如共享池、库缓存）至关重要。SQL_ADDRESS/SQL_HASH_VALUE： 即使在极端情况下SQL_ID无法解析，这些更底层的地址信息也能最终定位到SQL文本。
6. 相关知识点介绍
-
ORADEBUG HANGANALYZE的级别：LEVEL 3： 最常用的级别，收集足够的信息填充V$HANG_INFO和V$HANG_SESSION_INFO。LEVEL 4或更高： 收集更多信息，包括系统状态转储（systemstate dump），数据量巨大，除非Oracle支持人员要求，否则慎用。
-
系统状态转储（Systemstate Dump）：
- 这是一个比 hang analyze 更重量级的诊断工具。它会将整个Oracle实例的内存状态（包括所有会话、进程、队列、缓冲区等）完整地转储到跟踪文件中。
V$HANG_SESSION_INFO可以看作是系统状态转储中关于会话信息的精华摘要。
-
诊断的思维模式：
- 发现症状： 系统慢，会话卡住。
- 执行分析：
ORADEBUG HANGANALYZE 3。 - 查看拓扑： 查询
V$HANG_INFO，找到阻塞链的根（root blocker）。 - 深挖根因： 查询
V$HANG_SESSION_INFO，用WHERE SESSION_ID = <root_sid>查看根阻塞者的详细信息。重点看CURRENT_QUEUES,SQL_ID,WAIT_EVENT。 - 采取行动： 根据分析结果，决定是kill会话、优化SQL、还是调整资源。
7. 常用查询 SQL
1. 查看阻塞链中所有会话的详细信息（核心查询）
在执行 ORADEBUG HANGANALYZE 3 后运行。
SELECT chain_id,
session_id,
serial#,
blocking_session,
status,
state,
wait_event,
current_queues, -- 关键字段
current_latches, -- 关键字段
sql_id,
module,
program
FROM v$hang_session_info
ORDER BY chain_id, session_id;
2. 聚焦于阻塞链的根源（Root Blocker）
SELECT *
FROM v$hang_session_info hsi
WHERE session_id IN (
SELECT blocking_session
FROM v$hang_session_info
WHERE blocking_session IS NOT NULL
MINUS
SELECT session_id
FROM v$hang_session_info
WHERE blocking_session IS NOT NULL
)
ORDER BY chain_id;
-- 这个查询找到那些阻塞别人但自己不被任何其他会话阻塞的根源会话。
3. 查找持有特定类型锁的会话（例如，TX事务锁）
SELECT chain_id, session_id, serial#, current_queues, sql_id, program
FROM v$hang_session_info
WHERE current_queues LIKE '%TX%' -- 查找持有事务锁的会话
AND current_queues IS NOT NULL;
4. 关联 V$SQL 获取阻塞者正在执行的SQL文本
SELECT hsi.chain_id,
hsi.session_id,
hsi.blocking_session,
hsi.wait_event,
hsi.current_queues,
s.sql_text
FROM v$hang_session_info hsi
LEFT JOIN v$sql s ON hsi.sql_id = s.sql_id AND hsi.sql_child_number = s.child_number
WHERE hsi.chain_id = 1 -- 指定阻塞链ID
ORDER BY hsi.session_id;
5. 诊断非锁引起的挂起（查看闩锁和互斥量）
SELECT chain_id,
session_id,
current_latches,
current_mutexes,
wait_event,
sql_id
FROM v$hang_session_info
WHERE current_latches IS NOT NULL OR current_mutexes IS NOT NULL;
总结
V$HANG_SESSION_INFO 是Oracle数据库挂起分析体系中的**“显微镜”**。它将 V$HANG_INFO 提供的宏观阻塞图，细化到了每一个参与会话的微观状态。
它的核心价值在于提供了无可辩驳的证据链：
- 锁证据：
CURRENT_QUEUES直接显示会话持有的锁，坐实阻塞关系。 - 资源证据：
CURRENT_LATCHES和CURRENT_MUTEXES揭示了底层资源争用的元凶。 - 上下文证据：
SQL_ID,PLSQL_*字段精确指出了导致问题的代码。
掌握 V$HANG_INFO 和 V$HANG_SESSION_INFO 的联合使用方法，是DBA解决最棘手的数据库性能僵局（Hang）的最高阶技能。它使DBA能够从“系统好像卡住了”的模糊感知，精准地推进到“是会话A持有的TX锁阻塞了会话B，而会话A正在执行某个UPDATE语句”的精确诊断，从而采取最有效的解决措施。
欢迎关注我的公众号《IT小Chen》
扫一扫
2364
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
