SQL Server 嚴重損壞修復

  • 發行項

SQL Server：利用備份從嚴重損壞復原

Paul S。 Randal

T 此處不是採取 SQL Server 的備份，除非您知道如何將它們還原多點。 如果有任何更複雜的比完整資料庫備份的項目則要需要知道一些 RESTORE] 選項，才能順利您資料庫還原至您想要的點的時間。

如果您有複雜的資料庫配置或複雜的備份策略，以及您希望能夠還原，例如單一檔案群組，或利用部分資料庫可用性，這會是更多情況。
只要您有有效的備份策略，而且是有效的備份應該要能夠從災害中修復時間目標 (RTO) 和以修復點目標 (RPO) 復原。 在此三篇系列中第一個本文，我所討論各種類型的備份，以及如何制定備份策略 (請參閱瞭解 SQL Server 備份 在七月 2009年問題)。

本文章中我將說明還原如何運作以及如何執行某些更常見的還原作業。 如果您已閱讀備份發行項和我在該發行項簡介中提到的背景材質，它就會很有幫助。 我也將說明幾個更多棘手作業，例如執行時間點還原和線上逐漸還原部分資料庫可用性與。

只為先前文章中上 BACKUP，我不會說明 RESTORE 語法的運作方式，或瀏覽所有的還原作業的特定步驟。 SQL Server 線上叢書 》 並極佳的工作的。 請參閱 」RESTORE (Transact-SQL)"需相關資訊特別範例散佈整個主題。 還有實際上這麼多選項可供 RESTORE 的整個其他主題，以解釋他們!" 備份及還原 How-To 主題 (SQL Server Management Studio)"解釋如何使用工具來執行還原。

四個階段的還原

讓我們從開始還原實際運作的方式。 還原操作具有最多四個階段：

  1. 檔案建立和初始化
  2. 資料和/或交易記錄檔複本
  3. 取消復原復原的階段
  4. 復原復原的階段

嚴重損壞修復的主要目標是儘速使資料庫上線。 如果您的損毀修復計劃涉及還原備份 (而非，說，容錯移轉到資料庫鏡像)，您將想要還原程序會盡可能動作最快速度。 與每個四個還原步驟記住是有任何可執行的動作以加快速度嗎？

第一個步驟可以被基本上如果略過資料和記錄檔已經存在。 這表示，如果您要覆寫現有的資料庫不刪除資料庫之前先進行還原。 改，使用第一個還原作業的 [WITH 取代] 選項來告訴 SQL Server 使用現有的檔案。 如果這些檔案不存在，它們將被建立並再初始化。 建立該檔案是非常快速，但它們零-初始化的處理序可能會非常緩慢。

基於安全性理由，和預設，所有資料庫檔案會都是零初始化。 您可以啟用立即檔案初始化時，SQL Server 執行個體哪些 skips zeroing 的處理序，資料檔案的建立和成長包括那些還原--即使資料檔案的大小的唯一 gigabytes 因而可節省停機，小時期間所需的作業。 交易記錄檔永遠為零初始化因而交易記錄檔本身的循環的性質。

您可以閱讀更多關於所有的這與參考書目線上，在我立即的初始化" 部落格張貼分類。

您可能會想要知道有關第二個階段--為什麼不會將項目說"及 (或) 交易記錄檔 」 嗎？ 如果您閱讀前一篇文章，您會記得所有完整及差異備份也包含一些交易記錄檔記錄来啟用資料庫還原至一個交易一致的點的時間。 兩個階段是純粹的複製作業--執行沒有處理資料的--所以加速這最主要的方法是有 better-performing 的 I/O 子系統。 這是其中幾次它是可接受"擲回的硬體在問題 」。

其他方法可以加速複製階段是使用某種備份壓縮技術、 任一個原生 SQL Server 2008 或透過各種協力廠商解決方案之一。 複製階段的兩個組件是從備份媒體讀取和寫入資料及/或記錄檔。 如果您可以執行較少的讀取 (使用壓縮的備份媒體)，可以加速整體] 程序的少量的 CPU 資源。

階段三和四個是關於交易記錄檔，要在時間內將資料庫移到交易一致的位置上執行復原。 我說明復原二月 2009年發行項中的詳細資料 」瞭解日誌記錄和恢復 SQL Server 中". 如我稍後會說明，請注意，第四個階段是選擇性。

