Oracle Job调度从入门到精通：DBMS_JOB与DBMS_SCHEDULER实战指南-尧图网络科技

1. 从一次深夜告警说起：为什么我们需要关注Oracle Job

凌晨两点，手机突然震动，一条数据库告警信息弹了出来：“核心报表数据未按时生成，业务方已投诉”。睡眼惺忪地连上服务器，检查了一圈，发现本该在凌晨1点自动运行的聚合计算脚本，这次竟然悄无声息地“罢工”了。问题根源很快定位：负责调度这个脚本的那个DBMS_JOB，不知道什么原因，状态变成了BROKEN。这已经不是第一次了，手工创建的作业，缺乏有效的监控和管理，就像一颗定时炸弹，不知道什么时候会给你来个“惊喜”。

这次经历让我下定决心，必须把Oracle数据库中的定时任务——也就是JOB——这套机制彻底搞明白、用规范。无论是传统的DBMS_JOB，还是功能更强大的DBMS_SCHEDULER，它们都是DBA和开发人员手中自动化运维的利器。从简单的数据清理、统计信息收集，到复杂的ETL流程、业务报表生成，JOB的身影无处不在。但利器用不好，反而容易伤到自己。很多团队对JOB的使用停留在“能跑起来就行”的层面，忽略了其状态监控、异常处理、依赖管理和资源控制，最终导致像我一样在深夜被告警叫醒。

所以，这篇内容不是简单的语法罗列，而是结合我多年踩坑、填坑的经验，带你深入理解Oracle Job的创建、管理、监控以及排错的全过程。我们会从最基础的DBMS_JOB入手，再深入到更现代的DBMS_SCHEDULER，并重点探讨如何在生产环境中安全、可靠地使用它们。无论你是刚开始接触数据库运维的新手，还是希望优化现有任务调度体系的老手，相信这些实战细节都能给你带来直接的帮助。

2. 基石篇：深入理解传统的DBMS_JOB

虽然Oracle早已推出了更先进的DBMS_SCHEDULER，但大量遗留系统仍在广泛使用DBMS_JOB，理解它是读懂历史、排查旧问题的关键。更重要的是，它的核心概念——作业、提交、运行——是理解所有任务调度的基础。

2.1 DBMS_JOB的核心机制与关键参数

DBMS_JOB的本质是一个存储在数据库中的任务队列。当你提交一个作业(SUBMIT)时，并不是立即执行，而是由后台的CJQ0进程（协调作业队列进程）和JNNN进程（作业队列从属进程）来协同调度。SNP进程在较老版本中负责此功能，这是一个重要的版本差异点。

创建一个最基本的DBMS_JOB，核心是调用DBMS_JOB.SUBMIT过程。这个过程有四个关键参数，每一个都值得细细琢磨：

DECLARE v_jobno NUMBER; -- 用于接收系统生成的作业编号 BEGIN DBMS_JOB.SUBMIT( job => v_jobno, -- OUT参数，作业唯一编号 what => 'pkg_report.generate_daily;', -- 要执行的任务 next_date => SYSDATE, -- 下一次运行时间 interval => 'SYSDATE + 1' -- 执行间隔 ); COMMIT; -- 必须提交，作业才会真正进入队列！ DBMS_OUTPUT.PUT_LINE('成功创建作业，编号：' || v_jobno); END;

参数深度解析：

what参数：任务本体这是作业的核心，定义了“做什么”。它必须是一个合法的PL/SQL调用语句。
- 存储过程调用：‘my_proc;’或‘my_proc(参数);’。这是最推荐的方式，逻辑封装性好，易于管理。
- 匿名块：‘BEGIN ... END;’。适合简单逻辑，但不便于复用和修改。
- 一个关键细节：语句末尾的分号是必须的。缺少分号是新手最常见的错误之一，会导致作业提交成功但运行时报错。
interval参数：调度的心脏这是DBMS_JOB最灵活也最容易出错的地方。它是一个返回DATE类型的字符串表达式。
- 绝对时间：‘TRUNC(SYSDATE) + 1 + 2/24’表示每天凌晨2点。
- 相对间隔：‘SYSDATE + 1/24/60’表示1分钟后运行（常用于测试）。
- 复杂周期：‘NEXT_DAY(TRUNC(SYSDATE), ‘‘MONDAY’’) + 9/24’表示每周一上午9点。
- 重要陷阱：interval是在每次作业成功运行完成后才计算的。这意味着，如果你的作业在next_date时间点因为某种原因（如实例关闭）没有运行，那么它会在实例恢复后，以后台进程检查到它的时刻作为“上一次运行时间”来计算下一次的next_date。这可能导致作业的调度时间发生“漂移”。而DBMS_SCHEDULER的repeat_interval则没有这个问题，它基于固定的时间表。
next_date参数：启动的扳机它指定了作业首次（或下一次）尝试运行的时间。设置为SYSDATE意味着作业提交后，一旦后台进程轮询到（通常有几秒到几分钟的延迟），就会立即执行。
job参数：身份的标识这是一个OUT参数，系统会自动分配一个唯一的作业编号。务必记录下这个编号，它是后续所有管理操作（查看、修改、删除）的钥匙。

