一、手册使用说明

1.1 适用场景

• 生产库出现会话阻塞、业务卡顿、事务超时
• 监控工具（如OEM、Zabbix）告警“锁等待次数突增”“Concurrency等待占比超20%”
• 出现高风险锁事件（如enq: CI - contention、enq: TX - allocate ITL entry）

1.2 前置条件

• 具备SYSDBA或SELECT ANY DICTIONARY权限（需查询v$动态视图）
• 已安装Oracle客户端（如SQL Developer、PL/SQL Developer）或可访问数据库命令行
• 了解业务核心表（如订单表、支付表）的表名与用途

二、快速诊断四步法

第一步：识别当前锁等待会话（2分钟）

目标：快速找到“等待锁的会话”和“持有锁的会话”，明确阻塞关系。

执行SQL

SELECT -- 等待方信息 w.sid AS 等待会话ID, w.serial# AS 等待会话序列号, w.username AS 等待用户, w.program AS 等待进程, w.machine AS 等待机器, w.event AS 锁等待事件, -- 持有方信息 h.sid AS 持有会话ID, h.serial# AS 持有会话序列号, h.username AS 持有用户, -- 锁详情 l.type AS 锁类型, l.id1 AS 锁资源ID1, l.id2 AS 锁资源ID2, o.object_name AS 涉及对象名, o.object_type AS 对象类型 FROM v$session w JOIN v$lock l ON w.sid = l.sid LEFT JOIN v$session h ON l.block = 1 AND l.id1 = (SELECT id1 FROM v$lock WHERE sid = h.sid AND block = 1) LEFT JOIN dba_objects o ON l.id1 = o.object_id WHERE w.wait_class = 'Concurrency' -- 仅筛选并发类锁等待 AND w.status = 'ACTIVE' -- 排除非活跃会话 ORDER BY w.event, w.sid;

关键判断

• 若持有会话ID不为空：存在明确的阻塞源，优先处理持有会话
• 若涉及对象名不为空：锁定对象为表/索引，需关联业务判断影响范围
• 若锁等待事件包含enq:前缀：属于Oracle内置锁，需对照“高风险锁速查表”处理

第二步：分析锁等待链（3分钟）

目标：排查是否存在“多会话循环等待”（死锁）或“长链阻塞”（A等B、B等C）。

执行SQL（死锁检测）

-- 1. 查看最近死锁信息（需数据库开启死锁跟踪） SELECT dt.username, dt.sid, dt.serial#, dt.object_name, dt.mode_held, dt.mode_requested, dt.lock_type, dt.deadlock_time FROM dba_deadlocks dt ORDER BY dt.deadlock_time DESC; -- 2. 查看完整锁等待链 WITH lock_chain AS ( SELECT l.sid AS waiter_sid, l.block AS holder_sid, l.type AS lock_type, l.id1, l.id2, 1 AS level FROM v$lock l WHERE l.request > 0 -- 等待锁的会话 UNION ALL SELECT l.sid AS waiter_sid, l.block AS holder_sid, l.type AS lock_type, l.id1, l.id2, lc.level + 1 AS level FROM v$lock l JOIN lock_chain lc ON l.sid = lc.holder_sid WHERE l.request > 0 ) SELECT lc.level AS 阻塞层级, lc.waiter_sid AS 等待方ID, s1.username AS 等待方用户, lc.holder_sid AS 持有方ID, s2.username AS 持有方用户, lc.lock_type, lc.id1, lc.id2 FROM lock_chain lc LEFT JOIN v$session s1 ON lc.waiter_sid = s1.sid LEFT JOIN v$session s2 ON lc.holder_sid = s2.sid ORDER BY lc.level DESC;

关键判断

• 若阻塞层级超过3：属于长链阻塞，需从顶层持有会话开始处理
• 若dba_deadlocks有结果：存在死锁，需优先终止“非核心业务”的持有会话

第三步：定位锁等待根因（3分钟）

目标：根据锁类型和关联对象，判断是“参数配置问题”“SQL优化问题”还是“业务逻辑问题”。

核心根因判断逻辑

关键操作

• 若涉及表/索引：用dba_tables/dba_indexes查ITL、分区、碎片化情况
• 若涉及RAC：用gv$session/gv$lock查跨节点阻塞（加INST_ID字段）
• 若涉及REDO：用v$log/v$archive_dest_status查归档是否正常

第四步：评估业务影响（2分钟）

目标：判断锁等待是否影响核心业务，决定处理优先级。

执行SQL（关联业务会话）

SELECT s.sid, s.serial#, s.username, s.program, s.module, -- 业务模块（如“订单系统”“支付接口”） s.action, -- 具体操作（如“下单”“退款”） s.sql_id, -- 执行的SQL ID s.last_call_et AS 等待时长(秒), l.event AS 锁等待事件 FROM v$session s JOIN v$lock l ON s.sid = l.sid WHERE s.wait_class = 'Concurrency' AND s.module IN ('核心订单模块', '支付接口') -- 替换为实际核心业务模块 ORDER BY s.last_call_et DESC;

优先级判断

• 高优先级：核心业务（如支付、下单）阻塞超5分钟，影响用户操作
• 中优先级：非核心业务（如报表、统计）阻塞超30分钟
• 低优先级：内部维护操作（如备份、索引重建）阻塞

三、高风险锁分类诊断速查表

四、应急处理流程

4.1 紧急场景（核心业务阻塞）

1. 终止持有会话（需确认会话无关键事务）：

   -- 先验证会话操作（避免误杀） SELECT sql_text FROM v$sql WHERE sql_id = (SELECT sql_id FROM v$session WHERE sid = 持有会话ID); -- 终止会话（sid=持有会话ID，serial#=持有会话序列号） ALTER SYSTEM KILL SESSION '持有会话ID,持有会话序列号' IMMEDIATE;

2. 释放锁资源：
   • 若为ITL问题：临时调整表/索引INITRANS
   • 若为死锁：通过dba_deadlocks定位后，优先终止非核心会话

4.2 非紧急场景（非核心业务阻塞）

1. 收集诊断数据：
   • 导出AWR报告（锁定时间段）：@$ORACLE_HOME/rdbms/admin/awrrpt.sql
   • 导出ASH报告（实时数据）：@$ORACLE_HOME/rdbms/admin/ashrpt.sql
2. 根源分析：
   • 用AWR报告“Top 5 Timed Events”确认锁等待占比
   • 用ASH报告“Top SQL”定位导致锁等待的SQL语句
3. 优化处理：
   • 优化SQL（如加索引、调整WHERE条件）
   • 调整业务逻辑（如错峰执行高并发操作）

五、注意事项与禁忌

1. 禁止操作：
   • 不确认业务影响时，禁止直接KILL SESSION（可能导致事务回滚、数据不一致）
   • 禁止在 peak 时段修改INITRANS、重建索引（可能引发新锁等待）
2. 必做检查：
   • 终止会话前，需通过v$session.sql_id确认会话执行的SQL是否为“非关键操作”
   • 修改参数（如log_archive_max_processes）前，需记录当前值（便于回滚）
3. 日志留存：
   • 每次锁等待问题处理后，需留存“诊断SQL结果”“AWR/ASH报告”“处理步骤”，形成知识库

附录：常用诊断视图说明