在SQL Server 2005中，它的另外一個強大的新特點是數(shù)據(jù)庫快照。數(shù)據(jù)庫快照是一個數(shù)據(jù)庫的只讀副本，它是數(shù)據(jù)庫所有數(shù)據(jù)的映射，由快照被執(zhí)行的時間點來決定它的內(nèi)容。

這些數(shù)據(jù)庫快照在報表方面是非常有價值，因為在快照數(shù)據(jù)庫中或者在原數(shù)據(jù)庫中，對于任何查詢而言沒有鎖就將被執(zhí)行。快照也可以使用在災(zāi)難恢復(fù)中，因為你可以將現(xiàn)有的數(shù)據(jù)恢復(fù)到現(xiàn)有的快照中，或者還可以在有害數(shù)據(jù)操作聲明的事件中存儲個別必要的表和數(shù)據(jù)。

數(shù)據(jù)庫快照是如何工作的?

可以使用典型的數(shù)據(jù)庫命令CREATE DATABASE語句來生成一個數(shù)據(jù)庫快照，在聲明中有一個源數(shù)據(jù)庫快照的附加說明。當(dāng)快照被建立時，同時生成一個稀疏文件。這個文件（只能使用在NTFS卷中）在初始化的時候并沒有磁盤空間分配給它——盡管你可能在WINDOWS資源管理器中看到了文件的大小，它會看上去與原始的源數(shù)據(jù)庫文件的大小相同。對磁盤來說其實這個文件的大小接近于零。

數(shù)據(jù)庫快照在初始化時讀的數(shù)據(jù)文件是來自于源數(shù)據(jù)庫的。當(dāng)源數(shù)據(jù)庫的數(shù)據(jù)發(fā)生變化時，數(shù)據(jù)引擎就會將原始數(shù)據(jù)從源數(shù)據(jù)庫拷貝到快照數(shù)據(jù)庫中。這個技術(shù)確保快照數(shù)據(jù)庫只反映快照被執(zhí)行時數(shù)據(jù)的狀態(tài)。當(dāng)SELECT命令被用來發(fā)布反對數(shù)據(jù)庫快照時，不管數(shù)據(jù)頁的讀取是否被定位在源數(shù)據(jù)庫數(shù)據(jù)文件中還是在快照數(shù)據(jù)庫數(shù)據(jù)文件中都是沒有鎖被發(fā)布的。因為在只讀數(shù)據(jù)庫快照中是沒有鎖被發(fā)布，數(shù)據(jù)庫快照對于報表解決方案是一個重要的解決方案。

一個快照的實例

現(xiàn)在，讓我們來看看數(shù)據(jù)庫快照在SQL Server 2005中是如何工作的。為此，首先我需要一個源數(shù)據(jù)庫作為快照的來源。下面的腳本將創(chuàng)建一個源數(shù)據(jù)庫：

USE masterGOIF EXISTS(SELECT name from sysdatabases where [name] = 'SourceDatabase')DROP DATABASE SourceDatabaseGO

CREATE DATABASE SourceDatabaseON PRIMARY( NAME = SourceDatabase_Data,FILENAME = 'C:SQLServerSourceDatabase_Data.mdf') LOG ON(NAME = SourceDatabase_Log,FILENAME = 'C:SQLServerSourceDatabase_Log.ldf')GO

注意這里產(chǎn)品區(qū)域的大小。我定義它的大小為CHAR（150）來強調(diào)數(shù)據(jù)文件的增長級數(shù)，這樣在我接下來的實例中將更容易解釋清楚快照是如何工作的。

現(xiàn)在既然我已經(jīng)有了一個源數(shù)據(jù)庫，現(xiàn)在我裝載一些數(shù)據(jù)來擴展數(shù)據(jù)文件的大小位。如此，使用上面的腳本來創(chuàng)建銷售歷史表。

USE SourceDatabaseGOIF OBJECT_ID('SalesHistory')>0;;;DROP TABLE SalesHistoryGOCREATE TABLE SalesHistory(;;;SaleID INT IDENTITY(1,1),;;Product CHAR(150),;;;;SaleDate DATETIME,;;;;SalePrice MONEY)

DECLARE @i INTSET @i = 1WHILE (@i <=10000)

BEGIN;;;INSERT INTO SalesHistory;;;(Product, SaleDate, SalePrice);;;VALUES;;;('Computer', DATEADD(mm, @i, '3/11/1919'), DATEPART(ms, GETDATE()) + (@i + 57) )

