背景
早在2008年阿里就提出了去IOE想法，当时很多人还没意识到这是一个多么伟大的想法，直到2013年美国棱镜门事件之后我国政府已经意识到政府数据安全的重要性，也加强了政府数据安全方面的工作，并出台了多个数据安全相关的法律法规，例如2017年《中国网络安全法》 2019年《网络安全等级保护2.0》2021年《中国数据安全法》2021年《个人信息保护法》等相关法律法规。
而我们公司做为一家国有企业单位自然要响应国家相关数据安全法律法规，在经过多次的国产数据库调研后，最终选择了国产达梦数据库做为公司《信创建设-国产数据库替代》的最优选择，第一个试点系统是我们公司的一个人力系统，选择它进行试点是因为人力系统使用的ORACLE数据库，而达梦对于ORACLE数据库的兼容几乎到了99%的兼容性，于是替换迁移工作开始有序进行，刚开始数据库环境搭建，数据导入导出都没有遇到问题，直到今年9月份项目快上线时候微信项目群里有人@我反馈一个update语句运行了50分钟还没运行完，如下图：
刚开始我按照传统思路想，是不是数据量很大千万级别，数据表索引没创建等原因导致，还信誓旦旦根项目组说：小问题，等我忙完别的在处理。
最后发现居然都不是。下面是当时的问题解决及原因总结：
一：问题重新
在达梦DM管理工具SQL窗口执行以下SQL发现时间50分钟
update bd_psndoc set bd_psndoc.pk_hrorg='0001A71000000000CFMP' where bd_psndoc.code
in
(
'2006070009',
'2000070012',
'2017040002',
'2019070131',
'2020050003',
'2020040025',
'2020040024',
'2020040026',
'2020040027',
'2020060034',
'2020060032')
查询表bd_psndoc 只有4000多条记录，并且只更新11条数据
二、解决方法
根据达梦数据库官方《数据库性能诊断》一篇进行诊断
https://eco.dameng.com/document/dm/zh-cn/ops/performance-db
select * from v$trxwait;--查出ID=11112 供V$SESSIONS使用
select * from SYS."V$LOCK" WHERE "V$LOCK".BLOCKED='1';--1代表表锁，查询出table_id=1098
select * from SYS.SYSOBJECTS WHERE id='1098'--根据上一步查到的表ID可以再对象里面查询具体表名
select * from SYS."V$SESSIONS" WHERE TRX_ID='11112';--查出session_id=140277208140704
sp_close_session(140277208140704)--杀会话原来是由于多次的update未提交导致阻塞，杀掉阻塞的会话后，再次执行只要几毫秒。
三、总结
发生SQL阻塞可以通过v$lock和v$trxwait很方便的定位出阻塞源头，不同于Oracle的杀session使用的是alter system kill session方式
alter system kill session 'sid,serial#';
达梦使用的是sp_close_session（）的方式进行杀锁。同时建议对于UPDATE的操作可以设置自动提交，在DM管理工具的设置里，如下图：
