主页 / dba / 问题 / 312273
Accepted
variable
Asked: 2022-05-18 19:45:46 +0800 CST

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

  • 772

假设数据文件在 D: 并且日志文件在 E:

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

启动时，SQL Server 将意识到 .mdf 文件存在，但日志文件不存在。由于缺少日志文件，SQL 服务器将无法执行任何撤消/重做恢复步骤，并将数据库视为可疑对象。

注意：我试过这个并注意到数据库进入了可疑模式。这里的最佳做法是使用备份（完整 + tlog）来恢复数据库。在我的情况下，我从上午 12 点开始进行完整备份，但没有 tlog 备份。如果我从上午 12 点的备份中恢复，那么我会丢失一整天的数据（假设崩溃发生在中午）。我正在尝试通过利用现有数据文件来考虑如何在这种情况下进行。

  1. 在这种情况下如何恢复数据库？
  2. 说数据丢失只是那些在 tlog 文件中但未写入磁盘的事务是否正确？
sql-server transaction-log

3 个回答

  1. Best Answer

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

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

    说数据丢失只是那些在 tlog 文件中但未写入磁盘的事务是否正确？

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

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

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

    所有的赌注都取消了。因此，如果您在没有日志文件的情况下强制访问未完全关闭的数据库，则需要在上面进行整理。

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

    逻辑不一致由您处理。数据库是否足够小，可以遍历所有数据以确保其逻辑一致？可能不是。您现在明白了为什么要进行还原，以及为什么频繁的日志备份如此重要。

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

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

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

    • 8

  2. 取消附加 mdf 文件后，您可以尝试使用此未记录的命令。

    USE master;

CREATE DATABASE [Mydb]
    ON  ( FILENAME = N'E:\xxx\Mydb.mdf' )
    FOR ATTACH_FORCE_REBUILD_LOG;
GO

    这将重新构建一个新的 ldf 文件。mdf 文件中剩余的内容留给“尽最大努力”。

    • 4

  3. 在我的情况下，我从上午 12 点开始进行完整备份，但没有 tlog 备份。如果我从上午 12 点的备份中恢复，那么我会丢失一整天的数据（假设崩溃发生在中午）。

    听起来您当前的备份频率不支持您预期的恢复目标。
    记住关于恢复的两个最重要的指标：

    • 恢复时间目标 (RTO)您需要
      多长时间才能恢复损坏的数据库并再次运行？
    • 恢复点目标 (RPO)这样做允许您丢失
      多少数据？

    例如，如果您的 RPO 是四个小时，那么您需要每两个小时进行一次日志备份。

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

    来自您的数据和日志备份。

    说数据丢失只是那些在 tlog 文件中但未写入磁盘的事务是否正确？

    数据丢失将只是那些未提交的事务。只要它们在（预写的）事务日志中并提交，实例恢复就能够重构它们，即使它们从未被写入磁盘。

    • 3

相关问题