DB2 for z/OS 客户正在将新的、尖端的数据仓库任务添加到传统 OLTP 中。
为支持多个系统以及应对那些往往缺乏真知灼见的应用程序开发人员和主管，使得 DBA 工作充满挑战。幸运的是，DB2 9 for z/OS 提供了一种全新的乐观锁定特性，可以提高系统性能——或许也能使 DBA(和应用程序开发人员)的心态乐观起来。
数据库锁定是必不可少的开销，也是所有 DBMS 的核心组件。锁通过防止多个事务在同一时间更改相同的数据来维护数据完整性。但获取和维护数据库锁的成本可能非常高昂，对于复杂的系统、应用程序或事务来说更是如此。
乐观锁定现使用 DB2 表中定义的新特性来减少死锁、降低总体锁定开销，并提升系统和应用程序的性能。
要使用乐观锁定的新特性，您需要使用新参数(GENERATED ALWAYS、FOR EACH ROW ON UPDATE、AS ROW CHANGE TIMESTAMP)在DB2表内定义新的 ROW CHANGE TIMESTAMP 列，如下所示：
清单 1. 使用乐观锁定的新特性
CREATE TABLE BEULKE.PRODUCT_TBL (
PROD_NBR INTEGER NOT NULL,
PROD_INVENTORY INTEGER NOT NULL,
PROD_LAST_UPD NOT NULL
GENERATED ALWAYS
FOR EACH ROW ON UPDATE
AS ROW CHANGE
TIMESTAMP);
这些参数告诉 DB2，应该总是填充并特别注意时间戳和表。最后更新的时间戳已经内嵌在某些应用程序中多年了;IBM 如今承认并改进了这种技术。
这些新特性使 DB2 能够检索特定时间段内的行，能够了解它们的最后修改时间。DB2 不仅关注行时间戳信息，还关注记录 ID(RID)和变更标记信息。关注行属性使应用程序和用户能够通过时间戳查询数据库，根据 WHERE 时间戳子句标准获取一个特定的行或一组行。
新的列特性允许大多数应用程序回弹从而降低了锁定开销，还将锁定配置文件从 Repeatable Read(RR)、Read Stability(RS)或Cursor Stability(CS)还原为 Uncommitted Read(UR)。Uncommitted Read 避免了数据库锁定;应用程序可以通过在应用程序 UPDATE SQL 语句中使用新的时间戳列来维护数据库事务完整性。新时间戳列提供了行的时间戳和记录 ID(RID)，DB2 可用此信息来验证无其他应用程序更改了所需数据。
另外一条 DB2 9 SQL 短语——SKIP LOCKED DATA，也有助于避免锁定，因为它不会使用不兼容的锁来检索或影响数据行。可以在 SELECT、UPDATE 和 DELETE 等 SQL 语句中使用该短语来避免死锁。使用隔离级别的 UR 和 SKIP LOCKED DATA 短语时应倍加谨慎。尽管这些技术能够显著减少锁定数量、提升性能，但需要您透彻理解自己的应用程序。在使用这种性能提升技术之前，应详细研究每一个应用程序，还应阅读 DB2 手册，查看所有细节。由于这些技术能够大幅减少死锁和锁定开销——特别是在数据共享环境中，因此值得为此付出研究和实现的时间。
