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

　　去年三月份那会儿，我原以为SQL Server的备份策略已经够稳了——每天全量，每小时差异，结果呢？周一早上九点，开发说测试库的数据全没了，我一查备份日志，好家伙，差异备份从上周五下午三点就开始报错，但错误信息被日志轮转给吞了，监控系统愣是没告警。当时我盯着屏幕，机箱风扇嗡嗡转，水杯底结的那圈渍都快赶上咖啡渍了，突然就想起十六年前第一次碰SQL Server，那时候连备份恢复都要翻手册，现在倒好，自动化工具倒是多了，坑也跟着升级了。

　　你说这优胜劣汰是不是真理？我见过太多公司，SQL Server版本还是2008 R2，补丁都没打全，运维全靠人肉脚本——不是他们不想升级，是升级成本太高，业务停机半小时，老板能追着CTO骂三天。可结果呢？去年有个客户，数据库被勒索病毒加密，恢复的时候发现备份文件早就被覆盖了，最后只能从开发环境的测试库里扒数据，那还原度，啧啧，连订单时间都差了半小时。这时候你说，是该怪运维没做好监控，还是该怪老板舍不得花钱升级？

　　我旁边那前端小哥，昨天还在吐槽设计稿的还原度——他说切图的时候发现设计稿里的圆角是8px，但实际开发环境里渲染出来是7.9px，差点没把显示器砸了。我听着就乐了，这跟SQL Server的兼容性问题有啥区别？记不清是哪个版本了，SQL Server 2016刚出那会儿，有个存储过程用了新的窗口函数，结果在2014的环境里跑，直接报“语法错误”，开发说“我本地跑得好好的啊”，我查了半天才发现是版本不兼容。这时候你说，是该怪开发没测环境，还是该怪DBA没提前通知升级？

文章配图，仅供参考

　　说到并行查询，我前几天还跟一个后端吵了一架。他说他们的存储过程跑得慢，是因为SQL Server的并行度设置得太低，非要我把MAXDOP从4改成8。我查了执行计划，发现根本不是并行的问题，是有个WHERE条件没走索引，导致全表扫描。我让他改SQL，他偏不，说“改代码要重新部署，风险太大”。结果呢？我偷偷把MAXDOP改成8，监控显示CPU占用率直接翻了一倍，查询时间反而更长了——因为并行查询的线程多了，但数据量没变，线程切换的开销反而更大。最后他没办法，只能老老实实改SQL。你说这算不算优胜劣汰？不懂执行计划的被淘汰，不懂并行开销的也被淘汰，最后活下来的，都是那些既懂SQL优化又懂并行配置的。

　　我桌上那堆数据线，缠得跟麻花似的，每次插U盘都得找半天。这跟SQL Server的权限管理有啥区别？记不清是哪个项目了，开发说他们需要访问某个数据库的只读权限，我给了，结果过了两天，发现他们居然能执行DROP TABLE——原来我给的权限是db_datareader，但那个数据库的owner是开发组的账号，他们通过owner权限绕过了只读限制。我查了半天，发现是SQL Server的权限模型太复杂，db_datareader、db_datawriter、db_owner，还有服务器角色的sysadmin、securityadmin，稍不注意就留漏洞。这时候你说，是该怪DBA没设好权限，还是该怪SQL Server的权限模型太反人类？

　　外卖塑料袋响个不停的时候，我正盯着构建进度条——卡在87%不动了，浏览器开了三十来个标签，内存占用98%，我差点想直接重启电脑。这时候我突然想到，SQL Server的内存管理不也这样吗？默认设置是动态内存，SQL Server会尽量占满所有可用内存，结果导致操作系统和其他应用卡死。我见过太多服务器，SQL Server占了32G内存，操作系统只剩512M，连远程桌面都连不上。你说这算不算优胜劣汰？不懂内存配置的被淘汰，不懂资源隔离的也被淘汰，最后活下来的，都是那些既懂SQL Server内存管理又懂操作系统资源限制的。

　　现在想想，这十六年踩过的坑，大部分都是因为“我以为”——我以为备份不会出错，我以为权限不会泄露，我以为并行查询一定更快，结果现实总是给我一巴掌。所以我现在学乖了，监控必须全，日志必须留，权限必须最小化，优化必须看执行计划。至于那些“优胜劣汰”的道理，说白了就是，谁踩的坑多，谁活得久。就像我桌上那盆绿萝，养了三年都没死，不是因为它多强壮，是因为我忘了浇水的时候，它自己会从空调水里找水喝。

　　不过话说回来，有些坑是真没法避——比如老板突然说要迁移到云数据库，或者开发说要用NoSQL替代SQL Server。这时候我只能叹口气，把备份策略再检查一遍，把监控告警再调敏感点，然后默默祈祷，别在迁移的时候出幺蛾子。毕竟，运维这活儿，就是一边踩坑，一边填坑，填着填着，就成老油条了。

（编辑：52站长网）

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