SQL Server运维踩坑17年实战避坑指南

　　做了十七年SQL Server运维的老陈，这会儿正蹲在机房地上擦硬盘——上季度末那台主库宕机，恢复时发现日志文件把D盘撑爆了，三百多个G的日志文件，删都删不掉。我原以为用DBCC SHRINKFILE能搞定，结果卡在“正在收缩”状态二十分钟不动弹，监控警报都快把手机震没电了。这时候运维小王端着外卖进来，汤汁溅到键盘上，他慌慌张张抽纸巾擦，我盯着屏幕喊“别动！别碰任何东西！”，他手一抖，纸巾掉进机箱风扇里了。

　　那台机器是2018年买的，配置早就跟不上，但老板说“再撑两年，等业务转型”。我早劝过他备份策略要改，非说“每天全量备份就够了”，结果这次宕机后，恢复时间从两小时变成八小时——日志备份间隔太长，恢复时得从全量备份点开始重放所有事务，光是等日志文件同步就耗了四小时。更绝的是，恢复过程中发现某个关键表的主键索引碎了，重建索引又卡了半小时，这时候窗外开始下雨，雨点砸在机房玻璃上的声音，跟监控警报的“滴滴”声混在一起，听得人脑仁疼。

　　我蹲在地上擦硬盘时，突然想起2015年那回——也是主库宕机，当时用的还是SQL Server 2008 R2，恢复时发现备份文件损坏，最后是翻出三个月前的旧备份，手动合并了三百多条差异记录。那次老板骂得可凶，说“你们运维是干什么吃的”，结果转头就批了预算买新存储，说“不能让数据再丢”。现在倒好，新存储是买了，可备份策略还是老一套，我提过三次要改，每次都被财务驳回：“多买存储多花钱，现有的够用。”

文章配图，仅供参考

　　所以我现在跟新人说，SQL Server运维的避坑指南就一条：优胜劣汰。该淘汰的硬件必须淘汰，该升级的软件必须升级，该花的钱一分都不能省。别信那些“能用就行”的鬼话，等宕机了，老板可不会听你解释“是因为没买新存储”。就像上季度末这次，恢复完数据后，老板立刻批了预算买新服务器，说“这次要按最高配买，不能再省”。我原以为他只是说说，结果第二天财务就通知我“预算已到账，下周去采购”。

　　不过话说回来，这行干了十七年，最让我后怕的不是宕机，是那些“差点出事”的时刻。比如2019年那次，有个开发误删了生产表，还好有实时备份，五分钟就恢复了；比如2021年那次，存储阵列突然掉线，还好有双活架构，业务没中断；比如上个月，有个新人误改了数据库参数，导致查询变慢，还好我设置了参数变更审计，十分钟就回滚了。这些“差点出事”的时刻，比宕机更考验运维的功底——你得提前把坑都填平，等出事时才能从容应对。

　　现在我坐在新机房里，看着新服务器的指示灯绿得发亮，突然想起十七年前刚入行时，师傅跟我说的话：“运维这行，没有‘差不多’，只有‘行不行’。”当时不懂，现在懂了——所谓的“避坑指南”，不过是把“不行”的选项都淘汰掉，只留“行”的。就像SQL Server的版本升级，2008 R2淘汰了2005，2016淘汰了2012，现在2022都出了，谁还在用2008 R2？谁用谁倒霉。

　　下午运维小王来找我，说“陈哥，新服务器的监控怎么配？”，我指了指屏幕上的告警规则，说“按这个配，别漏任何指标。”他点头记下，又问“那备份策略呢？”，我说“全量+日志，每小时一次，保留七天。”他“哦”了一声，转身要走，我叫住他：“等等，再去跟开发说一声，别在生产环境直接改表结构，必须走变更流程。”他愣了下，说“他们之前没走流程吗？”，我冷笑一声：“要是走了，我上季度末能蹲在地上擦硬盘？”

（编辑：站长网）

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