回顧一下SNAPSHOT的構架：

SNAPSHOT隔離就像真實的快照，它會無視涉及行的變化。在SNAPSHOT隔離下運行的事務將讀取數據，然后由另一事務修改此數據。SNAPSHOT事務不阻塞由其他事務執(zhí)行的更新操作，它忽略數據的修改繼續(xù)從版本化的行讀取數據。但是，當快照事務嘗試修改已由其他事務修改的數據時，SNAPSHOT事務將生成錯誤并終止.

相比READ_COMMITTED_SNAPSHOT，SNAPSHOT真正做到了快照隔離，完全無視數據的更新。相對READ_COMMITTED_SNAPSHOT，它更進一步減輕了對鎖的依賴，在性能方面獲得了更大的優(yōu)勢。不可避免的是，SNAPSHOT的事務性也變得更差，但是，至少，它比NoLock要好。^_^

SNAPSHOT的限制：

SNAPSHOT比READ_COMMITTED_SNAPSHOT更快，但是壞消息是它的限制也多。

1．快照隔離不支持分布式事務，包括分布式分區(qū)數據庫中的查詢。

2．SQL Server 不會保留多個版本的系統(tǒng)元數據。表中的數據定義語言 (DDL) 語句和其他數據庫對象（索引、視圖、數據類型、存儲過程和公共語言運行時函數）會更改元數據。如果 DDL 語句修改一個對象，那么在快照隔離下對該對象的任何并發(fā)引用都將導致快照事務失敗。READ_COMMITTED_SNAPSHOT 數據庫選項為 ON 時，已提交讀事務沒有此限制。例如，數據庫管理員執(zhí)行下面的 ALTER INDEX 語句。 USE AdventureWorks;

GO

ALTER INDEX AK_Employee_LoginID

ON HumanResources.Employee REBUILD;

GO

執(zhí)行 ALTER INDEX 語句后，任何在執(zhí)行 ALTER INDEX 語句時處于活動狀態(tài)的快照事務，如果試圖引用 HumanResources.Employee 表，都將收到錯誤。而使用行版本控制的已提交讀事務不受影響。

3．BULK INSERT 操作可能會導致對目標表元數據的更改（例如，禁用約束檢查時）。如果出現(xiàn)這種情況，訪問大容量插入表的并發(fā)快照隔離事務將失敗。

設置SNAPSHOT：

設置SNAPSHOT隔離模式也很簡單，只要我們簡單的一步操作就可以實現(xiàn)。

ALTER DATABASE DATABASE_NAMESET ALLOW_SNAPSHOT_ISOLATION ON;

但是要注意：如果 ALLOW_SNAPSHOT_ISOLATION 數據庫選項設置為 ON，則數據庫中數據已修改的所有活動事務完成之前，Microsoft SQL Server Database Engine 實例不會為已修改的數據生成行版本。如果存在活動的修改事務，SQL Server 將把該選項的狀態(tài)設置為 PENDING_ON。所有修改事務完成后，該選項的狀態(tài)更改為 ON。在該選項完全處于 ON 狀態(tài)之前，用戶無法在數據庫中啟動快照事務。數據庫管理員將 ALLOW_SNAPSHOT_ISOLATION 選項設置為 OFF 后，數據庫將跳過 PENDING_OFF 狀態(tài)。

下面是ALLOW_SNAPSHOT_ISOLATION 選項的各個狀態(tài)當前數據庫的快照隔離框架狀態(tài)說明OFF未啟用對快照隔離事務的支持。不允許執(zhí)行快照隔離事務。PENDING_ON對快照隔離事務的支持處于轉換狀態(tài)（從 OFF 到 ON）。打開的事務必須完成。

不允許執(zhí)行快照隔離事務。ON已啟用對快照隔離事務的支持。

允許執(zhí)行快照事務。PENDING_OFF對快照隔離事務的支持處于轉換狀態(tài)（從 ON 到 OFF）。

