如何调用PL/SQL系统包_DBMS_JOB与DBMS_SCHEDULER定时任务

首页

数据库

热心网友

转载

2026-04-27

DBMS_JOB 还在用？先看 Oracle 版本和停用风险

如果您正在维护较老版本的 Oracle 数据库或历史遗留系统，那么对 DBMS_JOB 这个内置包一定非常熟悉。然而，一个至关重要的信息是：自 Oracle 10g 版本起，DBMS_JOB 已被 Oracle 官方正式标记为“弃用（Deprecated）”。 这代表着什么？意味着尽管该功能目前仍可运行，但已不再是 Oracle 技术发展的推荐方向，未来版本中可能会被移除。

在 Oracle 19c 及后续版本中，您或许仍能调用它，但官方明确不建议在新项目中使用。更重要的是，它缺乏现代作业调度所需的许多关键特性，例如基于时间窗口的执行、与资源管理器（Resource Manager）的集成、更强大的依赖链管理以及完善的日志审计功能。因此，如果您的数据库已升级至 12c 或更高版本，且没有强制维护旧脚本的要求，那么最佳实践是：直接绕过 DBMS_JOB，开始学习和采用更强大的 DBMS_SCHEDULER。

需要注意的是，这两个调度器之间存在“相互隔离”的特性，常常导致混淆。一个典型的报错是：ORA-27475: “JOB_NAME” must be a job。这通常是因为开发者误将 DBMS_JOB 创建的作业，当作 DBMS_SCHEDULER 的对象进行查询或操作。例如，在 DBA_SCHEDULER_JOBS 视图中查找不到 DBMS_JOB 创建的任务；反之，DBA_JOBS 视图也绝对看不到任何由 DBMS_SCHEDULER 创建的作业。

Oracle 10g–11g 环境：可继续使用 DBMS_JOB 维持现有系统运行，但强烈建议不要为其开发新的业务逻辑。
Oracle 12c 及以上版本：所有新建任务都应使用 DBMS_SCHEDULER。如需迁移旧任务，需特别注意权限变更——DBMS_SCHEDULER 要求明确的 CREATE JOB 系统权限，取代了原先 DBMS_JOB 所依赖的 CREATE PROCEDURE 权限。
视图完全独立：DBMS_JOB 创建的作业不会出现在任何 DBA_SCHEDULER_* 相关视图中，两者是完全独立的管理体系。

DBMS_SCHEDULER.CREATE_JOB 最简可用写法

初次接触 DBMS_SCHEDULER，很容易被其众多的参数和组件（如 Schedule、Program、Job Class）所困扰。其实，对于大多数一次性或简单的周期性任务，有一种更直接、不易出错的方法：使用内联（Inline）方式创建作业。 无需一开始就拆分组件，先用最简写法快速实现功能。

考虑一个典型需求：需要在每天凌晨2点执行一个名为 pkg_clean.upd_stats 的存储过程。使用内联方式创建作业的代码如下：

BEGIN
  DBMS_SCHEDULER.CREATE_JOB(
    job_name        => 'DAILY_STATS_UPDATE',
    job_type        => 'STORED_PROCEDURE',
    job_action      => 'pkg_clean.upd_stats',
    start_date      => TRUNC(SYSDATE) + 2/24,
    repeat_interval => 'FREQ=DAILY; BYHOUR=2; BYMINUTE=0',
    enabled         => TRUE,
    comments        => 'Daily stats refresh'
  );
END;

这段代码虽然简洁，但几个关键细节决定了作业能否成功运行：

