DB2隔离级别和锁 - 图文(4)

? 同样假设现在交易 2 插入一行 KEY VALUE 9 相应的行，这一行会加 W 锁，当插入新的 KEY 到索引的时候，KEY VALUE 12 对应的行会加 NW 锁。因为此时交易 1 对应的行上持有 X 锁，这时它不得不等待交易 1 释放掉该锁。

所以在 type-1 索引时，因为更改期间加锁的方式是 W 和 NW，所以很容易造成死锁，这会极大影响数据库的并发。 type-2 索引加锁算法

DB2 从 V8 以后所有新创建的索引都是 type-2 类型的索引。 type-2 索引可以大大減少 NEXT KEY 锁从而改进了性能，因为各项是标记为删除的而不是从页面中物理删除的 ( 伪删除 ) 。 type-2 索引同时允许索引列大于默认的 255 字节，同时还可以在线运行 REORG 和 RUNSTATS，并且支持新的多维群集 (MDC) 功能。在 DB2 V8 中，所有新的索引都是以 type-2 类型创建的，只有已经在表上定义了 ( 迁移前 ) type-1 索引的時候除外。可以使用 REORG INDEXES 将 type-1 索引转换为 type-2 索引。 Type-2 索引采用的是伪删除算法，图 6-2 是两种索引类型加锁的比较。

图 6-2 type-1 和 type-2 索引加锁比较

在 DB2 V8 之前的版本中，插入过程中可能使用 W 或 NW 锁，但是在 DB2 V8 以后只有在使用了隔离级别为 RR 的情况下才会出现这两种锁。因此，应尽可能避免这种情况。

6.2.7 扫描方式加锁情况

在 DB2 数据库中，不同的扫描方式在不同的隔离级别下加锁的情况也是不一样的，在 DB2 中主要有以下几种扫描方式：全表扫描、索引扫描和 RID 扫描 ( 注：如果使用了 MDC，那么还会有其他扫描方式，但此处我们不讨论 ) 。其中 RID 扫描也算是索引扫描。表 6-5 和表 6-6 总结了在全表和索引扫描方式下加锁的情况。

表 6-4 表扫描时在表 / 行上加锁情况

表 6-5 索引扫描时在表 / 行上的加锁情况

关于在不同隔离级别和扫描方式下表 / 行上的加锁情况，我们可以在 DB2 解释工具的输出中查看加锁情况。下面我们分别对全表扫描和索引扫描的加锁情况举例： 全表扫描加锁情况如下： dynexpln – d sample – q \ ---------------------------- 略 -------------------------- | Isolation Level: Repeatable Read | Lock Intents | | Table: Share | | Row : None | Sargable Predicate(s) ---------------------------- 略 ------------------------------ dynexpln – d sample – q \| Relation Scan --注：全表扫描 | | Prefetch: Eligible| Isolation Level: Read Stability --注：隔离级别为RS | Lock Intents| | Table: Intent Share --注：表上加IS锁 | | Row : Next Key Share--注：行上加 NS 锁 | Sargable Predicate(s)

索引扫描加锁情况如下：

dynexpln – d sample – q \ ---------------------------- 略 -------------------------- | Index Scan: Name = ORACLE.PK_EMPLOYEE ID = 1 | | Regular Index (Not Clustered) | | Index Columns: | | | 1: EMPNO (Ascending) | #Columns = 13 | Volatile Cardinality | Single Record | Fully Qualified Unique Key | #Key Columns = 1 | | Start Key: Inclusive Value | | | | 1: '000100' | | Stop Key: Inclusive Value | | | | 1: '000100' | Data Prefetch: None | Index Prefetch: None| Isolation Level: Read Stability --注：隔离级别为RS | Lock Intents| | Table: Intent Share --注：表上加IS锁 | | Row : Next Key Share --注：行上加NS锁

通过上面两个例子，我们希望读者能够明白关于扫描方式和隔离级别的加锁情况，关键是如何分析加锁情况。

回页首

6.3 乐观锁

6.3.1 悲观锁定和乐观锁定

悲观锁定

DB2 默认情况下都是采用悲观锁定方式工作，本节上面讲述的各个例子都属于这种情况。

悲观锁定策略的前提是，另一个用户很可能试图修改您正在修改的某个表行。如果选择了某个行，并检测到其他用户试图对该行执行更新或删除操作，那么该行将在这段时间内持有锁 ( 例如，通过使用 RR 隔离级别或以排它锁 (X) 模式锁定表 ) 。悲观锁定的优点就是能够保证实现一致且安全的更改。但是这种锁定策略的主要缺点就是并发性较差。对于具有大量用户或运行长期事务的系统，或者涉及大量 SQL 操作的事务，需要等待锁释放的概率则会增加。

