SQL Server运维踩坑十年总结：实战排障指南

　　去年十月那场事故，我现在想起来还后槽牙发酸——某库的tempdb膨胀到把磁盘撑爆，监控大屏的绿光闪得跟迪厅似的，开发在群里狂@我“为什么查询超时”，我盯着任务管理器里SQL Server进程占着98%的CPU，第三杯咖啡泼在键盘上都没察觉。后来查日志发现，是某个存储过程里的临时表没加索引，执行计划走的全表扫描——这破事儿要搁十年前，我早该想到，可现在呢？监控告警规则写了三十条，结果最关键的磁盘空间告警阈值设得比实际容量还大，这他妈不是自己挖坑自己跳吗？

　　说句难听的，SQL Server运维这行，优胜劣汰的规则比自然选择还狠。我原以为“备份策略”是最基础的，结果去年帮某客户恢复数据时，发现他们全量备份每天做，差异备份每小时做，可日志备份居然设成了“每周一次”——这操作比不备份还危险，恢复时直接卡在“日志链断裂”上，最后花了十八小时从全量备份里手动重建事务，开发在旁边拍桌子骂“你们DBA是吃干饭的？”我盯着屏幕上的“RESTORE LOG WITH NORECOVERY”命令，心想这锅我背，但下次再遇到这种“自以为懂备份”的客户，我直接甩手册走人。

　　执行计划这事儿，我踩过的坑能堆满三个硬盘。有次某表的主键是GUID，开发非说“自增ID会暴露业务量”，结果查询走索引扫描时，CPU直接飙到100%。我原以为改个数据类型就能解决，结果发现表里有三百多万条历史数据，改主键要重建所有外键约束，恢复演练做了五次，每次都在“ALTER TABLE”命令执行到一半时卡死——最后没办法，只能给查询加“OPTION (OPTIMIZE FOR UNKNOWN)”硬扛，开发在群里阴阳怪气“还是DBA有办法”，我回了个“微笑.jpg”，心里骂了句“去你妈的优化”。

　　说到监控，我敢打包票，九成以上的DBA都吃过“监控假阳性”的亏。某次某库的“连接数超限”告警响了，我冲到机房一看，连接数才五十，阈值设的是两百——结果发现是监控工具把“用户连接”和“系统连接”混在一起算了，真正的问题是某个应用开了三百个短连接，用完没释放。我改完监控规则，开发又跳出来说“你们监控太敏感，影响我们发布”，我直接把监控大屏的截图甩群里：“要么你们改代码，要么我关告警，选一个。”后来他们乖乖加了连接池，这事儿才算完——但我知道，下次遇到类似的坑，他们还是会先甩锅给DBA。

　　工具链这事儿，我见过最离谱的是某团队用“Excel+VBA”管理SQL Server权限。用户权限表存在共享文件夹里，VBA脚本读Excel文件生成GRANT语句，结果有次脚本写错了列名，把“SELECT”权限全给了“PUBLIC”角色——等发现时，某库的敏感数据已经被爬了三天。我查日志时，开发在旁边说“我们用Excel管理权限都五年了，从来没出过问题”，我盯着屏幕上的“GRANT SELECT ON SCHEMA::dbo TO PUBLIC”命令，心想“五年没出问题是因为你们运气好，不是因为这方法靠谱”。后来我强行给他们上了SQL Server Management Studio的权限管理模块，开发抱怨“不如Excel方便”，我回“方便和安全，你选一个”——这次他们没再反驳。

文章配图，仅供参考

　　下一步我打算把这些年踩的坑整理成个“反面教材库”，不是为了显摆，是怕自己忘了——毕竟人老了，记性不如坑多。要是哪天我退休了，后辈遇到类似问题，翻翻这库，说不定能少熬几个夜，少喝几杯咖啡——虽然我知道，他们该踩的坑，一个都少不了。

（编辑：站长网）

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