SQL Server數據庫快照的工作方式

翻譯自：How Database Snapshots Work

最近有一個帖子《errorlog中的異常信息rolled forward 和rolled back》

里面說到：

每周六凌晨1點會出現以下信息，服務器及數據庫未出現重啟，節點未切換，filestream access level =0

Configuration option 'user options' changed from 0 to 0. Run the RECONFIGURE statement to install.

FILESTREAM: effective level = 0, configured level = 0, file system access share name = 'MSSQLSERVER'.

148 transactions rolled forward in database 'XX_DB' (12). This is an informational message only. No user action is required.

1 transactions rolled back in database 'XX_DB' (12). This is an informational message only. No user action is required.

Recovery completed for database XX_DB (database ID 12) in 21 second(s) (analysis 22 ms, redo 15062 ms, undo 3293 ms.) This is an informational message only. No user action is required.

 為什麽會有rolled back和rolled forward？

回復者給出了下面答案：

是DBCC CHECKDB造成的，由於DBCC CHECKDB在執行時要先創建一個數據庫快照，所以才會有這些提示。

這些提示並不是針對當前數據庫，而是針對快照庫，所以當前數據庫不會有rolled forward和 rolled back。

如果還有伴有其它error信息，才可能是真的遇到問題了。

參考：

http://social.msdn.microsoft.com/Forums/sqlserver/en-US/46e87f6e-5725-4c46-95b6-b458ab993cd7/transactions-being-rolled-back-and-forward-by-dbcc-checkdb-is-this-ok

http://www.sqlservercentral.com/Forums/Topic617175-149-1.aspx#bm617327

http://support.microsoft.com/kb/926070/zh-cn

但是回復者還沒有回復一個問題：

Configuration option 'user options' changed from 0 to 0. Run the RECONFIGURE statement to install.

FILESTREAM: effective level = 0, configured level = 0, file system access share name = 'MSSQLSERVER'.

為什麽會出現FILESTREAM？？LZ說他們的系統沒有使用到FILESTREAM的相關功能

今晚又看了一篇文章《如何大幅提高DBCC CHECKDB/DBCC CHECKTABLE的性能》

里面說到：

正常情況下，CHECKDB/CHECKTABLE的運行不會對數據庫使用排它鎖，而是使用內部數據庫快照(internal database snapshot)。

這個內部數據庫快照實質就是Sparse Filestream, 它使用sparse file，COPY-ON-WRITE技術。詳細的工作原理可以參考如下的文檔：
 
數據庫快照的工作方式
http://msdn.microsoft.com/en-us/library/ms187054(v=SQL.105).aspx

 

我決定翻譯一下這篇文章，看文章里是否有說到FILESTREAM

---

正文

數據庫快照提供了一個在源數據庫創建快照的時候只讀的靜態視圖，這個靜態視圖會把還沒有提交的事務去除掉

沒有提交的事務會在新創建的數據庫快照里被回滾，因為數據庫引擎會在數據庫快照創建完之后運行修復檢查程序

但是，源數據庫中的事務不會受到任何影響

 

數據庫快照是獨立於源數據庫的。快照數據庫會作為一個數據庫存在於同一數據庫服務器實例中

此外，無論什么原因，當數據庫變為不可用的狀態的時候，快照數據庫也一樣變為不可用

快照數據庫不單只可以用來做報表之用，當在源數據庫發生一個用戶錯誤的時候，你可以修復源數據庫到數據庫快照被創建的那個時刻

自從數據庫快照被創建之后，數據丟失僅僅限於快照創建之后的那些數據庫數據更新的丟失

而且，創建數據庫快照對於在一個大的數據庫更新操作之前特別有用，例如改變數據庫的架構或者表結構

對於更多數據庫快照的用途，大家可以看一下數據庫快照的典型應用

 

理解數據庫快照的工作方式是很有幫助的，雖然不一定要使用數據庫快照。數據庫快照操作的級別是“頁面級別”

