故障现象：北京某会计事务所用友软件突然打不开，数据库丢失打不开，数据全没有了。

故障类型：博维数据恢复中心工程师检测后发现，用友软件使用的是SQL2000数据库，因为数据库损坏置疑引起来的数据丢失，SQL 2000数据库置疑惑修复就可以了

修复结果：因为硬盘引道原因引起的SQL2000数据库报错，从而数据全部丢失，我们工程师修复SQL2000数据库，找到原始路径后把修复好的传回覆盖，软件正常打开，数据全部找回。

一些小的方法：（数据无价，谨慎操作，数据重要找专业人事）

SQL Server2000数据库文件损坏时如何恢复 

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也许可以帮你一些忙。