SQL Server誤區(qū)30日談 第20天 破壞日志備份鏈之后,需要一個(gè)完整備份來重新開始日志鏈
更新時(shí)間:2013年01月09日 21:21:58 作者:
事務(wù)日志備份會(huì)備份自上次事務(wù)日志備份以來所有的事務(wù)日志(如果從來沒有過日志備份的話,那就從上一次完整備份開始)。有好幾種類型的操作會(huì)中斷事務(wù)日志的連續(xù)性,也就是說除非重新開始新的日志鏈,SQL Server無(wú)法再進(jìn)行日志備份
誤區(qū) #20:在破壞日志備份鏈之后,需要一個(gè)完整備份來重新開始日志鏈
錯(cuò)誤
事務(wù)日志備份會(huì)備份自上次事務(wù)日志備份以來所有的事務(wù)日志(如果從來沒有過日志備份的話,那就從上一次完整備份開始)。有好幾種類型的操作會(huì)中斷事務(wù)日志的連續(xù)性,也就是說除非重新開始新的日志鏈,SQL Server無(wú)法再進(jìn)行日志備份。下面這幾種操作都有可能引起日志鏈斷裂:
由完整恢復(fù)模式或大容量事務(wù)日志恢復(fù)模式轉(zhuǎn)為簡(jiǎn)單恢復(fù)模式
從數(shù)據(jù)庫(kù)鏡像進(jìn)行恢復(fù)
備份日志時(shí)指定了NO_LOG 或 WITH TRUNCATE_ONLY(還好在SQL Server 2008中這個(gè)選項(xiàng)被取消了)
更多請(qǐng)看:post BACKUP LOG WITH NO_LOG - use, abuse, and undocumented trace flags to stop it
通過下面的例子對(duì)此進(jìn)行闡述:
CREATE DATABASE LogChainTest;
GO
ALTER DATABASE LogChainTest SET RECOVERY FULL;
GO
BACKUP DATABASE LogChainTest TO DISK = 'C:\SQLskills\LogChainTest.bck' WITH INIT;
GO
BACKUP LOG LogChainTest TO DISK = 'C:\SQLskills\LogChainTest_log1.bck' WITH INIT;
GO
ALTER DATABASE LogChainTest SET RECOVERY SIMPLE;
GO
ALTER DATABASE LogChainTest SET RECOVERY FULL;
GO
結(jié)果是:
已為數(shù)據(jù)庫(kù) 'LogChainTest',文件 'LogChainTest' (位于文件 1 上)處理了 168 頁(yè)。
已為數(shù)據(jù)庫(kù) 'LogChainTest',文件 'LogChainTest_log' (位于文件 1 上)處理了 2 頁(yè)。
BACKUP DATABASE 成功處理了 170 頁(yè),花費(fèi) 0.224 秒(5.916 MB/秒)。
已為數(shù)據(jù)庫(kù) 'LogChainTest',文件 'LogChainTest_log' (位于文件 1 上)處理了 3 頁(yè)。
BACKUP LOG 成功處理了 3 頁(yè),花費(fèi) 0.121 秒(0.137 MB/秒)。
我首先創(chuàng)建了一個(gè)數(shù)據(jù)庫(kù),將其設(shè)置為完整恢復(fù)模式,這個(gè)是日志鏈的起點(diǎn),然后轉(zhuǎn)為簡(jiǎn)單恢復(fù)模式,再轉(zhuǎn)為完整恢復(fù)模式。
下面我再嘗試進(jìn)行日志備份
BACKUP LOG LogChainTest TO DISK = 'C:\SQLskills\LogChainTest_log2.bck' WITH INIT;
GO
則會(huì)得到如下報(bào)錯(cuò)信息:
消息 4214,級(jí)別 16,狀態(tài) 1,第 1 行
無(wú)法執(zhí)行 BACKUP LOG,因?yàn)楫?dāng)前沒有數(shù)據(jù)庫(kù)備份。
消息 3013,級(jí)別 16,狀態(tài) 1,第 1 行
BACKUP LOG 正在異常終止。
SQL Server已經(jīng)記錄了我破壞日志鏈的操作以及與進(jìn)行日志 備份無(wú)法備份自上次日志備份以來所有的日志,所以SQL Server不允許我進(jìn)行日志備份。
這個(gè)誤區(qū)是說此時(shí)就需要完整備份才能恢復(fù)日志鏈,但實(shí)際上,我只需要做一個(gè)差異備份(這個(gè)差異備份的跨度超過日志鏈斷裂的間隙),代碼如下:
BACKUP DATABASE LogChainTest TO DISK = 'd:\Test_bak\LogChainTest_log1.bck' WITH INIT, DIFFERENTIAL;
GO
BACKUP LOG LogChainTest TO DISK = 'd:\Test_bak\LogChainTest_log1.bck' WITH INIT;
GO
得到的結(jié)果:
已為數(shù)據(jù)庫(kù) 'LogChainTest',文件 'LogChainTest' (位于文件 1 上)處理了 64 頁(yè)。
已為數(shù)據(jù)庫(kù) 'LogChainTest',文件 'LogChainTest_log' (位于文件 1 上)處理了 1 頁(yè)。
BACKUP DATABASE WITH DIFFERENTIAL 成功處理了 65 頁(yè),花費(fèi) 0.119 秒(4.267 MB/秒)。
已為數(shù)據(jù)庫(kù) 'LogChainTest',文件 'LogChainTest_log' (位于文件 1 上)處理了 1 頁(yè)。
BACKUP LOG 成功處理了 1 頁(yè),花費(fèi) 0.052 秒(0.150 MB/秒)。
不得不說這種方式更Cool一些,因?yàn)槟悴辉傩枰粋€(gè)完整備份才能繼續(xù)進(jìn)行日志備份。
如果你的備份策略中包含了文件或是文件組的備份,你甚至只需要單個(gè)文件的差異備份就能繼續(xù)進(jìn)行日志備份。但前提是這個(gè)備份的跨度超過了斷裂LSN的長(zhǎng)度,當(dāng)然這是更深的話題了。
又揭穿了一個(gè)誤區(qū)!
錯(cuò)誤
事務(wù)日志備份會(huì)備份自上次事務(wù)日志備份以來所有的事務(wù)日志(如果從來沒有過日志備份的話,那就從上一次完整備份開始)。有好幾種類型的操作會(huì)中斷事務(wù)日志的連續(xù)性,也就是說除非重新開始新的日志鏈,SQL Server無(wú)法再進(jìn)行日志備份。下面這幾種操作都有可能引起日志鏈斷裂:
由完整恢復(fù)模式或大容量事務(wù)日志恢復(fù)模式轉(zhuǎn)為簡(jiǎn)單恢復(fù)模式
從數(shù)據(jù)庫(kù)鏡像進(jìn)行恢復(fù)
備份日志時(shí)指定了NO_LOG 或 WITH TRUNCATE_ONLY(還好在SQL Server 2008中這個(gè)選項(xiàng)被取消了)
更多請(qǐng)看:post BACKUP LOG WITH NO_LOG - use, abuse, and undocumented trace flags to stop it
通過下面的例子對(duì)此進(jìn)行闡述:
復(fù)制代碼 代碼如下:
CREATE DATABASE LogChainTest;
GO
ALTER DATABASE LogChainTest SET RECOVERY FULL;
GO
BACKUP DATABASE LogChainTest TO DISK = 'C:\SQLskills\LogChainTest.bck' WITH INIT;
GO
BACKUP LOG LogChainTest TO DISK = 'C:\SQLskills\LogChainTest_log1.bck' WITH INIT;
GO
ALTER DATABASE LogChainTest SET RECOVERY SIMPLE;
GO
ALTER DATABASE LogChainTest SET RECOVERY FULL;
GO
結(jié)果是:
復(fù)制代碼 代碼如下:
已為數(shù)據(jù)庫(kù) 'LogChainTest',文件 'LogChainTest' (位于文件 1 上)處理了 168 頁(yè)。
已為數(shù)據(jù)庫(kù) 'LogChainTest',文件 'LogChainTest_log' (位于文件 1 上)處理了 2 頁(yè)。
BACKUP DATABASE 成功處理了 170 頁(yè),花費(fèi) 0.224 秒(5.916 MB/秒)。
已為數(shù)據(jù)庫(kù) 'LogChainTest',文件 'LogChainTest_log' (位于文件 1 上)處理了 3 頁(yè)。
BACKUP LOG 成功處理了 3 頁(yè),花費(fèi) 0.121 秒(0.137 MB/秒)。
我首先創(chuàng)建了一個(gè)數(shù)據(jù)庫(kù),將其設(shè)置為完整恢復(fù)模式,這個(gè)是日志鏈的起點(diǎn),然后轉(zhuǎn)為簡(jiǎn)單恢復(fù)模式,再轉(zhuǎn)為完整恢復(fù)模式。
下面我再嘗試進(jìn)行日志備份
復(fù)制代碼 代碼如下:
BACKUP LOG LogChainTest TO DISK = 'C:\SQLskills\LogChainTest_log2.bck' WITH INIT;
GO
則會(huì)得到如下報(bào)錯(cuò)信息:
復(fù)制代碼 代碼如下:
消息 4214,級(jí)別 16,狀態(tài) 1,第 1 行
無(wú)法執(zhí)行 BACKUP LOG,因?yàn)楫?dāng)前沒有數(shù)據(jù)庫(kù)備份。
消息 3013,級(jí)別 16,狀態(tài) 1,第 1 行
BACKUP LOG 正在異常終止。
SQL Server已經(jīng)記錄了我破壞日志鏈的操作以及與進(jìn)行日志 備份無(wú)法備份自上次日志備份以來所有的日志,所以SQL Server不允許我進(jìn)行日志備份。
這個(gè)誤區(qū)是說此時(shí)就需要完整備份才能恢復(fù)日志鏈,但實(shí)際上,我只需要做一個(gè)差異備份(這個(gè)差異備份的跨度超過日志鏈斷裂的間隙),代碼如下:
復(fù)制代碼 代碼如下:
BACKUP DATABASE LogChainTest TO DISK = 'd:\Test_bak\LogChainTest_log1.bck' WITH INIT, DIFFERENTIAL;
GO
BACKUP LOG LogChainTest TO DISK = 'd:\Test_bak\LogChainTest_log1.bck' WITH INIT;
GO
得到的結(jié)果:
復(fù)制代碼 代碼如下:
已為數(shù)據(jù)庫(kù) 'LogChainTest',文件 'LogChainTest' (位于文件 1 上)處理了 64 頁(yè)。
已為數(shù)據(jù)庫(kù) 'LogChainTest',文件 'LogChainTest_log' (位于文件 1 上)處理了 1 頁(yè)。
BACKUP DATABASE WITH DIFFERENTIAL 成功處理了 65 頁(yè),花費(fèi) 0.119 秒(4.267 MB/秒)。
已為數(shù)據(jù)庫(kù) 'LogChainTest',文件 'LogChainTest_log' (位于文件 1 上)處理了 1 頁(yè)。
BACKUP LOG 成功處理了 1 頁(yè),花費(fèi) 0.052 秒(0.150 MB/秒)。
不得不說這種方式更Cool一些,因?yàn)槟悴辉傩枰粋€(gè)完整備份才能繼續(xù)進(jìn)行日志備份。
如果你的備份策略中包含了文件或是文件組的備份,你甚至只需要單個(gè)文件的差異備份就能繼續(xù)進(jìn)行日志備份。但前提是這個(gè)備份的跨度超過了斷裂LSN的長(zhǎng)度,當(dāng)然這是更深的話題了。
又揭穿了一個(gè)誤區(qū)!
您可能感興趣的文章:
- 定時(shí)自動(dòng)備份IIS的WWW日志的vbs腳本
- mssql自動(dòng)備份及自動(dòng)清除日志文件服務(wù)器設(shè)置
- sqlserver 數(shù)據(jù)庫(kù)日志備份和恢復(fù)步驟
- SQL Server2008 數(shù)據(jù)庫(kù)誤刪除數(shù)據(jù)的恢復(fù)方法分享
- SQL server 2008 數(shù)據(jù)安全(備份和恢復(fù)數(shù)據(jù)庫(kù))
- Shell腳本定時(shí)備份清除運(yùn)行系統(tǒng)日志的代碼
- win平臺(tái)oracle rman備份和刪除dg備庫(kù)歸檔日志腳本
- 數(shù)據(jù)庫(kù)崩潰,利用備份和日志進(jìn)行災(zāi)難恢復(fù)
- SQL Server 2008數(shù)據(jù)庫(kù)誤刪數(shù)據(jù)如何進(jìn)行數(shù)據(jù)恢復(fù)
- SQL Server 2008及更高版本數(shù)據(jù)庫(kù)恢復(fù)方法之日志尾部備份
相關(guān)文章
詳細(xì)分析sqlserver中的小數(shù)類型(float和decimal)
這篇文章主要介紹了sqlserver中的小數(shù)類型的相關(guān)知識(shí),文中講解非常細(xì)致,代碼幫助大家更好的理解和學(xué)習(xí),感興趣的朋友可以了解下2020-06-06
sqlserver合并DataTable并排除重復(fù)數(shù)據(jù)的通用方法分享
網(wǎng)上合并DataTable通用方法的文章很多,結(jié)合項(xiàng)目開發(fā)中的常用需求,并借鑒網(wǎng)上的做法,寫了一個(gè)合并DataTable的通用方法,主要功能是合并兩個(gè)DataTable(結(jié)構(gòu)可以不同,如字段不完全一致),并可以根據(jù)某一列值進(jìn)行排重處理2011-12-12
SqlServer將數(shù)據(jù)庫(kù)中的表復(fù)制到另一個(gè)數(shù)據(jù)庫(kù)
在使用SqlServer的過程中,我們可能需要將表從一個(gè)數(shù)據(jù)庫(kù)復(fù)制到另一個(gè)數(shù)據(jù)庫(kù)中,今天小編為大家介紹這種操作的具體方法及步驟2021-04-04
SQLite數(shù)據(jù)庫(kù)管理相關(guān)命令的使用介紹
本篇文章小編為大家介紹,SQLite數(shù)據(jù)庫(kù)管理相關(guān)命令的使用說明。需要的朋友參考下2013-04-04
SQL?Server2022安裝提示"安裝程序在運(yùn)行作業(yè)UpdateResult時(shí)失敗"解決方法
平時(shí)大家在安裝數(shù)據(jù)庫(kù)的時(shí)候,我也相信大家會(huì)遇到過一些報(bào)錯(cuò)導(dǎo)致安裝失敗,下面這篇文章主要給大家介紹了關(guān)于SQL?Server2022安裝提示"安裝程序在運(yùn)行作業(yè)UpdateResult時(shí)失敗"的解決方法,需要的朋友可以參考下2023-05-05

