17年云运维老兵亲授：SQL Server运维避坑实战指南

文章配图，仅供参考

　　优胜劣汰这事儿，在SQL Server运维里特别明显。我见过太多团队，把云厂商的RDS当本地SQL Server用——备份策略照搬，高可用配置照搬，连索引维护脚本都直接迁移。结果呢？去年双十一前，某电商团队用Azure SQL Database，把本地维护窗口的索引重建命令直接扔上去，直接触发自动缩容，生产库从P6缩到P2，订单系统卡了十八分钟。后来复盘才发现，云上的资源弹性是双刃剑，你当它是本地物理机玩，分分钟教你做人。

　　说到备份，上周还有个更离谱的。某金融团队用AWS RDS，配置了自动备份到S3，结果测试恢复时发现，备份文件是加密的，但密钥管理策略没同步到云账号。测试机排了一排，从SQL Server 2016到2022各个版本，全卡在"无法解密备份文件"这一步。产品经理在旁边嘀咕："就这么点东西，怎么恢复这么麻烦？"我盯着屏幕上那个0x80090005的错误码，心想：您要是早听我的，把密钥管理策略单独列个文档，现在至于在这儿干瞪眼？

　　地铁上掏手机复现过最离谱的坑：某次客户反馈SQL Server Agent作业偶尔失败，日志里全是"The job failed. Check the job history for details."这种废话。我原以为是权限问题，结果在地铁上用手机连VPN查，发现是云厂商的维护窗口和作业执行时间重叠——云平台自动重启实例时，刚好把正在运行的作业掐断了。更绝的是，这个行为在某个小版本的文档里写了，但没标红，也没在变更通知里提。那天我举着手机在车厢里来回踱步，旁边大妈用看神经病的眼神瞅我，我满脑子都是：这他妈也叫"高可用"？

　　参数调优这块，云上的SQL Server和本地完全两码事。我见过有人把max degree of parallelism从8改成4，结果在云上性能反而下降——因为云实例的CPU是虚拟化的，逻辑核心数和物理核心数不对等。去年帮某游戏团队优化，发现他们的SQL Server 2019在Azure上跑，查询计划总走错，最后发现是云平台的"智能查询处理"功能在某个补丁后默认开启了，和他们的自定义统计信息冲突。那天我蹲在测试环境里，把SQL Server的配置参数翻了个底朝天，发现云厂商的文档里，关于"智能查询处理"的说明只有三行，其中两行还是"可能影响性能"。

　　说到文档，云厂商的文档有时候比没写还坑。某次客户用GCP Cloud SQL，遇到"Could not allocate space for object 'dbo.SORT temporary run storage'"错误，我查官方文档，搜"tempdb space allocation"，跳出来的第一条是"How to resize your Cloud SQL instance"——教你怎么扩容，但没提云上的tempdb空间是动态分配的，和本地SQL Server的预分配机制完全不同。后来在社区论坛翻到个三年前的帖子，才找到解决方案：得在连接字符串里加"MultipleActiveResultSets=True"。我盯着屏幕上的解决方案，突然想起上周产品经理说的那句话："云上的东西，不都是开箱即用吗？"

　　现在我最怕听到的词是"自动"。自动备份、自动扩容、自动统计信息更新——这些功能听起来美好，但背后全是坑。某次客户用AWS RDS的自动备份，结果备份文件在S3上存了三个月，突然有一天全消失了——因为云账号的IAM策略被误修改，备份文件的生命周期被设成了"30天后删除"。更绝的是，这个修改是三个月前某个实习生操作的，当时没走变更流程，现在连日志都查不到。那天我盯着S3控制台里空荡荡的文件夹，突然明白：云上的"自动"，本质是把运维的责任转嫁给了你，只是换了个更隐蔽的方式。

　　现在我带团队，第一条规定就是：云上的SQL Server，必须当全新系统对待。本地那套经验，最多只能用30%，剩下的70%得重新学。上周有个新人问我："老师，云上的SQL Server和本地到底有啥区别？"我指着测试机上的三个实例——SQL Server 2016、2019、2022，分别跑在Azure、AWS、GCP上——说："区别？区别就是，你得把每个云平台的文档都当圣经读，还得随时准备被圣经里的'可能'、'建议'、'通常'坑死。"

　　写到这儿，突然想起桌上那排测试机还开着，SQL Server 2022的安装界面卡在"正在配置组件"已经二十分钟了。行吧，先去重启下，顺便把今天遇到的这个坑记下来——说不定明天就能用上。

（编辑：站长网）

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