数据库管理器支持三种一般类别的锁定:

共享(S)
挂起 S 锁定之后,并发应用程序进程只能对数据执行只读操作。
更新(U)
挂起 U 锁定之后,如果并发应用程序进程未声明它们要更新行,那么它们只能对数据执行只读操作。数据库管理器假定当前正在查看行的进程可能会更新该行。
互斥(X)
挂起 X 锁定之后,并发应用程序进程将无法以任何方式访问数据。这不适用于隔离级别为“未落实的读”(UR)的应用程序进程,这些进程能够读取但无法修改数据。

无论采用哪种隔离级别,数据库管理器都将对插入、更新或删除的每一行挂起互斥锁定。因此,所有隔离级别都将确保应用程序进程在工作单元运行期间更改的任何行在该工作单元完成前不会被任何其他应用程序进程更改。

The database manager supports three general categories of locks:

Share (S)
Under an S lock, concurrent application processes are limited to read-only operations on the data.
Update (U)
Under a U lock, concurrent application processes are limited to read-only operations on the data, if these processes have not declared that they might update a row. The database manager assumes that the process currently looking at a row might update it.
Exclusive (X)
Under an X lock, concurrent application processes are prevented from accessing the data in any way. This does not apply to application processes with an isolation level of uncommitted read (UR), which can read but not modify the data.

Regardless of the isolation level, the database manager places exclusive locks on every row that is inserted, updated, or deleted. Thus, all isolation levels ensure that any row that is changed by an application process during a unit of work is not changed by any other application process until the unit of work is complete.

数据库管理器支持四种隔离级别

可重复读 (RR)

可重复读隔离级别将锁定应用程序在工作单元 (UOW) 运行期间引用的所有行。如果应用程序在同一个工作单元中发出 SELECT 语句两次,那么每次将返回相同的结果。对于 RR 而言,不可能出现丢失更新、访问未落实的数据、不可重复读以及幻像读等情况。

在 RR 隔离级别下,应用程序在 UOW 完成前可以任意次地检索和处理行。但是,在该 UOW 完成之前,其他应用程序均无法更新、删除或插入将会影响结果集的行。在 RR 隔离级别下运行的应用程序无法看到其他应用程序所作的未落实更改。此隔离级别确保返回的所有数据在被应用程序看到前保持不变,即使使用了临时表或行分块方法也是如此。

所引用的每一行都将被锁定,而不仅仅是锁定所检索的行。例如,如果扫描 10000 行并对它们应用谓词,尽管可能只有 10 行满足条件,但仍会锁定全部的 10000 行。其他应用程序无法插入或更新再次执行查询时将被添加到该查询所引用的行列表中的行。这将防止出现幻像读情况。

由于 RR 可能会获取相当多的锁定,所以此数目可能会超出 locklist 和 maxlocks 数据库配置参数所指定的限制。为了避免锁定升级,在有可能发生锁定升级的时候,优化器可能会选择获取单个表级别锁定用于索引扫描。如果您不希望进行表级别锁定,那么请使用“读稳定性”隔离级别。

评估引用约束时,DB2® 服务器有时会将用于外表扫描的隔离级别升级到 RR,而不考虑用户先前设置的隔离级别。这将导致其他锁定一直被挂起到落实为止,从而增加发生死锁或锁定超时情况的可能性。为了避免这些问题,请创建只包含外键列的索引以供引用完整性扫描使用。

The database manager supports four isolation levels.

Repeatable read (RR)

The repeatable read isolation level locks all the rows that an application references during a unit of work (UOW). If an application issues a SELECT statement twice within the same unit of work, the same result is returned each time. Under RR, lost updates, access to uncommitted data, non-repeatable reads, and phantom reads are not possible.

Under RR, an application can retrieve and operate on the rows as many times as necessary until the UOW completes. However, no other application can update, delete, or insert a row that would affect the result set until the UOW completes. Applications running under the RR isolation level cannot see the uncommitted changes of other applications. This isolation level ensures that all returned data remains unchanged until the time the application sees the data, even when temporary tables or row blocking is used.

Every referenced row is locked, not just the rows that are retrieved. For example, if you scan 10 000 rows and apply predicates to them, locks are held on all 10 000 rows, even if, say, only 10 rows qualify. Another application cannot insert or update a row that would be added to the list of rows referenced by a query if that query were to be executed again. This prevents phantom reads.

Because RR can acquire a considerable number of locks, this number might exceed limits specified by the locklist and maxlocks database configuration parameters. To avoid lock escalation, the optimizer might elect to acquire a single table-level lock for an index scan, if it appears that lock escalation is likely. If you do not want table-level locking, use the read stability isolation level.

