DB2 V9.7 当前已落实(Currently Committed)
2009-12-18 00:00:00 来源:WEB开发网DB2 V9.7 引入了一系列新特性,使客户可以更轻松地节省 IT 成本。具体包括压缩增强、pureXML 增强、易用性增强、监控增强、工作负载管理增强、安全性提高、性能提高、应用开发提高、SQL PL 语言支持、SQL 兼容性提高和高可用、备份、日志、弹性、恢复提高等。本文的重点是介绍“当前已落实”新特性,该新特性的显著特点是在游标稳定性隔离级别时可以明显减少锁等待的出现,以及死锁的出现频率。通过使用“当前已落实”的 CS 隔离级别,可以有效提升高吞吐量事务处理环境下的数据库性能。从 DB2 V9.7 开始,DB2 通过采用完全锁定避免技术,当能够明确获得数据或者页的“已落实”版本时,允许扫描避免使用行级锁。当无法获知索引或行记录是否已落实时,扫描将改用使用传统的锁定方式。未提交的插入行在行级锁中是直接被标识的,允许“当前已落实”扫描直接忽略或跳过该行。
简介
从 IBM DB2 V9.7 开始,DB2 引入了一系列新特性,使客户可以更轻松地节省 IT 成本。具体包括压缩增强(通过对 XML 数据、临时表、索引、数据复制源表的压缩支持,进一步减少了对存储的需求,提高了 I/O 的效率,提高了对磁盘数据的快速访问)、pureXML 增强(通过对 pureXML 功能的进一步增强,使得数据仓库中可以部署和分析 XML 数据;现在 XML 可以在表分区、MDC 表、临时表、用户函数、分区数据库环境中使用)、易用性增强(通过对易用性的增强,减少了总体拥有成本 TCO,减少了执行系统管理任务对系统的影响,扩展了以前版本发布的自治特性)、监控增强(可以更灵活、更高粒度的监控 DB2 环境)、工作负载管理增强(新增调配正在进行的活动的优先级、与 Linux 工作负载管理 WLM 集成、对服务类提高缓冲池中 I/O 优先级控制等,新增了 AGGSQLTEMPSPACE、CPUTIME、CPUTIMEINSC、SQLROWSREAD、SQLROWSREADINSC 等阈值,改进了基于时间的阈值 ACTIVITYTOTALTIME、CONNECTIONIDLETIME 的粒度)、安全性提高(可以对敏感数据进行更好的保护)、性能提高(通过在游标稳定性隔离级别下引入“当前已落实”、扫描共享、在表分区上创建分区索引、在表中存储内嵌 LOB 文件等提高了对数据的访问速度,增加了数据的并发性; DB2 优化器通过访问计划重用、Statement concentrator 支持等增强了 DB2 的性能)、应用开发提高(通过“使用 ALTER TABLE 重命名列名”等简化了数据库对象的管理,通过引入 TRUNCATE 语句、创建临时表、公共同义词等很多新的功能提高了 SQL 编程、存储过程开发得到了简化和提高等)、SQL PL 语言支持、SQL 兼容性提高(可以从诸如 ORACLE 应用程序等更容易的迁移到 DB2 环境中)和高可用、备份、日志、弹性、恢复提高等。
本文的重点是介绍“当前已落实”(currently committed semantics,以后会简称 CC)新特性,该新特性的显著特点是在游标稳定性(Cursor stability,以后会简称 CS)隔离级别时可以明显减少锁等待的出现,以及死锁的出现频率。
在 DB2 V9.7 之前的版本中,当我们使用游标稳定性隔离级别(默认的隔离级别)时,一般只锁定事务声明并打开的游标当前引用的行,也就是说该事务一般只锁定当前行,对当前行以外的记录不做锁定;对其所获取的锁一直有效,直到游标重定位或事务终止为止。如果游标重定位,原来行上的锁就被释放,并获得游标现在引用的行上的锁。如果事务修改了它检索到的任何行,那么在事务终止之前,其他事务不能更新或删除该行,即使游标不再位于被更新或删除的行。需要注意:如果只检索的话,一般只锁定当前行;如果对检索的行还进行了更新或删除的话,则对修改的行也进行了锁定,即便指针移向了其他行,对修改行的锁定还是存在。而对修改行的锁定会阻止其他应用程序读取该行,直到对修改行的锁定解除后(对该修改落实后),其他应用才能读取该行。
我们首先来看一下 ORACLE 在 Snapshot 隔离级别下读操作与写操作堵塞的情况,具体如表格 1 所示,当读操作遇上读操作、读操作遇上写操作和写操作遇上读操作都不会发生堵塞,而写操作遇上写操作时则会发生堵塞:
表 1. ORACLE Snapshot 隔离级别情况下的的堵塞情况
先出现的工作负载 \ 后出现的工作负载 | 读工作负载 | 写工作负载 |
读工作负载 | 否(不堵塞) | 否(不堵塞) |
写工作负载 | 否(不堵塞) | 是(堵塞) |
下面我们看一下在 DB2 V9.7 之前的版本中使用游标稳定性隔离级别时读操作与写操作堵塞的情况,具体如表格 2 所示,当读操作遇上读操作时不会发生堵塞;当读操作遇上写操作时可能会发生堵塞(FOR READ ONLY 的读操作不会堵塞写操作,而 FOR UPDATE 的读操作由于其行上有 U 锁,会堵塞写操作);当写操作遇上读操作时一定会发生堵塞,而当写操作遇上写操作时同样会发生堵塞。
表格 2 . DB2 V9.7 之前的版本中使用 CS 隔离级别情况下的堵塞情况
先出现的工作负载 \ 后出现的工作负载 | 读工作负载 | 写工作负载 |
读工作负载 | 否(不堵塞) | 可能 |
写工作负载 | 是(堵塞) | 是(堵塞) |
再看一下在 DB2 V9.7 中,启用“当前已落实”的游标稳定性隔离级别时的读操作与写操作堵塞的情况,具体如表格 3 所示,可以看到比 DB2 之前的版本有了明显的改进,当读操作遇上读操作、读操作遇上写操作和写操作遇上读操作都不会发生堵塞,只有写操作遇上写操作时才会发生堵塞:
表格 3 . DB2 V9.7 中启用“当前已落实”的 CS 隔离级别情况下的堵塞情况
先出现的工作负载 \ 后出现的工作负载 | 读工作负载 | 写工作负载 |
读工作负载 | 否(不堵塞) | 否(不堵塞) |
写工作负载 | 否(不堵塞) | 是(堵塞) |
在 DB2 V9.7 中,在游标稳定性隔离级别下,通过启用“当前已落实”新特性,一个读操作已经不需要再等待该变更落实后再返回值,而是直接返回该行未变更前的值(也就是当前已落实的结果值,忽略任何可能发生的未落实操作)。不过需要注意的是在可更新游标中存在例外的情况:如果某行基于它自己之前的内容被更新过,当前已落实结果无法立即返回。
在游标稳定性隔离级别使用行级锁的情况(没有启用“当前已落实”)下,可能会出现锁定超时和死锁,特别是那些没有为防止这些问题进行特殊设计的应用程序。某些高吞吐量数据库应用程序不能容忍事物处理过程中的锁等待,某些应用不能容忍处理未提交的数据,但仍然需要不堵塞读操作事务。通过在 CS 隔离级别下启用“当前已落实”,可以有效提高高吞吐量事务处理环境下的数据库性能。在这些环境中,过多的锁等待是不能容忍的,通过启用“当前已落实”的 CS 隔离级别,可以有效的减少 timeout 和 deadlocks 。在“当前已落实”启用的情况下,只有落实的数据才会被返回,就像之前的例子,现在读操作不需要再等待更新操作释放行级锁了,读操作将直接返回“当前已落实”版本的数据(也就是首次写操作之前的值)。
由于“当前已落实”是 DB2 V9.7 的新特性,很多客户不知道该如何使用,本文将重点介绍 DB2 V9.7 关于“当前已落实”新特性以及相关的概念,并结合实际的例子帮助大家理解和提高。
当前已落实(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 对行级锁定新增的反馈机制,来标识哪些“日志记录”描述了该行的首次修改,当发生一个锁冲突时锁管理器将使用该反馈机制直接返回这些日志记录编号,如黑色箭头所示。当其他应用试图读取第一行或第三行时,将会直接从日志缓冲区或日志文件中返回该行的“已落实”版本数据。而对未提交的第五行,扫描将直接忽略或跳过该行。
图 1. “当前已落实”(Currently Committed)工作原理
查看原图(大图)
“当前已落实”是通过从日志中获取数据的可用性的(即从日志中获取已落实版本的数据),DB2 首先会从日志缓冲区中查找数据。当更新事务仍处于活动状态时,已落实版本数据会处于日志缓冲区或磁盘上的活动日志文件中。通过行级锁定中新增的反馈机制,DB2 不需要对所有日志文件进行搜索来查找已落实版本数据,而是直接访问合适的日志文件以及文件中的记录(直接 I/O 访问取代了对所有日志记录的扫描)。当 DB2 无法在活动日志文件中找到相关记录时,DB2 将切换到“当前已落实”不启用的状态,即读操作会等待写操作落实。
需要注意的是,启用“当前已落实”特性需要更多的日志表空间,因为记录一个事务内某行的第一次更新需要额外的空间。当检索该行的“当前已落实”映像(也就是第一次修改前的值)时将会用到这些日志数据。根据工作负载的不同,增加的日志数据对需要使用的总日志空间有一个微不足道的或可衡量的影响。当 cur_commit 数据库配置参数不启用时,将不需要额外的日志空间。如果日志文件所在磁盘存在大量读操作或者磁盘使用率比较高,可以考虑适当增加日志缓冲区参数 logbufsz 的大小。如果增加 logbufsz 的大小,还需要考虑增加 dbheap 数据库配置参数的大小,因为 logbufsz 所控制的日志缓冲区使用的内存空间是受 dbheap 参数控制的。
默认情况下,新创建的数据库“当前已落实”处于开启状态,这将允许任何的应用程序从这个新特性中获益(不需要对现有的应用做任何的更改)。如果你的数据库是从之前的版本升级上来的,那么默认情况下,“当前已落实” 设置是处于不启用状态的。你可以通过数据库配置参数 cur_commit 来启用或不启用“当前已落实”设置。同时,你还可以通过使用带 CONCURRENTACCESSRESOLUTION 选项的 BIND 和 PRECOMPILE 命令,对某个独立的应用单独设置“当前已落实”,以替代数据库级别的设置。
示例
在示例数据库 SAMPLE 中,存在 RHETTE.EMPLOYEE 和 RHETTE.DEPARTMENT 两张表,我们分别打开两个 DB2 CLP 窗口,分别称为窗口 1 和窗口 2,在窗口 1 中连上示例数据库 SAMPLE,更新表 RHETTE.EMPLOYEE,并试图读取表 RHETTE.DEPARTMENT,在窗口 2 中连上示例数据库 SAMPLE,更新表 RHETTE.DEPARTMENT,并试图读取表 RHETTE.EMPLOYEE,如果不启用“当前已落实”,将会产生一个死锁,并使其中一个应用程序失败,具体如清单 1 所示:
清单 1. 不启用 CC 情况下读操作与写操作堵塞示例- - 窗口 1
C:\> db2 connect to sample
数据库连接信息
数据库服务器 = DB2 / NT 9.7.0
SQL 授权标识 = RHETTE
本地数据库别名 = SAMPLE
C:\> db2 update db cfg using cur_commit DISABLED
DB20000I UPDATE DATABASE CONFIGURATION 命令成功完成。
SQL1363W 未动态更改为立即修改而提交的一个或多个参数。
对于这些配置参数,必须在所有应用程序都与此数据库断开连接之后,更改才会生效。
C:\> db2 force applications all
DB20000I FORCE APPLICATION 命令成功完成。
DB21024I 此命令为异步的,可能未能立即生效。
C:\>db2 get db cfg | find "CUR_COMMIT"
当前已落实 ( CUR_COMMIT ) = DISABLED
C:\> db2 connect to sample
数据库连接信息
数据库服务器 = DB2 / NT 9.7.0
SQL 授权标识 = RHETTE
本地数据库别名 = SAMPLE
C:\> db2 +c update rhette.employee set firstnme = ' CHRISTINE1 ' where empno = 00010
DB20000I SQL 命令成功完成。
C:\> db2 +c select * from rhette.department
DEPTNO DEPTNAME MGRNO ADMRDEPT LOCATION
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
A00 SPIFFY COMPUTER SERVICE DIV. 000010 A00 -
B01 PLANNING 000020 A00 -
C01 INFORMATION CENTER 000030 A00 -
D01 DEVELOPMENT CENTER - A00 -
D11 MANUFACTURING SYSTEMS 000060 D01 -
D21 ADMINISTRATION SYSTEMS 000070 D01 -
E01 SUPPORT SERVICES 000050 A00 -
E11 OPERATIONS 000090 E01 -
E21 SOFTWARE SUPPORT 000100 E01 -
F22 BRANCH OFFICE F2 - E01 -
G22 BRANCH OFFICE G2 - E01 -
H22 BRANCH OFFICE H2 - E01 -
I22 BRANCH OFFICE I2 - E01 -
J22 BRANCH OFFICE J2 - E01 -
14 条记录已选择。
- - 窗口 2
C:\> db2 connect to sample
数据库连接信息
数据库服务器 = DB2 / NT 9.7.0
SQL 授权标识 = RHETTE
本地数据库别名 = SAMPLE
C:\> db2 +c update rhette.department set deptname = ' PLANNING1 ' where deptno = 'B01'
DB20000I SQL 命令成功完成。
C:\> db2 +c select * from rhette.employee
SQL0911N 因为死锁或超时,所以当前事务已回滚。原因码为 " 2 " 。 SQLSTATE = 40001 。
现在我们在窗口 1 中对示例数据库 SAMPLE 启用“当前已落实”,再次重复上面的操作,可以发现 2 个窗口应用程序都执行成功,没有发生读操作等待写操作(同样没有发生死锁),具体如清单 2 所示:
清单 2. 启用 CC 情况下读操作与写操作不堵塞示例- - 窗口 1
C:\> db2 update db cfg using cur_commit on
DB20000I UPDATE DATABASE CONFIGURATION 命令成功完成。
SQL1363W 未动态更改为立即修改而提交的一个或多个参数。
对于这些配置参数,必须在所有应用程序都与此数据库断开连接之后,更改才会生效。
C:\> db2 force applications all
DB20000I FORCE APPLICATION 命令成功完成。
DB21024I 此命令为异步的,可能未能立即生效。
C:\> db2 connect to sample
数据库连接信息
数据库服务器 = DB2 / NT 9.7.0
SQL 授权标识 = RHETTE
本地数据库别名 = SAMPLE
C:\> db2 get db cfg | find "CUR_COMMIT"
当前已落实 ( CUR_COMMIT ) = ON
C:\> db2 +c update rhette.employee set firstnme = ' CHRISTINE1 ' where empno = 00010
DB20000I SQL 命令成功完成。
C:\> db2 +c select * from rhette.department
DEPTNO DEPTNAME MGRNO ADMRDEPT LOCATION
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
A00 SPIFFY COMPUTER SERVICE DIV. 000010 A00 -
B01 PLANNING 000020 A00 -
C01 INFORMATION CENTER 000030 A00 -
D01 DEVELOPMENT CENTER - A00 -
D11 MANUFACTURING SYSTEMS 000060 D01 -
D21 ADMINISTRATION SYSTEMS 000070 D01 -
E01 SUPPORT SERVICES 000050 A00 -
E11 OPERATIONS 000090 E01 -
E21 SOFTWARE SUPPORT 000100 E01 -
F22 BRANCH OFFICE F2 - E01 -
G22 BRANCH OFFICE G2 - E01 -
H22 BRANCH OFFICE H2 - E01 -
I22 BRANCH OFFICE I2 - E01 -
J22 BRANCH OFFICE J2 - E01 -
14 条记录已选择。
- - 窗口 2
C:\> db2 connect to sample
数据库连接信息
数据库服务器 = DB2 / NT 9.7.0
SQL 授权标识 = RHETTE
本地数据库别名 = SAMPLE
C:\> db2 +c update rhette.department set deptname = ' PLANNING1 ' where deptno = 'B01'
DB20000I SQL 命令成功完成。
C:\> db2 +c select * from rhette.employee
EMPNO FIRSTNME MIDINIT LASTNAME WORKDEPT(后面省略)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
000010 CHRISTINE I HAAS A00
000020 MICHAEL L THOMPSON B01
000030 SALLY A KWAN C01
000050 JOHN B GEYER E01
. . . . . . . . . .
42 条记录已选择。
如何获取或请求“当前已落实”
可以通过配置数据库配置参数 CUR_COMMIT 获取“当前已落实”或者通过 BIND / PRECOMPILE/PREP 命令对其 CONCURRENTACCESSRESOLUTION 子句指定 USE CURRENTLY COMMITTED 或 WAIT FOR OUTCOME 来请求“当前已落实”。
一、数据库配置参数 cur_commit
该数据库配置参数主要是用来控制游标稳定性扫描的行为,默认值为 ON,可选值为:
(1)ON :打开;
对于新创建的数据库,默认值是 ON,在此情况下,当你试图读取一个正在被其他应用程序修改的行时,将直接返回该行的当前已落实版本数据(也就是首次更改之前的值)。
(2)AVAILABLE:可用;
此值表示你的应用需要显式地请求“当前已落实行为”才能得到“当前已落实”结果。
(3)DISABLED:禁用;
如果数据库是从之前的版本升级而来,这个参数将被设置成 DISABLED,这是为了和以前版本的行为保持一致。如果你希望使用当前已落实来控制游标稳定性扫描的行为,需要将这个参数更改成 ON 。
需要注意的是,注册表变量 DB2_EVALUNCOMMITTED、DB2_SKIPDELETED 和 DB2_SKIPINSERTED 在启用 cur_commit 参数后会受到影响。在绑定(BIND)或预编译(PRECOMPILE)时对 CONCURRENTACCESSRESOLUTION 选项指定 USE CURRENTLY COMMITTED 或 WAIT FOR OUTCOME,那么注册表变量 DB2_EVALUNCOMMITTED、DB2_SKIPDELETED 和 DB2_SKIPINSERTED 将被忽略。
二、BIND 和 PRECOMPILE/PREP 的命令 CONCURRENTACCESSRESOLUTION 子句
BIND 和 PRECOMPILE/PREP 命令的 CONCURRENTACCESSRESOLUTION 子句主要是为了对程序包中的语句指定使用并行访问解析,语法结构如清单 3 所示:
清单 3. BIND 命令 CONCURRENTACCESSRESOLUTION 子句语法结构>> - BIND - - filename - - - - - - - - - - - - - - - - - - - - - - - - - - >
> - - + - - - - - - - - - - - - - - - - - - - - - - - - - - + - - >
' - CONCURRENTACCESSRESOLUTION - - + - USE CURRENTLY COMMITTED - + - '
' - WAIT FOR OUTCOME - - - - - - '
- - 清单 3 - 2 . PRECOMPILE/PREP 命令 CONCURRENTACCESSRESOLUTION 子句语法结构
>> - + - PRECOMPILE - + - - filename - - - - - - - - - - - - - - - - - - ->
' - PREP - - - - - - - '
> - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + - - - >
' - CONCURRENTACCESSRESOLUTION - - + - USE CURRENTLY COMMITTED - + - '
' - WAIT FOR OUTCOME - - - - - - - '
USE CURRENTLY COMMITTED
该选项值表示:当数据处于更新或删除的过程中时,指定数据库管理器对扫描行为使用“当前已落实版本”,当行处于插入的过程中时这个设定将被跳过。当隔离级别处于游标稳定性或者读稳定性隔离级别时(对读稳定性隔离级别这个子句将只跳过未提交的插入操作)这个子句将有效,并且将忽略掉其他设置。
WAIT FOR OUTCOME
该选项值表示:当遇上数据正处于更新的过程中时,指定游标稳定性或更高的隔离级别扫描等待其提交或回滚完成。当行处于插入或删除的过程中时这些行在扫描时将不再被跳过。这个选项值将会造成 DB2_EVALUNCOMMITTED、 DB2_SKIPDELETED 和 DB2_SKIPINSERTED 不再生效。
对 DB2_EVALUNCOMMITTED、 DB2_SKIPDELETED 和 DB2_SKIPINSERTED 的影响
首先我们来看一下这几个注册表变量的用途:
(1)DB2_SKIPINSERTED
当该变量启用时,将允许 CS 或 RS 扫描跳过未提交的插入行。
实际上在 DB2 V9.7 之前的版本中,正是通过该注册表变量提供了“当前已落实”的部分功能。如果启用“当前已落实”设置(扫描将直接跳过未提交的读),那么这个注册表变量无效。如果 DB2_SKIPINSERTED 设置成 OFF,则并不会使得“当前已落实”的跳过未提交读的功能失效。需要注意,“当前已落实”的跳过未提交读的行为在所有的 CS/RS 扫描中是有效的,除非将“当前已落实”改成别的值。
(2)DB2_SKIPDELETED
当该变量启用时,将允许 CS / RS 扫描跳过未提交的删除行和索引键(index updates = delete + insert) 。在早期 DB2 版本中 DB2_SKIPDELETED 生效时,未提交的已删除行将被跳过,但是更新和插入行还会导致锁等待。在 DB2 V9.7 中,这个参数被设置生效后,同时“当前已落实”也有效的情况下,未提交的已删除行将不再跳过(而是使用 Currently Committed version 替代进行运算)。但是,当“当前已落实”不可用时,未提交的已删除行还是会被跳过。
(3)DB2_EVALUNCOMMITTED
当该变量启用时,将允许 CS / RS 扫描对未落实的数据进行谓词求值。
带来的影响是,它将进行表或索引访问扫描以延迟或避免行锁定(扫描时使用 UR),直到知道数据记录满足谓词求值为止。
下面我们解释几个名词的含义:
(1)隐式“当前已落实”:
是指当数据库上的“当前已落实”设置启用,而请求没有显式的请求“当前已落实”(也就是数据库配置参数 CUR_COMMIT=ON,而且请求没有通过 BIND 或 PREP 命令将 CONCURRENTACCESSRESOLUTION 选项设置成 USE CURRENTLY COMMITTED 或 WAIT FOR OUTCOME)。
(2)显式“当前已落实”:
是指程序包中的语句通过 BIND 或 PREP 命令显式的请求“当前已落实”(通过 BIND 或 PREP 命令将 CONCURRENTACCESSRESOLUTION 选项设置成 USE CURRENTLY COMMITTED)。
(3)“等待运行结果”(Wait For Outcome):
是指程序包中的语句通过 BIND 或 PREP 命令显式的发出“等待运行结果”请求(通过 BIND 或 PREP 命令将 CONCURRENTACCESSRESOLUTION 选项设置成 WAIT FOR OUTCOME)。
在游标稳定隔离级别(CS)下的所有只读操作,不管其使用了隐式“当前已落实”还是显式“当前已落实”,DB2_SKIPINSERTED 注册表变量都不适用,因为“当前已落实”已经包含了该功能,而 DB2_SKIPDELETED 和 DB2_EVALUNCOMMITTED 注册表变量也将无效,具体如表格 4 中第二列所示。
在游标稳定隔离级别(CS)下的所有写操作和读稳定性隔离级别(RS)所有读 / 写操作,当其使用了隐式“当前已落实”时,DB2_SKIPINSERTED 注册表变量都不适用,因为“当前已落实”已经包含了该功能,而 DB2_SKIPDELETED 和 DB2_EVALUNCOMMITTED 注册表变量将继续有效,具体如表格 4 中第三列所示。
在游标稳定隔离级别(CS)下的所有写操作和读稳定性隔离级别(RS)所有读 / 写操作,当其使用了显式“当前已落实”时,DB2_SKIPINSERTED 注册表变量都不适用,因为“当前已落实”已经包含了该功能,而 DB2_SKIPDELETED 和 DB2_EVALUNCOMMITTED 注册表变量也将无效,具体如表格 4 中第四列所示。
在游标稳定隔离级别(CS)下的所有读 / 写操作和读稳定性隔离级别(RS)所有读 / 写操作,当其使用了“等待运行结果”(Wait For Outcome)时,DB2_SKIPINSERTED、DB2_SKIPDELETED 和 DB2_EVALUNCOMMITTED 注册表变量都将无效,具体如表格 4 中第五列所示。
表 4. “当前已落实”对一些注册表变量的影响
注册表变量 | 隐式“当前已落实”; 显式“当前已落实”; CS 只读操作; | 隐式“当前已落实”; CS 写操作; RS 读 / 写操作; | 显式“当前已落实”; CS 写操作; RS 读 / 写操作; | Wait For Outcome ; CS 或 RS 下的读写操作; |
DB2_SKIPINSERTED | 不适用(当前已落实已经包含该功能) | 不适用(当前已落实已经包含该功能) | 不适用(当前已落实已经包含该功能) | NO |
DB2_SKIPDELETED | NO(不适用) | YES | NO | NO |
DB2_EVALUNCOMMITTED | NO(不适用) | YES | NO | NO |
- ››db2 对float类型取char后显示科学计数法
- ››DB2中出现SQL1032N错误现象时的解决办法
- ››DB2 锁升级示例
- ››db2诊断系列之---定位锁等待问题
- ››db2 命令选项解释
- ››DB2 最佳实践: 使用 DB2 pureXML 管理 XML 数据的...
- ››DB2 9.5 SQL Procedure Developer 认证考试 735 准...
- ››DB2 9.5 SQL Procedure Developer 认证考试 735 准...
- ››DB2 9.5 SQL Procedure Developer 认证考试 735 准...
- ››DB2 基础: 表空间和缓冲池
- ››DB2 XML 编程,第 1 部分: 理解 XML 数据模型
- ››DB2 pureScale 实战
更多精彩
赞助商链接