DB2锁与隔离级别
数据库管理器支持三种一般类别的锁定：
- 共享（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 隔离级别既提供了高度的并行性，也提供了稳定的数据视图。所以，优化器确保在发生锁定升级前不获取表级别锁定。
- 在并发环境中运行
- 要求合格行在工作单元运行期间保持稳定
- 在工作单元中不会多次发出同一个查询，或者在一个工作单元中多次发出同一个查询时并不要求结果集相同
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.
- 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 下，可更新游标的工作方式就像隔离级别为 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.
- 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.
- 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.
日志片段
参考资料
https://www.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.admin.perf.doc/doc/c0004121.html
