SQL Server DBA必备：数据库运维实战手册

　　2025年2月那会儿，运维群里突然炸出本《SQL Server DBA必备：数据库运维实战手册》，我原以为又是那种“高可用配置分三步”的口水书，结果翻到第三章直接拍大腿——这作者怕不是在我工位装了监控？上周刚被一个Always On的同步延迟坑到凌晨三点，书里直接给了个“用扩展事件抓主库等待”的骚操作，我试了下，三分钟定位到是网络丢包，比之前用Perfmon瞎猜快十倍。

　　但最绝的是“优胜劣汰”那章。上周五中午，我正对着外卖盒扒拉米饭，群里@我的消息突然刷屏——生产库的CPU飙到95%，监控报警声比食堂的剁椒鱼头还刺耳。按老经验，我第一反应是查阻塞，结果跑DBCC INPUTBUFFER(spid)全是些“SELECT FROM BigTable”的烂SQL。正准备杀进程，突然想起书里说的“先看资源等待类型”，用sys.dm_os_waiting_tasks一查，好家伙，70%的线程在等PAGEIOLATCH_SH，明显是内存不足导致的物理读暴增。我原以为得加内存，结果按书里教的调了max server memory，把缓冲池压到合理范围，CPU直接掉回10%——这他妈比加内存省钱多了。

　　不过说真的，这书也不是没槽点。上周三凌晨两点，我在机房修备用机，噪音大得像有人在我耳边敲锣，翻到“备份恢复”那章，作者居然还在推荐“完整备份+差异备份”的老套路。我差点把书摔了——现在都2025年了，谁还用差异备份？增量备份配合CDC，恢复速度能快三倍不止。但转念一想，可能作者考虑到传统行业的兼容性？毕竟有些银行还在用SQL Server 2012，连含蓄查询都不支持，更别说CDC了。

　　说到兼容性，上周五下午，测试环境突然报错“列名 'xxx' 无效”，我一看，是开发把存储过程里的临时表列名改了，但没同步到所有分支。要是按以前，我得逐个脚本比对，但书里提了个“用SQL Data Compare工具自动同步”，我试了下，五分钟搞定，比手动改省了俩小时。不过这工具有个坑——如果目标库有约束，同步会失败，得先禁用约束再同步，再启用。这点作者没提，我踩了两次才记住。

　　对了，昨天中午，运维群又有人发了个表情包，是只猫抱着键盘哭，配文“DBA的命也是命”。我顺手把书里“自动化巡检脚本”那节甩过去，结果对方回了个“这脚本在我这跑不通”。我让他发错误日志，一看，好家伙，他居然用PowerShell 5.0跑我写的PS7脚本，能通才怪。这让我突然意识到，书里那些“优胜劣汰”的案例，可能得结合具体环境看——就像有人觉得Always On比日志传送高级，但有些小公司连域控都没有，根本玩不转Always On，这时候日志传送反而更稳。

　　其实最让我感慨的是“性能调优”那章。上周四，QPS突然从三千掉到五百，我按书里教的，先用sp_who2找阻塞，结果没阻塞；再用sys.dm_exec_requests看等待类型，全是CXPACKET，说明是并行查询的问题。我原以为得调MAXDOP，结果书里说“先查执行计划，看是不是表扫描导致的并行”，我一查，果然是有个大表没索引，全表扫描触发了并行。加个索引后，QPS直接回到三千二——这比盲目调MAXDOP管用多了。不过话说回来，有些老DBA总觉得“并行查询就是快”，其实并行是把双刃剑，用不好反而拖慢性能，这点书里没展开说，可能是怕得罪人？

　　现在这书在我工位上摆着，旁边是杯凉透的咖啡和半包烟。有时候遇到坑，翻两页就能找到解法；有时候翻半天没找到，就骂一句“这作者也没遇到过这破事”，然后自己研究。但不管怎么说，它至少帮我淘汰了那些“靠经验猜”的土方法——比如以前我调内存，都是凭感觉加，现在会先用sys.dm_os_performance_counters算缓冲池命中率，再决定加不加。这种“用数据说话”的思路，才是真正的“优胜劣汰”吧。

文章配图，仅供参考

（编辑：站长网）

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