While evaluating referential constraints, the DB2® server might occasionally upgrade the isolation level used on scans of the foreign table to RR, regardless of the isolation level that was previously set by the user. This results in additional locks being held until commit time, which increases the likelihood of a deadlock or a lock timeout. To avoid these problems, create an index that contains only the foreign key columns, and which the referential integrity scan can use instead.

读稳定性 (RS)

读稳定性隔离级别只锁定应用程序在工作单元运行期间检索的那些行。RS 确保在 UOW 完成之前,在该 UOW 运行期间读取的任何合格行不会被其他应用程序进程更改,并确保任何由另一个应用程序进程更改的行在该进程落实更改前无法被读取。对于 RS 而言,不可能出现访问未落实的数据以及不可重复读等情况。但是,有可能进行幻像读。

此隔离级别确保返回的所有数据在被应用程序看到前保持不变,即使使用了临时表或行分块方法也是如此。

RS 隔离级别既提供了高度的并行性,也提供了稳定的数据视图。所以,优化器确保在发生锁定升级前不获取表级别锁定。

RS 隔离级别适合于符合下列条件的应用程序:

  • 在并发环境中运行
  • 要求合格行在工作单元运行期间保持稳定
  • 在工作单元中不会多次发出同一个查询,或者在一个工作单元中多次发出同一个查询时并不要求结果集相同

Read stability (RS)

The read stability isolation level locks only those rows that an application retrieves during a unit of work. RS ensures that any qualifying row read during a UOW cannot be changed by other application processes until the UOW completes, and that any row changed by another application process cannot be read until the change is committed by that process. Under RS, access to uncommitted data and non-repeatable reads are not possible. However, phantom reads are possible.

This isolation level ensures that all returned data remains unchanged until the time the application sees the data, even when temporary tables or row blocking is used.

The RS isolation level provides both a high degree of concurrency and a stable view of the data. To that end, the optimizer ensures that table-level locks are not obtained until lock escalation occurs.

The RS isolation level is suitable for an application that:

  • Operates in a concurrent environment
  • Requires qualifying rows to remain stable for the duration of a unit of work
  • Does not issue the same query more than once during a unit of work, or does not require the same result set when a query is issued more than once during a unit of work

游标稳定性 (CS)

游标稳定性隔离级别将在游标定位于事务执行期间所访问的任何行上时锁定该行。此锁定在下一行被访存或者事务终止之前将保持有效。但是,如果更改了该行中的任何数据,那么在落实更改之前将一直挂起该锁定。

在此隔离级别下,其他应用程序无法在可更新游标定位于某一行上时更新或删除该行。在 CS 下,无法访问其他应用程序未落实的数据。但是,有可能进行不可重复读和幻像读。

CS 是缺省隔离级别。如果您希望最大程度地提高并行性,并且只需要查看已落实的数据时,此隔离级别适用。

Cursor stability (CS)

The cursor stability isolation level locks any row being accessed during a transaction while the cursor is positioned on that row. This lock remains in effect until the next row is fetched or the transaction terminates. However, if any data in the row was changed, the lock is held until the change is committed.

Under this isolation level, no other application can update or delete a row while an updatable cursor is positioned on that row. Under CS, access to the uncommitted data of other applications is not possible. However, non-repeatable reads and phantom reads are possible.

CS is the default isolation level. It is suitable when you want maximum concurrency and need to see only committed data.

未落实的读 (UR)

未落实的读隔离级别允许应用程序访问其他事务未落实的更改。并且,UR 不会阻止其他应用程序访问正被读取的行,除非该应用程序尝试更改或删除表。

在 UR 下,可能会出现访问未落实的数据、不可重复读以及幻像读等情况。如果对只读的表运行查询,或者只发出 SELECT 语句并且查看其他应用程序尚未落实的数据不会引起问题时,此隔离级别适用。

对于只读游标和可更新游标,UR 的工作方式有所不同。

  • 只读游标可访问其他事务未落实的大部分更改。
  • 在事务处理期间,正由其他事务创建或删除的表、视图和索引不可用。其他事务进行的任何其他更改在落实或回滚前都可被读取。在 UR 下,可更新游标的工作方式就像隔离级别为 CS 一样。
