SQL Server2000中，如果數據庫文件（非系統數據庫文件）遇到錯誤的時候，我們該怎麼辦。以下是筆者以前的筆記。僅適用於非master,msdb的數據庫。
說明如下：
1 建一個測試數據庫test(數據庫類型為完全)
2 建一個表，插入點記錄
create table a(c1 varchar(2))
go
insert into a values('aa')
go
insert into a values('bb')
go
3 作完全備份，到文件test_1.bak
4 在作一點修改
insert into a values('cc')
go
create table b(c1 int)
go
insert into b values(1)
go
insert into b values(2)
go
5 shutdown 數據庫服務器
6 用ultraedit編輯數據庫文件test_data.mdf,隨便修改點字節內容,相當於數據庫遭到致命的損壞。
7 啟動數據庫，並且運行企業管理器，點開數據庫，看到test變成灰色，而且顯示置疑。
8 運行isql -SLocalhost -Usa -P
1> backup log test TO DISK='D:Program FilesMicrosoft SQL ServerMSSQLBACKUP
est_2.bak' WITH NO_TRUNCATE
2>go
已處理 2 頁，這些頁屬於數據庫 'test' 的文件 'TEST_Log'（位於文件 1 上）。
BACKUP LOG 操作成功地處理了 2 頁，花費了 0.111 秒（0.087 MB/秒）。
9 進行恢復最老的完全備份
1> RESTORE DATABASE test FROM DISK='D:Program FilesMicrosoft SQL ServerMSSQL
BACKUP est_1.bak' WITH NORECOVERY
2> go
已處理 96 頁，這些頁屬於數據庫 'test' 的文件 'TEST_Data'（位於文件 1 上）。
已處理 1 頁，這些頁屬於數據庫 'test' 的文件 'TEST_Log'（位於文件 1 上）。
RESTORE DATABASE 操作成功地處理了 97 頁，花費了 0.107 秒（7.368 MB/秒）。
10 恢復最近的日志
1> RESTORE LOG test FROM DISK='D:Program FilesMicrosoft SQL ServerMSSQLBACKU
P est_2.bak' WITH RECOVERY
2> go
已處理 2 頁，這些頁屬於數據庫 'test' 的文件 'TEST_Log'（位於文件 1 上）。
RESTORE LOG 操作成功地處理了 2 頁，花費了 0.056 秒（0.173 MB/秒）。
數據已經完全恢復了，可以使用了。
select * from a
go
總結，DBA應該有一個完善的數據庫備份計劃。本例中，如果沒有一個完全備份的話，數據庫的恢復就不可能
當sql server數據庫崩潰時如何恢復？
任何數據庫系統都無法避免崩潰的狀況，即使你使用了clustered，雙機熱備……仍然無法完全根除系統中的單點故障，何況對於大部分用戶來說，無法承受這樣昂貴的硬件投資。所以，在系統崩潰的時候，如何恢復原有的寶貴數據就成為一個極其重要的問題了。
在恢復的時候，最理想的情況就是你的數據文件和日志文件都完好無損了，這樣只需要sp_attach_db，把數據文件附加到新的數據庫上即可，或者在停機的時候把所有數據文件(一定要有master等)都copy到原有路徑下也行，不過一般不推薦這樣的做法，sp_attach_db比較好，雖然麻煩許多。
但是呢，一般數據庫崩潰的時候系統是未必能有時間把未完成的事務和髒頁等寫入磁盤的，這樣的情況sp_attach_db就會失敗。那麼，寄期望於dba制定了一個良好的災難恢復計劃吧。按照你的恢復計劃，還原最新的完全備份，增量備份或者事務日志備份，然後如果你的活動事務日志還能讀得出來的話，恭喜你！你可以還原到崩潰前的狀態。
一般的單位都是沒有專職的dba的，如果沒有可用的備份，更可能是最近一次備份的時間過於久遠而導致不可接受的數據損失，而且你的活動事務日志也處於不可用的狀態，那就是最麻煩的情況了。
不幸的很的是，一般數據庫崩潰都是由於存儲子系統引起的，而這樣的情況是幾乎不可能有可用的日志用於恢復的。那麼就只好試一下這些方案了。當然，是要求至少你的數據文件是存在的，要是數據文件、日志文件和備份都沒有了的話，別找我，你可以到樓頂上去唱“神啊，救救我吧”。
首先，你可以試一下sp_attach_single_file_db，試著恢復一下你的數據文件，雖然能恢復的可能性不大，不過假如這個數據庫剛好執行了一個checkpoint的話，還是有可能成功的。
如果你沒有好到有摸彩票的手氣，最重要的數據庫沒有像你期盼的那樣attach上去，不要氣餒，還是有別的方案的。
我們可以試著重新建立一個log，先把數據庫設置為emergency mode，sysdatabases的status為32768 就表示數據庫處於此狀態。
不過系統表是不能隨便改的，設置一下先
use master
go
sp_configure 'allow updates', 1
reconfigure with override
go
然後
update sysdatabases set status = 32768 where name = ''
現在，祈求滿天神佛的保佑吧，重新建立一個log文件。成功的機會還是相當大的，系統一般都會認可你新建立的日志。如果沒有報告什麼錯誤，現在就可以松一口氣了。
雖然數據是恢復了，可是別以為事情就算完成了，正在進行的事務肯定是丟失了，原來的數據也可能受到一些損壞。
先把sql server 重新啟動一下，然後檢查你的數據庫吧。
先設置成單用戶模式，然後做dbcc
sp_dboption '', 'single user', 'true'
dbcc checkdb('')
如果沒有什麼大問題就可以把數據庫狀態改回去了，記得別忘了把系統表的修改選項關掉。
update sysdatabases set status = 28 where name = '' --當然你的數據庫狀態可能不是這個，自己改為合適的值吧。也可以用sp_resetstatus
go
sp_configure 'allow updates', 0
reconfigure with override
go
checkdb的時候可能報告有一些錯誤，這些錯誤的數據你可能就只好丟棄了。
checkdb有幾種修復選項，自己看著用吧，不過最後你可能還是得用repair_allow_data_loss，完成所有修復。
chekcdb並不能完成所有的修復，我們需要更進一步的修復，用dbcc checktable對每一個表做檢查吧。
表的列表可以用sysobjects裡面得到，把objectproperty是istable的全部找出來檢查一下吧，這樣能夠基本上解決問題了，如果還報告錯誤，試著把數據select into到另一張表檢查一下。
這些都做完了之後，把所有索引、視圖、存儲過程、觸發器等重新建立一下。dbcc dbreindex也許可以幫你一些忙。
數據庫日志文件丟失時的恢復步驟，描述我誤刪除了數據庫的事務日志文件(.ldf)之後，如何經過各種嘗試恢復數據庫的。
但是不少網友在處理“數據庫置疑”的實踐過程中，又產生了許多新的疑問。
我還是總結一下出現的幾種情況，以供參考。
2.Zach的靈驗腳本
Zach說他每次遇到這種數據庫置疑情況，就運行下面這個腳本，屢試不爽：
======================================================
--before running any script, run the following to set the
master database to allow updates
USE master
GO
sp_configure 'allow updates', 1
GO
RECONFIGURE WITH OVERRIDE
GO
--Run the following script
UPDATE master..sysdatabases SET status = status ^ 256
WHERE name = 'Database_Name'
--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 'allow updates', 0
GO
RECONFIGURE WITH OVERRIDE
GO
=====================================
從上面可以看出，處理置疑的基本步驟還是我那篇文章中說的(注意我使用的字體顏色)：
執行 sp_configure 以允許對系統表進行更新，然後用 RECONFIGURE WITH OVERRIDE 語句強制實施該配置；
數據庫重置緊急模式；
執行sp_resetstatus關閉數據庫的置疑標志，但是原封不動地保持數據庫的其它選項（只有系統管理員才能執行）。執行該過程後，立即重啟 SQL Server服務；
執行 sp_configure 以禁止對系統表進行更新，然後用 RECONFIGURE WITH OVERRIDE 語句強制實施該配置。
status ^ 256的意思就是：
Constant Value Description
SQLDMODBStat_Suspect 256 Database integrity is suspect for the referenced database.
不同的是，有時候丟失了數據庫日志文件，額外需要以下步驟：
把應用數據庫設置為Single User模式；
做DBCC CHECKDB；
才可以。
但是幾位網友的實踐結果就是這個DBCC CHECKDB執行失敗。一位網友yang說：“但是 DBCC CHECKDB就是執行不了，總是說“該數據庫處於回避恢復模式”。我已經試了很多次了，就是改變不了這個狀態。”
還有一位Rui執行DBCC CHECKDB時報錯：“Server: Msg 943, Level 14, State 1, Line 1 Database 'his_yb' cannot be opened because its version (539) is later than the current server version (515).”
對於Yang，可能他沒有一步一步做，。我的切身體會是，把應用數據庫設置為Single User模式後就可以做DBCC CHECKDB。之後呢，也許SQL Server重啟後自動檢查數據庫是否正常。但是數據應該是可以讀出來的，至少可以被DTS Wizard讀出來的。這時候的數據庫還存在問題，比如我的組件使用數據庫時，報告說：“發生錯誤：-2147467259,未能在數據庫 'XXX' 中運行 BEGIN TRANSACTION，因為該數據庫處於回避恢復模式。”
對於Rui，他碰到的那個錯誤
Server: Msg 943, Level 14, State 1, Line 2
Database 'XXXX' cannot be opened because its version (536) is later than
the current server version (515).
這表明Rui正試圖：
從一個SQL Server 2000(version 539,536之類的)的數據庫備份恢復到一個SQL Server 7.0中
或者
把一個SQL Server 2000(version 539,536之類的)的數據庫attach到一個SQL Server 7.0中，
這是不允許的。如果你必須使用這個SQL Server 2000的數據備份，那麼請您首先把這個備份倒入SQL Server 2000，最後用DTS把數據庫從SQL Server 2000上transfer到SQL Server 7.0上。
