第十四周翻译 Stairway to Transaction Log Management in SQL Server, Level 5: Managing the Log in Full Recovery Mode

第十四周翻译

Stairway to Transaction Log Management in SQL Server, Level 5: Managing the Log in Full Recovery Mode

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

Tony Davis, 2012-01-27

在本节中，我们将回顾在完全恢复模式下进行日志备份的原因和方法，以及如何使用这些日志备份文件与完整的数据库备份一起执行数据库恢复。完全恢复模式支持将数据库恢复到可用日志备份中的任意时间点，并假设可以进行尾日志备份，直到发生故障之前的最后一个提交事务的时间为止。

在完全恢复模式下，所有操作都被完全记录。对于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)操作,完整和BULK_LOGGED恢复模式。在BULK_LOGGED模式下工作时，记录最小日志操作的日志记录的差异将在第6级中更详细地讨论——在批量日志恢复模式下管理日志。

为什么要备份事务日志?

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

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

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

事务日志的COPY_ONLY备份

事务日志的COPY_ONLY备份不会截断事务日志。COPY_ONLY日志备份与普通日志备份方案“独立”存在;它不会破坏日志备份链。

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

如果您不确定是否在给定的数据库上执行事务日志备份，那么您可以使用类似于清单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来验证从该查询中得到的结果。database_recovery_status查看last_log_backup_lsn(参见清单3.5)或sys的值。数据库表，以查看log_reuse_wait_desc的值(如果需要备份，将返回LOG_BACKUP)。

如何备份事务日志

如前所述，如果不首先执行至少一个完整备份，就不可能执行事务日志备份。事实上，如果数据库处于完全恢复模式，但从未备份过，那么它实际上不会在完全恢复模式下工作。在执行第一次完整备份之前，数据库将处于自动截断模式。

使用BACKUP命令执行所有数据库备份，包括完整备份、日志备份或其他备份。该命令接受许多选项，这些选项在这里有文档说明:http://msdn.microsoft.com/en-us/library/ms186865.aspx。然而，最基本的，也就是通常使用的方法，执行磁盘完全备份的命令如下:

备份数据库DatabaseNameTO磁盘='FileLocation\DatabaseName.bak';

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

备份数据库DatabaseNameTO磁盘='FileLocation\DatabaseName。贝克'WITH初始化;

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

每次定期(如每日)全面备份后，会有频繁(如每小时)的日志备份，其基本命令非常相似:

备份日志DatabaseNameTO磁盘='FileLocation\DatabaseName_Log.bak';

存储日志备份

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

日志备份的频率

如前所述，您可能每15分钟进行一次日志备份，甚至更频繁。在这种情况下，为了避免需要恢复大量事务日志文件，您可以选择采用一种备份方案，其中包括完整备份和差异备份、事务日志备份。

实际上，备份方案通常是理想和实际之间的折衷，是对数据丢失的真实风险、公司将为此付出的代价以及降低该风险所涉及的成本的评估之间的折衷。许多非常重要的业务应用程序使用稍微简单但仍然严格的备份方案，可能包括定期夜间完全备份和每小时事务日志备份。

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

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

日志链和如何打破它

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

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

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

在sql Server 2008之前，有两个命令，即使用NO_LOG的备份日志或使用TRUNCATE_ONLY的备份日志(它们在功能上是等价的)，当发出这些命令时，将强制截断日志文件，从而打破日志链。您不应该在任何版本的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;

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

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:驱动器上创建一个“备份”目录，或者根据需要修改文件路径。

-- 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;

-- 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'

-- ....<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'

-- 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;

-- 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;

清单5.2:备份到备份集并从中恢复;不推荐

然而，使用备份集似乎是数据库备份到磁带时的遗留问题。当备份到磁盘时，使用这种方案不是一个好主意，因为备份文件会很快变得非常大。

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

因此，更常见的备份和恢复方案将使用惟一名称的备份，如清单5.3所示。

USE master;

BACKUP DATABASE TestDB

TO DISK ='C:\Backups\TestDB.bak'

WITH INIT;

-- Perform a transaction log backup of the Test database

BACKUP Log TestDB

TO DISK ='C:\Backups\TestDB_log.bak'

WITH INIT;

-- ....<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;

-- 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;

清单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;

清单5.5:使用STOPAT恢复到某个时间点

由于我们在将来指定了一个STOPAT时间，这段代码将把所有完成的事务前滚到第二个事务日志的末尾。

或者，也可以指定一个STOPAT time，它位于特定日志文件中记录的事务的时间范围内。在这种情况下，数据库将在指定的时间恢复到最后提交的事务。当您知道要恢复到什么时间，但不知道日志备份具体包含什么时间时，这是非常有用的。

也可以还原到特定的标记事务。例如，当您需要将由某个应用程序访问的多个数据库恢复到逻辑上一致的点时，这是非常有用的。这里没有进一步讨论这个话题,但是你可以找到更多图书在线(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。

在“错误的事务”之后恢复

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

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

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

1.在备用模式下，在活动数据库旁边还原数据库的备份。

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

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

当然，这个过程不一定是直接的，而且可能非常耗时。除非您购买了专门的日志读取工具，并且能够直接查询日志备份，否则将日志前滚可能意味着一系列艰苦的步骤，包括恢复日志、检查数据、进一步恢复，等等，直到您确定错误事务发生的确切位置。步骤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;

清单5.6:TestDB的完全备份

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

USE TestDB

INSERT INTO [TestDB].[dbo].[LogTest]

([SomeInt]

,[SomeLetters2])

VALUES

(66666,

'ST')

SELECT * FROM dbo.LogTest

清单5.7:将第11行插入TestDB

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

USE master

BACKUP Log TestDB

TO DISK ='C:\Backups\TestDB_log.bak'

WITH INIT;

清单5.8:TestDB的日志备份

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

USE TestDB

DROP TABLE dbo.LogTest ;

USE master

BACKUP Log TestDB

TO DISK ='C:\Backups\TestDB_log2.bak'

WITH INIT;

清单5.9:灾难!

为了在不中断正常业务操作的情况下检索丢失的数据，我们将在备用模式下恢复TestDB数据库的副本。备用数据库的数据和日志文件(称为ANewTestDB)被移动到一个“备用”目录(需要预先创建这个目录)。

-- restore a copy of the TestDB database, called

-- ANewTestDB, in STANDBY mode

USE master ;

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'

清单5.10:在备用模式下恢复TestDB的副本

现在我们有了一个名为ANewTestDB的新数据库，它处于“备用/只读”模式，如图5.1所示

图5.1:备用数据库

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

USE master

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的声誉取决于此。

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

本文是SQL Server中事务日志管理父楼梯的一部分。

原文地址：https://www.cnblogs.com/hawking-520/p/11032729.html