SQL Server中事务日志管理的阶梯，级别5：以完全恢复模式管理日志

Posted 2021-01-31 hujianwei

该系列
本文是Stairway系列的一部分：SQL Server中事务日志管理的阶梯

当事情进展顺利时，没有必要特别注意事务日志的功能或工作方式。您只需要确信每个数据库都有正确的备份机制。当出现问题时，了解事务日志对于采取纠正措施非常重要，尤其是在需要对数据库进行时间点恢复时！托尼戴维斯给出了每个DBA应该知道的正确程度的细节。

在此级别中，我们将查看在完全恢复模式下工作时如何以及如何进行日志备份，以及如何使用这些日志备份文件以及完整数据库备份执行数据库还原。完全恢复模式支持将数据库恢复到可用日志备份中的任何时间点，并假设可以在故障发生之前进行尾部日志备份，直到上次提交事务的时间。

什么得到记录？
在完全恢复模式下，所有操作都已完全记录。对于INSERT，UPDATE和DELETE操作，这意味着对于每个被修改的行，都会有一个日志记录，描述执行该语句的事务的ID，当该事务开始和结束时，哪些页面被更改，数据更改制作的，等等。

可以最小化记录的操作SELECT INTO，BULK INSERT和CREATE INDEX在完全恢复模式下工作时仍然完全记录，但操作略有不同。受这些操作影响的行不会单独记录;相反，只有数据库页面被记录，因为它们被填满。这样可以减少此类操作的日志记录，同时确保仍然存在执行回滚，重做和时间点恢复所需的所有相同信息。 Kalen Delaney发布了一些关于SELECT INTO（http://sqlblog.com/blogs/kalen_delaney/archive/2011/03/15/what-gets-logged-for-select-into.aspx）和索引重建的日志记录的调查（ http://sqlblog.com/blogs/kalen_delaney/archive/2011/03/08/what-gets-logged-for-index-rebuilds.aspx）操作，包括FULL和BULK_LOGGED恢复模式。在BULK_LOGGED模式下工作时，记录最小日志操作的差异将在第6级 - 管理BULK LOGGED恢复模式中的日志中详细讨论。

为什么备份事务日志？

在完全恢复模式下，只有日志备份可能导致截断日志。因此，事务日志将保存自上次备份事务日志以来执行的事务的完整和完整记录。由于所有操作都已完全记录，因此在繁忙的系统中，日志文件可以非常快速地增长。

因此，在完全恢复模式下工作时，除了完全备份和（可选）差异备份之外，还必须执行常规事务日志备份。许多新手或兼职DBA在其数据库上执行完全备份，但它们不执行事务日志备份。因此，事务日志不会被截断，并且它会增长并增长，直到它所在的驱动器用完磁盘空间，从而导致SQL Server停止工作。

一旦进行日志备份，就会发生日志截断，假设自上次备份以来发生了检查点，并且没有其他因素延迟截断，例如数据备份或恢复操作。有关可能延迟截断可恢复VLF的因素的完整列表，以及保留大量日志活动的因素，否则将不需要，例如流氓，长时间运行的未提交事务或数据库镜像或复制进程，请参阅：http：//msdn.microsoft.com/en-gb/library/ms345414.aspx。

COPY_ONLY备份事务日志
COPY_ONLY事务日志备份不会截断事务日志。 COPY_ONLY日志备份“独立”存在于正常日志备份方案中;它不会破坏日志备份链。

简而言之，事务日志备份执行双重目的，即允许还原和恢复到以前的某个时间点，以及控制事务日志的大小。可能导致事务日志相关问题的最常见原因是在完全恢复模式下工作，并且根本不进行日志备份，或者不经常使用日志备份来控制事务日志文件的大小。

如果您不确定是否在给定数据库上进行事务日志备份，那么您可以使用类似于清单5.1中所示的查询来查询MSDB数据库中的backupset表。

