DB2通用数据库的并发性

LOCKSIZE

LOCKSIZE 是 CREATE/ALTER TABLESPACE 语句的选项，在应用程序进程访问表空间中的表时，控制 DB2 UDB 获取的何种类型的锁（即，它决定该锁的"大小"，这有时也称作锁粒度）。该选项的可以是 LOB、TABLESPACE、TABLE、PAGE、ROW 和 ANY。

CREATE TABLESPACE 语句的 LOCKSIZE 参数默认为 ANY。LOCKSIZE ANY 允许 DB2 UDB 选择锁大小。DB2 UDB 通常将 LOCKSIZE PAGE 用于非 LOB 的表，而将 LOCKSIZE TABLESPACE 用于 LOB 表。

我建议在创建表空间时使用该默认值，除非您有理由进行其他选择。如果您选择修改 LOCKSIZE，那么就要根据使用该表空间的应用程序的性能监控结果和并发性特点来做决定。

使用何种大小的锁

在 DB2 V4 中才开始可以使用行级锁。之前，数据页是最小的锁定单元。I/T 行业中的许多人都假定行锁是并发性问题的灵丹妙药，但实际上，它并不能解决所有的并发性问题。在经历许多锁等待、死锁和超时的环境中，它也许提供了较大的改进。但在其他情形下，DB2 UDB 可能在获取更多锁上消耗资源，同时无法成比例地提高并发性。
因为 IRLM 获取、维护和释放行锁所需的处理与页面锁需要的大致相同，所以关于指定锁大小的决定其实就是在较高的锁定开销与并发性的潜在提高之间进行权衡。

因此，至于是使用页面锁还是使用行锁，这取决于您的数据和应用程序的特点。如果您觉察到使用页面锁定级别的表空间的数据页上存在大量竞争，那么就请考虑使用行锁。通过在行级别而非页面级别上进行锁定，可以极大地减少与其他应用程序进程的竞争，特别在访问是在随机的情况下。

但是，如果多个应用程序正以不同的顺序更新某一页上的相同行，那么行锁导致的竞争甚至可能比页面的还要多。这是因为，通过页面锁，第二个以及随后的应用程序在访问该页面之前，都必须等待第一个应用程序完成，而它们就可能超时。通过行锁，多个应用程序可以同时访问同一页上的行，但如果它们试图访问相同的行集，就可能死锁。

使用 LOCKSIZE TABLESPACE 或 LOCKSIZE TABLE 之前，用户必须相当确定没有其他重要的应用程序进程需要并发访问该对象。在任何表上指定 LOCKSIZE ROW 之前，极为明智的做法就是先对增加锁开销来提高并发性是否值得进行估计。

小型表

如果一个 DB2 UDB 表兼具尺寸小和高使用率的特点，那么就考虑使用 LOCKSIZE ROW，特别是每个页面中有许多行的时候。此外，因为表十分小，锁粒度将不会给锁开销带来较大的性能影响。

DB2 UDB 对象和授权的分组

通常总是将与同一应用程序逻辑相关的表分组到一个数据库中。理想情况是，每一个应用程序进程都引用尽可能少的 DB2 UDB 数据库。而且，要设法给用户不同的授权 ID 来使用不同的 DB2 UDB 数据库。实际上，这将增加可能应用程序进程的数目，同时可能减少每个应用程序进程可以访问的数据库数目。因此一般说来，"组合相似的事物"和"分开不同的事物"。

应用程序设计考虑

正如初始数据库设计一样，早在开发新的 DB2 UDB 应用程序之时就开始考虑并发性问题也很重要。更好的做法是，在实现之前，就将并发性原则包含到生产中去。然而，有时候并发性的提高可能取决于较新的 DB2 UDB 版本中的新功能以及与之接合的其他系统。在这些情况下，可能需要修改现有的应用程序，以便提高并发性水平。而在其他情况下，可能要等并发性问题发展和增长到一定的时候，才有必要对应用程序进行大量修改。以下是一些用以评估在某一时刻是开发新的 DB2 UDB 应用程序，还是修改现有的 DB2 UDB 应用程序的选项。

尽可能晚地访问关键资源

例如，设计和编写应用程序，以便 SQL 语句获取和更新 DB2 UDB 数据的时间尽可能地接近提交点。注意该问题将减少锁定数据的时间总量，从而减少其他应用程序进程无法使用该数据的时间。

尽可能快地提交工作

通常，在达到数据一致性临界点之后，尽快发出 COMMIT 语句是一种较好的 SQL 编程技术。该实践将有助于避免不必要的锁竞争，甚至在只读应用程序中也应该采用该实践。类似地，我们建议应用程序中一检测出 SQL 故障，就发出 ROLLBACK 语句。这将阻止未成功的 SQL 语句不必要地、过长时间地锁定 DB2 UDB 资源。

尽可能快地关闭游标

尽可能快地关闭游标是另一个可以帮助提高并发性的编程实践。通过尽快发出 CLOSE CURSOR 语句，应用程序将释放那些锁以及它们所持有的 DB2 UDB 资源。

应用程序重试逻辑

我建议应用程序中包含重试逻辑，即当程序接收死锁或超时状况的指示时，该应用程序代码应重试该操作，甚至允许重试多次。这就使得应用程序有可能从该状况中恢复，而无需操作人员从外部干涉或提供帮助。SQLCA 中的字段 SQLERRD(3) 返回一个理由码，指示是否发生了死锁或超时。