张云雷宝宝1. 达梦8锁阻塞巡检SQL方案设计背景
在达梦8数据库的日常运维中，锁阻塞问题是最常见的性能瓶颈之一。与Oracle等商业数据库不同，达梦8的锁机制有其特殊性——它不仅支持常规的行级锁和表级锁，还实现了独特的"意向锁"机制。当多个事务并发访问相同数据资源时，很容易出现会话相互等待的情况，严重时会导致业务系统完全卡死。
我曾在某政务系统中处理过一个典型案例：每月底批量任务运行时，核心业务表频繁出现锁等待超时。通过开发这套巡检SQL，我们实现了三个关键目标：
- 实时发现锁阻塞链条的源头会话（Head blocker）
- 精确定位被阻塞的关键业务SQL
- 识别出设计不合理的长时间运行事务
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 锁阻塞检测的核心SQL解析
2.1 锁等待关系查询
sql复制SELECT
lh.trx_id AS blocking_trx_id,
lh.sess_id AS blocking_sess_id,
lh.sql_text AS blocking_sql,
lh.start_time AS blocking_start,
lw.trx_id AS waiting_trx_id,
lw.sess_id AS waiting_sess_id,
lw.sql_text AS waiting_sql,
TIMESTAMPDIFF(SECOND, lw.start_time, NOW()) AS wait_seconds,
lh.lock_type AS lock_type,
lh.table_name AS locked_table
FROM
V$LOCK lh
JOIN
V$LOCK lw ON lh.block_sess = lw.sess_id
WHERE
lh.block_sess IS NOT NULL
ORDER BY
wait_seconds DESC;
关键字段说明：
blocking_trx_id：阻塞源事务IDwait_seconds：已等待时间（秒），这是判断严重程度的核心指标lock_type：锁类型（ROW_EXCLUSIVE/TABLE_SHARE等）
注意：达梦8的V$LOCK视图与Oracle的v$lock结构差异较大，其中block_sess字段专门用于标识阻塞会话
2.2 会话详情关联查询
sql复制SELECT
s.sess_id,
s.client_addr,
s.username,
s.status,
s.command,
s.program_name,
s.module,
TIMESTAMPDIFF(MINUTE, s.login_time, NOW()) AS session_duration,
t.trx_id,
t.trx_started,
t.trx_state
FROM
V$SESSION s
LEFT JOIN
V$TRANSACTION t ON s.trx_id = t.trx_id
WHERE
s.sess_id IN (SELECT blocking_sess FROM lock_wait_view)
OR s.sess_id IN (SELECT waiting_sess FROM lock_wait_view);
这个查询通过关联V$SESSION和V$TRANSACTION视图，可以获取到：
- 客户端IP和连接来源
- 会话持续时间（判断是否长时间未提交）
- 事务状态（ACTIVE/IDLE等）
3. 自动化巡检方案实现
3.1 巡检脚本部署
建议使用Shell脚本+SQL文件的方式实现定时巡检：
bash复制#!/bin/bash
DM_HOME="/opt/dmdbms"
DM_USER="SYSDBA"
DM_PWD="SYSDBA123"
OUTPUT_DIR="/var/log/dm_lock_check"
mkdir -p $OUTPUT_DIR
DATE=$(date +%Y%m%d_%H%M%S)
$DM_HOME/bin/disql $DM_USER/$DM_PWD \`$PWD/lock_check.sql > $OUTPUT_DIR/lock_report_$DATE.log
# 发送邮件通知
grep -q "blocking_sess_id" $OUTPUT_DIR/lock_report_$DATE.log && \
mail -s "达梦锁阻塞告警" dba@example.com < $OUTPUT_DIR/lock_report_$DATE.log
3.2 结果分析要点
当检测到锁阻塞时，报告会包含类似以下信息：
code复制blocking_sess_id | waiting_sess_id | wait_seconds | locked_table
-----------------+-----------------+--------------+-------------
15234 | 15256 | 328 | PAYMENT_RECORDS
处理优先级建议：
- 等待时间 > 300秒：立即处理
- 等待时间 60-300秒：30分钟内处理
- 等待时间 < 60秒：观察后续发展
4. 典型锁阻塞场景处理方案
4.1 长时间未提交事务
特征：
- 阻塞会话的session_duration值很大（如>30分钟）
- trx_state状态为ACTIVE但无实际SQL执行
解决方案：
sql复制-- 1. 查看会话详情
SELECT * FROM V$SESSION WHERE sess_id = [阻塞会话ID];
-- 2. 终止会话（需SYSDBA权限）
SP_CLOSE_SESSION([阻塞会话ID]);
4.2 无索引更新导致的表锁
特征：
- lock_type显示为TABLE_*
- 被锁表上没有合适索引
优化方案：
sql复制-- 检查表索引情况
SELECT * FROM ALL_INDEXES WHERE table_name = '[表名]';
-- 建议添加索引
CREATE INDEX idx_column ON [表名]([更新字段]);
5. 巡检优化建议
5.1 定期统计报表
建议每周生成锁阻塞统计报表，重点关注：
- 高频被锁表Top10
- 常见阻塞SQL模式
- 典型业务时段分布
sql复制SELECT
locked_table,
COUNT(*) AS block_count,
AVG(wait_seconds) AS avg_wait_time
FROM
lock_wait_view
WHERE
create_time > DATE_SUB(NOW(), INTERVAL 7 DAY)
GROUP BY
locked_table
ORDER BY
block_count DESC;
5.2 预防性措施
-
事务设计原则：
- 单个事务持续时间不超过5秒
- 避免在事务中进行用户交互
- 大批量操作使用分批提交
-
连接池配置建议：
properties复制# 达梦Druid连接池配置示例 maxActive=50 maxWait=3000 removeAbandoned=true removeAbandonedTimeout=60 -
监控集成：
- 将巡检结果接入Prometheus+Grafana
- 设置wait_seconds > 60的告警规则
6. 达梦8锁机制深度解析
6.1 锁类型对照表
| 锁类型代码 | 说明 | 冲突锁类型 |
|---|---|---|
| RS | 行共享锁(SELECT) | X, RX |
| RX | 行排他锁(UPDATE) | RS, S, X, RX |
| S | 表共享锁 | X, RX |
| X | 表排他锁(DDL操作) | 所有其他锁 |
| IS | 意向共享锁 | X |
| IX | 意向排他锁 | S, X |
6.2 锁升级机制
达梦8在以下情况会发生锁升级：
- 单个事务对同一表的锁请求超过5000个行锁
- 系统内存压力达到阈值
- 显式执行LOCK TABLE语句
监控锁升级事件：
sql复制SELECT * FROM V$LOCK_ESCALATION
WHERE event_time > DATE_SUB(NOW(), INTERVAL 1 HOUR);
7. 与Oracle锁机制的差异处理
7.1 关键差异点
-
等待超时设置：
- 达梦8默认无限等待
- 可通过参数设置：
ALTER SYSTEM SET DEADLOCK_TIMEOUT=30;
-
死锁检测：
- 达梦8检测到死锁后会随机终止一个事务
- 日志记录在$DM_HOME/log/dm_detdeadlock.log
-
特殊锁类型：
- 达梦8的BF锁(Bitmap Free)是Oracle没有的
- 分区锁管理方式不同
7.2 兼容性处理技巧
对于从Oracle迁移的应用，建议：
-
在连接字符串中添加：
properties复制oracle_compatible=true isolation_level=READ_COMMITTED -
修改容易引发锁冲突的SQL模式：
sql复制-- Oracle风格（易引发问题） SELECT * FROM table FOR UPDATE WAIT 5; -- 达梦推荐写法 BEGIN DECLARE CURSOR c1 IS SELECT * FROM table FOR UPDATE; OPEN c1; -- 业务处理 COMMIT; END;
8. 性能优化实战案例
8.1 政务系统批量任务优化
问题现象：
每月底执行统计报表时，核心交易表出现大面积锁等待，最长等待达15分钟。
分析过程：
- 通过巡检SQL发现阻塞源是
BATCH_STAT会话 - 该会话执行的是全表更新的统计操作
- 没有合适的索引导致升级为表锁
解决方案：
sql复制-- 1. 创建覆盖索引
CREATE INDEX idx_batch_stat ON transaction_detail(batch_date, region_code);
-- 2. 重写批处理逻辑（伪代码示例）
BEGIN
FOR partition IN (SELECT partition_name FROM user_tab_partitions
WHERE table_name='TRANSACTION_DETAIL') LOOP
UPDATE /*+ PARTITION(partition) */ transaction_detail
SET stat_flag='Y'
WHERE batch_date=TO_DATE('2023-06-30','YYYY-MM-DD');
COMMIT;
END LOOP;
END;
优化效果：
- 单次批处理时间从45分钟降至8分钟
- 锁等待事件减少92%
9. 高并发场景下的特殊处理
9.1 热点行更新方案
对于账户余额等热点数据：
sql复制-- 传统方式（易引发排队）
UPDATE accounts SET balance=balance-100 WHERE account_no='123456';
-- 优化方案（使用SELECT FOR UPDATE NOWAIT）
BEGIN
DECLARE cur CURSOR FOR
SELECT balance FROM accounts WHERE account_no='123456' FOR UPDATE NOWAIT;
OPEN cur;
FETCH cur INTO v_balance;
IF v_balance >= 100 THEN
UPDATE accounts SET balance=balance-100 WHERE account_no='123456';
ELSE
-- 余额不足处理
END IF;
CLOSE cur;
COMMIT;
EXCEPTION
WHEN OTHERS THEN
IF SQLCODE = -610 THEN -- 锁获取失败
-- 重试或返回繁忙提示
END IF;
END;
9.2 连接池优化配置
properties复制# 达梦Druid推荐配置（高并发场景）
initialSize=5
maxActive=100
minIdle=10
maxWait=1000
timeBetweenEvictionRunsMillis=60000
minEvictableIdleTimeMillis=300000
validationQuery=SELECT 1 FROM DUAL
testWhileIdle=true
testOnBorrow=false
testOnReturn=false
10. 巡检方案扩展建议
10.1 与Prometheus集成
通过达梦的ODBC驱动将巡检结果输出到Prometheus：
- 创建输出视图：
sql复制CREATE VIEW prometheus_lock_metrics AS
SELECT
'dm_lock_wait' AS metric,
wait_seconds AS value,
blocked_table AS labels
FROM
lock_wait_view;
- 使用dmfldr导出数据：
bash复制dmfldr USERID=SYSDBA/SYSDBA123 CONTROL=lock_metrics.ctl
10.2 自动化处理脚本示例
python复制#!/usr/bin/python3
import dmPython
import smtplib
from email.mime.text import MIMEText
def check_lock():
conn = dmPython.connect('SYSDBA/SYSDBA123@localhost:5236')
cursor = conn.cursor()
cursor.execute("""
SELECT blocking_sess_id, waiting_sess_id, wait_seconds
FROM lock_wait_view
WHERE wait_seconds > 60
""")
alerts = []
for row in cursor:
alerts.append(f"阻塞会话:{row[0]} 被阻塞会话:{row[1]} 等待:{row[2]}秒")
if alerts:
send_alert('\n'.join(alerts))
cursor.close()
conn.close()
def send_alert(content):
msg = MIMEText(content)
msg['Subject'] = '达梦数据库锁阻塞告警'
msg['From'] = 'dba@example.com'
msg['To'] = 'admin@example.com'
smtp = smtplib.SMTP('smtp.example.com')
smtp.send_message(msg)
smtp.quit()
if __name__ == '__main__':
check_lock()
11. 达梦8特有功能利用
11.1 锁超时提示功能
sql复制-- 启用会话级锁等待提示
SET LOCK_TIMEOUT=30; -- 单位：秒
-- 全局设置（需SYSDBA）
ALTER SYSTEM SET LOCK_TIMEOUT=30 SCOPE=BOTH;
当语句等待超过设定时间后，会返回错误而非无限等待：
code复制[执行语句]: update accounts set balance=balance+100 where account_no='888888';
[错误代码]: -610
[错误信息]: 获取锁超时
11.2 锁历史分析
达梦8的V$LOCK_HISTORY视图记录历史锁信息（需开启监控）：
sql复制-- 开启锁历史记录
ALTER SYSTEM SET ENABLE_LOCK_HISTORY=1;
-- 查询历史锁冲突
SELECT * FROM V$LOCK_HISTORY
WHERE lock_time > SYSDATE-1/24
ORDER BY wait_time DESC;
12. 常见误区和注意事项
-
误区：所有锁等待都需要处理
- 短时间的锁等待（<1秒）是正常现象
- 重点关注持续增长的等待链
-
注意事项：杀会话的风险
sql复制-- 错误的杀会话方式（可能导致事务不一致） SP_CLOSE_SESSION(sess_id); -- 推荐方式（尝试正常结束） SP_CANCEL_SESSION(sess_id); -- 先尝试取消 SP_CLOSE_SESSION(sess_id); -- 强制关闭（必要时） -
监控盲区：
- 分布式事务的锁等待需要特殊处理
- 分区表的不同分区锁独立管理
-
性能影响：
- 频繁查询V$LOCK视图会导致轻微性能开销
- 建议巡检间隔不低于5分钟
13. 锁问题诊断工具箱推荐
-
达梦自带工具：
- Manager管理工具中的"锁管理"模块
- disql的
SHOW LOCKS命令
-
第三方工具：
- 达梦版的DBeaver（支持可视化锁分析）
- 达梦性能分析器（需单独安装）
-
自制脚本集：
bash复制# 快速检查锁等待 #!/bin/bash disql SYSDBA/SYSDBA123 -e "SELECT COUNT(*) FROM V$LOCK WHERE block_sess IS NOT NULL;"
14. 与应用开发的协作建议
-
代码审查要点：
- 避免事务中包含耗时操作（如文件IO、网络请求）
- 更新操作尽量使用主键条件
- 合理设置事务隔离级别
-
JDBC最佳实践：
java复制// 正确的连接设置示例 Properties connProps = new Properties(); connProps.setProperty("oracle_compatible", "true"); connProps.setProperty("isolation_level", "READ_COMMITTED"); connProps.setProperty("lock_timeout", "3000"); // 3秒 Connection conn = DriverManager.getConnection( "jdbc:dm://localhost:5236", connProps); -
Spring事务配置：
xml复制<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource" ref="dataSource"/> <property name="defaultTimeout" value="5"/> <!-- 5秒超时 --> </bean>
15. 未来演进方向
-
达梦8.3新特性预览：
- 锁分组管理（Lock Grouping）
- 在线锁转换（Lock Conversion）
- 增强的死锁检测算法
-
云原生环境适配：
- Kubernetes Operator中的锁监控
- 分布式锁服务集成
-
AI预测建议：
sql复制-- 即将推出的AI建议功能示例 SELECT * FROM TABLE(DBMS_LOCK_ADVISOR( analysis_period => INTERVAL '1' HOUR));
这套巡检方案在某省级政务云环境中运行半年后，锁阻塞相关的生产事件减少了80%以上。最关键的是建立了预防-发现-处理-优化的完整闭环。实际部署时建议根据具体业务特点调整阈值和检查频率，特别是对核心业务表应该设置更严格的监控策略