Prayer

 锁升级问题可以通过增加LOCKLIST和MAXLOCKS数据库参数的大小来解决。但是，如果仍然遇到锁定问题，应检查是否因未能提交事务而未释放已更新行上的锁。

每个数据库都有一个锁列表，该列表包含所有同时连接到数据库的应用程序所持有的锁。在32位平台上，一个对象上的第一个锁要求占64字节，而其他的锁要求占32字节。在64位平台上，第一个锁要求占112字节，而其他锁要求占56字节。

当一个应用程序使用的LOCKLIST的百分比达到MAXLOCKS时，数据库管理器将执行一次锁升级(lock escalation)，在这个操作中将使行锁转换成单独的一个表锁。而且，如果LOCKLIST快要耗尽，数据库管理器将找出持有一个表上最多行锁的连接，并将这些行锁转换成表锁，以释放LOCKLIST内存。锁定整个表会大大降低并发性，死锁的几率也就增加了。

●       LOCKLIST表明分配给锁列表的存储容量。每个数据库都有一个锁列表，锁列表包含了并发连接到该数据库的所有应用程序所持有的锁。锁定是数据库管理器用来控制多个应用程序并发访问数据库中数据的机制。行和表都可以被锁定。

●       MAXLOCKS定义了应用程序持有的锁列表的百分比，在数据库管理器执行锁升级之前必须填充该锁列表。当一个应用程序所使用的锁列表百分比达到MAXLOCKS 时，数据库管理器会升级这些锁，这意味着用表锁代替行锁，从而减少列表中锁的数量。当任何一个应用程序所持有的锁数量达到整个锁列表大小的这个百分比时，对该应用程序所持有的锁进行锁升级。如果锁列表用完了空间，那么也会发生锁升级。数据库管理器通过查看应用程序的锁列表并查找行锁最多的表，来决定对哪些锁进行升级。如果用一个表锁替换这些行锁，将不再会超出MAXLOCKS 值，那么锁升级就会停止。否则，锁升级就会一直进行，直到所持有的锁列表百分比低于MAXLOCKS。MAXLOCKS参数乘以MAXAPPLS参数的值不能小于100。

LOCKLIST配置参数的计算方法如下(操作系统为32位平台)：

(1) 计算锁列表大小的下限：(512 * 32 * MAXAPPLS)/4096。其中，512是每个应用程序平均所含锁数量的估计值，32是对象(已有一把锁)上每把锁所需的字节数。

(2) 计算锁列表大小的上限：(512 * 64 * MAXAPPLS)/4096。其中，64是某个对象上第一把锁所需的字节数。

(3) 对于您的数据，估计可能具有的并发数，并根据您的预计为锁列表选择一个初始值，该值位于您计算出的上限和下限之间。

MAXLOCKS配置参数的计算方法如下：

MAXLOCKS = 100 * (512锁/应用程序 * 32字节/锁 * 2)/(LOCKLIST * 4096字节)

该公式允许任何应用程序持有的锁是平均数的两倍。如果只有几个应用程序并发地运行，则可以增大MAXLOCKS，因为在这些条件下锁列表空间中不会有太多争用。

锁升级会在以下两种情况下被触发：

●       某个应用程序请求的锁所占用的内存空间超出了MAXLOCKS和LOCKLIST的乘积大小。这时，数据库管理器将试图通过为提出锁请求的应用程序申请表锁，并释放行锁来节省空间。

●       在一个数据库中已被加上的全部锁所占的内存空间超出了LOCKLIST定义的大小。这时，数据库管理器也将试图通过为提出锁请求的应用程序申请表锁，并释放行锁来节省空间。

虽然升级过程本身并不用花很多时间，但是锁定整个表(相对于锁定个别行)降低了并发性，而且数据库的整体性能可能会由于对受锁升级影响的表的后续访问而降低。

在设计良好的数据库中，很少发生锁定升级。如果锁定升级将并行性降低到不可接受的程度(由lock_escalation监视元素监视)，那么就需要分析问题并决定如何解决此问题。

锁升级是有可能失败的，比如，现在一个应用程序已经在一个表上加有IX锁，表中的某些行上加有X锁，另一个应用程序又来请求表上的IS锁，以及很多行上的S锁，由于申请的锁数目过多引起锁的升级。数据库管理器试图为该应用程序申请表上的S锁来减少所需要的锁的数目，但S锁与表上原有的IX锁冲突，锁升级不能成功。