注意：DBMS_JOB.SUBMIT是一个需要显式提交(COMMIT)的DDL操作。如果你在PL/SQL块中提交了作业但没有COMMIT，那么这个作业只存在于你当前的事务中，其他会话和后台进程都看不到它，自然也不会执行。这是另一个常见坑点。

2.2 作业状态管理与监控实战

作业提交后，我们不能放任不管。它的生老病死、健康状态都存储在USER_JOBS、DBA_JOBS、DBA_JOBS_RUNNING等数据字典视图中。

1. 查看作业基本信息：

SELECT job, log_user, what, last_date, last_sec, this_date, this_sec, next_date, next_sec, broken, failures, interval FROM user_jobs ORDER BY job;

broken: 值为Y或N。这是最关键的字段之一。Y表示作业已损坏，调度器将不再尝试运行它。作业运行连续失败16次后，会自动标记为BROKEN。
failures: 连续失败的次数。成功运行一次后会清零。
last_date/last_sec: 上一次成功运行的开始日期和时间。
this_date/this_sec:当前正在运行的作业的开始日期和时间。如果为NULL，表示作业当前未运行。
next_date/next_sec: 计划下一次运行的日期和时间。

2. 管理作业状态：

运行一次作业：DBMS_JOB.RUN(job_number);。这会强制作业立即运行一次，且不影响其原有的next_date调度计划。常用于测试或手动补数据。
修改作业属性：使用DBMS_JOB.CHANGE。你可以单独修改what、next_date或interval，而不影响其他属性。
```
-- 只修改执行间隔为每天凌晨3点 DBMS_JOB.CHANGE(job => 1234, interval => 'TRUNC(SYSDATE+1) + 3/24'); COMMIT;
```
启动作业：DBMS_JOB.BROKEN(job_number, broken => FALSE);将broken状态从Y改为N，作业恢复调度。
停止作业：DBMS_JOB.BROKEN(job_number, broken => TRUE);将作业标记为损坏，停止调度。同时，next_date会被设置为4000-01-01这样一个遥远的日期。
删除作业：DBMS_JOB.REMOVE(job_number); COMMIT;

3. 一个真实的排错案例：作业静默失败曾经遇到一个作业，next_date一直停留在过去某个时间点，broken=‘N‘，但就是不运行。检查DBA_JOBS_RUNNING也没有它的记录。排查过程如下：

检查后台进程：ps -ef | grep ora_j查看JNNN进程是否存在且正常。
检查作业队列进程参数：SHOW PARAMETER job_queue_processes。这个参数定义了最多可以同时运行多少个作业。如果它为0，所有作业都不会被调度！这是Oracle安装后有时被忽略的一个参数。
```
ALTER SYSTEM SET job_queue_processes = 20; -- 根据系统负载调整
```
检查作业定义：what字段中的过程名或包名是否存在拼写错误？是否有同义词指向了错误的对象？
检查依赖对象状态：如果作业调用的存储过程依赖的某个表或视图失效，作业运行时可能会因编译错误而立即失败，但错误信息不易捕捉。可以尝试手动RUN一次作业，同时在另一个会话用SELECT * FROM DBA_JOBS_RUNNING和SELECT sid, serial#, sql_id FROM v$session WHERE program LIKE ‘%J0%‘找到对应的会话，然后去v$session和v$sql中查找错误信息。

这个案例的核心教训是：作业不运行，首先检查job_queue_processes，其次手动RUN并捕获实时错误。

3. 进化篇：掌握强大的DBMS_SCHEDULER

如果说DBMS_JOB是一把可靠但功能单一的螺丝刀，那么DBMS_SCHEDULER就是一个完整的、现代化的机械工具箱。它提供了作业(JOB)、调度(SCHEDULE)、程序(PROGRAM)、链(CHAIN)、窗口(WINDOW)、资源管理器(RESOURCE MANAGER)集成等一整套特性，更适合管理复杂的企业级任务调度。

