手工修復(fù)SqlServer數(shù)據(jù)庫

wooloov

朋友的SQLserver數(shù)據(jù)庫記錄了他公司的經(jīng)營數(shù)據(jù)，但沒有任何保護(hù)措施，數(shù)據(jù)備份也是好幾個(gè)月以前做了一次。并且這樣重要的數(shù)據(jù)庫，他也就是安裝在一塊IDE硬盤上（可能對他這么規(guī)模大小的公司，還沒有什么數(shù)據(jù)安全的意識）
不幸的事情終于發(fā)生，一天斷電導(dǎo)致SQLSErver數(shù)據(jù)庫無法打開了。
他送來的數(shù)據(jù)文件有508.3M，不包括日志文件。
在Sqlserver 2000里attache這個(gè)數(shù)據(jù)文件時(shí)，發(fā)生823錯(cuò)誤：
Event Type: Error
Event Source: MSSQL$DD
Event Category: (2)
Event ID: 17052
Date:  5/31/2008
Time:  7:13:31 PM
User:  DDW2K3\Administrator
Computer: DDW2K3
Description:
Error: 823, Severity: 24, State: 2
I/O error (bad page ID) detected during read at offset 0x00000000012000 in file 'C:\share\tiger_data.mdf'.
嘗試使用通常的辦法恢復(fù)，即建立一個(gè)新數(shù)據(jù)庫，然后用這個(gè)數(shù)據(jù)文件覆蓋新數(shù)據(jù)庫的數(shù)據(jù)文件。不成功，這個(gè)數(shù)據(jù)文件已嚴(yán)重?fù)p壞。
察看文件的0x00000000012000數(shù)據(jù)塊信息，發(fā)現(xiàn)page id 為00 00，顯然不對。并且從0x00000000012000開始到0x00000000014000的8K數(shù)據(jù)塊中沒有任何數(shù)據(jù)，說明SQLServer在讀寫這個(gè)頁面的時(shí)候發(fā)生了嚴(yán)重錯(cuò)誤，這8K信息已完全丟失。
解決辦法：
1. 把0x00000000012000處的page ID改為正常值。
2. 打開sqlserver enterprise manager，attache 修改后的數(shù)據(jù)文件。成功。
3. 使數(shù)據(jù)庫處于單用戶模式下，運(yùn)行dbcc checkdb （‘dbname’， repair_rebuild），數(shù)據(jù)成功恢復(fù)
4. 正常打開數(shù)據(jù)庫，備份文件。
SqlServer每個(gè)page為8K，自動在每個(gè)page前面標(biāo)注ID number，以保持?jǐn)?shù)據(jù)的一致性。由于斷電等意外因素，緩存內(nèi)的數(shù)據(jù)還來不及寫入到硬盤，就可能造成某個(gè)或某些Page的數(shù)據(jù)錯(cuò)誤，導(dǎo)致整個(gè)數(shù)據(jù)庫無法打開。

我上網(wǎng)查了大量的資料，一般發(fā)生這樣的情況下，只能依靠以前備份的數(shù)據(jù)來恢復(fù)。像這樣通過修改某個(gè)page id就能修復(fù)的情況，實(shí)在是不幸中的大幸了。



本文來自ChinaUnix博客，如果查看原文請點(diǎn)：http://blog.chinaunix.net/u2/73762/showart_1086020.html