Oracle 10g (Teil IV):

Jobsteuerung mit dbms_scheduler

Regelmäßig wiederkehrende Aufgaben und damit eine sinnvolle Automatisierung von Jobs ist nahezu in allen Anwendungsbereichen bekannt. Zur Automatisierung von Jobs in der Datenbank verwendete man in früheren Versionen das Paket dbms_job. Die Funktionalitäten und Erweiterungen dieses Pakets wurden in der Version 10g in dem Paket dbms_scheduler zusammengefasst.

Überblick

Der Scheduler, der zur Steuerung von Arbeitsaufträgen (Jobs) dient, ist ein Bestandteil von Oracle 10g. Er ist bereits in der Standard Edition enthalten.

Es gibt zwei verschiedene Möglichkeiten, den Scheduler zu bedienen (siehe Abbildung 1): Zum einen steht die API mit dem Paket DBMS_SCHEDULER als Datenbankobjekt zur Verfügung. Zum anderen gibt es die Möglichkeit, den Scheduler im Enterprise Manager über ein GUI zu bedienen.

Das Paket DBMS_SCHEDULER kann benutzt werden, um Jobs innerhalb von Applikationen zu definieren.

Komponenten

Der Scheduler benutzt die folgenden vier Haupt-Komponenten:

Abb. 1: Bedienungsmöglichkeiten des Schedulers.

• Programm ist eine Sammlung von Metadaten über die Tätigkeit, die durch den Scheduler unterstützt wird. Unterstützte Programmtypen können PL/SQL Blöcke, PL/SQL Stored Procedures, Java Stored Procedures oder auch Executables auf Betriebssystemebene sein.
• Job spezifiziert, welches Programm wann und mit welchen Argumenten ausgeführt wird.
• Schedule spezifiziert, wann und wie oft ein Job ausgeführt wird (Job-Programm-Beziehung).
• Window (Ausführungszeitfenster) repräsentiert ein Zeitintervall mit einem Anfangszeitpunkt und einem Endzeitpunkt.

Die einzelnen Komponenten werden im Laufe dieses Artikels noch detaillierter erklärt.

Programm

Programme sind Sammlungen von Kommandos, die als Datenbankobjekte gespeichert werden und mit anderen Benutzern über Objekt-Privilegien geteilt werden können. Um ein Programm anzupassen, können die Benutzer beim Anlegen eines Jobs für die Programm-Argumente Werte definieren. Diese Werte überschreiben dann die Default-Werte, die beim Anlegen des Programms definiert wurden.

Abb. 2: Aufbau eines Jobs.

Job

• Programm spezifiziert die Aufgabe, die mit dem Job ausgeführt werden soll.
• Schedule spezifiziert, wann der Job laufen soll.
• Job Attributes: Startdatum, Wiederholungszyklus, Enddatum.
• Arguments: Argumente, mit denen das Programm des Jobs ausgeführt werden soll.

Programm und Schedule können in der Jobdefinition spezifiziert oder, wie in Abbildung 3 dargestellt, als separate Datenbankobjekte angelegt und im Job über ihren Namen definiert werden.

EXECUTE
	Dbms_scheduler.CREATE_PROGRAM
	(program_name 	=>’BEREINIGE_LOGBUCH’,
	program_action 	=>’prc_bereinige_logbuch’,
	program_type 	=>’STORED_PROCEDURE’,
	enabled 		=>true);

EXECUTE
	Dbms_scheduler.CREATE_JOB
	(job_name 	=>’JOB_LOGBUCH_1’,
	program_name 	=>’BEREINIGE_LOGBUCH’,
	start_date 	=>’26.06.2004 12:00’,
	repeat_interval	=>’freq=monthly;interval=3’);

Die Attribute können beim Anlegen der Jobs definiert und durch die Prozedur SET_ATTRIBUTE des Pakets DBMS_SCHEDULER geändert werden (siehe Abbildung 4).

BEGIN
	DBMS_SCHEDULER.SET_ATTRIBUTE(
		Name 		=> ’refresh_schema’,
		attribute 	=> ’start_date’,
		value 		=> ’12/12/2004 12:00:00’
	);
	DBMS_SCHEDULER.SET_ATTRIBUTE(
		Name 		=> ’refresh_schema’,
		attribute 	=> ’repeat_interval’,
		value 		=> ’FREQ=MONTHLY;INTERVAL=5’
	);
	DBMS_SCHEDULER.SET_ATTRIBUTE(
		Name 		=> ’refresh_schema’,
		attribute 	=> ’end_date’,
		value 		=> ’12/05/2005 12:00:00’
	);
END;

Damit das neue Schedule in der Datenbank verwendet wird, muss man die Jobs zunächst deaktivieren und dann wieder aktivieren.

Sind einem Programm Argumente zugeordnet worden, so können diese über die Prozedur SET_JOB_ARGUMENT_VALUE geändert werden.

Informationen zu den in der Datenbank angelegten Jobs findet man in der View DBA_SCHEDULER_JOBS.

Schedule

Ein Schedule legt fest, wann und wie oft ein Job ausgeführt werden soll. Dabei wird unterschieden, ob ein Job nur einmal laufen oder über einen bestimmten Zeitraum hinweg in einem bestimmten Intervall wiederholt werden soll (siehe Abbildung 5).

