SQLServer災難恢複

<b></b>

<b>SQLServer災難恢複</b>

故障情況：

現在時間是星期二下午16：00，使用者打電話請求技術支援，說素材采集資料庫連接配接不上，小管在網管控制台啟動應用程式，發現确實如此。如圖1。

呵呵，這樣的以前經常出現阿，很簡單，告訴使用者等5分鐘。然後小管進行了簡單的測試：Ping資料庫伺服器沒有問題，證明網絡連接配接沒有問題。ODBC連接配接也可以連接配接到資料庫伺服器的MASTER資料庫，證明用戶端沒有問題。問題出在CMS應用資料庫上。

現在小管還沒有認識到問題的嚴重性，哼着歌來到資料庫伺服器上，打開企業管理器，察看CMS資料庫的狀态，竟然是“置疑”，開什麼玩笑，出現“置疑”狀态有幾種可能：

1、資料庫檔案或者相關的日志檔案丢失；

2、資料庫所在的路徑發生變化；

3、磁盤可用空間不足；

4、SQLSERVER可能沒有足夠的時間來恢複資料庫；

5、資料庫中在資料寫入的過程中資料頁因為停電或者記憶體洩漏等操作被損壞。如圖2

首先，小管重新啟動了資料庫伺服器，察看SQLSERVER服務管理器中的SQLSERVER的運作狀況，正常。說明：SQLSERVER服務是正常的。

打開企業管理器，故障情況依舊。

現在時間是16：20。首先向部門上司報告了故障發生的情況，請示以後緊急啟用了一台臨時伺服器。嘿嘿，做方案的時候就考慮到了，萬一發生資料庫災難或者伺服器損壞的狀況，應急使用的一台低端伺服器，2年沒有使用終于派上用場了。用戶端全部使用的是Windows 2000，使用信差服務向所有線上的使用者發了一個通知：素材資料庫因為故障，資料庫的查詢功能暫時不可用，其它正常。

現在時間是16：30。根據故障的狀況和“置疑”發生的可能性，小管逐一進行了排查。檔案路徑沒有改變，檔案也沒有丢失，磁盤空間還有30G，沒有進行資料庫恢複操作，那就隻有最後一種可能了。問一下同僚：資料中心停電沒有，反正自己的辦公室沒有停電，回答說沒有啊。哦，這就很奇怪了！小管的額頭開始有汗珠了，事情有點麻煩，現在可是資料處理的高峰時段，而且素材資料庫有1000萬條的資料啊，每天的資料入庫量高達上萬條。仔細問了一下，有沒有異常發生，這時候有個同僚說剛才在調試KVM的時候不小心把電源線給拔下來，由于沒有認識到是連接配接的伺服器，連續接插了幾次，我暈！！這可是資料存儲的SERVER啊！！如圖3

還好，資料庫檔案、日志檔案還在，可以使用資料庫附加到伺服器。打開查詢分析器輸入以下腳本指令：

如果資料庫檔案沒有問題，這樣的話就應該OK了。在資料庫規劃的時候，把資料庫檔案和日志檔案分開存儲，防止磁盤發生錯誤造成2個檔案同時損壞。如圖4

因為檔案很大，執行開始以後，小管就離開機房回到座位上，耐心等待資料庫附加完成。

現在時間是16：40。回到機房，上帝啊，最不願意看到的事情發生了，資料庫檔案損壞，不是有效的資料庫檔案頭，可以确認這是災難性的！小管的汗已經流了下來，還好，想到還有完整的資料備份機制，不怎麼要緊，至少可以把損失降低到最低程度吧，心中還有一絲慶幸。

現在時間是16：50。向上司報告了處理經過和可能的後果：今天的素材入可能丢失，可以盡最大努力恢複一下是否能夠成功恢複今天的資料。怎麼大老闆也來了，他沒有事情從來不到我們這兒！唉，看來事情比預料的要嚴重得多。

現在時間是17：00。到下班的時間了，今天是别想回家了，弄不好要通宵呢？小管拿出以前制定的備份政策看了一下，CMS資料庫的備份是這樣的：星期日、三淩晨2：00執行資料庫完整備份同時備份事務日志，星期一、二、四、五、六淩晨2：00執行資料庫差異備份，同時備份事務日志。MASTER的資料庫備份是在每天的1：00執行完全備份，每個星期的每一天都單獨保留相應得備份。

