如何在 SAP 系统中监控和分析 DB2 UDB 性能

核心提示： 锁升级 (Lock Escalation)：一个锁通常作为一个记录存储在内存锁表中，锁表的大小可以由数据库自动调节，如何在 SAP 系统中监控和分析 DB2 UDB 性能(8)，锁升级一般发生在锁的数量超过了数据库配置参数 MAXLOCKS 所指定的大小，为了减少锁的数量，DLCHKTIME 时

锁升级 (Lock Escalation)：一个锁通常作为一个记录存储在内存锁表中，锁表的大小可以由数据库自动调节。锁升级一般发生在锁的数量超过了数据库配置参数 MAXLOCKS 所指定的大小，为了减少锁的数量，数据库会把若干行一级的锁合并为表锁。这样数据库的并发性就会受到影响。

监控

我们进入 SAP 的 DBA Cockpit，然后在 Performance 的目录下双击 Database, 在 Locks and Deadlocks 的标签内，可以看到当前数据库的锁的状况。

图 7. 数据库锁状况

查看原图（大图）

从图中可以看到，当前锁表的大小为 22144KB，已经使用了 94KB。锁等待的平均时间为 10.40ms，没有锁升级和死锁被检测到。

分析

影响数据性能的有关锁的问题主要集中在锁等待，死锁和锁升级。这些问题的根源很可能是数据库应用的设计问题。因此，我们应该仔细调查造成死锁，锁等待和锁升级的应用程序，以及其用到的 SQL 语句。同时，在问题定位之前，我们也可以通过下面方法来解决数据库锁造成的性能问题。

锁等待和死锁：如果要避免锁等待和死锁的问题我们需要注意数据库参数中的 DLCHKTIME 和 LOCKTIMEOUT 两个参数的设置。其中 DLCHKTIME 单位是毫秒，是 DB2 检查死锁的间隔时间，如果该值为 10000ms，则表明每隔 10 秒钟数据库会检查一下有无死锁存在，如有死锁，会选择回滚其中的某一个事务，让另外一个事务完成交易。LOCKTIMEOUT 单位是秒，是锁等待最长时间，超过该时间仍未获得锁，则返回错误。LOCKTIMEOUT 的默认值为 -1，这意味着锁等待时间无限大，一般不推荐这种设置。DLCHKTIME 时间通常要设得比 LOCKTIMEOUT 时间小一些，否则还未发现死锁，就会返回锁等待超时错误 (SQL0911N 返回码 68) 。