……但到目前为止还没有任何工作.
我们目前正在运行：
ALTER DATABASE <dbname> REBUILD LOG ON (NAME=<dbname>,FILENAME='<logfilepath>')
…但考虑到数据库的大小,这可能需要几天时间才能完成.
问题
>上面的命令和下面的命令之间有区别吗？
DBCC CHECKDB ('<dbname>',REPAIR_ALLOW_DATA_LOSS)
>我们应该执行REPAIR_ALLOW_DATA_LOSS吗？
值得注意的是,数据来自其他来源,因此可以重建数据库,但是我们怀疑修复数据库要比重新插入所有数据快得多.
更新
对于那些保持得分：ALTER DATABASE / REBUILD LOG命令在大约36小时后完成并报告：
Warning: The log for database ‘dbname’ has been rebuilt. Transactional consistency has been lost. The RESTORE chain was broken,and the server no longer has context on the prevIoUs log files,so you will need to know what they were.
You should run DBCC CHECKDB to validate physical consistency. The database has been put in dbo-only mode. When you are ready to make the database available for use,you will need to reset database options and delete any extra log files.
然后我们运行了一个DBCC CHECKDB(花了大约13小时),这是成功的.让我们说,我们都已经了解了数据库备份的重要性(并授予项目经理访问服务器的权限……).
解决方法
这些命令应该可以解决这个问题：
ALTER DATABASE recovery_test_2 SET EMERGENCY; ALTER DATABASE recovery_test_2 SET SINGLE_USER; DBCC CHECKDB (recovery_test_2,REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS,ALL_ERRORMSGS;
我写了一篇关于这种情况的帖子：
SQL 2005/2008 Database Recovery Procedure – Log File Deleted (Part 3)
你问过两者之间的区别：
> DBCC CHECKDB(‘< dbname>‘,REPAIR_ALLOW_DATA_LOSS)和
> ALTER DATABASE< dbname> REBUILD LOG ON(NAME =< dbname>,FILENAME =’< logfilepath>‘)
问题是您可以同时运行这两个来重建日志文件,但是使用CHECKDB重建日志并检查数据库是否存在完整性错误.
如果在日志文件丢失时存在活动事务(未写入磁盘),则第二个(alter database)将不起作用.在启动或附加时,sql Server将希望从不存在的日志文件执行恢复(回滚和前滚).当磁盘崩溃或服务器意外关闭并且数据库未完全关闭时,就会发生这种情况.我想这不是你的情况,而且一切都很适合你.
> DBCC CHECKDB(DBNAME,REPAIR_ALLOW_DATA_LOSS)在紧急状态下运行数据库检查数据库是否存在不一致错误,首先尝试使用日志文件从任何不一致中恢复.如果缺少此选项,则会重建事务日志.> ALTER DATABASE REBUILD LOG ON …是一个未记录的过程,需要后续的DBCC CHECKDB来修复任何错误.
