要模拟备份时 CHECKSUM 检测到错误并中断，最有效的方法是直接修改数据库数据页的底层二进制数据（即人为制造物理损坏/Page Corruption）。
在 SQL Server 中，无法通过常规的 UPDATE 语句破坏页面校验和，因为引擎会自动重新计算。我们需要使用未公开的危险命令 DBCC WRITEPAGE 来直接篡改磁盘上的字节。
以下是完整的模拟步骤（请务必在独立的测试数据库中操作，绝对不能在生产环境运行！）：
第一步：准备测试数据库和表
首先，创建一个名为 TestVerify 的干净数据库，并写入一条测试数据。
-- 1. 创建测试数据库
CREATE DATABASE TestVerify;
GO
USE TestVerify;
GO
-- 2. 设置页面校验和为 CHECKSUM（默认通常也是这个）
ALTER DATABASE TestVerify SET PAGE_VERIFY CHECKSUM;
GO
-- 3. 创建一张简单的表并插入数据
CREATE TABLE TestTable (ID INT IDENTITY(1,1), Name VARCHAR(100));
INSERT INTO TestTable (Name) VALUES ('Row_To_Be_Corrupted');
GO第二步：找出数据所在的物理页面（Page ID）
我们需要知道数据存放在哪个数据页上，以便对其进行精准破坏。
-- 使用 DBCC IND 查看表的页面分配
-- 参数: ('数据库名', '表名', 1代表聚集索引或堆)
DBCC IND ('TestVerify', 'TestTable', 1);
GO
运行后在结果集中找到：
PageType = 1的那一行（1 代表数据页 Data Page）。- 记住这一行的
PageFID（文件 ID，通常是 1）和PagePID（页面 ID，例如是 240）。
直接篡改数据行的内容（比如把字母 'R' 改掉）
-- 1. 开启跟踪标记，允许将 DBCC 的结果输出到 SSMS 消息窗口
DBCC TRACEON (3604);
GO
-- 2. 查看页面内容
-- 参数: ('数据库名', 文件ID, 页面ID, 输出格式)
-- 输出格式 0 代表只打印页面头部，1 代表打印每行的十六进制和文本对照（推荐）
DBCC PAGE ('TestVerify', 1, 240, 1);
GO
- 原值分析 ：在数据行的内存镜像中，十六进制的
52代表大写字母R（即Row的开头）。 - 寻找绝对偏移量（Offset） ：
Slot 0的起始绝对偏移量是0x60（十进制的96）。- 从
3000...开始数，十六进制的52位于第 16 个字节的位置（从 0 开始算偏移是 15）。 - 因此，字母 'R' 在整个页面中的绝对偏移量是
96 + 15 = 111。
你想改成 0x33 的话，命令应该这样写：
第三步：使用 DBCC WRITEPAGE 故意破坏页面结构
现在，我们把数据库设为单用户模式，然后直接向这个页面写入错误的垃圾数据，从而破坏它的 Checksum 校验。
注意：请将下面代码中的 312 替换为你上一步实际查到的 PagePID。
-- 切换单用户模式
ALTER DATABASE TestVerify SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO
DBCC TRACEON (3604, 2588);
GO
-- 将偏移量设为 111，把字母 'R' (0x52) 强行篡改为 0x33（字符 '3'）
DBCC WRITEPAGE ('TestVerify', 1, 240, 111, 1, 0x33,1);
GO
DBCC TRACEOFF (3604, 2588);
GO
-- 恢复多用户
ALTER DATABASE TestVerify SET MULTI_USER;
GO
-- 1. 开启跟踪标记，允许将 DBCC 的结果输出到 SSMS 消息窗口
DBCC TRACEON (3604);
GO
-- 2. 查看页面内容
-- 参数: ('数据库名', 文件ID, 页面ID, 输出格式)
-- 输出格式 0 代表只打印页面头部，1 代表打印每行的十六进制和文本对照（推荐）
DBCC PAGE ('TestVerify', 1, 240, 1);
GO
第四步：测试备份，见证 CHECKSUM 报错 🚨
现在，我们运行带有 WITH CHECKSUM 的备份命令。由于磁盘上的页面已被破坏，备份会立刻中断并报出物理损坏的错误。
BACKUP DATABASE [TestVerify] TO DISK = N'S:\tmp\TestVerify.bak' WITH NOFORMAT, INIT,
NAME = N'TestVerify-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10, CHECKSUM
GOExpected Output (预期错误信息)：
你会看到类似下面的报错，提示遇到了 输入/输出(I/O)错误，并且明确指出了 Checksum 不匹配
通过这个实验，你可以直观地看到 CHECKSUM 是如何在第一时间内拦截坏数据的。如果你想进一步了解当遇到这种备份报错时，应该通过什么步骤去尝试挽救或修复数据库，请告诉我！