INSERT INTO SalesHistory;;;(Product, SaleDate, SalePrice);;;VALUES;;;('BigScreen', DATEADD(mm, @i, '3/11/1927'), DATEPART(ms, GETDATE()) + (@i + 13) )

INSERT INTO SalesHistory;;;(Product, SaleDate, SalePrice);;;VALUES;;;('PoolTable', DATEADD(mm, @i, '3/11/1908'), DATEPART(ms, GETDATE()) + (@i + 29) )

SET @i = @i + 1

ENDGO

一旦你運行以下的腳本，就可以來操縱數(shù)據(jù)庫文件儲存的地方了。在這個實例上面，我將這些文件放在C:SQL Server文件夾下。在我的計算機上，當(dāng)數(shù)據(jù)庫被初始化創(chuàng)建時數(shù)據(jù)文件的大小是1,216KB，數(shù)據(jù)裝載后的大小是7,360KB。既然源數(shù)據(jù)庫有一些數(shù)據(jù)已經(jīng)在里面了，所以我們現(xiàn)在就能建立一個快照了。使用以下的腳本來建立數(shù)據(jù)庫快照。

CREATE DATABASE SnapshotDatabaseON(NAME = 'SourceDatabase_Data',FILENAME = 'C:SQLServerSnapshotDatabase.mdf') AS SNAPSHOT OF SourceDatabase

這個創(chuàng)建快照的語法與創(chuàng)建數(shù)據(jù)庫的語法非常相似。兩個主要的區(qū)別：第一個區(qū)別是AS SNAPSHOT OF SourceDatabase語句，在服務(wù)器實例上指明哪個數(shù)據(jù)庫將作為快照的源數(shù)據(jù)庫；第二個區(qū)別是，在事實上數(shù)據(jù)庫快照是不會生成日志文件的。因為沒有數(shù)據(jù)操作事物只會發(fā)生在只讀數(shù)據(jù)庫上，所以沒有也不需要日志。

這個數(shù)據(jù)庫腳本創(chuàng)建一個名為SnapshotDatabase.mdf（數(shù)據(jù)文件的擴展名不需要mdf）的稀疏文件。如果你在WINDOWS資源管理器中操作這個文件，并同時查看它的屬性，你將看到這個文件的大小與源數(shù)據(jù)庫文件的大小相同；然而，實際上磁盤上的大小卻接近于零。這時，數(shù)據(jù)庫快照是沒有它自己的數(shù)據(jù)。

你能運行上面我使用的腳本重新在SourceDatabase數(shù)據(jù)庫里面插入10,000行數(shù)據(jù)到SalesHistory表中。這時，我的SourceDatabase數(shù)據(jù)庫大小是12,480KB，同時，磁盤上我的SourceDatabase數(shù)據(jù)庫大小現(xiàn)在為448KB。這時在SourceDatabase數(shù)據(jù)庫中所改變的數(shù)據(jù)頁都已經(jīng)被拷貝到SnapshotDatabase數(shù)據(jù)庫中了，這樣就能解釋為什么在磁盤上它的大小被增加了。

進一步思考

數(shù)據(jù)庫快照允許你為報表創(chuàng)建只讀數(shù)據(jù)庫，并且如果有必要的話你可以恢復(fù)你的源數(shù)據(jù)庫到你的數(shù)據(jù)庫快照上。同樣的，你也可以根據(jù)你的報表目的創(chuàng)建任意多個數(shù)據(jù)庫快照。

特別值得注意的是，這些數(shù)據(jù)庫快照會占用磁盤空間，如果有太多的數(shù)據(jù)庫快照的話，它將很快的將你的磁盤陣列填滿，尤其在一個產(chǎn)品環(huán)境下，如果數(shù)據(jù)經(jīng)常要被更新，就更容易將磁盤陣列填滿。

另外，使用數(shù)據(jù)庫快照會降低數(shù)據(jù)庫的性能，因為在數(shù)據(jù)庫中將數(shù)據(jù)頁作為執(zhí)行寫操作拷貝是增加了數(shù)據(jù)庫輸入/輸出。

雖然有這些小缺點，如果你能為報表提出一個好的數(shù)據(jù)庫快照創(chuàng)建方案，SQL Server 2005的這個新的特性將有更多的人使用。