備份的重要性
在開始分享之前,我們首先來看看數(shù)據(jù)庫備份的重要性。進入DT時代,數(shù)據(jù)的價值越發(fā)體現(xiàn),數(shù)據(jù)已經(jīng)成為每個公司賴以生存的生命線,數(shù)據(jù)的重要性不言而喻,而公司絕大多數(shù)核心數(shù)據(jù)都存放在數(shù)據(jù)庫里。數(shù)據(jù)庫本身的災難恢復(DR)能力是數(shù)據(jù)安全的最后一道防線,也是數(shù)據(jù)庫從業(yè)者對數(shù)據(jù)安全底線的堅守。數(shù)據(jù)庫中數(shù)據(jù)潛在的安全風險包括:硬件故障、惡意入侵、用戶誤操作、數(shù)據(jù)庫損壞和自然災害導致的數(shù)據(jù)損失等。在關系型數(shù)據(jù)庫SQL Server中,數(shù)據(jù)庫備份是災難恢復的能力有力保證。
Full Backup
Full Backup(完全備份)是SQL Server所有備份類型中,最為簡單、最基礎的數(shù)據(jù)庫備份方法,它提供了某個數(shù)據(jù)庫在備份時間點的完整拷貝。但是,它僅支持還原到數(shù)據(jù)庫備份成功結束的時間點,即不支持任意時間點還原操作。
Full Backup工作方式
以上是Full Backup是什么的解釋,那么接下來,我們通過一張圖和案例來解釋Full Backup的工作原理。
這是一張某數(shù)據(jù)庫的數(shù)據(jù)產(chǎn)生以及數(shù)據(jù)庫備份在時間軸上的分布圖,從左往右,我們可以分析如下:
7 P.m.:產(chǎn)生了數(shù)據(jù)#1
10 P.m.:數(shù)據(jù)庫完全備份,備份文件中包含了#1
2 a.m.:產(chǎn)生了數(shù)據(jù)#2,目前數(shù)據(jù)包含#1,#2
6 a.m.:產(chǎn)生了數(shù)據(jù)#3,目前數(shù)據(jù)包含#1,#2,#3
10 a.m.:數(shù)據(jù)庫完全備份,備份文件中包含#1,#2,#3
1 p.m.:產(chǎn)生了數(shù)據(jù)#4,目前數(shù)據(jù)包含#1,#2,#3,#4
5 p.m.:產(chǎn)生了數(shù)據(jù)#5,目前數(shù)據(jù)包含#1,#2,#3,#4,#5
8 p.m.:產(chǎn)生了數(shù)據(jù)#6,目前數(shù)據(jù)包含#1,#2,#3,#4,#5,#6
10 p.m.:數(shù)據(jù)庫完全備份,備份文件中包含了數(shù)據(jù)#1,#2,#3,#4,#5,#6
從這張圖和相應的解釋分析來看,數(shù)據(jù)庫完全備份工作原理應該是非常簡單的,它就是數(shù)據(jù)庫在備份時間點對所有數(shù)據(jù)的一個完整拷貝。當然在現(xiàn)實的生產(chǎn)環(huán)境中,事務的操作遠比這個復雜,因此,在這個圖里面有兩個非常重要的點沒有展示出來,那就是:
-
備份操作可能會導致I/O變慢:由于數(shù)據(jù)庫備份是一個I/O密集型操作,所以在數(shù)據(jù)庫備份過程中,可能會導致數(shù)據(jù)庫的I/O操作變慢。
-
全備份過程中,數(shù)據(jù)庫的事務日志不能夠被截斷:對于具有大事務頻繁操作的數(shù)據(jù)庫,可能會導致事務日志空間一直不停頻繁增長,直到占滿所有的磁盤剩余空間,這個場景在阿里云RDS SQL產(chǎn)品中有很多的客戶都遇到過。其中之一解決方法就需要依賴于我們后面要談到的事務日志備份技術。
T-SQL創(chuàng)建Full Backup
使用T-SQL語句來完成數(shù)據(jù)庫的完全備份,使用BACKUP DATABASE語句即可,如下,對AdventureWorks2008R2數(shù)據(jù)庫進行一個完全備份:
USE master
GO
BACKUP DATABASE [AdventureWorks2008R2]
TO DISK = 'C:\Temp\AdventureWorks2008R2_20171112_FULL.bak' WITH COMPRESSION, INIT, STATS = 5;
GO
SSMS IDE創(chuàng)建Full Backup
除了使用T-SQL語句創(chuàng)建數(shù)據(jù)庫的完全備份外,我們還可以使用SSMS IDE界面操作來完成,方法:
右鍵點擊想要備份的數(shù)據(jù)庫 => Tasks => Backup => 選擇FULL Backup Type => 選擇Disk 做為備份文件存儲 => 點擊Add 添加備份文件 => 選擇你需要存儲備份文件的目錄 => 輸入備份文件名,如下圖兩張圖展示。
Back up Database設置界面
Transaction Log Backup
SQL Server數(shù)據(jù)庫完全備份是數(shù)據(jù)庫的完整拷貝,所以備份文件空間占用相對較大,加之可能會在備份過程中導致事務日志一直不斷增長。為了解決這個問題,事務日志備份可以很好的解決這個問題,因為:事務日志備份記錄了數(shù)據(jù)庫從上一次日志備份到當前時間內(nèi)的所有事務提交的數(shù)據(jù)變更,它可以配合數(shù)據(jù)庫完全備份和差異備份(可選)來實現(xiàn)時間點的還原。當日志備份操作成功以后,事務日志文件會被截斷,事務日志空間將會被重復循環(huán)利用,以此來解決完全備份過程中事務日志文件一致不停增長的問題,因此我們最好能夠周期性對數(shù)據(jù)庫進行事務日志備份,以此來控制事務日志文件的大小。但是這里需要有一個前提是數(shù)據(jù)庫必須是FULL恢復模式,SIMPLE恢復模式的數(shù)據(jù)庫不支持事務日志的備份,當然就無法實現(xiàn)時間點的還原。請使用下面的語句將數(shù)據(jù)庫修改為FULL恢復模式,比如針對AdventureWorks2008R2數(shù)據(jù)庫:
USE [master]
GO
ALTER DATABASE [AdventureWorks2008R2] SET RECOVERY FULL WITH NO_WAIT
GO
Transaction Log Backup工作方式
事務日志備份與數(shù)據(jù)完全備份工作方式截然不同,它不是數(shù)據(jù)庫的一個完整拷貝,而是至上一次日志備份到當前時間內(nèi)所有提交的事務數(shù)據(jù)變更。用一張圖來解釋事務日志備份的工作方式:
00:01:事務#1,#2,#3開始,未提交
00:02:事務#1,#2,#3成功提交;#4,#5,#6事務開始,未提交;這時備份事務日志;事務日志備份文件中僅包含已提交的#1,#2,#3的事務(圖中的LSN 1-4,不包含#4)
00:04:由于在00:02做了事務日志備份,所以#1,#2,#3所占用的空間被回收;#4,#5,#6事務提交完成
00:05:事務#7已經(jīng)提交成功;#8,#9,#10開始,但未提交;事務日志備份文件中包含#4,#5,#6,#7的事務(圖中的LSN4-8,不包含#8)。
從這張圖我們看到,每個事務日志備份文件中包含的是已經(jīng)完成的事務變更,兩次事務日志備份中存放的是完全不同的變更數(shù)據(jù)。而每一次事務日志備份成功以后,事務日志空間可以被成功回收,重復利用,達到了解決數(shù)據(jù)庫完全備份過程中事務日志一致不斷增長的問題。
T-SQL創(chuàng)建事務日志備份
使用T-SQL語句來創(chuàng)建事務日志的備份方法如下:
USE Master
GO
BACKUP LOG [AdventureWorks2008R2]
TO DISK = N'C:\temp\AdventureWorks2008R2_log_201711122201.trn' with compression,stats=1;
GO
BACKUP LOG [AdventureWorks2008R2]
TO DISK = N'C:\temp\AdventureWorks2008R2_log_201711122202.trn' with compression,stats=1;
GO
BACKUP LOG [AdventureWorks2008R2]
TO DISK = N'C:\temp\AdventureWorks2008R2_log_201711122203.trn' with compression,stats=1;
GO
SSMS IDE創(chuàng)建事務日志備份
使用SSMS IDE創(chuàng)建事務日志備份的方法:
右鍵點擊想要創(chuàng)建事務日志備份的數(shù)據(jù)庫 => Tasks => Backup => 選擇Transaction Log Backup Type => 選擇Disk 做為備份文件存儲 => 點擊Add 添加備份文件 => 選擇你需要存儲備份文件的目錄 => 輸入備份文件名,如下圖展示:
事務日志備份鏈
由于數(shù)據(jù)庫完全備份是時間點數(shù)據(jù)的完整拷貝,每個數(shù)據(jù)庫完整備份相互獨立,而多個事務日志備份是通過事務日志鏈條連接在一起,事務日志鏈起點于完全備份,SQL Server中的每一個事務日志備份文件都擁有自己的FirstLSN和LastLSN,F(xiàn)irstLSN用于指向前一個事務日志備份文件的LastLSN;而LastLSN指向下一個日志的FirstLSN,以此來建立這種鏈接關系。這種鏈接關系決定了事務日志備份文件還原的先后順序。當然,如果其中任何一個事務日志備份文件丟失或者破壞,都會導致無法恢復整個事務日志鏈,僅可能恢復到你擁有的事務日志鏈條的最后一個。事務日志備份鏈條的關系如下圖所示:
我們使用前面“T-SQL創(chuàng)建事務日志備份”創(chuàng)建的事務日志鏈,使用RESTORE HEADERONLY方法來查看事務日志鏈的關系:
USE Master
GO
RESTORE HEADERONLY FROM DISK = N'C:\temp\AdventureWorks2008R2_log_201711122201.trn';
RESTORE HEADERONLY FROM DISK = N'C:\temp\AdventureWorks2008R2_log_201711122202.trn';
RESTORE HEADERONLY FROM DISK = N'C:\temp\AdventureWorks2008R2_log_201711122203.trn';
查詢結果如下:
從這個結果展示來看,事務日志備份文件AdventureWorks2008R2_log_201711122201的LastLSN指向了的AdventureWorks2008R2_log_201711122202的FirstLSN,而AdventureWorks2008R2_log_201711122202的LastLSN又指向了AdventureWorks2008R2_log_201711122203的FirstLSN,以此來建立了事務日志備份鏈條關系。假如AdventureWorks2008R2_log_201711122202的事務日志備份文件丟失或者損壞的話,數(shù)據(jù)庫只能還原到AdventureWorks2008R2_log_201711122201所包含的所有事務行為。
這里有一個問題是:為了防止數(shù)據(jù)庫事務日志一直不斷的增長,而我們又不想每次都對數(shù)據(jù)庫做完全備份,那么我們就必須對數(shù)據(jù)庫事務日志做周期性的日志備份,比如:5分鐘甚至更短,以此來降低數(shù)據(jù)丟失的風險,以此推算每天會產(chǎn)生24 * 12 = 288個事務日志備份,這樣勢必會導致事務日志恢復鏈條過長,拉長恢復時間,增大了數(shù)據(jù)庫還原時間(RTO)。這個問題如何解決就是我們下面章節(jié)要分享到的差異備份技術。
Differential Backup
事務日志備份會導致數(shù)據(jù)庫還原鏈條過長的問題,而差異備份就是來解決事務日志備份的這個問題的。差異備份是備份至上一次數(shù)據(jù)庫全量備份以來的所有變更的數(shù)據(jù)頁,所以差異備份相對于數(shù)據(jù)庫完全備份而言往往數(shù)據(jù)空間占用會小很多。因此,備份的效率更高,還原的速度更快,可以大大提升我們?yōu)碾y恢復的能力。
Differential Backup工作方式
我們還是從一張圖來了解數(shù)據(jù)庫差異備份的工作方式:
7 a.m.:數(shù)據(jù)包含#1
10 a.m.:數(shù)據(jù)庫完全備份,備份文件中包含#1
1 p.m.:數(shù)據(jù)包含#1,#2,#3,#4
2 p.m.:數(shù)據(jù)庫差異備份,備份文件中包含#2,#3,#4(上一次全備到目前的變更數(shù)據(jù))
4 p.m.:數(shù)據(jù)包含#1,#2,...,#6
6 p.m.:數(shù)據(jù)庫差異備份,備份文件中包含#2,#3,#4,#5,#6
8 p.m.:數(shù)據(jù)包含#1,#2,...,#8
10 p.m.:數(shù)據(jù)庫完全備份,備份文件中包含#1,#2,...,#8
11 p.m.:產(chǎn)生新的數(shù)據(jù)#9,#10;數(shù)據(jù)包含#1,#2,...,#10
2 a.m.:數(shù)據(jù)庫差異備份,備份文件中包含#9,#10
從這個差異備份的工作方式圖,我們可以很清楚的看出差異備份的工作原理:它是備份繼上一次完全備份以來的所有數(shù)據(jù)變更,所以它大大減少了備份日之鏈條的長度和縮小備份集的大小。
T-SQL創(chuàng)建差異備份
使用T-SQL語句創(chuàng)建差異備份的方法如下:
USE master
GO
BACKUP DATABASE [AdventureWorks2008R2]
TO DISK = 'C:\Temp\AdventureWorks2008R2_20171112_diff.bak' WITH DIFFERENTIAL
GO
SSMS創(chuàng)建差異備份
使用SSMS IDE創(chuàng)建差異備份的方法:
右鍵點擊想要創(chuàng)建事務日志備份的數(shù)據(jù)庫 => Tasks => Backup => 選擇Differential Backup Type => 選擇Disk 做為備份文件存儲 => 點擊Add 添加備份文件 => 選擇你需要存儲備份文件的目錄 => 輸入備份文件名,如下圖展示:
最后總結
本期月報分享了SQL Server三種常見的備份技術的工作方式和備份方法。數(shù)據(jù)庫完全備份是數(shù)據(jù)庫備份時間的一個完整拷貝;事務日志備份是上一次日志備份到當前時間的事務日志變更,它解決了數(shù)據(jù)庫完全備份過程中事務日志一直增長的問題;差異備份上一次完全備份到當前時間的數(shù)據(jù)變更,它解決了事務日志備份鏈過長的問題。
將SQL Server這三種備份方式的工作方式,優(yōu)缺點總結如下表格:
10.png
從這個表格,我們知道每種備份有其各自的優(yōu)缺點,那么我們?nèi)绾蝸碇贫ㄎ覀兊膫浞莺瓦原策略以達到快速災難恢復的能力呢?這個話題,我們將在下一期月報中進行分享。
核心關注:拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務領域、行業(yè)應用,蘊涵了豐富的ERP管理思想,集成了ERP軟件業(yè)務管理理念,功能涉及供應鏈、成本、制造、CRM、HR等眾多業(yè)務領域的管理,全面涵蓋了企業(yè)關注ERP管理系統(tǒng)的核心領域,是眾多中小企業(yè)信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處:拓步ERP資訊網(wǎng)http://www.ezxoed.cn/
本文標題:MSSQL-最佳實踐-SQL Server三種常見備份
本文網(wǎng)址:http://www.ezxoed.cn/html/consultation/10839724048.html