USE msdb ;
SELECT   backup_set_id ,
         backup_start_date ,
         backup_finish_date ,
         backup_size ,
         recovery_model ,
         [type]
FROM     dbo.backupset
WHERE    database_name = ‘TestDB‘

代码清单5.1：是否正在进行日志备份？

在类型列中，D表示数据库备份，L表示日志备份，I表示差异备份。

请注意，由于可以在不影响备份和还原行为的情况下操作此备份集表中的数据，因此您可能需要通过查询sys.database_recovery_status以查看last_log_backup_lsn（参见清单3.5）或sys的值来验证此查询的结果。 .databases表查看log_reuse_wait_desc的值（如果需要备份，将返回LOG_BACKUP）。

如何备份事务日志
如前所述，如果没有首先进行至少一次完整备份，则无法执行事务日志备份。实际上，如果您的数据库处于完全恢复模式但从未进行过备份，那么它实际上不会在完全恢复模式下工作。数据库将处于自动截断模式，直到执行第一次完全备份。

使用BACKUP命令执行所有数据库备份，完整，日志或其他。该命令接受了许多选项，这些选项在此处记录：http：//msdn.microsoft.com/en-us/library/ms186865.aspx。但是，最基本的，通常是如何使用它，执行磁盘完全备份的命令如下：

BACKUP DATABASE DatabaseNameTO DISK =‘FileLocation DatabaseName.bak‘;

如果这是要执行的第一个备份，则将在指定的目录中创建DatabaseName.bak文件。如果此类文件已存在，则默认行为是将后续备份附加到该文件。要覆盖此行为，并规定应覆盖任何现有文件，我们可以使用INIT选项，如下所示：

BACKUP DATABASE DatabaseNameTO DISK =‘FileLocation DatabaseName.bak‘WITH INIT;

但是，最常见的是，每个后续备份都有一个唯一的名称;更多关于这一点在即将到来的部分，恢复到失败点。

在每次定期（例如每天）完整备份之后，将会有频繁（例如每小时）的日志备份，其基本命令非常相似：

BACKUP LOG DatabaseNameTO DISK =‘FileLocation DatabaseName_Log.bak‘;

存储日志备份
显然，备份的数据和日志文件不应存储在托管实时文件的同一驱动器上。如果该驱动器遭受硬件故障，那么所有副本将与实时文件一起丢失，备份将是徒劳的。这些文件应备份到单独的设备，或备份到本地镜像驱动器。

日志备份的频率
如前面的级别所述，您可能每15分钟或甚至更频繁地进行日志备份。在这种情况下，为了避免恢复大量事务日志文件的需要，您可以选择采用备份方案，其中包含散布有差异备份的完整备份，其中散布着事务日志备份。

实际上，备份方案通常在理想和实际之间，在评估数据丢失的真实风险，公司成本以及降低风险所涉及的成本之间做出妥协。许多非常重要的业务应用程序使用稍微简单但仍然严格的备份方案，可能涉及定期夜间完整备份以及每小时事务日志备份。

日志备份的频率也可以由数据库所处的事务数量决定。对于非常繁忙的数据库，可能需要经常备份以控制日志的大小。

没有简单的方法来计算日志备份的频率。大多数DBA会对日志备份的频率进行最佳估计，然后观察文件的增长特性，然后根据需要调整备份方案，以防止它们变得过大。

日志链以及如何打破它
如上所述，如果没有首先进行至少一次完整备份，则无法执行事务日志备份。为了将数据库恢复到某个时间点，或者在特定日志备份结束时或者在特定日志备份中的某个时间点，必须存在完整的不间断的日志记录链，从第一次日志备份开始在完整（或差异备份）之后，直到故障点。这称为日志链。

有许多方法可以打破日志链，如果这样做，则意味着您只能将数据库恢复到在事件发生之前进行日志备份时才会破坏链。简而言之，如果您关心恢复数据的能力，打破链条并不是一个好主意。打破链条的两种最常见的方法包括：

事务日志备份文件丢失或损坏 - 您只能恢复到上一个??良好的日志备份。日志链将在下一个良好的完整或差异备份时再次启动。
切换到SIMPLE恢复模式 - 如果您从FULL切换到SIMPLE恢复模式，这将打破日志链，因为将启动检查点并且可以立即截断事务日志。当您返回FULL模式时，您需要进行另一次完整备份以重新启动日志链。实际上，在进行完全备份之前，数据库将保持自动截断模式，您将无法备份日志文件。
在SQL Server 2008之前，有一些命令，即BACKUP LOG WITH NO_LOG或BACKUP LOG WITH TRUNCATE_ONLY（它们在功能上等效），当发出时，会强制执行日志文件截断，从而破坏日志链。您不应该在任何版本的SQL Server中发出这些命令，但是我在这里提到它们，因为当他们试图处理“失控的日志文件”时，他们仍然会使用它们，而不了解它对它们的能力的影响。恢复他们的数据库有关更多详细信息，请参阅第8级 - 帮助，我的日志已满。

尾部日志备份
只要您拥有最近的完整备份和完整的日志链，就可以在发生任何故障之前将数据库恢复到最终日志备份结束时存在的状态。但是，假设您按小时，每小时进行事务日志备份，并在下午1:45发生故障。您可能会丢失45分钟的数据;事实上，如果失败是如此灾难性以至于实时交易日志无法恢复，那么这就是您将失去的数据量。

但是，有时即使数据文件不可用，实时事务日志仍然可用，特别是如果事务日志包含在单独的专用驱动器上。如果是这种情况，则应备份实时事务日志，即执行自上次日志备份以来生成的日志记录的最终备份。这将捕获实时日志文件中的剩余日志记录，直至故障点。这称为尾部日志备份，是在开始还原和恢复操作之前应执行的最后一个操作。

尾部日志备份和最少日志记录的操作
如果由于数据库故障导致数据文件不可用，并且日志尾部包含最少日志记录的操作，那么将无法执行尾部日志备份，因为这将需要访问更改的数据扩展区。数据文件。这将在第6级“以批量记录模式管理事务日志”中进行更详细的介绍。

如果要还原的数据库处于联机状态，则会按如下方式备份日志尾部：

BACKUP LOG DatabaseNameTO DISK =‘FileLocation DatabaseName_Log.bak‘WITH NORECOVERY

NORECOVERY选项将数据库置于还原状态，并假定您要执行的下一个操作是RESTORE。如果数据库处于脱机状态且无法启动，您仍应尝试按照上述描述备份日志尾部（尽管可省略NORECOVERY选项，因为不会进行任何事务处理）。

如果您确定日志文件已损坏，则文档建议您作为最后的手段，尝试使用以下命令执行尾部日志备份：

BACKUP LOG DatabaseNameTO DISK =‘FileLocation DatabaseName_Log.bak‘WITH CONTINUE_AFTER_ERROR

如果主数据库和数据文件已损坏，但日志可用，Microsoft建议重建master数据库，然后备份上一个活动日志。但是，这些主题超出了本Stairway的范围，我将向您介绍文档以获取更多详细信息。请参阅http://msdn.microsoft.com/en-us/library/ms190952.aspx。

执行还原和恢复
执行尾部日志备份后，如果可能，下一步是还原上次完全备份（如果适用，则执行差异备份），然后还原完整的日志备份文件序列，包括尾部日志备份。此序列还原操作的基本语法如下：

RESTORE {DATABASE | LOG} DatabaseNameFROM DISK =‘FileLocation FileName.bak‘WITH NORECOVERY;

如果在恢复时省略了WITH NORECOVERY选项，则默认情况下RESTORE命令将继续执行WITH RECOVERY。换句话说，SQL Server将尝试协调数据和日志文件，前滚已完成的事务，然后根据需要回滚未完成的事务。通过指定WITH NORECOVERY，我们指示SQL Server我们正在进行恢复序列，并且在执行任何回滚之前必须前滚更多操作。在还原序列中还原最后一个备份后，可以按如下方式恢复数据库：

