SQL Server运维避坑指南：18年实战经验精编

　　去年九月，凌晨三点十七分，我盯着备份恢复窗口里那行“错误 3154：备份集中的数据库与现有数据库不匹配”，手指悬在回车键上没敢按——不是怕操作，是怕听见旁边工位老张又叹气。他刚端起保温杯吹了三下热气，杯沿上还沾着半粒枸杞，说：“你再试一次，我给你计时。”

　　我原以为改个兼容级别就能绕过这报错，结果第八次restore database命令跑完，日志里还是那句“无法覆盖已存在文件”，可磁盘里明明没有那个mdf——查过两次，连隐藏属性都扒出来了，它就是不在那儿。

　　后来发现，是昨天下午运维组小王手动删过一次tempdb的ldf，没重启服务，SQL Server自己悄悄重建了tempdb，但系统表sys.master_files里那条旧记录没刷掉（对，就那条file_id=2、name='tempdev'的记录），而这次恢复脚本里刚好用了with move 'tempdev' to 'D:\\data\\old_tempdev.mdf'……它根本没去碰你写的路径，它只认sys.master_files里那条残血记录里的物理名——反正这玩意儿从SQL Server 2005时代起就没换过逻辑校验方式。

　　我问小王删log前知不知道这个链路，他眨眨眼，指着屏幕上还没关的远程桌面连接框：“哎，我连的是测试实例啊，手滑点错了目标服务器。”——他点开的那个RDP标题栏写着“SQL-PROD-02（已断开）”，底下一行小字：“上次断开时间：二十一小时前”。

　　我调出那台机器的Windows事件日志，翻到八月三十一号十九点零七分，Application日志里有一条Warning，Event ID 17147：“SQL Server could not recycle tempdb due to file access conflict”，但没写具体哪个文件、哪个进程锁着它。我截图发给DBA组长，他回复得很快：“这提示天天有，ignore就行。”（他真这么写的，原话。）

　　所以问题不在备份脚本，不在恢复参数，不在路径权限，也不在SQL版本——它卡在一条被遗忘的tempdb重建残影里，在系统表里活成了幽灵，在日志里装成哑巴，在监控告警里干脆隐身。你清空缓存没用，重启Agent没用，连杀掉所有用户会话都没用，因为它压根不走会话层，它蹲在启动那一刻的初始化链条最底端，只等你某次restore顺手带一句with move……

　　后来我们临时停掉SQL Agent，手动执行sp_detach_db把那个名字为tempdev但早已不存在的文件从系统表里踢出去——过程很糙，是直接update sys.sysfiles加dbcc checkdb跳过验证硬干的。做完立刻恢复成功。老张把保温杯搁回桌上，枸杞沉到底了，说：“下次再这样，先查sys.master_files，别查disk。”

　　但我现在想起来还是后怕：如果那次恢复是凌晨三点十七分自动触发的，没人在场盯窗口；如果脚本里with move后面跟的是变量拼接；如果小王删的是另一个名字相近的数据库log（比如testdb_log）；如果老张那晚没来加班……这些“如果”全没发生，可它们离现实就差那么半秒——就像你总以为陷阱在配置里，在命令里，在文档最后一行小字里，其实它蹲在你上一次误操作留下的半句没删干净的system table记录里，不响，不跳，就静静躺着。

文章配图，仅供参考

　　哦对，那天咖啡机坏了，修理工说主板芯片氧化，换了块新的，但第二天又黑屏——和SQL Server一个毛病，表面看是软件问题，其实是个硬件接触不良的虚焊点在周期性失效。（这事儿和备份恢复没关系，删了不影响你懂这事。）

　　还有，老张保温杯底下垫着张A4纸，边角卷起来了，上面记着三行字：“查master_files”、“别信warning日志”、“tempdb不是你的”。第三行墨水洇开了，“的”字右边糊成一片蓝灰色。（这也和事儿无关，删掉完全不影响。）

　　我也不知道那块主板芯片是不是真的氧化了——修理工拆机时我路过，看见他左手拿镊子，右手正往板子上滴焊锡膏，膏体泛着油光，像某种活物在呼吸。

　　有谁碰到过这个吗？

（编辑：航空爱好网）

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