suffice 嗎] 以說也更多的交易記錄檔，需要復原在還原期間，才會愈長還原。 這表示如果比方說您有一週前從完整資料庫備份且交易記錄檔備份後的再還原程序的本質上會每小時重新顯示從最後一週完成之前的所有交易。 我在前一篇文章--新增差異式備份到整 plus 記錄備份策略中此討論方案。

差異式資料庫備份包含所有資料檔網頁上次的完整資料庫備份之後有變更，並可用於還原作業来避免重新執行完整資料庫備份與差異式資料庫備份之間期間中發生的所有交易。 這可以大幅減少將資料庫還原所需花費的時間而是稍微複雜一點的備份策略。

您可以在線上叢書 》 主題中找到的詳細資訊 」在 SQL Server 的備份與還原效能最佳化".

您需要還原？

當嚴重損壞演時的首先您需要做的是如這即將要聽寫您從嚴重損壞修復時，所必須採取的動作，出什麼已損毀，運作。 存放媒體失敗的可能性包括：

  • 整個資料庫的損害 (比方說任何已儲存資料庫已終結或資料庫是單一的資料檔案和它已經損毀)。
  • 損毀的多重檔案群組資料庫的單一檔案群組。
  • 損毀的多個檔案的檔案群組的單一檔案。
  • 資料庫中的單一頁面的損壞。
  • 透過資料庫散佈傷害。

您可以查明藉由檔案的通知都將無法存取，尋找透過 SQL Server 錯誤記錄檔所頁面-讀取，就會發生錯誤 (針對執行個體、 頁面總和檢查碼失敗或損壞頁偵測錯誤)，或一般損毀時遇到損壞。 損害發生一般作法是執行在 DBCC CHECKDB 一致性檢查作業，以取得如何作用廣泛損毀部份是了解。

一致性檢查的說明這篇文章的討論範圍內，但您可以監看的簡報，我在科技 Ed IT 論壇中標題為 2008 年十一月所做的視訊"損毀生存的技術"，並聆聽從今年年初的 TechNet 廣播面試我討論一下資料庫損毀 (直接下載的連結here).

嚴重損壞並不受限於 I/O 子系統或伺服器失敗--還有要考慮的人為錯誤。 根據不良程式化的應用程式或 careless Transact-SQL 陳述式 (「 我不知道我是在實際執行伺服器上 「 分析藍本)，通常不小心會刪除資料庫資料表 (或從它們的資料)。 在這種情況下可能很困難圖出什麼需要還原] 和 [從時間，什麼點，特別是如果沒有人擁有要提出錯誤。 您可能會運氣使用標準的報告，從預設的追蹤其中 DDL 作業是仍然可以使用或 DELETE 陳述式所攔截由您自己的記錄--但往往還有沒有記錄的誰做什麼到資料庫。 我將討論從這種情況下更詳細地稍後復原。 您尚未復原--無論誰執行資料意外刪除或發生的時、 「 長或更多的時間，傳送前您注意的問題--它可以復原的更複雜。

因此第一個步驟，如果資料庫在 FULL 復原模式中執行，而且交易記錄檔未損毀，執行以確保到在嚴重損壞為止的所有交易已都備份的記錄機尾備份。 這個最終 」 的交易記錄檔備份將會有所有項目往上直到在嚴重損壞的時間，並且可以用於使正在還原遠為盡可能可能是最新的資料庫。

在一簡單地說，您需要找出您必須還原。 然後它會成為一個問題，您就可以還原。

您可以還原是什麼？

任何還原作業的目的是還原最少的可能備份，所以還原作業很快速，盡可能並同時又能讓您以符合您 RPO 您 RTO 內完成。

要提問這裡主要的問題是 「 何種備份有？ 」如果您有唯一的備份完整資料庫備份從一週前，且整個資料庫已經遺失，還有只有一個還原選項--一週的時間前遺失以來的所有工作然後中的點。 簡單地說您的備份策略應該永遠確保您可以還原您需要什麼在嚴重損壞事件時，如我前一篇文章所述。

因此方式可以判斷何種備份，您有可用？ 第一次，您可以查詢各種備份 msdb 資料庫中的歷程記錄資料表。 這些資料表包含自前次備份歷程資料表清除已採取 SQL Server 執行個體中的所有備份的記錄。

就其本身的備份是而言，最好命名備份檔案，以包括資料庫、 輸入的備份，日期和時間，讓備份可以識別一目瞭。 如果您還沒完成了這項作業，您可以找出何種備份的檔案包含使用 RESTORE HEADERONLY] 指令。 這會顯示備份的檔案標題基本上是描述備份本身中繼資料的內容。 您可以閱讀更多在線上叢書 》 主題 ＜檢視有關備份的資訊".

