主頁 > 知識庫 > SQL Server誤區(qū)30日談 第20天 破壞日志備份鏈之后,需要一個完整備份來重新開始日志鏈

SQL Server誤區(qū)30日談 第20天 破壞日志備份鏈之后,需要一個完整備份來重新開始日志鏈

熱門標簽:榕城市地圖標注 電銷外呼系統(tǒng)軟件功能 浙江穩(wěn)定外呼系統(tǒng)供應商 美團地圖標注商戶認證注冊 怎么給高德做地圖標注 承德地圖標注公司名需要花錢嗎 北京400電話辦理多少錢 慶陽地圖標注 咸陽電腦外呼系統(tǒng)運營商
誤區(qū) #20:在破壞日志備份鏈之后,需要一個完整備份來重新開始日志鏈
錯誤

事務日志備份會備份自上次事務日志備份以來所有的事務日志(如果從來沒有過日志備份的話,那就從上一次完整備份開始)。有好幾種類型的操作會中斷事務日志的連續(xù)性,也就是說除非重新開始新的日志鏈,SQL Server無法再進行日志備份。下面這幾種操作都有可能引起日志鏈斷裂:

由完整恢復模式或大容量事務日志恢復模式轉為簡單恢復模式
從數(shù)據(jù)庫鏡像進行恢復
備份日志時指定了NO_LOG 或 WITH TRUNCATE_ONLY(還好在SQL Server 2008中這個選項被取消了)

更多請看:post BACKUP LOG WITH NO_LOG - use, abuse, and undocumented trace flags to stop it

通過下面的例子對此進行闡述:

復制代碼 代碼如下:

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

結果是:
復制代碼 代碼如下:

已為數(shù)據(jù)庫 'LogChainTest',文件 'LogChainTest' (位于文件 1 上)處理了 168 頁。
已為數(shù)據(jù)庫 'LogChainTest',文件 'LogChainTest_log' (位于文件 1 上)處理了 2 頁。
BACKUP DATABASE 成功處理了 170 頁,花費 0.224 秒(5.916 MB/秒)。
已為數(shù)據(jù)庫 'LogChainTest',文件 'LogChainTest_log' (位于文件 1 上)處理了 3 頁。
BACKUP LOG 成功處理了 3 頁,花費 0.121 秒(0.137 MB/秒)。

我首先創(chuàng)建了一個數(shù)據(jù)庫,將其設置為完整恢復模式,這個是日志鏈的起點,然后轉為簡單恢復模式,再轉為完整恢復模式。
下面我再嘗試進行日志備份
復制代碼 代碼如下:

BACKUP LOG LogChainTest TO DISK = 'C:\SQLskills\LogChainTest_log2.bck' WITH INIT;
GO

則會得到如下報錯信息:
復制代碼 代碼如下:

消息 4214,級別 16,狀態(tài) 1,第 1 行
無法執(zhí)行 BACKUP LOG,因為當前沒有數(shù)據(jù)庫備份。
消息 3013,級別 16,狀態(tài) 1,第 1 行
BACKUP LOG 正在異常終止。

SQL Server已經記錄了我破壞日志鏈的操作以及與進行日志 備份無法備份自上次日志備份以來所有的日志,所以SQL Server不允許我進行日志備份。
這個誤區(qū)是說此時就需要完整備份才能恢復日志鏈,但實際上,我只需要做一個差異備份(這個差異備份的跨度超過日志鏈斷裂的間隙),代碼如下:
復制代碼 代碼如下:

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

得到的結果:
復制代碼 代碼如下:

已為數(shù)據(jù)庫 'LogChainTest',文件 'LogChainTest' (位于文件 1 上)處理了 64 頁。
已為數(shù)據(jù)庫 'LogChainTest',文件 'LogChainTest_log' (位于文件 1 上)處理了 1 頁。
BACKUP DATABASE WITH DIFFERENTIAL 成功處理了 65 頁,花費 0.119 秒(4.267 MB/秒)。
已為數(shù)據(jù)庫 'LogChainTest',文件 'LogChainTest_log' (位于文件 1 上)處理了 1 頁。
BACKUP LOG 成功處理了 1 頁,花費 0.052 秒(0.150 MB/秒)。

不得不說這種方式更Cool一些,因為你不再需要一個完整備份才能繼續(xù)進行日志備份。
如果你的備份策略中包含了文件或是文件組的備份,你甚至只需要單個文件的差異備份就能繼續(xù)進行日志備份。但前提是這個備份的跨度超過了斷裂LSN的長度,當然這是更深的話題了。
又揭穿了一個誤區(qū)!
您可能感興趣的文章:
  • 定時自動備份IIS的WWW日志的vbs腳本
  • mssql自動備份及自動清除日志文件服務器設置
  • sqlserver 數(shù)據(jù)庫日志備份和恢復步驟
  • SQL Server2008 數(shù)據(jù)庫誤刪除數(shù)據(jù)的恢復方法分享
  • SQL server 2008 數(shù)據(jù)安全(備份和恢復數(shù)據(jù)庫)
  • Shell腳本定時備份清除運行系統(tǒng)日志的代碼
  • win平臺oracle rman備份和刪除dg備庫歸檔日志腳本
  • 數(shù)據(jù)庫崩潰,利用備份和日志進行災難恢復
  • SQL Server 2008數(shù)據(jù)庫誤刪數(shù)據(jù)如何進行數(shù)據(jù)恢復
  • SQL Server 2008及更高版本數(shù)據(jù)庫恢復方法之日志尾部備份

標簽:新鄉(xiāng) 上海 拉薩 重慶 江蘇 昭通 呼和浩特 貴州

巨人網(wǎng)絡通訊聲明:本文標題《SQL Server誤區(qū)30日談 第20天 破壞日志備份鏈之后,需要一個完整備份來重新開始日志鏈》,本文關鍵詞  SQL,Server,誤區(qū),30日談,第,;如發(fā)現(xiàn)本文內容存在版權問題,煩請?zhí)峁┫嚓P信息告之我們,我們將及時溝通與處理。本站內容系統(tǒng)采集于網(wǎng)絡,涉及言論、版權與本站無關。
  • 相關文章
  • 下面列出與本文章《SQL Server誤區(qū)30日談 第20天 破壞日志備份鏈之后,需要一個完整備份來重新開始日志鏈》相關的同類信息!
  • 本頁收集關于SQL Server誤區(qū)30日談 第20天 破壞日志備份鏈之后,需要一個完整備份來重新開始日志鏈的相關信息資訊供網(wǎng)民參考!
  • 推薦文章