加入收藏 | 设为首页 | 会员中心 | 我要投稿 站长网 (https://www.0516zz.com/)- 智能数字人、图像技术、AI硬件、数据标注、数据治理!
当前位置: 首页 > 站长学院 > MsSql教程 > 正文

SQL Server运维11年踩坑实录:实战排障指南

发布时间:2026-10-22 11:26:59 所属栏目:MsSql教程 来源:DaWei
导读:  去年寒假,凌晨三点十七分,我蹲在IDC二号机房B排第七柜前面,左手捏着一块拧干的抹布擦SSD槽位标签——不是为清洁,是那标签翘边刮手。空调冷凝水正顺着桥架滴到脚踝上,嗒、嗒、嗒。老张在对面柜子底下喊“日志轮转又卡

  去年寒假,凌晨三点十七分,我蹲在IDC二号机房B排第七柜前面,左手捏着一块拧干的抹布擦SSD槽位标签——不是为清洁,是那标签翘边刮手。空调冷凝水正顺着桥架滴到脚踝上,嗒、嗒、嗒。老张在对面柜子底下喊“日志轮转又卡死了”,我没应,先把抹布塞进裤兜,湿的,得等会儿再拿出来甩两下。


  我原以为是tempdb争用,结果查完sp_who3发现是某个运维同事手动跑了ALTER DATABASE SET READ_COMMITTED_SNAPSHOT ON,但没等GO就切屏回微信抢红包,后面脚本全挂在事务里没提交。那个数据库的log_reuse_wait_desc死在XACT_ABORT上,三十八分钟。我敢打包票,他微信头像还是那只叼玫瑰的柴犬,去年年会抽奖抽的,现在还挂那儿。


  机房噪音忽大忽小,是三号UPS风扇轴承快散了,嗡——嗡——嗡——,中间夹着王工接电话:“嗯…对…主从延迟?主从?哦你说镜像…那没同步链路啊…”他边说边用指甲抠键盘托盘缝里的瓜子皮,一粒、两粒、三粒。我盯着他抠第三粒时,SQL Server Agent服务突然自启了——没人动它,就是自己醒了。这个我说不准,监控里没留下任何触发痕迹,WMI事件日志清空过,但不是我们清的。


文章配图,仅供参考

  优胜劣汰?对。不是指产品,是人。活下来的不是最懂锁升级路径的,是那个记得每次改完maxdop都顺手去SQL Server Configuration Manager里确认TCP端口没被自动重置的;不是背得出全部137个wait type的,是那个看见sp_server_diagnostics输出里有个‘io_completion’抖动就立刻去翻存储多路径软件版本号的。上个月刚走的李锐,写了个自动巡检脚本,能把每个instance的backupset count按周环比画成折线图——好看极了,报表组夸了三次。但他没加一句判断:如果msdb里某条backupset的physical_device_name字段是NULL,后续所有count全错。他离职前一晚跑出来的报表,全是0。没人问他为啥,报表跑出来了,图也绿了,行了。


  我泡的那杯速溶咖啡搁在机柜顶板上,早凉透了,表面浮着层薄薄的褐色油膜。外卖单子压在键盘下面,是昨天晚饭的,备注写着“不要香菜”,可送来的是青椒肉丝。现在还在那儿。这事和SQL Server没关系,但和我的情绪有关系——你信不信,那天我改完登录名对应的SID映射,执行完ALTER LOGIN [domain\\user] WITH PASSWORD = 'x' UNLOCK后,心里想的是:这青椒肉丝,明天还能吃么?


  别信所谓“最佳实践清单”。第十七条写着“Always enable Instant File Initialization”,但没写“除非你的sysadmin里混进了一个AD组策略管理员,他上周把本地策略推送到所有DB服务器,而那个策略里恰好禁用了SeManageVolumePrivilege”。真事。推策略的人叫陈默,三十出头,戴黑框眼镜,发邮件永远用“Hi All”,从不@具体人。他推完策略那天,我在恢复一个8TB数据库,data file扩展等了二百一十四秒——比心跳还长。我删了邮件草稿箱里写到一半的投诉,改成了“请教下,能否帮忙确认下域策略中关于SeManageVolumePrivilege的部署范围?”他回得很快:“Hi All,已确认无全局影响。”


  其实最耗神的不是死锁图,是猜用户到底改过啥。用户说“我就点了一下‘刷新’”,然后blocking chain拉出来五层,最后源头是个sleeping session,last_request_start_time是三天前。我查syssessions,查dm_exec_requests,查ring buffer,最后在default trace里翻到一条Audit Database Object Access Event,对象名是usp_generate_report_v2_legacy_copy_old。这玩意根本不在任何作业里,也不在任何应用代码库里。我问前端负责人,他愣住三秒,说:“哦…那个啊,我们测试环境删库前手动执行过一遍,怕报表数据污染。”删库?他脸上一点愧意没有,反而笑着给我看手机里刚收到的钉钉消息截图:“运维说他们没做任何操作”,落款时间比他执行usp还早十八秒。我盯着那条消息,突然想起我妈去年冬天炖的排骨汤,火太大,锅底焦了,她掀盖时那股糊味冲得我打喷嚏。就是那种味道,现在还记得。


  上个月我重新装了一台Windows Server,补丁升到最新,SQL Server打上CU23,Agent作业全配置好,启动项检查三遍。交出去当天下午,用户反馈查询慢。我看执行计划,nested loop右表走了PK扫描,统计信息明明两小时前刚更新过。登上去一查,auto_update_statistics_async 是 OFF,但auto_update_statistics 是 ON。我以为没问题。直到看见sys.dm_db_stats_properties返回的modification_counter是421万,而上一次update是三百七十二天前。不是服务器时间错了——是系统表里那个datetime列,存的是UTC,而我们所有监控脚本读的是localtime,差八小时,于是所有“过去24小时”判断都失效了。没人注意到,因为没人真去看stat update timestamp,只看status是不是“updated”。这个我敢打包票,我亲手改过六次syspolicy_policies表,就为绕过那个该死的评估频率校验。


  现在我把每台新装实例的SQL Server Agent服务启动类型,全改成“手动”。等第一次备份做完、第一个索引维护跑通、第一个告警通知发出之后,再改回来。就这么简单。别的先不管。反正我桌上那盒金嗓子,含片只剩三颗了。

(编辑:站长网)

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