5.锁
缺省情况下，每一个插入的行之上都有一个X锁，这个锁是在该行创建时就开始有的，一直到insert被提交。有两个跟insert和锁相关的性能问题：
◆为获得和释放锁而产生的CPU开销。
◆可能由于锁冲突而导致的并发问题。
对于经过良好优化的批量插入，由获得每一行之上的一个X锁以及后来释放该锁引起的CPU开销是比较可观的。对于每个新行之上的锁，惟一可以替代的是表锁(DB2中没有页锁)。当使用表锁时，耗时减少了3%。有3种情况可以导致表锁的使用，在讨论表锁的缺点之前，我们先用一点时间看看这3种情况：
运行ALTERTABLELOCKSIZETABLE。这将导致DB2为随后使用该表的所有SQL语句使用一个表锁，直到locksize参数改回到ROW。
运行LOCKTABLEINEXCLUSIVEMODE。这将导致表上立即上了一个X锁。注意，在下一次提交(或回滚)的时候，这个表将被释放，因此，如果您要运行一个测试，测试中每N行提交一次，那么就需要在每次提交之后重复执行LOCKTABLE。
使用缺省锁，但是让LOCKLIST和MAXLOCKS数据库配置参数的值比较小。当获得少量的行锁时，行锁就会自动地逐渐升级为表锁。
当然，所有这些的缺点就在于并发的影响：如果表上有一个X锁，那么其他应用程序除非使用了隔离级别UR(未提交的读)，否则都不能访问该表。如果知道独占访问不会导致问题，那么就应该尽量使用表锁。但是，即使您坚持使用行锁，也应记住，在批量插入期间，表中可能存在数千个有X锁的新行，所以就可能与其他使用该表的应用程序产生冲突。通过一些方法可以将这些冲突减至最少：
确保锁的升级不会无故发生。您可能需要加大LOCKLIST和/或MAXLOCKS的值，以允许插入应用程序有足够的锁。
对于其他的应用程序，使用隔离级别UR。
对于V8FixPak4，或许也可以通过DB2_EVALUNCOMMITTED注册表变量来减少锁冲突：如果将该变量设置为YES，那么在很多情况下，只能获得那些符合某个谓词的行上的锁，而并不是获得被检查的所有行上的锁。
发出一个COMMIT命令以释放锁，因此如果更频繁地提交的话就足以减轻锁冲突的负担。
注意
在V7中，存在涉及insert和键锁的并发问题，但是在V8中，由于提供了type-2索引，这些问题实际上已经不见了。如果要迁移到V8中来，那么应该确保使用带CONVERT关键字的REORGINDEXES命令，以便将索引从type-1转换为type-2。
在V7中，插入过程中可能使用W或NW锁，但是在V8中只有在使用了type-1索引或者隔离级别为RR的情况下才会出现这两种锁。因此，应尽可能避免这两种情况。
一条insert所据有的锁(通常是一个X锁)通常不会受隔离级别的影响。例如，使用隔离级别UR不会阻止从插入的行上获得锁。然而，如果使用了INSERT...SELECT，则隔离级别将影响从SELECT获得的锁。