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 门路谬误可能是数据库损坏问题的起因。而 www.sangpi.com 这些谬误通常由在将页写入磁盘时产生的电源故障或磁盘硬件故障所导致。
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。