阿里云RDS任务编排踩坑纪实

1.奇怪的问题

前段时间，将一个本地版sqlServer2008的数据库，迁移到了阿里云RDS for SqlServer2008上。原本在任务计划中执行的一个任务，迁移到了云数据库的任务编排中。任务的主要目的是对当日无效的业务数据，状态更新为已过期。客户反映，最近一段时间，一直有应该过期没有过期的数据，影响了新业务的录入。

2.解决问题思路

根据客户反映的问题，我列举如下两个原因：

1、任务编排中的代码没有执行；

2、任务按时执行了，因为业务复杂，其他业务将历史数据修改了状态。

为此，我做了如下工作排错，

• 我首先检查了任务编排中的代码，将代码在sql中执行，发现没有问题；
• 我让同事检查了和状态相关可能的所有业务，还是没有问题；
• 根据对数据的查看，每天大部分需要处理的数据都是处理了的，只有少部分数据没有处理，说明肯定有处理状态的代码；
• 我在思考是不是任务编排每次都只能执行固定条数的代码，为此，专门做了测试，结果排除了这种猜测；
• 检查所有的代码，工作量太大了，我设计了一个思路，修改任务编排中的代码，在执行前后，将需要处理状态的数据，写到一个表里，做好了任务，等待晚上的执行结果。结果第二天早上，发现自己的代码没有按计划执行，确实又有处理状态的代码执行了。

遇到这种陷入瓶颈的问题，我告诫自己，答案在现场，于是，我打算晚上12:00，看看到底代码执行了没有。

3.半夜追踪

晚上12:00起来，看了一下执行计划，已经执行过了，能查到执行记录；又查了一下数据，确实有部分数据没有处理完。

我又重新梳理了一下功能，当看到“发布”、“下线”字样时，我突然想到，是不是需要重新发布？任务计划确实是执行了，执行的是内存中的，脚本中看到的，并没有执行。

按照这个思路，我重新发布，重新执行了一下计划，果然，数据按照设计的逻辑执行了。

4.踩坑落幕

至此，在Rds任务编排中踩到的坑，才算踩平。这就是没有认真读操作说明的弊端，也证明了自己常说的那句话，答案就在现场，遇到问题，在现场找答案。