KB2653893 - 修正：在 2008 R2、SQL Server 2008 或 SQL 2012 中還原資料庫需要很長時間SQL Server

徵兆

在 Microsoft SQL Server 2008 R2、Microsoft SQL Server 2008 或 Microsoft SQL Server 2012 中還原資料庫可能需要很長時間。

原因

此問題發生是因為當資料庫中有多個 VLF) 清單，建立虛擬日誌檔案 (VLF 清單會花費較長時間。

解決方案

狀態

Microsoft 已確認＜適用於＞一節中所列的 Microsoft 產品確實有上述問題。

其他相關資訊

你可以透過查看 SQL 錯誤日誌檔案，然後在每個交易日誌備份檔中找到 LSN) 的日誌序號 (來檢查 VLF 區段的數量。 LSN 中冒號符號前的首位數字對應 LSN 的編號。

例如，LSN 第一則資訊訊息中的第一個數字是 1。 然而，LSN 第二則資訊訊息中的第一個數字是 100001。 在此情境中，從第一則資訊訊息到第二則資訊訊息之間，有 100,000 個 VLF 被使用。 因此，包含多個虛擬日誌Files (VLF的分段交易日誌) 類似以下情況：

{原木積壓了。 資料庫：mydbname，建立日期 (時間) ：2010/07/08 (12：36：46) ，首次 LSN：1：5068：70，最後 LSN：1：5108：1，傾印裝置數：1，裝置資訊： (FILE=1，TYPE=DISK：{'C：\folder\logbackup1.trn'}) 。 這只是一則資訊訊息。 不需要使用者操作。

原木被積壓了。 資料庫：mydbname，建立日期 (時間) ：2010/07/08 (15：36：46) ，第一個 LSN：100001：5108：1，最後 LSN：100002：5108：1，傾印裝置數：1，裝置資訊： (FILE=2，TYPE=DISK：{'C：\folder\logbackup2.trn'}) 。 這只是一則資訊訊息。 不需要使用者操作。}

參考

欲了解更多關於 LSN) (日誌序列號的資訊，請造訪以下 MSDN 網站：

關於日誌序列號的一般資訊

欲了解更多日誌檔案結構如何影響資料庫復原時間的資訊，請造訪以下 MSDN 網站：

日誌檔案結構如何影響資料庫復原時間

欲了解更多關於交易日誌 VLF 的資訊，請造訪以下 MSDN 網站：

關於交易日誌檔案的一般資訊

因應措施 

• 請等待還原或復原操作完成
  
  。如果您有一個尚未還原的資料庫，且在還原或恢復時出現效能緩慢，您可能需要等待還原或復原操作完成。 例如，你可能會在 SSMS) 中看到SQL Server Management Studio (未恢復資料庫的離線狀態或恢復狀態。 停止 SQL Server 通常無法緩解緩慢的復原，且可能需要更多時間重複相同的復原分析、重做或復原階段。

• 避免還原包含數千個 VLF 的交易日誌序列。
  
  如果你在使用備份檔案還原和恢復資料庫時遇到效能緩慢，可以避免還原包含數千個 VLF 的交易日誌序列。 要找出記錄虛擬日誌檔案最多的備份檔案，請使用以下陳述來查看日誌備份檔案中的 FirstLSN 和 LastLSN 欄位：
  RESTORE HEADERONLY FROM DISK='C：\folder\file.trn'
  
  你可以決定避免還原日誌備份檔案。 或者，你可以在 RESTORE 指令中使用 STOP AT 陳述式，以避免交易日誌中高度碎片化的部分。 若未完整還原至故障復原情境中最新時間點的日誌序列，資料會在資料庫 SQL Server 中遺失。 這種資料遺失是因為並非所有交易都被保留。 因此，這是一個商業權衡的抉擇。 你可以完全還原高度碎片化的交易日誌。 然而，這項手術可能需要數小時。 或者，你可以在復原中使用 STOP AT 陳述式，在日誌高度碎片化的部分前停止復原。 但如果你遺漏了，所有遺失的交易都會遺失。
  
  注意：若不安裝此熱修正，重啟 SQL Server 後通常無法安全恢復。 SQL Server 必須先找到 VLF 清單來分析日誌檔案、重新執行已完成的交易，然後復原未完成的交易以完成復原，才能安全讓資料庫上線。 在恢復期間，你無法安全地跳過交易。