3.1 核心概念与创建你的第一个调度作业

DBMS_SCHEDULER采用了更清晰的对象模型：

PROGRAM：定义“做什么”。可以是一个存储过程、一个PL/SQL块，甚至是一个操作系统可执行程序。
SCHEDULE：定义“何时做”。一个独立的时间计划对象，可以被多个作业复用。
JOB：将PROGRAM和SCHEDULE关联起来，并定义执行环境（如凭证、目标等）。它是最常用的入口。

让我们创建一个最简单的、功能等同于之前DBMS_JOB例子的调度作业：

BEGIN DBMS_SCHEDULER.CREATE_JOB ( job_name => ‘MY_DAILY_REPORT_JOB‘, job_type => ‘STORED_PROCEDURE‘, job_action => ‘pkg_report.generate_daily‘, start_date => SYSTIMESTAMP, repeat_interval => ‘FREQ=DAILY; BYHOUR=2; BYMINUTE=0‘, -- 每天2点 enabled => TRUE, comments => ‘生成每日业务报表‘ ); END;

执行这条语句后，作业立即生效，无需COMMIT。你会发现，repeat_interval参数使用了更直观的日历表达式，这比DBMS_JOB的日期运算字符串要强大和规范得多。

3.2 日历表达式详解与高级调度策略

日历表达式是DBMS_SCHEDULER的调度灵魂，它遵循FREQ、INTERVAL、BY系列关键字的结构。

基础频率：

FREQ=SECONDLY; INTERVAL=30每30秒
FREQ=MINUTELY; INTERVAL=15每15分钟
FREQ=HOURLY; INTERVAL=2每2小时
FREQ=DAILY每天
FREQ=WEEKLY每周
FREQ=MONTHLY每月
FREQ=YEARLY每年

复杂组合示例：

工作日早上9点：FREQ=DAILY; BYDAY=MON,TUE,WED,THU,FRI; BYHOUR=9; BYMINUTE=0
每月最后一天下午5点：FREQ=MONTHLY; BYMONTHDAY=-1; BYHOUR=17
每季度第一个周一：FREQ=MONTHLY; BYMONTH=1,4,7,10; BYDAY=1MON(这里BYDAY=1MON表示每月的第一个周一)
每隔3天运行：FREQ=DAILY; INTERVAL=3

高级调度特性：

开始与结束时间：start_date和end_date可以精确控制作业的生命周期。
持续时间与最大运行时间：可以设置作业每次运行的最长时间(max_run_duration)，超时后会被强制停止。
依赖调度：作业可以依赖于另一个作业的成功完成。这通过创建CHAIN（链）来实现，是构建复杂ETL工作流的基础。

3.3 作业类、资源管理与执行环境控制

这是DBMS_SCHEDULER超越DBMS_JOB的另一个维度——对任务执行资源的精细化管理。

1. 作业类：作业类(JOB_CLASS)是一组共享资源分配规则的作业的集合。创建作业时可以指定其所属的类。

BEGIN DBMS_SCHEDULER.CREATE_JOB_CLASS( job_class_name => ‘LOW_PRIORITY_BATCH‘, resource_consumer_group => ‘LOW_GROUP‘, -- 关联到资源消费者组 logging_level => DBMS_SCHEDULER.LOGGING_FULL, comments => ‘用于低优先级批处理作业‘ ); END;

然后创建作业时指定：job_class => ‘LOW_PRIORITY_BATCH‘。这样，所有属于此类的作业都会在指定的资源消费者组下运行，避免影响高优先级的在线业务。

2. 凭证：对于需要访问操作系统资源（如执行Shell脚本、读写文件）的作业，需要定义凭证(CREDENTIAL)。

BEGIN DBMS_SCHEDULER.CREATE_CREDENTIAL( credential_name => ‘OS_USER_CRED‘, username => ‘oracle‘, password => ‘your_password‘ ); END;

创建外部作业时使用：credential_name => ‘OS_USER_CRED‘。这比传统上用job_queue_processes跑外部脚本更安全、更可控。

3. 目标：在RAC环境中，你可以指定作业在哪个实例上运行，或者允许它在任何可用实例上运行(‘any‘)，这提供了高可用性。

通过作业类、凭证、目标的组合，你可以构建一个隔离的、资源受控的、高可用的自动化任务执行环境。

4. 运维实战：监控、排错与性能优化

