#翻译#在SQL Server中的事务日志管理的楼梯间，第5级:在完全恢复模式下管理日志 By Tony Davis, 2012/01/27，原文链接：Stairway to Transaction Log Management in SQL Server, Level 5: Managing the Log in Full Recovery Mode http://www.sqlserverce

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

当事情进展顺利时，不需要特别知道到事务日志是做什么的，或者它是如何工作的。您只需确信每个数据库都有正确的备份机制。当事务出错时，对事务日志的理解在采取纠正措施是非常重要的，特别是需要一个实时的数据库恢复时。Tony Davis给出了每个DBA都应该知道的正确的细节级别。

 在这个级别，我们将回顾在完全恢复模式下如何进行日志备份，以及如何使用这些日志备份文件进行数据库恢复，以及完整的数据库备份。完全恢复模式能使数据库恢复到可用的日志备份中的任何时间点，并且在发生故障之前，进行尾日志备份，直到最后一次提交事务。

 什么是记录?

 在完全恢复模式下，所有操作都被完全记录。对于插入、更新和删除操作，这意味着对每一行进行修改，将会有一个日志记录来描述执行该语句的事务的ID，当该事务开始和结束时，该事务的页面被更改，所做的数据更改，等等。

 在完全恢复模式下工作时，可以将SELECT INTO、批量插入和创建索引的操作都完全记录在日志中，但它的处理方式略有不同。受这些操作影响的行没有单独记录;相反，只有数据库页面被记录，因为它们被填充。这减少了对此类操作的日志记录，同时确保仍然存在所有需要执行回滚、重做和在时间恢复中点的相同信息。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级中更详细地讨论了在第6级中管理日志的日志记录，在大容量日志恢复模式中管理日志。

 为什么要备份事务日志?

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

 因此，在完全恢复模式下工作时，必须执行常规事务日志备份，以及完全备份和可选的差异备份。许多新手或兼职dba在他们的数据库上执行完整的备份，但是他们不执行事务日志备份。因此，事务日志不会被截断，它会不断增长，直到磁盘空间耗尽为止，导致SQL Server停止工作。

 当记录日志备份时，就会发生日志的截断，假设在之前的备份之后出现了一个检查点，并且没有其他因素会延迟截断，例如数据备份或恢复操作。完整列表的因素,可能会推迟恢复的甚低频截断,以及因素保持日志活跃的大片地区,否则不会需要,如一个流氓,长期未提交的事务或数据库镜像或复制流程,参见:http://msdn.microsoft.com/en-gb/library/ms345414.aspx。

