如何从 SQL Server 日志文件驱动器崩溃中恢复？

Question

假设数据文件位于 D: 且日志文件位于 E:

假设 E 驱动器崩溃并且日志文件 (.ldf) 丢失。我将一个新的空磁盘附加到 E: 并启动 sql server。

启动时，SQL Server 将意识到 .mdf 文件存在，但日志文件不存在。由于丢失日志文件，SQL Server 将无法执行任何撤消/重做恢复步骤，并将数据库置于可疑位置。

注意：我尝试了此操作并注意到数据库进入可疑模式。这里的最佳实践是使用备份（完整+tlog）来恢复数据库。在我的情况下，我有上午 12 点的完整备份，但没有 tlog 备份。如果我从凌晨 12 点的备份中恢复，那么我会丢失一整天的数据（假设崩溃发生在中午）。我正在尝试思考如何利用现有的数据文件来处理这种情况。

1. 这种情况下如何恢复数据库呢？
2. 说数据丢失仅是那些位于 tlog 文件中但未写入磁盘的事务是正确的吗？

Answer 1

这种情况下如何恢复数据库呢？

从备份中恢复。继续阅读，您就会明白为什么我们推荐恢复路线。

说数据丢失仅是那些位于 tlog 文件中但未写入磁盘的事务是正确的吗？

我不会这么说。正如您所指出的，您的数据库是可疑的。所以你无法访问它。无论您采取什么方式“强制”该数据库可访问，都会给您带来不一致的数据库。举几个例子：

1. 物理不一致：例如为索引修改而写入的页面，而未写入相应的数据页。

2. 逻辑不一致：例如没有订单详细信息行的订单。或者反过来。

所有的赌注都落空了。因此，如果您强制访问未完全关闭且没有日志文件的数据库，则需要进行上述清理。

物理不一致可以使用 DBCC CHECKDB 和 REPAIR_ALLOW_DATA_LOSS 来处理。当然，它会丢弃任何看起来不正确的页面。你准备好这样做了吗？此外，这可能会增加更多的逻辑不一致（与上面第 2 步中已有的不一致）。

逻辑上的不一致由你来处理。数据库是否足够小以遍历所有数据以确保其逻辑一致？可能不会。您现在了解了为什么恢复是最佳选择，以及为什么频繁的日志备份如此重要。

至于如何在这种状态下强制访问数据库，有两种选择：

1. 使用 ATTACH_FORCE_REBUILD_LOG 附加它。这没有记录，所以我不会走这条路。

2. 使用 ALTER DATABASE 将其设置为紧急模式。然后使用 REPAIR_ALLOW_DATA_LOSS 进行 CHECKDB。此处描述了此过程。