如果未落实的读应用程序使用了模糊游标,那么它可以在运行期间使用 CS 隔离级别。如果 PREP 或 BIND 命令的 BLOCKING 选项值为 UNAMBIG(缺省值),那么模糊游标可以升级为 CS。要避免这种升级,请执行下列操作:

  • 将该应用程序中的游标修改为明确游标。将 SELECT 语句更改为包括 FOR READ ONLY 子句。
  • 保留应用程序中的模糊游标,但对该程序进行预编译或者对其进行绑定并指定 BLOCKING ALL 和 STATICREADONLY YES 选项,以便允许该程序运行时将模糊游标视为只读游标。

The uncommitted read isolation level allows an application to access the uncommitted changes of other transactions. Moreover, UR does not prevent another application from accessing a row that is being read, unless that application is attempting to alter or drop the table.

Under UR, access to uncommitted data, non-repeatable reads, and phantom reads are possible. This isolation level is suitable if you run queries against read-only tables, or if you issue SELECT statements only, and seeing data that has not been committed by other applications is not a problem.

UR works differently for read-only and updatable cursors.

  • Read-only cursors can access most of the uncommitted changes of other transactions.
  • Tables, views, and indexes that are being created or dropped by other transactions are not available while the transaction is processing. Any other changes by other transactions can be read before they are committed or rolled back. Updatable cursors operating under UR behave as though the isolation level were CS.
If an uncommitted read application uses ambiguous cursors, it might use the CS isolation level when it runs. The ambiguous cursors can be escalated to CS if the value of the BLOCKING option on the PREP or BIND command is UNAMBIG (the default). To prevent this escalation:

  • Modify the cursors in the application program to be unambiguous. Change the SELECT statements to include the FOR READ ONLY clause.
  • Let the cursors in the application program remain ambiguous, but precompile the program or bind it with the BLOCKING ALL and STATICREADONLY YES options to enable the ambiguous cursors to be treated as read-only when the program runs.

日志片段

Database name                              = GMCC_HSH
Database path                              = /db2home/GMCC_HSH/db2inst1/NODE0000/SQL00001/MEMBER0000/
Input database alias                       = GMCC_HSH
Locks held                                 = 36034
Applications currently connected           = 5
Agents currently waiting on locks          = 4
Snapshot timestamp                         = 09/15/2018 11:25:02.350620
 S锁
 Lock Name                   = 0x02000800000000000000000054
 Lock Attributes             = 0x00000000
 Release Flags               = 0x00000001
 Lock Count                  = 1
 Hold Count                  = 0
 Lock Object Name            = 8
 Object Type                 = Table
 Tablespace Name             = USERSPACE1
 Table Schema                = HSH
 Table Name                  = MCI_OM_ORDER
 Mode                        = S
U锁
 Lock Name                   = 0x02000800000000000000000054
 Lock Attributes             = 0x00000000
 Release Flags               = 0x40000000
 Lock Count                  = 1
 Hold Count                  = 0
 Lock Object Name            = 8
 Object Type                 = Table
 Tablespace Name             = USERSPACE1
 Table Schema                = HSH
 Table Name                  = MCI_OM_ORDER
 Mode                        = SIX
 Status                      = Converting
 Current Mode                = U
X锁
 Lock Name                   = 0x020008001500F0020000000052
 Lock Attributes             = 0x00000000
 Release Flags               = 0x40000000
 Lock Count                  = 1
 Hold Count                  = 0
 Lock Object Name            = 49283093
 Object Type                 = Row
 Tablespace Name             = USERSPACE1
 Table Schema                = HSH
 Table Name                  = MCI_OM_ORDER
 Mode                        = X

参考资料

https://www.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.admin.perf.doc/doc/c0004121.html

