SQLServer中事务日志管理的阶梯，第5级：在完全恢复模式下管理日志
By Tony Davis, 2012/01/27
系列
本文是楼梯系列的一部分：SQL Server中事务日志管理的阶梯
当事件进展顺利时，没有必要特别注意事务日志的作用或它是如何工作的。你只需要保证每个数据库都有正确的备份。当时间出错时，对事务日志的理解对于采取纠正措施是很重要的，特别是当需要对数据库进行实时恢复时。T型 ONNDAVIS给出了每个DBA都应该知道的正确的细节级别。
在这个级别上，我们将回顾在完全恢复模式下工作时为什么和如何进行日志备份，以及如何使用这些日志备份文件与完整的数据库一起执行数据库还原。在故障发生之前，完全恢复模式支持数据库恢复到可用日志备份中的任何时间点，并且假设可以进行尾日志备份，直到上次提交的传输时间。
什么会被记录？
在完全恢复模式下，所有操作都会被完全记录下来。对于INSERT、UPDATE和DELETE操作，这意味着对于被修改的每一行，都会有一个日志记录描述tr的ID。 执行语句的反动作，当事务开始和结束时，哪些页面被更改，所做的数据更改，等等。
在完全恢复模式下工作时，仍然可以将SELECT、BULKINSERT和CREATEINDEX最少登录的操作完全记录的，但其执行方式略有不同。受影响的行不是单独记录的；相反，只有数据库页在填充时才会被记录。这减少了无意中听到的此类操作的日志记录，同时确保仍然存在所有相同的信息，这些信息都是执行回滚、重做和时间点还原所需的。KalenDelaney发表了一些关于记录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)
操作，包括完整恢复模式和大容量日志恢复模式。在BULK_LOGLOG模式下工作时，最低日志记录操作的日志记录的差异将在第6级-Manag中详细讨论。 启用“大容量日志恢复模式”。
为什么备份事务日志？
在完全恢复模式下，只有日志备份才能导致日志的截断。因此，事务日志将保存自上次转换以来执行的事务的完整记录。 行动日志已备份。由于所有操作都是完全记录的，日志文件在繁忙的系统中可以非常大、非常快地增长。
因此，在完全恢复模式下工作时，除了完全备份和(可选)差异备份之外，还必须执行常规事务日志备份。许多新手或兼职 EDBA对其数据库执行完全备份，但不执行事务日志备份。因此，事务日志不会被截断，它会不断增长，直到它正在运行的驱动器。 磁盘空间不足，导致SQLServer停止工作。
日志的截断将在日志备份后立即发生，前提是自上一次备份以来就发生了检查点，而且没有其他因素延迟截断，例如dat。 备份或还原操作。对于可能延迟可恢复VLFS截断的因素的完整列表，以及保持大量日志活动的因素，否则不需要这样做。例如长期运行的未提交事务或数据库镜像或复制进程，请参阅
http://msdn.microsoft.com/en-gb/library/ms345414.aspx.
仅复制事务日志的备份
仅复制事务日志备份不会截断事务日志。ACOPY_Only日志备份与常规日志备份方案“独立”存在；它不会破坏日志备份链。
简而言之，事务日志备份具有双重功能，即允许恢复和恢复到以前的时间点，以及控制事务日志的大小。可能是最普遍的事务日志相关问题的原因是在完全恢复模式下工作，根本没有进行日志备份，或者没有频繁地进行日志备份以控制事务日志文件的大小。
如果你不确定给定数据库上是否正在进行事务日志备份，则可以使用类似于清单5.1所示。
1 USE msdb ;SELECT backup_set_id , 2 backup_start_date , 3 backup_finish_date , 4 backup_size , 5 recovery_model , 6 [type]FROM dbo.backupsetWHERE database_name = 'TestDB'
清单5.1：是否进行日志备份？
在类型列中，D表示数据库备份，L表示日志备份，I表示差异备份。
注意，由于可以在不影响备份和还原行为的情况下操作该回溯表中的数据，因此你可能希望通过queryingsys.database_re验证从该查询中得到的结果。 COPHOP_STATUS用于查看LAST_LOG_BACKUP_LSN的值(请参见清单3.5)，或sys.database表查看log_重用_WAIT_desc的值(如果需要备份，则返回LOG_BACKUP)。
如何备份事务日志
如前面所述，如果不先进行至少一次完全备份，就不可能执行事务日志备份。实际上，如果你的数据库处于完全恢复模式，一旦备份，那么它实际上不会在完全恢复模式下工作。在执行第一次完全备份之前，数据库将处于自动截断模式.
所有数据库备份，包括完整备份、日志备份或其他备份，都是使用BACKUP命令执行的。该命令接受许多选项，这些选项记录在这里：http://msdn.microsoft.com/en-us/library/ms186865.aspx.但是，在其中最基本的(通常是如何使用它)，执行磁盘完整备份的命令如下所示：
BACKUP DATABASE DatabaseNameTO DISK ='FileLocationDatabaseName.bak';
如果这是要执行的第一个备份，则将在指定目录中创建DatabaseName.bak文件。如果这样的文件已经存在，则默认行为是追加后续文件。 备份到那个文件。若要重写此行为，并规定任何现有文件都应被覆盖，我们可以使用INIT选项，如下所示：
BACKUP DATABASE DatabaseNameTO DISK ='FileLocationDatabaseName.bak'WITH INIT;
但是，最常见的情况是，每个后续备份都有一个唯一的名称；稍后将在“恢复到失败点”一节中对此进行详细介绍。
在每次定期(例如每天)完全备份之后，将有频繁(例如每小时)的日志备份，其基本命令非常相似：
BACKUP LOG DatabaseNameTO DISK ='FileLocationDatabaseName_Log.bak';
存储日志备份
显然，备份的数据和日志文件不应该存储在承载活动文件的同一驱动器上。如果该驱动器硬件出现故障，那么你的所有副本都将随着现场的运行而丢失。文件和备份都是徒劳的。文件应备份到单独的设备，或备份到本地镜像驱动器。
存储日志备份
显然，备份的数据和日志文件不应该存储在承载活动文件的同一驱动器上。如果该驱动器硬件出现故障，那么您的所有副本都将随着现场的运行而丢失。 文件和备份都是徒劳的。文件应备份到单独的设备，或备份到本地镜像驱动器。
日志备份频率
如前面所述，你可能每15分钟进行一次日志备份，或者甚至更频繁地进行日志备份。在这种情况下，为了避免需要恢复大量的事务日志， ES，你可以选择采用一种备份方案，其中包括带有差异备份的完整备份，以及带有事务日志备份的备份。
在现实中，备份方案通常更多地是在理想和实际之间，在评估数据丢失的真实风险，以及评估公司的成本和成本之间的折衷。在降低风险方面下功夫。许多非常重要的业务应用程序使用了一些简单但严格的备份方案，可能涉及到每晚定期的充分备份或每小时事务日志备份。
日志备份的频率也可能取决于数据库所受事务的数量。对于非常繁忙的数据库，可能需要频繁备份以控制日志的大小。
没有一种简单的方法可以计算日志备份的频率。大多数DBA将对应该进行日志备份的频率进行最佳估计，然后观察文件的增长特征。 然后根据需要调整备份方案，以防止它们过大。
日志链及其破坏方法
如前所述，如果不首先进行至少一次完全备份，就不可能执行事务日志备份。为了将数据库恢复到某个时间点，要么恢复到特定日志的末尾。 备份或某个特定日志备份中的某个时间点，必须存在完整、完整的日志记录链，从完整备份(或差异备份)后的第一次日志备份到 失败的关键。这就是所谓的日志链。
打破日志链的方法有很多种，如果这样做，就意味着只能将数据库恢复到在中断链的事件发生之前进行日志备份的时间。简而言之，如果你关心恢复数据的能力，那么打破链并不是一个好主意。打破链条的两种最常见的方式包括：
事务日志备份文件的丢失或损坏-你只能恢复到上次良好的日志备份。日志链将在下一个良好的完整或差异返回时再次启动。
切换到简单恢复模式——如果你从完全恢复模式切换到简单恢复模式，这将破坏日志链，因为检查点将被触发，事务日志可以立即被TRUN处理。如果返回完全模式，则需要进行另一次完全备份才能重新启动日志链。实际上，在进行完全备份之前，数据库将保持自动截断模式。 你就不能备份日志文件了。
在SQLServer 2008之前，有两个命令，即BACKUP LOG WITH NO_LOGor BACKUP LOG WITH TRUNCATE_ONLY(它们在功能上等效)，在发出命令时，将强制日志文件截断 打破了日志链。你不应该在SQLServer的任何版本中发出这些命令，但是我在这里提到它们，因为在试图处理“失控的日志文件”时，不了解它对恢复数据库能力的影响，仍然会被粗心大意的人使用。请参阅第8级-帮助，我的日志已满，以获得更多细节。
尾日志备份
只要你有最近的完整备份和完整的日志链，你就可以在任何操作失败之前将数据库恢复到它在最终日志备份结束时所处的状态。然而，假定你每小时进行事务日志备份，并在下午1：45发生故障。你可能会损失45分钟的数据，事实上，如果故障是灾难性的话活动事务日志是不可检索的，那么这就是你将丢失的数据量。
但是，有时即使数据文件不可用，也仍然可以使用活动事务日志，特别是如果事务日志包含在单独的专用驱动器中。如果是这样的话， 你应该备份活动事务日志，即对上次日志备份后生成的日志记录执行最终备份。这将捕获活动日志文件中的其余日志记录，最多可捕获到失败的关键。这被称为尾日志备份，是在开始恢复和恢复操作之前应该执行的最后一个操作。
尾日志备份和最少日志记录的操作
如果数据文件由于数据库故障而不可用，并且日志尾包含最少日志记录的操作，则不可能执行尾日志备份，因为要求访问数据文件中更改的数据区段。这将在第6级“大容量日志模式下的事务日志管理”中详细介绍。
如果希望还原的数据库处于联机状态，则将按以下方式备份日志尾：
BACKUP LOG DatabaseNameTO DISK ='FileLocationDatabaseName_Log.bak'WITH NORECOVERY
NORECOVERY选项将数据库置于还原状态，并假定你希望执行的下一个操作是还原。如果数据库离线且无法启动，则仍应尝试备份刚才描述的日志尾(因为没有事务正在进行，尽管NORECOVERY选项可以省略)。
如果你确信日志文件已损坏，则文档建议，作为最后手段，您可以尝试使用以下方法进行尾日志备份：
BACKUP LOG DatabaseNameTO DISK ='FileLocationDatabaseName_Log.bak'WITH CONTINUE_AFTER_ERROR
如果主数据库和数据文件损坏，但日志可用，Microsoft建议重新构建主数据库，然后备份最后一个活动日志。然而，这些主题是在这个阶梯的范围，我参考你的文件，以获得更多的细节。见http://msdn.microsoft.com/en-us/library/ms190952.aspx.
执行恢复和恢复
在执行了尾日志备份之后，如果可能的话，下一步是恢复最后一个完整备份(如果适当的话，接着是差异备份)，然后恢复日志备份的完整序列。包括尾部日志备份。此还原操作序列的基本语法如下：
RESTORE {DATABASE | LOG} DatabaseNameFROM DISK ='FileLocationFileName.bak'WITH NORECOVERY;
如果还原时省略了WITH NORECOVERY选项，那么默认情况下RESTORE命令将继续恢复。换句话说，SQLServer将尝试协调数据和日志文件，滚动转发已完成的事务，然后根据需要回滚未完成的事务。通过使用NORECOVERY指定，我们将指示SQLServer输入还原序列和必须前滚更多操作，然后才能执行回滚。还原序列中的最后一个备份之后，数据库可以恢复如下：
RESTORE DATABASE DatabaseName WITH RECOVERY
一个常见的要求是将数据库还原到不同的位置，在这种情况下，你可以简单地将文件作为还原过程的一部分移动，如下所述：
http://msdn.microsoft.com/en-us/library/ms190255.aspx.
数据库故障后恢复
下面的示例描述如何在发生故障时恢复数据库，从而无法再访问数据库数据文件。
完全恢复到故障点
假设“活动”事务日志可以在数据库故障(可能是由硬件故障引起的)之后到达，那么理论上应该可以恢复和恢复数据库权限。 通过使用以下步骤，直到失败为止：
1.备份日志的尾
2.恢复最近的完全备份(如果适用，再加上差异)
3.依次还原在完整(或差异)备份之后并在故障发生前完成的每个事务日志备份。
4.恢复尾日志备份
5.恢复数据库
联机丛书中的许多示例演示了从“备份集”恢复和恢复，换句话说，是存储所有备份的单个“设备”。实际上，这意味着备份到磁盘时，备份设备是位于磁盘上某个位置的单个.bak文件。
因此，例如，清单5.2中所示的简单示例使用了由一个完整备份和一个事务日志备份组成的备份集，并演示了如何执行完全恢复。为了运行这个 代码，首先需要重新创建TestDB数据库，然后插入几行数据示例(为方便起见，用于此操作的脚本CreateAndPopulateTestDB.sql包含在代码中）。你还需要在数据库服务器的本地C：驱动器上创建一个“备份”目录，或者修改文件路径。
1 -- 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 setBACKUP DATABASE TestDBTO DISK = 'C:BackupsTestDB.bak'WITH FORMAT; 2 GO 3 -- Perform a transaction log backup of the Test database-- This is the second file in the setBACKUP Log TestDBTO DISK = 'C:BackupsTestDB.bak' 4 GO 5 -- ....<FAILURE OCCURS HERE>.... 6 -- The RESTORE HEADERONLY command is optional.-- It simply confirms the files that comprise -- the current setRESTORE HEADERONLYFROM DISK = 'C:BackupsTestDB.bak' 7 GO 8 -- Back up the tail of the log to prepare for restore-- This will become the third file of the bakup setBACKUP Log TestDBTO DISK = 'C:BackupsTestDB.bak'WITH NORECOVERY; 9 GO 10 -- Restore the full backupRESTORE DATABASE TestDBFROM DISK = 'C:BackupsTestDB.bak'WITH FILE=1, NORECOVERY; 11 -- Apply the transaction log backupRESTORE LOG TestDBFROM DISK = 'C:BackupsTestDB.bak'WITH FILE=2, NORECOVERY; 12 -- Apply the tail log backupRESTORE LOG TestDBFROM DISK = 'C:BackupsTestDB.bak'WITH FILE=3, NORECOVERY; 13 -- Recover the databaseRESTORE DATABASE TestDBWITH RECOVERY; 14 GO
清单5.2：备份到备份集并从中恢复；不建议
但是，使用备份集似乎是数据库备份到磁带时的遗物。当备份到磁盘时，使用此方案是个坏主意，因为当然备份文件会长得很大。
在实践中，更常见的做法是，每个完整备份和事务日志备份文件都将单独命名，并可能加上备份的时间和日期。例如 ，大多数第三方备份工具，流行的社区生成脚本，加上sms中的维护计划向导/设计器，都将创建单独的日期标记文件，例如Adventureworks_Full_20080904_000001.bak.
因此，更常见的备份和还原方案将使用唯一命名的备份，如清单5.3所示。
1 USE master;BACKUP DATABASE TestDBTO DISK ='C:BackupsTestDB.bak'WITH INIT; 2 GO 3 -- Perform a transaction log backup of the Test databaseBACKUP Log TestDBTO DISK ='C:BackupsTestDB_log.bak'WITH INIT; 4 GO 5 -- ....<FAILURE OCCURS HERE>.... 6 -- Back up the tail of the log to prepare for restoreBACKUP Log TestDBTO DISK ='C:BackupsTestDB_taillog.bak'WITH NORECOVERY, INIT; 7 GO 8 -- Restore the full backupRESTORE DATABASE TestDBFROM DISK = 'C:BackupsTestDB.bak'WITH NORECOVERY; 9 -- Apply the transaction log backupRESTORE LOG TestDBFROM DISK = 'C:BackupsTestDB_log.bak'WITH NORECOVERY; 10 -- Apply the tail log backupRESTORE LOG TestDBFROM DISK = 'C:BackupsTestDB_taillog.bak'WITH NORECOVERY; 11 -- Recover the databaseRESTORE DATABASE TestDBWITH RECOVERY; 12 GO
清单5.3：备份和恢复唯一名称的备份文件
时间点恢复到最后一个完好的日志备份
有时，不幸的是，可能无法执行完全恢复；例如，如果由于故障而无法使用活动事务日志。在这种情况下，我们需要恢复到最近的日志备份结束。需要为这种情况做好准备，即包含事务日志的驱动器出现故障，这决定了日志备份的频率。 如果你每15分钟进行一次备份，那么你将面临15分钟数据丢失的风险。
假设我们执行了清单5.4所示的备份序列。为了这个演示，我们正在覆盖以前的备份文件，而且备份序列显然大大缩短了。
1 -- FULL BACKUP at 2AMUSE master ;BACKUP DATABASE TestDBTO DISK = 'C:BackupsTestDB.bak'WITH INIT ; 2 GO 3 -- LOG BACKUP 1 at 2.15 AMUSE master ;BACKUP LOG TestDBTO DISK = 'C:BackupsTestDB_log.bak'WITH INIT ; 4 GO 5 -- LOG BACKUP 2 at 2.30 AMUSE master ;BACKUP LOG TestDBTO DISK = 'C:BackupsTestDB_log2.bak'WITH INIT ; 6 GO
清单5.4：一系列简短的日志备份
如果凌晨2：30后不久发生灾难性故障，我们可能需要在凌晨2：30将数据库恢复到日志备份2结束时的状态。
此示例中的恢复序列与我们前面在清单5.3中看到的非常相似，但是由于尾备份是不可能的，而且我们只能恢复到某个点，所以需要使用STOPAT选项，如清单5.5所示。
1 --RESTORE Full backupRESTORE DATABASE TestDBFROM DISK = 'C:BackupsTestDB.bak'WITH NORECOVERY; 2 --RESTORE Log file 1RESTORE LOG TestDBFROM DISK = 'C:BackupsTestDB_log.bak'WITH NORECOVERY, STOPAT = 'Jan 01, 2020 12:00 AM'; 3 --RESTORE Log file 2RESTORE LOG TestDBFROM DISK = 'C:BackupsTestDB_Log2.bak'WITH NORECOVERY, STOPAT = 'Jan 01, 2020 12:00 AM'; 4 --Recover the databaseRESTORE DATABASE TestDBWITH RECOVERY; 5 GO
清单5.5：使用STOPAT恢复到某个时间点
由于我们在未来指定了STOPAT时间，此代码将所有已完成的事务前滚到第二个事务日志的末尾。
或者，可以指定一个STOPAT时间，该时间位于特定日志文件中记录的事务的时间范围内。在这种情况下，数据库将恢复到最后一个。 在指定的时间提交事务。当你知道要还原到什么时候，但不知道日志备份包含了什么时间时，这是非常有用的。
还可以恢复到特定的标记事务。例如，当需要将某个应用程序访问的多个数据库恢复到逻辑一致性时，这是非常有用的。本主题在这里不作进一步讨论，但你可以在联机丛书(http://msdn.microsoft.com/en-us/library/ms187014.aspx)上找到更多信息，而MladandPrajdic提供了一个很好的示例。 在这里：
http://weblogs.sqlteam.com/mladenp/archive/2010/10/20/sql-server-transaction-marks-restoring-multiple-databases-to-a-common.aspx.
在“受损的事务”之后恢复
在任何数据库故障的上下文之外，可能需要还原数据库备份和事务日志，以便在错误之前将数据库返回到特定的时间点。 进行了单独的数据修改，例如删除或截断表。
你对这种情况的反应将取决于问题的性质。如果可能，你可以断开所有用户与数据库的连接(在通知他们之后)，并评估刚刚发生的事。在某些情况下，你可能需要估计问题发生的时间，然后使用时间恢复点对数据库和日志进行完全恢复。一旦恢复完成，哟 您必须通知用户某些事务可能已经丢失，并请求原谅。
当然，通常你将无法以这种方式中断正常的业务操作，以修复意外的数据丢失。由于活动数据库仍在运行并被访问，所以你可以尝试在备用模式下还原数据库的备份。这允许还原进一步的日志备份，但与使用NORECOVERY不同的是，数据库仍然是可读的。恢复计划可能会好的，如下所示：
1.在备用模式下，在活动数据库旁边还原数据库的备份
2.将日志前滚到错误事务发生之前的点，数据丢失。
3.将丢失的数据复制到活动数据库，并删除还原的副本。
当然，这个过程并不是简单明了的，而且可能很费时。除非你已经购买了专门的日志读取工具，并且可以直接查询日志备份，否则，回滚向前的日志可能意味着一系列艰苦的步骤，包括恢复日志、检查数据、进一步恢复等等，直到你确定了错误事务的确切位置。步骤3也可能很困难，因为你将把数据导入到活动系统中，这些数据不一定与数据库的当前状态相一致，因此可能存在引用和完整性问题。
让我们看一下实现上述步骤1和2的示例。首先，让我们从头开始，运行CreateAndPopulateTestDB.sql脚本重新创建TestDB数据库和将10行测试数据放入新的LogTest表。在清单5.6中，我们只需执行一个完整的数据库备份(覆盖以前的任何备份文件)。如果没有备份，则需要创建“备份”目录，或适当调整路径。
1 -- full backup of the databaseBACKUP DATABASE TestDBTO DISK ='C:BackupsTestDB.bak'WITH INIT; 2 GO
清单5.6：TestDB的完全备份
然后，我们将新的一行数据插入到LogTest表中。
1 USE TestDB 2 GOINSERT INTO [TestDB].[dbo].[LogTest] 3 ([SomeInt] 4 ,[SomeLetters2]) 5 VALUES 6 (66666, 7 'ST') 8 SELECT * FROM dbo.LogTest
清单5.7：将第11行插入TestDB
现在，我们有了一个在LogTest表中有11行的动态TestDB数据库，以及一个有10行的备份版本。现在让我们捕获日志备份中的其他修改，如清单5.8所示。
1 USE master 2 GOBACKUP Log TestDBTO DISK ='C:BackupsTestDB_log.bak'WITH INIT; 3 GO
清单5.8：TestDB的日志备份
现在，我们将模拟一个错误的“坏事务”，只需删除LogTesttable，然后进行最后的日志备份。
1 USE TestDB 2 GODROP TABLE dbo.LogTest ; 3 USE master 4 GOBACKUP Log TestDBTO DISK ='C:BackupsTestDB_log2.bak'WITH INIT; 5 GO
清单5.9：灾难！
为了尝试检索丢失的数据，在不中断正常业务操作的情况下，我们将在备用模式下恢复TestDB数据库的副本。待机的数据和日志文件。数据库，称为ANewTestDB，被移动到一个“备用”目录(你需要预先创建这个目录)。
1 -- restore a copy of the TestDB database, called-- ANewTestDB, in STANDBY modeUSE master ; 2 GORESTORE DATABASE ANewTestDB 3 FROM DISK ='C:BackupsTestDB.bak' 4 WITH STANDBY='C:BackupsANEWTestDB.bak', 5 MOVE 'TestDB_dat' TO 'C:StandbyANewTestDB.mdf', 6 MOVE 'TestDB_log' TO 'C:StandbyANewTestDB.ldf' 7 GO
清单5.10：在备用模式下还原TestDB的副本
我们现在有了一个名为ANewTestDB的新数据库，它处于“备用/只读”模式，如图5.1所示。
图5.1：备用数据库
对ANewTestDB数据库中的LogTest表的查询将显示10行。但是，我们希望将表恢复到它被错误丢弃之前的状态。然后，下一步是对备用数据库执行日志备份。
1 USE master 2 GORESTORE LOG ANewTestDBFROM DISK = 'C:BackupsTestDB_log.bak' 3 WITH STANDBY='C:BackupsANewTestDB_log.bak'
清单5.11：在备用模式下将日志备份还原到ANewTestDB数据库
此时，对ANewTestDB的查询显示了11行，我们现在可以将该数据复制回活动数据库。如果我们再往前走一步，恢复第二个日志备份，我们将 意识到我们走得太远了，待机数据库中的表也会丢失。
备用还原的另一种方法是考虑使用第三方工具，例如RedGate的SQL虚拟还原，它提供了一种将备份挂载为实时的、功能齐全的数据库的方法，没有物理恢复。
无论DBA喜欢与否，开发人员通常都可以访问生产数据库来执行临时数据加载和更改。DBA和开发人员的共同责任是确保 SES进展顺利，因此不会引起需要执行刚才描述的那种操作的问题。在第6级中，我们将回到这个主题-处理批量操作。
当然，所需赔偿行动的确切性质取决于不良交易的性质。如果一张桌子被“不小心掉了”，那么你很可能会沿着 待命路线走下去。在其他时候，你可以简单地创建一个脚本来“反转”恶意修改。
如果损坏只影响单个列或有限的行数，则可以选择使用sql数据比较等工具，该工具可以直接与备份文件进行比较，并可以进行级还原。
或者，如果你运行SQLServer 2005(或更高版本)EnterpriseEdition，并且有了最近的数据库快照，你可能可以对快照运行一个查询来检索数据查看获取数据库快照的时间，然后编写一个UPDATE或INSERT命令，将数据从数据库快照中提取到活动的源数据库中。
最后，作为最后手段，专门的日志读取器工具可以帮助你逆转事务的影响，尽管我不知道在SQLServer 2005和更高版本中有任何可靠工作。
总结
在这个级别上，我们已经介绍了备份和恢复在完全恢复模式下运行的数据库的日志文件的基本知识，这将是许多生产数据库的规范。
对于大多数DBA来说，需要执行实时恢复是一个罕见的事件，但这是这样的任务之一，如果有必要的话，完成并做好它是绝对关键的：DBA的计算取决于它。
在出现损坏、驱动器故障等情况下，如果幸运的话，实时恢复可能需要备份事务日志的尾部，并恢复到故障点的权利。如果 事务日志不可用，或者如果你要恢复到“受损的事务”发生之前的某个时间点，则情况会变得更棘手，但希望这一步中所涉及的细节将有所帮助。
资源：
TransactionLogStairway_Level5_Code.zip
本文是SQL Server楼梯中事务日志管理的一部分。