Sqlserver關於校驗和_備份還原的CHECKSUM

官方文件


總結
1、資料庫備份的時候啟用備份校驗和，則會消耗更多資源，備份過程也會更慢
2、資料庫備份的時候啟用備份校驗和，備份操作不會向資料庫頁中新增任何校驗和也不會源頁面和頁面內容，只是把備份校驗和儲存在備份片上，也就是生成的備份檔案上
3、如果備份的時候帶CHECKSUM引數，則還原這個備份檔案時候的時候自動也帶CHECKSUM 引數，如果備份的時候不帶CHECKSUM引數，則還原的時候預設就是NO_CHECKSUM
4、校驗和其實就是寫入資料的時候同時寫入一條校驗資訊，讀取資料的時候會計算一個校驗資訊，並把這個校驗資訊和寫入的校驗資訊比較，如果兩個值不匹配，則讀取會失敗。就像資料庫備份的時候如果啟用了備份校驗和則在備份的同時會往生成的備份檔案生成一個備份校驗資訊，恢復的時候也會生成一個備份校驗資訊，這個時候恢復過程生成的備份校驗資訊匹配上了備份檔案的備份校驗資訊，則恢復可以順利進行
5、RESTORE VERIFYONLY僅僅檢查檔案是否符合Microsoft Tape Format (MTF)規範，驗證備份集是否完整以及整個備份是否可讀。 但是，RESTORE VERIFYONLY 不嘗試驗證備份卷中的資料結構，即驗證資料檔案是否損壞，但是不驗證備份檔案是否含有垃圾資料。什麼是垃圾資料，比如你使用一個16進位制的編輯器修改了備份檔案中儲存的資料，這個時候備份檔案沒有損壞但是有垃圾資料，然後再次執行RESTORE VERIFYONLY仍然會返回“備份裝置有效(The backup set is valid)”的資訊。這種情況下我們就可以在備份時使用CHECKSUM選項，它會讀取資料檔案的頁校驗和或頁殘缺檢測並寫入備份檔案生成備份校驗和，後面RESTORE VERIFYONLY的時候就必須驗證這個備份檔案的備份校驗和
6、如果有DBCC CHECKDB了，其實Backup備份的時候可以不需要CHECKSUM引數，因為DBCC CHECKDB也會驗證頁資訊，就算是DBCC CHECKDB的PHYSICAL_ONLY頁會驗證頁面殘缺頁、校驗和錯誤以及常見的硬體故障。PAGE_VERIFY { CHECKSUM校驗 | TORN_PAGE_DETECTION殘缺頁 | NONE }
7、如果備份的時候沒帶CHECKSUM 引數，還原的時候加上了CHECKSUM，因為備份檔案沒有驗和，所以還原會報錯



Backup備份操作是否啟用備份校驗和。
{ NO_CHECKSUM | CHECKSUM } 控制是否啟用備份校驗和。

NO_CHECKSUM 顯式禁用備份校驗和的生成（以及頁校驗和的驗證）。 此選項為預設行為。

CHECKSUM 如果此選項已啟用並且可用，則指定備份操作將驗證每頁的校驗和及頁殘缺，並生成整個備份的校驗和。
使用備份校驗和可能會影響工作負荷以及備份吞吐量。



Restore還原操作是否啟用備份校驗和。
{ CHECKSUM | NO_CHECKSUM }
支援的語句：RESTORERESTORE FILELISTONLYRESTORE HEADERONLYRESTORE LABELONLY 和 RESTORE VERIFYONLY。
預設行為是在存在校驗和時驗證校驗和，在不存在校驗和時不進行驗證並繼續執行操作。也就是說如果備份的時候帶CHECKSUM引數，則還原這個備份檔案時候的時候自動也帶CHECKSUM 引數，如果備份的時候不帶CHECKSUM引數，則還原的時候預設就是NO_CHECKSUM

CHECKSUM
指定必須驗證備份校驗和，在備份缺少備份校驗和的情況下，該選項將導致還原操作失敗，並會發出一條訊息表明校驗和不存在。
預設情況下，當遇到無效的校驗和時，RESTORE 會報告校驗和錯誤並停止。 然而，如果指定了 CONTINUE_AFTER_ERROR，RESTORE 會在返回校驗和錯誤以及包含無效校驗和的頁面編號之後繼續。
備註1：僅當使用備份校驗和時，頁校驗和才與備份操作相關。
備註2：也就是說如果備份的時候沒帶CHECKSUM 引數，還原的時候加上了CHECKSUM，因為備份檔案沒有驗和，所以還原會報錯

NO_CHECKSUM
顯式禁用還原操作的校驗和驗證功能。






備份校驗和
    SQL Server 支援三種校驗和：頁校驗和、日誌塊校驗和以及備份校驗和。 生成備份校驗和時，BACKUP 將驗證從資料庫讀取的資料是否與資料庫中存在的任意校驗和或頁殘缺指示一致。
    BACKUP 語句選擇性地計算備份流的備份校驗和；如果給定頁上存在頁校驗和或殘缺頁資訊，則當備份該頁時，BACKUP 還將驗證它的校驗和、殘缺頁狀態以及 ID。 建立備份校驗和時，備份操作不會向頁中新增任何校驗和。 將在這些頁位於資料庫中時對其進行備份，備份不會修改這些頁。
    由於驗證和生成備份校驗和引起的開銷，使用備份校驗和會對效能造成潛在的影響。 工作負荷和備份吞吐量都可能受到影響。 因此，不是必須使用備份校驗和。 如果決定在備份過程中生成校驗和，請仔細監視由此引起的 CPU 開銷以及對系統中任何併發工作負荷造成的影響。
    BACKUP 永遠不會修改磁碟上的源頁面和頁面內容。


