猿學-sql server 備份與恢復系列四 大容量模式下的備份與還原

一. 概述

  在sql server 備份與恢復系列的第一篇裏,有講到大容量模式下備份與還原的相關知識。這篇重點來演示在大容量模式下常用的備份與還原模式“完整備份+差異備份+日誌備份”。 在大容量恢復模式下,特別要注意的是在什麼情況下會導致數據還原丟失風險,帶着這個問題,來進行演示說明。備份策略如下圖所示:

二.備份

    我這裏有TestBulkLogged庫,庫裏新建了一個product空表。備份SQL語句如下所示:

複製代碼

use master
-- 設置大容量模式
ALTER DATABASE TestBulkLogged SET RECOVERY bulk_logged

-- 做一次完整備份到備份設備中(備份基準) 
backup database  TestBulkLogged to BackupTestDevice

-- 新增
insert into TestBulkLogged.dbo.product(model,upbymemberid,brand) values('第一次新增數據',9708,'IT')

-- 做一次日誌備份
backup log   TestBulkLogged to BackupTestDevice

-- 批量插入(5998 行受影響)
insert into TestBulkLogged.dbo.product(model,upbymemberid,brand)
select model,upbymemberid,brand from test.dbo.product

-- 做二次日誌備份
backup log   TestBulkLogged to BackupTestDevice

-- 第二次日誌備份後的新增
insert into TestBulkLogged.dbo.product(model,upbymemberid,brand) values('第二次新增數據',9708,'IT')

-- 做差異備份
backup database  TestBulkLogged to BackupTestDevice with differential 

-- 全部刪除(6000 行受影響)
delete from TestBulkLogged.dbo.product

複製代碼

  查看備份集列表如下圖所示:

三. 還原(1)批量插入的是否會丟失

  通過還原查看批量插入操作是否丟失,在備份尾日誌時如果報錯, 信息如下:"因爲數據庫正在使用,所以無法獲得對數據庫的獨佔訪問權" 需要將庫設置成單用戶模式

use master
-- 先還原完整備份 ,norecovery(正在還原...)不可讀寫. file指備份集位置號
restore database TestBulkLogged from BackupTestDevice with file=10, norecovery 

    

   在大容量模式下還原時,sql server會檢測你是否進行了尾日誌備份,也是確保最後一次日誌備份後,所做的數據操作在還原後不丟失。(如果尾日誌備份失敗,則丟失數據)。下面先備份一下尾日誌, 使用norecovery 暫不提交

-- 尾日誌備份
backup log TestBulkLogged to BackupTestDevice with norecovery 

 上圖備份了尾日誌後,備份集裏多出了一個文件號14, 下面在重新還原完整備份

-- (重新)從備份恢復一個全備份 ,norecovery(正在還原...)不可讀寫. file指備份集位置號
restore database TestBulkLogged from BackupTestDevice with file=10, norecovery 

    

-- 恢復到日誌文件11  
restore database TestBulkLogged from BackupTestDevice  with file=11, norecovery

-- 恢復到日誌文件12  
restore database TestBulkLogged from BackupTestDevice  with file=12, recovery

    

 接下來我們來查詢下庫中的product表,查看數據是否全部恢復。

-- 查詢大批量操作的數據,是否已還原出來
select * from TestBulkLogged.dbo.product

  

  結論:通過上圖我們可以瞭解到,第一次和第二次做的日誌備份都完美的還原了過來。 大批量插入操作也得到了還原。證明在大容量模式下,大批量操作的數據, 還原恢復可能存在丟失的風險,但不一定會丟失掉

 四. 還原(2)打斷日誌鏈

  在前面講述事務日誌時提到了, 事務日誌鏈LSN, 在還原的時候必須要保持事務鏈的順序,依次的還原。 下面演示跳過日誌鏈文件ID:11 ,直接還原日誌鏈文件ID:12。

複製代碼

-- 尾日誌備份
backup log TestBulkLogged to BackupTestDevice with norecovery 

-- 從備份恢復一個全備份 ,norecovery(正在還原...)不可讀寫. file指備份集位置號
restore database TestBulkLogged from BackupTestDevice with file=10, norecovery 

-- 跳過日誌文件11,恢復到日誌文件12  
restore database TestBulkLogged from BackupTestDevice  with file=12, recovery

複製代碼

  

  結論:如果只有(完整備份和事務日誌備份), 在還原時,事務日誌必須保持LSN順序,依次還原,否則還原失敗就會丟失數據。

五. 還原(3) 基於差異備份下的日誌還原

  在生產環境中,由於日誌文件備份頻繁,導致日誌文件太多,如果按日誌文件一個一個來還原,需要大量時間和精力。下面演示直接從差異備份還原開始,看後面的日誌文件是否能還原成功。

複製代碼

-- 尾日誌備份
backup log TestBulkLogged to BackupTestDevice with norecovery 

-- 從備份恢復一個全備份 ,norecovery(正在還原...)不可讀寫. file指備份集位置號
restore database TestBulkLogged from BackupTestDevice with file=10, norecovery 

-- 恢復到差異備份文件13. 跳過日誌文件11,12 
restore database TestBulkLogged from BackupTestDevice  with file=13, recovery

複製代碼

   上面還原是跳過了日誌文件,直接使用差異備份文件還原。我們來查看下錶中的數據,會發現差異備份完全可以還原正確成功。

  

下面是差異備份與日誌備份組合來還原,結論是日誌文件不需要一個一個來還原,可以直接定位到,一個差異備份來還原,再還原,之後的日誌文件。

複製代碼

-- 尾日誌備份
backup log TestBulkLogged to BackupTestDevice with norecovery 

-- 從備份恢復一個全備份 ,norecovery(正在還原...)不可讀寫. file指備份集位置號
restore database TestBulkLogged from BackupTestDevice with file=10, norecovery 

-- 恢復到差異備份文件13. 跳過日誌文件11,12 
restore database TestBulkLogged from BackupTestDevice  with file=13, norecovery

-- 恢復到日誌文件14 
restore database TestBulkLogged from BackupTestDevice  with file=14, recovery

複製代碼

   結論:有了差異備份,在還原時就節省了很多還原時間和精力。可以在完整備份的基準內,直接選擇最後一次的差異備份加上之後的日誌備份來還原。

猿學-中國互聯網IT軟件培訓專家!承接電信、能源、金融、政府、製造業、商貿流通業、醫療衛生、教育與文化、交通、移動互聯網、傳媒、環保等軟件項目合作,歡迎洽談!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章