当前已落实（Currently Committed）工作原理

    从 DB2 V9.7 开始，DB2 通过采用完全锁定避免（full lock avoidance techniques）技术，当能够明确获得数据或者页的“已落实”版本时，允许扫描避免使用行级锁。当无法获知索引或行记录是否已落实时，扫描将改为使用传统的锁定方式。 DB2 通过在行级锁定中增加新的反馈机制，来标识哪些“日志记录”描述了该行的首次修改（从该行的首次修改，就可以获得修改前的数据值，也就是该行的已落实版本），当发生一个锁冲突时锁管理器将使用该反馈机制直接返回这些日志记录编号。一个当前已落实扫描将用使用该反馈结果，用来从日志（日志缓冲区中或者活动日志文件中）访问该行的“当前已落实”版本（也就是首次更新之前的结果值）。未提交的插入行在行级锁中是直接被标识的，允许“当前已落实”扫描直接忽略或跳过该行。

    具体如图 1 所示，emp 表有 5 条记录，其中第二行和第四行插入操作已经完成，描述该插入操作的日志记录已经存储在使用 TSM 归档的带库中，具体如图 1 中右下方红色部分所示；第三行正处于更新状态（还没落实），记录该行的日志记录处于磁盘中的活动日志文件中，该日志记录描述了第三行的首次更改情况，具体如图 1 右边中间黄色部分所示；第五行正处于插入状态（还没落实），记录该行的日志记录处于磁盘中的活动日志文件中，该日志记录描述了第五行的首次插入情况，具体如图 1 右边中间黄色部分所示；第一行正处于删除状态（还没落实），记录该行的日志记录处于日志缓冲区中，该日志记录描述了第一行的首次更改情况，具体如图 1 右边上方绿色部分所示；图 1 中间的 Locklist 部分表示锁管理器，在锁管理器中描述了第一行、第三行、第五行处于 X 锁状态，与这些行对应的日志记录也在该锁管理器中，这就是 DB2 V9.7 对行级锁定新增的反馈机制，来标识哪些“日志记录”描述了该行的首次修改，当发生一个锁冲突时锁管理器将使用该反馈机制直接返回这些日志记录编号，如黑色箭头所示。当其他应用试图读取第一行或第三行时，将会直接从日志缓冲区或日志文件中返回该行的“已落实”版本数据。而对未提交的第五行，扫描将直接忽略或跳过该行。

    “当前已落实”是通过从日志中获取数据的可用性的（即从日志中获取已落实版本的数据），DB2 首先会从日志缓冲区中查找数据。当更新事务仍处于活动状态时，已落实版本数据会处于日志缓冲区或磁盘上的活动日志文件中。通过行级锁定中新增的反馈机制，DB2 不需要对所有日志文件进行搜索来查找已落实版本数据，而是直接访问合适的日志文件以及文件中的记录（直接 I/O 访问取代了对所有日志记录的扫描）。当 DB2 无法在活动日志文件中找到相关记录时，DB2 将切换到“当前已落实”不启用的状态，即读操作会等待写操作落实。

    需要注意的是，启用“当前已落实”特性需要更多的日志表空间，因为记录一个事务内某行的第一次更新需要额外的空间。当检索该行的“当前已落实”映像（也就是第一次修改前的值）时将会用到这些日志数据。根据工作负载的不同，增加的日志数据对需要使用的总日志空间有一个微不足道的或可衡量的影响。当 cur_commit 数据库配置参数不启用时，将不需要额外的日志空间。如果日志文件所在磁盘存在大量读操作或者磁盘使用率比较高，可以考虑适当增加日志缓冲区参数 logbufsz 的大小。如果增加 logbufsz 的大小，还需要考虑增加 dbheap 数据库配置参数的大小，因为 logbufsz 所控制的日志缓冲区使用的内存空间是受 dbheap 参数控制的。

    默认情况下，新创建的数据库“当前已落实”处于开启状态，这将允许任何的应用程序从这个新特性中获益（不需要对现有的应用做任何的更改）。如果你的数据库是从之前的版本升级上来的，那么默认情况下，“当前已落实”设置是处于不启用状态的。你可以通过数据库配置参数 cur_commit 来启用或不启用“当前已落实”设置。同时，你还可以通过使用带 CONCURRENTACCESSRESOLUTION 选项的 BIND 和 PRECOMPILE 命令，对某个独立的应用单独设置“当前已落实”，以替代数据库级别的设置。