如何使用损坏或删除SQL Server事务日志文件重建数据库

This is the last article, but not the least one, in the SQL Server Transaction Log series. In this series of articles (see the TOC below), we described the Transaction Log concept from four different aspects.

这是SQL Server事务日志系列中的最后一篇文章，但并非最不重要。在本系列文章（请参见下面的TOC ）中，我们从四个不同方面描述了事务日志概念。

In the first articles group, we described the main concept of the SQL Server Transaction, dived deeply the internal structure of the SQL Server Transaction Log, and the vital role that the Transaction Log plays in keeping the database in a consistent state and recovering the corrupted database or mistakenly modified table to a specific point in time.

在第一篇文章组中，我们描述了SQL Server事务的主要概念，深入探讨了SQL Server事务日志的内部结构，以及事务日志在使数据库保持一致状态并恢复损坏的数据库中所起的重要作用。数据库或错误地将表修改到特定的时间点。

After that, we went through the three recovery model types, Full, Simple and Bulk-Logged, that controls how the transactions are written to the SQL Transaction Log file, and the relationship between the SQL Server Transaction Log and the different types of high availability and disaster recovery solutions.

之后，我们介绍了三种恢复模型类型，即完全，简单和大容量日志记录，它们控制如何将事务写入SQL事务日志文件，以及SQL Server事务日志与不同类型的高可用性之间的关系。和灾难恢复解决方案。

After building a good understanding background about the SQL Transaction Log, we discussed how to manage and monitor the SQL Server Transaction Log file growth, the different operations that can be performed on the Transaction Log, such as the log backup, shrink and truncate operations and finally the list of best practices that should be performed by the database administrators in order to keep the SQL Transaction Log in healthy state.

在对SQL事务日志建立了良好的理解背景之后，我们讨论了如何管理和监视SQL Server事务日志文件的增长，可以在事务日志上执行的不同操作，例如日志备份，收缩和截断操作以及最后，数据库管理员应执行的最佳实践列表，以使SQL事务日志保持正常状态。

Finally, we discussed how to take advantages from the logs that are automatically written to the Transaction Log in Undoing or Redoing a specific data modification process. In this article, we will see how to rebuild a SQL Server database that has a corrupted or deleted SQL Server Transaction Log file.

最后，我们讨论了如何在撤消或重做特定数据修改过程中利用自动写入事务日志的日志的优势。在本文中，我们将看到如何重建具有损坏或删除SQL Server事务日志文件SQL Server数据库。

问题定义 (Issue definition )

When the SQL Server service started, the SQL Server Engine will read the whole Transaction Log file and perform the recovery process, that includes both the Redo and Undo phase. If the reading process or the recovery process fails, the database will not be brought online and will be marked as Suspect or Recovery Pending, based on the failure stage.

启动SQL Server服务时，SQL Server引擎将读取整个事务日志文件并执行恢复过程，该过程包括“重做”和“撤消”阶段。如果读取过程或恢复过程失败，则数据库将不会联机，并会根据失败阶段将其标记为“ 可疑”或“ 恢复未决” 。

The Transaction Log file corruption can be caused due to multiple reasons, include:

可能由于多种原因导致事务日志文件损坏，包括：

The system terminated abnormally without proper shutdown for the databases 系统异常终止，没有正确关闭数据库
Hardware or configuration issue occurred with the I/O subsystem that is used to host the system and user databases files 与用于承载系统和用户数据库文件的I / O子系统发生硬件或配置问题
The system got affected by a virus, malicious software or malware attack that damaged the files or make it inaccessible 系统受到病毒，恶意软件或恶意软件攻击的影响，这些病毒损坏了文件或使其无法访问
The Transaction Log file ran out of free space and exceeds the configured maximum file size 事务日志文件中的可用空间不足，并且超出了配置的最大文件大小

故障排除 (Troubleshooting)