在啟用備份校驗和後，備份操作將執行以下步驟：
1、向備份介質寫入頁之前，備份操作將驗證頁級資訊（頁校驗和或頁殘缺檢測）是否存在。 如果兩者都不存在，則備份無法驗證頁。 將按原樣包含未經驗證的頁，並且其內容將新增到總備份校驗和中。如果備份操作在驗證過程中遇到頁錯誤，備份將失敗。
2、無論是否存在頁校驗和，BACKUP 都會為備份流生成一個單獨的備份校驗和。 還原操作可使用（可選）備份校驗和來驗證該備份是否損壞。 備份校驗和儲存在備份介質上，而不是儲存在資料庫頁上。 備份校驗還可根據需要在還原時使用。
3、備份集標記為包含備份校驗和（在 msdb..backupset 的 has_backup_checksums 列中）。 有關詳細資訊，請參閱 backupset (Transact-SQL)。

備註1、在還原操作過程中，如果備份介質中存在備份校驗和，則預設情況下，RESTORE 和 RESTORE VERIFYONLY 語句都將驗證備份校驗和及頁校驗和。 如果不存在備份校驗和，則這兩種還原操作直接執行，而不會進行驗證；這是因為沒有備份校驗和，還原無法可靠地驗證頁校驗和。
備註2、有關頁校驗和及頁殘缺檢測的詳細資訊，請參閱 ALTER DATABASE 語句的 PAGE_VERIFY 選項。 有關詳細資訊，請參閱 ALTER DATABASE SET 選項 (Transact-SQL)。





ALTER DATABASE SET 選項 (Transact-SQL)
PAGE_VERIFY { CHECKSUM | TORN_PAGE_DETECTION | NONE }
發現磁碟 I/O 路徑錯誤引起的損壞的資料庫頁面。 磁碟 I/O 路徑錯誤可能是資料庫損壞問題的原因。 這些錯誤通常由在將頁寫入磁碟時發生的電源故障或磁碟硬體故障所導致。

CHECKSUM
在向磁碟中寫入頁面時，計算整個頁面內容的校驗並將該值儲存在頁首中。 從磁碟中讀取頁時，將重新計算校驗和，並與儲存在頁頭中的校驗和值進行比較。 如果兩個值不匹配，將同時在 SQL Server 錯誤日誌和 Windows 事件日誌中報告錯誤訊息 824（指示校驗和失敗）。 校驗和失敗指示存在 I/O 路徑問題。 若要確定其根本原因，需要調查硬體、韌體驅動程式、BIOS、篩選器驅動程式（如防病毒軟體）和其他 I/O 路徑元件。

TORN_PAGE_DETECTION
將頁面寫入磁碟時，將每個 512 位元組扇區的特定 2 位模式儲存在 8 KB 資料庫頁面中並儲存在資料庫頁頭中。 從磁碟中讀取頁時，頁頭中儲存的殘缺位將與實際的頁扇區資訊進行比較。
如果值不匹配，表明只有頁面的一部分被寫入磁碟。 在這種情況下，將同時在 SQL Server 錯誤日誌和 Windows 事件日誌中報告錯誤訊息 824（指示頁撕裂錯誤）。 如果頁面寫入確實不完整，則資料庫恢復通常會檢測到頁撕裂。 不過，其他 I/O 路徑故障可能隨時導致頁撕裂。

NONE
資料庫頁寫入不會生成 CHECKSUM 或 TORN_PAGE_DETECTION 值。 在讀取過程中，即使頁頭中存在 CHECKSUM 或 TORN_PAGE_DETECTION 值，SQL Server 也不會驗證校驗和或頁撕裂。


使用 PAGE_VERIFY 選項時，請考慮下列重要事項：
1、預設值為 CHECKSUM。
2、使用者資料庫或系統資料庫升級到 SQL Server 2005 (9.x) 或更高版本後，PAGE_VERIFY 值（NONE 或 TORN_PAGE_DETECTION）不會更改。 建議更改為 CHECKSUM。
3、ORN_PAGE_DETECTION 可能使用較少資源，但提供的 CHECKSUM 保護最少。
4、無需使資料庫離線、鎖定資料庫或以其他方式阻止對資料庫的併發訪問，即可設定 PAGE_VERIFY。
5、CHECKSUM 與 TORN_PAGE_DETECTION 互相排斥。 不能同時啟用這兩個選項。



備註1、在 SQL Server 的早期版本中，TempDB 資料庫的 PAGE_VERIFY 資料庫選項設定為 NONE 且不能修改。 從 SQL Server 2008 開始，對於新安裝的 SQL Server，TempDB 資料庫的這一預設值為 CHECKSUM。 如果是升級安裝的 SQL Server，則預設值仍為 NONE。 可以修改該選項。 我們建議為 tempdb 資料庫使用 CHECKSUM。
備註2、檢測到頁撕裂或校驗和失敗時，如果失敗僅限於索引頁，則可透過還原資料進行恢復，可能還需要重建索引進行恢復。 如果要在校驗和失敗的情況下確定受影響的一個或多個資料庫頁面的型別，請執行 DBCC CHECKDB。 有關還原選項的詳細資訊，請參閱 RESTORE 引數。 雖然還原資料可解決資料損壞問題，但應儘快診斷並糾正根本原因（如磁碟硬體故障），以防止繼續出錯。
備註3、SQL Server 將對因校驗和、頁撕裂或其他 I/O 錯誤而失敗的任何讀取都重試四次。 如果在任何一次重試中讀取成功，則會向錯誤日誌寫入訊息。 觸發讀取的命令會繼續執行。 如果重試失敗，則該命令失敗，且顯示錯誤訊息 824。