创建作业只是开始，让作业集群健康、稳定、高效地运行才是真正的挑战。

4.1 全方位的监控体系

1. 数据字典视图：你的监控仪表盘

*_SCHEDULER_JOBS：所有作业的定义和当前状态（ENABLED,DISABLED,RUNNING,FAILED等）。
*_SCHEDULER_JOB_LOG：作业每次运行的详细日志。这是排查故障的第一现场。
*_SCHEDULER_JOB_RUN_DETAILS：比LOG更详细的运行信息，包括运行时长、CPU使用等。
*_SCHEDULER_RUNNING_JOBS：当前正在运行的作业信息。

一个实用的监控查询，用于查看最近失败的任务及其错误信息：

SELECT log_id, job_name, status, error#, error_message, req_start_date, actual_start_date, run_duration FROM dba_scheduler_job_run_details WHERE status = ‘FAILED‘ AND actual_start_date > SYSDATE - 1 -- 查看最近一天内的失败 ORDER BY actual_start_date DESC;

2. 自定义告警与事件DBMS_SCHEDULER支持基于事件的通知。你可以设置当作业失败、超过最大运行时长等事件发生时，自动发送邮件或调用一个处理程序。

BEGIN DBMS_SCHEDULER.ADD_EVENT_QUEUE_SUBSCRIBER( subscriber_name => ‘MY_ALERT_QUEUE_SUB‘ ); -- 然后可以配置规则，将特定作业的失败事件放入队列，再由高级队列(AQ)触发后续动作 END;

对于大多数场景，定期查询JOB_LOG和RUN_DETAILS视图并集成到现有的监控平台（如Zabbix, Prometheus）是更通用的做法。

4.2 常见问题排查手册

问题1：作业状态为“SCHEDULED”但迟迟不运行。

检查调度器开关：SELECT * FROM DBA_SCHEDULER_GLOBAL_ATTRIBUTE WHERE ATTRIBUTE_NAME = ‘SCHEDULER_DISABLED‘;如果值为TRUE，整个调度器都被禁用了。
检查作业是否被禁用：SELECT enabled FROM USER_SCHEDULER_JOBS WHERE job_name = ‘...‘;
检查资源限制：作业所属的作业类(JOB_CLASS)关联的资源消费者组(RESOURCE_CONSUMER_GROUP)可能没有足够的资源份额，或者资源计划(RESOURCE_PLAN)未激活。
检查依赖：如果作业是链(CHAIN)的一部分，检查其前置步骤是否成功。

问题2：作业运行失败，错误信息为“ORA-27486: insufficient privileges”。

这是权限问题。执行作业的用户（通常是作业的owner）需要CREATE JOB权限。对于外部作业，还需要CREATE EXTERNAL JOB权限以及对应凭证(CREDENTIAL)的执行权限。

解决方案：

GRANT CREATE JOB TO your_user; -- 对于外部作业 GRANT CREATE EXTERNAL JOB TO your_user; EXEC DBMS_SCHEDULER.GRANT_EXECUTE_ON_CREDENTIAL(‘OS_USER_CRED‘, ‘your_user‘);

问题3：作业运行时间过长，甚至挂起。

查看当前运行详情：

SELECT sj.job_name, sjr.session_id, s.sid, s.serial#, s.sql_id, s.event, s.seconds_in_wait FROM dba_scheduler_running_jobs sjr JOIN dba_scheduler_jobs sj ON sjr.job_name = sj.job_name LEFT JOIN v$session s ON sjr.session_id = s.sid WHERE sjr.job_name = ‘YOUR_JOB_NAME‘;

通过sql_id可以进一步查看正在执行的SQL，通过event可以查看会话在等待什么资源（如锁、IO等）。这可能是由于作业内部的SQL效率低下，或者与其它会话存在资源争用。

问题4：DBMS_JOB作业在RAC环境中只在某个实例运行。

这是DBMS_JOB的固有缺陷，作业与创建它的实例绑定。解决方案是迁移到DBMS_SCHEDULER，或者使用DBMS_JOB的instance参数（不推荐，管理复杂）。

4.3 性能优化与最佳实践

