SQL Server事务日志管理的进阶，第5级：在完全恢复模式下管理日志

SQL Server事务日志管理的进阶，第5级：在完全恢复模式下管理日志

 

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

 

托尼·戴维斯(Tony Davis)著，2012年1月27日

 

该系列

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

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

 

在这一级别中，我们将回顾在完全恢复模式下工作时进行日志备份的原因和方法，以及如何使用这些日志备份文件与完全数据库备份一起执行数据库还原。完全恢复模式支持将数据库恢复到可用日志备份中的任何时间点，并且，假设可以在失败发生之前执行最后一次提交事务的时间之前执行尾日志备份。

 

什么记录?

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

 

在完全恢复模式下工作时，可以最低限度记录SELECT INTO、BULK INSERT和CREATE INDEX的操作仍然是完全记录的，但操作方式略有不同。受这些操作影响的行不会单独记录;相反，只有数据库页面在被填充时才会被记录下来。这减少了此类操作的日志记录，同时确保仍然存在执行回滚、重做和时间点恢复所需的相同信息。Kalen Delaney发表了一些关于SELECT INTO  (http://sqlblog.com/blogs/kalen_delaney/archive/2011/03/15/ what-gets-logge-forsel-into .aspx)和索引(http://sqlblog.com/blogs/kalen_delaney/archive/2011/03/08/what-gets-logge-forindex -rebuilds.aspx)操作的日志记录的研究，包括完全和批量记录恢复模式。在批量记录模式下工作时，最低日志记录操作的日志记录差异将在第6级-在批量日志恢复模式下管理日志中进行更详细的讨论。

 

为什么备份事务日志?

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

 

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

 

日志的截断将在日志备份完成后立即发生，假设自上次备份以来已经发生了检查点，并且没有其他因素延迟截断，例如数据备份或还原操作。有关可能延迟可恢复的VLFs截断的所有因素，以及保持大量日志活动(否则不需要)的因素，如流氓的、长时间运行的未提交事务或数据库镜像或复制进程，请参见http://msdn.microsoft.com/en-gb/library/ms345414.aspx。

 

事务日志的COPY_ONLY备份

事务日志的COPY_ONLY备份不截断事务日志。一个COPY_ONLY日志备份存在于普通日志备份方案之外;它不会破坏日志备份链。

 

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

 

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

 

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表示差异备份。

 请注意，由于可以在不影响备份和恢复行为的情况下对这个反备份表中的数据进行操作，因此您可能希望通过查询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。然而，在最基本的情况下(通常是这样使用的)，对磁盘执行完整备份的命令如下:

 

如果这是要执行的第一个备份，则数据库名。bak文件将创建在指定的目录。如果已经存在这样的文件，那么默认行为是将后续备份追加到该文件。要覆盖此行为，并规定应该覆盖任何现有文件，我们可以使用INIT选项，如下所示:

 

然而，最常见的是，每个后续备份都有一个惟一的名称;关于这一点，请在下一节恢复到故障点。

 

在每次常规(如每日)全面备份之后，会有频繁(如每小时)的日志备份，基本命令非常类似:

 

 

 存储日志备份

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

 

日志备份频率

如前所述，您可能每15分钟进行一次日志备份，甚至可能更频繁。在这种情况下，为了避免需要还原大量的事务日志文件，您可以选择采用一种由完全备份组成的备份方案，其中穿插了差异备份和事务日志备份。

 

在现实中，备份方案通常是理想和实际之间的折衷，是对数据丢失的真实风险的评估，以及它将给公司带来的成本，以及降低这种风险所涉及的成本之间的折衷。许多非常重要的业务应用程序使用稍微简单一些但仍然严格的备份方案，可能涉及定期的夜间完整备份和每小时的事务日志备份。

 

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

 

没有简单的方法来计算多久做一次日志备份。大多数数据库管理员将对日志备份的频率进行最佳估计，然后观察文件的增长特征，然后根据需要调整备份方案，以防止文件过大。

 

日志链和如何打破它

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

 

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

• 事务日志备份文件的丢失或损坏—您将只能恢复到上一次良好的日志备份。日志链将在下一个良好的完全备份或差异备份时再次启动。
•  切换到简单恢复模式—如果您曾经从完全恢复模式切换到简单恢复模式，这将破坏日志链，因为会触发检查点，事务日志可以立即被截断。当您返回到FULL模式时，您将需要另一个完整备份来重新启动日志链。事实上，在进行完整备份之前，数据库将保持自动截断模式，并且无法备份日志文件。

 

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

 

尾日志备份

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

 

但是，有时即使数据文件不可用，仍然可以使用实时事务日志，特别是如果事务日志包含在单独的专用驱动器上。如果是这样，应该备份实时事务日志，即对上次日志备份之后生成的日志记录执行最后一次备份。这将捕获活动日志文件中到故障点为止的其余日志记录。这称为尾部日志备份，是开始恢复和恢复操作之前应该执行的最后一个操作。

 

      尾部日志备份和最低日志记录的操作

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

 

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

 

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

 

如果您确定日志文件已经损坏，那么文档建议，作为最后一种方法，您可以尝试使用以下方法进行尾部日志备份:

 

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

 

执行恢复和恢复

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

 

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

 

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

 

数据库故障后的恢复

下面的示例描述如何在数据库数据文件不再可访问的情况下恢复数据库。

 

完全恢复到故障点

假设“活动”事务日志可以在数据库故障(可能是由硬件故障引起的)之后到达，那么从理论上讲，应该可以通过以下步骤恢复和恢复数据库，直至故障点:

 

1.备份日志的尾部

2.恢复最近的完整备份(加上差异，如果适用)

3.依次恢复在完全备份(或差异备份)之后执行并在失败之前完成的每个事务日志备份

4.还原尾日志备份

5.恢复数据库

 

在线书籍中的许多示例演示了从“备份集”(也就是存储所有备份的单个“设备”)恢复和恢复。实际上，这意味着，当备份到磁盘时，备份设备是位于磁盘上某个位置的单个.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中的维护计划向导/设计器，都将创建单独的日期戳文件，例如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时间，因此此代码将前滚所有已完成的事务，直到第二个事务日志结束。

 

或者，也可以指定一个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-multi -database -to-a-common.aspx。

 

 在“错误的事务”后恢复

在任何数据库失败的上下文之外，可能需要恢复数据库备份和事务日志，以便在进行错误的数据修改(如删除或截断表)之前将数据库及时返回到特定的时间点。

 

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

 

当然，您通常不能以这种方式中断正常的业务操作，以修复意外的数据丢失。由于live数据库仍在运行和访问中，您可以尝试在备用模式下恢复数据库的备份。这允许恢复更多的日志备份，但与使用NORECOVERY不同的是，数据库仍然是可读的。恢复方案可能是这样的:

 

1.在备用模式下，在活动数据库旁边恢复数据库的备份

2.将日志前滚到错误事务发生之前的位置，数据丢失。

3.将丢失的数据复制到活动数据库，并删除恢复的副本

 

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

 

让我们看一个实现上面步骤1和步骤2的示例。首先，让我们从头开始运行CreateAndPopulateTestDB。重新创建TestDB数据库的sql脚本，并将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:向TestDB插入第11行

 

因此，现在我们有了一个LogTest表中有11行活动TestDB数据库，以及一个有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 Data Compare等工具作为替代，它可以直接与备份文件进行比较，并可以进行行级恢复。

 

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

 

最后，作为最后的手段，一个专门的日志阅读器工具可能会帮助您逆转事务的影响，尽管我不知道在SQL Server 2005或更高版本中有任何可靠的工作。

 

总结

在这个级别中，我们介绍了在完全恢复模式下操作的数据库的备份和恢复日志文件的基本知识，这将是许多生产数据库的标准。

 

对于大多数DBA来说，执行时间点恢复的需求很少，但是如果有必要，那么执行时间点恢复非常重要;DBA的声誉取决于此。

 

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

 

 

资源:

TransactionLogStairway_Level5_Code.zip

本文是SQL Server Stairway中的事务日志管理的一部分

 

注册我们的RSS订阅，当我们在楼梯上发布一个新级别时，就会得到通知!