Oracle DBMS-Job wird nicht ausgeführt

Dies ist eine der am häufigsten gestellten Scheduler-Fragen. Hier listen wir einige der häufigsten Probleme und ihre Lösungen auf.

1) job_queue_processes ist möglicherweise zu niedrig (dies ist das häufigste Problem). Der Wert von job_queue_processes begrenzt die Gesamtzahl der dbms_scheduler- und dbms_job-Jobs, die zu einem bestimmten Zeitpunkt ausgeführt werden können. Um zu überprüfen, ob dies der Fall ist, überprüfen Sie den aktuellen Wert von job_queue_processes mit SQL> select value from v$parameter where name='job_queue_processes';Check the number of running jobsSQL> select count() from dba_scheduler_running_jobs;SQL> select count( ) von dba_jobs_running;

Wenn dies das Problem ist, können Sie den Parameter mit SQL> alter system set job_queue_processes=1000;

2) max_job_slave_processes ist möglicherweise zu niedrig. Wenn dieser Parameter nicht NULL ist, begrenzt er, wie viele dbms_scheduler-Jobs gleichzeitig ausgeführt werden können. Um zu prüfen, ob dies das Problem ist, prüfen Sie den aktuellen Wert mit SQL> select value from dba_scheduler_global_attributewhere attribute_name='MAX_JOB_SLAVE_PROCESSES';dann prüfen Sie die Anzahl der laufenden JobsSQL> select count(*) from dba_scheduler_running_jobs;

Wenn dies das Problem ist, können Sie die Zahl erhöhen oder einfach mit SQL> exec dbms_scheduler.set_scheduler_attribute('max_job_slave_processes',null)

3) Sitzungen können zu niedrig sein. Dieser Parameter begrenzt die Anzahl der Sitzungen zu jeder Zeit. Jeder Scheduler-Job erfordert 2 Sitzungen. Um zu überprüfen, ob dies das Problem ist, überprüfen Sie den aktuellen Wert mit SQL> select value from v$parameter where name='sessions'; Überprüfen Sie dann die aktuelle Anzahl der Sitzungen mit SQL> select count(*) from v$session;

Wenn die Zahlen zu nahe beieinander liegen, können Sie das Maximum mit SQL> alter system set job_queue_processes=200;

4) Haben Sie kürzlich einen Zeitzonen-Update-Patch angewendet oder die Datenbank auf eine Version mit neueren Zeitzoneninformationen aktualisiert? Wenn Sie beim Aktualisieren der Zeitzoneninformationen Schritte übersprungen haben, werden Jobs möglicherweise nicht ausgeführt. Um zu überprüfen, ob dies der Fall ist, versuchen Sie SQL> select * from sys.scheduler$_job;undSQL> select * from sys.scheduler$_window;und vergewissern Sie sich, dass sie ohne Fehler beendet werden.

Wenn eine Zeitzonenwarnung ausgegeben wird, wenden Sie das Upgrade oder den Zeitzonen-Patch erneut an und achten Sie darauf, alle Schritte zu befolgen.

5) Läuft die Datenbank im eingeschränkten Modus? Wenn die Datenbank im eingeschränkten Modus läuft, werden keine Jobs ausgeführt (es sei denn, Sie verwenden 11g und verwenden das Attribut ALLOW_RUNS_IN_RESTRICTED_MODE).>

Wenn die Anmeldung eingeschränkt ist, können Sie den eingeschränkten Modus mit SQL> ALTER SYSTEM DISABLE RESTRICTED SESSION;

6) Soll der Job auf einer heruntergefahrenen Instanz ausgeführt werden?

Sie können dies überprüfen, indem Sie nachsehen, ob instance_id für den Job gesetzt ist (überprüfen Sie die Ansicht dba_scheduler_jobs), und wenn ja, sollten Sie überprüfen, ob diese Instanz aktiv ist.

7) Soll der Job auf einem Dienst ausgeführt werden, der auf keiner Instanz gestartet wurde?

Sie können dies überprüfen, indem Sie prüfen, auf welche job_class ein Job zeigt, und dann prüfen, ob diese Klasse auf einen Dienst zeigt. Stellen Sie in diesem Fall sicher, dass der Dienst auf mindestens einer laufenden Instanz gestartet wurde. Sie können einen Dienst auf einer Instanz mit dbms_service.start_service.

8) Ist der Ressourcenmanager mit einem restriktiven Ressourcenplan in Kraft?

Wenn ein restriktiver Ressourcenplan in Kraft ist, sind Scheduler-Jobs möglicherweise nicht genügend Ressourcen zugewiesen, sodass sie möglicherweise nicht ausgeführt werden. Sie können überprüfen, welcher Ressourcenplan gültig ist, indem Sie

SQL> Name aus V$RSRC_PLAN auswählen;

Wenn kein Plan wirksam ist oder der wirksame Plan INTERNAL_PLAN ist, dann ist der Ressourcenmanager nicht wirksam. Wenn der Ressourcenmanager aktiv ist, können Sie ihn deaktivieren, indem Sie Folgendes tun

