最近回歸本行，開始數(shù)據(jù)庫的研究。雖然不是9R2，但是好歹SQLServer的傻瓜式配置也不是浪得虛名，也算混的勉強過關把。 不過仔細研究了下2005的行版本控制這塊做的確實不錯，下面把我研究的共享，歡迎批判。行版本控制隔離：簡介行版本控制的隔離是SQL Server 2005一個新的隔離框架。使用行版本控制的隔離可以在大量并發(fā)的情況下，顯著減少所得產(chǎn)生，并且與NoLock相比，它又可以顯著降低骯臟讀，幻影，丟失更新等現(xiàn)象的發(fā)生(READ_COMMITTED_SNAPSHOT) 當在基于行版本控制的隔離下運行的事務讀取數(shù)據(jù)時，讀取操作不會獲取正被讀取的數(shù)據(jù)上的共享鎖（S 鎖），因此不會阻塞正在修改數(shù)據(jù)的事務。另外，鎖定資源的開銷隨著所獲取的鎖的數(shù)量的減少降至最低。使用行版本控制的已提交讀隔離和快照隔離可以提供副本數(shù)據(jù)的語句級或事務級讀取一致性。行版本控制隔離：優(yōu)勢使用行版本控制的隔離級別具有以下優(yōu)點：·讀取操作檢索一致的數(shù)據(jù)庫快照。·SELECT 語句在讀取操作過程中不鎖定數(shù)據(jù)（讀取器不阻塞編寫器，編寫器也不阻塞讀取器）。·SELECT 語句可以在其他事務更新行時訪問最后提交的行值，而不阻塞應用程序。·死鎖的數(shù)量減少。·事務所需的鎖的數(shù)量減少，這減少了管理鎖所需的系統(tǒng)開銷。·鎖升級的次數(shù)減少。行版本控制隔離：原理SQL Server 2005的行版本控制原理上很簡單，就是在庫表中每一行的記錄上都悄悄的增加了一個類時間戳列（行版本列）。當使用行版本控制的隔離時，SQL Server 2005 Database Engine 向使用行版本控制操作數(shù)據(jù)的每個事務分配一個事務序列號 (XSN)。事務在執(zhí)行 BEGIN TRANSACTION 語句時啟動。但是，事務序列號在執(zhí)行 BEGIN TRANSACTION 語句后的第一次讀/寫操作時開始增加。事務序列號在每次分配時都增加 1。當事務執(zhí)行時，SQL Server根據(jù)行版本列，來提供的行的相應版本。 而SQLServer將維護所有在數(shù)據(jù)庫中執(zhí)行的數(shù)據(jù)修改的邏輯副本（版本）。特定的事務每次修改行時，數(shù)據(jù)庫引擎 實例都存儲以前提交的 tempdb 中行的圖像版本。每個版本都標記有進行此更改的事務的事務序列號。已修改行的版本使用鏈接列表鏈接在一起。最新的行值始終存儲在當前的數(shù)據(jù)庫中并鏈接至版本存儲區(qū) tempdb 中存儲的版本。（修改大型對象 (LOB) 時，只有已更改的片段才會復制到 tempdb 中的版本存儲區(qū),; 對于短期運行的事務，已修改行的版本將可能保存在緩沖池中，而不會寫入 tempdb 數(shù)據(jù)庫的磁盤文件中。如果只是臨時需要副本行，它將只是簡單地從緩沖池中刪除而不會引發(fā) I/O 開銷。） MSDN上一再強調(diào)要關注提升tempdb的地位，不然因為tempdb的性能導致整個數(shù)據(jù)庫性能下降，可就是無妄之災了。

行版本控制隔離：種類 行版本控制分為兩種已提交讀快照隔離級別（READ_COMMITTED_SNAPSHOT）和快照隔離級別（ALLOW_SNAPSHOT_ISOLATION），他們屬于行版本控制的隔離的范疇，但是實際上他們卻有方方面面的不同。下面是MSDN對他們的比較。屬性已提交讀快照隔離級別快照隔離級別必須設置為 ON 以便啟用所需支持的數(shù)據(jù)庫選項。READ_COMMITTED_SNAPSHOTALLOW_SNAPSHOT_ISOLATION會話如何請求特定類型的行版本控制。使用默認的已提交讀隔離級別，或運行 SET TRANSACTION ISOLATION LEVEL 語句來指定 READ COMMITTED 隔離級別。這可以在事務啟動后完成。需要執(zhí)行 SET TRANSACTION ISOLATION LEVEL 來在事務啟動前指定 SNAPSHOT 隔離級別。由語句讀取的數(shù)據(jù)的版本。在每條語句啟動前提交的所有數(shù)據(jù)。在每個事務啟動前提交的所有數(shù)據(jù)。如何處理更新。從行版本恢復到實際的數(shù)據(jù)，以選擇要更新的行并使用選擇的數(shù)據(jù)行上的更新鎖。獲取要修改的實際數(shù)據(jù)行上的排他鎖。沒有更新沖突檢測。使用行版本選擇要更新的行。嘗試獲取要修改的實際數(shù)據(jù)行上的排他鎖，如果數(shù)據(jù)已被其他事務修改，則出現(xiàn)更新沖突，同時快照事務也將終止。有更新沖突檢測。無。集成支持。無法禁用。

讀取數(shù)據(jù)時的行為SNAPSHOT隔離就像真實的快照，它會無視涉及行的變化。在SNAPSHOT隔離下運行的事務將讀取數(shù)據(jù)，然后由另一事務修改此數(shù)據(jù)。SNAPSHOT事務不阻塞由其他事務執(zhí)行的更新操作，它忽略數(shù)據(jù)的修改繼續(xù)從版本化的行讀取數(shù)據(jù)。但是，當快照事務嘗試修改已由其他事務修改的數(shù)據(jù)時，SNAPSHOT事務將生成錯誤并終止.READ_COMMITTED_SNAPSHOT類似與以前的READ_COMMITTED隔離級別，也就是說與快照事務相同的是，即使其他事務修改了數(shù)據(jù)，已提交讀事務也將讀取版本化的行。然而，與快照事務不同的是，已提交讀將執(zhí)行下列操作：·在其他事務提交數(shù)據(jù)更改后，讀取修改的數(shù)據(jù)。·能夠更新由其他事務修改的數(shù)據(jù)，而快照事務不能。修改數(shù)據(jù)時的行為在使用行版本控制的已提交讀事務中，使用阻塞性掃描（其中讀取數(shù)據(jù)值時將在數(shù)據(jù)行上采用更新鎖（U 鎖）完成選擇要更新的行。這與不使用行版本控制的已提交讀事務相同。如果數(shù)據(jù)行不符合更新標準，在該行上將釋放更新鎖并且將鎖定下一行并對其進行掃描。在快照隔離下運行的事務對數(shù)據(jù)修改采用樂觀方法：直到數(shù)據(jù)被修改時才獲取數(shù)據(jù)上的鎖。不需要獲取鎖就可以選擇要更新的行。當數(shù)據(jù)行符合更新標準時，快照事務將驗證未被并發(fā)事務（在快照事務開始后提交）修改的數(shù)據(jù)行。如果數(shù)據(jù)行已在快照事務以外修改，則將出現(xiàn)更新沖突，同時快照事務也將終止。更新沖突由數(shù)據(jù)庫引擎 處理，無法禁用更新沖突檢測。