SQL Server运维踩坑20年实战解法

　　跟人吵架——就昨天，客户运维总监在电话里说“你们那套巡检脚本太重，吃资源”，我直接把听筒拿远三秒，听见自己后槽牙磨得咯咯响。他没说完我就接了句：“你上个月用DBCC CHECKDB跑了六小时，磁盘IO打满，连备份都卡住，这会儿倒嫌我脚本重？”他那边突然静了，我听见窗外在下雨，雨点砸在机房北侧彩钢板上，咚、咚、咚，像有人在敲空铁桶。

　　我原以为SQL Server的维护计划能托底——结果它连收缩日志这种事都能在半夜三点触发一个隐式事务锁死tempdb，而没人收到告警。因为维护计划根本不会管你数据库是不是设置了AUTO_CLOSE=ON，更不会提醒你那个数据库的model是2005兼容级——就离谱。张工蹲在机柜前换硬盘，汗从额角淌下来，在防静电服领口洇开一小片深色；他左手捏着螺丝刀，右手正往嘴里塞半块冷掉的肉包子，油星子溅到KVM键盘上。我没拦他，也没提这事——提了也白提，他早把sp_updatestats当万能膏药抹了十年。

文章配图，仅供参考

　　优胜劣汰？对。不是技术优胜劣汰，是人。活下来的全是那些敢在凌晨四点手动kill spid 57、敢把log_reuse_wait_desc查三遍再动DBCC OPENTRAN、敢在AG同步延迟127分钟时拔掉网络线硬切的那个群。其余人要么写了三年自动化部署文档却从来没真正删过一次msdb..sysmaintplan_subplans，要么把“Always On”念得比“always on”还顺溜，但压根不知道alwayson_health Extended Events session默认不收集死锁图——这个我敢打包票，他们连事件文件路径都没配过。

　　王磊上个月在西区机房改完备份策略，转身被叫去帮财务调报表性能，再回来发现Ola Hallengren的IndexOptimize作业跑崩了三次：第一次因参数@TimeLimit=3600写成@TimeLimit=360，第二次因@FragmentationLow=@EmptyString拼错成@FragmentationLow=''（注意单引号多了一个），第三次纯粹是误点了“重新生成”按钮，把全库索引重做一遍，连堆表都不放过。那天机房空调坏了，风扇嗡嗡响得像拖拉机，我站在他身后看他鼠标悬停在“Execute”上十七秒，最后按了Ctrl+Z——手抖的。我没说话，只盯着他显示器右下角时间跳成04:19:22。

　　有个反常识结论：越干净的环境越危险。上周客户说他们“全用Azure SQL托管实例，不用操心底层”，结果我连进去看了三小时才摸清——他们的master数据库居然被挂了个自定义触发器，监听CREATE DATABASE事件，偷偷改掉新库的MAXDOP=1和cost threshold for parallelism=50……谁干的？不知道。触发器名是t_safety_audit_20230918，创建时间显示2023年9月18日，但SQL Agent历史里那天根本没job跑。李敏接了个电话，捂着话筒说“妈，我真不能回去吃中秋饭”，挂了就低头拧紧服务器导轨螺丝，动作比平时慢半拍。

　　还有个事说不准：自动增长步长设成100MB到底伤不伤性能。有人说碎，有人说匀，我说看数据文件底下是不是VMFS卷——但客户不让碰存储层，我也就只能闭嘴。反正他们现在每周一早上九点准点出现CHECKDB超时，每次都重试两次才过。我问要不要加TRACE FLAG 2569，对方眨了眨眼，问我：“这玩意儿……影响业务吗？”桌上放着一份没拆封的麻辣香锅外卖，汤汁在塑料盒底积了一小洼红油，映着监控屏的绿光晃来晃去。

　　我们当年踩坑，靠的是人盯人、眼盯屏、手动抓wait_info、手写kill语句、手算VLF数量。现在呢？全扔给Power BI仪表盘。结果有次大屏红了，所有人凑过去看——原来指标字段用的是sys.dm_db_index_usage_stats.last_user_seek，没加WHERE database_id=DB_ID()，把全实例的累计值全揉一块儿了。运维组长当场打开SSMS，连上master，exec sp_who2，扫了一圈就指出来spid 92在疯狂读msdb..sysjobhistory……但他没动，只是掏出手机开始拍屏。我盯着他手机镜头里反射出的自己：左耳耳机线断了一截，胶布缠了三层。

　　所以我不信什么“智能运维平台”。信的是老刘——五十岁，戴老花镜修SQL Server 2000备份链路修复脚本，修到第三十二遍时，把xp_cmdshell临时打开三秒，只为确认那个UNC路径底下是不是真有那个datestamp命名的子目录。他不写注释，但每行后面都留两个空格，像一种仪式。我问他为啥不迁走，他头也不抬：“迁？谁来教new dba看懂这些空格是干嘛的？”

　　下一步？明早八点我得去客户那儿，看他们刚上的SQL Server 2022 CU13补丁能不能压住那个内存泄漏。如果压不住……我就把SQL Server服务账户密码改成一串十六位乱码，贴在机柜门内侧。让新来的DBA先找十分钟密码——找到再说别的。

（编辑：站长网）

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