如果要将CMS資料庫還原到星期二下午16：00時的狀态，根據備份方案要這樣：還原在星期日淩晨2：00建立的資料庫完整備份，還原在星期二淩晨 2:00 建立的差異資料庫備份。但是最後一次差異備份後資料庫修改的資料怎麼辦？每天的資料量可是接近萬條啊，不會需要手工重新輸入吧。

現在也不知道MASTER資料庫是否完整。根據狀況分析，有可能MSATER資料庫也可能有故障。先恢複今天淩晨1：00備份的MASTER資料庫。

打開企業管理器，選擇資料庫右鍵所有任務選擇還原資料庫，如圖5

。

機械操作過程小管很熟悉的，選擇資料庫名為：master，從備份裝置上恢複，選擇master_back.bak資料庫備份，選擇資料庫完全還原備份集合，如圖6

點選确定即可。哦，怎麼出錯了？原來，小管忙中出錯：在正在運作的資料庫上要強行恢複正在運作的MASTER資料庫，這怎麼行呢？如圖7

首先要進入單使用者模式，然後才能恢複MASTER資料庫。進入管理工具的服務管理器，找到MSSQLSERVER服務，停止。如圖8

小管提示：要以單使用者方式啟動資料庫，必須在啟動參數中輸入-C–M，重新啟動資料庫就醫單使用者方式啟動了。如圖9

重新進入還原MASTER資料庫視窗，選擇備份檔案，确定即可。如圖10

哦，怎麼又彈出一個錯誤視窗，呵呵，這個錯誤不要緊，是告訴你，已經成功還原了MASTER資料庫，同時又自動關閉了MSSQLSERVER服務，如果要使用SQLSERVER要重新啟動該服務。如圖11

現在是17：20，已經成功恢複了MASTER資料庫。下一步，就是要恢複CMS資料庫了。上司在那邊催大家吃飯了，吃完飯以後再說。吃飯是小問題，關鍵是大家在一起讨論一下如何能夠恢複今天的資料，換換腦子，說不定有别的辦法。

17：30-19：00，吃飯，當然主要是讨論的過程，沒有什麼結果，認為可能性不大，大家以前都沒有類似的經曆和遇到同樣的錯誤。看來真的很危險了。

現在是19：00，回到資料機房，小管坐下來想了好半天，怎麼做才好呢？1、如果現在伺服器上直接恢複資料庫，在發生問題怎麼辦？2、如果恢複不成功又引發别的問題怎麼辦？最好的辦法就是在自己的機器上模拟一個環境，通過以後再到SERVER上操作，避免因為操作失誤或者其它的原因，增加排故的難度，這是最好的辦法。

現在是19：10。在自己的PC上，小管建立了一個資料庫，test，隻建立了一個表qq，輸入5條資料，我們可以看一下是不是隻有5條紀錄。如圖12

OK，然後完整備份這個test資料庫。展開控制台的層級結構，選中管理下的備份，右鍵“建立備份裝置”：如圖13

輸入備份裝置的名稱：如圖14

打開test資料庫，進入備份資料庫視窗，選取剛建立的備份裝置，選擇完全備份，因為是完整備份而且是第一次，是以選擇“追加到媒體”或者“重寫現有媒體”均可。OK備份完成！

這個完全備份的目的相當于星期日淩晨2：00的完全備份。如圖15

再給test資料庫插入5條資料，這樣資料庫的紀錄數量為10條了。再看一下表中是不是有10條紀錄了。如圖16

OK，确實資料已經插入了。現在給這個資料庫做一次差異備份，這個差異備份的目的相當于星期一淩晨2：00的差異備份。

打開test資料庫，進入備份資料庫視窗，選取剛建立的備份裝置，選擇差異備份，注意：選擇“追加到媒體”。OK備份完成！如圖17

同樣的操作在給資料庫插入5條紀錄，完成星期二淩晨的差異備份。

然後是最重要的，現在資料庫中有15條紀錄，我在加入10紀錄，這10條紀錄就是我做完差異備份以後沒有進行備份的資料，也就是我要恢複的關鍵資料。我們現在看一下，資料庫的記錄情況：框内的資料就是新增加的，也是要恢複的。如圖18

