重建事务日志

一尘不染

重建事务日志

sql-server

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

分离和重新附加数据库；和
取消删除事务日志文件

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

我们目前正在运行：

ALTER DATABASE <dbname> REBUILD 
LOG ON (NAME=<dbname>,FILENAME='<logfilepath>')

…但是考虑到数据库的大小，这可能需要几天才能完成。

问题

上面的命令和下面的命令有区别吗？

sql 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 小时），它是成功的。假设我们都知道数据库备份的重要性（并授予项目经理访问服务器的权限......）。

阅读 128

2022-11-20

共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 将要从不存在的日志文件执行恢复（回滚和前滚）。当磁盘崩溃或服务器意外关闭并且数据库未完全关闭时，就会发生这种情况。我想这不是你的情况，一切都对你有好处。

DBCC CHECKDB (DBNAME, REPAIR_ALLOW_DATA_LOSS)在处于紧急状态的数据库上运行检查数据库是否存在不一致错误，首先尝试使用日志文件从任何不一致中恢复。如果丢失，将重建事务日志。
ALTER DATABASE REBUILD LOG ON...是一个未记录的过程，需要后续DBCC CHECKDB修复任何错误。

2022-11-20