RESTORE DATABASE DatabaseName WITH RECOVERY

常见的要求是将数据库还原到其他位置，在这种情况下，您只需将文件作为还原过程的一部分进行移动，如下所述：http：//msdn.microsoft.com/en-us/library/ms190255.aspx。

数据库失败后恢复
以下示例描述了如何恢复数据库以响应故障，从而无法再访问数据库数据文件。

完全恢复到失败点
假设可能由于硬件故障导致数据库故障后可以访问“实时”事务日志，那么理论上应该可以通过使用以下步骤恢复和恢复数据库直到故障点：

备份日志的尾部
恢复最近的完整备份（加上差异，如果适用）
反过来，还原在完全（或差异）备份之后并在故障发生之前完成的每个事务日志备份
恢复尾部日志备份
恢复数据库
联机丛书中的许多示例演示了从“备份集”恢复和恢复，换句话说，是存储所有备份的单个“设备”。实际上，这意味着，备份到磁盘时，备份设备是位于该磁盘上某个位置的单个.bak文件。

因此，例如，清单5.2中所示的简单示例使用由一个完整备份和一个事务日志备份组成的备份集，并显示如何执行完全还原。为了运行此代码，您首先需要重新创建TestDB数据库，然后插入一些示例数据行（为方便起见，执行此操作的脚本，CreateAndPopulateTestDB.sql，包含在此级别的代码下载中） 。您还需要在数据库服务器的本地C：驱动器上创建“备份”目录，或者根据需要修改文件路径。

-- Perform a full backup of the Test database
-- The WITH FORMAT option starts a new backup set
-- Be careful, as it will overwrite any existing sets
-- The full backup becomes the first file in the set
BACKUP DATABASE TestDB
TO DISK = ‘C:BackupsTestDB.bak‘
WITH FORMAT;
GO

-- Perform a transaction log backup of the Test database
-- This is the second file in the set
BACKUP Log TestDB
TO DISK = ‘C:BackupsTestDB.bak‘
GO

-- ....<FAILURE OCCURS HERE>....

-- The RESTORE HEADERONLY command is optional.
-- It simply confirms the files that comprise 
-- the current set
RESTORE HEADERONLY
FROM DISK = ‘C:BackupsTestDB.bak‘
GO

-- Back up the tail of the log to prepare for restore
-- This will become the third file of the bakup set
BACKUP Log TestDB
TO DISK = ‘C:BackupsTestDB.bak‘
WITH NORECOVERY;
GO

-- Restore the full backup
RESTORE DATABASE TestDB
FROM DISK = ‘C:BackupsTestDB.bak‘
WITH FILE=1, NORECOVERY;

-- Apply the transaction log backup
RESTORE LOG TestDB
FROM DISK = ‘C:BackupsTestDB.bak‘
WITH FILE=2, NORECOVERY;

-- Apply the tail log backup
RESTORE LOG TestDB
FROM DISK = ‘C:BackupsTestDB.bak‘
WITH FILE=3, NORECOVERY;

-- Recover the database
RESTORE DATABASE TestDB
WITH RECOVERY;
GO

代码清单5.2：备份到备份集并从中恢复; 不建议

但是，使用备份集似乎是数据库备份到磁带时的遗留问题。 备份到磁盘时，使用此方案是一个坏主意，因为当然，备份文件会很快变大。

实际上，每个完整备份和事务日志备份文件将被单独命名，并且可能标记了备份所用的时间和日期，这种情况更为常见。 例如，大多数第三方备份工具，流行的社区生成脚本以及SSMS中的维护计划向导/设计器都将创建单独的带日期戳的文件，例如AdventureWorks_FULL_20080904_000001.bak。

因此，更常见的备份和还原方案将使用唯一命名的备份，如清单5.3所示。

