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

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

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

SNAPSHOT的限制：

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

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

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

GO

ALTER INDEX AK_Employee_LoginID

ON HumanResources.Employee REBUILD;

GO

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

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

設(shè)置SNAPSHOT：

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

ALTER DATABASE DATABASE_NAMESET ALLOW_SNAPSHOT_ISOLATION ON;

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

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

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

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

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

SNAPSHOT的使用：

下面是使用READ_COMMITTED_SNAPSHOT的一個(gè)例子： 在快照隔離下運(yùn)行的事務(wù)可以訪問數(shù)據(jù)庫(kù)中為快照啟用的表。若要訪問沒有為快照啟用的表，則必須更改隔離級(jí)別。例如，下面的代碼示例顯示了在快照事務(wù)下運(yùn)行時(shí)聯(lián)接兩個(gè)表的 SELECT 語(yǔ)句。一個(gè)表屬于未啟用快照隔離的數(shù)據(jù)庫(kù)。當(dāng) SELECT 語(yǔ)句在快照隔離下運(yùn)行時(shí)，該語(yǔ)句無法成功執(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ù)隔離級(jí)別更改為已提交讀隔離級(jí)別的相同 SELECT 語(yǔ)句。由于此更改，SELECT 語(yǔ)句將成功執(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的演示:

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

在會(huì)話 1 上：

USE AdventureWorks;GO

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

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

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

在會(huì)話 2 上：USE AdventureWorks;GO

-- 開始一個(gè)事務(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;

在會(huì)話 1 上：

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

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

在會(huì)話 1 上：

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

--現(xiàn)在我們也來嘗試下修改小4同志的資料，--事務(wù)即將崩潰，請(qǐng)系緊安全帶。^_^.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