Abb. 5: Zeitplanung bei Schedules: Einmalige oder mehrmalige Ausführung.

Soll ein Job nur einmal ausgeführt werden, so muss nur der Zeitpunkt angegeben werden, zu dem der Job gestartet werden soll.

Soll der Job öfter ausgeführt werden, so muss ein Startzeitpunkt angegeben werden und ein Intervall innerhalb dessen der Job wiederholt werden soll. Das Intervall kann auf verschiedene Weisen spezifiziert werden. Entweder benutzt man eine dem Englischen ähnliche Syntax (z. B. last monday of the month) oder einen PL/SQL-Ausdruck (z. B. FREQ=monthly; BYMONTHDAY-1).

Optional kann auch noch ein Endzeitpunkt angegeben werden, über den hinaus keine Jobs mehr gestartet werden. Ein Beispiel zeigt Abbildung 6.

EXECUTE
	Dbms_Scheduler.CREATE_SCHEDULE
	(schedule_name 	=> ‘DB_CLEANER’,
	start_date 	=> ‘systimestamp’,
	end_date 		=> ‘systimestamp + 30’,
	repeat_interval	=> ‘freq = daily; interval = 7’,
	comments 		=> ‘alle 7 Tage’);

EXECUTE
	Dbms_scheduler.CREATE_JOB
	(job_name 	=> ‘JOB_LOGBUCH_1’,
	program_name 	=> ‘BEREINIGE_LOGBUCH’,
	schedule_name 	=> ‘DB_CLEANER’);

Ein Schedule ermöglicht die gleichzeitige Verwaltung von mehreren Jobs. Somit muss die zeitliche Definition nicht für jeden Job einzeln angepasst werden, sondern wird zentral für den Schedule geändert.

Informationen zu den in der Datenbank vorhandenen Schedules findet man in den folgenden Views:

• DBA_SCHEDULER_SCHEDULES
• DBA_SCHEDULER_JOBS

Monitoring

Das GUI, das im Enterprise Manager vorhanden ist, bietet einen Überblick über alle Jobs. So kann man den Verlauf der einzelnen Jobs überwachen. Jobs, die nicht oder mit Fehlern beendet wurden, kann man durch das Filtern anhand ihrer Attribute einfach identifizieren.

Der Scheduler hat einen flexiblen Logging-Mechanismus. Über den Logging-Level wird bestimmt, welche Informationen geloggt werden. Der Scheduler stellt dazu drei verschiedene Logging-Level zur Verfügung:

• Full: Bei „full“ wird jede Statusänderung beim Ausführen des Jobs protokolliert.
• Off: Der Logging-Level „off“ schaltet das Logging komplett aus.
• Job run: Bei dem Logging-Level „job run“ wird lediglich protokolliert, ob der Job erfolgreich gelaufen ist oder nicht.

Damit das Logging auf Dauer nicht unübersichtlich wird, löscht der Scheduler anhand des Attributs „log history“ die bisherigen Log-Daten. Dieses Attribut bestimmt, wie lange die Historie der Jobs aufbewahrt werden soll. Es kann darüber hinaus global für den Scheduler gesetzt werden.

Vorteile des Oracle Schedulers gegenüber Schedulern von Drittanbietern

Ein entscheidender Vorteil des Oracle Schedulers gegenüber Software von Drittherstellern ist, dass der Oracle Scheduler direkt mit der Standard bzw. der Enterprise Edition von Oracle 10g mitgeliefert wird. So entstehen keine zusätzlichen Kosten für die Jobsteuerung.

Dass man seine Erfahrungen mit der Oracle Datenbank nutzen kann, ist ein weiterer Vorzug des Oracle Schedulers. Sprich: Man muss sich keine neue Syntax aneignen und auch kein neues System kennen lernen.

Neben der Plattformunabhängigkeit zeichnet ihn auch die Tatsache aus, dass Jobs nur dann gestartet werden, wenn die Datenbank online ist. Fällige Jobs werden nach dem Starten der Datenbank nachgeholt.

Fazit

Der Scheduler von Oracle 10g bietet einige lang erwartete Features für eine flexible Verwaltung von sich wiederholenden Aufgaben in einer Oracle Datenbank. Externe Programme können einfach gestartet werden. Es gibt eine grafische Benutzeroberfläche, die das Arbeiten vereinfacht. Und der DBA kann genau überprüfen, wer zu welchem Zeitpunkt welchen Job ausführt.

Es gibt allerdings ein paar Unzulänglichkeiten, die wir Ihnen nicht vorenthalten wollen:

• Die logische Ablaufsteuerung muss nach wie vor manuell implementiert werden. Es gibt also keine Möglichkeit, Netze zu definieren.
• Ebenfalls ist bisher kein Benachrichtigungsmechanismus implementiert worden.

Das Paket dbms_job ist in der Praxis vielfach genutzt worden. Und durch die erweiterte Funktionalität mit dbms_scheduler sind die Einsatzmöglichkeiten sehr viel umfangreicher geworden. Allerdings gibt es bisher keine automatische Möglichkeit, von DBMS_JOB auf DBMS_SCHEDULER umzuschwenken.

Sie möchten dennoch umschwenken und von den neuen Funktionalitäten profitieren? Fordern Sie uns! Wir unterstützen Sie gern bei diesem Vorhaben.

Kathrin Hammerschmidt (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen