回顧一下SNAPSHOT的構(gòu)架：

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

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

SNAPSHOT的限制：

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

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

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

GO

ALTER INDEX AK_Employee_LoginID

ON HumanResources.Employee REBUILD;

GO

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

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

設(shè)置SNAPSHOT：

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

ALTER DATABASE DATABASE_NAMESET ALLOW_SNAPSHOT_ISOLATION ON;

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

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

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

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

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

SNAPSHOT的使用：

下面是使用READ_COMMITTED_SNAPSHOT的一個例子： 在快照隔離下運行的事務(wù)可以訪問數(shù)據(jù)庫中為快照啟用的表。若要訪問沒有為快照啟用的表，則必須更改隔離級別。例如，下面的代碼示例顯示了在快照事務(wù)下運行時聯(lián)接兩個表的 SELECT 語句。一個表屬于未啟用快照隔離的數(shù)據(jù)庫。當(dāng) 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;

下面的代碼示例顯示了已修改為從事務(wù)隔離級別更改為已提交讀隔離級別的相同 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的演示:

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

在會話 1 上：

USE AdventureWorks;GO

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

-- 開始一個snapshot事務(wù)SET TRANSACTION ISOLATION LEVEL SNAPSHOT;GOBEGIN TRANSACTION;

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

在會話 2 上：USE AdventureWorks;GO

-- 開始一個事務(wù)BEGIN TRANSACTION;

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

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

在會話 1 上：

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

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

在會話 1 上：

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

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

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

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