承接上篇，本文說明快照建立後的驗證操作、多快照管理、磁碟空間消耗模型與效能影響，提供生產環境部署建議。
驗證快照資料一致性
來源資料庫再次插入 10,000 筆資料後：
- 來源資料檔：12,480 KB
- 稀疏檔案實體：448 KB（含首批 10,000 筆對應的變更頁）
- 查詢快照資料庫 → 僅見前 30,000 筆資料（快照建立時刻狀態）
- 查詢來源資料庫 → 見 60,000 筆資料（最新狀態）
總結：快照應用優勢
- 報表專用唯讀複本，零鎖定衝突。
- 可建立多個時間點快照，支援歷史趨勢分析。
- 災難復原：
RESTORE DATABASE SourceDatabase FROM DATABASE_SNAPSHOT = 'SnapshotDatabase' 秒級還原（僅回寫變更頁）。
- 誤刪/誤改資料救援：從快照
SELECT INTO 導回來源資料庫。
注意事項與限制
1. 磁碟空間消耗
- 每個快照獨立維護稀疏檔案，來源資料庫寫入越頻繁、快照保留越久，稀疏檔案增長越快。
- 高頻寫入 OLTP 環境，多快照可能迅速填滿磁碟陣列。
- 建議： 設定快照保留期限（如 24 小時）、定期清理舊快照、監控磁碟使用率告警。
2. 效能影響
- 來源資料庫寫入時觸發 Copy-on-Write，增加額外 I/O（讀取原頁、寫入稀疏檔）。
- 大量批次更新期間，效能衝擊明顯。
- 建議： 避開尖峰時段建立快照、快照檔案置於獨立磁碟/磁碟陣列、評估啟用瞬間快照儲存體陣列功能（硬體層面）。
3. 其他限制
- 快照不可備份、不可附加/分離、不可變更 Schema。
- 全文檢索目錄不包含在快照中。
- 來源資料庫設為單一使用者/離線/緊急模式時，快照不可用。
- 鏡像資料庫無法建立快照。
最佳實務部署建議
- 報表專用快照：每日排程建立晨間快照，報表伺服器連線快照查詢。
- 災難復原快照：重大變更前（Schema 變更、大量資料匯入）手動建立快照。
- 命名慣例：
DBName_Snapshot_YYYYMMDD_HHMM，便於識別與清理。
- 自動化清理作業：
DROP DATABASE SnapshotDatabase_... 刪除過期快照。
