请问哪位知道只有一个数据文件时的恢复方法？我看了一些文章，都不成功！

[tyd163xx]

下面是我在别的论坛看到的文章，可是总是试不成功忘大侠们指点：
如果哪位大侠知道只有一个数据文件时的恢复方法，请赐教，不胜感谢！
本人邮箱：[e-mail]
分数可以再加500分。

我看了文章《当SQL Server数据库崩溃时如何恢复》，做了以下实验：
1、创建TEST数据库
2、导入部分数据
3、停止SQL SERVER服务，除去test_Log.LDF文件，重起SQL SERVER
这时TEST处于置疑状态，然后按文章所说
Use Master
Go
sp_configure 'allow updates', 1
reconfigure with override
Go
update sysdatabases set status = 32768 where name = 'TEST'
4、刷新
接着问题就出现了，原文：“祈求满天神佛的保佑吧，重新建立一个log文件。成功的机会还是相当大的，系统一般都会认可你新建立的日志。”

请问：这个LOG文件怎么重建？我在EM中新建一个test_Log2.LDF时出现“5004”错误。

附原文：（若本文作者看到转贴请别介意，如有不妥之处请多多包涵）
工作告一段落，今天下午有空，写篇文章，也许会对大家有帮助

任何数据库系统都无法避免崩溃的状况，即使你使用了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 = '<db_name>'
现在，祈求满天神佛的保佑吧，重新建立一个log文件。成功的机会还是相当大的，系统一般都会认可你新建立的日志。如果没有报告什么错误，现在就可以松一口气了。

虽然数据是恢复了，可是别以为事情就算完成了，正在进行的事务肯定是丢失了，原来的数据也可能受到一些损坏。

先把SQL Server 重新启动一下，然后检查你的数据库吧。
先设置成单用户模式，然后做dbcc
sp_dboption '<db_name>', 'single user', 'true'
DBCC CHECKDB('<db_name>')
如果没有什么大问题就可以把数据库状态改回去了，记得别忘了把系统表的修改选项关掉。
update sysdatabases set status = 28 where name = '<db_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也许可以帮你一些忙。

然后，就可以向boss吹嘘一下你的丰功伟业，顺便小小的提一下加薪的要求，如果（很有可能）不得逞的话，也只好回家睡觉去:'(
记得下次别忘了做好备份哦~


上面提到的命令、对象在Books Online中均有详细说明，请注意参看。
Thank you for your reading.

[happydreamer]

这篇文章写的已经很详细了，你具体遇到什么提示呢
参考一下下面的用法：
exec sp_detach_db 'factory','true'

exec sp_attach_single_file_db @dbname='factroy',
@physname = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\factory_data.mdf'

[tyd163xx]

呵呵，我指的是非正常状态下，log文件遭到破坏，而dat文件正常，且不能用
exec sp_attach_single_file_db 附加的状况。
这种情况要恢复是比较困难的。

[tyd163xx]

在SQL SERVER正常停止的状态下获得的数据文件可以在
1、本机原目录
2、本机其他目录
3、其他机器上附加成功。

但在特殊情况下，如服务器崩溃、磁盘故障，只幸存了数据文件，但只依靠数据文件无法附件成功时。怎么重建日志？怎么恢复数据、保持数据库的一致性？

[dongquestion]

你只好早早做好备份了，并且最好做个远程备份，并且再作备份之前，先check database一下，然后祈求上帝必要弄坏你的机器:)

[dongquestion]

打错了,应该祈求上帝不要弄坏你的机器:)

[tyd163xx]

嘿嘿，可是难免会有这种情况的啊

[tyd163xx]

考，没人理我啊