在源數據庫的一個頁面被第一次修改之前，源數據頁面會從源數據庫復制到數據庫快照。這個過程叫做：“COPY-ON-WRITE”操作

 

數據庫快照存儲了源數據頁面，保留當快照被創建時已經存在的數據記錄。后來的數據頁面修改不會影響到快照里的頁面內容。

對於每一個第一次被修改的頁面會重復上面的COPY-ON-WRITE操作。用這種方法，快照會保存保留了所有已經被修改的數據記錄的原始頁面

當快照被創建的時候。

 

為了存儲這些復制的原始頁面，快照使用一個或者多個稀疏文件。最初，一個稀疏文件實際上是一個沒有用戶數據和還沒有分配磁盤空間的空白的文件

當源數據庫里越來越多的數據頁面被更新，數據文件的size會增長。當快照建立之后，稀疏文件只會占用一點磁盤空間，當源數據庫不斷更新，

一個稀疏文件會增長成為一個大文件

想知道稀疏文件的更多信息，可以參閱：Understanding Sparse File Sizes in Database Snapshots

 

下面的圖片描述了一個"copy-on-write"操作。在下面的快照圖里灰白色的方塊表示一個稀疏文件里還沒有被分配的空間

當接收到第一個源數據庫的第一個數據頁面更新，數據庫引擎會將頁面寫入到稀疏文件，並且操作系統會在快照的稀疏文件里分配

空間然后復制原始數據頁。然后數據庫引擎會更新源數據庫的數據頁面。

 

 

注意：因為數據庫快照不是數據庫存儲冗余，快照不會防止磁盤錯誤或者其他類型的數據庫損壞。如果你必須還原源數據庫到某一個

時間點，這個時間點是數據庫快照創建的時刻，那么你就要執行一個備份策略，從數據庫備份中還原，而不是從數據庫快照中還原

 

數據庫快照的讀操作

對於用戶來講，數據庫快照從來不會發生改變，因為在數據庫快照上的讀操作總是訪問原始數據頁面無論這些數據頁面來自哪里

如果在源數據庫的數據頁面從來沒有被更新過，快照上的讀操作會讀取源數據庫的源數據頁面。下面的圖片顯示了一個在剛剛新建的快照上

的讀操作，對應的稀疏文件並沒有包含任何數據頁面。這個讀操作只會讀取源數據庫的數據

 

 

當有一個數據頁面被更新之后，快照上的讀操作就會訪問存儲在稀疏文件里原始數據頁面，下面的圖片描述了一個快照上的讀操作

訪問一個在源數據庫被更新了的數據頁面。讀操作讀取快照稀疏文件里的原始頁面。

 

數據庫快照增長對於更新模式的影響

如果你的源數據庫相當大並且你正在關注磁盤空間的使用率，在某一時刻你應該用新的數據庫快照替換舊的快照。

理想的數據庫快照生存期依據於快照的增長速率和磁盤的可用空間。所需的磁盤空間取決於快照期間源數據庫有多少的數據頁面被更新了

因此，如果大部分的更新只是一小部分頁面的重復更新，快照增長速率會比較慢，快照所需空間也會保持相對比較小的空間

相反，當所有原始頁面至少最終被更新，快照會增長到與源數據庫大小一樣。如果磁盤開始填滿，快照和磁盤會進行相互競爭對於磁盤空間

如果磁盤已經沒有空間，對於快照的寫操作會失敗

 

記錄：關於實際和潛在的快照大小的更多信息可以參閱：Understanding Sparse File Sizes in Database Snapshots

 

因此，當計划要多少磁盤空間在快照期間知道典型的數據庫更新模式是很有用的。對於某些數據庫，更新的頻率是固定的，

例如：一個庫存數據庫有可能有很多每日都需要更新的頁面，每日或每個星期替換舊的數據庫快照是很有用的。對於其他數據庫，

頁面更新的比例有可能有很大的不同在業務運作期間；例如，一個目錄數據庫有可能只在季度更新，在其他時間只會偶爾更新

