站长必修：SQL Server运维12大坑及避坑指南

　　去年六月，我蹲在三号机房角落修一个凌晨三点爆掉的镜像端点——不是主库崩了，是见证服务器上那个该死的 sys.dm_hadr_database_replica_states 视图，查出来同步状态是 SUSPENDED，但 log_send_queue_size 居然在往下掉。我盯着它掉了十八秒，然后不动了。老张叼着半截烟进来，说“你等它自己恢复”，我点点头，结果他转身去接了个电话，说他女儿小升初填表卡在户籍栏。那会儿窗外雨刮器坏了，左一下右一下地刮，玻璃上全是斜着的水痕。

文章配图，仅供参考

　　坑一：sp_who2 里看着一切正常，sp_who3 看着也正常，但 application_name 是 “SQLAgent - TSQL JobStep (Job 0x……)” 的那个会话，已经锁住 msdb.dbo.sysjobhistory 三百七十二分钟，而 job history 表上没任何索引。我说这话时，隔壁组阿哲正用纸巾擦键盘上撒的豆浆——他今早赶高铁前买的那杯，漏了。我没拦他，反正他擦完还得重装 SSMS 插件。我原以为加个非聚集索引就完事，结果发现 SQL Server 2016 SP2 后这表居然默认不走 index seek，哪怕你在 where 条件里把 run_date、run_time、step_id 全写死，它还是扫全表。这个我敢打包票。

　　坑二：自动增长设成“按 MB 增长”，但 DBA 临走前改过 master 上的 model 数据库文件增长步长——改成 1MB。于是每次日志撑不住，就咔咔咔切三十次 VLF。上周五下午，有个站的事务日志暴涨到四百G，vlf_count 查出来是八千六百零三。运维跑来问我是不是被攻击了。我没理他，先去茶水间倒水，看见李工蹲在地上拧饮水机后面漏水的软管，拧了三分半钟，拧出两滴水。回来一看，那个库的 recovery model 被人改成 FULL，但从来没做日志备份。我说“补个日志备份就行”，他点头去了。五分钟后他探头问：“备份完能 shrink 吗？” 我说“你shrink试试”，他就真试了——收缩完日志文件变成一千二百个 VLF，比刚才还碎。我手边那碗酸辣粉凉透了，汤浮着一层红油。

　　坑三：tempdb 配置四个文件，每个 8GB，初始大小一样、自动增长一样、都不带 trace flag 1117 和 1118——好家伙，刚上线就全是 PAGELATCH_UP 等待。监控图上蓝线跟心电图似的跳。我调出 sys.dm_os_waiting_tasks，一眼扫到 session_id=57 的 wait_type 是 PAGELATCH_UP，resource_description 是“2:1:109649”。我数了三遍页号。这时陈总监从门口路过，敲了下门框，问“能不能导出最近三天慢查询 TOP100”，我说“行”，他转身就走，没听见我后半句“但导完你得先看下执行计划里有没有 RID Lookup 回表”。

　　坑四：备份压缩开关开着，backupset.compressed_backup_size 却比 backupset.backup_size 还大——说明根本没压进去。查出来是 backup media header 被塞进了乱码字符，SQL Server 没报错，但解压逻辑直接跪了。我们对着 backupset.media_family_id + media_set_id + first_lsn 排查的时候，机房空调突然停了，整个房间嗡一声安静下来，只剩风扇转轴吱呀吱呀，像坏掉的指甲刮黑板。后来发现是 SAN 存储链路抖动导致 media header 写偏两个字节。这事我没报 bug，因为微软 KB 里有段小字写着“不保证跨设备故障场景下的 header 完整性校验”。

　　坑五：AlwaysOn 可读副本上跑报表，查询计划里明明用了 NONCLUSTERED COLUMNSTORE INDEX，执行时却走 clustered index scan——原因居然是 SET ARITHABORT OFF。客户那边的 BI 工具连上来就是 OFF。我们改了连接字符串加了 arithabort=true，报表快了十七倍，但第二天他们又把配置文件回滚了，说是“和另一套 Oracle 报表系统冲突”。那天下午我啃了一整个苹果，核扔进显示器旁的纸篓，没扔准，滚到服务器机柜下面去了。

　　坑六：重建索引时开 online=on，等了四小时没动静。sys.dm_exec_requests 显示 state = suspended，wait_type = LCK_M_SCH_M。一查 blocking_session_id，是 session 128，也就是 SQL Server 自己的内部任务——正在给同一张表更新统计信息。它俩互相等：重建要拿 SCH_M 锁，统计信息更新也要拿 SCH_M 锁，但统计信息更新卡在等一个已释放的旧内存结构回收（这事儿没人写文档）。我叫停重建，手动 exec sp_updatestats，它跑了十一分钟才退出。退出之后，重建命令立刻开始跑。我看着进度条走到 1%，手机震了一下，是我妈发来一张图，问我“路由器黄灯是不是坏了”。

　　优胜劣汰是真的。不是说谁活下来谁牛，是那些不改默认值、不查 DMV、不看 wait_info、不翻错误日志第 387 行的人，系统一升级、一打补丁、一换硬件驱动，啪就掉队了。我去年删过一个作业，它每天零点清空 errorlog，结果 log 太大，xp_readerrorlog 报错超时，作业失败又触发警报邮件风暴，最后堆满邮箱配额。这事过去三个月，现在想起来，手还抖。但我也说不准是不是该上 Extended Events 替代 SQL Trace——Trace 在 2022 版里早就 deprecated 了，可有些老站还在用，而且用得稳如泰山。我就没动。

　　昨天我又去看三号机房，窗上水痕没了，雨停了。老张没来，听说去陪产假。阿哲换了新键盘，没豆浆。我打开 SSMS，连上那个曾挂掉的镜像端点，执行 select top 1 from sys.dm_hadr_database_replica_states。状态是 SYNCHRONIZED。我合上笔记本，起身前顺手把桌上那张皱巴巴的「机房温湿度记录表」翻过来，背面记了三行字：1）下次换 backup compression 设备前先测 header；2）tempdb 文件大小要手工 pre-allocate 到 16GB 以上；3）别信“auto grow 就好”这四个字。至于第四行？没写完。钢笔漏墨，蹭花了。

（编辑：站长网）

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