job_type 参数选择：该参数主要有三个常用值：'PLSQL_BLOCK'（用于执行匿名 PL/SQL 块，块内容需以分号结尾）、'STORED_PROCEDURE'（只需填写存储过程名，切勿添加括号和参数）、'EXECUTABLE'（调用操作系统命令或脚本，需额外配置操作系统凭证）。选错类型将直接导致作业执行失败。
repeat_interval 语法规则：它遵循的是 IETF RFC 2445 日历表达式标准，并非 Linux 系统的 cron 表达式。例如，写 BYDAY=MON,WED,FRI 是合法的，但如果误写成 0 0 * * 1,3,5，则会立即触发 ORA-27467 语法错误。
start_date 的常见陷阱：如果该参数简单地设置为 SYSDATE，作业将在创建成功后立即触发执行一次。许多开发者遇到的“为何新建作业立刻运行了两次？”问题，根源往往在于此。

权限、所有者与运行上下文三大易错点

作业创建成功，但运行时却报权限错误？这可能是 DBMS_SCHEDULER 中最令人困惑的问题之一。其核心原则是：作业默认以创建者（所有者）的身份和权限在后台运行，而非以当前启用或修改它的用户身份执行。

常见的错误现象包括：作业日志中报告 ORA-01031: insufficient privileges，或存储过程执行时提示 ORA-00942: table or view does not exist，但手动登录该用户执行却完全正常。

创建作业的权限：创建作业的用户必须拥有 CREATE JOB 系统权限。DBA 角色包含此权限，但普通开发账号通常需要单独授权。
作业执行的权限：作业执行时，使用的是作业所有者的权限。关键点在于：通过角色（Role）授予的权限在存储过程内部是无效的。举例说明，如果用户 SCOTT 创建了作业，而作业调用的过程 pkg_clean.upd_stats 内部需要查询 HR.EMPLOYEES 表，那么 SCOTT 必须被直接授予（Direct Grant）该表的 SELECT 权限，仅通过角色拥有该权限是无法成功执行的。
对象引用的完整性：当作业调用的存储过程不在当前用户 Schema 下时，job_action 参数必须使用全限定名。例如，应写为 'hr.pkg_clean.upd_stats'，仅写 'pkg_clean.upd_stats' 会导致 ORA-27477 错误。

查看状态、修改时间、停止任务的实用命令

作业部署上线后，日常运维离不开监控与调整。无需翻阅大量文档，掌握以下几个最实用的命令和视图即可应对大部分场景：

查看作业状态：要检查作业是否启用、上次执行时间、当前状态及错误信息，可查询此视图：

SELECT job_name, enabled, last_start_date, state, failure_count, additional_info
FROM dba_scheduler_jobs
WHERE job_name = 'DAILY_STATS_UPDATE';

临时停用与恢复执行：如需暂停作业但保留定义，使用 DBMS_SCHEDULER.DISABLE('DAILY_STATS_UPDATE');。需要时再启用：DBMS_SCHEDULER.ENABLE('DAILY_STATS_UPDATE');。
修改下次运行时间（谨慎操作）：DBMS_SCHEDULER.SET_ATTRIBUTE('DAILY_STATS_UPDATE', 'start_date', SYSTIMESTAMP + INTERVAL '1' HOUR);。请注意，此操作仅影响后续的调度计划，对于已生成在队列中的运行实例，不会产生改变。

真正棘手的问题，往往是 repeat_interval 参数书写错误，导致作业“静默”失效。例如，本意想每小时执行一次，写成了 'FREQ=HOURLY' 却遗漏了关键的 INTERVAL=1。这种情况下，Oracle 可能会静默地忽略整个重复规则，作业状态显示为 ENABLED，但它永远不会再被触发。遇到作业不按预期运行的情况，第一步应是查询 dba_scheduler_job_log 视图，检查近期是否有 FAILED 或 STOPPED 的记录，那里通常隐藏着问题的根源。

来源:https://www.php.cn/faq/2314229.html

免责声明：游乐网为非赢利性网站，所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系youleyoucom@outlook.com。

上一篇：怎么导出隐藏表或系统表_查看与备份完整系统数据下一篇：Redis String数据结构内存结构_分析SDS简单动态字符串优化点