关于DB2 数据库并发性（一）
日期：2014-05-16 浏览次数：20398 次
关于 DB2 数据库并发性的探讨（转）?
?
简介：?OLTP 数据库通常是高并发的使用模式，具有高的并发性对 OLTP 系统来说至关重要，并发事务实际上取决于资源的使用状况，原则上应尽量减少对资源的锁定时间，减少对资源的锁定范围，从而能够尽量增加并发事务的数量，那么影响并发的因素有哪些呢？这篇系列文章分 2 部分就这个内容进行一些探讨，同时会尽量使用不同的工具（数据库快照、事件监视器、控制中心等）来演示如何监控资源的使用状况，让大家在获得知识的同时，也可以熟悉各种工具的使用。
?
<script type="text/javascript"></script><!-- Rating_Area_End -->
?
<!-- dW_Summary_Area_END --><!-- CONTENT_BODY -->
概述
OLTP 数据库通常是高并发的使用模式，具有高的并发性对 OLTP 系统来说至关重要，并发事务实际上取决于资源的使用状况，原则上应尽量减少对资源的锁定时间，减少对资源的锁定范围，从而能够尽量增加并发事务的数量，那么影响并发的因素有哪些呢？这篇系列文章之一将从 DB2 数据库本身所提供的机制对并发性的影响进行一些探讨，这些机制包括隔离级别、数据库锁参数、实例注册表变量、乐观锁定。
同时本文讨论及实验所基于的环境如下，见图 1：
图 1. DB2 版本
设置 DB2 注册表变量 DB2OPTIONS，将自动提交功能关闭，后面的实验默认都基于这个设置。
| db2set DB2OPTIONS=+c db2 terminate db2stop db2start |
回页首
隔离级别与并发性
当多个用户访问同一数据库时会发生的现象介绍如下：
在单用户环境中，每个事务都是顺序执行的，而不会遇到与其他事务的冲突。但是，在多用户环境下，多个事务可以（而且常常）同时执行。因此每个事务都有可能与其他正在运行的事务发生冲突。有可能与其他事务发生冲突的事务称为交错的 或并行的 事务，而相互隔离的事务称为串行化 事务，这意味着同时运行它们的结果与一个接一个连续地运行它们的结果没有区别。在多用户环境下，在使用并行事务时，会发生四种现象：
- 丢失更新：这种情况发生在两个事务读取并尝试更新同一数据时，其中一个更新会丢失。例如：事务 1 和事务 2 读取同一行数据，并都根据所读取的数据计算出该行的新值。如果事务 1 用它的新值更新该行以后，事务 2 又更新了同一行，则事务 1 所执行的更新操作就丢失了。由于设计 DB2 的方法，DB2 不允许发生此类现象。
- 脏读：当事务读取尚未提交的数据时，就会发生这种情况。例如：事务 1 更改了一行数据，而事务 2 在事务 1 提交更改之前读取了已更改的行。如果事务 1 回滚该更改，则事务 2 就会读取被认为是不曾存在的数据。
- 不可重复的读：当一个事务两次读取同一行数据，但每次获得不同的数据值时，就会发生这种情况。例如：事务 1 读取了一行数据，而事务 2 在更改或删除该行后提交了更改。当事务 1 尝试再次读取该行时，它会检索到不同的数据值（如果该行已经被更新的话），或发现该行不复存在了（如果该行被删除的话）。
- 幻像：当最初没有看到某个与搜索条件匹配的数据行，而在稍后的读操作中又看到该行时，就会发生这种情况。例如：事务 1 读取满足某个搜索条件的一组数据行，而事务 2 插入了与事务 1 的搜索条件匹配的新行。如果事务 1 再次执行产生原先行集的查询，就会检索到不同的行集。
维护数据库的一致性和数据完整性，同时又允许多个应用程序同时访问同一数据，这样的特性称为并发性。 DB2 数据库用来尝试强制实施并发性的方法之一是通过使用隔离级别——通过‘事务、隔离级别、锁’机制，它决定在第一个事务访问数据时，如何对其他事务锁定或隔离该事务所使用的数据。 DB2 使用下列隔离级别来强制实施并发性：
- 可重复的读（Repeatable Read）
- 读稳定性（Read Stability）
- 游标稳定性（Cursor Stability）
- 未提交的读（Uncommitted Read）
可重复的读隔离级别可以防止所有现象，但是会大大降低并发性的程度（可以同时访问同一资源的事务数量）。未提交的读隔离级别提供了最大的并发性，但是后三种现象都可能出现。
DB2 UDB 支持以下隔离级别：可重复读（Repeatable read，RR）、读稳定性（Read stability，RS）、游标稳定性（Cursor stability，CS）、未提交读（Uncommitted read，UR），下面分别讲述：
| 可重复读（Repeatable read，RR） 确保 工作单元（UOW）期间的任何表行读操作直到 UOW 完成，不会被其他应用程序进程更改。类似地，由另一个应用程序进程更改的任何行直到由该应用程序进程提交，不会被读取。运行在 RR 级别的应用程序进程是完全与并发应用程序进程的效果相隔离的。 |
RR 隔离级别通常会直接对表加 S 锁，所以对并发的影响最大，但有一种情况例外：如果 WHERE 条件字段上建有主键或者 UNIQUE INDEX，并且通过主键或者 UNIQUE INDEX 进行查询，那么数据库将只对表加 IS 锁，结果行加 S 锁——在锁列表足够用，没有发生锁升级的情况下才成立，也就是说，这个时候 RR 级别 =RS 级别，这时不允许其他事务对这些行进行更新或者删除，因为对行的更新或者删除会对相应的行加 X 锁，这和行 S 锁相排斥；其他情况下，会直接对表加 S 锁，这时将不允许其他事务对任何行进行更新或者删除。
下面我们做个实验，验证使用RR隔离级别的查询对表的加锁情况。
表 1. 实验使用的数据模型
| 表名 | 表结构 | 主键/ UNIQUE INDEX |
数据规模 |
| TEST_HAVE_PRI |
免责声明： 本文仅代表作者个人观点，与爱易网无关。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请读者仅作参考，并请自行核实相关内容。
|
