SQL日志文件丢失，只有MDF恢复

新建一个同名的数据库，然后把数据库设置为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>'

以上操作完了之后，把msql的server服务给停了，然后把需要恢复的MDF文件替换掉新建的MDF文件。操作完之后，再开启MSSQL服务，成功的机会还是相当大的，系统一般都会认可你新建立的日志。
============================================================

此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表，但是仅仅有系统表

G．下面执行真正的恢复操作，重建数据库日志文件
dbcc rebuild_log('test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.ldf')

H．验证数据库一致性（可省略）
dbcc checkdb('test')
一般执行结果如下：
CHECKDB 发现了 0 个分配错误和 0 个一致性错误（在数据库 'test' 中）。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

I．设置数据库为正常状态
sp_dboption 'test','dbo use only','false'
如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦。

J．最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接操作系统表是一件比较危险的事情。当然，我们可以在SQL Server Enterprise Manager里面恢复，也可以使用如下语句完成
sp_configure 'allow updates',0
go
reconfigure with override
go
================================================

最后就要检查数据了：

先设置成单用户模式，然后做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