使用任何一種方法，您試圖找出要用來還原損毀或已刪除資料的還原順序。 還原順序是一組必須還原的備份和適當的順序，以將其還原。 還原順序可能很簡單，例如只在一個完整備份 (資料庫、 檔案群組或檔案)，或複雜的一段完整差異式與交易記錄檔備份。

比方說假設的案例，其中備份策略牽涉到完整的資料庫、 差異式資料庫及交易記錄檔備份。 如果系統損毀發生，而且資料檔案已損壞什麼是還原順序？ 圖 1 說明這個範例。

在這種情況下最短和最快速的還原順序是最新的完整資料庫備份 (F)、 最近的差異式資料庫備份 (D2) 與然後所有後續交易記錄檔備份，且包含的記錄機尾備份 (L7 和 L8)。

其中一個最棘手的問題規劃還原順序時正在尋找最早必要的交易記錄檔備份來還原 (有時稱為尋找最小值-LSN 或 「 最小值-日誌序號 」)。 在 的 圖 1 中的範例，只交易記錄檔備份 L7 和 L8 是必要的的因為差異式資料庫備份 D2 帶資料庫給一個較新的點的時間比所有先前的交易記錄檔備份。

圖 1：範例還原順序

SQL Server 將允許先前，不需要交易記錄檔備份來還原但它們將不會使用以及基本上只是浪費的嚴重損壞修復 time.Continuing 如果差異式資料庫備份 D2 會發生什麼事我範例已損毀或遺失？ 圖 2 顯示這個案例。

圖 2：還原傷害差異式資料庫備份的順序

在這種情況最短和最快速的還原順序是最新的完整資料庫備份 (F) 下, 一個最近一次差異式資料庫備份 (D1) 與然後所有後續交易記錄檔備份 (L4、 L5、 L6、 L7 及 L8)。 這可能只只要是備份 D1、 L4、 L5 及 L6 是仍可使用。 很重要不要太快刪除備份 ； 否則您可能會遇到的問題在嚴重損壞時。

比方說如果完整資料庫備份 F 已損毀，除非仍然可以使用先前的完整資料庫備份，否則，資料庫將無法復原。 如果差異式資料庫備份 D1 刪除 D2 完成因為，然後 的 圖 2 中案例將不可能，並還原順序會涉及所有交易記錄檔備份，完整資料庫備份--可能很長的還原順序之後。

這樣會引發的問題 」 時應該刪除先前的備份？ 」答案是肯定 」 它取決!"如果您沒有要保留周圍的備份，特定長度的時間的法律義務，然後您，並取決於您有的備份策略和有需要多少磁碟空間。 無論如何，不要立即刪除先前的備份只要取得一個新 ； 它是保持至少一個或兩個完整週期的備份之前的較舊備份的最佳方法。 在理想的情況下，您應該測試您的備份移除舊的之前。

交易記錄檔備份一般而言您必須有它們全部因為採取最後一次完整資料庫備份就最終秋天後還原順序。 如果單一的交易記錄檔備份從交易記錄檔備份鏈結 」) 遺失或損毀，還原作業無法繼續過去的間距。 前面提先前的發行項中驗證備份的完整性是索引鍵一部分能夠順利還原。

您可以找到需找出您就可以還原完整的線上叢書 》 主題中的詳細資訊 」使用 SQL Server 資料庫的還原順序".

範例還原案例

最常見的還原實例包含完整資料庫備份，以及再一或多個交易記錄檔備份將資料庫向前在時間。 您可以這樣透過 SQL 「 伺服器Management Studio (SSMS) 或透過 Transact-SQL，雖然有一些您需要知道的如果您要直接使用 RESTORE 命令。

還原備份時有三個選項可用於還原作業的完成方式以及其所有關聯到修復的 「 復原 」 階段。 還原每個連續的備份中還原順序永遠執行修復的 「 取消復原 」 階段的但是在還原交易記錄檔備份鏈結中的非常最後一次備份之前，不能執行復原階段。 這是因為沒有其他的交易記錄檔備份可以套用一旦完成復原，因此所有會還原在還原順序必須指定不以執行修復的 「 復原 」 階段。

不幸的是，預設值是執行修復--相當於使用 RESTORE 陳述式上的 [WITH 修復] 選項的 「 復原 」 階段。 還原多個備份時, 必須非常小心每一個指定 WITH NORECOVERY。 在實際上最安全的方式是還原順序使用所有的還原] 的 [WITH NORECOVERY] 選項，並再以手動方式完成修復之後。 以下是一些範例 Transact-SQL 程式碼來還原完整資料庫備份和兩個的交易記錄檔備份，並以手動方式完成，使資料庫上線的修復：