If you are not able to bring the database online as it stuck in SUSPECT or Recovery Pending state , the first action you need to perform is reviewing the SQL Server Error Logs and the Windows Application and System event logs on the SQL Server that is hosting this database. If any hardware issue detected, contact the system administrator or the hardware vendor to fix the issue for you. If the issue is caused due to a Transaction Log file corruption, continue reading this article to know how to fix that issue.

如果由于处于“挂起”状态或“挂起”状态而无法使数据库联机，则需要执行的第一个操作是查看承载此数据库SQL Server上SQL Server错误日志以及Windows应用程序和系统事件日志。数据库。如果检测到任何硬件问题，请与系统管理员或硬件供应商联系以为您解决问题。如果问题是由于事务日志文件损坏引起的，请继续阅读本文以了解如何解决该问题。

There is a number of errors you may find that indicates an issue with the SQL Server Transaction Log file, such as:

您可能会发现许多错误，这些错误表明SQL Server事务日志文件存在问题，例如：

A file activation error occurred. The physical file name ‘C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA\XXX.ldf’ may be incorrect. Diagnose and correct additional errors, and retry the operation 发生文件激活错误。物理文件名“ C：\ Program Files \ Microsoft SQL Server \ MSSQL13.MSSQLSERVER \ MSSQL \ DATA \ XXX.ldf”可能不正确。诊断并纠正其他错误，然后重试该操作
SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0x186ba635; actual: 0x186b2635). It occurred during a read of page (2:0) in database ID 22 at offset 0000000000000000 in file ‘C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA\XXX.ldf’. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online SQL Server检测到一个基于逻辑一致性的I / O错误：错误的校验和（预期：0x186ba635；实际：0x186b2635）。它是在读取文件ID C：\ Program Files \ Microsoft SQL Server \ MSSQL13.MSSQLSERVER \ MSSQL \ DATA \ XXX.ldf中偏移0000000000000000的数据库ID 22中的页面（2：0）时发生的。 SQL Server错误日志或系统事件日志中的其他消息可能会提供更多详细信息。这是严重的错误情况，威胁到数据库的完整性，必须立即更正。完成完整的数据库一致性检查（DBCC CHECKDB）。此错误可能是由多种因素引起的；有关更多信息，请参见SQL Server联机丛书。
The log cannot be rebuilt because there were open transactions/users when the database was shutdown, no checkpoint occurred to the database, or the database was read-only. This error could occur if the transaction log file was manually deleted or lost due to a hardware or environment failure 无法重建日志，因为关闭数据库时有打开的事务/用户，数据库没有检查点，或者数据库是只读的。如果由于硬件或环境故障而手动删除或丢失了事务日志文件，则可能会发生此错误

The best and the safest option to fix the database Transaction Log file corruption issue is restoring the database from the latest backup chain, that includes restoring the Full backup, The Differential backup, and all Transaction Log backup to the last healthy point in time before the corruption occurred.

解决数据库事务日志文件损坏问题的最佳，最安全的方法是从最新的备份链还原数据库，这包括将完全备份，差异备份和所有事务日志备份还原到数据库之前的最后一个健康时间点。发生腐败。

But what if this option is not applicable, due to having no proper backup strategy configured or some of the backup files in the current backup chain were lost? In this case, we cannot accept the data loss that is resulted from restoring the last Full backup file or half of the backup chain before reaching the lost backup file, as the database contains critical data. The last applicable option, that deserves trying is rebuilding the Transaction Log file, as we will show in the next section, tolerating the lost of recovering, undo and redo, the transactions that were located in the original Transaction Log file.

但是如果由于没有配置正确的备份策略或者当前备份链中的某些备份文件丢失而导致该选项不适用怎么办？在这种情况下，由于数据库包含关键数据，我们无法接受由于在恢复丢失的备份文件之前还原最后一个完整备份文件或一半备份链而导致的数据丢失。值得尝试的最后一个适用选项是重建事务日志文件，这将在下一节中显示，可以容忍丢失，还原和重做丢失了原始事务日志文件中的事务的情况。

解析度 (Resolution)

In order to rebuild the corrupted SQL Server Transaction Log file, we should put the database in the Emergency state with Single User Mode, using the command below:

