MSSQL· 最佳实践· SQL Server三种常见备份

场景引入

在开始今天关于SQL Server数据库备份链的分享之前，我们还是以上一期SQL Server备份策略分享的场景引入。假设我们存在如下图所示的备份文件列表，为什么我们就可以使用“全备 + 差备 + 日志备份”来实现快速的数据库还原操作呢？我们又是如何快速的查找到TestDR数据库的备份链条，并以此来还原的呢？这两个话题是我们今天要解答和解决的。 TestDR数据库备份文件列表如下图所示：

在解决今天的问题之前，我需要首先介绍一个非常重要的概念：LSN。SQL Server的每一个事务日志都有自己的唯一标识号Log Sequence Number(简写为LSN)。LSN会随着时间的推移和事务日志的产生而不断增大。那么在SQL Server中如何查看以及有几种类型的LSN呢？

备份文件LSN

在SQL Server中，查看备份的LSN非常简单，我们可以使用RESTORE HEADERONLY命令跟上备份文件路径，即可查看。

从以上截图红色方框中我们可以看出来，SQL Server的LSN分为以下四类：

  • FirstLSN：备份集中第一个事务日志的LSN；
  • LastLSN：备份集中最后一个事务日志的下一个LSN；
  • CheckpointLSN：最后一个Checkpoint发生时的LSN；
  • DatabaseBackupLSN：最后一个FULL Backup备份的LSN。

LSN是查找SQL Server 数据库备份链不可或缺的神一般存在的关键信息。我们可以利用前面讲到的四类LSN，使用如下五步骤来实现SQL Server备份链的查找。

  • 获取Full Backup: 查找最新一个FULL Backup文件，拿到对应CheckpointLSN；
  • 获取第一个Log Backup：查找第二步中的LastLSN位于Log Backup文件的FirstLSN和LastLSN之间的Log Backup，并获取相应的LastLSN；
  • 获取下一个Log Backup: 下一个Log Backup文件的FirstLSN等于第三步中获取到额LastLSN；
  • 获取第N个Log Backup：按照步骤四中的方法查找，直到所有日志文件查找完毕后，一个完整的备份链条查找完毕。

以上的理论解释稍显枯燥，我们用具体的示例来解释，就显得更为丰满和易于理解。我们把“场景引入”中的十五个备份文件，参照“备份文件LSN”中的方法来获取到LSN，如下面的截图所示： 03.png

那么，TestDR数据库的备份链可以通过如下的方法来查找：

  • 获取Full Backup: 查找最新一个FULL Backup（BackType=1）文件，拿到CheckpointLSN：24000000012800197，图中红色方框标示；
  • 获取Diff Backup：查找Diff Backup（BackType=5）文件，Diff Backup文件的DatabaseBackupLSN等于第一步中的CheckpointLSN:24000000012800197，图中黄色方框标示，取FirstLSN最大者: 24000000037600007，然后拿到LastLSN: 24000000039200001；
  • 获取第一个Log Backup：查找第二步中的LastLSN（24000000039200001）位于Log Backup（BackType=5）的FirstLSN（24000000036800001）与LastLSN（24000000040000001）之间的Log Backup，如图中绿色方框标示，并获取到LastLSN：24000000040000001；
  • 获取第N个Log Backup：按照步骤四中的方法查找，直到所有日志文件查找完毕。 所以，我们最终获取到的TestDR数据库的最简单，快速恢复的备份链是：

这个链条和我们上一期分享的数据库备份文件还原操作是完全吻合的。

具体实现

备份链结果截图展示如下：

从这个截图中，restore_order和Backup_file字段可以很清楚的看到数据库还原的顺序，以及相应的备份文件路径。所有备份文件的LSN分布如下截图： 05.png

从备份链条我们发现，12:00的这个差异备份C:\Temp\TestDR_20171217@12:00_DIFF.bak非常关键，假设现实中，我们发现这个文件恰恰损坏掉了，那么我们的可以实现应用的数据库还原吗？答案是肯定的，我们把刚才的脚本输入参数修改如下：

得到如下备份还原链条：

从这个结果，我们可以看到，系统选择了06:00这个差异备份文件，然后一步步使用接下来的事务日志备份文件进行还原。

最后总结