重建事务日志

我们有一个非常大的数据库（〜6TB），该数据库的事务日志文件已删除（在SQL Server关闭的同时，我们已经尝试过：

1. 分离并重新附加数据库；和
2. 删除事务日志文件

...但是到目前为止没有任何效果。

我们目前正在运行：

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小时后完成并报告：

警告：数据库“ dbname”的日志已重建。事务一致性已丢失。RESTORE链已损坏，并且服务器不再在先前的日志文件上具有上下文，因此您将需要知道它们是什么。
您应该运行DBCC CHECKDB来验证物理一致性。数据库已置于仅dbo模式。当准备好使数据库可用时，您将需要重置数据库选项并删除所有额外的日志文件。

然后，我们运行了一个DBCC CHECKDB（花了大约13个小时），这是成功的。可以说，我们都已经了解了数据库备份的重要性（并授予项目经理对服务器的访问权限...）。

切勿分离Suspect数据库。无论如何，分离数据库后如何附加数据库？您使用CREATE DATABASE过FOR ATTACH_REBUILD_LOG选项吗？

这些命令应该可以解决问题：

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数据库恢复过程–日志文件已删除（第3部分）

您询问了以下两者之间的区别：

• DBCC CHECKDB ('<dbname>', REPAIR_ALLOW_DATA_LOSS) 和
• ALTER DATABASE <dbname> REBUILD LOG ON (NAME=<dbname>,FILENAME='<logfilepath>')

事实是，您可以同时运行以重建日志文件，但是CHECKDB可以重建日志并检查数据库是否存在完整性错误。

另外，如果在丢失日志文件时存在活动事务（未写入磁盘），则第二个数据库（备用数据库）将不起作用。在启动或附加时，SQL Server将要从不存在的日志文件执行恢复（回滚和前滚）。当磁盘崩溃或服务器意外关闭且数据库未完全关闭时，会发生这种情况。我想这不是您的情况，一切对您都有好处。

1. DBCC CHECKDB (DBNAME, REPAIR_ALLOW_DATA_LOSS)在紧急状态下在数据库上运行时，请检查数据库中是否存在不一致错误，然后首先尝试使用日志文件从任何不一致中恢复。如果缺少此记录，则重建事务日志。

2. ALTER DATABASE REBUILD LOG ON...是一个未记录的过程，需要后续步骤DBCC CHECKDB来修复所有错误。

是的，这是两个不同的语句，每个语句执行的操作都非常不同。

根据文件删除时数据库的状态，您可以通过附加数据库并使用以下方法重建日志来启动并运行：

EXEC sp_attach_single_file_db 'dbname here', 'file path and name here'

请参见产品文档中的sp_attach_single_file_db（Transact-SQL）。

另请参阅Paul S. Randal的这篇博客文章：

紧急模式维修：非常非常不得已的手段