事务日志备份与还原

†事务日志备份与恢复原理一个不懂事务日志的DBA，是很难掌握数据库的精髓的。事务日志忠实地记录了数据库的活动，所以基于这些记录的活动就可以随心所欲地将数据库的状态恢复到特定的即时点或本章深入研究事务日志备份与恢复操作。14.1事务日志备份与恢复原理下面我们首先来学习事务日志备份与恢复的原理。14.1.1事务日志备份与恢复原理事务日志备份只能与完全恢复模型和大容量日志记录恢复模型一起使用。在简单模型可以使用事务日志备份将数据库恢复到特定的即时点（如输入多余数据前的那一点）或当SQLServer2005到达事务日志地创建事务日志备份。经常备份将减少丢失数据的危险。图14-1所示为基于完全恢复模型下的1个完全备份＋N个连续的事务日志备份的策略。如果中间的日志备份02删除或者损坏，则数据库只能恢复到日志备份01的即时点。假如日志备份01、02和03都是完整的，那么在恢复时，先恢复数据库完全备份，然完整，如果是完整的，可以做一个当前日志的备份，然后依次恢复日志备份04就可以了。可以在恢复数据库完全备份后，恢复数据库在完全备份和日志备份01中间的某个时刻，这间序列，否则系统不会执行。比如现在只有日志备份01，其时刻为12:11，假如我们指定恢复到12:12，那么这样的时点是非法的。14.1.2事务日志备份连续的奥秘中的事务日志备份，判断其是否连续。restoreheaderonlyfromdisk='c:\test2.bak'因为这些事务日志备份的LSN首尾连接，后一个日志备份的FirstLSN等于前一个日志—日志备份（编号2FirstLSN：290179，LastLSN：290001。—日志备份（编号3FirstLSN：290001，LastLSN：300001。—日志备份（编号4FirstLSN：300001，LastLSN：300001。290179。终点是最后一个日志备份的LastLSN：300001。不连续的日志备份就是指在产生的日志备份序列中，出现了前后首尾不能续接的情况。这种情况主要发生在初学或者刚开始做DBA的读者身上，不断切换数据库的恢复模型，比如从简单恢复模型切换到完全恢复模型，或者从完全恢复模型切换到大容量日志记录模型，假如你的日志备份出现下列情况。那么，这样的日志序列LSN首尾不能衔接，无法连—日志备份（编号2FirstLSN：290179，LastLSN：290001。—日志备份（编号3FirstLSN：300001，LastLSN：300001。14.1.3恢复到即时点的奥秘将数据库的状态恢复在日志序列中间的任意一个即时点。但是，这样做是有前提条件的。首先，必须要有一个正确的完整数据库备份，为什么这里要强调“正确”二字呢？如果读者已经对事务日志的连续性概念有正确认识和理解的话，那么这里的“正确”二字就代表完整数据库备份必须是在第1个日志备份序列的时间点之间完成的。事务日志备份1中间的某个即时点。然后可以连续执行事务日志备份来进行恢复。就是完整数据库备份完成的即时点处于日志备份序列之外。如图14-4所示。我们可以把这个过程理解为火车的工作机制。火车头（完整数据库备份）和车厢（日志即时点）！同样，如果车厢之间发生断裂（事务日志备份序列断裂），我们就只能走到相连接的部分（恢复连续的日志备份序列），其余部分没有任何意义！这句话的含义是，永远不要指望将数据库的状态恢复到日志序列记录的LSN区间之外！这很好理解，因为LSN没有记录的数据库活动，数据库的恢复机制无凭无据，如何恢14.1.4恢复到故障点的奥秘无论我们翻阅SQLServer2005的联机丛书，还是我们查阅有关的资料，都会告诉我我们首先从原理上来理解恢复到故障点的奥秘，如图14-5所示。从图中我们可以看出，要将数据库恢复到故障点，必须满足3个条件。除非存储设备出现故障，否则这个问题也很好解决。这一点在目前的SQLServer2005的图书中几乎没有提到！稍微有点实际经验的DBA（这里是指真正从事大型数据库管理的DBA），肯定会意识到这个问题的严重性！那么，在最后一个日志备份完成的时刻到故障点之间的日志呢？等待DBA的将是被老板炒鱿鱼的悲惨命运！因此，要想完成故障点的恢复，就必须完成尾日志的备份。接下来我们就来学习尾日志志备份到当前故障点所有的事务。比如存放日志文件的硬盘损坏，那么这种情况下，上帝也无法挽救一个DBA的命运！点。自上一次事务日志备份后对数据库所做的更改将丢与正常日志备份在下列几个方面有所不同。—如果数据库损坏或离线，则可以尝试进行尾日志备份。仅当日志文件未损坏且数据库不包含任何大容量日志更改时，尾日志备份才会成功。如果数据库包含要备份的、在记录间隔期间执行的大容量日志更改，则仅在所有数据文件都存在且未损坏的情况下，尾日志备份才会成功。—尾日志备份可使用COPY_ONLY选项独立于定期日志备份进行创建。仅复制备份不会影响备份日志链。事务日志不会被尾日志备份截断，并且捕获的日志将包括在以后的正常日志备份中。这样就可以在不影响正常日志备份过程的情况下进行尾日志备份，例如，为了准备进行在线还原。—如果数据库损坏，则尾日志可能会包含不完整的元数据，这是因为某些通常可用于日志备份的元数据在尾日志备份中可能会不可用。使用CONTINUE_AFTER_ERROR进行的日志备份可能会包含不完整的元数据，这是因为此选项将通知进行日志备份而不考虑数据库的状态。对于将数据库恢复到即时点，很好理解也很好操作。下面我们重点来研究将数据库恢复到故障点时必不可少的操作，即尾日志备份。14.2.1图形化尾日志备份操作图14-7所示为选择日志备份的数据库的【选项】选项卡。默认情况下选择的是【截断事务日志】单选按钮，这样将永远无法备份尾日志。也可以直接执行BackupLog语句来完成日志备份。下面介绍该语句的语法形式。BACKUPLOG{database_name|@database_{]}对于其他参数读者可以参阅联机丛书的有关说明。与备份尾日志有关的主要参数如下。—NO_TRUNCATE：只与BACKUPLOG一起使用。指定不截断日志，并使数据库引擎尝试执行备份，而不考虑数据库的状态。该选项允许在数据库损坏时备份日—BACKUPLOG的NO_TRUNCATE选项相当于同时指定COPY_ONLY和CONTINUE_AFTER_ERROR。—NO_LOG|TRUNCATE_ONLY：通过放弃活动日志以外的所有日志，无须备份复制日志即可删除不活动的日志部分，并截断日志。该选项会释放空间。因为并可恢复。为了进行恢复，请立即执行BACKUPDATABASE以执行完整备份或完整要备份尾日志，主要使用Truncate_Only参数就可以。本书的实例代码如下。WITHNO_TRUNCATE,NOFORMAT,NAME=N'db_test-事务日志备份',SKIP,NOREWIND,NOUNLOAD,NORECOVERY,通过前面的学习，我们已经知道SQLServer2005数据库提供了将数据库的状态恢复坏，否则将丢失最后一次日志备份完成时刻到故障点的事务。很多DBA不了解这其中的奥秘，往往会想当然地认为利用已有的备份日志就可以将数接下来我们通过一个具体的实例来完成将数据库恢复到故障点的功能。案例的设计和完成的思路如下。（1）新建数据库db_test，数据库工作在完全恢复模型下，新建表t_clusterindextest，向表中录入1001条数据。查询得到数据库的日志文件记录的日志区间。（2）做一次完整数据库备份。查询得到备份后的数据库的日志区间和备份集中的日志（3）删除99条数据，产生事务日志，查询得到数据库的日志区间。（4）第1次完成事务日志备份，按照默认设置就可以，即不是尾日志备份。查询备份后的数据库日志区间和备份集的日志区间。（5）删除101条数据，产生事务日志，查询得到数据库的日志区间。（6）第2次完成事务日志备份，按照默认设置就可以，即不是尾日志备份。查询备份后的数据库日志区间和备份集的日志区间。（8）备份尾日志，然后尝试进行恢复操作。在备份过程形成的最后的备份集中，我们可以这样来进行验证。（1）利用完整数据库备份＋日志备份1，可以将数据库恢复到删除99条记录的状态。（2）利用完整数据库备份＋日志备份1＋日志备份2，可以恢复到将数据库删除200条记录的状态，而无法将数据库恢复到删除201条记录的状态。备份来将数据库恢复到删除201条记录的状态。刻理解联机日志千万不能出故障的根本原因。接下来介绍如何形成备份集。按照与前面章节同样的办法，创建新的db_test数据库。创建表t_clusterindextest，生执行dbcclog命令查询此时数据库的日—第1条日志记录的CurrentLSN：0000001d:0000001a:0001。—最后1条日志记录的CurrentLSN：0000001d:00000137:00a2。—第1条日志记录的CurrentLSN：0000001d:00000166:00b3。—最后1条日志记录的CurrentLSN：0000001d:000001b5:0003。（3）执行restoreheaderonly命令查询备份集中图14-12产生完整数据库备份后的备份集日志Ø—FirstLSN：290179。Ø—LastLSN：290001。Deletefromdb_test.dbo.t_clusterindextestWherettid<=99—第1条日志记录的CurrentLSN：0000001d:00000166:00b3。—最后1条日志记录的CurrentLSN：0000001d:000001ba:0067。WITHNOFORMAT,NAME=N'db_test-事务日志备份SKIP,NOREWIND,NOUNLOAD,—第1条日志记录的CurrentLSN：0000001d:00000166:00b3。—最后1条日志记录的CurrentLSN：0000001d:000001ba:0067。Deletefromdb_test.dbo.t_clusterindextestWherettid>99ANDttid<=200—第1条日志记录的CurrentLSN：0000001d:00000166:00b3。—最后1条日志记录的CurrentLSN：0000001e:00000010:0008。（4）执行dbcclog命令查询备份后的数据库—第1条日志记录的CurrentLSN：0000001e:00000013:0001。—最后1条日志记录的CurrentLSN：0000001e:00000027:0001。（5）执行restoreheaderonly命令查询备份集中deletefromdb_test.dbo.t_clusterindextestwherettid=555—第1条日志记录的CurrentLSN：0000001e:00000013:0001。—最后1条日志记录的CurrentLSN：0000001e:0000004c:0005。（1）选择备份日志，在如图14-21所示的选项卡中选择进行尾日志备所有的操作执行完毕后，执行dbcclog命令查询数据库的日志如图14-23所示。—第1条日志记录的CurrentLSN：0000001e:00000013:0001。—最后1条日志记录的CurrentLSN：0000001e:00000050:0001。14.4在线恢复到故障点据库msdb中存储的数据库备份信息，但使用的日志还是备份集中的日志。14.4.1存储备份信息的系统表信息，可以通过执行下列语句来完成。select*frommsdb.dbo.backupset14.4.2在线恢复到故障点在ManagementStudio中选择还原数据库，出现如图14-26所示的【常规】选项卡。如果数据库被损坏，我们就只能利用备份集文件（通常扩展名为BAK）来恢复数据库，如果备份集中包含了尾日志备份，我们同样能将数据库恢复到故障点。前面我们已经介绍了使用restoreheaderonly命令可以查看备份集文件的头部信息。这里的信息和msdb系统数据库中保存的信息是一致的。在ManagementStudio中选择还原数据库，选择从设备还原，设置设备为bak文件，然而，令我们吃惊的是，尽管备份集中有3个日志备份（2个日志备份＋1个尾日志备份），而且这3个日志备份的LSN是前后续接的，但是在图14-26中我们只能发现2个日志备份的序列，尾日志备份序列不可见，经过笔者的反复实验，这个问题始终存在。份序列和前面的日志备份序列首尾连接，但是在图形化界面中确实无法选择。最后成功完成尾日志恢复的语句实例如下。NORECOVERY,NOUNLOAD,REPLACE,NORECOVERY,NOUNLOAD,NORECOVERY,NOUNLOAD,NOUNLOAD,下面的语句为恢复尾日志的语句。NOUNLOAD,可以看出，上述恢复尾日志的语句和恢复日志序列语句是不同的。NORECOVERY,NOUNLOAD,最本质的不同，是尾日志恢复少了一个参数NORECOVERY。RECOVERY参数指示还原操作回滚任何未提交的事务。在恢复进程后即可随时使用数据库。如果既没有指定NORECOVERY和RECOVERY，也没有指定STANDBY，则默认为RECOVERY。NORECOVERY参数指示还原操作不回滚任何未提交的事务。如果稍后必须应用另一个事务日志，则应指定NORECOVERY或STANDBY选项。使用NORECOVERY选项执行脱机还原操作时，数据库将无法使用。还原数据库备份和一个或多个事务日志时，或者需要多个RESTORE语句（例如还原一WITHNORECOVERY选项，但最后的RESTORE语句除外。14.5.3验证是否恢复到故障点（2）执行dbcclog语句，查询恢复后的数据库的日志情况如图14-29—第1条日志记录的CurrentLSN：0000001e:00000013:0001。—最后1条日志记录的CurrentLSN：0000001e:00000064:000a。在图14-23中，我们知道发生尾日志备份后的数据库日志的最后一条日志记录的Curee由于恢复后的日志记录的LSN（0000001e:SN（0000001e:00000050:0001），所以我们得出结论，我们的恢复操作确实将数据库恢复到了故障点。多余出来