還原資料庫 DBMaint2008 FROM
磁碟 = 'C:\SQLskills\DBMaint2008_Full_051709_0000.bak'
取代]、 [加總檢查碼]、 [NORECOVERY ；
移

RESTORE LOG DBMaint2008 FROM
磁碟 = 'C:\SQLskills\DBMaint2008_Log_051709_0100.bak'
與 NORECOVERY ；
移

RESTORE LOG DBMaint2008 FROM
磁碟 = 'C:\SQLskills\DBMaint2008_Log_051709_0200.bak'
與 NORECOVERY ；
移

RESTORE 資料庫 DBMaint2008 WITH 復原 ；
移

請注意我也用來確保它們還原驗證任何頁總合檢查碼出現在資料庫中所還原的完整資料庫備份還原的 [CHECKSUM 選項。

如果第一個 RESTORE 陳述式上未指定 WITH NORECOVERY，會傳回下列錯誤：

msg 3117，層級 16，狀態 1，行 1
無法還原記錄備份或差異備份，因為沒有檔案已經準備好 rollforward。
msg 3013，層級 16，狀態 1，行 1
RESTORE LOG 正在異常終止。

-您必須非常小心地使用正確的選項，否則風險不必重新啟動長的還原順序-還有沒有方法可以復原修復，一旦完成它。

沒有，但是，一個有趣的選項，這種做法--WITH 待命選項。 這是我在前文有提到的三個選項的最後一個。 它的運作方式是正在執行復原階段的修復，但是它會保留它 (在 「 您指定名稱和路徑的"復原"檔案) 中一般的附註，然後允許唯讀存取資料庫。 資料庫是交易一致，但您必須能夠繼續進行還原順序。 如果決定繼續執行 [復原會反轉 (使用復原檔案的內容)，且下一個交易記錄檔還原然後。 這是有用的兩個案例：允許唯讀存取至記錄傳送次要資料庫以及在還原順序期間查看資料庫的內容。

如果您正在復原從嚴重損壞牽涉到意外刪除的資料表，比方說您可能想要時間點還原。 有數種方法可這麼做，但最常見是您要還原資料庫，但是確保復原不會超過特定時間繼續進行。 在這種情況下您可以使用 WITH STOPAT 選項來防止交易記錄檔還原從移的過去的時間您知道該資料表已被刪除。 對於執行個體使用 Transact-SQL 範例之上，如果我想要防止資料庫還原過去的上午 1: 45，我可以使用下列語法上第二個 RESTORE LOG 陳述式：

RESTORE LOG DBMaint2008 FROM
磁碟 = 'C:\SQLskills\DBMaint2008_Log_051709_0200.bak'
與 NORECOVERY STOPAT = '2009-05-17 01:45:00.000' ；
移

我甚至可以結合 STOPAT] 及 [待命]，請參閱在時間內是否是正確的點及然後，如果不是，稍後等等還原相同的交易記錄檔備份，幾秒鐘的時間，時間。 這種作業變得非常繁瑣，但它可能是唯一的解決方案，如果您不知道什麼時間的作業所花費的地方。

可以在線上叢書 》 的主題中找到完整討論這些和其他選項，以便 RESTORE 陳述式來"RESTORE 引數 (Transact-SQL)".

在 SQL Server 2005 企業版中引入 coolest 的新功能之一是部分資料庫可用性。 這項功能可讓多重檔案群組資料庫在線上，並可當做長度為至少主要檔案群組處於連線狀態。 很明顯地，無法存取任何離線檔案群組中的資料，但是這項功能可以讓非常大型的資料庫分割成更容易且更快速的復原能力的不同檔案群組。 已新增另一個企業專用功能是能夠執行逐漸還原 (比方說單一檔案群組從多重檔案群組資料庫) 線上，而其餘的資料庫用於處理。

結合這兩個功能啟用一些相當複雜且有效率的還原] 案例，只要 architected 資料庫如此一來，而且正確備份存在。

您會發現一個絕佳、 深入 SQL 伺服器技術文章的一些廣泛的範例可在 tinyurl.com/mbpa65 標題為 「 Microsoft SQL Server 2005 部分資料庫可用性 」。 另外還有 75 分鐘錄製的 Kimberly L 鍵。 Tripp 傳遞科技 Ed EMEA 工作階段，標題為 "SQL Server 2005 VLDB 可用性和復原策略「，是很值得監看。

還原至不同的位置時的考量

在同一個執行 SQL Server 個體上若要用它通常連接，並具有相同名稱還原資料庫時，就會是最簡單的還原實例。 當您移動進一步離開從該案例，還原作業 aftermath 會變成變得更加複雜。

如果還原該資料庫時在相同的執行個體上，但是使用不同的名稱，您可能需要對諸如 DTS/SSIS 封裝、 資料庫維護計劃、 應用程式的字串和依賴資料庫名稱的任何項目進行變更。

如果在相同伺服器上的不同執行個體上還原資料庫，事情取得許多更為複雜：

  • SQL Server 登入將會不同，或可能不存在。
  • SQL 代理程式作業和 DTS/SSIS 封裝將會不同，或可能不存在。
  • master 資料庫是不同，因此任何使用者定義的預存程序可能會遺失。
  • SQL Server 執行個體名稱會不同，所以可能會有用戶端連線問題。
  • 如果在不同的伺服器上執行個體上還原資料庫，列出的所有項目會套用，但那里可能會加入安全性問題作為 Windows 帳戶可能不同，而它們可能在不同的 Windows 網域。
  • 一個其他的考量是 SQL Server 還原資料庫的版本。 有一些功能，如果在資料庫中使用使資料庫企業僅 」--它不能還原標準版上 (或較低) 的 SQL Server 執行個體。
  • 在 SQL Server 2000 或更早版本，但這並不是問題。 在 SQL Server 2005 中如果使用資料表或索引分割資料庫是企業僅 」。在 SQL Server 2008 功能清單是：
  • 異動資料擷取
  • 透明資料加密
  • 資料壓縮
  • 分割

這些都需要系統管理員 (sysadmin) 權限，才能啟用除了因此潛在破壞嚴重損壞復原計劃涉及還原為標準版執行個體到一個資料表擁有者可以啟用其中的資料壓縮。 您可以告訴任何這些功能是否正在使用 DMV sys.dm_db_persisted_sku_features 資料庫中使用，且據以調整您的損毀修復計劃。

挖掘探究

就像對備份數列中第一個發行項，一樣有很多的 Facet 我沒有空間，以涵蓋的還原作業。 既然您已經瞭解基本技巧，但是，您可以深入一些線上叢書] 和 [部落格] 連結，如更深入的資訊。 開始線上叢書 》 中最佳的地方是主題"還原及修復概觀 (SQL Server)". 您也可以在找到大量資訊我的部落格啟動 [備份/還原類別目錄。

我想您獲得從這份文件的主要 takeaway 是順利復原資料庫，使用備份，您需要練習以確定您知道該怎麼做。 您不想被 high-pressure 嚴重損壞修復狀況期間學習 RESTORE 命令的語法。 您也可能會發現您的備份策略不允許您復原內商務需求。 也許備份花太長的時間來還原、 或許記錄檔備份會不慎覆寫彼此，或也許您忘了備份伺服器憑證用來啟用 SQL Server 2008 中的透明資料庫加密。

目前為止，最好準備供嚴重損壞是有列出步驟瀏覽，並讓一組指令碼將會協助識別何種備份存在和要將它們還原順序的還原計畫。 我永遠要說這應該由最資深 DBA 撰寫小組的並由最 junior DBA--以確保每個人都可以安全地遵循步驟進行測試。 不過，如果您是非自願 DBA，我們則要需要整合計劃自己，並請確定您可以遵循。

在下一個發行項中我將說明如何從資料庫損毀復原，如果您沒有任何備份，以及您可能會選擇執行修復作業，即使您沒有備份。
在平均數的時間內，而是永遠，如果有任何意見或問題捨棄我一條線-Paul@SQLskills.com.

感謝至 Kimberly L。 對於提供技術檢閱這份文件的 Tripp。

Paul S. Randal 是導演的管理導演 SQLskills.com、 SQL Server MVP 和 Microsoft 地區。 他曾在 SQL Server 儲存引擎小組在 Microsoft 從 1999年至 2007年。 Randal DBCC CHECKDB/修復撰寫的 SQL Server 2005，並在 SQL Server 2008 開發期間已負責核心儲存引擎。 Randal 是在嚴重損壞修復、 高可用性和資料庫維護的專家，而且一般主持人在世界各地演說。 在他部落格SQLskills.com/blogs/paul 而是位在為 @ PaulRandal Twitter。