Oracle定时任务重复执行主因是未显式控制上一次任务是否完成，调度器仅依据NEXT_DATE触发，不判断前序实例状态；需通过自建锁表、设置stop_on_window_close、完善日志及事务处理来规避。
重复执行不是调度逻辑出错，而是任务状态没管住——绝大多数情况，问题不在dbms_job或dbms_scheduler本身，而在你没显式控制“上一次是否真跑完了”。
为什么JOB会重复执行？关键在NEXT_DATE和事务边界
Oracle定时任务不会自动判断“上一个实例是否还在跑”，它只认NEXT_DATE。如果存储过程执行时间超过设定间隔（比如每5分钟跑一次，但某次处理耗时8分钟），而你又没在过程里做防重逻辑，下一轮调度就会在上一轮还没结束时被触发，两个会话同时操作同一张表或同一组数据，结果就是重复、冲突甚至死锁。
-
NEXT_DATE是“下一次该什么时候启动”，不是“上一次结束后再等X分钟” - 手动调用
dbms_job.run(job_id)或dbms_scheduler.enable不会重置运行中状态，只会强行再启一个实例 - 如果存储过程里没
COMMIT或ROLLBACK，事务挂起，dbms_job可能因超时失败后重试，导致看似“重复”
dbms_job场景：用job_queue_processes + 自锁表控制并发
老系统还在用dbms_job时，不能依赖调度器自带的互斥机制。最稳妥的做法是自己加一层轻量级锁。
- 建一张
job_lock表：CREATE TABLE job_lock (job_name VARCHAR2(100) PRIMARY KEY, locked_at DATE) - 在存储过程开头加“抢锁”逻辑：
INSERT INTO job_lock VALUES ('my_daily_proc', SYSDATE)，捕获ORA-00001（唯一键冲突）即说明已有实例在跑，直接RETURN - 结尾务必
DELETE FROM job_lock WHERE job_name = 'my_daily_proc'，并COMMIT - 别忘了检查
job_queue_processes参数是否足够：SHOW PARAMETER job_queue_processes，值为0就完全不跑
dbms_scheduler场景：用ENABLED + STOP_ON_WINDOW_CLOSE避免堆积
dbms_scheduler比dbms_job多了真正意义上的作业状态管理，但默认配置仍可能堆积。
- 创建作业时显式设
stop_on_window_close => TRUE，防止窗口关闭时作业被强制中断后重试 - 禁用自动重启：
auto_drop => FALSE+max_runs => 1（如需单次）或用schedule_name配合repeat_interval而非硬编码间隔 - 查运行中实例：
SELECT job_name, state, running_instance FROM dba_scheduler_jobs WHERE state = 'RUNNING'，别只看dba_scheduler_job_log - 避免用
PLSQL_BLOCK直接写大段逻辑——封装成存储过程，便于加锁、日志和异常隔离
最容易被忽略的点：日志没落地，你根本不知道它“重复”了还是“卡死了”
所有定时任务必须有可追溯的日志入口。没有INSERT INTO job_log或DBMS_SCHEDULER.CREATE_JOB_LOG_ENTRY的记录，你看到的“重复执行”大概率是“前一次失败静默退出+下一次照常触发”的假象。
- 日志表至少含：
job_name、start_time、end_time、status（'STARTED'/'SUCCEEDED'/'FAILED'）、error_msg - 日志写入必须在
EXCEPTION块里补全，且不要用DBMS_OUTPUT——它不会被JOB捕获 - 对长时间运行的任务，加心跳更新：
UPDATE job_log SET last_heartbeat = SYSDATE WHERE job_name = ...，方便监控存活
