实例讲解如何在DB2 UDB中正确的监控死锁

核心提示：前言：这篇文章通过具体的实例阐述了如何在DB2 UDB 中监控死锁的发生，在DB2 UDB中有两种类型的监控器：快照监控器和事件监控器，实例讲解如何在DB2 UDB中正确的监控死锁，快照顾名思义就是数据库连续状态下的一个切面，通过快照监控器，从而释放锁空间，虽然锁升级本身并不耗费多少时间，你可以很方便地查看当前连接的应

前言：这篇文章通过具体的实例阐述了如何在DB2 UDB 中监控死锁的发生。在DB2 UDB中有两种类型的监控器：快照监控器和事件监控器。快照顾名思义就是数据库连续状态下的一个切面，通过快照监控器，你可以很方便地查看当前连接的应用程序，当前等待的锁，当前的死锁，以及正在执行的SQL语句，同时你可以查看缓冲区，表和表空间的用法。假如保存历史数据，并且能够做出比较，对于分析数据库的并发性能有很大的帮助。

但是我们并不能猜测什么时候发生死锁，所以假如有一个后台程序能够一直监控数据库的活动，记录下所有的死锁事件，这对于数据库治理员来说是非常重要的。DB2 UDB提供了事件监控器。通过不遗漏地获得一段时间内所有的数据库事件（在本文中只关心其中的死锁事件），事件监控器提供了一种可以分析历史数据（本文的重点），猜测将来趋势的可能。DB2 UDB同时提供了DB2 Performance Expert (DB2/PE) 或者类似的程序用来生成分析报表，不过这已经超出了本文的范畴。

常用术语

锁是控制应用程序并发的数据库软件机制，锁用来防止以下情况的发生：

1． 丢失以前更新

2． 不可重复读取

3． 访问未提交数据

锁的模式包括共享锁和排他锁，共享锁答应其他程序读取已经被其他共享锁占用的资源，所以也叫读锁，排他锁意味着在释放资源以前其他的应用程序无法访问同一资源，所以也叫写锁。此外，DB2 UDB 还提供了不同的锁级别，不同的应用程序可能会要求访问不同范围的数据，锁级别有利于充分利用系统资源，提高系统性能。若一个应用程序请求一个锁，而该锁被另外一个应用程序所使用且不能共享，DB2 UDB 就会挂起前一个应用程序。锁升级就是当LOCKLIST (LOCKLIST代表锁能够占用的内存空间) 耗尽或者一个应用程序所拥有的锁大于MAXLOCKS*LOCKLIST的时候（MAXLOCKS 代表应用程序所拥有的锁占所空间的百分比），DB2 UDB 就试图把几个行级别的锁合并为一个表级别的锁，从而释放锁空间。虽然锁升级本身并不耗费多少时间，但是锁住整个表通常会大大地降低并发性能。