DB2锁与隔离级别的更多相关文章

  1. MySQL学习【第十二篇事务中的锁与隔离级别】

    一.事务中的锁 1.啥是锁? 顾名思义,锁就是锁定的意思 2.锁的作用是什么? 在事务ACID的过程中,‘锁’和‘隔离级别’一起来实现‘I’隔离性的作用 3.锁的种类 共享锁:保证在多事务工作期间,数 ...

  2. 【MySQL】MySQL锁和隔离级别浅析一

    <MySQL技术内幕InnoDB存储引擎>第一版中对于MySQL的InnoDB引擎锁进行了部分说明,第二版有部分内容更新. 与MySQL自身MyISAM.MSSQL及其他平台BD锁的对比: ...

  3. mysql 开发进阶篇系列 12 锁问题(隔离级别下锁的差异)

    1. innodb在不同隔离级别下的一致性读及锁的差异 不同的隔离级别下,innodb处理sql 时采用的一致性读策略和需要的锁是不同的,同时,数据恢复和复制机制的特点,也对一些sql的一致性读策略和 ...

  4. 理解MySql的锁&事务隔离级别

    这几篇文章是从网上(http://www.hollischuang.com)看到的一系列文章,也是重温了一下数据库的相关知识.下面是对这些文章的一些前后行文逻辑的说明: 我们知道,在DBMS的多个事业 ...

  5. mysql 锁 事务隔离级别

    主题 最近在看mysql相关的书籍.实验了一些内容.分享一下,主要是关于事务隔离级别(read-committed和repeatable-read)和锁相关的. 很多网上文章上都能搜索到 read-c ...

  6. (7)MySQL进阶篇SQL优化(InnoDB锁-事务隔离级别 )

    1.概述 在我们在学习InnoDB锁知识点之前,我觉得有必要让大家了解它的背景知识,因为这样才能让我们更系统地学习好它.InnoDB与MyISAM的最大不同有两点:一是支持事务(TRANSACTION ...

  7. 【MySQL】MySQL锁和隔离级别浅析二 之 INSERT

    最近在整理线上性能时,发现一台线上DB出现两个insert产生的死锁问题 ------------------------ LATEST DETECTED DEADLOCK ------------- ...

  8. DB2之隔离级别和锁的论述

    在DB2数据库中, 是通过行级锁和表级锁协调作用来提供较好的并发性, 同时保证数据库中数据的安全. 在DB2中缺省情况下使用行级锁(当然需要IS/IX锁配合),只有当出现锁资源不足, 或者是用命令指定 ...

  9. DB2隔离级别之RR/RS/CS/UR

      1.RR隔离级别:在此隔离级别下. DB2会锁住全部相关的纪录. 在一个SQL语句运行期间, 全部运行此语句扫描过的纪录都会被加上对应的锁.在一个SQL语句运行期间,全部运行此语句扫描过的纪录都会 ...

随机推荐

  1. abp框架下,donet core配置swagger

    abp已经自带了swagger,但是我们的文档注释swagger并没有做处理,需要我们自己手动处理一下 1.对Application层配置xml输出,一般勾上xml,默认的地址就可以啦! 2.修改St ...

  2. html css+div+jquery实现图片轮播

    一直想自己动手做一个图片轮播的控件,查查网上的资料大多引用已经做好的组件,其原理算法不是很清楚,于是自己用jquery写了一个.先看下效果图: 主要界面实现思路如下: 1.新建一个div宽度为100% ...

  3. vue使用vue-video-player在直播中的应用

    文档地址:https://github.com/savokiss/vue-videojs-demo live demo地址:https://github.com/savokiss/vue-videoj ...

  4. SQL练习题-50道SQL练习题及答案与详细分析

    网上流传较广的50道SQL训练,奋斗了不知道多久终于写完了.前18道题的难度依次递增,从19题开始的后半部分算是循环练习和额外function的附加练习,难度恢复到普通状态.第9题非常难,我反正没有写 ...

  5. Python:从入门到实践--第十一章--测试代码--练习

    #1.城市和国家:编写一个函数,它接受两个形参:一个城市名和一个国家名. #这个函数返回一个格式为City,Country的字符串,如Santiago,Chile.将这个函数 #存储在一个名为city ...

  6. JavaScript新手入门 贪吃蛇

    从小就在玩贪吃蛇,但是知道今天自己做了一遍才知道原理的具体的实现步骤. 刚进入界面时显示开始游戏(不重要,本人比较喜欢吹毛求疵) 中间黑色部分为游戏的主要展示部分 主要步骤及源码: body中代码,红 ...

  7. mongoDB数据库的安装与配置

    noSql数据库MongoDB的安装地址:https://www.mongodb.com/download-center?jmp=nav#community 选择相应的版本进行下载,在此以window ...

  8. 9th week blog

    1957年 约翰·巴科斯(John Backus)创建了是全世界第一套高阶语言:FORTRAN. 1959年 葛丽丝·霍普(Grace Hopper)创造了现代第一个编译器A-0 系统,以及商用电脑编 ...

  9. 7th week blog

    DOM:Document Object Model(文档对象模型) Document Object Model的历史可以追溯至1990年代后期微软与Netscape的“浏览器大战”,双方为了在Java ...

  10. Linux第五节课学习笔记

    Linux系统中的一切都是文件,命令就是命令文件. 命令执行分为4步: 1.路径+命令名称. 2.别名.可用alias命令创建别名. 3.内部命令. 4.外部命令.99%的情况都属于第四种.定义这些路 ...