你们那边 DB2 是哪个版本的? DB2 v9.7以后,Currently Commited功能是默认开启的,可以避免大量的读写事务并发导致的锁等问题。
你这个问题,建议从两方面入手:
1、查看生产数据库监控,看看锁资源是否充足,锁的相关数据库配置是否合理(LOCKLIST、MAXLOCKS、LOCKTIMEOUT等)看看db2diag.log 是否经常出现锁升级现象。
2、排查锁等事件中参与的并发应用,看看是否存在下面问题:
并发应用之间的执行顺序是否合理?
并发应用的隔离级别是否设置合理(注意,大多数应用中间件的隔离级别默认是 RS)?
持有锁事务是否业务逻辑过于复杂、执行时间过长,占用大量的锁资源太长时间?
并发应用中,涉及的游标应该尽快关闭,不要使用模糊游标!
并发应用的 SQL是否可以优化,避免访问不必要的数据?
并发应用的 SQL 是否有效地使用了索引?
我想到的,目前就这么多,其他思路,社区其他高手多多补充吧
收起修改配置是解决眼前当下的短期问题。修改应用程序中的SQL语句,和流程处理顺序,是解决锁类问题的根本方法。
收起从报错信息来看,是产生了锁超时,这里就需要找到持有锁的连接和等待锁的连接信息。
1、首先查询目前数据库存在的锁等待
db2pd -d DBNAME -wlocks
有三列信息需要关注的
agent_id :应用程序 id
lockname:锁名字,重点关注锁名一样的信息
sts :锁状态,如果是‘G’说明应用持有这个锁,‘W’说明应用等待这个锁。
2、根据前面查到的 agentid来查application新
db2pd -d DBNAME -app app=agentid
或者
db2pd -d DBNAME -apinfo app=agentid
这样可以查到锁和被锁的连接情况。
还有一种就是直接查系统表 SYSIBMADM.MON_LOCKWAITS。
select LOCK_NAME,REQ_APPLICATION_HANDLE,REQ_STMT_TEXT,HLD_APPLICATION_NAME,HLD_CURRENT_STMT_TEXT from SYSIBMADM.MON_LOCKWAITS with ur
用这条语句可以查出正在锁和锁等待的应用信息,更多信息可以选择更多列。
记住,上面的查锁等待信息的操作需要在锁等待时操作,如果出现了这个报错说明已经超时回滚了,也就差不到信息了。
收起