在季度的交替前和后創建數據庫快照是一種業務策略。季度交替前的數據庫快照允許修復重要的更新錯誤

而季度交替后的快照能夠被用來做報表寫入一直到下一個季度

 

下面的圖片描述了兩種更新模式的數據庫快照的size的影響。

更新模式A影響只有30%原始頁面被更新的快照環境

更新模式B影響80%原始頁面被更新的快照環境

 

數據庫快照的元數據

對於數據庫快照，數據庫元數據包括源數據庫ID屬性，ID屬性存儲在sys.databases目錄視圖里的某一列里

更多關於ID屬性的信息，可以查看sys.databases (Transact-SQL).

通常，一個數據庫快照不會顯示元數據信息（就是說你查不到快照數據庫里面的一些元數據），不過你可以從源數據庫那里查詢這些元數據。

這些元數據包括，下面的SQL語句返回的數據

USE <database_snapshot> 
SELECT * FROM sys.database_files 

 

唯一的異常是：當源數據庫使用全文搜索或者鏡像數據庫時，在快照數據庫里禁用他們（禁用這些技術）

通過改變一些設置值利用數據庫快照的元數據

---

很可惜還是沒有看到FILESTREAM的相關信息

百度了一下，下面的3篇文章都在SQLSERVER啟動的時候看到這句話

FILESTREAM: effective level = 0, configured level = 0, file system access share name = 'MSSQLSERVER'.

http://wenwen.soso.com/z/q163659365.htm

http://bbs.csdn.net/topics/370129706

http://wenwen.soso.com/z/q163659365.htm

應該是FILESTREAM功能檢查，並不是數據庫快照相關的

 

 

 

2013-11-29補充：

這里感謝 nzperfect大俠

對於這條信息：FILESTREAM: effective level = 0, configured level = 0, file system access share name = 'MSSQLSERVER'.

他給出了一個鏈接：

http://connect.microsoft.com/SQLServer/feedback/details/687963/reconfigure-statement-causes-non-useful-entries-to-be-written-to-the-sql-server-log

里面說到是SQL2008和SQL2008R2 的錯誤日志冗余信息，即使你沒有開啟FILESTREAM功能也會有這條信息的

本人在SQL2005 SP4和SQL2012 SP1的錯誤日志里並沒有發現FILESTREAM相關的錯誤日志記錄

應該是SQL2005的時候還沒有出FILESTREAM技術，而在SQL2012的時候已經把這個冗余信息去掉了。

非常感謝nzperfect大俠

SQL2008R2 FILESTREAM冗余錯誤日志記錄的截圖

 

如有不對的地方，歡迎大家拍磚o(∩_∩)o 

 

2013-12-2補充：

http://msdn.microsoft.com/zh-cn/library/ms186858(v=sql.120).aspx

數據庫還原是可以從數據看快照中還原的

還原使用 BACKUP 命令所做的備份。 通過此命令，您可以執行下列還原方案：
（1）基於完整數據庫備份還原整個數據庫（完整還原）。
（2）還原數據庫的一部分（部分還原）。
（3）將特定文件或文件組還原到數據庫（文件還原）。
（4）將特定頁面還原到數據庫（頁面還原）。
（5）將事務日志還原到數據庫（事務日志還原）。
（6）將數據庫恢復到數據庫快照捕獲的時間點。

 

K.從數據庫快照恢復

 

下面的示例將數據庫恢復到數據庫快照。 該示例假定該數據庫當前僅存在一個快照。 有關如何創建此數據庫快照的示例，請參閱創建數據庫快照 (Transact-SQL)。

 注意

恢復到快照將刪除所有全文目錄。

 

 

USE master;  
RESTORE DATABASE AdventureWorks2012 FROM DATABASE_SNAPSHOT = 'AdventureWorks_dbss1800';
GO

有關詳細信息，請參閱將數據庫恢復到數據庫快照。