MSSQL 增量數據庫到數據庫備份/複製
我正試圖在我不斷被要求做的重複任務上節省一些時間。
我們有一個內部應用程序，我們稱之為“App”。
這個應用程序有一個名為“AppLive”的數據庫
我們有一個相同應用程序的“測試”實例，它使用數據庫“AppTesting”。這樣我們就可以在不影響實時數據的情況下執行測試等。
當使用者想開始玩應用程序的測試實例時，我被要求“將實時數據導入測試數據庫”。他們需要從我們的 AppLive 數據庫導入到 AppTesting 數據庫的最新實時數據集。
我目前的流程是這樣的：
對活動數據庫進行最近的每晚完整備份。刪除測試數據庫 將 AppLive 備份文件“還原”到名為 AppTesting 的新數據庫（與已刪除數據庫同名）。
這為我們提供了進入 Test 數據庫的最新夜間數據。
問題在於數據庫變得越來越大。它大約 11GB - 備份文件遠端儲存在 NAS 驅動器上。
所以我必須等待 45 分鐘才能將數據庫備份文件傳輸到 SQL 伺服器上，然後開始導入。這又需要一個絕對的年齡。
我對此的理想解決方案是：
繼續每晚對 AppLive 數據庫進行完整備份（以滿足我們的正常備份要求），並在此基礎上對我進行增量備份 - 這樣當我必須將實時數據導入我們的測試數據庫時，我就不必玩了巨大的 11GB 文件。理想情況下，我希望能夠對 MSSQL 管理工作室說“請使用來自 AppLive 的所有新數據更新 AppTest db” - 我不希望這樣安排，測試數據必須保持靜態，直到我們被要求更新它與新數據。
我希望這足夠清楚，並且有人能夠指出我正確的方向。
你有幾個選擇。
1）編寫一個powershell腳本或其他東西來自動恢復。這把它變成了火然後忘記了。然後，您可以選擇將其與工具的預定執行（例如在星期日）結合到第三個數據庫中。這將意味著與測試數據庫的消費者坐下來弄清楚他們對陳舊數據的容忍度（即數據庫需要多新鮮）。然後，當請求刷新數據時，刪除目前的測試數據庫，將恢復的數據庫重命名為副本（您可能還想重命名物理文件），一切順利。
日誌傳送
數據庫鏡像。
對於您要完成的工作，選項 2 和 3 似乎有些矯枉過正。