近日由于误操作,删除了MSSQL的数据库的日志文件(ldf),幸而数据文件(mdf)完好无损,查阅资料,说直接附加数据文件,sql server会自动创建日志文件,于是照做,但却提示创建数据库失败的错误,怎么都附加不了。后来才知道那个ldf,是个活动日志文件,包含有事务信息,丢失后无法直接进行附加操作。教训啊,以后千万不要随意手工删除日志文件了,很容易造成数据丢失,特别是在进行这样的操作前最好备份一下数据。我就是因为没有备份,折腾了大半天。好在历经艰苦,终于把数据库附加上了,数据也完好无损,把恢复经过写出来供后来者参考。
为方便描述,这里我的数据库名字为test,数据文件名为test.mdf,日志文件名为test.ldf,文件保存在c:\data目录下。
停止数据库服务,删除日志文件test.ldf;执行下列命令,重建日志文件
DBCC REBUILD_LOG ('test','c:\test.ldf')取消数据库紧急模式:
update sysdatabases set status = 0 where name = 'test'
restore database test WITH RECOVERY
sp_configure 'allow', 0
reconfigure with override最后可以用下列命令检查一下有没有错误:
DBCC CHECKDB('test')如果一切正常的,你的数据库应该安安静静的躺倒了它该在的地方了。 另外,当日志文件满的的时候,在分离数据库之前一定要收缩日志文件,否则分离之后再想恢复的时候就会因为无法写日志文件导致无法进行附加操作。当然一旦出现这个问题,也可以用上面的方法进行处理。
为方便描述,这里我的数据库名字为test,数据文件名为test.mdf,日志文件名为test.ldf,文件保存在c:\data目录下。
- 新建一同名数据库test,然后停止数据库服务;
- 用需要恢复的数据文件(test.mdf)替换新建的数据库文件;
- 启动数据库服务,数据库test的状态显示为质疑;
- 在查询分析器执行下列SQL语句,将数据库改成紧急模式:
sp_configure 'allow', 1
reconfigure with override
update sysdatabases set status = 32768 where name = 'test'
reconfigure with override
update sysdatabases set status = 32768 where name = 'test'
停止数据库服务,删除日志文件test.ldf;执行下列命令,重建日志文件
DBCC REBUILD_LOG ('test','c:\test.ldf')取消数据库紧急模式:
update sysdatabases set status = 0 where name = 'test'
restore database test WITH RECOVERY
sp_configure 'allow', 0
reconfigure with override最后可以用下列命令检查一下有没有错误:
DBCC CHECKDB('test')如果一切正常的,你的数据库应该安安静静的躺倒了它该在的地方了。 另外,当日志文件满的的时候,在分离数据库之前一定要收缩日志文件,否则分离之后再想恢复的时候就会因为无法写日志文件导致无法进行附加操作。当然一旦出现这个问题,也可以用上面的方法进行处理。
转载于:https://blog.51cto.com/firefish/218473