达梦8数据库锁阻塞巡检SQL解析与应用

1. 达梦8数据库锁阻塞巡检SQL解析与应用

作为一名长期奋战在一线的DBA，数据库锁阻塞问题就像悬在头上的达摩克利斯剑。每当业务高峰期来临，系统响应变慢，第一个要排查的就是锁阻塞情况。今天给大家分享一个在达梦8数据库中经过千锤百炼的锁阻塞巡检SQL，这个脚本已经帮我解决了数十次生产环境锁问题。

这个SQL的核心价值在于：

1. 能清晰区分锁持有者(HOLDER)和等待者(WAITER)
2. 直观展示锁模式强度(lmode)
3. 关联出被锁对象和正在执行的SQL片段
4. 结果集可直接用于故障处理决策

2. SQL核心逻辑拆解

2.1 基础表关系与字段含义

先看涉及到的三个关键系统视图：

• v$lock：存储当前所有锁信息
• dba_objects：数据库对象元数据
• v$sessions：活跃会话信息

关键字段说明：

• blocked：标识是否被阻塞('1'表示是)
• lmode：锁模式(数字越大强度越高)
• table_id：被锁对象ID(关联dba_objects.object_id)
• trx_id：事务ID(同一事务的多个锁共享)

2.2 SQL执行流程解析

sql复制SELECT 
  CASE WHEN l.blocked='1' THEN 'WAITER' ELSE 'HOLDER' END AS role,
  s.sess_id,
  l.trx_id, 
  l.lmode,
  NVL(o.object_name,'-') AS object_name,
  SUBSTR(s.sql_text,1,60) AS sql60
FROM (
  SELECT * 
  FROM v$lock
  WHERE TRIM(TRANSLATE(blocked,'01','  ')) IS NULL -- 仅 0 或 1
  AND TRIM(TRANSLATE(table_id ,'0123456789',' ')) IS NULL
) l
LEFT JOIN dba_objects o
  ON TRIM(l.table_id) = TO_CHAR(o.object_id)
JOIN v$sessions s
  ON s.trx_id = l.trx_id
WHERE l.blocked='1' OR l.lmode >= 5
ORDER BY l.trx_id, l.blocked;

执行步骤分解：

1. 从v$lock筛选有效记录（blocked只能是0/1，table_id为纯数字）
2. 关联dba_objects获取对象名称（LEFT JOIN避免漏掉系统锁）
3. 关联v$sessions获取会话信息和SQL片段
4. 筛选出被阻塞的锁(l.blocked='1')或高粒度锁(lmode>=5)
5. 按事务ID和阻塞状态排序输出

关键技巧：使用TRANSLATE+TRIM过滤非法值是达梦特有的写法，比正则表达式更高效

3. 结果集深度解读

执行结果包含6个关键字段：

锁模式强度说明：

• lmode=3：行共享锁(RS)
• lmode=4：行排他锁(RX)
• lmode=5：共享行排他锁(SRX)
• lmode=6：排他锁(X)

4. 实战应用场景

4.1 常规巡检流程

建议每天业务低峰期执行一次，重点关注：

1. 是否存在WAITER记录（表明有阻塞）
2. 高粒度锁(lmode>=5)的持有时间
3. 同一对象上的锁竞争情况

4.2 故障排查步骤

当发现系统响应变慢时：

1. 执行该SQL获取当前锁状态
2. 定位WAITER记录及其对应的HOLDER

   sql复制-- 查找某个WAITER对应的HOLDER
   SELECT * FROM (
     /* 原SQL */
   ) WHERE trx_id = [WAITER记录的trx_id] AND role = 'HOLDER'
   

3. 对比两者的lmode判断是否合理：
   • HOLDER持X锁，WAITER申请X锁 → 死锁可能
   • HOLDER持SRX锁，WAITER申请X锁 → 可能正常

4.3 会话终止操作

确认需要终止会话时：

sql复制-- 需SYSDBA权限执行
CALL SP_CLOSE_SESSION([sess_id]);

重要提醒：终止会话前务必确认该会话没有执行关键事务，避免数据不一致

5. 性能优化实践

5.1 SQL执行计划分析

通过达梦管理工具查看该SQL的执行计划，确保：

1. v$lock访问使用全表扫描（数据量小）
2. dba_objects关联使用object_id索引
3. v$sessions关联使用trx_id索引

5.2 历史锁阻塞分析

建议创建历史表定期存储巡检结果：

sql复制CREATE TABLE lock_block_history AS 
SELECT SYSDATE AS check_time, t.* FROM (
  /* 原SQL */
) t WHERE 1=0;

-- 定期插入数据
INSERT INTO lock_block_history
SELECT SYSDATE, t.* FROM (
  /* 原SQL */
) t;

6. 常见问题解决方案

6.1 结果为空的情况

可能原因：

• 系统确实没有锁竞争（理想状态）
• SQL执行瞬间所有锁已释放
• 权限不足无法查询系统视图

处理方案：

1. 确认当前用户有查询v$lock、v$sessions的权限
2. 在业务高峰期重复执行
3. 结合v$system_event视图检查'enqueue'等待事件

6.2 误杀会话预防

安全操作建议：

1. 终止会话前先记录完整SQL：

   sql复制SELECT sql_text FROM v$sessions WHERE sess_id = [待终止会话ID]
   

2. 在测试环境重现相同场景
3. 使用达梦的锁超时参数替代强制杀会话：

   sql复制-- 设置锁等待超时(秒)
   ALTER SYSTEM SET LOCK_TIMEOUT = 30;
   

6.3 系统锁识别

当object_name显示为"-"时：

1. 可能是达梦内部系统锁
2. 通过table_id关联v$locked_object获取更多信息
3. 通常不需要处理，重启后会自动释放

7. 高级应用技巧

7.1 锁等待链分析

修改SQL实现多级阻塞分析：

sql复制WITH lock_tree AS (
  SELECT 
    l1.trx_id AS top_trx,
    CONNECT_BY_ROOT l1.trx_id AS root_trx,
    LEVEL AS lock_level
  FROM v$lock l1
  CONNECT BY PRIOR l1.trx_id = l1.blocked
  START WITH l1.blocked = '1'
)
SELECT /* 原SQL字段 */, lt.lock_level
FROM /* 原SQL关联 */
JOIN lock_tree lt ON l.trx_id = lt.top_trx

7.2 锁模式转换监控

跟踪锁升级情况：

sql复制SELECT 
  h.sess_id,
  h.object_name,
  h.lmode AS old_mode,
  l.lmode AS new_mode,
  h.sql60
FROM lock_block_history h
JOIN (
  /* 原SQL */
) l ON h.sess_id = l.sess_id AND h.object_name = l.object_name
WHERE h.lmode < l.lmode

8. 达梦锁机制深度解析

达梦采用多粒度锁机制，主要特点：

1. 支持行锁、表锁、页锁等多种粒度
2. 锁兼容矩阵严格遵循ANSI SQL标准
3. 自动检测死锁并选择代价最小的事务回滚

常见锁转换场景：

• 当会话持有大量行锁时会自动升级为表锁
• 长时间未提交的事务可能导致锁堆积
• 大事务操作容易引发锁等待超时

锁优化建议：

1. 事务要短小精悍，及时提交
2. 大批量操作使用分批提交
3. 合理设计索引减少锁冲突

这套锁阻塞巡检SQL在我负责的多个大型达梦数据库环境中表现稳定，特别是在金融核心系统每天处理百万级交易时，帮助快速定位了十余次锁问题。建议DBA同行们将其纳入日常巡检清单，配合达梦自带的锁监控工具使用效果更佳。