Oracle调度任务发送幽灵通知问题求助

• 检查作业链的独立通知配置
  部分调度任务是作为作业链（Chain）的步骤存在的，链步骤可能单独配置了通知，这类配置不会出现在dba_scheduler_notifications中。执行以下查询排查：

  SELECT chain_name, step_name, recipient, subject, message
  FROM dba_scheduler_chain_notifications;
  

• 清理Scheduler通知队列的遗留消息
  Oracle Scheduler的通知依赖AQ队列发送，可能旧的通知消息仍滞留在队列中未处理。先定位Scheduler相关队列：

  SELECT queue_name, queue_table
  FROM dba_queues
  WHERE owner = 'SYS' AND queue_table LIKE '%SCHEDULER%';
  

  通常默认队列表是sys.scheduler$_notification_qtab，查看队列中的消息：

  SELECT * FROM sys.scheduler$_notification_qtab;
  

  若存在旧生产库格式的消息，可通过DBMS_AQ.DEQUEUE或清空队列的方式删除。

• 排查遗留的DBMS_JOB任务
  若系统仍在使用旧版DBMS_JOB而非DBMS_SCHEDULER，这类任务的通知配置不会出现在Scheduler视图中。执行查询：

  SELECT job, what, last_date, next_date
  FROM dba_jobs;
  

  检查what字段是否包含发送邮件的逻辑（如调用UTL_MAIL的存储过程）。

• 检查操作系统级定时任务
  确认是否存在操作系统层面的定时任务（如Linux的crontab、Windows任务计划），通过脚本连接测试库发送邮件。这类任务不属于数据库调度器，需直接查看操作系统配置。

• 验证Scheduler规则集与订阅者
  Scheduler通知可能通过规则集（Rules）和订阅者（Subscriptions）关联，而非直接绑定到任务。执行以下查询：

  SELECT * FROM dba_scheduler_rules;
  SELECT * FROM dba_scheduler_subscriptions;
  

  检查是否有指向生产库邮件别名的订阅规则。

• 排查直接调用UTL_MAIL/UTL_SMTP的存储过程
  部分任务中断通知可能是通过存储过程直接调用邮件包发送，而非Scheduler内置通知。查询数据库中的相关代码：

  SELECT owner, name, line, text
  FROM dba_source
  WHERE (text LIKE '%UTL_MAIL.SEND%' OR text LIKE '%UTL_SMTP%')
    AND (text LIKE '%FAILURE%' OR text LIKE '%ABORT%');
  

  找到相关存储过程后，检查其逻辑是否存在旧的生产库邮件配置。

• 检查Scheduler任务运行历史的重试通知
  已失败的任务实例可能被配置为重试发送通知，即使任务已重建。查询近期失败的任务记录：

  SELECT job_name, log_date, status, additional_info
  FROM dba_scheduler_job_run_details
  WHERE status = 'FAILED'
    AND log_date > SYSDATE - 30;
  

  查看additional_info字段是否包含旧通知的发送记录，必要时清理历史任务实例。

• 确认数据库链接是否关联生产库
  检查测试库是否存在指向生产库的DB Link，若任务通过DB Link调用生产库的存储过程，可能触发生产库的通知：

  SELECT * FROM dba_db_links;
  

  若存在可疑链接，验证任务是否依赖该链接执行。

内容的提问来源于stack exchange，提问作者Gary G