數據庫管理器支持三種一般類別的鎖定：
- 共享（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