来源：http://www.sqlservercentral.com/articles/Stairway+Series/73785/
作者：Tony Davis, 2012/01/27
翻译：刘琼滨、谢雪妮、许雅莉、赖慧芳
译文：
该系列
本文是楼梯系列的一部分:SQL Server中的事务日志管理的阶梯
当事情进展顺利时，没有必要特别注意事务日志的作用或它是如何工作的。您只需要确信每个数据库都有正确的备份机制。当事情出错时，对事务日志的理解对于采取纠正措施非常重要，特别是当需要一个时间点的数据库恢复时！Tony Davis给出了每个DBA都应该知道的正确的细节。
在这个级别上，我们将回顾在完全恢复模式下工作的原因和如何使用日志备份，以及如何使用这些日志备份文件执行数据库恢复，并结合完整的数据库备份。完全恢复模式支持在可用的日志备份中对任何时间点进行数据库恢复，并假定可以在发生故障之前进行尾日志备份，直到最后一次提交事务的时间。
什么记录?
在完全恢复模式下，所有操作都被完全记录下来。对于插入、更新和删除操作，这意味着对于每一个被修改的行，都将有一个日志记录来描述执行语句的事务的ID，当事务开始和结束时，哪些页面被更改，所做的数据更改，等等。
可以进行最低记录的操作，批量插入并创建引索，当在完全恢复模式下工作时，仍然完全被记录下来，但是它的工作方式略有不同。受这些操作影响的行没有单独记录;相反，只有数据库页面会被记录，因为它们会被填满。这减少了对此类操作的记录，同时确保仍然存在执行回滚、重做和点时间恢复所需的所有相同信息。Kalen德莱尼发表了一些调查记录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_LOGGED恢复模式。在批量登录模式下工作的日志记录的差异在第6级中更详细地讨论了——在批量登录的恢复模式中管理日志。
为什么要备份事务日志?
在完全恢复模式下，只有一个日志备份可以导致日志的截断。因此，事务日志将保存自上次事务日志备份以来执行的事务的完整且完整的记录。由于所有操作都是完全日志记录的，所以日志文件在繁忙的系统中可以非常快速地增长。
因此，当在完全恢复模式下工作时，除了完全备份和可选的差异备份之外，执行常规事务日志备份是非常重要的。许多新手或兼职dba在他们的数据库上执行完整的备份，但是他们不执行事务日志备份。因此，事务日志不会被截断，它会不断增长，直到磁盘空间耗尽，导致SQL服务器停止工作。
一旦日志备份被执行，日志的截断就会发生，假设在之前的备份之后发生了一个检查点，并且没有其他的因素在延迟截断，比如数据备份或恢复操作。完整列表的因素,可能会推迟恢复的甚低频截断,以及因素保持日志活跃的大片地区,否则不会需要,如一个流氓,长期未提交的事务或数据库镜像或复制流程,参见:http://msdn.microsoft.com/en-gb/library/ms345414.aspx。
对事务日志的复制备份
只对事务日志进行复制的备份不会截断事务日志。一个只复制日志备份的日志备份是“独立”的;它不会破坏日志备份链。
简而言之，事务日志备份执行双重目的，允许恢复和恢复到以前的时间点，以及控制事务日志的大小。可能是事务日志相关问题最常见的原因是在完全恢复模式下工作，而不使用日志备份，或者不频繁地使用日志备份来控制事务日志文件的大小。 如果您不确定是否在给定的数据库上执行了事务日志备份，那么您可以使用类似于清单5.1中所示的查询来简单地查询MSDB数据库中的back心烦表。
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:是否正在进行日志备份?
在type列中，D表示数据库备份、L日志备份和I微分备份。 注意，由于这个back心烦表中的数据可以在不影响备份和恢复行为的情况下进行操作，所以您可能需要通过查询sys来验证您的发现。数据库恢复状态，以查看lastlogbackuplsn的值(请参见清单3.5)或系统。数据库表，以查看logreusewaitdesc的值(如果需要备份，将返回logbackup)。
如何备份事务日志
正如前面所讨论的，在不进行至少一次完整备份的情况下执行事务日志备份是不可能的。实际上，如果您有一个完全恢复模式的数据库，但是从来没有备份过，那么它实际上不会在完全恢复模式下工作。数据库将处于自动截断模式，直到执行第一个完整的备份。
所有数据库备份，全部，日志或其他，都是使用备份命令执行的。命令接受大量的选项,文档:http://msdn.microsoft.com/en-us/library/ms186865.aspx。但是，在最基本的情况下，通常是如何使用它的，执行完整备份到磁盘的命令如下:
备份数据库到磁盘='FileLocation\DatabaseName.bak';
如果这是要执行的第一个备份，则是DatabaseName。将在指定的目录中创建bak文件。如果已经存在这样的文件，那么默认的行为是将后续的备份附加到该文件。为了覆盖这个行为，并规定任何现有的文件都应该被覆盖，我们可以使用INIT选项，如下:
备份数据库到磁盘='FileLocation\DatabaseName.bak'WITH INIT;
然而，最常见的情况是，每个后续的备份都有一个惟一的名称;关于这一点，在接下来的部分中，将会恢复到失败的程度。
在每一个常规的(例如日常)的备份之后，将会有频繁的(例如每小时)日志备份，基本的命令非常相似:
备份数据库到磁盘='FileLocation\DatabaseName_Log.bak';
存储日志备份
显然，备份的数据和日志文件不应该存储在承载活动文件的同一驱动器上。如果该驱动器受到硬件故障的影响，那么您的所有副本将与实时文件一起丢失，而备份将是无效的。文件应该备份到一个单独的设备上，或者备份到本地镜像驱动器上。
日志备份的频率
正如前面提到的，您可能每15分钟就会使用日志备份，甚至可能更频繁。在这种情况下，为了避免需要恢复大量的事务日志文件，您可以选择采用一种备份方案，其中包含了包含有差异备份的完整备份，并穿插了事务日志备份。
在现实中，备份计划通常更像是理想与现实之间的折衷，是对数据丢失真实风险的评估，以及它将对公司造成的损失，以及降低风险的成本。许多非常重要的业务应用程序使用了一些简单的、但严格的备份计划，可能包括定期的每夜完全备份，以及每小时的事务日志备份。
日志备份的频率也可能由数据库所受的事务数量决定。对于非常繁忙的数据库，为了控制日志的大小，可能需要频繁地进行备份。
要计算日志备份的频率是不容易的。大多数dba将对日志备份的频率进行最佳估计，然后观察文件的增长特性，然后根据需要调整备份计划，以防止它们变得过大。
日志链，以及如何打破它
正如所指出的，如果不首先进行一次完整的备份，就不可能执行事务日志备份。为了恢复一个数据库的时间点,要么结束的一个特定的日志备份或时间点在一个特定的日志备份,一定存在一个完整的日志记录,从第一个日志备份后,一个完整
的(或微分备份),直到故障点。这就是所谓的对数链。
有很多方法可以打破这个日志链，如果您这样做，就意味着只有在事件发生之前，才能够恢复数据库，以便在事件发生之前进行日志备份。简而言之，如果您关心恢复数据的能力，那么打破这个链条并不是一个好主意。打破这一链条的最常见的两种方法包括:
事务日志备份文件的丢失或损坏——您将只能恢复到最后一个良好的日志备份。日志链将在下一个良好的全或差备份中重新启动。
切换到简单的恢复模式——如果您从完全恢复模式切换到简单的恢复模式，这将破坏日志链，因为一个检查点将被启动，事务日志可以立即被截断。当您返回到FULL模式时，您将需要另一个完整的备份来重新启动日志链。实际上，在您进行完全备份之前，数据库将保持自动截断模式，您将无法备份日志文件。
在sql Server 2008之前，有一些命令，即带有nolog的备份日志或仅带树干的备份日志(它们在功能上是等价的)，在发出时，会强制执行日志文件截断，从而破坏日志链。您不应该在任何版本的SQL Server中发出这些命令，但是我在这里提到它们，因为它们在处理“失控的日志文件”时仍然会使用这些命令，而不理解它们对恢复数据库的能力有何影响。看第8级-帮助，我的日志已经满了，更多的细节。
尾日志备份
只要您有一个完整的备份和一个完整的日志链，您就可以将数据库恢复到在任何故障之前，它存在于最终日志备份的末尾的状态。但是，假设您每小时以小时为单位执行事务日志备份，并且在下午1点45分发生故障。你可能会损失45分钟的数据;实际上，如果失败是如此的灾难性，实时事务日志无法恢复，那么这就是您将丢失的数据量。
然而，即使数据文件不存在，有时仍然可以使用实时事务日志，特别是如果事务日志包含在一个单独的专用驱动器上。如果是这种情况，您应该备份live事务日志，即执行自上次日志备份以来生成的日志记录的最终备份。这将捕获实时日志文件中剩余的日志记录，直至故障点。这被称为尾日志备份，是在开始恢复和恢复操作之前应该执行的最后一个操作。
尾日志备份和最小日志操作
如果由于数据库故障导致数据文件不可用，日志的尾部包含最少的日志记录操作，那么就不可能进行尾日志备份，因为这需要访问数据文件中更改的数据区段。这将在第6级更详细地介绍，在批量日志模式下管理事务日志。
如果您希望恢复的数据库是联机的，那么日志的尾部就会备份如下:
备份数据库到磁盘='FileLocation\DatabaseName_Log.bak'WITH NORECOVERY
norecooption选项将数据库置于恢复状态，并假设您希望执行的下一个操作是恢复。如果数据库是离线的，并且不会启动，那么您仍然应该尝试按照刚才描述的方式备份日志的尾部(尽管可以忽略noreco选项，因为没有任何事务正在进行中)。
如果您确定日志文件损坏了，那么文档说明，作为最后的手段，您可以尝试做一个尾日志备份:
备份数据库到磁盘='FileLocation\DatabaseName_Log.bak'WITH CONTINUE_AFTER_ERROR
如果主数据库和数据文件被损坏，但是日志是可用的，微软建议重新构建主数据库，然后备份最后一个活动日志。然而，这些主题超出了这一阶梯的范围，我将向您介绍进一步的详细信息。见http://msdn.microsoft.com/en-us/library/ms190952.aspx。
执行恢复和恢复
如果可能的话，执行了尾部日志备份，下一步是恢复最后一个完整的备份(如果适当的话，后面是差异备份)，然后恢复日志备份文件的完整序列，包括尾部日志备份。这个恢复操作序列的基本语法如下:
从磁盘='FileLocation文件名恢复数据库日志数据库。贝克'WITH NORECOVERY;
如果在恢复时，删除了noreco选项，那么在默认情况下，恢复命令将继续进行恢复。换句话说，SQL Server将尝试协调数据和日志文件，将已完成的事务向前滚动，然后在必要时回滚未完成的事务。通过使用norecowe指定，我们正在指示SQL Server，我们正在进入一个恢复序列，并且在执行任何回滚之前，必须将更多的操作向前推进。在恢复恢复序列中的最后一个备份之后，可以恢复数据库，如下所列:
恢复数据库数据库的恢复
一个常见需求是将数据库恢复到一个不同的位置,在这种情况下,您可以简单地将文件恢复过程的一部分,这里所描述的那样:http://msdn.microsoft.com/en-us/library/ms190255.aspx。
数据库故障后恢复
下面的示例描述了如何在响应失败时恢复数据库，从而使数据库数据文件不再可访问。
完全恢复故障点
假设“live”事务日志可以在数据库失败之后达到，这可能是由于硬件故障导致的，那么理论上应该可以通过以下步骤来恢复和恢复您的数据库。
1、备份日志的尾部 2、恢复最近的全备份(如果可以的话，还可以使用微分)
2、反过来，恢复在完全(或差异)备份之后进行的每个事务日志备份，并在故障发生之前完成备份。
3、恢复尾日志备份 5、恢复数据库
在线书籍中发现的许多例子都表明了“备份集”的恢复和恢复，换句话说，就是一个“设备”，所有备份都存储在其中。在实际操作中，这意味着当备份到磁盘时，备份设备是单一的。这个文件位于磁盘的某个地方。
例如，清单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:\Backups\TestDB.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:\Backups\TestDB.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:\Backups\TestDB.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:\Backups\TestDB.bak'
WITH NORECOVERY;
GO
-- Restore the full backup
RESTORE DATABASE TestDB
FROM DISK = 'C:\Backups\TestDB.bak'
WITH FILE=1, NORECOVERY;
-- Apply the transaction log backup
RESTORE LOG TestDB
FROM DISK = 'C:\Backups\TestDB.bak'
WITH FILE=2, NORECOVERY;
-- Apply the tail log backup
RESTORE LOG TestDB
FROM DISK = 'C:\Backups\TestDB.bak'
WITH FILE=3, NORECOVERY;
-- Recover the database
RESTORE DATABASE TestDB
WITH RECOVERY;
GO
清单5.2:备份和恢复备份集;不推荐
然而，在数据库备份到磁带时，使用备份集似乎是一个遗留问题。当备份到磁盘时，使用这个计划是一个坏主意，因为备份文件会很快变得非常大。
在实践中，更常见的是每个完整的备份和事务日志备份文件都将被单独命名，并且可能会标记出备份被占用的时间和日期。例如，大多数第三方备份工具，流行的社区生成脚本，以及SSMS中的维护计划向导/设计器，都将创建单独的日期戳的文件，例如adventureworksfull20080904000001.bak。
因此，更常见的备份和恢复方案将使用惟一指定的备份，如清单5.3所示。
USE master;
BACKUP DATABASE TestDB
TO DISK ='C:\Backups\TestDB.bak'
WITH INIT;
GO
-- Perform a transaction log backup of the Test database
BACKUP Log TestDB
TO DISK ='C:\Backups\TestDB_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:\Backups\TestDB_taillog.bak'
WITH NORECOVERY, INIT;
GO
-- Restore the full backup
RESTORE DATABASE TestDB
FROM DISK = 'C:\Backups\TestDB.bak'
WITH NORECOVERY;
-- Apply the transaction log backup
RESTORE LOG TestDB
FROM DISK = 'C:\Backups\TestDB_log.bak'
WITH NORECOVERY;
-- Apply the tail log backup
RESTORE LOG TestDB
FROM DISK = 'C:\Backups\TestDB_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:\Backups\TestDB.bak'
WITH INIT ;
GO
-- LOG BACKUP 1 at 2.15 AM
USE master ;
BACKUP LOG TestDB
TO DISK = 'C:\Backups\TestDB_log.bak'
WITH INIT ;
GO
-- LOG BACKUP 2 at 2.30 AM
USE master ;
BACKUP LOG TestDB
TO DISK = 'C:\Backups\TestDB_log2.bak'
WITH INIT ;
GO
清单5.4:一列简短的日志备份
如果一个灾难性的故障发生在凌晨2:30之后，我们可能需要将数据库恢复到日志备份2的末尾，即凌晨2:30。 这个例子中的恢复序列与我们前面看到的清单5.3非常类似，但是由于尾部备份是不可能的，我们只能恢复到某个特定的点，所以我们需要使用STOPAT选项，如清单5所示。
--RESTORE Full backup
RESTORE DATABASE TestDB
FROM DISK = 'C:\Backups\TestDB.bak'
WITH NORECOVERY;
--RESTORE Log file 1
RESTORE LOG TestDB
FROM DISK = 'C:\Backups\TestDB_log.bak'
WITH NORECOVERY, STOPAT = 'Jan 01, 2020 12:00 AM';
--RESTORE Log file 2
RESTORE LOG TestDB
FROM DISK = 'C:\Backups\TestDB_Log2.bak'
WITH NORECOVERY, STOPAT = 'Jan 01, 2020 12:00 AM';
--Recover the database
RESTORE DATABASE TestDB
WITH RECOVERY;
GO
清单5:使用STOPAT恢复到某个时间点
由于我们在将来指定了一个停止时间，这段代码将把所有已完成的事务转发到第二个事务日志的末尾。 或者，也可以指定在特定日志文件中记录的事务的时间范围内的停止时间。在这种情况下，数据库将被恢复到指定时间的最后一个提交事务。当您知道需要恢复什么时间时，这是很有用的，但是不知道日志备份包含了什么时间。
还可以恢复到一个特定的标记事务。例如，当您需要恢复某个应用程序访问的多个数据库，以达到逻辑上一致时，这是很有用的。这里没有进一步讨论这个话题,但是你可以找到更多图书在线(http://msdn.microsoft.com/en-us/library/ms187014.aspx),和姆Prajdic提供了一个很好的例子:http://weblogs.sqlteam.com/mladenp/archive/2010/10/20/sql-server-transaction-marks-restoring-multiple-databases-to-a-common.aspx。
在“糟糕的交易”之后恢复
在任何数据库失败的情况下，可能需要恢复数据库备份，再加上事务日志，以便在错误的数据修改之前及时将数据库返回到某个特定的点上，这样就会删除或截断表。
你对这种情况的反应将取决于问题的性质。如果可能，您可能会将所有用户从数据库断开(在通知他们之后)，并评估所发生的事情的影响。在某些情况下，您可能需要估计问题发生的时间，然后使用时间恢复的点对数据库和日志进行全面恢复。一旦恢复完成，您就必须通知用户一些事务可能已经丢失，并请求原谅。
当然，通常您不能以这种方式中断正常的业务操作，从而修复意外的数据丢失。由于live数据库仍然处于运行状态，并且正在被访问，所以您可以尝试在备用模式中恢复数据库的备份。这允许重新恢复日志备份，但是与使用noreco非常不同，数据库仍然是可读的。恢复计划可能是这样的:
1、恢复数据库的备份，在备用模式下，与实时数据库一起 2、在出现错误的事务之前，将日志滚到该点，数据丢失了
2、将丢失的数据复制到实时数据库并删除已恢复的副本
当然，这个过程并不一定是直接的，而且可能非常耗时。除非您已经购买了专门的日志阅读工具，并且可以直接查询日志备份，否则，将日志向前滚动可能意味着一系列艰苦的步骤，包括恢复日志、检查数据、恢复进一步的数据等等，直到您确定了错误的事务发生的确切位置。步骤3也很困难，因为您将把数据引入到与数据库当前状态不一致的实时系统中，因此可以引用
让我们来看一个实现上述步骤1和步骤2的示例。首先，让我们从头开始，运行CreateAndPopulateTestDB。用于重新创建TestDB数据库的sql脚本，并将10行测试数据插入到一个新的日志测试表中。在清单5.6中，我们只做一个完整的数据库备份(覆盖以前的备份文件)。如果您还没有这样做，那么您需要创建“备份”目录，或者适当地调整路径。
-- full backup of the database
BACKUP DATABASE TestDB
TO DISK ='C:\Backups\TestDB.bak'
WITH INIT;
GO
清单5.6:TestDB的完整备份，然后将一个新的数据行插入到LogTest表中。
然后，我们将一个新的数据行插入到LogTest表中。
USE TestDB
GO
INSERT INTO [TestDB].[dbo].[LogTest]
([SomeInt]
,[SomeLetters2])
VALUES
(66666,
'ST')
SELECT * FROM dbo.LogTest
清单5.7:将第11行插入到TestDB中现在，我们有一个实时的TestDB数据库，在LogTest表中有11行，一个有10行的备份版本。现在，让我们在日志备份中捕获额外的修改，如清单5.8所示。
USE master
GO
BACKUP Log TestDB
TO DISK ='C:\Backups\TestDB_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:\Backups\TestDB_log2.bak'
WITH INIT;
GO
清单5.9:灾难! 为了尝试检索丢失的数据，不中断正常的业务操作，我们将在备用模式中恢复TestDB数据库的副本。备用数据库名为ANewTestDB的数据和日志文件被移动到一个“备用”目录(您需要预先创建这个目录)。
-- restore a copy of the TestDB database, called
-- ANewTestDB, in STANDBY mode
USE master ;
GO
RESTORE DATABASE ANewTestDB
FROM DISK ='C:\Backups\TestDB.bak'
WITH STANDBY='C:\Backups\ANEWTestDB.bak',
MOVE 'TestDB_dat' TO 'C:\Standby\ANewTestDB.mdf',
MOVE 'TestDB_log' TO 'C:\Standby\ANewTestDB.ldf'
GO
清单5.10:在备用模式中恢复TestDB的副本
现在我们有了一个名为ANewTestDB的新数据库，它处于“备用/只读”模式，如图5.1中所示。
图5.1:备用数据库 在ANewTestDB数据库中对LogTest表的查询将显示10行。然而，我们希望将表重新回到之前的状态，因为它在错误地被错误地丢弃之前。因此，下一步是对备用数据库执行恢复日志备份。
USE master
GO
RESTORE LOG ANewTestDB
FROM DISK = 'C:\Backups\TestDB_log.bak'
WITH STANDBY='C:\Backups\ANewTestDB_log.bak'
清单5.11:在备用模式下恢复到ANewTestDB数据库的日志备份
此时，针对ANewTestDB的查询将显示11行，现在我们可以将这些数据复制到实时数据库中。如果我们更进一步，恢复了第二个日志备份，那么我们就会意识到我们已经走得太远了，在备用数据库中也会丢失这个表。 备用恢复的另一种选择是考虑使用第三方工具，如Red Gate的SQL虚拟恢复，它提供了一种将备份作为实时的、功能完备的数据库，而不需要物理恢复的方法。
不管dba是否喜欢，开发人员通常都可以访问生产数据库来执行特定的数据加载和更改。DBA和开发人员的共同职责是确保这些进展顺利进行，因此不会导致需要描述的操作的问题。我们将在稍后的第6级回到这个主题——处理批量操作。当然，所需要的修复行动的确切性质取决于糟糕交易的性质。如果一个表被“意外地删除”，那么很有可能您将使用备用路径沿着恢复的方向前进。在其他时候，您可以简单地创建一个脚本，以“反转”这个流氓的修改。
如果损害只影响单个列或有限的行数，那么作为另一种选择，可以使用SQL数据比较之类的工具，它可以直接与备份文件进行比较，并且可以进行行级别的恢复。或者,如果您运行SQL Server 2005企业版(或更高版本),并提供最近的数据库快照,您可以运行一个查询检索数据的快照,因为它看起来当时数据库快照,然后写一个更新或插入命令将数据从数据库快照进入生活,源数据库。
如果损害只影响单个列或有限的行数，那么作为另一种选择，可以使用SQL数据比较之类的工具，它可以直接与备份文件进行比较，并且可以进行行级别的恢复。或者,如果您运行SQL Server 2005企业版(或更高版本),并提供最近的数据库快照,您可以运行一个查询检索数据的快照,因为它看起来当时数据库快照,然后写一个更新或插入命令将数据从数据库快照进入生活,源数据库。
摘要
在这个级别上，我们已经介绍了备份和恢复以完全恢复模式运行的数据库日志文件的基础知识，这将是许多生产数据库的规范。 对于大多数dba来说，执行一个时间点恢复的需求是一个罕见的事件，但是这是其中一个任务，如果有必要，它是非常重要的，它可以做得很好;DBA的声誉取决于它。
在腐败、驱动失败等方面，时间点的恢复可能涉及到，如果您幸运的话，可以备份事务日志的尾部并恢复到故障点。如果事务日志不可用，或者如果您正在恢复，以便在出现“坏事务”之前恢复到某个时间点，那么情况将变得更加复杂，但是希望本文所涉及的一些技术将会有所帮助。
资源: TransactionLogStairway_Level5_Code.zip 本文是SQL Server阶梯上的事务日志管理的一部分 注册到我们的RSS订阅源，当我们在楼梯上发布一个新级别的时候，就会得到通知！