SQL Server DBA六年实战运维手册

　　去年十一月，凌晨三点十七分，监控告警弹窗在副屏右下角跳第三下——不是红的，是灰的，就那种Windows通知中心里被系统静音过的浅灰，标题栏写着“SQL Server DBA六年实战运维手册”八个字，底下小字：备份校验失败（差异备份集 #7）。我伸手去够咖啡杯，杯子空的，杯底黏着半片干掉的橘子皮，我原以为是昨天下午啃的，结果摸到边缘发硬、没糖霜、也不是橘子——是梨子皮，上周三市场部发的试吃装，早该扔了。

　　我点开日志路径，/var/opt/mssql/data/backup/checksums/202311/weekly_07，文件存在，权限是640，属组mssql，但md5sum比对不上——不是算错了，是校验值本身就被写进了日志的第十九行，和实际读出来的值差了三位。我盯着那三字符，B9F 而不是 B9E，像打字员手滑按了F而不是E，可这是自动脚本生成的日志，连空格都是trim过的。这时候张工推门进来，头发翘着，拎着个印着“联通营业厅”的塑料袋，里面晃荡两罐凉透的啤酒。他站我身后看了二十来秒，说：“你信这个标题？”

　　我没回，点了重跑校验——第八次。上一次成功是十月二十八号凌晨四点零六分，那天刚好台风“尼格”登陆粤西，机房空调压缩机歇了十二分钟，UPS扛住了，但tempdb缓存全丢，所以那次备份其实压根没走CHECKSUM通路，只是绕过了——我们后来查出来是启用了trace flag 3042临时降级，但没人记得这事是谁加的，日志里只留了一行#COMMENT：临时避坑。而这一次没有台风，没有空调报警，什么都没有，只有那个灰底白字的标题，在凌晨三点十七分准时跳出来，像打卡。

　　我改了脚本，在checksum比对前插了个sleep 0.3，再跑。成了。但我知道这不是原因——睡0.3秒解决不了MD5散列碰撞，它只是让系统多等了三百毫秒，恰好错开了某个时钟抖动窗口。我把这段删了，重新跑无sleep版本，又挂了。再插sleep，又过。反复四次，中间有次sleep设成0.31，失败；0.29，也失败；只有0.30和0.3000001能过。服务器时间同步用的是chrony，NTP源是内网ntp-sz-02，这台我亲手配的，没改过 driftfile 路径。反正我就盯住那个灰标题，它就悬在那儿，不报错，不恢复，不消失，也不变颜色，就维持着被系统忽略的那种灰。

文章配图，仅供参考

　　后来我翻到一份旧配置快照，是八月份导出的，里面有一行被注释掉的参数：–with-checksum-fallback=on，底下括号里手写一行小字：“测过，和log backup sequence mismatch冲突”。我也不知道这行是谁写的，字体不像我的，倒像张工以前爱用的圆珠笔字迹，但张工说他从不手写注释，他说“写了等于没写”。他说话时正剥第二罐啤酒的拉环，金属声很脆，拉环飞出去撞在防火门上，弹回来滚进通风口格栅里，不见了。

　　最后我手动把那个差异备份集从restore history表里删了，清了msdb.dbo.backupset里的关联记录，重做一次完整备份，再做差异——这次校验通过了，标题也没跳。但它站得住的地方，真就是优胜劣汰：不是逻辑最优，不是设计最稳，是活下来的那条路径，刚好没撞上时钟抖动+checksum缓存读取偏移+log sequence解析器某处未对齐的边界条件组合。我也不知道下一回是第几次会触发。有谁碰到过这个吗

（编辑：航空爱好网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!