title: MSSQL-最佳實踐-資料庫備份鍊
在SQL Server備份專題分享中，前兩期我們分享了三種常見的備份以及備份政策的制定，在第三期分享中，我們将要分享SQL Server的資料庫備份鍊。完整的資料庫備份鍊是保證資料庫能夠實作災難恢複的基礎，如果備份鍊條被打斷或者備份鍊條上的檔案損壞，勢必會導緻資料恢複不完整或者不能滿足預期，而造成資料丢失，危害資料完整性生命線，後果非常嚴重。是以，了解SQL Server資料庫備份鍊非常重要。
<a href="http://mysql.taobao.org/monthly/2017/11/03/">MSSQL· 最佳實踐· SQL Server三種常見備份</a>
<a href="http://mysql.taobao.org/monthly/2017/12/05/">MSSQL · 最佳實踐 · SQL Server備份政策</a>
在開始今天關于SQL Server資料庫備份鍊的分享之前，我們還是以上一期SQL Server備份政策分享的場景引入。假設我們存在如下圖所示的備份檔案清單，為什麼我們就可以使用“全備 + 差備 + 日志備份”來實作快速的資料庫還原操作呢？我們又是如何快速的查找到TestDR資料庫的備份鍊條，并以此來還原的呢？這兩個話題是我們今天要解答和解決的。
TestDR資料庫備份檔案清單如下圖所示：
在解決今天的問題之前，我需要首先介紹一個非常重要的概念：LSN。SQL Server的每一個事務日志都有自己的唯一辨別号Log Sequence Number(簡寫為LSN)。LSN會随着時間的推移和事務日志的産生而不斷增大。那麼在SQL Server中如何檢視以及有幾種類型的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；
擷取Diff Backup：查找Diff Backup檔案，Diff Backup檔案的DatabaseBackupLSN等于第一步中的CheckpointLSN，如果有多個Diff Backup檔案，取FirstLSN最大者，然後拿到相應LastLSN；
擷取第一個Log Backup：查找第二步中的LastLSN位于Log Backup檔案的FirstLSN和LastLSN之間的Log Backup，并擷取相應的LastLSN；
擷取下一個Log Backup: 下一個Log Backup檔案的FirstLSN等于第三步中擷取到額LastLSN；
擷取第N個Log Backup：按照步驟四中的方法查找，直到所有日志檔案查找完畢後，一個完整的備份鍊條查找完畢。
以上的理論解釋稍顯枯燥，我們用具體的示例來解釋，就顯得更為豐滿和易于了解。我們把“場景引入”中的十五個備份檔案，參照“備份檔案LSN”中的方法來擷取到LSN，如下面的截圖所示：
那麼，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；
擷取下一個Log Backup: 下一個Log Backup檔案的FirstLSN（24000000040000001）應該等于上一步擷取到額LastLSN，如圖中粉紅色标示；
擷取第N個Log Backup：按照步驟四中的方法查找，直到所有日志檔案查找完畢。
是以，我們最終擷取到的TestDR資料庫的最簡單，快速恢複的備份鍊是：C:TempTestDR_20171217@00:00_FULL.bak => C:TempTestDR_20171217@12:00_DIFF.bak => C:TempTestDR_20171217@13:00_LOG.trn => C:TempTestDR_20171217@14:00_LOG.trn。這個鍊條和我們上一期分享的資料庫備份檔案還原操作是完全吻合的。
在“備份鍊原理”章節中，我們找出備份鍊是通過“用眼睛看”的查找方式來實作的。但是現實中如果資料庫執行個體衆多，資料庫紛繁複雜，用眼睛看的方法就顯得低效而準确率不高。那麼，如何實作資料庫備份鍊的自動查找呢？不着急，我已經為大家寫好了，你隻需要把相同資料庫的多個備份檔案路徑放入輸入參數中，我們就非常輕松、快捷的查找到資料庫的備份鍊，并以此為依據來還原資料庫。還是以TestDR的十五個備份檔案為例來查找備份鍊條，代碼如下：
備份鍊結果截圖展示如下：
從這個截圖中，restore_order和Backup_file字段可以很清楚的看到資料庫還原的順序，以及相應的備份檔案路徑。所有備份檔案的LSN分布如下截圖：
從備份鍊條我們發現，12:00的這個差異備份C:TempTestDR_20171217@12:00_DIFF.bak非常關鍵，假設現實中，我們發現這個檔案恰恰損壞掉了，那麼我們的可以實作應用的資料庫還原嗎？答案是肯定的，我們把剛才的腳本輸入參數修改如下：
得到如下備份還原鍊條：
從這個結果，我們可以看到，系統選擇了06:00這個差異備份檔案，然後一步步使用接下來的事務日志備份檔案進行還原。
本期是SQL Server備份專題的第三期，在前兩期基礎上分享了如何通過備份檔案查找SQL Server資料庫備份鍊，并以此來還原資料庫的理論方法和具體實作，可以幫助使用者實作簡單、快速查找資料庫備份還原鍊條。