面试宝典: Oracle数据库enq:TX - row lock contention 等待事件处理过程

最新推荐文章于 2025-09-01 20:39:25 发布

原创最新推荐文章于 2025-09-01 20:39:25 发布 · 1k 阅读

21 ·

CC 4.0 BY-SA版权

文章标签：

#数据库 #面试 #oracle

AI辅助_面试宝典专栏收录该内容

584 篇文章

订阅专栏

在这里插入图片描述
好的，我们来深入解析 Oracle 数据库中的 enq: TX - row lock contention 等待事件。这是 OLTP 系统中最常见、最核心的并发控制等待事件，直接关系到行级数据的并发修改，是数据库性能调优的重中之重。

1. 什么是 `enq: TX - row lock contention` 等待事件？

本质： 它表示一个会话正在等待获取特定数据行的 TX (Transaction Enqueue / Row Lock)。当一个会话尝试修改（UPDATE, DELETE）或显式锁定（SELECT ... FOR UPDATE）某一行数据时，如果该行已经被另一个会话锁定且尚未提交，就会发生这种等待。
名字解析：
- enq:：表示这是一个 Enqueue 等待事件。
- TX： Enqueue 的类型标识符。T 代表 Transaction，X 代表模式（Mode），表示这是一种事务锁，具体用于保护行级数据。
- row lock contention：明确表示是行锁争用。
核心特征：
- 行级粒度： 锁定的对象是单行数据（或索引条目对应的行）。
- 写操作核心： 由 INSERT, UPDATE, DELETE, SELECT ... FOR UPDATE 操作触发。INSERT 锁定新插入的行（防止唯一冲突等），其他操作锁定目标行。
- 互斥性 (Exclusive)： TX 锁是独占锁 (Exclusive Lock)。一次只能有一个会话持有某一行上的 TX 锁（用于修改或 FOR UPDATE）。
- 持有时间： TX 锁在事务开始时（执行第一条 DML 语句）获取，并在事务结束（COMMIT 或 ROLLBACK）时释放。这是 TX 锁最关键的属性，也是导致阻塞的根本原因。
- 与 TM 锁的关系： 执行 DML 时，会话会先获取目标表的 TM 锁（通常是 RX 模式），然后尝试获取要修改的具体行的 TX 锁。TM 是表级意图锁，TX 是行级锁。
- 队列机制： 如果一行被锁定，后续请求该行 TX 锁的会话会排队等待。Oracle 使用队列 (Enqueue) 机制管理这些等待者，确保公平性（默认 FIFO）。
等待参数：
- P1： Enqueue 的名称和模式。格式为 name|mode。对于 TX，name 是 TX，mode 通常是 6（独占模式 eXclusive - X）。
- P2： Enqueue 标识符 1 (id1)。对于 TX Enqueue，id1 表示 undo segment number + slot 的一部分（通常需要结合 P3 计算事务地址 USN.SLT）。
- P3： Enqueue 标识符 2 (id2)。对于 TX Enqueue，id2 表示 sequence（序列号），结合 P2 可以唯一标识一个事务（USN.SLT.SEQ - Undo Segment Number, Slot, Sequence），也标识了该事务所持有的所有行锁。id2 的值也是被锁定行的 rowid 的一部分（具体是 rowid 中的 seq 或 rfile+block+row 的编码）。

2. 产生的过程

当一个会话尝试修改或锁定一行数据时：

发起 DML/查询： 会话执行 UPDATE, DELETE, SELECT ... FOR UPDATE, 或 INSERT（锁定新行）语句。
确定目标行： Oracle 解析语句，定位到要修改或锁定的具体行（通过 rowid 或索引扫描）。
请求 TX Enqueue： 会话尝试以独占模式 (X, mode 6) 获取保护该目标行的 TX Enqueue。
检查锁状态：
- 行未被锁定： 如果该行当前没有任何会话持有 TX 锁（即未被其他活动事务修改或锁定），会话立即成功获取 TX 锁。然后可以修改该行（对于 DML）或返回该行数据（对于 SELECT FOR UPDATE）。
- 行已被锁定 (争用)： 如果另一个会话已经持有该行的 TX 锁（因为它正在修改该行或已执行 SELECT FOR UPDATE 且未提交），当前会话无法立即获取锁。
进入等待： 会话进入 enq: TX - row lock contention 等待状态，并排队等待该行的 TX Enqueue（默认 FIFO 顺序）。在等待期间，会话处于阻塞状态。
持有者提交/回滚： 持有该行 TX 锁的会话执行 COMMIT 或 ROLLBACK，释放其持有的所有 TX 锁（包括该行的锁）。
唤醒等待者： 等待队列中的第一个会话（按排队顺序）被唤醒，成功获得该行的 TX 锁。
继续操作： 该会话获得锁后：
- 对于 UPDATE/DELETE：修改该行数据。
- 对于 SELECT FOR UPDATE：返回该行数据（现在已锁定）。
- 对于 INSERT：（如果因唯一约束等需要锁定新行）继续插入逻辑。
事务结束释放锁： 当该会话执行 COMMIT 或 ROLLBACK 时，它持有的 TX 锁被释放。

