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

　　会议室空调还在滴水，我盯着对方简历上“精通SQL Server运维”那行字，突然想起去年6月那个凌晨三点——生产库突然卡死，监控显示tempdb的日志文件涨到200G，DBA在群里喊“谁开了隐式事务？”，结果发现是测试环境跑了个没加WHERE的UPDATE语句，连着主库的AlwaysOn同步直接崩了。那会儿我盯着屏幕上的“事务日志已满”，脑子里第一反应是：这破指南要能提前写出来，能少挨多少骂？

文章配图，仅供参考

　　说到监控，我想起上个月面了个自称“运维专家”的，简历上写着“熟悉SQL Server性能调优”，结果我问他“怎么监控长时间运行的查询”，他居然说“看活动监视器”。我差点把咖啡喷在表格上——活动监视器？那玩意儿刷新间隔5秒，等你看到问题，用户早摔键盘了。真正有用的得用Extended Events，或者直接上Query Store，把历史查询数据存起来，出问题时直接翻记录，比活动监视器靠谱一百倍。那哥们儿后来支支吾吾说“没实际用过Query Store”，我直接在评价栏写了“基础工具不熟，pass”。

　　回到“12大故障”，我觉得它站得住的地方是“优胜劣汰”——比如里面提到的“索引碎片超过30%必须重建”，这确实是血泪教训。去年我们有个订单表，索引碎片堆到45%，查询从200ms飙到2秒，DBA愣是没发现，直到业务投诉才去查。后来定了规矩：每周跑一次sys.dm_db_index_physical_stats，碎片超过30%的索引，非高峰期直接重建。现在监控脚本里加了这条，再没出现过因为索引碎片导致的性能问题。不过那哥们儿说的“重建索引要选在线模式”，我倒觉得得看情况——在线重建确实不影响读写，但IO开销大，小表无所谓，大表还是得停机维护，别为了所谓的“高可用”把自己坑死。

　　走廊有股消毒水味，我低头看了眼表——面试已经40分钟了，原计划半小时，这哥们儿还挺能聊。他正说到“备份策略要分全量+差异+日志”，我插了句：“去年我们有个库，备份脚本写错了，全量备份没跑，差异备份基于的基线是三天前的，结果主库挂了，恢复的时候发现差异备份用不了，只能从一周前的全量恢复，丢了三天数据。”他瞪大眼睛：“那业务不炸？”我冷笑：“炸了，客户直接投诉到CEO那儿，运维团队加班三天才把数据补回来——后来我们改了策略，全量备份每天跑，差异备份每小时跑，日志备份每15分钟跑，还加了备份验证脚本，跑完自动检查MD5，确保备份文件能用。”他点头说“确实该这样”，我补了句：“不过最坑的是，那脚本是前同事写的，他离职前没交接清楚，我们花了半个月才理清楚逻辑——所以啊，文档比代码重要，尤其是运维脚本。”

　　说到这儿，我突然想起另一个候选人——去年面了个自称“SQL Server大师”的，简历上写着“优化过百万级数据表”，结果我问他“怎么优化大表分区”，他居然说“用WHERE条件过滤”。我差点笑出声——WHERE条件过滤是查询优化，分区是存储优化，俩概念都分不清，还敢称“大师”？后来查了他简历，发现他之前在一家小公司做开发，只接触过几十万数据的小表，根本没碰过大表运维。这种“纸上谈兵”的，最坑人。

　　回到眼前这哥们儿，他正说到“故障转移要提前测试”，我深有同感。去年我们做AlwaysOn切换演练，结果主库切到备库后，应用连接池没更新，所有请求还是往旧主库发，导致备库被打死，主库反而没事。后来查了半天，发现是连接字符串里没写“MultiSubnetFailover=True”，切换后DNS解析没及时更新，连接池还是认旧IP。现在每次演练前，我们都得检查应用配置，确保连接字符串、超时时间、重试机制都设对，不然切换就是自寻死路。那哥们儿点头说“确实容易忽略”，我补了句：“不过最坑的是，有些开发觉得运维是DBA的事，自己不配合——上次我们让开发改连接字符串，他们说‘影响性能’，死活不改，结果演练失败，被业务骂得狗血淋头。后来我们直接拉上开发负责人一起开会，把风险说清楚，才逼着他们改了。”

　　空调还在滴水，我看了眼表——已经50分钟了，得收尾了。最后我问他：“你觉得SQL Server运维里最容易被忽略的是什么？”他想了想说：“可能是权限管理？”我点头：“对，尤其是sa账号的权限——去年我们有个实习生，用sa账号跑了个存储过程，结果把生产库的表结构改了，业务直接停摆。后来我们收了所有sa权限，改用角色分配，每个账号只给必要的权限，还加了操作审计，谁改了什么都能查到。”他问：“那遇到紧急情况怎么办？”我冷笑：“紧急情况也得按规矩来——去年主库挂了，有人直接用sa账号连上去改配置，结果改错了，问题更严重。后来我们定了死规矩：任何涉及生产的操作，必须先在测试环境验证，再由两人确认，最后由主管签字——宁可慢一点，也别出大事故。”

　　面试结束，我送他出门，走廊的消毒水味更浓了。回到会议室，我看着桌上的简历，突然想起那“12大故障”里还有一条没说——别太依赖自动化脚本。去年我们有个备份脚本，写得太复杂，结果某天磁盘空间不足，脚本没报错，继续跑，把备份文件写到了/tmp目录，第二天被系统自动清理了。等发现时，主库已经挂了三天，最近的备份是五天前的。后来我们改了脚本，加了磁盘空间检查，跑完还发邮件通知，确保每一步都可控。这大概就是“优胜劣汰”吧——运维这行，没踩过坑的，永远不知道坑有多深。

（编辑：站长网）

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