此后啟動的快照事務無法訪問此數據庫。更新事務仍會導致此數據庫中出現(xiàn)版本控制開銷。現(xiàn)有快照事務仍可以訪問此數據庫，不會遇到任何問題。直到數據庫快照隔離狀態(tài)為 ON 時處于活動狀態(tài)的所有快照事務完成后，狀態(tài) PENDING_OFF 才變?yōu)?OFF。

SNAPSHOT的使用：

下面是使用READ_COMMITTED_SNAPSHOT的一個例子： 在快照隔離下運行的事務可以訪問數據庫中為快照啟用的表。若要訪問沒有為快照啟用的表，則必須更改隔離級別。例如，下面的代碼示例顯示了在快照事務下運行時聯(lián)接兩個表的 SELECT 語句。一個表屬于未啟用快照隔離的數據庫。當 SELECT 語句在快照隔離下運行時，該語句無法成功執(zhí)行。SET TRANSACTION ISOLATION LEVEL SNAPSHOT;

BEGIN TRAN

SELECT t1.col5, t2.col5

FROM Table1 as t1

INNER JOIN SecondDB.dbo.Table2 as t2

ON t1.col1 = t2.col2;

下面的代碼示例顯示了已修改為從事務隔離級別更改為已提交讀隔離級別的相同 SELECT 語句。由于此更改，SELECT 語句將成功執(zhí)行。

SET TRANSACTION ISOLATION LEVEL SNAPSHOT;

BEGIN TRAN

SELECT t1.col5, t2.col5

FROM Table1 as t1

WITH (READCOMMITTED)

INNER JOIN SecondDB.dbo.Table2 as t2

ON t1.col1 = t2.col2;

SNAPSHOT的演示:

在此示例中，在快照隔離下運行的事務將讀取數據，然后由另一事務修改此數據。快照事務不阻塞由其他事務執(zhí)行的更新操作，它忽略數據的修改繼續(xù)從版本化的行讀取數據。但是，當快照事務嘗試修改已由其他事務修改的數據時，快照事務將生成錯誤并終止。

在會話 1 上：

USE AdventureWorks;GO

--在數據庫上開啟snapshot隔離級別.ALTER DATABASE AdventureWorksSET ALLOW_SNAPSHOT_ISOLATION ON;GO

-- 開始一個snapshot事務SET TRANSACTION ISOLATION LEVEL SNAPSHOT;GOBEGIN TRANSACTION;

--選擇EmployeeID號為4的員工的休假資料SELECT EmployeeID, VacationHoursFROM HumanResources.EmployeeWHERE EmployeeID = 4;

在會話 2 上：USE AdventureWorks;GO

-- 開始一個事務BEGIN TRANSACTION;

--我們修改了EmployeeID為4的員工的休假資料UPDATE HumanResources.EmployeeSET VacationHours = VacationHours - 8WHERE EmployeeID = 4;

-- 確認下現(xiàn)在EmployeeID為4的員工的休假資料SELECT VacationHoursFROM HumanResources.EmployeeWHERE EmployeeID = 4;

在會話 1 上：

--因為會話二的事務沒有提交，--EmployeeID為4的員工的休假資料因該沒變SELECT EmployeeID, VacationHoursFROM HumanResources.EmployeeWHERE EmployeeID = 4;

在會話 2 上：--提交我們的更新，數據被更改了COMMIT TRANSACTION;GO

在會話 1 上：

--OK，現(xiàn)在看看小4同志的資料，被修改的數據被華麗的無視了SELECT EmployeeID, VacationHoursFROM HumanResources.EmployeeWHERE EmployeeID = 4;

--現(xiàn)在我們也來嘗試下修改小4同志的資料，--事務即將崩潰，請系緊安全帶。^_^.UPDATE HumanResources.EmployeeSET SickLeaveHours = SickLeaveHours - 8WHERE EmployeeID = 4;

--ROLLBACK之后小4的數據到底是什么？你知道嗎？ROLLBACK TRANSACTIONGO

http://www.cnblogs.com/trisaeyes/archive/2006/12/30/607994.html