为了重建损坏SQL Server事务日志文件，我们应使用以下命令将数据库置于单用户模式的“紧急”状态：

USE master
GO
ALTER DATABASE [TestTRNLogCorrupt] SET EMERGENCY
GO
ALTER DATABASE [TestTRNLogCorrupt] SET SINGLE_USER
GO

In this way we ensure that the database will be brought up without the Transaction Log file, allowing us to run the proper commands that are required to fix the file corruption issue:

这样，我们可以确保在没有事务日志文件的情况下启动数据库，从而使我们能够运行解决文件损坏问题所需的正确命令：

After that, we will try to execute the DBBC CHECKDB command using the REPAIR_ALLOW_DATA_LOSS option, in order to check the database for any inconsistency error and apply some special repairs to fix the Transaction Log corruption issue, as in the T-SQL script below:

之后，我们将尝试使用REPAIR_ALLOW_DATA_LOSS选项执行DBBC CHECKDB命令，以便检查数据库是否存在任何不一致错误，并应用一些特殊的修复程序来修复事务日志损坏问题，如下面的T-SQL脚本中所示：

DBCC CHECKDB ([TestTRNLogCorrupt], REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS, ALL_ERRORMSGS;
GO

Unfortunately, the corruption of the SQL Transaction Log in our database cannot be fixed using the DBCC CHECKDB command and requires further troubleshooting to make it fixed. The error message is received from the DBCC CHECKDB command in our case will be like:

不幸的是，无法使用DBCC CHECKDB命令修复数据库中SQL事务日志的损坏，并且需要进行进一步的故障排除才能将其修复。从DBCC CHECKDB命令收到的错误消息在我们的情况下将类似于：

If you reach this step and the SQL Server Transaction Log file still corrupted, I recommend you NOT to detach the database and try to attach it without referencing the Transaction Log file in order to create a new Transaction Log file.

如果达到此步骤并且SQL Server事务日志文件仍然损坏，建议您不要分离数据库，并尝试在不引用事务日志文件的情况下附加数据库以创建新的事务日志文件。

If you try to detach the corrupted database, as below:

如果您尝试分离损坏的数据库，如下所示：

Then try to attach it while removing the reference to the SQL Transaction Log file:

然后尝试在删除对SQL事务日志文件的引用时附加它：

The attach process will fail, showing the error message below:

附加过程将失败，并在下面显示错误消息：

In order to attach it correctly without using the SQL Server Transaction Log file, renamed the old Transaction Log file:

为了正确附加它而不使用SQL Server事务日志文件，请重命名旧的事务日志文件：

Then run the CREATE DATABASE command using the FOR ATTACH_REBUILD_LOG command, shown below:

然后使用FOR ATTACH_REBUILD_LOG命令运行CREATE DATABASE命令，如下所示：

CREATE DATABASE [TestTRNLogCorrupt]
ON (FILENAME = 'C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA\TestTRNLogCorrupt.mdf')
FOR ATTACH_REBUILD_LOG

And the database will be attached using the MDF file, with a new SQL Transaction Log file created on that database to replace the corrupted one, as shown below:

然后将使用MDF文件附加数据库，并在该数据库上创建一个新SQL事务日志文件来替换损坏的数据库，如下所示：

Another option to rebuild the corrupted SQL Server Transaction Log file is taking the database offline, as below:

重建损坏SQL Server事务日志文件的另一个选项是使数据库脱机，如下所示：

And the database will be marked as Offline, as shown below:

并将数据库标记为Offline ，如下所示：

Then change the corrupted SQL Transaction Log file name, as shown below:

然后更改损坏SQL事务日志文件名，如下所示：

Then run the ALTER DATABASE T-SQL command below, using the REBUILD LOG option, and provide the SQL Server Transaction Log file original name in order to rebuild the file again for that database, as in the T-SQL script below:

然后，使用REBUILD LOG选项运行下面的ALTER DATABASE T-SQL命令，并提供SQL Server事务日志文件的原始名称，以便再次为该数据库重建文件，如下面的T-SQL脚本所示：

ALTER DATABASE [TestTRNLogCorrupt] REBUILD LOG ON
(NAME= logicalname, FILENAME='C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA\TestTRNLogCorrupt_log.ldf')
GO

And the SQL Server Engine will rebuild the Transaction Log file, with a warning message recommending you to run the DBCC CHECKDB command to validate the physical consistency of the database, as shown below:

然后，SQL Server Engine将重建事务日志文件，并显示一条警告消息，建议您运行DBCC CHECKDB命令来验证数据库的物理一致性，如下所示：

After that, we will bring the database online, as shown below:

之后，我们将使数据库联机，如下所示：

And the database will be brought online under Single User Mode state, shown below:

数据库将在“单用户模式”状态下联机，如下所示：

Now, we will return the database back to the MULTI_USER online mode, using the ALTER DATABASE statement below:

现在，我们将使用下面的ALTER DATABASE语句将数据库返回到MULTI_USER在线模式：

ALTER DATABASE [TestTRNLogCorrupt] SET MULTI_USER
GO

And the database will be in the Online state, as shown from the SQL Server Management Studio below:

数据库将处于Online状态，如下面SQL Server Management Studio所示：

As mentioned in the previous warning message, we will run the DBCC CHECKDB command below, in order to check the physical consistency of the database after rebuilding the SQL Transaction Log file:

如前面的警告消息中所述，我们将在下面运行DBCC CHECKDB命令，以便在重建SQL事务日志文件后检查数据库的物理一致性：

DBCC CHECKDB ([TestTRNLogCorrupt])

And the DBCC CHECKDB will show us that there is no consistency issue on that database that needs to be fixed, as in the result message below:

并且DBCC CHECKDB将向我们显示该数据库上没有需要修复的一致性问题，如以下结果消息所示：

All is fixed now!

现在一切都固定了！

Although this method fixed the SQL Server Transaction Log file corruption issue, it may result with losing some data that are written to the Transaction Log but not hardened yet to the underlying disk after a CHECKPOINT process, without knowing what was lost exactly. Nothing will be better than having a proper backup strategy that helps to recover the data in case of any corruption without falling in the risk of any data loss.

尽管此方法解决了SQL Server事务日志文件损坏的问题，但是它可能导致丢失一些数据，这些数据在CHECKPOINT进程后丢失了写入事务日志中但尚未硬化到基础磁盘的数据，而又不知道确切丢失了什么。没有合适的备份策略能更好地解决数据损坏的情况，而又不会降低任何数据丢失的风险。

We reached the end of the SQL Server Transaction Log articles series. Hope you enjoyed it. Stay tuned to the next articles series ?

我们到了SQL Server事务日志文章系列的结尾。希望你喜欢。请继续关注下一篇文章系列？

目录 (Table of contents)

SQL Server Transaction Overview

SQL Server Transaction Log Architecture

What are SQL Virtual Log Files aka SQL Server VLFs?

SQL Server Transaction Log and Recovery Models

SQL Server Transaction Log and High Availability Solutions

SQL Server Transaction Log Growth Monitoring and Management

SQL Server Transaction Log Backup, Truncate and Shrink

SQL Server Transaction Log Administration Best Practices

Recovering Data from the SQL Server Transaction Log

How to Rebuild a Database with a Corrupted or Deleted SQL Server Transaction Log File

Auditing by Reading the SQL Server Transaction Log

SQL Server事务概述

SQL Server事务日志体系结构

什么是SQL虚拟日志文件（又名SQL Server VLF）？

SQL Server事务日志和恢复模型

SQL Server事务日志和高可用性解决方案

SQL Server事务日志增长监视和管理

SQL Server事务日志备份，截断和收缩

SQL Server事务日志管理最佳实践

从SQL Server事务日志中恢复数据

如何使用损坏或删除SQL Server事务日志文件重建数据库

通过读取SQL Server事务日志进行审核

翻译自: https://www.sqlshack.com/how-to-rebuild-a-database-with-a-corrupted-or-deleted-sql-server-transaction-log-file/