避免高频短作业：如果业务需要每秒执行一次检查，考虑使用DBMS_PIPE、Advanced Queueing或应用层的定时器，而不是创建每秒运行一次的数据库作业。频繁的作业启停会消耗可观的CPU和内存资源。
合理设置job_queue_processes：对于DBMS_JOB，此参数不宜设置过大，通常10-20足够。过大会增加进程管理开销。对于DBMS_SCHEDULER，其并发由资源管理器控制，更精细。
使用作业类进行资源隔离：务必为批处理作业创建独立的作业类，并将其绑定到专用的资源消费者组（如BATCH_GROUP）。在资源管理计划中，给这个组分配固定的CPU份额和并行度限制，确保批处理不会挤占联机事务处理（OLTP）的资源。
详尽的日志记录：创建作业时，设置logging_level => DBMS_SCHEDULER.LOGGING_FULL。虽然会占用更多空间，但在排查复杂问题时，完整的日志是无价之宝。定期清理历史日志即可。
为作业设置超时：使用max_run_duration参数。例如，INTERVAL ‘PT2H‘表示最长运行2小时。防止失控的作业永远运行下去。
设计幂等性作业：作业逻辑应设计成可重复执行而不会产生副作用或重复数据。这样，当作业失败重跑时，就不会引入新的问题。例如，使用MERGE语句代替INSERT，或者在处理前先删除目标时间段的数据。

5. 从DBMS_JOB迁移到DBMS_SCHEDULER

对于历史系统，将关键的DBMS_JOB迁移到DBMS_SCHEDULER是提升可维护性和可靠性的重要步骤。迁移不是简单的语法转换，而是涉及调度语义、异常处理和资源管理的重构。

迁移步骤与注意事项：

清单梳理：首先从DBA_JOBS中导出所有作业的详细信息（what, interval, broken状态等）。
语义分析：重点分析interval字符串。DBMS_JOB的interval计算基于“上一次成功完成的时间”，而DBMS_SCHEDULER的repeat_interval基于固定的时间表。如果原作业对执行时间的“漂移”有依赖，需要重新设计调度策略。大多数情况下，你需要的是基于日历的固定调度。
创建等价的SCHEDULER JOB：使用DBMS_SCHEDULER.CREATE_JOB创建新作业。对于存储过程调用，直接转换。对于复杂的匿名块，考虑将其封装成存储过程。
并行运行与验证：不要立即删除旧作业。让新旧作业并行运行一段时间（可以先将旧作业的interval改为一个很大的值，使其暂时不调度，但保留定义）。对比新旧作业的输出结果和执行时间，确保功能一致。
切换与清理：验证无误后，将旧作业标记为BROKEN或直接REMOVE，并确保新作业的enabled状态为TRUE。
更新依赖：检查是否有其他脚本、程序或监控系统通过作业编号(job number)引用旧作业，需要更新这些引用。

一个迁移工具示例思路：你可以编写一个PL/SQL脚本，读取DBA_JOBS，并尝试自动生成对应的CREATE_JOB语句。但对于复杂的interval逻辑和作业依赖，人工审核和调整是必不可少的。

迁移的核心价值在于，你将获得更稳定的调度（无时间漂移）、更强大的监控（详尽的日志）、更精细的控制（资源管理）以及更好的可维护性（对象化的调度和程序）。虽然需要一些前期投入，但从长期的运维成本来看，这笔投资是值得的。

6. 复杂场景应用：作业链与依赖管理

当单个作业无法满足需求，需要将多个任务按特定顺序和逻辑组织起来时，DBMS_SCHEDULER的链功能就派上了用场。链允许你定义一组有依赖关系的程序步骤，并控制它们的执行流程（成功、失败、超时后的动作）。

6.1 创建与运行一个简单的作业链

假设我们有一个简单的数据加载流程：1) 清空临时表， 2) 从源系统加载数据到临时表， 3) 验证数据， 4) 将有效数据合并到目标表。

第一步：创建链对象

BEGIN DBMS_SCHEDULER.CREATE_CHAIN ( chain_name => ‘ETL_DAILY_LOAD_CHAIN‘, rule_set_name => NULL, evaluation_interval => NULL, comments => ‘每日ETL数据加载流程‘ ); END;

第二步：定义链中的步骤每个步骤指向一个PROGRAM（或内联的PL/SQL代码块）。

