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