事务日志的COPY_ONLY备份

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

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

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

 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是一个日志备份，而我是一个差异备份。

 请注意，由于这个back表中的数据可以在不影响备份和恢复行为的情况下进行操作，因此您可能需要通过查询sys来验证您的查询结果。database_recovery_status以查看last_log_backup_lsn的值(见例3.5)或sys。数据库表可以看到log_reuse_wait_desc的值(如果需要备份，将返回LOG_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';

 存储日志备份

 显然，备份的数据和日志文件不应该存储在承载活动文件的同一驱动器上。如果该驱动器故障，那么您的所有副本将连同live文件一起丢失，备份将是无效的。这些文件应该备份到一个单独的设备上，或者备份到一个本地的镜像驱动器上。

日志备份的频率

 正如前面提到的，您可能每隔15分钟就进行一次日志备份，或者更频繁地进行日志备份。在这种情况下，为了避免需要恢复大量的事务日志文件，您可以选择采用由完全备份组成的备份方案，其中穿插了差异备份，并穿插了事务日志备份。

 在现实中，备份方案往往是理想与实际之间的妥协，是对数据丢失的真实风险的评估，以及它将给公司带来的损失，以及降低风险所涉及的成本。许多非常重要的业务应用程序使用的都比较简单，但仍然是严格的备份计划，可能包括经常的夜间完全备份和小时事务日志备份。

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

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

 日志链和如何打破它

 如前所述，如果不首先进行一次完整的备份，就不可能执行事务日志备份。为了恢复一个数据库的时间点,结束的一个特定的日志备份或时间点在一个特定的日志备份点,一定存在一个完整的日志记录,从第一个日志备份后,一个完整的(或微分备份),直到故障点。这就是所谓的日志链。

 有许多方法可以破坏日志链，如果您这样做，就意味着您只能将数据库恢复到在事件发生之前所采取的日志备份的时间。简而言之，如果您不自信您的恢复数据的能力，那么破坏链就不是一个好主意。最常见的破坏链条的方法有:

 事务日志备份文件的丢失或损坏—您只能恢复到前一个良好的日志备份。日志链将在下一个良好的完整或差异备份中重新启动。

切换到简单的恢复模式——如果您从FULL到SIMPLE恢复模式，这将会破坏日志链作为一个检查点将被激发，事务日志可以立即被截断。当您返回到FULL模式时，您需要再次进行完全备份以重新启动日志链。实际上，在您完全备份之前，数据库仍然处于自动截断模式，您将无法备份日志文件。

 在sql Server 2008中，有一些命令，即使用TRUNCATE_ONLY(它们是功能对等的)的备份日志和NO_LOG或备份日志，当发出时，会强制一个日志文件截断，从而破坏日志链。您不应该在任何版本的SQL Server中发出这些命令，但是我在这里提到它们，因为它们仍然会被粗心的人使用，当他们试图处理一个“失控的日志文件”时，不理解它对恢复数据库的能力所带来的影响。请参阅第8级-帮助，我的日志已满，以获取更多细节。

 尾日志备份

 只要您有一个最近的完整备份和完整的日志链，您就可以将您的数据库恢复到在任何失败之前在最终日志备份结束时存在的状态。但是，假设您每小时执行一次事务日志备份，而在下午1:45时发生故障。你可能会损失45分钟的数据;实际上，如果失败是灾难性的，那么实时事务日志是不可恢复的，那么这就是您将丢失的数据量。

 然而，有时候即使数据文件不存在，实时事务日志仍然可用，特别是如果事务日志包含在单独的专用驱动器上。如果是这样，您应该备份实时事务日志，即执行自上次日志备份以来生成的日志记录的最后备份。这将捕获活日志文件中剩余的日志记录，直至失败点。这称为尾日志备份，是在开始恢复和恢复操作之前应该执行的最后一个操作。

尾部日志备份和最低日志操作

 如果数据文件由于数据库故障而不可用，并且日志尾部包含了最低日志记录操作，那么就不可能执行尾日志备份，因为这需要访问数据文件中更改的数据区。这将在第6级中更详细地介绍，在大容量日志模式中管理事务日志。

 如果您希望恢复的数据库是联机的，那么日志的尾部将备份如下:

BACKUP LOG DatabaseNameTO DISK ='FileLocation\DatabaseName_Log.bak'WITH NORECOVERY

 NORECOVERY选项将数据库置于恢复状态，并假设您希望执行的下一个动作是恢复。如果数据库处于脱机状态，并且不会启动，那么您仍然应该尝试像刚才描述的那样备份日志的尾部(虽然NORECOVERY选项可以省略，因为没有任何事务正在进行中)。

 如果您确信日志文件已经损坏，那么文档说明，作为最后的手段，您可以尝试使用:

BACKUP LOG DatabaseNameTO DISK ='FileLocation\DatabaseName_Log.bak'WITH CONTINUE_AFTER_ERROR

 如果主数据库和数据文件被损坏，但是日志是可用的，Microsoft建议重新构建主数据库，然后备份最后一个活动日志。但是，这些主题不在此楼梯的范围内，请您参考文档了解更多细节。见http://msdn.microsoft.com/en-us/library/ms190952.aspx。

执行恢复和恢复

 在执行尾日志备份之后，如果可能的话，下一步是恢复最后的完整备份(如果适当的话，接下来是差异备份)，然后恢复日志备份文件的完整序列，包括尾部日志备份。这个恢复操作序列的基本语法如下:

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

 如果在恢复时忽略了NORECOVERY选项，那么默认情况下，恢复命令将继续进行恢复。换句话说，SQL Server将尝试协调数据和日志文件，滚动完成的事务，然后在必要时回滚未完成的事务。通过在NORECOVERY中指定，我们正在指导SQL Server，我们正在进入一个恢复序列，并且在任何回滚都可以执行之前，必须对更多的操作进行滚转。在还原恢复序列中的最后一个备份之后，数据库可以恢复如下:

RESTORE DATABASE DatabaseName WITH RECOVERY

 一个常见需求是将数据库恢复到一个不同的位置,在这种情况下,您可以简单地将文件恢复过程的一部分,这里所描述的那样:http://msdn.microsoft.com/en-us/library/ms190255.aspx。

数据库故障后恢复

 下面的示例描述了如何在响应失败时恢复数据库，从而使数据库数据文件无法访问。

完全恢复到故障点

 假设在数据库失败后可以达到“live”事务日志，这可能是由硬件故障引起的，那么理论上应该可以通过以下步骤恢复和恢复数据库，直至故障点。

 备份日志的尾部

恢复最近的全部备份(如果可以的话，还可以加上微分)

反过来，每个事务日志备份都是在完整(或差异)备份之后进行的，并在失败之前完成

还原尾日志备份

恢复数据库

 许多在网上找到的例子都显示了从“备份集”中恢复和恢复，换句话说，一个单独的“设备”存储所有备份。实际上，这意味着当备份到磁盘时，备份设备是单个的。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:\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中的维护计划向导/设计器，都将创建单独的date戳的文件，例如AdventureWorks_FULL_20080904_000001.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.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.5:使用STOPAT恢复到时间点

 由于我们在将来指定了一个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数据库仍在运行和被访问，所以您可以尝试在备用模式下恢复数据库的备份。这允许恢复更多的日志备份，但不像使用NORECOVERY时，数据库仍然是可读的。恢复方案可能是这样的:

 在备用模式下，在实时数据库旁边恢复数据库的备份

将日志向前滚动到错误事务发生之前的点，数据丢失。

将丢失的数据复制到数据库并删除已恢复的副本

 当然，这个过程并不简单，而且可能非常耗时。除非您已经购买了专用的日志读取工具，并且可以直接查询日志备份，因此，将日志向前滚动将意味着需要一系列艰苦的步骤，包括恢复日志、检查数据、进一步恢复，等等，直到您确定了错误的事务发生的地方。步骤3也很困难，因为您将会将数据引入到与数据库当前状态不一定一致的实时系统中，因此可能存在引用完整性问题。

 让我们看一个实现上面第1步和第2步的例子。首先，让我们从头开始运行CreateAndPopulateTestDB。sql脚本来重新创建TestDB数据库，并将10行测试数据插入到一个新的LogTest表中。在例5.6中，我们只是做了一个完整的数据库备份(覆盖了以前的备份文件)。您需要创建“备份”目录，如果您还没有这样做，或者适当地调整路径。

 -- full backup of the database

BACKUP DATABASE TestDB

TO DISK ='C:\Backups\TestDB.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:将第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 Virtual restore，它提供了一种方法，可以将备份作为实时的、完全功能的数据库，而不需要物理恢复。

无论dba是否喜欢，开发人员通常都可以访问生产数据库来执行特定的数据加载和更改。DBA和开发人员的共同责任是确保这些工作顺利进行，因此不需要仅仅描述那些需要采取行动的问题。我们稍后将在第6级处理批量操作返回到这个主题。

当然，所需的赔偿行动的确切性质取决于不良交易的性质。如果一个表被“意外删除”，那么很可能您将以备用路由的方式进行恢复。在其他时候，您可以简单地创建一个脚本，以“反转”恶意修改。

如果损害只影响单个列或有限的行数，那么作为替代方法，可以使用SQL数据比较之类的工具，这可以直接与备份文件进行比较，并可以进行行级恢复。 

或者,如果您运行SQL Server 2005企业版(或更高版本),并提供最近的数据库快照,您可以运行一个查询检索数据的快照,因为它看起来当时数据库快照,然后写一个更新或插入命令将数据从数据库快照进入生活,源数据库。 

最后，作为最后的手段，一个专用的日志阅读器工具可以帮助您消除事务的影响，尽管我不知道在SQL Server 2005和以后的工作中有哪些工作是可靠的。

总结

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

对于大多数dba来说，需要执行时间点恢复是很少见的事情，但这是其中的一项任务，如果有必要，它是绝对重要的，它完成得很好;DBA的声誉取决于此。

如果您运气好，可以备份事务日志的尾部，并恢复到失败点的权限，那么在发生腐败、驱动失败等情况时，及时恢复可能会涉及到。如果事务日志不可用，或者您正在恢复，以便在发生“坏事务”之前恢复到某个时间点，那么情况就变得更加棘手，但是希望这一步中涉及的一些技术将会有所帮助。