墨西哥工廠機房失火，異常斷電后開啟報表服務器,發現一個數據庫OTS狀態變為SUSPECT，不能查詢，不能查看屬性，不能備份。

Windows 2003sp2+SQL Server 2005sp2

1.嘗試ONLINE數據庫,失敗。

Database 'OTS' cannot be opened - it has been marked SUSPECT by recover Explanation

查看對應的數據文件和日志文件,存在.

2.運行checkdb ‘OTS’,提示Database 'OTS' cannot be opened.

3.關閉SQL SERVER,拷出MDF,LDF文件.

*遇到數據庫有問題時，最好不要用SQL SERVER的備份,因為全備份會截斷事務日志,可能造成數據庫無法恢復.也不要做detach和delete動作,這樣可能MDF檔再也附加不上去,數據庫徹底沒用了.事實上,此時也無法進行這些動作。

4.檢查磁盤空間是否足夠,MEM是否正常.

如果磁盤不再有可用空間,無法完成restore過程,數據庫也會被置為suspect狀態.

5.開啟SQL SERVER，用sa賬號登錄。

USEmaster

GO

sp_configure'allowupdates',1

GO

RECONFIGUREWITHOVERRIDE

GO

執行sp_resetstatus'OTS',關閉ots數據庫的置疑標志。完成后信息如下：

Database'OTS'statusreset!

WARNING:YoumustrebootSQLServerpriortoaccessingthisdatabase!

sp_configure'allowupdates',0

GO

RECONFIGUREWITHOVERRIDE

GO

6.重啟SQL SERVER,故障依舊。

7.嘗試將OTS數據庫改名后新建一同名數據庫,失敗，不能rename.

8.刪除掉OTS數據庫,嘗試用備份出來的MDF和LDF檔新建一個同名數據庫。

*不到萬不得已,千萬不要做刪除的動作。事實證明,OTS數據庫刪除后,數據文件和日志文件再也不能附加上去,故障不能重現。

9.將MDF和LDF文件拷到其他磁盤,再附加,報同樣錯誤.

10.使用sp_attach_single_db只附加MDF檔,仍然報錯.

SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0x5b206e03; actual: 0x2acd7ef5). It occurred during a read of page (1:79842) in database ID 7 at offset 0x00000026fc4000 in file 'D:\Data\OTS.mdf'.Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

11.關閉數據庫,對磁盤進行掃描.同時修復壞磁盤錯誤.這個過程持續了相當長時間.完成后,再次開啟SQL SERVER,故障依舊.

12.用CREATE DATABASE DBName ON ( FILENAME = N'DBFile' ) FOR ATTACH_REBUILD_LOG附加數據庫時出現提示：The log cannot be rebuilt because the database was not cleanly shut down.

13.此時已經沒有OTS庫可以拿來做恢復了,只好在網上尋找恢復工具.找到一個Recovery for SQL Server,可以從MDF和LDF中將大部分結構和數據恢復出來,但是有部分數據對象有問題，特別是存儲過程有一些亂碼.

14.新建同名的數據庫OTS(數據庫文件名也跟以前一樣)，停止數據庫服務，用COPY出來的.mdf文件覆蓋新數據庫的同名文件，啟動數據庫服務。

運行alter database OTS set emergency，將數據庫設置為emergency mode

運行下面的命令恢復數據庫：

use master

exec sp_dboption 'OTS', N'single', N'true' --將目標數據庫置為單用戶狀態

dbcc checkdb('OTS')

數據庫CHECK發現大量GAM，SGAM分配錯誤，和類似以下信息：

Msg 8935, Level 16, State 1, Line 1

Table error: Object ID 862626116, index ID 1, partition ID 72057594055360512, alloc unit ID 72057594063814656 (type In-row data). The previous link (1:66955) on page (1:1183) does not match the previous page (1:200244) that the parent (1:69276), slot 23 expects for this page.

Msg 8935, Level 16, State 1, Line 1

Table error: Object ID 862626116, index ID 1, partition ID 72057594055360512, alloc unit ID 72057594063814656 (type In-row data). The previous link (1:41230) on page (1:1757) does not match the previous page (1:91286) that the parent (1:57623), slot 6

通過系統表查看Object ID 862626116的TABLE，發現PK字段有重復值。

因為此表數據是從其他DB抄過來的，所以數據丟失也沒有關系，所以執行下面的語句。

dbcc checkdb('OTS',REPAIR_ALLOW_DATA_LOSS)

提示上面提到的TABLE PK字段有重復值，而GAM，SGAM分配錯誤已經被repair

dbcc checkdb('OTS',REPAIR_REBUILD)

仍然提示上面提到的TABLE PK字段有重復值。我們暫時不管它，將目標數據庫置為多用戶狀態

exec sp_dboption 'OTS', N'single', N'false'

此時數據庫已經可用，再來看那個有問題的TABLE，constraint已經沒有了，只剩下PK和index,我們將PK取消掉，查找出有重復值的行，刪除掉，再建上PK。

再次運行checkdb 'OTS',已經沒有錯誤。

最后做一次數據庫的完整備份。

總結:

1.出現問題時不要驚慌，驚慌的后果往往是不理性的思考甚至不思考就做出一些不可逆的動作。

2.沒有把握時,不要輕易做分離數據庫、刪除數據庫、重啟數據庫服務器動作。

3.在數據庫可以打開的時候，使用CheckDB，等待它運行完成并報告所有錯誤，再根據這些錯誤來制定修復策略，雖然這個過程會比較長。

4.CheckDB并不能解決一切問題，所有數據只能靠完整的備份來恢復。所以，備份重于一切。如果實在沒有辦法，也可以借助一些工具，通過讀取MDF，LDF檔，生成腳本的方法來恢復結構和數據。

5.不管修復動作能不能成功，都要注意查找產生問題的原因，防止再次出現類似問題。

總結

以上是生活随笔為你收集整理的Linux+写数据异常断电,同事处理异常断电数据库状态变为SUSPECT过程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。