DB2 SQL RR/RS/CS/UR四個級別(轉)

1.RR隔離級別：在此隔離級別下， DB2會鎖住全部相關的紀錄。在一個SQL語句執行期間，全部執行此語句掃描過的紀錄都會被加上相應的鎖。具體的鎖的類型仍是由操做的類型來決定，若是是讀取，則加共享鎖；若是是更新，則加獨佔鎖。由於會鎖定全部為得到SQL語句的結果而掃描的紀錄，因此鎖的數量可能會很龐大，這個時候，索引的增長可能會對SQL語句的執行有很大的影響，因為索引會影響SQL語句掃描的紀錄數量。

2.RS隔離級別：此隔離級別的要求比RR隔離級別稍弱，此隔離級別下會鎖定全部符合條件的紀錄。不管是讀取，仍是更新，若是SQL語句中包含查詢條件，則會對全部符合條件的紀錄加相應的鎖。 若是沒有條件語句， 也就是對錶中的全部記錄進行處理，則會對全部的紀錄加鎖。

3.CS隔離級別：此隔離級別僅鎖住當前處理的紀錄。

4.UR隔離級別：此隔離級別下，若是是讀取操做，不會出現任何的行級鎖。 對於非只讀的操做，它的鎖處理和CS相同。

DB2默認的隔離級別是CS。 DB2默認的隔離級別是CS。 即遊標穩定性。即遊標穩定性。

詳細說明：

當多個用戶訪問同一數據庫時會發生的現象介紹以下：

在單用戶環境中，每一個事務都是順序執行的，而不會遇到與其餘事務的衝突。可是，在多用戶環境下，多個事務能夠（並且經常）同時執行。所以每一個事務都有可能與其餘正在運行的事務發生衝突。有可能與其餘事務發生衝突的事務稱爲交錯的 或並行的 事務，而相互隔離的事務稱爲串行化 事務，這意味着同時運行它們的結果與一個接一個連續地運行它們的結果沒有區別。在多用戶環境下，在使用並行事務時，會發生四種現象：

丟失更新：這種狀況發生在兩個事務讀取並嘗試更新同一數據時，其中一個更新會丟失。例如：事務 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 鎖，這時將不容許其餘事務對任何行進行更新或者刪除。

讀穩定性（Read stability，RS）相似於 RR 。可是，運行在 RS 級別的應用程序進程不是徹底與併發應用程序 進程的效果相隔離的。若是這樣的應用程序進程不止一次發出一樣的查詢，它就會看到更改了的數據或者由其餘 應用程序進程添加的新的「幻影（phantom）」行。RS 隔離級別會對錶加 IS 鎖，結果行加 NS 鎖，這時不容許其餘事務對這些行進行更新（UPDATE/DELETE），可是容許插入任何行，由於對這些行的更新會對相應的行加 X 鎖，這和行 NS 鎖相排斥——上述說法基於鎖列表足夠用，沒有發生鎖升級的狀況下才成立。

遊標穩定性（Cursor stability，CS）也確保由另外一個應用程序進程更改的任何行直到被那個應用程序進程提交， 不會被讀取。 CS 隔離級別只確保每一個可更新遊標的當前行不被其餘應用程序進程更改； 在 UOW 期間讀過的行能夠被其餘應用程序進程更改。針對可滾動更新遊標，在提交以前，會對全部結果行一直加 U 鎖， 不管遊標滾動到什麼地方； CS 隔離級別針對不可更新遊標會對錶加 IS 鎖，若是未在 WHERE 條件字段上建立索引， 查詢首先會查找鎖列表，檢查鎖列表中是否存在與 IS 鎖相排斥的鎖，若是存在的話， 那麼將等待全部持有排斥鎖的事務提交，查詢才能執行下去；若是 WHERE 條件字段建立了索引，而且使用了索引， 那麼查詢將經過索引獲得結果行，而後檢查鎖列表中是否存在與結果行相排斥的鎖，若是存在的話， 那麼將等待全部持有排斥鎖的事務提交，查詢才能執行下去 .未提交讀（Uncommitted read，UR）對於某些操做，容許在 UOW 期間讀過的任何行能夠被其餘應用程序進程更改，並容許讀任何被另外一個應用程序進程更改過的行，即便該更改尚未提交。對於其餘操做，UR 相似於 CS 。綜上所述，離級別對併發性具備最顯著的影響，不一樣隔離級別得到的資源的鎖定範圍也不一樣，若是全部事務都能作到不過度貪婪的佔有鎖資源——鎖的範圍大、佔用時間長，那麼事務之間發生鎖衝突的可能性將大大下降，事務的併發性也將會很好。那麼如何選擇正確的隔離級別呢？

使用的隔離級別不只影響數據庫對併發性的支持如何，並且影響併發應用程序的性能。一般，使用的隔離級別越嚴格，併發性就越小，某些應用程序的性能可能會越低，由於它們要等待資源上的鎖被釋放。那麼，如何決定要使用哪一種隔離級別呢？最好的方法是肯定哪些現象是不可接受的，而後選擇可以防止這些現象發生的隔離級別：

若是正在執行大型查詢，並且不但願併發事務所作的修改致使查詢的屢次運行返回不一樣的結果，則使用可重複的讀隔離級別。 若是但願在應用程序之間得到必定的併發性，還但願限定的行在事務執行期間保持穩定，則使用讀穩定性隔離級別。 若是但願得到最大的併發性，同時不但願查詢看到未提交的數據，則使用遊標穩定性隔離級別。 若是正在只讀的表 / 視圖 / 數據庫上執行查詢，或者並不介意查詢是否返回未提交的數據，則使用未提交的讀隔離級別。 對於統計類報表，不須要獲得十分精確的數據，那麼最好使用 UR 隔離級別，既能夠節省昂貴的鎖列表資源，也不會由於鎖衝突影響其餘事務的執行，同時也不會受到其餘事務的影響，順利的獲得統計結果。未提交的讀隔離級別一般用於那些訪問只讀表和視圖的事務，以及某些執行 SELECT 語句的事務（只要其餘事務的未提交數據對這些語句沒有負面效果）。 顧名思義，其餘事務對行所作的更改在已經提交以前對於使用未提交的讀隔離級別的事務是可見的。可是，此類事務不能看見或訪問其餘事務所建立的表、視圖或索引，直到那些事務被提交爲止。相似地，若是其餘事務刪除了現有的表、視圖或索引，那麼僅當進行刪除操做的事務終止時，使用未提交的讀隔離級別的事務才能知道這些對象再也不存在了。（必定要注意一點：當運行在未提交的讀隔離級別下的事務使用可更新遊標時，該事務的行爲和在遊標穩定性隔離級別下運行同樣，並應用遊標穩定性隔離級別的約束。）