SQL>alter system set resource_manager_plan ='';

9) Wurde der Planer deaktiviert? Dies ist keine unterstützte Aktion, aber es ist möglich, dass jemand es trotzdem getan hat. Um dies zu überprüfen, doSQL> wählen Sie den Wert von dba_scheduler_global_attribute aus, wobei attribute_name='SCHEDULER_DISABLED'

Wenn diese Abfrage TRUE zurückgibt, können Sie dies mit SQL> exec dbms_scheduler.set_scheduler_attribute('scheduler_disabled','false');

Gründe, warum Aufträge verspätet sein können

1) Das erste, was zu überprüfen ist, ist die Zeitzone, in der der Job geplant ist, mitSQL> select owner, job_name, next_run_date from dba_scheduler_jobs;

Wenn sich die Jobs in der falschen Zeitzone befinden, werden sie möglicherweise nicht zur erwarteten Zeit ausgeführt. Wenn das next_run_date einen absoluten Zeitzonenoffset (wie +08:00) anstelle einer benannten Zeitzone (wie US/PACIFIC) verwendet, werden die Jobs möglicherweise nicht wie erwartet ausgeführt, wenn Sommerzeit gilt – sie können eine Stunde früher oder später ausgeführt werden.

2) Es kann sein, dass zu dem Zeitpunkt, zu dem der Job ausgeführt werden sollte, vorübergehend einer der oben genannten Grenzwerte erreicht wurde, was zu einer Verzögerung des Jobs führte Job verzögert sich.

3) Ein möglicher Grund dafür, dass einer der oben genannten Grenzwerte erreicht werden kann, ist, dass möglicherweise ein Wartungsfenster in Kraft getreten ist. Wartungsfenster sind OracleScheduler-Fenster, die zur Fenstergruppe mit dem Namen MAINTENANCE_WINDOW_GROUP gehören. Während eines geplanten Wartungsfensters werden mehrere Wartungsaufgaben mithilfe von Jobs ausgeführt. Dies kann dazu führen, dass einer der oben aufgeführten Grenzwerte erreicht wird und Benutzeraufträge verzögert werden. Weitere Informationen dazu finden Sie im Administratorhandbuch (Kapitel 24).

Um eine Liste der Wartungsfenster zu erhalten, verwenden Sie SQL> select * from dba_scheduler_wingroup_members;

Um zu sehen, wann die Windows ausgeführt werden, verwenden Sie SQL> select * from dba_scheduler_windows;

Um dies zu beheben, können Sie entweder die Limits erhöhen oder die Wartungsfenster so verschieben, dass sie zu günstigeren Zeiten ausgeführt werden.

Andere Probleme diagnostizieren

Wenn nichts davon funktioniert, sind hier einige weitere Schritte, die Sie unternehmen können, um herauszufinden, was los ist.

1) Überprüfen Sie, ob das Alarmprotokoll Fehler enthält. Wenn die Datenbank Probleme beim Zuweisen von Speicher hat oder keinen Speicherplatz mehr hat oder andere katastrophale Fehler aufgetreten sind, sollten Sie diese zuerst beheben. Sie können den Speicherort des Warnungsprotokolls finden, indem Sie SQL> select value from v$parameter where name ='background_dump_dest'; Das Warnungsprotokoll befindet sich in diesem Verzeichnis mit einem Namen, der mit "alert" beginnt.

2) Überprüfen Sie, ob eine Job-Koordinator-Trace-Datei vorhanden ist, und wenn ja, überprüfen Sie, ob sie Fehler enthält. Wenn dies existiert, befindet es sich im Verzeichnis „background_dump_dest“, das Sie wie oben finden können, und sieht in etwa so aus wie SID-cjq0_nnnn.trc . Wenn hier Fehler auftreten, können diese darauf hinweisen, warum Jobs nicht ausgeführt werden.

3) Wenn einer der oben genannten Punkte darauf hinweist, dass der SYSAUX-Tablespace (wo der Scheduler seine Protokolltabellen speichert) voll ist, können Sie die Prozedur dbms_scheduler.purge_log verwenden, um alte Protokolleinträge zu löschen.

4) Prüfen Sie, ob derzeit ein Fenster geöffnet ist. Wenn ja, können Sie versuchen, es zu schließen, um zu sehen, ob das hilft .

SQL> select * from DBA_SCHEDULER_GLOBAL_ATTRIBUTE where 
attribute_name='CURRENT_OPEN_WINDOW';
SQL> exec DBMS_SCHEDULER.close_window ('WEEKNIGHT_WINDOW');

5) Versuchen Sie, einen einfachen einmal ausgeführten Job auszuführen, und prüfen Sie, ob er ausgeführt wird

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) Wenn ein einfacher einmaliger Job nicht ausgeführt wird, können Sie versuchen, den Planer wie folgt neu zu starten.

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');