3. 哪些场景会触发 `enq: TX - row lock contention`

核心场景是多个会话试图修改或锁定同一行数据，且它们的操作在时间上重叠（一个未提交，另一个就发起请求）：

高并发更新热点行：
- 最典型场景： 多个会话同时尝试更新数据库中的同一行数据。例如：
  - 更新计数器（如 UPDATE counters SET value = value + 1 WHERE id = 'page_views';）。
  - 修改热门商品的库存 (UPDATE inventory SET stock = stock - 1 WHERE product_id = 'hot_item';)。
  - 更新用户账户余额 (UPDATE accounts SET balance = balance - :amt WHERE acct_id = :id;)。
SELECT FOR UPDATE 阻塞 DML：
- 会话 A 执行 SELECT ... FROM table WHERE ... FOR UPDATE 查询并锁定某些行，但长时间不提交。
- 会话 B 尝试 UPDATE 或 DELETE 会话 A 锁定的同一行数据，会被阻塞。
未提交的修改阻塞后续操作：
- 会话 A 执行 UPDATE 或 DELETE 修改了某些行，但长时间不提交。
- 会话 B 尝试修改会话 A 修改过的同一行数据（UPDATE/DELETE）或尝试锁定它（SELECT ... FOR UPDATE），会被阻塞。
- 会话 C 尝试 INSERT 一行，如果该 INSERT 因唯一约束等原因需要检查/锁定与会话 A 修改相关的行（如外键引用），也可能被阻塞（见第 5 点）。
外键约束与未提交的父表操作：
- 核心问题： 当存在外键约束，且父表行被修改（UPDATE 主键/唯一键或 DELETE）但未提交时，在子表上尝试修改可能引用该父表行的数据会导致阻塞。
- 过程 (更复杂)：
  1. 会话 A 删除父表 PARENT 中的一行（或在唯一键列上更新）但未提交。
  2. 会话 B 尝试在子表 CHILD 上 INSERT 一行，该行恰好引用了会话 A 正在删除/修改的父表行。
  3. 为了确保参照完整性，Oracle 需要检查父表行是否存在且有效。
  4. 由于会话 A 的事务未提交，父表行的状态不确定（可能最终提交删除，也可能回滚）。
  5. 会话 B 必须等待会话 A 的事务结束（提交或回滚）才能确定父表行的最终状态，从而决定子表的 INSERT 是否违反外键约束。此时会话 B 等待 enq: TX - row lock contention，锁定的对象是父表行（的 TX 锁）。
- DELETE 子表行：
  1. 会话 A 删除父表行未提交。
  2. 会话 B 尝试删除子表中引用该父表行的子行。
  3. 会话 B 同样需要等待会话 A 提交以确认父表行是否被删除（如果父表行最终被删除，子行删除可以继续；如果回滚，父表行存在，子行删除也可能继续，但状态需确认）。
- 影响： 父表上未提交的 DML 会阻塞子表上相关的 DML。即使子表外键有索引，也会发生这种等待！ 索引只能优化检查速度，但不能改变在未提交事务时需要等待的事实。
唯一约束 / 主键冲突：
- 会话 A INSERT 一行，该行的主键或唯一键值 X 已存在于表中但会话 A 未提交。
- 会话 B 尝试 INSERT 另一行，其主键或唯一键值也恰好是 X。
- 会话 B 会立即失败（ORA-00001）吗？不会！ 因为会话 A 的事务未提交，其插入的行是否最终可见尚未确定（可能回滚）。会话 B 必须等待会话 A 的事务结束，以确定键值 X 是否最终被占用。此时会话 B 等待 enq: TX - row lock contention，锁定的对象是索引条目或表块中与会话 A 新插入行相关的锁。
位图索引更新： 更新涉及位图索引的列时，锁定粒度是位图段（包含多个行），可能引发类似行锁的争用（有时也报告为 TX 争用）。
递归事务： 某些 Oracle 内部操作（如空间管理递归事务）也可能持有行锁并导致阻塞。

