SQL Server2000中，如果數(shù)據(jù)庫文件（非系統(tǒng)數(shù)據(jù)庫文件）遇到錯誤的時候，我們該怎么辦。以下是筆者以前的筆記。僅適用于非master,msdb的數(shù)據(jù)庫。

說明如下：

1 建一個測試數(shù)據(jù)庫test(數(shù)據(jù)庫類型為完全)
2 建一個表，插入點記錄

create table a(c1 varchar(2))
go
insert into a values(#39;aa#39;)
go
insert into a values(#39;bb#39;)
go

3 作完全備份，到文件test_1.bak
4 在作一點修改

insert into a values(#39;cc#39;)
go
create table b(c1 int)
go
insert into b values(1)
go
insert into b values(2)
go

5 shutdown 數(shù)據(jù)庫服務器
6 用ultraedit編輯數(shù)據(jù)庫文件test_data.mdf,隨便修改點字節(jié)內容,相當于數(shù)據(jù)庫遭到致命的損壞。
7 啟動數(shù)據(jù)庫，并且運行企業(yè)管理器，點開數(shù)據(jù)庫，看到test變成灰色，而且顯示置疑。
8 運行isql -SLocalhost -Usa -P
1> backup log test TO DISK=#39;D:Program FilesMicrosoft SQL ServerMSSQLBACKUP
est_2.bak#39; WITH NO_TRUNCATE
2>go

已處理 2 頁，這些頁屬于數(shù)據(jù)庫 #39;test#39; 的文件 #39;TEST_Log#39;（位于文件 1 上）。
BACKUP LOG 操作成功地處理了 2 頁，花費了 0.111 秒（0.087 MB/秒）。

9 進行恢復最老的完全備份

1> RESTORE DATABASE test FROM DISK=#39;D:Program FilesMicrosoft SQL ServerMSSQL
BACKUP est_1.bak#39; WITH NORECOVERY
2> go

已處理 96 頁，這些頁屬于數(shù)據(jù)庫 #39;test#39; 的文件 #39;TEST_Data#39;（位于文件 1 上）。
已處理 1 頁，這些頁屬于數(shù)據(jù)庫 #39;test#39; 的文件 #39;TEST_Log#39;（位于文件 1 上）。
RESTORE DATABASE 操作成功地處理了 97 頁，花費了 0.107 秒（7.368 MB/秒）。

10 恢復最近的日志

1> RESTORE LOG test FROM DISK=#39;D:Program FilesMicrosoft SQL ServerMSSQLBACKU
P est_2.bak#39; WITH RECOVERY
2> go

已處理 2 頁，這些頁屬于數(shù)據(jù)庫 #39;test#39; 的文件 #39;TEST_Log#39;（位于文件 1 上）。
RESTORE LOG 操作成功地處理了 2 頁，花費了 0.056 秒（0.173 MB/秒）。

數(shù)據(jù)已經(jīng)完全恢復了，可以使用了。

select * from a
go

總結，DBA應該有一個完善的數(shù)據(jù)庫備份計劃。本例中，如果沒有一個完全備份的話，數(shù)據(jù)庫的恢復就不可能

當sql server數(shù)據(jù)庫崩潰時如何恢復？

　　任何數(shù)據(jù)庫系統(tǒng)都無法避免崩潰的狀況，即使你使用了clustered，雙機熱備……仍然無法完全根除系統(tǒng)中的單點故障，何況對于大部分用戶來說，無法承受這樣昂貴的硬件投資。所以，在系統(tǒng)崩潰的時候，如何恢復原有的寶貴數(shù)據(jù)就成為一個極其重要的問題了。

　　在恢復的時候，最理想的情況就是你的數(shù)據(jù)文件和日志文件都完好無損了，這樣只需要sp_attach_db，把數(shù)據(jù)文件附加到新的數(shù)據(jù)庫上即可，或者在停機的時候把所有數(shù)據(jù)文件(一定要有master等)都copy到原有路徑下也行，不過一般不推薦這樣的做法，sp_attach_db比較好，雖然麻煩許多。

　　但是呢，一般數(shù)據(jù)庫崩潰的時候系統(tǒng)是未必能有時間把未完成的事務和臟頁等寫入磁盤的，這樣的情況sp_attach_db就會失敗。那么，寄期望于dba制定了一個良好的災難恢復計劃吧。按照你的恢復計劃，還原最新的完全備份，增量備份或者事務日志備份，然后如果你的活動事務日志還能讀得出來的話，恭喜你！你可以還原到崩潰前的狀態(tài)。

　　一般的單位都是沒有專職的dba的，如果沒有可用的備份，更可能是最近一次備份的時間過于久遠而導致不可接受的數(shù)據(jù)損失，而且你的活動事務日志也處于不可用的狀態(tài)，那就是最麻煩的情況了。

　　不幸的很的是，一般數(shù)據(jù)庫崩潰都是由于存儲子系統(tǒng)引起的，而這樣的情況是幾乎不可能有可用的日志用于恢復的。那么就只好試一下這些方案了。當然，是要求至少你的數(shù)據(jù)文件是存在的，要是數(shù)據(jù)文件、日志文件和備份都沒有了的話，別找我，你可以到樓頂上去唱“神啊，救救我吧”。

　　首先，你可以試一下sp_attach_single_file_db，試著恢復一下你的數(shù)據(jù)文件，雖然能恢復的可能性不大，不過假如這個數(shù)據(jù)庫剛好執(zhí)行了一個checkpoint的話，還是有可能成功的。

　　如果你沒有好到有摸彩票的手氣，最重要的數(shù)據(jù)庫沒有像你期盼的那樣attach上去，不要氣餒，還是有別的方案的。

　　我們可以試著重新建立一個log，先把數(shù)據(jù)庫設置為emergency mode，sysdatabases的status為32768 就表示數(shù)據(jù)庫處于此狀態(tài)。

　　不過系統(tǒng)表是不能隨便改的，設置一下先

　　use master
　　go
　　sp_configure #39;allow updates#39;, 1
　　reconfigure with override
　　go

　　然后
　　update sysdatabases set status = 32768 where name = #39;#39;
　　現(xiàn)在，祈求滿天神佛的保佑吧，重新建立一個log文件。成功的機會還是相當大的，系統(tǒng)一般都會認可你新建立的日志。如果沒有報告什么錯誤，現(xiàn)在就可以松一口氣了。

　　雖然數(shù)據(jù)是恢復了，可是別以為事情就算完成了，正在進行的事務肯定是丟失了，原來的數(shù)據(jù)也可能受到一些損壞。

　　先把sql server 重新啟動一下，然后檢查你的數(shù)據(jù)庫吧。
　　先設置成單用戶模式，然后做dbcc

　　sp_dboption #39;#39;, #39;single user#39;, #39;true#39;
　　dbcc checkdb(#39;#39;)

　　如果沒有什么大問題就可以把數(shù)據(jù)庫狀態(tài)改回去了，記得別忘了把系統(tǒng)表的修改選項關掉。

　　update sysdatabases set status = 28 where name = #39;#39; --當然你的數(shù)據(jù)庫狀態(tài)可能不是這個，自己改為合適的值吧。也可以用sp_resetstatus
　　go
　　sp_configure #39;allow updates#39;, 0
　　reconfigure with override
　　go

　　checkdb的時候可能報告有一些錯誤，這些錯誤的數(shù)據(jù)你可能就只好丟棄了。
　　checkdb有幾種修復選項，自己看著用吧，不過最后你可能還是得用repair_allow_data_loss，完成所有修復。
　　chekcdb并不能完成所有的修復，我們需要更進一步的修復，用dbcc checktable對每一個表做檢查吧。

　　表的列表可以用sysobjects里面得到，把objectproperty是istable的全部找出來檢查一下吧，這樣能夠基本上解決問題了，如果還報告錯誤，試著把數(shù)據(jù)select into到另一張表檢查一下。
　　這些都做完了之后，把所有索引、視圖、存儲過程、觸發(fā)器等重新建立一下。dbcc dbreindex也許可以幫你一些忙。

數(shù)據(jù)庫日志文件丟失時的恢復步驟，描述我誤刪除了數(shù)據(jù)庫的事務日志文件(.ldf)之后，如何經(jīng)過各種嘗試恢復數(shù)據(jù)庫的。

但是不少網(wǎng)友在處理“數(shù)據(jù)庫置疑”的實踐過程中，又產(chǎn)生了許多新的疑問。
我還是總結一下出現(xiàn)的幾種情況，以供參考。

2.Zach的靈驗腳本

Zach說他每次遇到這種數(shù)據(jù)庫置疑情況，就運行下面這個腳本，屢試不爽：
======================================================
--before running any script, run the following to set the
master database to allow updates
USE master
GO
sp_configure #39;allow updates#39;, 1
GO
RECONFIGURE WITH OVERRIDE
GO

--Run the following script
UPDATE master..sysdatabases SET status = status ^ 256
WHERE name = #39;Database_Name#39;

--Run the following script
exec SP_resetstatus Database_Name

--stop and start the MSDTC at this stage

--After the procedure is created, immediately disable
updates to the system tables:
exec sp_configure #39;allow updates#39;, 0
GO
RECONFIGURE WITH OVERRIDE
GO
=====================================

從上面可以看出，處理置疑的基本步驟還是我那篇文章中說的(注意我使用的字體顏色)：
執(zhí)行 sp_configure 以允許對系統(tǒng)表進行更新，然后用 RECONFIGURE WITH OVERRIDE 語句強制實施該配置；
數(shù)據(jù)庫重置緊急模式；
執(zhí)行sp_resetstatus關閉數(shù)據(jù)庫的置疑標志，但是原封不動地保持數(shù)據(jù)庫的其它選項（只有系統(tǒng)管理員才能執(zhí)行）。執(zhí)行該過程后，立即重啟 SQL Server服務；
執(zhí)行 sp_configure 以禁止對系統(tǒng)表進行更新，然后用 RECONFIGURE WITH OVERRIDE 語句強制實施該配置。

status ^ 256的意思就是：
Constant  Value  Description
SQLDMODBStat_Suspect  256  Database integrity is suspect for the referenced database.

不同的是，有時候丟失了數(shù)據(jù)庫日志文件，額外需要以下步驟：
 把應用數(shù)據(jù)庫設置為Single User模式；
 做DBCC CHECKDB；
才可以。

但是幾位網(wǎng)友的實踐結果就是這個DBCC CHECKDB執(zhí)行失敗。一位網(wǎng)友yang說：“但是 DBCC CHECKDB就是執(zhí)行不了，總是說“該數(shù)據(jù)庫處于回避恢復模式”。我已經(jīng)試了很多次了，就是改變不了這個狀態(tài)。”
還有一位Rui執(zhí)行DBCC CHECKDB時報錯：“Server: Msg 943, Level 14, State 1, Line 1 Database #39;his_yb#39; cannot be opened because its version (539) is later than the current server version (515).”

對于Yang，可能他沒有一步一步做，。我的切身體會是，把應用數(shù)據(jù)庫設置為Single User模式后就可以做DBCC CHECKDB。之后呢，也許SQL Server重啟后自動檢查數(shù)據(jù)庫是否正常。但是數(shù)據(jù)應該是可以讀出來的，至少可以被DTS Wizard讀出來的。這時候的數(shù)據(jù)庫還存在問題，比如我的組件使用數(shù)據(jù)庫時，報告說：“發(fā)生錯誤：-2147467259,未能在數(shù)據(jù)庫 #39;XXX#39; 中運行 BEGIN TRANSACTION，因為該數(shù)據(jù)庫處于回避恢復模式?！?/P>

對于Rui，他碰到的那個錯誤
Server: Msg 943, Level 14, State 1, Line 2
Database #39;XXXX#39; cannot be opened because its version (536) is later than
the current server version (515).
這表明Rui正試圖：
從一個SQL Server 2000(version 539,536之類的)的數(shù)據(jù)庫備份恢復到一個SQL Server 7.0中
或者
把一個SQL Server 2000(version 539,536之類的)的數(shù)據(jù)庫attach到一個SQL Server 7.0中，
這是不允許的。如果你必須使用這個SQL Server 2000的數(shù)據(jù)備份，那么請您首先把這個備份倒入SQL Server 2000，最后用DTS把數(shù)據(jù)庫從SQL Server 2000上transfer到SQL Server 7.0上。