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

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

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