SQL Server中事务日志管理的阶梯,级别5:以完全恢复模式管理日志
Tony Davis, 2012-01-27
在此级别中,我们将查看在FULL
恢复模式下工作时为何以及如何进行日志备份,以及如何使用这些日志备份文件以及完整数据库备份执行数据库还原。FULL
恢复模式支持将数据库还原到可用日志备份中的任何时间点,并假设可以在发生故障之前进行尾部日志备份,直到上次提交的事务的时间。
什么得到记录?
在FULL恢复模式下,所有操作都已完全记录。对于插入、更新和删除操作,这意味着对于修改的每一行,都会有一个日志记录,描述执行语句的事务的ID、事务开始和结束时、哪些页已更改、所做的数据更改等。
在FULL恢复模式下工作时,可以最低限度地记录的操作(选择进入、大容量插入和创建索引)仍然完全记录,但执行方式略有不同。受这些操作影响的行不是单独记录的;而是在数据库页被填充时只记录它们。这减少了人们听到的此类操作的日志记录,同时确保仍然存在执行回滚、重做和时间点恢复所需的所有相同信息。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)操作,包括进入FULL
和BULK_LOGGED
恢复模式。在BULK_LOGGED
模式下工作时,记录最小日志操作的差异将在第6级 - 管理 BULK LOGGED 恢复模式中的日志中进行更详细的讨论。
为什么要备份事务日志?
在FULL恢复模式下,只有日志备份才能导致日志截断。因此,事务日志将保存自上次备份事务日志以来执行的事务的完整记录。由于所有操作都已完全记录,因此在繁忙的系统中,日志文件可能会增长得非常大、非常快。
因此,在FULL恢复模式下工作时,除了执行完全备份和(可选)差异备份之外,还必须执行常规事务日志备份。许多新手或兼职DBA在其数据库上执行完整备份,但不执行事务日志备份。因此,事务日志不会被截断,并且会不断增长,直到它所在的驱动器耗尽磁盘空间,导致SQL Server停止工作。
在执行日志备份后,将立即截断日志,前提是自上次备份以来已发生检查点,并且没有其他因素延迟截断,例如数据备份或还原操作。有关可能延迟截断可恢复VLF的因素的完整列表,以及保持大量日志活动(否则不需要)的因素,例如恶意、长时间运行的未提交事务或数据库镜像或复制进程,请参阅:http://msdn.microsoft.com/en-gb/library/ms345414.aspx。
COPY_ONLY
备份事务日志
COPY_ONLY
事务日志的备份不会截断事务日志。一个COPY_ONLY
日志备份是否存在“独立”正常的日志备份方案; 它不会破坏日志备份链。
简而言之,事务日志备份的双重目的是允许恢复和恢复到以前的时间点,并控制事务日志的大小。可能与事务日志相关的问题最常见的原因是在完全恢复模式下工作,而不进行日志备份,或者不频繁地进行日志备份以控制事务日志文件的大小。
如果您不确定是否在给定的数据库上执行事务日志备份,那么您可以使用类似于清单5.1所示的查询,简单地查询MSDB
数据库中的backupst表。
-
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
列中,a D
表示数据库备份,L
日志备份和I
差异备份。
请注意,因为在这种数据备份集表可以在不影响备份被操纵和恢复的行为,您可能要验证此查询你的发现,通过查询sys.database_recovery_status
看到的值last_log_backup_lsn
(见清单3.5),或sys.databases
表格中显示的值of log_reuse_wait_desc
(LOG_BACKUP
如果需要备份,将返回)。
如何备份事务日志
如前所述,如果没有首先进行至少一次完整备份,则无法执行事务日志备份。实际上,如果您的数据库处于FULL
恢复模式但从未进行过备份,那么它实际上不会在FULL
恢复模式下工作。数据库将处于自动截断模式,直到执行第一次完全备份。
使用该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';
存储日志备份
显然,备份的数据和日志文件不应存储在托管实时文件的同一驱动器上。如果该驱动器遭受硬件故障,那么所有副本将与实时文件一起丢失,备份将是徒劳的。这些文件应备份到单独的设备,或备份到本地镜像驱动器。
日志备份的频率
如前面的级别所述,您可能每15分钟或甚至更频繁地进行日志备份。在这种情况下,为了避免需要恢复大量的事务日志文件,您可以选择采用备份方案,其中包含散布有差异备份的完整备份,其中散布着事务日志备份。
实际上,备份方案通常在理想和实际之间,在评估数据丢失的真实风险,公司成本以及降低风险所涉及的成本之间做出妥协。许多非常重要的业务应用程序使用稍微简单但仍然严格的备份方案,可能涉及定期夜间完整备份以及每小时事务日志备份。
日志备份的频率也可以由数据库所经历的事务的数量决定。对于非常繁忙的数据库,可能需要经常备份以控制日志的大小。
没有简单的方法来计算日志备份的频率。大多数DBA会对日志备份的频率进行最佳估计,然后观察文件的增长特性,然后根据需要调整备份方案,以防止它们变得过大。
日志链以及如何打破它
如上所述,如果没有首先进行至少一次完整备份,则无法执行事务日志备份。为了将数据库恢复到某个时间点,或者在特定日志备份的末尾或特定日志备份中的某个时间点,必须存在完整的不间断的日志记录链,从第一次日志备份开始在完整(或差异备份)之后,直到故障点。这称为日志链。
有许多方法可以打破日志链,如果这样做,则意味着您只能将数据库恢复到在事件发生之前进行日志备份的时间。简而言之,如果您关心恢复数据的能力,打破链条并不是一个好主意。打破链条的两种最常见的方法包括:
- 事务日志备份文件丢失或损坏 - 您只能恢复到上一个良好的日志备份。日志链将在下一个良好的完整或差异备份时再次启动。
- 切换到
SIMPLE
恢复模式 - 如果您从切换FULL
到SIMPLE
恢复模式,这将打破日志链,因为将启动检查点并且可以立即截断事务日志。当您返回FULL
模式时,您需要再次进行完整备份以重新启动日志链。实际上,在进行完全备份之前,数据库将保持自动截断模式,您将无法备份日志文件。
在SQL Server 2008之前,有一些命令,即BACKUP
LOG
WITH NO_LOG
或BACKUP
LOG
WITH
TRUNCATE_ONLY
(它们在功能上等效),当发出时,会强制删除日志文件,从而破坏日志链。您不应该在任何版本的SQL Server中发出这些命令,但是我在这里提到它们,因为它们在尝试处理“失控的日志文件”时仍然被不小心使用,而不了解它对它们的能力的影响。恢复他们的数据库 有关更多详细信息,请参阅第8级 - 帮助,我的日志已满。
尾部日志备份
只要您具有最近的完整备份和完整的日志链,就可以在发生任何故障之前将数据库恢复到最终日志备份结束时存在的状态。但是,假设您每小时按小时执行事务日志备份,并在下午1:45发生故障。您可能会丢失45分钟的数据; 实际上,如果失败是如此灾难性以至于实时事务日志无法恢复,那么这就是您将丢失的数据量。
但是,有时即使数据文件不可用,实时事务日志仍然可用,特别是如果事务日志包含在单独的专用驱动器上。如果是这种情况,则应备份实时事务日志,即执行自上次日志备份以来生成的日志记录的最终备份。这将捕获实时日志文件中的剩余日志记录,直至故障点。这称为尾部日志备份,是在开始还原和恢复操作之前应执行的最后一个操作。
尾部日志备份和最少日志记录的操作
如果由于数据库故障导致数据文件不可用,并且日志尾部包含最少日志记录的操作,那么将无法执行尾部日志备份,因为这将需要访问更改的数据扩展区。数据文件。这将在第6级“ 以批量记录模式管理 事务日志”中进行更详细的介绍。
如果要还原的数据库处于联机状态,则会按如下方式备份日志尾部:
BACKUP LOG DatabaseNameTO DISK ='FileLocation\DatabaseName_Log.bak'WITH NORECOVERY
该NORECOVERY
选项将数据库置于还原状态,并假定您要执行的下一个操作是a RESTORE
。如果数据库处于脱机状态且无法启动,您仍应尝试按照刚才描述的方式备份日志尾部(尽管NORECOVERY
可以省略该选项,因为不会进行任何事务处理)。
如果您确定日志文件已损坏,则文档建议您作为最后的手段,尝试使用以下命令执行尾部日志备份:
BACKUP LOG DatabaseNameTO DISK ='FileLocation\DatabaseName_Log.bak'WITH CONTINUE_AFTER_ERROR
如果主数据库和数据文件已损坏,但日志可用,Microsoft建议重建master数据库,然后备份上一个活动日志。但是,这些主题超出了本Stairway的范围,我将向您介绍文档以获取更多详细信息。请参阅http://msdn.microsoft.com/en-us/library/ms190952.aspx。
执行还原和恢复
执行尾部日志备份后,如果可能,下一步是还原上次完整备份(如果适用,则执行差异备份),然后还原完整的日志备份文件序列,包括尾部日志备份。此序列还原操作的基本语法如下:
RESTORE {DATABASE | LOG} DatabaseNameFROM DISK ='FileLocation\FileName.bak'WITH NORECOVERY;
如果在恢复时省略了该WITH
NORECOVERY
选项,则默认情况下该RESTORE
命令将继续WITH
RECOVERY
。换句话说,SQL Server将尝试协调数据和日志文件,前滚已完成的事务,然后根据需要回滚未完成的事务。通过指定WITH
NORECOVERY
,我们指示SQL Server我们正在进入还原序列,并且在执行任何回滚之前必须前滚更多操作。在还原序列中还原最后一个备份后,可以按如下方式恢复数据库:
RESTORE DATABASE DatabaseName WITH RECOVERY
一个常见的要求是将数据库还原到其他位置,在这种情况下,您只需将文件作为还原过程的一部分进行移动,如下所述:http://msdn.microsoft.com/en-us/library/ms190255的.aspx。
数据库失败后恢复
以下示例描述了如何恢复数据库以响应故障,从而无法再访问数据库数据文件。
完全恢复到失败点
假设可能由于硬件故障导致数据库故障后可以到达“实时”事务日志,那么理论上应该可以通过使用以下步骤恢复和恢复数据库直到故障点:
- 备份日志的尾部
- 恢复最近的完整备份(加上差异,如果适用)
- 反过来,还原在完全(或差异)备份之后并在故障发生之前完成的每个事务日志备份
- 恢复尾部日志备份
- 恢复数据库
联机丛书中的许多示例演示了从“备份集”恢复和恢复,换句话说,是存储所有备份的单个“设备”。实际上,这意味着,备份到磁盘时,备份设备是.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-multiple-databases-to-a-common.aspx。
在“不良交易”之后恢复
在任何数据库故障的上下文之外,可能需要还原数据库备份和事务日志,以便在数据库进行错误数据修改之前将数据库返回到特定时间点,例如删除或截断表。
您对这种情况的回应将取决于问题的性质。如果可能,您可以断开所有用户与数据库的连接(通知后),并评估刚刚发生的事情的影响。在某些情况下,您可能需要估计问题发生的时间,然后使用时间点恢复完全恢复数据库和日志。恢复完成后,您必须通知用户某些交易可能已丢失,并请求原谅。
当然,通常您无法以这种方式中断正常的业务操作,以修复意外的数据丢失。由于实时数据库仍在运行并正在被访问,因此您可以尝试在STANDBY
模式下恢复数据库的备份。这允许恢复进一步的日志备份,但与使用时不同NORECOVERY
,数据库仍然可读。恢复方案可能如下所示:
- 在
STANDBY
模式下,与实时数据库一起还原数据库的备份 - 将日志前滚到错误事务发生之前的点,数据丢失。
- 将丢失的数据复制到实时数据库并删除已还原的副本
当然,这个过程不一定是直截了当的,而且可能非常耗时。除非您购买了专门的日志读取工具,并且可以直接查询日志备份,否则滚动日志可能意味着一系列艰苦的步骤,包括恢复日志,检查数据,进一步恢复等等,直到您已经确定了坏交易发生的确切位置。步骤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
在STANDBY
模式下恢复数据库的副本。备用数据库的数据和日志文件(称为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
in STANDBY
模式的副本
我们现在有一个名为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数据库STANDBY
此时,针对ANewTestDB的查询显示11行,现在我们可以准备将该数据复制回实时数据库。如果我们更进一步并恢复了第二个日志备份,我们就会意识到我们已经走得太远了,备用数据库中的表也会丢失。
执行备用还原的另一种方法是考虑使用第三方工具,例如Red Gate的SQL Virtual Restore,它提供了一种将备份挂载为实时,功能齐全的数据库而无需物理还原的方法。
无论DBA是否喜欢,开发人员通常都可以访问生产数据库来执行临时数据加载和更改。DBA和开发人员共同负责确保这些过程顺利进行,因此不会导致需要采取上述行动的问题。我们稍后将在第6级 - 处理批量操作中回到此主题。
当然,所需的赔偿行动的确切性质取决于不良交易的性质。如果一张桌子“意外掉落”,那么很可能你会沿着这RESTORE
WITH
STANDBY
条路走下去。在其他时候,您可以简单地创建一个脚本来“反转”流氓修改。
如果损坏只影响单个列或有限数量的行,那么可以使用SQL Data Compare等工具,它可以直接与备份文件进行比较,并可以进行行级恢复。
或者,如果您运行SQL Server 2005(或更高版本)Enterprise Edition,并且可以使用最近的数据库快照,则可以对快照运行查询,以便在查看数据库快照时查看数据,然后编写UPDATE
或INSERT
命令将数据从数据库快照拉入实时源数据库。
最后,作为最后的手段,专门的日志阅读器工具可以帮助您消除事务的影响,尽管我不知道SQL Server 2005及更高版本中的任何可靠工作。
摘要
在本级别中,我们已经介绍了为FULL
恢复模式下运行的数据库备份和恢复日志文件的基础知识,这将成为许多生产数据库的标准。
对于大多数DBA来说,执行时间点恢复的需求是一种罕见的事件,但它是其中一项任务,如果有必要,完成并完成它是绝对关键的; DBA的声誉取决于它。
在损坏,驱动器故障等情况下,如果幸运的话,时间点恢复可能涉及备份事务日志的尾部并恢复到故障点。如果事务日志不可用,或者您正在恢复以便在发生“错误事务”之前恢复到某个时间点,则情况变得更加棘手,但希望此步骤中涉及的一些技术将有所帮助。
本文是SQL Server中事务日志管理的父楼梯阶梯的一部分