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

1. 项目背景与核心价值

在数据库运维工作中，锁阻塞问题就像交通拥堵一样常见却又棘手。达梦8作为国产数据库的代表产品，其锁机制与阻塞场景有着独特的设计特点。这个巡检SQL脚本的诞生，源于我在实际运维中多次遇到的紧急情况——当业务系统突然卡顿，DBA需要快速定位到底是哪个会话阻塞了关键业务表，而手动排查往往要花费大量时间。

这个脚本的价值在于：它能像CT扫描仪一样，快速透视数据库内部的锁等待链条，精准定位阻塞源头。不同于简单的锁查询语句，它通过关联多张系统视图，自动构建阻塞关系树，并输出关键会话信息、SQL文本和等待时长，让DBA能在5分钟内完成过去需要半小时的故障定位。

2. 技术架构解析

2.1 达梦8锁机制特点

达梦8采用多粒度锁机制，包含表级锁（TM）和行级锁（TX）。与Oracle的锁架构类似，但有以下特殊设计：

• 意向锁升级机制：当行锁冲突达到阈值时会自动升级为表锁
• 死锁检测周期：默认60秒检测一次，比MySQL的innodb_deadlock_detect_interval更保守
• 锁超时设置：通过DM.INI中的LOCK_TIMEOUT参数控制（默认无限等待）

2.2 阻塞关系树构建原理

脚本的核心逻辑是通过递归CTE（WITH子句）遍历三张关键视图：

1. V$LOCK：当前持有的锁信息
2. V$SESSION：会话基础信息
3. V$SQL_AREA：SQL文本缓存

关键关联字段是SESSION_ID和BLOCKING_SESSION，通过BLOCKING_SESSION不为空的记录找到阻塞源头，再反向构建出完整的阻塞链条。

3. 完整SQL实现

sql复制WITH BLOCK_TREE AS (
    -- 基础查询：找出所有被阻塞的会话
    SELECT 
        s.SESS_ID,
        s.SQL_TEXT,
        s.STATUS,
        s.LOGON_TIME,
        l.BLOCKED,
        l.BLOCKING_SESS,
        s.USERNAME,
        s.CLIENT_ADDR,
        0 AS LEVEL,
        CAST(s.SESS_ID AS VARCHAR(1000)) AS PATH
    FROM 
        V$SESSION s
        JOIN V$LOCK l ON s.SESS_ID = l.SESS_ID
    WHERE 
        l.BLOCKED = 1
        
    UNION ALL
    
    -- 递归部分：向上查找阻塞源
    SELECT 
        s.SESS_ID,
        s.SQL_TEXT,
        s.STATUS,
        s.LOGON_TIME,
        l.BLOCKED,
        l.BLOCKING_SESS,
        s.USERNAME,
        s.CLIENT_ADDR,
        bt.LEVEL + 1,
        CAST(bt.PATH || '->' || s.SESS_ID AS VARCHAR(1000))
    FROM 
        BLOCK_TREE bt
        JOIN V$SESSION s ON bt.BLOCKING_SESS = s.SESS_ID
        JOIN V$LOCK l ON s.SESS_ID = l.SESS_ID
)
SELECT 
    LEVEL AS 阻塞层级,
    SESS_ID AS 会话ID,
    USERNAME AS 数据库用户,
    CLIENT_ADDR AS 客户端IP,
    STATUS AS 会话状态,
    LOGON_TIME AS 登录时间,
    SQL_TEXT AS 执行SQL,
    PATH AS 阻塞路径
FROM 
    BLOCK_TREE
ORDER BY 
    LEVEL, PATH;

4. 关键参数说明

4.1 输出字段详解

4.2 性能优化参数

在大型生产环境中，建议添加以下过滤条件：

sql复制WHERE 
    -- 只查活跃会话
    STATUS = 'ACTIVE'  
    -- 排除系统会话
    AND USERNAME NOT IN ('SYSDBA','SYSAUDITOR')  
    -- 只显示阻塞超过5分钟的情况
    AND LOGON_TIME < SYSDATE - 5/1440

5. 典型应用场景

5.1 紧急故障排查

当收到业务系统卡顿报警时：

1. 执行脚本获取阻塞关系树
2. 根据"阻塞层级"定位最顶端的会话（LEVEL最大值）
3. 检查该会话的SQL_TEXT和登录时间
4. 通过CLIENT_ADDR确认应用来源

5.2 定期健康检查

建议每天低峰期运行一次脚本，重点关注：

• 重复出现的相同SQL（可能存在缺失索引）
• 长期存在的阻塞链条（可能有应用逻辑缺陷）
• 特定客户端的频繁阻塞（需要优化连接池配置）

6. 实战经验分享

6.1 常见阻塞模式

1. 报表查询阻塞OLTP：

   • 特征：阻塞源SQL包含全表扫描，被阻塞会话是短事务
   • 解决方案：为报表创建专用副本或添加NOLOCK提示

2. 批量更新锁升级：

   • 特征：阻塞源执行大批量UPDATE，被阻塞会话尝试修改同一表
   • 解决方案：拆分批量操作为小事务，或调整LOCK_TIMEOUT

3. 外键未索引：

   • 特征：阻塞发生在DELETE操作，且涉及外键关联表
   • 解决方案：为外键字段添加索引

6.2 性能采集技巧

为后续分析建议保存历史数据：

sql复制-- 创建历史记录表
CREATE TABLE DBA_BLOCK_HISTORY AS 
SELECT * FROM BLOCK_TREE WHERE 1=0;

-- 定期插入数据（可配置为JOB）
INSERT INTO DBA_BLOCK_HISTORY
SELECT SYSDATE AS COLLECT_TIME, bt.* 
FROM BLOCK_TREE bt;

7. 进阶优化方向

7.1 锁等待监控看板

基于历史数据可以构建：

• 每小时阻塞事件趋势图
• 最常阻塞的TOP10 SQL
• 客户端IP阻塞排名

7.2 自动化处理方案

对于已知模式的阻塞，可编写PL/SQL脚本自动处理：

sql复制DECLARE
    v_top_blocker SYS_REFCURSOR;
BEGIN
    -- 查找阻塞超过10分钟的会话
    OPEN v_top_blocker FOR 
        SELECT SESS_ID FROM BLOCK_TREE 
        WHERE LEVEL = (SELECT MAX(LEVEL) FROM BLOCK_TREE)
        AND LOGON_TIME < SYSDATE - 10/1440;
    
    -- 自动kill阻塞源
    FOR r IN v_top_blocker LOOP
        EXECUTE IMMEDIATE 'ALTER SYSTEM KILL SESSION ''' || r.SESS_ID || '''';
        DBMS_OUTPUT.PUT_LINE('Killed session: ' || r.Sess_ID);
    END LOOP;
END;

重要提示：自动化KILL操作需谨慎，建议先保存会话信息再操作，并确保有审批流程