生产环境里使用的数据库是DB2。但是最近频繁出现一个奇怪的死锁现象：某一个select sql 语句总是会出现死锁。
按照以往的经验，通常都是update/delete之类的更新sql语句会出现死锁的问题。而且这个 select sql 语句是一个很普通的sql，没有任何大数据量的处理。
分析这个死锁，有很多难以处理的地方。
1、因为生产环境
简介 锁是数据库为了控制并发数据的完整性而引入的机制，在并发应用中出现锁现象并不可怕，锁现象通常分为死锁和锁等待两种情形。 死锁是因为两个并发的进程或者线程同时各自占有一个资源，又需要占有对方资源，但又都各不相让造成的，这通常是因为程序在并发上考虑不周造成的。 锁等待则是数据库中最普通的情况，一各应用使用数据期间必然要加锁，防止其他进程或应用破坏数据，其他进程或应用在此期间不得不等待前
COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver][DB2/NT] SQL0911N 由于死锁或超时，已回滚当前事务。原因码“2”。SQLSTATE=40001 IBM 对该问题提供的处理办法 此问题可能是应用程序引起的 DB2 死锁，尤其是访问 DB2 数据源时，遇到类似以下内容的错误： ERROR CODE: -911
COM.ibm.d
锁是数据库为了控制并发数据的完整性而引入的机制，在并发应用中出现锁现象并不可怕，锁现象通常分为死锁和锁等待两种情形。 死锁是因为两个并发的进程或者线程同时各自占有一个资源，又需要占有对方资源，但又都各不相让造成的，这通常是因为程序在并发上考虑不周造成的。 &nb
实例讲解如何在DB2 UDB中正确的监控死锁 aS,?Kr P
前言：这篇文章通过详细的实例阐述了如何在DB2 UDB 中监控死锁的发生。在DB2 UDB中有两种类型的监控器：快照监控器和事件监控器。快照顾名思义就是数据库连续状态下的一个切面，通过快照监控器，你可以很方便地查看当前连接的应用程序，当前等待的锁，当前的死锁，以及正在执行的SQL语句，同时你可以查看缓冲区，表和表空
C:\>db2 get snapshot for locks on js
数据库锁定快照
数据库名称 = JS
数据库路径 = D:\DB2\NODE0000\SQL00001\
输入数据库别名 = JS
挂起的锁定 = 5
当前已连接的应用程序 = 1
当前正等待锁定的代理程序数 = 0
快照时间戳记 = 2007-09-04 1
继续温故知新，关于锁，DB2这块貌似做的很严格，正因为过犹不及，也是被同行所诟病的，并发性明显不如Oracle。主要原因还是在于本身锁的设计上面，oracle有回滚段，不会因为某些更改操作而导致整个表被hold住。用户还是可以读，对于某些更改数据的读，oracle读的是before image，也就是不是更改中的值，而是更改前的值。所以往往业务的需求大于理
-查看数据库管理器级别快照信息 db2 get snapshot for dbm -查看数据库级别快照信息 db2 get snapshot for database on dbname -查看
背景在团队协作的开发环境下，难免会遇到多个成员同时访问一张表的情况。在断点调试时，又非常容易加事务的长连接，引发死锁。下面实例讲解解锁过程。 解锁过程①查找节点
解锁之前，需要知道数据库所在节点。
db2 => LIST NODE DIRECTORY 节点目录 目录中的条目数 = 3 节点 1 条目： 节点名 = NDE5DC7D 注释 = 目录条目类型 = LOCAL
几个月前发现一个很少用的表死锁了，重启DB2，也没在意，今天发现一个使用非常频繁的表死锁了，而且是写的死锁，执行Select很快，但执行 Uptdate则吊在那里了，初步判定是死锁了，使用DB2提供的事件监视器没有看到任何有用的信息，于是打电话给IBM的800。
800的那位小姐声音很动听，而且还是前几天帮我解决问题的那位，等我描述完我的问题
原理： 锁是数据库为了控制并发数据的完整性而引入的机制，在并发应用中出现锁现象并不可怕，锁现象通常分为死锁和锁等待两种情形。 死锁是因为两个并发的进程或者线程同时各自占有一个资源，又需要占有对方资源，但又都各不相让造成的，这通常是因为程序在并发上考虑不周造成的。 锁等待则是数据库中最普通的情况，一个
问题描述：在一个运行于DB2上的OLTP系统中，应用程序每两个小时挂起一次。挂起持续的时间每次长达2～3分钟甚至更多。在挂起期间，所有的INSERT、UPDATE和DELETE操作都无响应，但是一些查询操作可以执行。运行环境：DB2 V9.1，操作系统 AIX 5.3。最初怀疑问题是由锁定等待引起的，但是当把LOCKTIMEOUT设置为10秒之后，此挂起现象依然继续发生。挂起发生后，应用
DB2 数据库发生死锁了怎么办？ 责任编辑：郑重作者：IT168陈敏 2007-12-18 【内容导航】第1页：上线前的准备第2页：维护时的注意事项第3页：发生死锁后的对策文本Tag：IBMDB2 DB2 上线之后维护时我们要做的几件事情 1. 做好定期维护 通过使用如下命令进行维护： －reorg表和索引定期重组 －runstats表和索引的统
db2 get snapshot for locks on sampledb2 get db cfg for sampledb2 update db cfg using dlchktime 10000-查看数据库管理器级别快照信息 db2 get snapshot for dbm -查看数据库级别快照信息
db2 get snapshot for locks on sample db2 get db cfg for sample db2 update db cfg using dlchktime 10000 -查看数据库管理器级别快照信息 db2 get snapshot for dbm -查看数据库级别快照信息  
DB2锁等待和死锁问题数据库中之所以会存在死锁或者锁等待，是因为某一事务执行时间过长，导致锁没有及时释放，那么我们的解决办法就是，事务过程尽量要短，并且事务中的sql执行要快，这样才不会有过多的锁等待。还有一个原因，就是一些执行糟糕的sql，比如走了全表扫描，那么它会占据表中大量的锁，导致锁住了其他行，其他用户只能等待。解决锁等待，要注意以下几点优化查询 Sql，采用db2advis建立合适的索引
在DB2的命令行中输入：
update monitor switches using lock on table on
然后打开另一个DB2命令窗口执行我的那个被吊死的Update语句。
然后在第一个DB2命令窗口执行：
get snapshot for locks on Database_Name(你的数据库的名字)> locks.TXT
DB2错误信息（按sqlcode排序）
sqlcode sqlstate 说明
000 00000 SQL语句成功完成
01xxx SQL语句成功完成，但是有警告
+012 01545 未限定的列名被解释为一个有相互关系的引用
+098 &n
DB2中基本的锁有两类： 共享锁（Share locks简记为S锁）：也称读锁，事务A对对象T加S锁，其他事务也只能对T加S，多个事务可以同时读，但不能有写操作，直到A释放S锁。 排它锁（Exclusivelocks简记为X锁）：也称写锁，事务A对对象T加X锁以后，其他事务不能对T加任何锁，只有事务A可以读写对象T直到A释放X锁。事务隔离级别：隔离级别脏读不可重复读幻读未提交读（Uncommitt
1.创建死锁监视器 mkdir /home/db2inst1/dlocksdb2 connect to <dbname>db2 "create event monitor dlocks for deadlocks with details write to file '/home/db2inst1/dlocks' MAXFILES 5 MAXFILESIZE ...
原创
2022-07-29 21:05:38
232阅读