BEGIN -- 步骤1：清空临时表 DBMS_SCHEDULER.DEFINE_CHAIN_STEP ( chain_name => ‘ETL_DAILY_LOAD_CHAIN‘, step_name => ‘CLEAN_STAGE‘, program_name => ‘CLEAN_STAGING_TABLE_PROC‘ -- 这是一个预先创建好的PROGRAM ); -- 步骤2：加载数据 DBMS_SCHEDULER.DEFINE_CHAIN_STEP ( chain_name => ‘ETL_DAILY_LOAD_CHAIN‘, step_name => ‘LOAD_DATA‘, program_name => ‘LOAD_DATA_TO_STAGE_PROC‘ ); -- 步骤3：验证数据 DBMS_SCHEDULER.DEFINE_CHAIN_STEP ( chain_name => ‘ETL_DAILY_LOAD_CHAIN‘, step_name => ‘VALIDATE_DATA‘, program_name => ‘VALIDATE_STAGE_DATA_PROC‘ ); -- 步骤4：合并到目标表 DBMS_SCHEDULER.DEFINE_CHAIN_STEP ( chain_name => ‘ETL_DAILY_LOAD_CHAIN‘, step_name => ‘MERGE_TO_TARGET‘, program_name => ‘MERGE_DATA_PROC‘ ); END;

第三步：定义步骤间的依赖规则规则决定了步骤的执行顺序和条件。

BEGIN -- 链开始时，首先运行 CLEAN_STAGE DBMS_SCHEDULER.DEFINE_CHAIN_RULE ( chain_name => ‘ETL_DAILY_LOAD_CHAIN‘, condition => ‘TRUE‘, action => ‘START CLEAN_STAGE‘, rule_name => ‘ETL_RULE_START‘ ); -- CLEAN_STAGE 成功后，运行 LOAD_DATA DBMS_SCHEDULER.DEFINE_CHAIN_RULE ( chain_name => ‘ETL_DAILY_LOAD_CHAIN‘, condition => ‘CLEAN_STAGE COMPLETED‘, action => ‘START LOAD_DATA‘, rule_name => ‘ETL_RULE_1‘ ); -- LOAD_DATA 成功后，运行 VALIDATE_DATA DBMS_SCHEDULER.DEFINE_CHAIN_RULE ( chain_name => ‘ETL_DAILY_LOAD_CHAIN‘, condition => ‘LOAD_DATA COMPLETED‘, action => ‘START VALIDATE_DATA‘, rule_name => ‘ETL_RULE_2‘ ); -- VALIDATE_DATA 成功后，运行 MERGE_TO_TARGET DBMS_SCHEDULER.DEFINE_CHAIN_RULE ( chain_name => ‘ETL_DAILY_LOAD_CHAIN‘, condition => ‘VALIDATE_DATA COMPLETED‘, action => ‘START MERGE_TO_TARGET‘, rule_name => ‘ETL_RULE_3‘ ); -- MERGE_TO_TARGET 完成后，整个链结束 DBMS_SCHEDULER.DEFINE_CHAIN_RULE ( chain_name => ‘ETL_DAILY_LOAD_CHAIN‘, condition => ‘MERGE_TO_TARGET COMPLETED‘, action => ‘END‘, rule_name => ‘ETL_RULE_END‘ ); END;

第四步：启用链并创建按计划运行的链作业

BEGIN DBMS_SCHEDULER.ENABLE(‘ETL_DAILY_LOAD_CHAIN‘); DBMS_SCHEDULER.CREATE_JOB ( job_name => ‘RUN_ETL_CHAIN_JOB‘, job_type => ‘CHAIN‘, job_action => ‘ETL_DAILY_LOAD_CHAIN‘, repeat_interval => ‘FREQ=DAILY; BYHOUR=1‘, enabled => TRUE ); END;

6.2 链的复杂逻辑与错误处理

链的强大之处在于其基于规则的条件判断。

处理失败：你可以定义当某个步骤失败时，是跳转到另一个清理步骤，还是直接结束整个链并标记为失败。

-- 如果 VALIDATE_DATA 步骤失败，则运行一个清理和告警步骤 DBMS_SCHEDULER.DEFINE_CHAIN_RULE ( chain_name => ‘ETL_DAILY_LOAD_CHAIN‘, condition => ‘VALIDATE_DATA FAILED‘, action => ‘START CLEANUP_AND_ALERT_STEP‘, rule_name => ‘ETL_RULE_ON_VALIDATE_FAIL‘ );

超时处理：可以在定义步骤时指定step_timeout，并在规则中处理step_name TIMED_OUT事件。
并行执行：规则条件可以支持AND和OR。例如，‘STEP_A COMPLETED AND STEP_B COMPLETED‘，这样STEP_C就可以在A和B都完成后才开始，实现了并行分支的同步。
查看链运行状态：使用*_SCHEDULER_CHAINS、*_SCHEDULER_CHAIN_STEPS、*_SCHEDULER_CHAIN_RULES等视图来监控链的定义和运行状态。