根本原因是19c中DBMS_JOB降级为DBMS_SCHEDULER兼容层，需显式授予CREATE JOB权限；同时JOB_QUEUE_PROCESSES必须>0、_SYSTEM_TRIG_ENABLED须为TRUE，且expdp/impdp迁移易致LOG_USER错置为SYS引发权限失败。
升级到 Oracle 19c 后 DBMS_JOB 看似能提交、查询，但作业不再自动执行——根本原因不是功能被删，而是权限、调度机制和底层行为发生了隐性变化，且错误不报在作业本身，而藏在授权链或系统级开关里。
DBMS_JOB 提交成功但不触发：缺 CREATE JOB 权限
19c 中 DBMS_JOB 已完全降级为 DBMS_SCHEDULER 的兼容层，所有 job 实际由 Scheduler 托管。这意味着：即使用户有 EXECUTE 权限，也必须显式授予 CREATE JOB 才能创建可调度的作业。
- 现象：
DBMS_JOB.SUBMIT成功返回 job 号，dba_jobs中可见，但NEXT_DATE不更新、BROKEN为N却始终不运行 - 检查：
SELECT * FROM dba_role_privs WHERE grantee = 'YOUR_USER' AND granted_role = 'SCHEDULER_ADMIN_ROLE';（通常没有） - 修复：以
SYS身份执行GRANT CREATE JOB TO your_user;；若在 CDB 环境且作业需跨 PDB 生效，加CONTAINER=ALL
LOG_USER 变成 SYS：expdp 导入 job 时权限上下文丢失
用 expdp/impdp 迁移含 job 的 schema 时，job 元数据会被还原，但执行上下文（LOG_USER）默认绑定到导入操作所用用户（通常是 SYS），而非原始 owner。
- 现象：
SELECT job, log_user, schema_user FROM dba_jobs;显示LOG_USER = 'SYS'，导致 job 运行时报ORA-01031: insufficient privileges（因SYS下无法访问应用 schema 对象） - 本质：job 定义中的
WHAT字符串仍指向原 schema，但执行时按LOG_USER解析权限，SYS没有该 schema 下表的 SELECT 权限 - 修复：重提 job，确保用目标 schema 用户连接后执行
DBMS_JOB.SUBMIT；或改用DBMS_SCHEDULER.CREATE_JOB显式指定job_style => 'REGULAR'和auto_drop => FALSE，避免上下文污染
作业卡在“已提交但未调度”：JOB_QUEUE_PROCESSES 或 _SYSTEM_TRIG_ENABLED 异常
19c 默认启用 Scheduler，但传统 job 仍依赖旧机制开关。若这些参数被误调或遗留配置干扰，job 会静默失效。
-
JOB_QUEUE_PROCESSES必须 > 0（虽 19c 推荐用 Scheduler，但DBMS_JOB仍走此路径）；查：SHOW PARAMETER job_queue_processes - _SYSTEM_TRIG_ENABLED 隐含参数控制 job 触发器是否激活；查：
SELECT ksppinm, ksppstvl FROM x$ksppi a, x$ksppcv b WHERE a.indx = b.indx AND ksppinm = '_system_trig_enabled';，若为FALSE，需ALTER SYSTEM SET "_system_trig_enabled"=TRUE SCOPE=BOTH; - 注意：服务器 uptime > 497 天也会触发 job 停摆（Bug 3427424），此时仅重启数据库实例无效，必须重启 OS
为什么 DBMS_JOB.SUBMIT 不报错却无效：19c 中它只是 Scheduler 的代理层
DBMS_JOB.SUBMIT 在 19c 内部会调用 DBMS_SCHEDULER.CREATE_JOB 并设置兼容模式，但不校验目标 schema 是否有 CREATE JOB 或对象访问权限——错误被延迟到首次调度时刻才暴露，且只记入 alert.log，不抛给客户端。
- 验证方法：手动运行
EXEC DBMS_JOB.RUN(job_number);，若报ORA-27486: insufficient privileges，说明是权限问题；若报ORA-00942: table or view does not exist，说明LOG_USER上下文错位 - 迁移建议：不要强行保留
DBMS_JOB；改用DBMS_SCHEDULER.CREATE_JOB，显式指定schema、credential_name和auto_drop，避免隐式上下文切换 - 关键细节：19c 中
DBMS_JOB.NEXT_DATE更新依赖DBMS_SCHEDULER的内部队列刷新，若 Scheduler 自身异常（如sys.scheduler$_event_queue积压），DBMS_JOB表现就是“不动”