USE master;
BACKUP DATABASE TestDB
TO DISK =‘C:BackupsTestDB.bak‘
WITH INIT;
GO

-- Perform a transaction log backup of the Test database
BACKUP Log TestDB
TO DISK =‘C:BackupsTestDB_log.bak‘
WITH INIT;
GO

-- ....<FAILURE OCCURS HERE>....

-- Back up the tail of the log to prepare for restore
BACKUP Log TestDB
TO DISK =‘C:BackupsTestDB_taillog.bak‘
WITH NORECOVERY, INIT;
GO

-- Restore the full backup
RESTORE DATABASE TestDB
FROM DISK = ‘C:BackupsTestDB.bak‘
WITH NORECOVERY;

-- Apply the transaction log backup
RESTORE LOG TestDB
FROM DISK = ‘C:BackupsTestDB_log.bak‘
WITH NORECOVERY;

-- Apply the tail log backup
RESTORE LOG TestDB
FROM DISK = ‘C:BackupsTestDB_taillog.bak‘
WITH NORECOVERY;

-- Recover the database
RESTORE DATABASE TestDB
WITH RECOVERY;
GO

代码清单5.3：备份和恢复唯一命名的备份文件

时间点恢复到上次良好日志备份
有时，遗憾的是，可能无法执行完全恢复; 例如，如果由于失败而导致实时事务日志不可用。 在这种情况下，我们需要恢复到最近的日志备份结束。 需要为这种可能性做好准备，即包含事务日志的驱动器出现故障，该事务日志规定了日志备份的频率。 如果每15分钟进行一次备份，则会面临15分钟数据丢失的风险。

想象一下，我们已经执行了清单5.4中所示的备份序列。 为了这个演示，我们覆盖了以前的备份文件，并且备份序列显然比实际中缩短了很多。

-- FULL BACKUP at 2AM
USE master ;
BACKUP DATABASE TestDB
TO DISK = ‘C:BackupsTestDB.bak‘
WITH INIT ;
GO

-- LOG BACKUP 1 at 2.15 AM
USE master ;
BACKUP LOG TestDB
TO DISK = ‘C:BackupsTestDB_log.bak‘
WITH INIT ;
GO

-- LOG BACKUP 2 at 2.30 AM
USE master ;
BACKUP LOG TestDB
TO DISK = ‘C:BackupsTestDB_log2.bak‘
WITH INIT ;
GO

代码清单5.4：一系列简短的日志备份

如果在凌晨2:30之后不久发生灾难性故障，我们可能需要将数据库恢复到日志备份2结束时凌晨2:30的状态。

这个示例中的恢复序列与我们之前在清单5.3中看到的非常相似，但由于尾部备份是不可能的，我们只能恢复到某一点，我们需要使用STOPAT选项 ，如清单5.5所示。

--RESTORE Full backup
RESTORE DATABASE TestDB
FROM DISK = ‘C:BackupsTestDB.bak‘
WITH NORECOVERY;

--RESTORE Log file 1
RESTORE LOG TestDB
FROM DISK = ‘C:BackupsTestDB_log.bak‘
WITH NORECOVERY, STOPAT = ‘Jan 01, 2020 12:00 AM‘;

--RESTORE Log file 2
RESTORE LOG TestDB
FROM DISK = ‘C:BackupsTestDB_Log2.bak‘
WITH NORECOVERY, STOPAT = ‘Jan 01, 2020 12:00 AM‘;

--Recover the database
RESTORE DATABASE TestDB
WITH RECOVERY;
GO

代码清单5.5：使用STOPAT恢复到某个时间点

由于我们将来指定了STOPAT时间，因此该代码将向前滚动所有已完成的事务，直到第二个事务日志结束。

或者，可以指定STOPAT时间，该时间落在特定日志文件中记录的事务的时间范围内。在这种情况下，数据库将在指定的时间恢复到上次提交的事务。当您知道要还原到什么时间但不确切知道该时间包含哪些日志备份时，这非常有用。

