关于达梦数据库锁表问题 本小白费了一下午时间又偶然间看到的文章,帮了大忙谢谢!

原文: http://www.dameng.com/teachers_view.aspx?TypeId=183&Id=911&FId=t26:183:26

大家知道，达梦数据库支持多用户并发访问、修改数据。在实际工作中，有可能出现多个事务同时访问、修改相同数据的情况，当一个事务正在占用某个资源的锁，此时另一个事务正在请求这个资源上与第一个锁相冲突的锁类型时，就会发生阻塞。此时，被阻塞的事务将一直挂起，直到持有锁的事务放弃锁定的资源为止。本文就将给大家介绍如何使用对应的动态性能视图查看阻塞以及如何解决阻塞。

本文实验环境：演示环境：DM Database Server x64 V7.1.6.46-Build(2018.02.08-89107)ENT

1、创建测试表并插入数据

建表：

 

2.在T1上面生成TID锁

执行update操作并且不提交，具体操作如下：

 

3.开启新会话

3.1 在新会话下执行select操作

 

可以看到，由于MVCC的多版本机制，写不会阻塞读，所以select操作可以正常进行。但是前面的事务没有提交，所以查出来的结果还是旧版本的值，也就是update之前的值。

3.2 在新会话下执行DML操作

 

此时，由于delete操作需要加上与之前update操作相同类型的锁，所以阻塞发生，当前事务被挂起。

4.阻塞的排查

当阻塞发生时，我们可以通过v$lock视图查到当前数据库中锁的状态

 

结果中我们可以看到，事务2399被阻塞了，阻塞他的事务为2393，

同样我们也可以通过V$TRXWAIT视图查找谁阻塞谁，

 

得出同样的结果，ID为2399的事务正在等待ID为2393的事务，等待时间是1071599毫秒。

接下来，通过V$SESSIONS视图查找两个事务对应的会话

 

可以得到两个事务对应的会话ID和当前执行SQL语句，可以知道是哪些SQL语句产生的阻塞。

5.阻塞的解决方法

根据需求，可以有两种解决方案。

5.1提交或回滚产生阻塞的事务。

根据上文，我们可知产生阻塞的事务会话ID为2410147992。此时，我们只需要在该会话下提交或回滚事务，锁自然会被释放，阻塞解决。

5.2关闭产生阻塞的会话

同样，我们也可以使用系统过程SP_CLOSE_SESSION(SESS_ID)来关闭对应的会话，具体使用方法如下。

 

此时，锁被释放，delete操作也可以顺利进行下去。