這是最常見的Scheduler問題之一。 這裏我們列出一些常見問題及其解決方案。
1）JOB_QUEUE_PROCESSES可能太低（這是最常見的問題） JOB_QUEUE_PROCESSES的值限制了在給定時間運行DBMS_SCHEDULER 和DBMS_JOB作業的總數。 要檢查是否是這種情況，請檢查當前值 job_queue_processes和 SQL>從v $ parameter中選擇值，其中name ='job_queue_processes'; 然後檢查運行作業的數量 SQL> select count（）from dba_scheduler_running_jobs; SQL> select count（）from dba_jobs_running;
如果這是可以增加使用 SQL參數>改變系統組JOB_QUEUE_PROCESSES = 1000的問題;如果該參數不爲空
2）max_job_slave_processes可能太低 那麼它限制多少DBMS_SCHEDULER工作可以 同時運行。要檢查這是否是問題，請使用 SQL> select value from dba_scheduler_global_attribute where attribute_name ='MAX_JOB_SLAVE_PROCESSES';檢查當前的 值。 然後檢查正在運行的作業的數量 SQL> select count（*）from dba_scheduler_running_jobs;
如果是這樣，你可以增加數或空出來使用 SQL> EXEC dbms_scheduler.set_scheduler_attribute問題（「max_job_slave_processes」，NULL）
3）會議可能太低 此參數限制隨時的會話數量。每個計劃任務 需要2個會話。要檢查這是否是問題，請使用 檢查當前的 值SQL>從v $ parameter中選擇值，其中name ='sessions'; 然後使用 SQL> select v（v）從v $ session中檢查當前的會話數;
如果數字太接近，可以使用 來增加最大值SQL> alter system set job_queue_processes = 200;
4）您最近是否應用了時區更新補丁程序或將數據庫 升級到具有較新時區信息的版本？如果在 更新時區信息時跳過了任何步驟，作業可能無法運行。要檢查這個 是否是這種情況，請嘗試執行 SQL> select * from sys.scheduler $ _job; 和 SQL> select * from sys.scheduler $ _window; 並確保它們完成沒有錯誤。
如果它引發時區警告，請重新應用升級或時區修補程序，確保遵循所有步驟。
5）數據庫是否在限制模式下運行？ 如果數據庫以限制模式運行，則不會運行任何作業（除非 您使用11g並使用ALLOW_RUNS_IN_RESTRICTED_MODE屬性）。 要檢查此用途 SQL>從v $實例中選擇登錄名;
如果登錄限制您可以禁用使用 SQL的受限模式> ALTER SYSTEM DISABLE RESTRICTED SESSION;
6）作業是否計劃在某個實例停止運行？
您可以通過查看是否爲作業設置instance_id（檢查dba_scheduler_jobs視圖）來檢查該情況，如果是，則應檢查該實例是否已啓動。
7）作業是否計劃在沒有在任何實例上啓動的服務上運行？
您可以通過檢查作業指向的job_class然後檢查該類是否指向服務來檢查此問題。如果是這樣，請確保服務已在至少一個正在運行的實例上啓動。您可以使用dbms_service.start_service在實例上啓動服務。
8）資源管理器是否實施了限制性資源計劃？
如果限制性資源計劃生效，調度程序作業可能沒有足夠的資源分配，因此它們可能無法運行。您可以通過執行查看哪些資源計劃生效
SQL>從V $ RSRC_PLAN中選擇名稱;
如果沒有計劃生效或計劃生效是INTERNAL_PLAN，那麼資源管理器不生效。如果資源管理器生效，則可以通過執行以禁用它
SQL> alter system set resource_manager_plan ='';
9）調度程序是否被禁用？這不是受支持的操作 ，但有人可能已經完成了它。要檢查這從dba_scheduler_global_attribute做 SQL>選擇值，其中屬性名稱=「SCHEDULER_DISABLED」
如果該查詢返回true，則可以解決這個使用 SQL> EXEC DBMS_SCHEDULER。set_scheduler_attribute（ 'scheduler_disabled'， '假'）;
原因作業可能運行後期
1）檢查的第一件事是，作業計劃與 SQL>選擇所有者，JOB_NAME，從dba_scheduler_jobs next_run_date的時區;
如果作業是在錯誤的時區，他們可能無法在預期時間 運行。如果next_run_date正在使用絕對時區偏移量（如 +08：00）而不是命名時區（如US/PACIFIC），那麼作業可能不是 ，如果夏令時生效則按預期運行 - 它們可能會運行一小時 早或晚。
2）這可能是因爲在作業計劃運行，的幾個 上述限制可能已暫時達到了造成延遲的一個工作的時間。 檢查上面的限制是否足夠高，並且如果可能的話，在 期間檢查作業被延遲的時間。
3）一個可能的原因在於上述極限可以擊中之一是一個 維護窗口可能已經生效。維護窗口是Oracle 屬於名爲 MAINTENANCE_WINDOW_GROUP的窗口組的計劃程序窗口。在計劃的維護時段內，幾個 維護任務使用作業運行。這可能會導致上面列出的限制 中的一個被限制，並且用戶作業被延遲。有關詳細信息，請參閱管理指南 （第24章）。
要獲取維護窗口列表，請使用 SQL> select * from dba_scheduler_wingroup_members;
時看到的窗口中運行，使用 SQL> SELECT * FROM dba_scheduler_windows;
爲了解決這個問題，你可以增加限制或重新安排維修 窗口以更方便的時間運行。
診斷等問題
如果沒有這個工程，在這裏您可以採取嘗試 弄清楚是怎麼回事了一些進一步的措施。
1）檢查是否有警報日誌中的任何錯誤。如果數據庫爲 分配內存出現問題或磁盤空間不足或發生了其他任何災難性錯誤，則應首先解決這些錯誤。您可以通過使用 SQL>從v $ parameter中選擇值來查找警報日誌的位置，其中name ='background_dump_dest';您可以使用 查找警報日誌的位置。 警報日誌將位於此目錄中，名稱以「alert」開頭。
2）檢查時是否工作協調跟蹤文件，如果是的話，檢查它是否 包含任何錯誤。如果存在，它將位於 'background_dump_dest'目錄中，您可以在上面找到它，並且將顯示 ，如SID-cjq0_nnnn.trc。如果在這裏有任何錯誤，他們可能會提示工作未運行的原因。3）如果以上任一指示SYSAUX表空間（調度程序存儲其日誌表的位置）已滿，則可以使用dbms_scheduler.purge_log過程清除舊的日誌條目。
4）查看是否有當前打開的窗口。如果有的話，你可以嘗試關閉它，看看是否有幫助。
SQL> select * from DBA_SCHEDULER_GLOBAL_ATTRIBUTE where
attribute_name='CURRENT_OPEN_WINDOW';
SQL> exec DBMS_SCHEDULER.close_window ('WEEKNIGHT_WINDOW');
5）試運行一個簡單的一次性執行的作業，看它是否運行
SQL>begin
dbms_scheduler.create_job (
job_name => 'test_job',
job_type => 'plsql_block',
job_action => 'null;',
enabled => true);
end;
/
SQL> -- wait a while
SQL> select * from user_scheduler_job_run_details where job_name='TEST_JOB';
6）如果一個簡單的運行一次作業沒有運行，你可以嘗試重新啓動調度程序如下。
SQL> exec dbms_scheduler.set_scheduler_attribute('SCHEDULER_DISABLED', 'TRUE');
SQL> alter system set job_queue_processes=0;
SQL> exec dbms_ijob.set_enabled(FALSE);
SQL>
SQL> alter system flush shared_pool;
SQL> alter system flush shared_pool;
SQL>
SQL> exec dbms_ijob.set_enabled(TRUE);
SQL> alter system set job_queue_processes=99;
SQL> exec dbms_scheduler.set_scheduler_attribute('SCHEDULER_DISABLED', 'FALSE');