还可以恢复到特定标记的事务。例如，当您需要将某个应用程序访问的多个数据库还原到逻辑上一致的点时，这非常有用。这里不再讨论这个主题，但你可以在联机丛书（http://msdn.microsoft.com/en-us/library/ms187014.aspx）上找到更多信息，Mladen Prajdic在这里提供了一个很好的例子：http ：//weblogs.sqlteam.com/mladenp/archive/2010/10/20/sql-server-transaction-marks-restoring-multiple-databases-to-a-common.aspx。

在“不良交易”之后恢复
在任何数据库故障的上下文之外，可能需要还原数据库备份和事务日志，以便在错误的数据修改之前将数据库返回到特定时间点，例如删除或截断表。

您对这种情况的回应将取决于问题的性质。如果可能，您可以断开所有用户与数据库的连接（在通知他们之后），并评估刚刚发生的事情的影响。在某些情况下，您可能需要估计问题发生的时间，然后使用时间点恢复完全恢复数据库和日志。恢复完成后，您必须通知用户某些交易可能已丢失，并请求原谅。

当然，通常您无法以这种方式中断正常的业务操作，以修复意外的数据丢失。由于实时数据库仍在运行并正在被访问，因此您可以尝试在STANDBY模式下恢复数据库的备份。这允许恢复进一步的日志备份，但与使用NORECOVERY时不同，数据库仍然可读。恢复方案可能如下所示：

在STANDBY模式下，与实时数据库一起恢复数据库的备份
将日志向前滚动到错误事务发生之前的点，数据丢失。
将丢失的数据复制到实时数据库并删除已还原的副本
当然，这个过程不一定是直截了当的，而且可能非常耗时。除非您购买了专门的日志读取工具，并且可以直接查询日志备份，否则滚动日志可能意味着一系列艰苦的步骤，包括恢复日志，检查数据，进一步恢复等等，直到您已经确定了坏交易发生的确切位置。第3步也很困难，因为您将数据引入实时系统，这不一定与数据库的当前状态一致，因此可能存在引用完整性问题。

让我们看一下实现上面步骤1和2的示例。首先，让我们从头开始，运行CreateAndPopulateTestDB.sql脚本来重新创建TestDB数据库，并将10行测试数据插入到新的LogTest表中。在代码清单5.6中，我们只是进行完整的数据库备份（覆盖任何以前的备份文件）。如果您尚未创建“备份”目录，则需要创建“备份”目录，或者根据需要调整路径。

-- full backup of the database
BACKUP DATABASE TestDB
TO DISK =‘C:BackupsTestDB.bak‘
WITH INIT;
GO

代码清单5.6：TestDB的完全备份

然后，我们将一行新数据插入LogTest表。

USE TestDB
GO
INSERT INTO [TestDB].[dbo].[LogTest]
           ([SomeInt]
           ,[SomeLetters2])
     VALUES
           (66666,
           ‘ST‘)
           
SELECT * FROM dbo.LogTest

代码清单5.7：在TestDB中插入第11行

所以现在我们在LogTest表中有一个包含11行的实时TestDB数据库，以及一个包含10行的备份版本。 现在让我们在日志备份中捕获其他修改，如清单5.8所示。

USE master
GO
BACKUP Log TestDB
TO DISK =‘C:BackupsTestDB_log.bak‘
WITH INIT;
GO

代码清单5.8：TestDB的日志备份

现在，我们将模拟一个错误的“坏事务”，只需删除LogTest表，然后我们进行最终的日志备份。

USE TestDB
GO
DROP TABLE dbo.LogTest ;

USE master
GO
BACKUP Log TestDB
TO DISK =‘C:BackupsTestDB_log2.bak‘
WITH INIT;
GO

清单5.9：坏事件！

为了在不中断正常业务操作的情况下尝试检索丢失的数据，我们将以STANDBY模式恢复TestDB数据库的副本。 备用数据库的数据和日志文件（称为ANewTestDB）将移至“备用”目录（您需要事先创建此目录）。