現在已經是20：30，到現在為止，已經全部仿真我們的備份狀況。按照正常的恢複辦法隻能恢複15條資料，那最後增加的資料也就是今天的上萬條資料就可能恢複了。到底該怎麼辦呢？

打開SQLSERVER聯機幫助檔案，希望從中得到幫助，但是都沒有符合我遇到的這個狀況，因為我們的日志備份是晚上進行的，到發生故障時為止，沒有經過一次備份。

現在已經是21：30分，找到SQL的QQ群，向兄弟們求助，得到的資訊基本上是不可能。大老闆的電話到現在已經打了3次了，詢問故障的解決狀況，沒有一絲進展。實在是沒有辦法了，隻好等明天再說。小管離開機關的時候已幾經是淩晨2：00了。

現在時間是星期三上午8：00，小管早早來到辦公室，打開MSN、QQ看看哥們又沒有來的早的，基本上都是9：00上班阿。

現在時間是8：50。有哥們來了，聽了我的描述，搖搖頭，沒有遇到過。這時候一個哥們上來，小管好像看到了一分希望。電話描述以後，告訴我這個情況是可以恢複的，不過要2個前提條件：打開資料庫，右鍵，屬性，選擇“選項”按鈕，看一下你的故障還原模型是什麼模式。如果不是完全模式的話，是不可能恢複的。這個設定是預設安裝的，如果你沒有手工更改的話。這個很簡單阿，小管看了一下是“完全”，沒有動過。如圖19

現在時間9：30。第二個條件，事務日志是完好的，如果這個檔案發生錯誤的話，那就沒有希望了。在查詢分析器中打開MASTER，執行“BACKUP LOG test to test_data_backup”，如果執行成功代表log日志正常。小管馬上進行了測試，ok沒有問題，看來問題可以解決。如圖20

這時候小管看了一下時間10：10分，同時又查詢了一下日志的資料：

執行 BACKUP LOG 語句以備份目前活動的事務日志，同時指定：要備份的事務日志所屬的資料庫名稱。事務日志備份将寫入的備份裝置。NO_TRUNCATE 子句，通過它備份事務日志而不截斷該事務日志的非活動部分。隻要事務日志檔案是可通路的并且沒有損壞，那麼即使資料庫不可通路，此子句也允許備份事務日志的活動部分。

知道了，我現在的狀況是資料庫損壞但是log檔案還是好的，而且先在要做的話，肯定要加上NO_TRUNCATE，測試一下。小管停止MSSQLSERVER服務，删掉test資料庫，重新重新整理企業管理器，看到的test資料庫的狀态也是“置疑”。如圖21

在查詢分析器中，進入到MASTER資料庫，敲入腳本指令“BACKUP LOG test to test_data_backup with NO_TRUNCATE”。如圖22

處理成功。也就是說在資料庫損壞或者遺失的情況下，日志檔案是可以手工恢複的。幸虧我的log檔案時單獨備份的，如果和資料庫檔案放在一起，說不定也受損了。

小管提示：為了您的安全請分開指定資料庫檔案，和日志檔案的存放位置。

現在時間10：30。進入到資料庫還原視窗，可以看到備份裝置集合中出現了剛才建立的2個log事務日志。如圖23

點選确定，資料庫開始還原。如圖24

開始還原備份以及事務日志，小管這時的心都要跳出來，謝天謝地，沒有提示出錯資訊。如圖25

看來時沒有問題的，小管打開資料庫，察看是否資料已經完全恢複。如圖26

現在時間11：00。資料真的已經恢複成功，看來我的素材資料庫恢複也是有希望的。

小管提示：首先察看故障還原模型一定要是“完全的”，其二，察看LOG日志檔案是否受損，其三恢複日志檔案，其四，恢複資料庫。

按照這個思路，小管來到伺服器上，先把資料庫檔案和日志檔案作了一次備份，然後按照過程進行操作。Ok，成功！現在已經是11：30了。小管停掉臨時伺服器，把臨時資料導入到CMS伺服器上，重建索引，至此資料恢複成功。

小管忠告：如果沒有确認故障的原因，不要再伺服器上作任何系統級别的操作。想辦法模拟環境，在類似的狀态下操作，保證資料的安全性。

本文轉自wangshujiang51CTO部落格，原文連結：http://blog.51cto.com/wangshujiang/42420，如需轉載請自行聯系原作者