Nachdem ich Teile von Design and implementation of Temporal Triggers for MySQL RDBMS gelesen hatte, habe ich einen flüchtigen Blick auf das Scheduling von Kommandos in MaxDB 7.6 geworfen. Mit Scheduling ist hier nicht die Aufteilung von Rechenzeit zwischen den parallel in der Datenbank ablaufenden Arbeiten gemeint, sondern eine zeitgesteuerte Ausführung wie sie in Andrey’s Arbeit beschrieben wird. Die Menge der verfügbaren Dokumentation im MaxDB deutet zwar darauf hin, daß noch nicht der endgültige Funktionsumfang bei MaxDB erreicht ist, aber es reicht für einen flüchtigen Blick.

Leistungsumfang

MaxDB verfügt über einen eingebauten Scheduler. Der Scheduler ist in der Lage DBM-Kommandos auszuführen. Die Ausführung erfolgt zeitgesteuert. Es ist möglich eine einmalige oder eine mehrmalige Ausführung zu konfigurieren. In beiden Fällen wird ein Zeitpunkt angegeben zu dem ein Job ausgeführt wird. Wird eine mehrmalige Ausführung konfiguriert, dann erfolgt diese auf täglicher Basis zum angegebenen Zeitpunkt. Es steht keine Syntax zur Verfügung, um einen Job in anderen Zeitabständen als 24 Stunden ausführen zu lassen. Es ist also nicht möglich einen Job anzulegen der alle 15-Minuten oder zu jeder vollen Stunde ausgeführt wird. Wenn dies gewünscht ist, müssen mehrere Jobs mit 15-Minuten Abständen angelegt werden.

Ein Job steht für genau ein DBM-Kommando. Es ist nicht möglich mehr als ein Kommando in einem Job abzulegen. Will man eine Kommandofolge ausführen, dann muß man mehrere Jobs mit je einem DBM-Kommando nacheinander ausführen. Jedem Job wird von der Datenbank eine ID zugewiesen. Die Syntax von scheduler_create_job erlaubt es, Bezug auf die ID eines vorhergehenden Jobs zu nehmen, um bestimmte Ausführungsreihenfolgen zu erreichen.

./dbmcli on BW>apropos scheduler_create_job
OK
scheduler_create_job     <time>|<pre_job_id> <command> [-o[nce]]

Mit dem DBM-Kommando sql_execute und seinen Verwandten gelingt es zwar ein einfaches SQL-Statement auszuführen. Sollte es notwendig sein, eine ganze Reihe von SQL-Anweisungen auszuführen, empfiehlt sich der Aufruf einer Stored Procedure. Schwieriger als die Ausführung von SQL-Anweisungen ist der Aufruf eines externen Programms. Da aus gutem Grund kein DBM-Kommando existiert, welches den Aufruf eines beliebigen Programms unterstützt, bleibt nur der Mißbrauch eines der exec_*-Kommandos. Natürlich ist es nicht im Sinne des Erfinders das Binary, welches exec_sdbinfo aufruft auszutauschen, aber ist es grundsätzlich möglich. Ich frage mich jedoch warum man ein externes Programm über den Scheduler der Datenbank aufrufen will, statt cron, at oder ähnliches zu verwenden.

Erste Schritte mit dem MaxDB Scheduler

Die Benutzung und Konfiguration des Schedulers ist denkbar einfach. Einmal gestartet führt der Scheduler alle Kommandos aus, die mit scheduler_create_job angelegt wurden und nicht deaktiert sind. In diesem Satz verbergen sich drei Dinge. Erstens: der MaxDB Scheduler(dienst) kann mit scheduler_start gestartet und mit scheduler_stop gestoppt werden . Der aktuelle Status des Schedulers kann mit scheduler_state abgefragt werden. Nur wenn der Scheduler gestartet ist, werden die konfigurierten Jobs ausgeführt. Zweitens: es werden Jobs ausgeführt. Ein Job wird mit scheduler_create_job angelegt und mit scheduler_delete_job gelöscht. Alle Jobs können mit scheduler_list_jobs aufgelistet werden. Die Liste zeigt Statusinformationen zu den Jobs. Eine Änderung von Jobs ist nicht möglich, stattdessen muß ein Job gelöscht und neu angelegt werden. Drittens: ein Job wird nur dann ausgeführt, wenn der Scheduler(dienst) aktiviert ist und der Job selbst aktiviert ist. Zur Aktivierung eines Jobs dient scheduler_activate_job, die Deaktivierung erfolgt mit scheduler_deactivate_job.

./dbmcli on BW>help scheduler
OK
scheduler_activate_job   <job_id>
scheduler_create_job     <time>|<pre_job_id> <command> [-o[nce]]
scheduler_deactivate_job <job_id>
scheduler_delete_job     <job_id>
scheduler_list_jobs
scheduler_start
scheduler_state
scheduler_stop

---
./dbmcli on BW>scheduler_state
OK
OFF

---
./dbmcli on BW>scheduler_start
OK

---
./dbmcli on BW>scheduler_create_job 12:00:00 db_online
OK
0

---
./dbmcli on BW>scheduler_list_jobs
OK
ID 0
owner:       dbadmin
status:      active
runs:        at 12:00:00
last run:    never
dbm_command: db_online

Soweit ist alles selbsterklärend. scheduler_create_job liefert als Rückgabewert eine Job-ID, die von anderen Kommandos zur Identifizierung des Jobs benutzt wird. scheduler_list_jobs zeigt u.a. Informationen über die letzte Ausführung eines Jobs an. Diese Informationen sind jedoch nicht sehr ausführlich. Da der Scheduler immer DBM-Kommandos ausführt, landen die Ausgaben des Schedulers nicht in einem gesonderten Scheduler-Log, sondern im Logfile des DBM-Servers. Es ist bei Bedarf also auch eine Ausführungshistorie verfügbar. Das Logfile des DBM-Servers liegt im Verzeichnis RUNDIRECTORY/dbm.prt.

./dbmcli on BW>param_directget RUNDIRECTORY
OK
RUNDIRECTORY    /var/opt/sdb/data/wrk/BW

---
./dbmcli on BW>scheduler_list_jobs
OK
ID 0
owner:       dbadmin
status:      active
runs:        at 12:00:00
last run:    2005-10-11 12:00:01
             DBM Server PID 8755
             return code OK (0)
dbm_command: db_online

---

Damit wurden alle Bausteine vorgestellt, die für die ersten Schritte benötigt werden. Viel Glück beim Erkunden dieses noch noch recht neuen Features!