DB2中的maxlocks locklist 参数

wxin

　　maxlocks数据库配置参数用于指定触发锁定升级的百分比。获取触发锁定升级的锁定的表可能不受影响。每个锁在内存中都需要一定的内存空间，为了减少锁需要的内存开销，DB2提供了锁升级这一功能。锁升级是通过对表加上非意图性的表锁，同时释放行锁来减少锁的数目，从而达到减少锁需要的内存开销的目的的。锁升级由数据库管理器自动完成，数据库的配置参数锁列表页面数(LOCKLIST)和应用程序占有百分比(MAXLOCKS)直接影响锁升级的处理.
　　应用程序超出允许它具有的总的锁内存百分比(MAXLOCKS值)的情况。因此，数据库执行锁升级，将应用程序的锁内存百分比降低到MAXLOCKS指定的百分比之下。下图说明了更为常见的情况：到达总的锁内存限制，因此执行锁升级来释放锁内存。
　　锁升级问题可以通过增加LOCKLIST和MAXLOCKS数据库参数的大小来解决。但是，如果仍然遇到锁定问题，应检查是否因未能提交事务而未释放已更新行上的锁。
　　每个数据库都有一个锁列表，该列表包含所有同时连接到数据库的应用程序所持有的锁。在32位平台上，一个对象上的第一个锁要求占64字节，而其他的锁要求占32字节。在64位平台上，第一个锁要求占112字节，而其他锁要求占56字节。
　　当一个应用程序使用的LOCKLIST的百分比达到MAXLOCKS时，数据库管理器将执行一次锁升级(lockescalation)，在这个操作中将使行锁转换成单独的一个表锁。而且，如果LOCKLIST快要耗尽，数据库管理器将找出持有一个表上最多行锁的连接，并将这些行锁转换成表锁，以释放LOCKLIST内存。锁定整个表会大大降低并发性，死锁的几率也就增加了。
　　●<wbr><wbr><wbr><wbr><wbr><wbr>LOCKLIST表明分配给锁列表的存储容量。每个数据库都有一个锁列表，锁列表包含了并发连接到该数据库的所有应用程序所持有的锁。锁定是数据库管理器用来控制多个应用程序并发访问数据库中数据的机制。行和表都可以被锁定。</wbr></wbr></wbr></wbr></wbr></wbr>
　　●<wbr><wbr><wbr><wbr><wbr><wbr>MAXLOCKS定义了应用程序持有的锁列表的百分比，在数据库管理器执行锁升级之前必须填充该锁列表。当一个应用程序所使用的锁列表百分比达到MAXLOCKS时，数据库管理器会升级这些锁，这意味着用表锁代替行锁，从而减少列表中锁的数量。当任何一个应用程序所持有的锁数量达到整个锁列表大小的这个百分比时，对该应用程序所持有的锁进行锁升级。如果锁列表用完了空间，那么也会发生锁升级。数据库管理器通过查看应用程序的锁列表并查找行锁最多的表，来决定对哪些锁进行升级。如果用一个表锁替换这些行锁，将不再会超出MAXLOCKS值，那么锁升级就会停止。否则，锁升级就会一直进行，直到所持有的锁列表百分比低于MAXLOCKS。MAXLOCKS参数乘以MAXAPPLS参数的值不能小于100。</wbr></wbr></wbr></wbr></wbr></wbr>
　　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，因为在这些条件下锁列表空间中不会有太多争用。
　　锁升级会在以下两种情况下被触发：
　　●<wbr><wbr><wbr><wbr><wbr><wbr>某个应用程序请求的锁所占用的内存空间超出了MAXLOCKS和LOCKLIST的乘积大小。这时，数据库管理器将试图通过为提出锁请求的应用程序申请表锁，并释放行锁来节省空间。</wbr></wbr></wbr></wbr></wbr></wbr>
　　●<wbr><wbr><wbr><wbr><wbr><wbr>在一个数据库中已被加上的全部锁所占的内存空间超出了LOCKLIST定义的大小。这时，数据库管理器也将试图通过为提出锁请求的应用程序申请表锁，并释放行锁来节省空间。</wbr></wbr></wbr></wbr></wbr></wbr>
　　虽然升级过程本身并不用花很多时间，但是锁定整个表(相对于锁定个别行)降低了并发性，而且数据库的整体性能可能会由于对受锁升级影响的表的后续访问而降低。
　　在设计良好的数据库中，很少发生锁定升级。如果锁定升级将并行性降低到不可接受的程度(由lock_escalation监视元素监视)，那么就需要分析问题并决定如何解决此问题。
　　锁升级是有可能失败的，比如，现在一个应用程序已经在一个表上加有IX锁，表中的某些行上加有X锁，另一个应用程序又来请求表上的IS锁，以及很多行上的S锁，由于申请的锁数目过多引起锁的升级。数据库管理器试图为该应用程序申请表上的S锁来减少所需要的锁的数目，但S锁与表上原有的IX锁冲突，锁升级不能成功。
　　如果锁升级失败，引起锁升级的应用程序将接到一个–912的SQLCODE。
　　下面我们举一个实际的例子。
　　首先，运行下面的命令以打开针对锁的DB2监视器：
　　db2 -v update monitor switches using lockon
　　db2 -v terminate
　　然后收集数据库快照：
　　db2 -v get snapshot for database on sample | grep–i lock
　　在快照输出中，检查下列各项：
　　Locks held currently = 21224
　　Lock waits = 24683
　　Time database waited on locks (ms) =32875
　　Lock list memory in use (Bytes) =87224
　　Deadlocks detected = 89
　　Lock escalations = 8
　　Exclusive lock escalations =12
　　Agents currently waiting on locks =0
　　Lock Timeouts = 0
　　Internal rollbacks due to deadlock =0
　　如果“Lock list memory in use(Bytes)”超过定义的LOCKLIST大小的50%，那么就增加LOCKLIST数据库配置参数中的4KB页的数量。
　　如果发生了“Lockescalations>0”或“Exclusive lockescalations>0”，则应该或者增大LOCKLIST或者MAXLOCKS，抑或同时增大两者。查看“Locksheld currently”、“Lock waits”、“Time database waited on locks(ms)”、“Agents currentlywaiting on locks”和“Deadlocksdetected”中是否存在高值，如果有的话，就可能是差于最优访问计划、事务时间较长或者应用程序并发问题的症状。