4. 可能的原因

enq: TX - row lock contention 的出现意味着行级并发修改发生了冲突。主要原因包括：

A. 应用设计问题 (根本原因)：
- 热点行更新： 应用逻辑设计导致大量并发会话集中更新少数几行（如计数器、库存、账户余额）。这是最常见的原因。
- 长事务： 应用执行 DML 后长时间不提交事务（包含用户交互、批量处理未分批提交、事务包含无关操作），导致行锁被长时间持有。
- 过度使用 SELECT FOR UPDATE： 不必要地使用 SELECT ... FOR UPDATE 锁定行，且锁定时间过长。
- 锁顺序问题： 应用不同部分以不同顺序访问和锁定相同资源（行），容易导致死锁（虽然死锁会立即报错，但之前可能经历短暂 TX 争用）。
B. 用户行为：
- 用户通过 SQL*Plus 或其他工具执行 DML 后忘记提交。
- 应用出现未处理的异常，导致事务未正确提交或回滚。
- 用户会话异常断开（如网络中断），Oracle 需要一段时间（DISTRIBUTED_LOCK_TIMEOUT）才能检测并回滚事务，期间锁仍持有。
C. 外键约束：
- 父表上的未提交 DML (DELETE/UPDATE PK/UK) 阻塞子表上引用相关行的 DML (INSERT/UPDATE/DELETE)，如第 3 部分第 4 点所述。
D. 唯一/主键约束：
- 并发 INSERT 尝试插入相同主键/唯一键值，且第一个插入者未提交，如第 3 部分第 5 点所述。
E. 索引问题：
- 位图索引： 更新位图索引列时锁定范围大，易发争用。
- 低效索引： UPDATE/DELETE 的 WHERE 条件低效，导致扫描或锁定过多行。
F. 数据库参数：
- DISTRIBUTED_LOCK_TIMEOUT：设置过大（默认 60 秒）会延长检测和清理僵死事务（持有锁）的时间。适当减小（如 30 秒）可以更快释放锁，但可能增加 ORA-02049 风险。

5. 详细排查过程

排查 enq: TX - row lock contention 的核心是：定位阻塞链 -> 识别被锁定的行和持有者 -> 分析根本原因（热点行？长事务？外键？）-> 针对性解决。

步骤 1: 确认问题与范围

识别 Top Wait Event: 查看 AWR/ASH 报告 (awrrpt.sql, ashtop.sql)。确认 enq: TX - row lock contention 是否在系统级别或特定时间段是主要等待事件。记录其 Total Wait Time (s) 和 Avg Wait (ms)。
确定影响范围： 是整个数据库？特定表？特定业务模块？使用 ASH 报告 (ashrpt.sql) 或查询 gv$active_session_history / dba_hist_active_sess_history，按 sql_id, module, action, user_id, current_obj# 等维度聚合等待事件和时间。特别关注 sql_id 是否是特定的更新语句或 SELECT FOR UPDATE。
关联负载类型： 检查 AWR 报告的 “Load Profile” 部分。高 Transactions, 高 Executions, 高 Rollbacks 可能与锁争用相关。

步骤 2: 定位阻塞链、被锁行与持有者 (关键步骤)

目标：找到谁在等待（Waiter）、谁在阻塞（Blocker）、阻塞了哪一行（Row）。

使用 DBA_HIST_ACTIVE_SESS_HISTORY (ASH) / GV$ACTIVE_SESSION_HISTORY (实时)：

