[SQL][問題處理]當資料庫發生異常時，才發現備份檔是壞的…
才想說下午天氣要開始變壞了，要想早點離開的時候，電話就這麼剛好地響起來了，而似乎下班時候才響的電話，都不是甚麼好處理的狀況。
一個同事傳來一個緊急的問題，原來是客戶發現資料庫有異常，因此想把資料庫的備份檔還原，就把有異常的資料庫刪除之後，要還原備份檔的時候，就出現以下的錯誤訊息了…
而客戶端又不能連線處理，又遠在海峽的另外一邊，因此想說把客戶的備份檔案傳回來測試看看囉。好在資料庫並不大，很快地透過一些轉接的方式取得到檔案了，因此就趕快把他放到測試環境中測試一下，跟客戶端發生的問題是一樣的。此時透過指令的方式來還原，並且在後面加上「WITH CONTINUE_AFTER_ERROR」參數，強迫還原資料庫，因此當還原完畢的時候，就會發現在最後面會出現有「資料庫可能存在不一致性」的訊息了。
既然看到這樣的訊息，當然我們可以先用 「DBCC CHECKDB」的指令，先檢查一下這些有異常的地方是發生在那些地方，並且做個記錄下來。所幸檢查下來發現有異常的幾個地方，都可以利用更早之前的備份來做個修正，或者是人工修改。因此再確定無誤之後，就將剛剛還原回來的資料庫，先設定到 「SINGLE_USER」 的模式下，利用 「DBCC CHECKDB 配合 repair_allow_data_loss 參數」來做修正，修正完畢之後，再將資料庫設定為 「MULTI_USER」的狀態
此時算是修正完畢，但檢查一下資料庫，看起來有些參數並沒有設定，因此調整一些資料庫參數，將原本的復原模式和頁面檢查的部分都做了調整。
但修改完畢之後，發現資料庫的 LOG 檔案居然有 3GB，而且也不能縮減。就如同之前所整理的另外一篇文章 [SQL][Troubleshooting]一值長大沒有辦法縮小的記錄檔 所遇到的問題類似，因此查看 sys.databases 後發現也是因為資料庫曾經被設定過要做 REPLICATION，只是因為之前寫的那篇的時候，是發生在 SQL Server 2008 上面，而這次遇到的是在 SQL Server 2005 上，這兩者在處理上的一個小差異，就是在配合使用 「EXEC sp_removedbreplication」的時候，在 2005 的時候不能指定要處理的資料庫名稱，必須切換到該資料庫下面執行。執行完畢之後，就可以輕鬆的壓縮 Log 檔了，也將資料庫回復到正常狀態了。
至於後續，只能先協助客戶做一些調整了，像是前面步驟我們更改資料庫參數 PAGE_VERIFY，因此當資料頁有異常的時候就會及早知道，不會再等到錯誤一堆都不能用的時候才發覺有異常。另外調整一下維護計畫，在資料庫備份之前，建議客戶先去做 DBCC CHECKDB 做一次檢查，並且在備份完成之後，透過 RESTORE VERIFYONLY 的方式，立即檢查一次備份檔案是否是正常的。否則每次都要等到有問題的時候才發現備份是有問題的，不會每次都那麼剛好可以搶救回來的。只能說將這些建議客戶去做了，至於客戶願不願意這樣去進行，就看他自己囉。