重建事务日志

Question

我们有一个非常大的数据库（~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-only 模式。当您准备好使数据库可供使用时，您将需要重置数据库选项并删除任何额外的日志文件。

然后我们运行了一个DBCC CHECKDB（大约需要 13 小时），它成功了。假设我们都了解了数据库备份的重要性（以及授予项目经理访问服务器的权限......）。

Answer 1

永远不要分离可疑数据库。无论如何，您如何在分离后附加数据库？您使用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修复任何错误。

Answer 2

是的，这是两种不同的陈述，每一种都做不同的事情。

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

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

请参阅产品文档中的sp_attach_single_file_db (Transact-SQL)。

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

紧急模式维修：最后的手段