-- 查找经历 TX 行锁等待的会话及其阻塞者
SELECT
  ash.session_id AS waiter_sid, ash.session_serial# AS waiter_serial#,
  ash.user_id AS waiter_user_id, u1.username AS waiter_username,
  ash.sql_id AS waiter_sql_id, ash.sql_opname AS waiter_op, -- 等待者 SQL 操作
  ash.blocking_session AS blocker_sid, ash.blocking_session_serial# AS blocker_serial#,
  ash.blocking_inst_id AS blocker_inst_id, -- RAC 中阻塞实例 ID
  s2.username AS blocker_username, s2.osuser AS blocker_osuser, s2.machine AS blocker_machine,
  s2.program AS blocker_program, s2.module AS blocker_module, s2.action AS blocker_action,
  s2.sql_id AS blocker_sql_id, s2.prev_sql_id AS blocker_prev_sql_id, -- 阻塞者 SQL
  s2.status AS blocker_status, TO_CHAR(s2.logon_time, 'YYYY-MM-DD HH24:MI:SS') AS blocker_logon,
  s2.last_call_et AS blocker_idle_sec, -- 阻塞者空闲时间 (秒)，长事务指示器!
  o.owner AS object_owner, o.object_name AS object_name, o.object_type AS object_type,
  ash.row_wait_obj#, ash.row_wait_file#, ash.row_wait_block#, ash.row_wait_row#, -- 被等待的行标识
  COUNT(*) AS total_waits, SUM(ash.time_waited)/1000 AS total_wait_sec
