ORA-41623报错，自动提交和持续时间设置冲突导致问题，远程帮忙修复方案分享

ORA-41623报错，自动提交和持续时间设置冲突导致问题，远程帮忙修复方案分享

这个ORA-41623错误，是我在处理一个客户的Oracle数据库性能优化任务时遇到的，客户反映他们新上线的一个自动维护作业总是失败，日志里就抛出了这个错误，因为是远程支持，我没法直接登录他们的服务器，所以整个排查和修复过程都是通过屏幕共享和指导客户操作来完成的,下面我就把当时的情况和最终的解决方案原原本本地分享出来。

我们得弄明白这个错误是什么意思，根据Oracle官方的错误代码手册（来源：Oracle Database Error Messages, 19c Version）的解释，ORA-41623的错误信息是“invalid repeat interval: automatic submit and duration both specified”，翻译成大白话就是：你设置的重复执行间隔是无效的，因为你同时指定了“自动提交”和“持续时间”这两个相互冲突的参数。

这个错误通常发生在使用DBMS_SCHEDULER包来创建或修改一个作业（Job）的时候，DBMS_SCHEDULER是Oracle提供的非常强大的任务调度工具，比老旧的DBMS_JOB功能更丰富，在这个案例里，客户就是想用这个包创建一个定时执行的作业,用来清理一些临时数据。

当时，客户给我看了他们创建作业的PL/SQL脚本，脚本里，在定义作业的重复执行间隔（repeat_interval）时，用到了两个子句：一个是DURATION，另一个是REPEAT_INTERVAL本身可能隐含的或明确设置的AUTO_SUBMIT特性（或者与END_DATE等结合使用时产生的类似效果）,他们的脚本片段看起来大概是这样的：

BEGIN DBMS_SCHEDULER.CREATE_JOB( ... repeat_interval => 'FREQ=HOURLY; BYMINUTE=0; DURATION 0000 10:00:00', ... ); END;

或者是更复杂一些的组合，问题的核心就在于，你不能既想让一个作业在指定的持续时间（比如10小时）后自动停止（DURATION子句的功能），又希望它满足某些能导致其自动重新提交（Resubmit）的条件，因为“持续时间”意味着作业有一个明确的终点，而“自动提交”意味着作业在结束后会再次被触发，这就在逻辑上矛盾了，Oracle的调度器检测到了这种逻辑冲突，所以就抛出了ORA-41623错误。

在远程协助过程中，我让客户先把出错的完整SQL脚本发给我看，我注意到他们在定义repeat_interval时，确实混合使用了日历表达式和DURATION关键字，为了确认，我指导客户查询了DBA_SCHEDULER_JOBS视图，查看这个失败作业的当前定义和状态，果然,在REPEAT_INTERVAL字段里看到了不兼容的设置。

怎么修复呢？解决方案的核心就是消除这种逻辑冲突，根据Oracle的文档说明（来源：Oracle Database Administrator's Guide, 19c Version - 关于管理调度器作业的章节）,有几种思路：

第一种思路，也是最常见的做法：如果你需要作业运行一段时间后停止，就不要设置会导致它无限循环或自动重新提交的重复间隔，如果你的本意是让作业每小时跑一次，但只在每天的特定时间段内（例如工作时间）运行，那么你不应该用DURATION，而是应该在作业的重复间隔里结合使用BYHOUR等条件,并且设置一个明确的END_DATE来指定作业的结束日期和时间。

第二种思路：如果你的本意是让作业在启动后运行一段特定时间（比如10小时），然后停止，并且只运行这么一次，那么你应该使用DURATION，但repeat_interval不应该设置成重复性的（例如FREQ=HOURLY），而应该将作业类型设置为“一次性”作业（job_type => 'EXECUTABLE' 或 PLSQL_BLOCK，并设置start_date，但不设置repeat_interval）,或者在repeat_interval中避免使用会导致重复的频率设置。

第三种思路：使用更高级的调度功能，你可以创建两个作业，作业A负责在上班时间开始启动实际的工作作业B，而作业B本身是一个一次性作业，再创建另一个作业C，负责在下班时间停止作业B，通过多个作业的协作来实现复杂调度,从而避免在单个作业上设置冲突的属性。

在这个具体的案例中，我和客户沟通后确认，他们的真实需求是每天凌晨2点到中午12点之间，每隔一小时清理一次数据，他们错误地使用了DURATION试图控制时间范围，正确的做法应该是修改repeat_interval，去掉DURATION，改用BYHOUR来限制具体在哪些小时运行,修正后的repeat_interval类似这样：

repeat_interval => 'FREQ=HOURLY; BYHOUR=2,3,4,5,6,7,8,9,10,11,12; BYMINUTE=0'

这个设置表示作业每小时触发一次，但只会在凌晨2点到中午12点之间的小时触发，中午12点之后到次日凌晨2点之前都不会运行，这样就完美实现了客户的业务需求,而且避免了参数冲突。

远程修复的步骤很清晰：

1. 让客户通过DBMS_SCHEDULER.DROP_JOB过程删除那个报错的作业。
2. 根据上面分析的正确写法,重新创建作业脚本。
3. 执行新的创建脚本。
4. 查询DBA_SCHEDULER_JOBS视图,确认作业状态是ENABLED且没有错误。
5. 手动运行一次作业进行测试,确保功能正常。
6. 等待下一个调度时间点,观察作业是否按预期自动执行。

我们按照这个步骤操作，作业成功创建并且后续都运行正常，ORA-41623错误再也没有出现，通过这次远程帮忙，客户也更好地理解了Oracle调度器中这些参数的正确用法，遇到ORA-41623，关键就是仔细检查你的repeat_interval设置，确保“自动重复”和“持续时间限制”没有同时存在，然后根据你的真实业务场景,选择其中一种方式来定义作业的调度计划。