1.奇怪的问题
前段时间,将一个本地版sqlServer2008的数据库,迁移到了阿里云RDS for SqlServer2008上。原本在任务计划中执行的一个任务,迁移到了云数据库的任务编排中。任务的主要目的是对当日无效的业务数据,状态更新为已过期。客户反映,最近一段时间,一直有应该过期没有过期的数据,影响了新业务的录入。
2.解决问题思路
根据客户反映的问题,我列举如下两个原因:
1、任务编排中的代码没有执行;
2、任务按时执行了,因为业务复杂,其他业务将历史数据修改了状态。
为此,我做了如下工作排错,
- 我首先检查了任务编排中的代码,将代码在sql中执行,发现没有问题;
- 我让同事检查了和状态相关可能的所有业务,还是没有问题;
- 根据对数据的查看,每天大部分需要处理的数据都是处理了的,只有少部分数据没有处理,说明肯定有处理状态的代码;
- 我在思考是不是任务编排每次都只能执行固定条数的代码,为此,专门做了测试,结果排除了这种猜测;
- 检查所有的代码,工作量太大了,我设计了一个思路,修改任务编排中的代码,在执行前后,将需要处理状态的数据,写到一个表里,做好了任务,等待晚上的执行结果。结果第二天早上,发现自己的代码没有按计划执行,确实又有处理状态的代码执行了。
遇到这种陷入瓶颈的问题,我告诫自己,答案在现场,于是,我打算晚上12:00,看看到底代码执行了没有。
3.半夜追踪
晚上12:00起来,看了一下执行计划,已经执行过了,能查到执行记录;又查了一下数据,确实有部分数据没有处理完。
我又重新梳理了一下功能,当看到“发布”、“下线”字样时,我突然想到,是不是需要重新发布?任务计划确实是执行了,执行的是内存中的,脚本中看到的,并没有执行。
按照这个思路,我重新发布,重新执行了一下计划,果然,数据按照设计的逻辑执行了。
4.踩坑落幕
至此,在Rds任务编排中踩到的坑,才算踩平。这就是没有认真读操作说明的弊端,也证明了自己常说的那句话,答案就在现场,遇到问题,在现场找答案。