FROM dba_hist_active_sess_history ash -- 或用 gv$active_session_history 查实时
JOIN dba_users u1 ON (ash.user_id = u1.user_id)
LEFT JOIN gv$session s2 ON (ash.blocking_inst_id = s2.inst_id AND ash.blocking_session = s2.sid AND ash.blocking_session_serial# = s2.serial#) -- 关联阻塞者会话
LEFT JOIN dba_objects o ON (ash.row_wait_obj# = o.object_id) -- 关联被锁行所在对象
WHERE ash.event = 'enq: TX - row lock contention'
AND ash.sample_time BETWEEN ... AND ... -- 指定问题时间段
GROUP BY ash.session_id, ash.session_serial#, ash.user_id, u1.username,
         ash.sql_id, ash.sql_opname, ash.blocking_session, ash.blocking_session_serial#,
         ash.blocking_inst_id, s2.username, s2.osuser, s2.machine, s2.program, s2.module, s2.action,
         s2.sql_id, s2.prev_sql_id, s2.status, s2.logon_time, s2.last_call_et,
         o.owner, o.object_name, o.object_type,
         ash.row_wait_obj#, ash.row_wait_file#, ash.row_wait_block#, ash.row_wait_row#
ORDER BY total_waits DESC, total_wait_sec DESC;

核心输出：
- 等待者 (Waiter)： waiter_sid, waiter_serial#, waiter_username, waiter_sql_id, waiter_op (操作类型，如 UPDATE)。
- 阻塞者 (Blocker)： blocker_sid, blocker_serial#, blocker_username, blocker_osuser, blocker_machine, blocker_program, blocker_module, blocker_action, blocker_sql_id, blocker_prev_sql_id, blocker_status, blocker_logon, blocker_idle_sec (关键！长事务标志)。
- 被锁对象： object_owner, object_name, object_type (通常是 TABLE)。
- 被锁行地址： row_wait_obj#, row_wait_file#, row_wait_block#, row_wait_row#。这 4 个值唯一标识了被争用的那一行！
- 等待统计。

解析被锁行地址： 使用 row_wait_file#, row_wait_block#, row_wait_row# 定位具体的行。

SELECT *
FROM DBMS_ROWID.ROWID_CREATE(1, -- Data Object Number 通常为 1，或从 dba_objects 的 data_object_id 获取
                             &row_wait_obj#, -- 来自 ASH
                             &row_wait_file#, -- 来自 ASH
                             &row_wait_block#, -- 来自 ASH
                             &row_wait_row#) AS rowid_value; -- 来自 ASH

得到一个有效的 ROWID。然后可以用这个 ROWID 查询被锁定的行：

SELECT * FROM &schema_name.&table_name WHERE rowid = '&rowid_value';
-- 或者更通用 (需要知道对象名)
SELECT * FROM &schema_name.&table_name
WHERE DBMS_ROWID.ROWID_BLOCK_NUMBER(rowid) = &row_wait_block#
  AND DBMS_ROWID.ROWID_ROW_NUMBER(rowid) = &row_wait_row#
  AND DBMS_ROWID.ROWID_RELATIVE_FNO(rowid) = &row_wait_file#;

重要： 查询被锁定的行需要访问该块。如果阻塞者持有 TX 锁，查询可能也会被阻塞（等待 buffer busy waits 或 read by other session）！谨慎操作，最好在低峰期或结合其他信息分析。
查看这行数据的内容，理解为什么它是热点（如计数器 ID、热门商品 ID、特定账户 ID）。

深入分析阻塞者会话：
- blocker_idle_sec 值大： 强烈表明阻塞会话有长时间未提交的事务。
- 查看阻塞者 SQL：
```
-- 当前 SQL
SELECT sql_text FROM v$sql WHERE sql_id = '&blocker_sql_id';
-- 上一个 SQL (如果当前为空闲)
SELECT sql_text FROM v$sql WHERE sql_id = '&blocker_prev_sql_id';
```
  - 分析阻塞者在做什么：是否是更新热点行的语句？是否是 SELECT FOR UPDATE？是否涉及父表/子表操作？
- 检查阻塞者事务状态：
```
SELECT t.start_time, t.status, t.xid, t.used_ublk, t.used_urec, t.log_io, t.phy_io
FROM v$transaction t
JOIN v$session s ON (t.addr = s.taddr)
WHERE s.sid = &blocker_sid
  AND s.serial# = &blocker_serial#;
```
  - 如果返回结果，说明阻塞者有未提交事务 (t.status = 'ACTIVE')。used_ublk (使用的撤销块数) 和 used_urec (使用的撤销记录数) 反映事务大小和修改量。
  - 如果无结果，说明阻塞者没有未提交事务（可能是 SELECT FOR UPDATE 持有锁但无事务？实际 SELECT FOR UPDATE 会启动事务）。或者 ASH 信息有延迟。
使用 Oracle 提供的锁树脚本 (实时)： 运行 @?/rdbms/admin/utllockt.sql。这个脚本会清晰展示当前的锁等待关系（树状结构），标明阻塞者、等待者、被锁对象和模式（TX in mode 6）。非常直观。

步骤 3: 分析根本原因

根据步骤 2 收集的信息判断：

热点行更新： 多个等待者/阻塞者集中在更新同一行或少数几行（通过 row_wait_* 字段或查询出的行内容识别）。阻塞者的 SQL 是更新语句。
长事务： 阻塞者 last_call_et 很大，有未提交事务 (V$TRANSACTION 确认)，执行的 SQL 可能是较早之前的 DML。
SELECT FOR UPDATE 未提交： 阻塞者的 SQL 是 SELECT ... FOR UPDATE 或 prev_sql_id 对应此类语句，且会话状态可能为 INACTIVE 但持有锁。
外键相关：
- 被锁对象 (object_name) 是子表，阻塞者正在操作父表（通过 blocker_sql_id 或 blocker_prev_sql_id 识别为父表的 DELETE/UPDATE）。
- 或者，被锁对象是父表，阻塞者正在操作子表（较少见，但子表 DML 也可能因检查父表状态而等待父表行锁）。
- 使用步骤 2 中的外键查询（参考 enq: TM - contention 部分）确认约束关系。注意：即使外键有索引，这种等待也可能发生！
唯一/主键冲突：
- 等待者的操作是 INSERT。
- 被锁对象是带有主键/唯一约束的表。
- 阻塞者的操作也是 INSERT 到同一表（或未提交的 INSERT）。
- 尝试插入的键值可能相同（需要结合应用逻辑或日志推断）。
位图索引： 被更新列上有位图索引，且等待集中发生在更新这些列时。

步骤 4: 综合分析与解决方案

根据根本原因采取针对性措施：

1. 解决热点行更新：
- 应用逻辑重构：
  - 序列化访问： 使用数据库序列 (SEQUENCE) 或应用层原子计数器替代直接在行上更新计数器。
  - 批量提交 / 减少竞争： 如果必须更新行，尝试合并更新（如应用层累加后批量更新）、增加随机延迟、使用队列异步处理。
  - 乐观锁： 使用版本号或时间戳字段，在 UPDATE 的 WHERE 子句中检查数据未被他人修改（UPDATE ... SET ..., version = version + 1 WHERE ... AND version = :old_version）。冲突时应用层重试或报错，避免数据库排队等待。适用于冲突不太频繁的场景。
  - 分解热点： 将一个热点行拆分成多行（如将全局计数器拆分成多个分片计数器）。
- Oracle 特性：
  - SELECT FOR UPDATE SKIP LOCKED： 只锁定未被锁定的行，跳过已锁定的行。适用于处理队列等场景。
  - SELECT FOR UPDATE NOWAIT： 尝试锁定行，如果行已被锁定，立即报错 (ORA-00054)，而不是等待。应用层捕获错误并重试或处理。适用于预期冲突少且需快速响应的场景。
  - DBMS_LOCK： 使用显式的、应用定义的锁（如 REQUEST, CONVERT）在更高层次协调对共享资源的访问。
2. 解决长事务：
- 应用优化：
  - 及时提交： 确保 DML 操作后尽快提交事务。避免在事务中包含用户交互或长时间操作。
  - 小批量提交： 对于批量操作，分成小批次处理并提交。
  - 事务设计： 重新设计业务流程，缩短事务长度，将非数据库操作移出事务。
  - 设置超时： 使用 RESOURCE_LIMIT 和 PROFILES 设置 IDLE_TIME 或应用层设置事务超时，自动终止空闲会话或回滚长事务。
- 监控与处理：
  - 定位并通知： 找到长事务持有者（V$SESSION/V$TRANSACTION），通知用户提交。
  - 终止会话 (谨慎)： 对于无响应或僵死的长事务会话，使用 ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE; 终止。评估影响（事务会回滚）！
3. 优化 SELECT FOR UPDATE：
- 评估必要性： 是否真的需要行级锁？是否可以用只读查询加应用层校验？
- 缩短持有时间： 锁定后立即处理，尽快提交。
- 使用 NOWAIT / SKIP LOCKED： 避免阻塞。
4. 处理外键相关等待：
- 此问题无法通过索引完全避免！ 索引只能加速检查，不能消除对未提交父行状态的等待。
- 优化父表事务： 确保修改父表（尤其是删除或更新主键）的操作快速提交。避免在父表上执行长事务。
- 调整业务逻辑： 如果可能，改变操作顺序，先提交父表变更，再进行子表操作。
- 延迟约束检查 (慎用)： 对于 INSERT，可考虑将约束设为 DEFERRABLE INITIALLY DEFERRED。但这将检查推迟到提交时，可能带来其他复杂性和错误风险。不推荐常规使用。
5. 处理唯一/主键冲突：
- 应用层生成键： 使用序列 (SEQUENCE) 生成唯一主键，避免冲突。
- INSERT ... ON DUPLICATE KEY UPDATE (如果支持)： 处理可能的冲突（非标准 Oracle）。
- 先查询后插入 (有风险)： 应用层先 SELECT 检查键是否存在，不存在再 INSERT。存在竞争条件风险（SELECT 后到 INSERT 前可能被其他会话插入）！ 需配合 SERIALIZABLE 隔离级别或重试机制。
6. 位图索引问题：
- 评估必要性： 位图索引适用于低基数列。如果列更新频繁或基数高，考虑改用 B-Tree 索引。
- 避免更新位图索引列： 如果可能，减少对这些列的更新。
7. 参数调整：
- DISTRIBUTED_LOCK_TIMEOUT (默认 60)： 减小此参数（如设 30）可以让 Oracle 更快地检测和清理僵死分布式事务或断开会话持有的锁，减少阻塞时间。但设置过小可能增加 ORA-02049 错误（分布式事务超时）。谨慎调整。
```
ALTER SYSTEM SET DISTRIBUTED_LOCK_TIMEOUT = 30 SCOPE=BOTH;
```

关键诊断视图与脚本总结

定位等待与会话：
- V$SESSION_WAIT / V$SESSION (EVENT, STATE, WAIT_TIME, SECONDS_IN_WAIT, ROW_WAIT_OBJ#, ROW_WAIT_FILE#, ROW_WAIT_BLOCK#, ROW_WAIT_ROW#)
- V$ACTIVE_SESSION_HISTORY (实时) / DBA_HIST_ACTIVE_SESS_HISTORY (历史 AWR) - 最强大
- V$LOCK / GV$LOCK (类型=‘TX’, LMODE, REQUEST, BLOCK, CTIME)
- DBA_HIST_SYSTEM_EVENT / AWR 报告
分析阻塞链：
- V$SESSION (BLOCKING_INSTANCE, BLOCKING_SESSION, BLOCKING_SESSION_STATUS)
- GV$LOCK (BLOCK)
- 脚本： @?/rdbms/admin/utllockt.sql (Oracle 提供的锁树可视化脚本)
获取 SQL 信息：
- V$SQL / V$SQLTEXT / DBA_HIST_SQLTEXT
检查事务状态：
- V$TRANSACTION (连接 V$SESSION.TADDR, START_TIME, STATUS, USED_UBLK, USED_UREC)
分析对象：
- DBA_OBJECTS (由 OBJECT_ID 定位对象名)
分析外键：
- DBA_CONSTRAINTS, DBA_CONS_COLUMNS
参数：
- V$PARAMETER (DISTRIBUTED_LOCK_TIMEOUT)