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

文章配图，仅供参考

　　我原以为是tempdb争用，把三个大表索引重建任务挪到了凌晨一点，结果它照旧卡在四点十七分。运维同事老周叼着半截没点的烟进来，说：“你查查xp_cmdshell是不是被禁了？”我说没动过配置，他敲了两行sp_configure就出去了——后来我翻记录才发现，他压根没执行reconfigure，那两行就是敲着玩的。

　　第八次重试备份作业时，我手动右键“执行”，SQL Server Management Studio弹出那个熟悉得让人反胃的框：“操作已启动”，底下进度条不动，鼠标指针转三圈，然后自动消失。再点，“操作已启动”；再点，“操作已启动”。我没截图，因为前七次都一样。反正我信了界面，直到早上六点客服打来电话，说“你们站点数据库连不上，首页报502”，我才意识到——Agent根本没在跑任何东西，它只是假装在线。

　　（上周五物业来换楼道灯，声控开关坏了，踩三脚亮，第四脚灭，第五脚又亮，第七脚彻底不响——跟这破Agent一个毛病。）

　　翻msdb.dbo.sysjobactivity看last_executed_step_date，全是一串1900-01-01 00:00:00.000；再查sysjobschedules.next_run_date，倒全是今天，但next_run_date全被塞进了同一秒：四点十七分零三秒。我也不知道是谁改的——没人承认，也没审计日志留痕，连谁最后登录过msdb都查不到，因为默认trace早关了。老周说是“有人手抖点错了频率设置”，可频率设置哪来的“同一秒触发八次”的选项？我查了sp_add_jobschedule参数说明，没这个功能，SQL Server自己都不支持。

　　最要命的是：它卡住时，backup job本身在msdb里status字段显示“1”（已启用），而is_executing字段却是NULL，不是0也不是1。我问过微软Support，那边人说“这是已知行为”，说完就挂了，我再拨过去提示“当前坐席繁忙”。我也不知道什么叫“已知行为”——已知却不管？还是已知所以不用修？

　　（隔壁PHP论坛的站长昨天发帖说他升级到8.3后GD库读不了webp，我顺手搜了下CVE编号，发现补丁包里压根没包含GD模块更新，就一个readme写着“暂不支持”——这事跟我这事儿一样离谱，但不相关，删掉不影响。）

　　我试过重启SQL Server Agent服务，它起来后头三分钟一切正常，第四分钟开始，又默默把所有job的next_run_date写成四点十七分。我抓包看到它往msdb发了一堆UPDATE语句，目标字段是next_run_date和date_created，时间戳全带毫秒级精度，但日期部分全是1900年——不对，是0x00000000硬编码进去的，DBCC PAGE翻data页确认过。老周最后甩给我一句话：“别动schedule，直接写Windows定时任务调sqlcmd”。可我原以为Agent是核心组件，结果它连时间戳都存不稳。

　　现在每次部署完新实例，我第一件事就是停掉SQL Server Agent，改用Task Scheduler跑备份，虽然多一层壳，至少它报错会吐出来，不会在界面上微笑等你点第八次。但昨天凌晨四点十七分，我看见Windows事件日志里有一条ID 102，来源SQLServerAgent，描述栏写着：“作业调度器初始化成功”。它真的成功了吗？

　　有谁碰到过这个吗

（编辑：航空爱好网）

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