图 6-3 阐释了悲观锁定的功效。事务 1 读取某条特定记录并对该行应用一个锁，并且需要花些时间确定是否要对这个行执行更新操作。同时，事务 2 希望访问这个行，但是它必须等待事务 1 释放该行的锁。也就是说，只有事务 1 释放锁后，事务 2 才能收到SELECT操作的结果并继续执行它的业务逻辑。

图 6-3 悲观锁定的工作示意图

乐观锁定

悲观锁定方法的主要问题是事务之间必须互相等待。避免发生这种情况的方法就是使用乐观锁定策略，即假设在修改某行时，另一个用户试图对这一行进行修改的可能性极低。如果确实对这一行进行了修改，那么更新或删除操作将会失败，应用程序逻辑将处理这些失败，例如重新尝试选择。通过使用这种方法，使得事务在对行执行选择、更新或删除操作期间，不会持有行锁。但是，由此产生的问题是需要一种方式确保数据在被读取和修改期间没有发生变化。尽管应用程序需要更多的重试逻辑，但乐观锁定策略的主要优点是通过最小化给定资源对其他事务的不可用时间，来减少锁竞争，同时不会牺牲数据完整性 ( 虽然乐观锁定刚刚被引入 DB2 FOR Linux/UNIX/Windows，但是早已被提供给 DB2 FOR z/OS 用户 ) 。因此，它具有比悲观锁定更好的伸缩性。

图 6-4 阐释了乐观锁定背后的思想。与图 6-3 类似，事务 1 读取某个特定记录，但随后即释放锁。因此，事务 2 现在可以顺利地对同一行进行检索。在提交事务之前，事务 1 和事务 2 都必须检查该行在执行前面的SELECT之后是否发生改变。如果发生了一处修改，事务就必须重新执行新的SELECT来检索当前数据。然而，若该行在执行SELECT之后未发生变化，则可以成功更新数据。

图 6-4 乐观锁定的工作示意图

6.3.2 DB2 V9.5 的乐观锁定

DB2 V9.5 的乐观锁定特性最小化了给定资源对于其他事务的不可用时间，进一步改善了并发性。由于数据库管理器能够确定某一行何时会被修改，因此可以保证数据完整性，同时限制持有锁的时间。通过实现乐观并发控制，数据库管理器可以在完成读操作后立即释放行或页锁。

DB2 V9.5 支持的乐观锁定特性简便、快捷，并且不会产生误判 (False Positive) 。这一特性通过如下所示的新 SQL 函数、表达式和特性来实现：

?

行标识符(RID_BIT或RID)内置函数：该内置函数可用于SELECT列表或谓词语句。例如，在谓词“WHERE RID_BIT(tab)=? ”中，RID_BIT等于谓词被实现为一种新的直接访问方法，从而可以更有效地定位行。在 DB2 V9.5 以前，这种称为值乐观锁定的技术确定值的方式为：将所有选择的列值添加到谓词，然后应用某些唯一的列组合来筛选出单个行，这种访问方法效率较低。

?

ROW CHANGE TOKEN表达式：这种新的表达式返回一个标记作为 BIGINT 。这个标记表

示某一行的修改序列中的一个相对点。应用程序可以将某行的当前行修改标记值与上次取回行时保存的行修改标记值进行比较，以判断行是否发生修改。

?

基于时间的更新检测：这个特性通过ROW CHANGE TIMESTAMP表达式添加到 SQL 中。要支持这一特性，表需要定义一个新生成的行修改时间戳列来保存时间戳值。这可以通过ALTER

TABLE语句添加到现有表，或者在创建新表时定义行修改时间戳列。是否提供行修改时间戳列

还将影响乐观锁定的行为，因为该列有助于将行修改标记的粒度从页级别提高到行级别，这对乐观锁定应用程序非常有利。

? 隐式隐藏列：从兼容性方面来说，这个特性有助于将行修改时间戳列应用到现有表和应用程序。在使用隐式列列表时，隐式隐藏列不会被外部化。例如，对表执行SELECT* 时不会在结果表中返回隐式隐藏的列，并且执行不包含列列表的INSERT语句时也不会要求提供隐式隐藏列的值，但是隐式隐藏列必须定义为允许 NULL 值或具有另一个默认值。

使用上述编程模型的应用程序将从增强的乐观锁定特性中获益。注意，未使用这种编程模型的应用程序被认为是非乐观锁定应用程序，它们将按照以前的方式工作。

百度搜索“77cn”或“免费范文网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读，免费范文网，提供经典小说教育文库DB2隔离级别和锁 - 图文(4)在线全文阅读。