SQL Server 2016：由於龐大的事務日誌，無法從 .bak 文件恢復數據庫？
從我們的生產伺服器上，我下載了一個 SQL Server 2014 的 .bak 文件，我想在我的電腦中的 SQL Server 2016 Developer 中恢復該文件，以使用最新數據測試應用程序的較新版本。
我從 SSMS 恢復數據庫，雖然進度條在幾秒鐘內達到 100%（.bak 文件大約為 145 MB），但該過程仍然像這樣卡住，沒有任何事情發生，即使恢復過程似乎仍在繼續。
我注意到，一旦恢復過程開始，就會立即創建一個非常大的事務日誌，它的大小超過 300 GB。
我該如何解決這個問題？我已經讀過也許我應該在創建 .bak 文件之前縮小事務日誌，但我害怕對生產數據庫造成損害。我應該以正確的方式做什麼？
當您備份數據庫時，它會從您的數據庫中獲取所有數據以及在還原後將數據庫置於一致狀態所需的部分事務日誌。
當您從備份還原數據庫時，它會準確創建已備份的數據庫，因此如果您現在有一個 300Gb 的日誌文件，則意味著您的生產伺服器上的原始數據庫有一個 300Gb 的日誌文件。
是的，您
shrink現在可以在測試伺服器上創建日誌文件，但首先您應該將數據庫放入SIMPLE RECOVERY MODEL. 這不會影響您的生產數據庫。但是如果您的備份大小僅為 145Mb，這意味著您的生產數據庫存在問題：有人將其放入
FULL RECOVERY MODEL並且不進行日誌備份。從您的數據庫大小中可以清楚地看出：當日誌文件比數據文件大 300 倍以上時，這是錯誤恢復模式的問題這是檢查數據庫大小的程式碼：
use yourDB; select name, type_desc, cast(size * 8. / 1024 as decimal(20,2)) as Mb from sys.database_files;更新：
…每天晚上製定維護計劃，以便對數據庫進行完整備份，重新組織/更新索引，並每週更新一次統計資訊。到目前為止，夜間備份一直就足夠了。
…無論如何，我是否應該保留事務日誌和完整恢復模型，我應該知道什麼來改進事情？我的意思是，如果我想進行日誌備份以減少事務日誌，我該怎麼辦？我是否應該更改維護計劃中的任何設置
您不需要完整的恢復模式。就目前而言，您的備份計劃假設您可以接受失去 1 天的工作，並且對於小型非關鍵數據庫來說這是正常的。
當您在 中時
simple recovery model，最低限度記錄的操作如index rebuild或select into將被最低限度地記錄，這意味著它們會更快。如果您需要恢復數據庫，這將是從完整備份中進行的一次簡單恢復。
您的日誌管理將是最小的：它將在檢查點自動截斷。
當您在其中時，
full recovery model這意味著您對數據的每次更改都將被完整記錄，並且所有更改都將保留在您的日誌文件中，直到您進行日誌備份。所以現在發生在你身上的是你的日誌文件包含了從你的第一次完整備份（因為沒有進行日誌備份）到現在對你的數據庫所做的所有更改。如果您現在備份日誌，您將等待比今天等待 300Gb 日誌空間歸零的時間更長。要備份此日誌，您需要足夠的磁碟空間，大約 300Gb。此備份完成後，即使您嘗試縮小日誌大小也不會改變，因為日誌的活動部分將駐留在最後一個 VLF 中。
因此，即使在進行瞭如此龐大的日誌備份之後，如果您決定堅持使用完全恢復模式，您的日誌大小仍然會存在問題。您必須等到日誌的活動部分移動到第一個 VLF，這可能需要一些時間，因為您的數據庫足夠小，更改也很小，但您的最後一個 VLF 是巨大的。在shrinkig 之後，您必須決定多久進行一次日誌備份以及適合您數據庫的日誌文件大小。
那麼誰以及為什麼選擇完全恢復模式呢？一些 HA 技術需要它：日誌傳送、鏡像、AOAG。或者不允許數據失去的人。例如，如果今天您的數據文件失去了，您可以使用日誌備份 (300Gb) 的尾部並將數據庫恢復到其生命的最後一分鐘，方法是先恢復昨晚的完整備份，然後再恢復日誌備份。如果沒有它，您所能做的就是從昨天的備份中恢復您的數據庫，即恢復的數據庫將包含昨天狀態的數據，而今天的所有工作都失去了。
他們在評論中談論什麼？時間點還原。完全恢復模式允許您將數據庫恢復到過去的任何時間點（當然，只有在您擁有完整的日誌備份鏈的情況下）。你真的需要嗎？當您被告知將您的數據庫帶到 2017-01-04 03:45:00 時，是否會出現這種情況？或者也許將它帶回 2017-01-04 00:00:00，即完整備份的時間就足夠了？如果只有後者，您可以保持簡單的恢復模式並繼續在每晚 00:00:00 備份您的數據庫
我只是不知道如何將值得一本書的材料放在一頁中:) 嘗試從 BOL 開始：恢復模型和事務日誌管理