DIFF 升級為 FULL
我們使用 Ola Hallengren 的
DatabaseBackup
儲存過程將 SQL Server 2012 實例上的 SharePoint 數據庫負載備份到 Azure blob 儲存中。我們已經這樣做了很長一段時間,沒有任何問題。然而,在過去的 6 周里,我們DIFFs
被隨機提升FULL
,我們無法找出原因。這是代理步驟的輸出
BACKUP DATABASE [Database] TO URL = N'https://strorgage.blob.core.windows.net/server/instance/Database/2020/11/diff/Database_FULL_20201105_200000.bak' WITH NO_CHECKSUM, COMPRESSION, CREDENTIAL = N'*storeageaccountname*'
如果您查看生成的 URL,您會注意到程序儲存在 DIFF 目錄中,但會創建一個完整的備份文件。
https://strorgage.blob.core.windows.net/server/instance/Database/2020/11/diff/Database_FULL_20201105_200000.bak --^ --^
DatabaseBackup (Ola proc) 是從 2019-06-14 開始的,所以它需要升級才能公平,但它已經執行了 18 個月以上。
我們不直接呼叫 Ola 程式碼,因為我們有一個小型包裝程序,它為 Azure 建構虛擬路徑名,但本質上這就是我們呼叫 Ola 程式碼的方式。
這是一個問題,由於某些未知原因,DIFF 備份被提升為 FULL,這會導致 Azure blob 備份的 PB 數而不是 GB 數 - 每天。
EXECUTE dbo.DatabaseBackup @Database = @DatabaseName, @URL = @BackupPath, @Credential = @StorageAccount, @BackupType = @backupType, @Compress = @Compression, @LogToTable = 'Y', @ChangeBackupType = 'Y', @Updateability = @DatabaseReadOnlyState, @DirectoryStructure = NULL, @AvailabilityGroupDirectoryStructure = NULL
你對此有什麼想法嗎?
您說將 DIFF 升級為 FULL 備份是“隨機的”,但我敢打賭,您可以在數據庫本身中找到此活動與數據流失(或索引維護)之間的聯繫。
因為您正在使用
ChangeBackupType='Y'
,所以備份作業正在查看sys.dm_db_file_space_usage以查看有多少數據庫已更改,如果超過門檻值則執行完整備份(我很難從原始碼中辨別預設門檻值)。您可以通過調整ModificationLevel
參數(百分比)來更改該門檻值。從文件ModificationLevel
指定將差異備份更改為完整備份的百分比。此選項只能與@ChangeBackupType = ‘Y’ 一起使用。DatabaseBackup 檢查 sys.dm_db_file_space_usage 中的allocated_extent_page_count 和modified_extent_page_count 以計算數據庫有多少已被修改。
介紹
查看您的程式碼,您似乎已經在使用
@ChangeBackupType
Ola 在他的SQL Server 維護解決方案中為DatabaseBackup儲存過程提供的參數。此參數的文件提供了以下資訊:DatabaseBackup 簽
differential_base_lsn
入sys.master_files
以確定是否可以執行差異備份。如果無法進行差異備份,則預設跳過數據庫。或者,您可以將 ChangeBackupType 設置為 Y 以改為執行完整備份。相關 的……和……
DatabaseBackup 簽
last_log_backup_lsn
入sys.database_recovery_status
以確定是否可以執行完整或批量日誌恢復模式的事務日誌備份。如果無法備份事務日誌,則預設跳過數據庫。或者,您可以將 ChangeBackupType 設置為 Y 以改為執行差異備份或完整備份。不相干
參考: DatabaseBackup (ola.hallengren.com)
假設
看到您正在使用有問題的參數並假設您的數據庫都在完全恢復模式下執行,那麼我希望 Ola 的腳本按照他們被告知的方式執行並執行差異備份,就像您之前觀察到的那樣…… ..
然而
…某些東西正在以這樣的方式改變 SharePoint 數據庫,以至於 Ola 的程序假設數據庫需要完整備份。Ola檢查各種情況,其中一種是根據參數….
修改級別
如果設置了第一個參數,還有一個附加參數
@ModificationLevel
可以將 DIFF 備份轉換為 FULL 備份@ChangeBackupType = 'Y'
。查看 Ola 的程式碼為我們提供了以下資訊:IF @ModificationLevel IS NOT NULL AND @BackupType <> 'DIFF' BEGIN INSERT INTO @Errors ([Message], Severity, [State]) SELECT 'The value for the parameter @ModificationLevel is not supported.', 16, 3 END
這意味著如果參數
@ModifcationLevel
設置為一個值並@ChangeBackupType
設置為Y
,那麼備份過程會將 DIFF 備份轉換為 FULL 備份,如果更改的頁面數量觸發了這種情況。因為您沒有設置
@ModificationLevel
它NULL
,所以可以在 Ola 的程式碼中看到:@ModificationLevel int = NULL,
在您的情況下似乎並非如此,除非您的參數值當然
@ModificationLevel
不是 is notNULL
。解決方案 1
**在這種情況下,我們找到了罪魁禍首。**將值更改
@ModificationLevel
回NULL
,一切都很好。轉換的進一步原因
備份將從 更改為 的另一個原因
DIFF
是FULL
參數@ChangeBackupType
本身。描述(從上面)寫成:
DatabaseBackup(過程)檢查
differential_base_lsn
以sys.master_files
確定是否可以執行差異備份。如果無法進行差異備份,則預設跳過數據庫。或者,您可以將 ChangeBackupType 設置為 Y 以改為執行完整備份。檢查程式碼
Ola 在程式碼中這樣寫:
SELECT @CurrentDifferentialBaseLSN = differential_base_lsn FROM sys.master_files WHERE database_id = DB_ID(@CurrentDatabaseName) AND [type] = 0 AND [file_id] = 1
這部分在這裡:
IF @CurrentBackupType = 'DIFF' BEGIN SELECT @CurrentDifferentialBaseIsSnapshot = is_snapshot FROM msdb.dbo.backupset WHERE database_name = @CurrentDatabaseName AND [type] = 'D' AND checkpoint_lsn = @CurrentDifferentialBaseLSN END IF @ChangeBackupType = 'Y' BEGIN IF @CurrentBackupType = 'DIFF' AND @CurrentDifferentialBaseIsSnapshot = 1 BEGIN SET @CurrentBackupType = 'FULL' END END;
這是什麼意思?
翻譯 Ola 的程式碼
好吧,它有點像這樣:
- 獲取
differntial_base_lsn
目前數據庫的值- 如果備份類型是 DIFF 則…
讀取目前數據庫
is_snapshot
的表中的列,備份為(數據庫備份)msdb.dbo.backupset``@CurrentDifferentialBaseLSN``type``D
如果
@ChanageBackupType is
Y`和@CurrentBackupType
是`DIFF和@CurrentDifferentialBaseIsSnapshot
是1
然後
- 設置
@CurrentBackupType
為FULL
在這裡你有一個可能的情況……
解決方案 2
…如果您的數據庫由第三方解決方案(CommVault、NetApp 等)備份,那麼第三方解決方案將使用 SQL Server VSS Writer 服務創建有效且一致的數據庫備份,該服務將在
msdb.dbo.backupset
已拍攝數據庫的快照副本中記錄下來,該副本會為您的 DIFF 所基於is_snapshot
的給定設置該數據庫的參數。differntial_base_lsn
因此,您嘗試執行的 DIFF 備份不能再基於
is_snapshot
備份,並且必須再次創建新的 FULL 備份,以重置is_snapshot
和differntial_base_lsn
值,並為將來的 DIFF 備份創建新的基礎。查找其他備份
您必須確定哪個第 3 方(或其他備份解決方案b)正在干預您實施的解決方案,並確保它們是…
- 修改為共存
- 最小化為一個備份解決方案。