-- restore a copy of the TestDB database, called
-- ANewTestDB, in STANDBY mode
USE master ;
GO
RESTORE DATABASE ANewTestDB
   FROM DISK =‘C:BackupsTestDB.bak‘
   WITH STANDBY=‘C:BackupsANEWTestDB.bak‘,
   MOVE ‘TestDB_dat‘ TO ‘C:StandbyANewTestDB.mdf‘, 
   MOVE ‘TestDB_log‘ TO ‘C:StandbyANewTestDB.ldf‘
GO

代码清单5.10：在STANDBY模式下恢复TestDB的副本

我们现在有一个名为ANewTestDB的新数据库，它处于“Standby / Read-Only”模式，如图5.1所示。

图5.1：备用数据库

对ANewTestDB数据库中的LogTest表的查询将显示10行。 但是，我们希望让桌子恢复到错误丢弃之前的状态。 因此，下一步是执行将日志备份还原到备用数据库。

USE master
GO
RESTORE LOG ANewTestDB
FROM DISK = ‘C:BackupsTestDB_log.bak‘
   WITH STANDBY=‘C:BackupsANewTestDB_log.bak‘

代码清单5.11：在STANDBY模式下将日志备份恢复到ANewTestDB数据库

此时，针对ANewTestDB的查询显示11行，现在我们可以准备将??该数据复制回实时数据库。如果我们更进一步并恢复了第二个日志备份，我们就会发现我们已经走得太远了，备用数据库中的表也会丢失。

执行备用还原的另一种方法是考虑使用第三方工具，例如Red Gate的SQL Virtual Restore，它提供了一种将备份挂载为实时，功能齐全的数据库而无需物理还原的方法。

无论DBA是否喜欢，开发人员通常都可以访问生产数据库来执行临时数据加载和更改。 DBA和开发人员共同负责确保这些过程顺利进行，因此不会导致需要采取刚才所述行为的问题。我们稍后将在第6级 - 处理批量操作中回到此主题。

当然，所需修复行动的确切性质取决于不良交易的性质。如果一张桌子被“意外掉落”，那么你很可能会沿着RESTORE WITH STANDBY路线前进。在其他时候，您可以简单地创建一个脚本来“反转”流氓修改。

如果损坏只影响单个列或有限数量的行，那么可以使用SQL Data Compare之类的工具，它可以直接与备份文件进行比较，并且可以进行行级恢复。 。

或者，如果您运行SQL Server 2005（或更高版本）Enterprise Edition，并且可以使用最近的数据库快照，则可以对快照运行查询，以便在查看数据库快照时查看数据，然后编写UPDATE或INSERT命令将数据从数据库快照提取到实时源数据库。

最后，作为最后的手段，专门的日志阅读器工具可以帮助您消除事务的影响，尽管我不知道SQL Server 2005及更高版本中的任何可靠工作。

摘要
在本级别中，我们已经介绍了备份和恢复以完全恢复模式运行的数据库的日志文件的基础知识，这将是许多生产数据库的标准。

对于大多数DBA来说，执行时间点恢复的需求是一种罕见的事件，但它是其中一项任务，如果有必要，完成并完成它是绝对关键的; DBA的声誉取决于它。

在损坏，驱动器故障等情况下，如果幸运的话，时间点恢复可能涉及备份事务日志的尾部并恢复到故障点的权限。如果事务日志不可用，或者您正在恢复以便在发生“错误事务”之前恢复到某个时间点，则情况变得更加棘手，但希望此步骤中涉及的一些技术将有所帮助。

资源：
TransactionLogStairway_Level5_Code.zip
本文是SQL Server Stairway中事务日志管理的阶梯的一部分

原文作者：Tony Davis, 2012/01/27

原文链接：http://www.sqlservercentral.com/articles/Stairway+Series/73785/