sql服务器第5级事务日志管理的阶梯：完全恢复模式下的日志管理
原文链接http://www.sqlservercentral.com/articles/Stairway+Series/73785/
作者 Tony Davis, 2012/01/27
系列
本文是阶梯系列的一部分：sql服务器中事务日志管理的楼梯
当事情进展顺利时，没有必要特别注意事务日志的工作或工作方式。你只需要确信每个数据库都有正确的备份系统。当出现问题时，对事务日志的理解对于采取纠正行动非常重要，特别是当需要立即对数据库进行点对点恢复时！作者Tony Davis给出了每个数据库管理员应该知道的正确的细节级别。
在此级别中，我们将讨论在完全恢复模式下工作时为什么要日志备份、如何进行日志备份，以及如何使用这些日志备份文件与完整数据库备份一起执行数据库还原。完全恢复模式支持数据库恢复到可用日志备份中的任何时间点，并且假设可以进行跟踪日志备份，在故障发生之前的上次提交的事务。
什么会被记录？
在完全恢复模式下，所有操作都已完全登录。对于插入、更新和删除操作，这意味着对于每个被修改的行，将有一个日志记录，描述执行该语句的事务的id，该事务开始和结束时，哪些页被更改，所做的数据更改，等等。
在完全恢复模式下，可以进行最小程度的登录选择、批量插入和创建索引的操作仍然会被完全记录，但操作略有不同。受这些操作影响的行不会单独记录，而只会在数据库页面被填充时进行记录。这减少了这种操作的偶然听到的日志记录，同时确保仍然存在执行回滚、重做和时间恢复点所需的所有相同的信息。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) 。在完整和大容量日志恢复模式中。在第6级----在批量日志恢复模式下管理日志----中更详细地讨论了最小日志操作的日志记录的不同。
为什么要备份事务日志？
在完全恢复模式下，只有日志备份才能导致日志的截断。因此，事务日志将保存自上次备份事务日志以来所进行的交易的完整记录。由于所有操作都已完全登录，日志文件在繁忙的系统中可以非常多、非常快地增长。
因此，在完全恢复模式下工作时，执行常规事务日志备份是非常重要的，此外还有完整的备份和可选的差异备份。许多新手或兼职的数据库管理员，在他们的数据库中执行完整的备份，但是他们不执行事务日志备份。因此，事务日志不会被截断，并且它会不断地增长，直到它运行的驱动器的磁盘空间用完，从而导致sql服务器停止工作。
一旦进行日志备份，日志就会被截断，假设检查点已发生自上次备份后，并且没有其他因素延迟截断，例如数据备份或还原操作。用于获取可能延迟截断可恢复的虚拟日志文件的全部因素列表，以及使日志中的大部分区域保持活动状态而不需要保持活动状态的因素，例如流氓的、长期运行的未提交的事务或数据库镜像或复制过程。http://msdn.microsoft.com/en-gb/library/ms345414.aspx.
仅复制事务日志的备份
仅复制事务日志的备份不会截断事务日志。仅使用版权的日志备份与正常日志备份方案“独立”存在；它不会破坏日志备份链。简而言之，事务日志备份执行双重目的，即允许还原和恢复到以前的时间点，以及控制事务日志的大小。事务日志相关问题的最常见原因可能是在完全恢复模式下工作，而不进行日志备份，或者日志备份不够频繁，不能控制事务日志文件的大小。
如果您不确定是否在给定的数据库上进行事务日志备份，那么可以简单地使用类似于清单5.1所示的查询来询问主存数据库数据库中的备份设置表。
USE msdb ;SELECT backup_set_id ,
backup_start_date ,
backup_finish_date ,
backup_size ,
recovery_model ,
[type]FROM dbo.backupsetWHERE database_name = 'TestDB'
表5.1：是否正在进行日志备份？
在类型列中，d表示数据库备份，l表示日志备份，i表示差异备份。
注意，由于这个备份设置表中的数据可以在不影响备份和恢复行为的情况下操作，可能需要您验证在这个查询中的发现，通过查询 sys.database_recovery_status 以查看最后last_log_backup_lsn的值（见表3.5），或者用sys.databases表查看log_reuse_wait_desc的值（如果需要备份，将返回日志备份）。
如何备份事务日志
正如前面所讨论的，如果不首先执行至少一个完整的备份，就不可能执行事务日志备份。事实上，如果数据库处于完全恢复模式，但从未备份，那么它实际上就不会在完全恢复模式下工作。数据库将处于自动截断模式，直到执行第一个完整备份。所有的数据库备份，包括完整的、日志或其他的，都是使用备份命令执行的。命令接受许多选项，这些选项记录在
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';
储存日志备份
很明显，备份的数据和日志文件不应该存储在托管活文件的同一驱动器上。如果该驱动器出现硬件故障，那么您的所有副本将与现场文件一起丢失，备份将是徒劳的。这些文件应该备份到单独的设备上，或者备份到本地的镜像驱动器上。
日志备份的频率
正如在前面的关卡中所指出的，您可能每隔15分钟进行一次日志备份，或者更频繁地这样做。在这种情况下，为了避免需要还原大量的事务日志文件，您可以选择采用一个备份方案，其中包括穿插有差异备份的完整备份，以及穿插有事务日志备份的备份。
在现实中，备份方案往往是理想和实际之间的折衷，是评估数据丢失的真实风险、公司将付出的代价和减轻这种风险所涉及的费用之间的折衷。许多非常重要的业务应用程序使用的备份方案比较简单，但却很严格，可能包括定期的夜间完整备份和每小时的事务日志备份。
日志备份的频率也可能取决于数据库所涉及的事务的数量。对于非常繁忙的数据库，可能需要经常备份以控制日志的大小。
没有简单的方法来计算使用日志备份的频率。大多数数据库管理员将对日志备份的频率进行最佳估计，然后观察文件的增长特性，然后根据需要调整备份方案，来防止文件变得过大。
日志链和如何打破日志链
如前所述，不先执行至少一个完整备份的情况下，不可能执行事务日志备份。为了将数据库恢复到某个时间点，或者恢复到特定日志备份的末尾，或者恢复到特定日志备份中的某个时间点，必须存在一个完整的完整的日志记录链，从完整备份（或差异备份）后的第一个日志备份，一直到故障。这就是所谓的日志链。
有许多方法可以打破日志链，如果这样做，则意味着您只能恢复数据库到事件发生前的日志备份时间。简而言之，如果你关心恢复数据的能力，打破这个链不是一个好主意。打破僵局最常见的两种方式包括：
（1）事务日志备份文件丢失或损坏——您只能恢复到前一个良好日志备份。日志链将在下一次良好的完全备份或特定时间再次启动。
（2）切换到简单的恢复模式——如果您曾经从完全恢复模式切换到简单恢复模式，就会打破日志链，因为一个检查点将被启动，事务日志将被立即截断。当您返回到完全模式时，您将需要采取另一个完全备份来重新启动日志链。事实上，除非您使用完整备份，否则数据库将保持自动截断模式，您将无法备份日志文件。
在sql服务器2008之前，有几个命令，即带有 BACKUP LOGWITH NO_LOG 或 BACKUP LOG WITH TRUNCATE_ONLY（它们在功能上是等价的），当发布时，将强制截断日志文件，从而打破日志链。您不应该在sql服务器的任何版本中发布这些命令，我在这里提到它们，是因为它们仍然被误用，当试图处理一个“失控的日志文件”，不了解它对他们恢复数据库的能力的影响。想知道更多细节看看第八层--救命，我的日志已经满了。
尾部日志备份
只要您有最近的完整备份和完整的日志链，就可以在任何失败之前将数据库恢复到最终日志备份结束时的状态。但是，假设您每小时、每小时都使用事务日志备份，在下午1:45发生故障。您可能会损失45分钟的数据；实际上，如果故障是灾难性的，导致实时事务日志无法恢复，那么您将损失的数据量就是这45分钟的数据。
但是，即使数据文件不是动态的，有时仍然可以使用动态事务日志，特别是如果事务日志包含在单独的专用驱动器上。如果是这种情况，则应备份正在运行的事务日志，即执行自上次日志备份以来生成的日志记录的最后备份。这将捕获实时日志文件中的剩余日志记录，直到故障点。这称为跟踪日志备份，是在开始还原和恢复操作之前应该执行的最后一个操作。
跟踪日志备份和最小日志操作
如果数据库失败导致数据文件不可用，且日志尾部包含的日志操作最少，则不可能进行尾部日志备份，因为这将需要访问数据文件中已更改的数据区域。这将在第6级中更详细地描述，以批量日志模式管理事务日志。
如果要还原的数据库在线，则日志的尾部将被备份如下：
BACKUP LOG DatabaseNameTO DISK
='FileLocation\DatabaseName_Log.bak'WITH NORECOVERY
不恢复（NORECOVERY）选项将数据库置于还原状态，如果您希望执行的下一个操作是还原。如果数据库离线且无法启动，您仍应尝试像刚才描述的那样备份日志的尾部（可以省略不恢复选项，因为不会有任何事务在进行中）。
如果您确定日志文件已被损坏，则文档建议，作为最后的手段，您尝试使用以下方法进行跟踪日志备份：
BACKUP LOG DatabaseNameTO DISK
='FileLocation\DatabaseName_Log.bak'WITH CONTINUE_AFTER_ERROR
如果主数据库和数据文件损坏，但日志可用，微软建议重建主数据库，然后备份最后一个活动日志。然而，这些主题是在这个阶梯的范围之外，我请你参考文件的进一步细节。http://msdn.microsoft.com/en-us/library/ms190952.aspx.
进行修复和恢复
执行了尾标备份后，如果可能的话，下一步是恢复最后一个完整备份（如果适当的话，然后是差异备份），然后恢复日志备份文件的完整序列，包括尾标备份。这个还原操作序列的基本语法如下：
RESTORE {DATABASE | LOG} DatabaseNameFROM DISK
='FileLocation\FileName.bak'WITH NORECOVERY;
如果在还原时省略了带不恢复选项，则默认情况下还原命令将继续进行恢复。换句话说，sql服务器将尝试协调数据和日志文件，向前滚动已完成的事务，然后在必要时回滚未完成的事务。通过使用不恢复选项指定，我们指示sql服务器，我们正在输入一个还原序列，在执行任何回滚之前，必须向前滚动更多的操作。在还原还原序列中的最后一个备份之后，数据库可以按以下方式恢复：
RESTORE DATABASE DatabaseName WITH RECOVERY
常见的要求是将数据库还原到不同的位置，在这种情况下，您可以简单地移动文件作为还原过程的一部分，如下所述：
http://msdn.microsoft.com/en-us/library/ms190255.aspx.
数据库失败后恢复
下面的示例描述了如何针对失败恢复数据库，数据库数据文件不再可访问。
完全恢复到故障点
假设在数据库失败之后，可能是硬件失败导致了“实时”事务日志，那么理论上应该可以通过使用以下步骤将数据库还原和恢复到故障点：
（1）备份日志的尾部
（2）还原最近一次的完全备份（如果适用，附加差异）
（3）依次还原在完整备份（或差异备份）之后进行并在故障时间之前完成的每个事务日志备份
（4）还原尾部日志备份
（5）恢复数据库
许多在线书籍上的例子展示了从一个“备份集”恢复和恢复，换句话说，一个存储所有备份的“设备”。实际上，这意味着备份到磁盘时，备份设备是单个的.bak文件位于该磁盘的某处。
例如，表5.2所示的简单示例使用一个由一个完整备份和一个事务日志备份组成的备份集，并演示如何执行完整还原。为了运行此代码，您首先需要重新创建testdb数据库，然后插入几行样例数据（为了方便起见，将在此级别的代码下载中包含创建和流行的脚本）。您还需要在本地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 setBACKUP DATABASE TestDBTO DISK = 'C:\Backups\TestDB.bak'WITH FORMAT;
GO
-- Perform a transaction log backup of the Test database-- This is the second file in the setBACKUP Log TestDBTO DISK = 'C:\Backups\TestDB.bak'
GO
-- ....<FAILURE OCCURS HERE>....
-- The RESTORE HEADERONLY command is optional.-- It simply confirms the files that comprise -- the current setRESTORE HEADERONLYFROM 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 setBACKUP Log TestDBTO DISK = 'C:\Backups\TestDB.bak'WITH NORECOVERY;
GO
-- Restore the full backupRESTORE DATABASE TestDBFROM DISK = 'C:\Backups\TestDB.bak'WITH FILE=1, NORECOVERY;
-- Apply the transaction log backupRESTORE LOG TestDBFROM DISK = 'C:\Backups\TestDB.bak'WITH FILE=2, NORECOVERY;
-- Apply the tail log backupRESTORE LOG TestDBFROM DISK = 'C:\Backups\TestDB.bak'WITH FILE=3, NORECOVERY;
-- Recover the databaseRESTORE DATABASE TestDBWITH RECOVERY;
GO
表5.2：备份和恢复备份集（不推荐）
然而，使用备份集是数据库备份到磁带时遗留下来的。当备份到磁盘时，不能用这个方案，当然是因为备份文件很快变得非常大。
在实践中，每个完整的备份和事务日志备份文件都将被单独命名，并可能以备份的时间和日期为标记，这是非常常见的。例如，大多数第三方备份工具、流行的社区生成的脚本，加上数据库集成开发环境中的维护计划向导/设计器，都将创建单独的日期标记文件，例如AdventureWorks_FULL_20080904_000001.bak.
因此，更常见的备份和还原方案将使用单独命名的备份，如表5.3所示。
BACKUP DATABASE TestDBTO DISK ='C:\Backups\TestDB.bak'WITH INIT;
GO
-- Perform a transaction log backup of the Test databaseBACKUP Log TestDBTO DISK ='C:\Backups\TestDB_log.bak'WITH INIT;
GO
-- ....<FAILURE OCCURS HERE>....
-- Back up the tail of the log to prepare for restoreBACKUP Log TestDBTO DISK ='C:\Backups\TestDB_taillog.bak'WITH NORECOVERY, INIT;
GO
-- Restore the full backupRESTORE DATABASE TestDBFROM DISK = 'C:\Backups\TestDB.bak'WITH NORECOVERY;
-- Apply the transaction log backupRESTORE LOG TestDBFROM DISK = 'C:\Backups\TestDB_log.bak'WITH NORECOVERY;
-- Apply the tail log backupRESTORE LOG TestDBFROM DISK = 'C:\Backups\TestDB_taillog.bak'WITH NORECOVERY;
-- Recover the databaseRESTORE DATABASE TestDBWITH RECOVERY;
GO
表5.3：备份和恢复独立命名的备份文件
及时还原到最后一个良好的日志备份
不幸的是，有时可能无法执行完全还原；例如，如果由于失败而无法使用正在运行的事务日志。在这种情况下，我们只需要还原到最近的日志备份结束。需要为这种可能的情况做好准备，即包含事务日志的驱动器发生故障，这就决定了是否经常进行日志备份。如果你每15分钟做一次备份，那么你就会面临15分钟数据丢失的风险。
想象一下，我们已经执行了表5.4中显示的备份序列。为了这个演示，我们覆盖了以前的备份文件，而且备份序列显然比实际情况缩短了很多。
-- FULL BACKUP at 2AMUSE master ;BACKUP DATABASE TestDBTO DISK = 'C:\Backups\TestDB.bak'WITH INIT ;
GO
-- LOG BACKUP 1 at 2.15 AMUSE master ;BACKUP LOG TestDBTO DISK = 'C:\Backups\TestDB_log.bak'WITH INIT ;
GO
-- LOG BACKUP 2 at 2.30 AMUSE master ;BACKUP LOG TestDBTO DISK = 'C:\Backups\TestDB_log2.bak'WITH INIT ;
GO
表5.4：一系列简短的日志备份
如果在凌晨2:30后不久发生了灾难性的故障，我们可能需要将数据库恢复到日志备份2结束时的状态，即凌晨2:30。
这样的例子中的还原序列和我们在第5.3项中看到的非常相似，但是由于尾部备份是不可能的，我们只能恢复到某个点，我们需要使用停止选项，如清单5.5所示。
--RESTORE Full backupRESTORE DATABASE TestDBFROM DISK = 'C:\Backups\TestDB.bak'WITH NORECOVERY;
--RESTORE Log file 1RESTORE LOG TestDBFROM DISK = 'C:\Backups\TestDB_log.bak'WITH NORECOVERY, STOPAT = 'Jan 01, 2020 12:00 AM';
--RESTORE Log file 2RESTORE LOG TestDBFROM DISK = 'C:\Backups\TestDB_Log2.bak'WITH NORECOVERY, STOPAT = 'Jan 01, 2020 12:00 AM';
--Recover the databaseRESTORE DATABASE TestDBWITH RECOVERY;
GO
表5.5：恢复到一个时间点，使用停止在（STOPAT）
由于我们已经在未来指定了一个停止时间，这个代码将把所有已完成的事务滚动到第二个事务日志的末尾。
或者，可以指定在特定日志文件中记录的事务的时间范围内的停止时间。在这种情况下，数据库将在指定的时间恢复到最后一次提交的事务。您知道要恢复到什么时间的话很有帮助，但不知道该时间日志备份包含了什么。
你也可以还原到特定标记的事务。例如，当您需要将一个应用程序访问的多个数据库还原到逻辑一致的点时，这是很有用的。在这里不对这个题目作进一步讨论，但你可以在网上找到更多(http://msdn.microsoft.com/en-us/library/ms187014.aspx)
Mladen Prajdic提供了一个很好的例子：
“不良交易”后恢复
在数据库失败的情况下，可能有必要恢复数据库备份和事务日志，以便在错误的数据修改之前将数据库返回到特定的时间点，这样的丢失或截断表。
你对这种情况的反应将取决于问题的性质。如果可能的话，您可以将所有用户从数据库中断开（在通知他们之后），并评估刚刚发生的事情的含义。在某些情况下，您可能需要估计问题发生的时间，然后使用时间还原点对数据库和日志进行完全恢复。一旦还原完成，您必须通知用户一些事务可能已经丢失，并请求原谅。
当然，通常情况下，您将无法以这种方式中断正常的业务操作，来修复意外的数据丢失。由于现场数据库仍处于运行状态并被访问，可以尝试在备用模式下恢复数据库的备份。这样可以恢复更多的日志备份，但与使用不恢复时不同的是，数据库仍然是可读的。还原方案可能是这样的：
（1）恢复数据库的备份，在备用模式下，与动态数据库一起
（2）将日志向前滚动到错误事务发生之前的点，数据丢失。
（3）将丢失的数据复制到实时数据库，并删除已还原的副本
当然，这个过程不但不简单，而且相当耗时。除非你购买了一个专门的日志读取工具，并且可以直接查询日志备份，否则向前滚动日志可能意味着一系列艰苦的步骤，包括恢复日志、检查数据、进一步恢复等等，直到你弄清楚错误的事务发生在哪里。步骤3也可能是困难的，因为您将把数据引入到动态系统中，而这些数据不一定与数据库的当前状态一致，因此可能存在引用完整性问题。
让我们来看一个实现上述步骤1和2的例子。首先，让我们从头开始，运行创建和流行的sql脚本来重新创建testdb数据库，并将10行测试数据插入到新的日志测试表中。在表5.6中，我们只需要做一个完整的数据库备份（覆盖任何先前的备份文件）。如果尚未创建“备份”目录，则需要创建“备份”目录，或酌情调整路径。
-- full backup of the databaseBACKUP DATABASE TestDBTO DISK ='C:\Backups\TestDB.bak'WITH INIT;
GO
清单5.7：在TestDB插入第11行
现在我们有一个有11行的实时测试数据库和一个有10行的备份版本。现在让我们在日志备份中捕获额外的修改，如表5.8所示。
USE master
GOBACKUP Log TestDBTO DISK ='C:\Backups\TestDB_log.bak'WITH INIT;
GO
表5.8：日志备份TestDB
现在，我们要模拟一个错误的“糟糕的事务”，只要删除日志测试表，然后做最后的日志备份。
USE TestDB
GODROP TABLE dbo.LogTest ;
USE master
GOBACKUP Log TestDBTO DISK ='C:\Backups\TestDB_log2.bak'WITH INIT;
GO
表5.9：灾难！
为了在不中断正常业务的前提下试图恢复丢失的数据，我们将在备用模式下恢复一个testdb数据库的副本。备用数据库的数据和日志文件被移到“备用”目录（您需要事先创建这个目录）。
-- restore a copy of the TestDB database, called-- ANewTestDB, in STANDBY modeUSE master ;
GORESTORE 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数据库中的日志测试表的查询将显示10行。然而，我们希望将表恢复到它被错误丢失之前的状态。因此，下一步是对备用数据库执行还原日志备份。
USE master
GORESTORE LOG ANewTestDBFROM DISK = 'C:\Backups\TestDB_log.bak'
WITH STANDBY='C:\Backups\ANewTestDB_log.bak'
表5.11：在待机模式下恢复newtestdb数据库的日志备份
此时，对ANewTestDB的查询显示了11行，我们现在可以将这些数据复制回实时数据库了。如果我们更进一步，恢复第二个日志备份，我们就会意识到我们做得太过分了，备用数据库中也会缺少这个表。
做备用还原的替代方法是考虑使用第三方工具，比如红门的sql虚拟还原，它提供了一种不需要物理还原就可以作为实时、功能齐全的数据库安装备份的方法。
不管数据库管理员喜欢与否，开发人员通常都可以访问生产数据库来执行特定的数据加载和更改。数据库管理员和开发者的共同责任是确保这些过程顺利进行，从而避免引发需要采取上述行动的问题。稍后我们将在第6级讨论大型操作时回到这个话题。
当然，所要求的赔偿行动的确切性质取决于不良事务的性质。如果一个表格“不小心掉了”，那么你很可能是在沿着备用路线往前走。在其他时候，你可以简单地创建一个脚本来“逆转”流氓的修改。
如果损坏只影响到单列或有限的行数，那么作为一种替代方法，可能使用sql数据比较等工具，可以直接与备份文件进行比较，并可以进行行级还原。
或者，如果您运行sql服务器2005（或以后的）企业版，并提供了最近的数据库快照，则您可以对快照运行查询，以便在数据库快照拍摄时查看数据，然后编写一个更新或插入命令，将数据从数据库快照中放到正在运行的源数据库中。
作为最后的手段，一个专门的日志读取工具可以帮助您消除事务的影响，尽管我完全不知道在sql服务器2005和以后版本工作可靠性。
总结
在这个级别中，我们已经涵盖了备份和还原数据库日志文件的基本知识，这些日志文件在完全恢复模式下运行，这将成为许多生产数据库的常规。
对于大多数数据库管理员来说，执行点内还原的需要是一个罕见的事件，但如果有必要的话，它是其中的一项任务，它的完成和完成是绝对关键的；数据库管理员的声誉取决于它。
在腐败、驱动失败等情况下，可能涉及到点的及时恢复，如果你幸运的话，备份事务日志的尾部并恢复到故障点。如果没有可用的事务日志，或是为了在“坏事务”发生之前回到某个时间点，那么情况就会变得更复杂，但希望这个步骤中包含的一些技术会有所帮助。
资源：
事务阶梯-5级代码
本文是sql服务器楼梯中事务日志管理的一部分