| |
| |
|
|
Plattformen
Der Job Scheduler steht für folgende Plattformen zur Verfügung:
-
Windows 2000/2003/XP/Vista
-
Linux ab Kernel 2.4
-
Solaris 8/9/10
-
HP-UX 11 (PA-RISC, IA64 Itanium)
Der Job Scheduler kann ohne Datenbank betrieben werden, oder mit einer der unterstützten
Datenbanken mittels ODBS/JDBS Treibern:
- Oracle 8.1.7, 9.2, 10g
- SQL Server 2000, 2005
- DB2 8.x
- MySQL Version 4.1, 5.x
- PostgreSQL 8.x
- Firebird 1.5
|
|
|
Organisation von Jobs und Job-Ketten
Der Job Scheduler wird eingesetzt, um ausführbare Dateien und Shell Scripte zu starten
und um Datenbank-Prozeduren auszuführen, die zu vorbestimmten Zeitpunkten
oder von externen Ereignissen ausgelöst werden.
Ausführen von Jobs:
-
Jobs sind die kleinste Einheit für die Verarbeitung von ausführbaren Dateien, Shell Scripten,
und Prozeduren, sowie von Job-Implementierungen basierend auf dem Job Scheduler API.
-
Jobs können unabhängig voneinander ausgeführt werden, je nach Ergebnis (Erfolg, Fehler, Exit Code)
eines jeweiligen Jobs können Folge-Jobs gestartet werden.
-
Jobs können parallel von einer konfigurierbaren Anzahl von Tasks verarbeitet werden.
Lesen Sie mehr über dieses Feature in der Job Dokumentation.
Job-Ketten:
-
Job-Ketten können Sie sich wie ein Fließband mit mehreren Job-Knoten vorstellen.
Das bedeutet, dass jeder Job genau einem Verarbeitungsschritt in der Job-Kette zugewiesen ist.
-
Der Workflow wird durch Aufträge reguliert. Einen Auftrag kann man sich als Arbeitsanweisung
vorstellen, die in einer Job-Kette abgearbeitet wird. Der Auftrag wird einer Job-Kette zugeordnet.
Er erhält eine für diese Job-Kette eindeutige Identifizierung.
Der Status des Auftrags ändert sich während der Verarbeitung
durch die jeweiligen Job-Knoten. Jeder Auftrag kann als Nutzlast Parameter transportieren.
-
Aufträge werden während der Verarbeiung persistent gespeichert. Wird ein Job während der Verarbeitung
gestoppt und dann wieder gestartet, dann wird die Verarbeitung genau an der Stelle fortgesetzt, an der
sie vorher angehalten wurde.
Lesen Sie mehr über dieses Feature in der Dokumentation für Job-Ketten.
Organisation:
-
Job- und Job-Ketten Konfigurationen können von den Konfigurationsdateien eines Hosts gelesen werden.
-
Konfigurationen können zur Startzeit des Job Schedulers aus einer zentralen Datenbank gelesen werden.
Dieses Konzept wird im Feature Managed Jobs erklärt.
-
Konfigurationen können mittels Managed Jobs für Job Scheduler Instanzen
auf mehreren Hosts eingesetzt werden.
|
|
|
Standard Jobs
Der Job Scheduler wird mit einer Auswahl von Standard Jobs ausgeliefert:
-
Logging and Cleanup
-
Sanity Checking
-
Mail Forwarding
-
Remote Job Execution
-
FTP Transfer
-
File Operations (rename, copy, remove, check existence)
Lesen Sie mehr über dieses Feature auf unserer Web-Seite Lösungen
|
|
|
Solution Stacks
Solution Stacks sind Implementierungen des Job Schedulers mit Komponenten Dritter. Diese Komponenten
könnten Code enthalten, der nicht mit der Open Source Lizenz des Job Schedulers kompatibel ist, aus diesem
Grund wird der Code nicht ausgeliefert sondern muss seperat heruntergeladen werden:
-
Integration mit Netzwerk Monitoren (Nagios, Hobbit)
-
Berichte mit JasperReports
-
Secure Shell mit Ganymed (ssh, scp, sftp)
Lesen Sie mehr über diesen Software Stack auf unserer Web-Seite Lösungen.
|
|
|
Konfiguration aus Hot Folders
Hot Folders sind Verzeichnisse die vom Job Scheduler automatisch überwacht werden. D.h. Konfigurationen
für den Job Scheduler können in einzelnen Dateien gehalten werden, im Falle einer Änderung übernimmt der
Job Scheduler die neue Konfiguration im laufenden Betrieb und ohne die Notwendigkeit eines Neustarts.
Lesen Sie mehr über dieses Feature auf der Web-Site Konfiguration mit Hot Folders.
|
|
|
Graphische Oberflächen (GUI)
Der Job Scheduler wird mit XML-Dateien konfiguriert, mit dem GUI können allerdings
Jobs auch ohne XML-Kenntnisse verwaltet werden. Die GUIs ermöglichen die Job-Kontrolle,
das Verwalten von Jobs und Job-Ketten zur Laufzeit.
Eingebautes GUI zur Job-Kontrolle
Jeder Job Scheduler enthält einen HTTP-Server, der Statusinformationen der Jobs anzeigt und
zur Laufzeit Operationen zur Job-Kontrolle ermöglicht
(starten und stoppen von Jobs, Zugriff auf Log-Dateien etc.):
-
Zeigt die Job-Historie, die Protokolle der Tasks, Aufträge und das Job Scheduler
Hauptprotokoll an.
-
Stellt für das Job Scheduling Funktionen zum Monitoring und zur Kontrolle zur Verfügung:
starten und stoppen von Jobs, beenden von Jobs, Parameter setzen und Protokolle abrufen.
Lesen Sie mehr über dieses Feature in der HTTP Server Dokumentation.
Managed Jobs GUI
Mit dem GUI ist es möglich, mehrere Job Scheduler auf unterschiedlichen Systemen zu überwachen.
-
Mit einer Explorer-ähnlichen Web-Oberfläche, die mit Ajax implementiert wurde, können
Jobs, Job-Ketten und weitere Job Scheduler Objekte konfiguriert werden.
-
Jobs können an mehrere Job Scheduler auf unterschiedlichen Hosts übergeben werden.
-
Job Scheduler Konfigurationen werden in einer der unterstützten Datenbanken gespeichert.
-
Die Web-Oberfläche ermöglicht den Zugriff auf die Job-Historie, sowie den Abruf
von Protokollen bereits ausgeführter Jobs.
Lesen Sie mehr über dieses Feature in der Dokumentation Managed Jobs (PDF).
Grafischer Editor für XML Konfigurationsdateien
Der grafische Editor wird als Alternative zum Managed Jobs GUI von Anwendern genutzt, die
die Job-Konfigurationen nicht in der Datenbank speichern wollen,
sondern stattdessen bevorzugen, die Konfigurationsdateien auf der Platte zu speichern.
-
Der Konfigurations-Editor verringert die Komplexität, direkt auf die
XML-Struktur zuzugreifen, und prüft die Konfiguration gegen ein XML-Schema.
Außerdem ist es viel einfacher komplexe Laufzeitkonfigurationen per Mausklick zu verwalten.
-
Der Konfigurations-Editor unterstützt die gleichen Operationen wie das Managed Jobs GUI.
-
Der Editor stellt Wizards für die Konfiguration von Jobs und Job-Ketten zur Verfügung.
Lesen Sie mehr über dieses Feature in der Dokumentation für GUI und Konfiguration.
|
|
|
Bedienung mittels Kommandozeile
Neben den Grafischen Oberflächen (GUI) können die grundsätzlichen adminstrativen Aufgaben
mittels Kommandozeile kontrolliert werden:
- starten, stoppen, beenden und abbrechen des Job Schedulers
- starten, stoppen, beenden und abbrechen von Jobs.
Lesen Sie mehr über dieses Feature in der Dokumentation über die Kommandozeile.
|
|
|
API: Application Programming Interface
Der Job Scheduler bietet APIs für die Implementierung von Jobs, Job Scripten und zur
Kontrolle von Prozessen auf entfernten Rechnern.
API zur Job Implementierung
-
Jobs können in jeder der unterstützten Programmiersprachen Java, Javascript (Spidermonkey), Perl, VBScript geschrieben werden.
Sie können eine beliebige Script-Sprache verwenden, allerdings
haben nur Jobs mit Implementierungen in einer der
unterstützten Sprachen Zugriff auf das Job Scheduler API.
-
Scripte für Vor- und Nachverarbeitung von existierenden Jobs (Monitor Scripte).
-
Starten von Jobs und Job-Ketten per Programmaufruf.
-
Erstellen dynamischer Job-Parameter.
-
Implementierung von bedingter Job-Verarbeitung.
-
Schreiben von Meldungen und Debug-Ausgaben in die Protokolle des Job Schedulers.
-
Versenden von eMail durch Jobs.
-
Erstellen dynamischer Job-Konfigurationen, hinzufügen von Jobs, Job-Ketten und Aufträgen programmgesteuert.
Lesen Sie mehr über dieses Feature in der API Dokumentation.
XML API zur Job-Kontrolle
-
Überwachen von Jobs und Job-Ketten mit einfachen XML-Kommandos.
-
Jobs starten, hinzufügen und entfernen von Aufträgen für Job-Ketten.
-
Überwachen des Job Schedulers (beenden, abbrechen, neu starten, pausieren, fortsetzen).
-
Abfragen von Statusinformationen für Jobs, Job-Ketten, Aufträge etc.
Lesen Sie mehr über dieses Feature in der Dokumentation der XML-Kommandos.
|
|
|
Web Service Integration
Der Job Scheduler kann so konfiguriert werden, dass er sich wie ein Web Service hinsichtlich
der Jobs und Job-Ketten verhält:
-
Jeder Job kann als Web Service fungieren - unabhängig von der Implementierung.
-
Die Annahme der Web Service Requests beinhaltet synchrone und asynchrone Job-Starts.
-
Requests von Web Service Clients nutzen das Job Scheduler XML API zur Job-Kontrolle,
um Jobs und Job-Ketten zu starten und Parameter zu übergeben.
-
Requests von Web Service Clients können automatisch für die Job Scheduler XML API per Stylesheet transformiert werden.
-
Anworten an den Aufrufer oder an andere Web Services werden vom Job Scheduler übernommen.
-
Antworten können automatisch per Stylesheet in individuelle XML-Formate transformiert werden.
Lesen Sie mehr über dieses Feature im Web Service Implementation Tutorial.
Weitere Beispiele finden Sie auf unserer Web-Seite Lösungen.
|
|
|
Job-Start Ereignisse
Jobs können durch folgende Ereignisse gestartet werden:
-
Job-Starts können durch das Überwachen (monitoring) von Verzeichnissen ausgelöst werden, d.h. der Start erfolgt,
sobald eine Veränderung in einem der überwachten Verzeichnisse erfolgt ist, oder wenn Dateien
hinzugefügt oder gelöscht wurden.
Lesen Sie mehr über dieses Feature in der Dokumentation
Verzeichnisüberwachung
und Verzeichnisüberwachung mit Dateiaufträgen.
-
Jobs können gestartet werden sobald ein vordefinierter Zeitpunkt erreicht ist: Tageszeit,
Wochentag, Tag im Monat, relativ zum Monatesende (ultimo) etc.
Lesen Sie mehr über dieses Feature in der Dokumentation über Run Times.
-
Programmgesteuerte Job-Starts können mit dem Job Scheduler API ausgelöst werden
(verfügbar für Java, Javascript, VBScript, Perl).
Lesen Sie mehr über dieses Feature in der API Dokumentation.
-
Job-Starts können von Ereignissen ausgelöst werden, die mittels TCP und UDP gesendet wurden.
Lesen Sie mehr über dieses Feature in der Dokumentation für XML-Befehle.
-
Manuelle Job-Starts können über die Grafische Oberfläche ausgelöst werden.
-
Jobs können manuell per Kommandozeile gestartet werden.
|
|
|
Zeitfenster für die Job-Verarbeitung
Job-Aktivitäten können auf bestimmte Zeifenster eingeschränkt werden.
Der Job Scheduler unterstützt eine beliebige Anzahl von Zeitfenstern, die
nach individuellen Anforderungen konfiguriert werden können.
-
Geplante Wartungsfenster oder System-Backup Intervalle können
konfiguriert werden, damit Jobs nicht ausgeführt werden.
-
Zeitfenster sind die zugelassenen Betriebszeiten für Jobs,
z.B. kann die Betriebszeit für den Zeitraum zwischen 8:00 Uhr und 10:00 Uhr eingestellt werden,
unabhängig davon, zu welchem Zeitpunkt in diesem Zeitraum ein Ereignis den Job-Start auslöst.
-
Job-Starts, die außerhalb des Zeitfensters ausgelöst werden, werden automatisch auf
das nächste verfügbare Zeitfenster verschoben.
-
Zeitfenster für Feiertage können pro Job oder für alle Jobs konfiguriert werden.
Lesen Sie mehr über dieses Feature in der Dokumentation über Run Time Konfiguration.
|
|
|
Priorisierung von Jobs
Für das Job Scheduling können Jobs priorisiert werden durch:
-
die Zuteilung von System-Prioritäten idle, below_normal,
normal, above_normal und high, oder durch numerische Werte
die für das jeweilige Betriebssystem zugelassen sind.
-
Verwendung von Prozess-Klassen, sofern die Jobs als separate Prozesse (tasks)
gestartet werden. Es können eine maximale Anzahl von Prozessen pro Klasse und die
maximale Anzahl belegbarer Prozesse pro Job konfiguriert werden: sind bspw. drei
Jobs für eine Prozessklasse mit max. 10 Prozessen konfiguriert, dann können dieselben
Jobs in mehreren Instanzen (tasks) ablaufen.
Lesen Sie mehr über dieses Feature in der Job Dokumentation.
|
|
|
Benachrichtigung per eMail
Benachrichtigungen über den Status eines Jobs können automatisch per eMail versendet werden.
Für folgende Ereignisse werden automatisch eMails versendet:
- on success:
im Erfolgsfall, d.i. bei ausführbaren Dateien der Exit Code = 0,
bei programmierten Jobs das Ausbleiben eines Fehlers;
- on error:
im Fehlerfall, d.i. bei ausführbaren Dateien ein Exit Code != 0,
bei Jobs das Auftreten von Exceptions bzw.
das Werfen einer Exception durch einen API-Aufruf;
- on warning:
bei programmierten Jobs können Warnungen mittels API-Aufruf im Task-Protokoll erzeugt werden;
- on process:
bei programmierten Jobs kann der Versand
von eMails für das Erreichen einer Mindestanzahl von Prozessschritten konfiguriert werden.
Der Inhalt von automatisch generierten eMails:
-
Absenderinformationen über den Host, Job Scheduler, Uhrzeit des Auftretens des Fehlers
bzw. des Ereignisses, das den Versand veranlasst hat.
-
Die originale Fehlermeldung oder eine andere Benachrichtigung.
-
Job Protokoll als Anhang: bei ausführbaren Dateien sind
stdout und stderr des Jobs im Protokoll enthalten,
bei programmierten Jobs sind alle im Protokoll erzeugten Ausgaben enthalten.
Protokollierungsstufen (log level) können konfiguriert werden.
-
eMails werden an vorkonfigurierte Empfänger, wahlweise pro Job einstellbar, versendet. Mittels
Job Scheduler API kann ein Job alle Elemente eines eMails beeinflussen
(Empfänger, Cc, Bcc, subject, body, Hinzufügen weiterer Anhänge).
-
Inhalt und Layout von eMails können mittels Stylsheets individuell angepasst werden.
-
Können eMails, z.B. mangels Verbindung zum Mail-Server, nicht versendet werden, dann werden Sie
im Dateisystem zwischengespeichert und der Versand in regelmäßigen Intervallen wiederholt.
Lesen Sie mehr über dieses Feature in der Dokumentation über eMail-Versand.
|
|
|
Protokollierung der Job-Historie
Folgende Protokolle werden erzeugt:
- Job-Protokoll:
Start und Ende eines Jobs.
- Scheduler Protokoll:
Das Protokoll beinhaltet zusammenfassend die Protokolle aller Tasks.
- Task-Protokoll:
Pro Task eines Jobs ein Task-Protokoll. Bei Verarbeitung ausführbarer Dateien enthält
das Protokoll den Inhalt von stdout und stderr, bei programmierten Jobs sind alle
per API erzeugten Ausgaben enthalten. Pro Job können individuell
Protokollierungsstufen (log level) vereinbart werden.
- Auftragsprotokoll:
Das Auftragsprotokoll ist der auftragsbezogene Inhalt der Protokolle aller derjenigen
Tasks, die der Auftrag durchlief, d.i. eine zusammenfassende Sicht auf alle
Prozesse eines Auftrags.
- Analyseprotokoll:
zu Debugging-Zwecken.
Mit Ausnahme des Analyseprotokolls werden alle Protokolle automatisch in der Datenbank
komprimiert (gzip) gespeichert. Die Protokolle sind über die Web-Oberfläche des einzelnen
Job Schedulers und über eine zentrale Historienauskunft abrufbar. Die zentrale Auskunft
beinhaltet gruppierte Anzeigen nach Verarbeitungsergebnis, -Dauer und Häufigkeit von Job-Läufen.
Neben den Protokolldaten werden in der Datenbank Historientabellen für Tasks und
Aufträge geführt, die zur Auswertung herangezogen werden können.
Lesen Sie mehr über dieses Feature in der Dokumentation der Protokolle.
|
|
|
Job-Sperren
Mit diesem Feature wird verhindert, dass zwei Jobs parallel auf die gleiche Ressource
zugreifen, z.B. eine Datenbank oder eine Datei. Die Sperre bewirkt, dass nur jeweils ein Prozess den exklusiven
Zugriff auf die Ressource erhält und zwar so lange wie die Sperre besteht. Dadurch wird z.B.
gewährleistet, dass in Datei- und Datenbanksystemen die Lese-und Schreibanforderungen konsistent sind.
Ist ein Job in der Warteschleife bis eine Sperre frei wird (lock contention), dann wird der Job automatisch
gestartet sobald die Sperre frei ist.
Der Job Scheduler unterstützt zwei Arten von Sperren:
- Exklusive Sperren:
Solange eine Task mit einer exklusiven Sperre belegt ist, kann keine andere Task (Job) diesen Status gleichzeitig erhalten.
Mit einer exklusiven Sperre wird sichergestellt, dass ein Prozess, der in eine Ressource schreibt oder aus ihr liest, nicht von einem
anderen Prozess unterbrochen wird (write-lock). Die exklusive Sperre wird für Prozesse eingesetzt, die Ressourcen ändern.
- Nicht-exklusive Sperren:
Mehrere Prozesse (Jobs) können gleichzeitig eine Sperre belegen. Die Nicht-exklusiven Sperren erlauben, dass
mehrere Prozesse gleichzeitig auf eine Ressource zugreifen, vorausgesetzt dass die Prozesse keine
Änderungen in der Ressource vornehmen wollen (read-lock). Die Anzahl der nicht-exklusiven Sperren kann
eingeschränkt werden.
Lesen Sie mehr über dieses Feature in der Dokumentation über Job-Sperren.
|
|
|
Externe Job-Verarbeitung
Falls es notwendig wird, dass ein Job auf Host A verarbeitet und anschließend ein Job auf Host B
ausgeführt wird, dann ist externe Job-Verarbeitung das passende Feature.
Jobs können von einem Job Scheduler verarbeitet werden, der auf einem entfernten Server
läuft. Dies trifft auf einfache Shell Scripte und ausführbare Dateien zu, die mit den
oben benannten Standard Jobs eingesetzt werden.
-
Extern verarbeitete Jobs verhalten sich hinsichtlich des Job Schedulers, von dem sie verarbeitet werden,
genau so als wären sie lokal verarbeitet worden. Der einzige Unterschied ist, dass die
Verarbeitungslast vom auslösenden zum verarbeitenden Job Scheduler übertragen wird.
-
Das bedeutet zum Beispiel, dass alle API-Aufrufe sich auf das lokale Job Scheduler Objekt beziehen.
-
Die Information aus den Job-Protokollen, der Endstatus und mögliche
Fehlermeldungen werden an den auslösenden Job Scheduler weitergeleitet.
Lesen Sie mehr über dieses Feature in der Dokumentation für Externe Job-Verarbeitung.
|
|
|
Backup Job Scheduler: Verfügbarkeit und Ausfallsicherheit
Die Unternehmens-IT muss sich darauf verlassen können, dass Jobs ausgeführt
werden, auch wenn ein bestimmtes Job Scheduler Server System nicht läuft oder abgestürzt ist.
Ein Job Scheduler Backup Cluster garantiert den ausfallsicheren Einsatz eines (primären) Job Schedulers.
Der Cluster besteht aus einem primären Job Scheduler und einem oder mehreren Backup Job Schedulern.
Ein ausfallsicheres System besteht aus einem primären Job Scheduler und mindestens einem Backup, bei dem
die Job Scheduler auf unterschiedlichen Server Systemen laufen.
-
Alle Job Scheduler im Backup Cluster signalisieren ihre Verfügbarkeit indem sie sogenannte heartbeats
versenden, gleichzeitig prüfen sie, ob die anderen Job Scheduler im Cluster verfügbar sind, indem sie die
heartbeats der anderen Job Scheduler überwachen (monitoring).
-
Falls einer der Backup Job Scheduler fehlende heartbeats eines primären Job Scheduler
über einen längeren Zeitraum bemerkt (ca. 1-2 Minuten), dann übernimmt er die Verarbeitung.
Das bedeutet, dass die Verarbeitung der Prozesse und offenen Aufträge, sowie bereits in Verarbeitung befindliche Jobs
eines primären Job Schedulers übernommen werden, falls erforderlich werden neue Jobs gestartet.
Lesen Sie mehr über dieses Feature in der Dokumentation Backup Job Scheduler.
|
|
|
Load Balancing mit mehreren Job Schedulern
Falls sie ein hohes Datenaufkommen zeitaufwändig verarbeiten müssen, dann können
mehrere Job Scheduler die Verarbeitungszeit maßgeblich verkürzen und gleichzeitig die Verfügbarkeit erhöhen.
Beim Load Balancing werden Aufgaben von mehreren Job Schedulern übernommen, die die Verarbeitung
auf verteilten Rechnersystemen abwickeln.
-
Mehrere Job Scheduler (Cluster) können gleichzeitig Aufträge von unterschiedlichen Hosts verarbeiten.
Der Cluster wird zum Load Balancing eingesetzt, um die Verarbeitungszeit zu verkürzen und um die
Notwendigkeit zusätzlicher Backup Hardware zu minimieren.
-
Die Job Scheduler im Cluster signalisieren mit sogenannten heartbeats ihre Verfügbarkeit.
Stellt ein Job Scheduler fest, dass über einen längeren Zeitraum (1-2 Minuten) der heartbeat
eines anderen Job Schedulers ausbleibt, dann übernimmt dieser sofort die Verarbeitung der angefangenen Aufträge.
-
Eine beliebige Anzahl von Job Schedulern können parallel eingesetzt werden.
Lesen Sie mehr über dieses Feature in der Dokumentation Verteilte Aufträge.
|
|
|
Maßnahmen zur Ausfallsicherheit
Der Job Scheduler bietet die folgenden Maßnahmen im Falle von Ressourcen-Knappheit oder Systemausfall:
- Sanity Checking
Jeder überwachte Job Scheduler enthält einen Job für das Sanity Checking,
der mit konfigurierbarer Intensität verfügbare Ressourcen für
den Prozessstart, Hauptspeicher etc. abfragt. Einer oder mehrere Job Scheduler können das
Monitoring anderer Job Scheduler übernehmen.
- Wiederanlauffähigkeit
Der Job Scheduler speichert persistent in der Datenbank die Informationen über
offene Aufträge und eingereihte Jobs. Nach Wiederanlauf des Job Schedulers werden
automatisch offene Aufträge fortgesetzt und eingereihte Jobs abgearbeitet.
- Wiederherstellung von Datenbankverbindungen
Die Datenbankverbindung ist effektiv der single point of failure - kommt sie nicht zustande,
dann wird ein konfigurierbares Verfahren aktiv:
-
Wiederholter Verbindungsaufbau,
-
Abbruch nach angebbarer Anzahl der Wiederholungsversuche,
-
Fortsetzung des Betriebs ohne Datenbank (nur möglich wenn
keine datenbankverwalteten Jobs eingesetzt werden), die Job-Historie wird in diesem
Fall in Textdateien geführt.
Falls eine Datenbankverbindung wiederhergestellt werden muss, wird eine
Benachrichtigung an den Administrator versendet.
Lesen Sie mehr über dieses Feature in der Dokumentation Datenbank Einstellungen.
|
|
|
Ausführen von Datenbankprozeduren
Der Job Scheduler wird eingesetzt, um Jobs mit SQL Statements und Aufrufen von Stored Procedures etc.
in einer der unterstützten Datenbanken auszuführen:
-
Es können beliebig viele Prozeduren einzeln oder auftragsgesteuert in Job-Ketten ausgeführt werden.
Return Codes und SQL-Ausgaben von Prozeduren werden ins Protokoll aufgenommen.
-
Mit dem Managed Jobs GUI können die auszuführenden
Prozeduren zentral in der Datenbank konfiguriert und gespeichert werden.
-
Die Prozeduren können von beliebigen Job Schedulern auf den unterstützten Plattformen
gestartet werden. Da die Verbindungen durch Type 4 JDBC Treiber
im Neztwerk hergestellt werden, muss der Job Scheduler nicht auf dem Datenbank Server
installiert werden. Darüber hinaus beschränkt sich die Verarbeitungslast dieser Jobs
hauptsächlich auf die Datenbank.
Lesen Sie mehr über dieses Feature in der Dokumentation Managed Jobs (PDF).
|
|
|
MySQL Job Scheduling
SQL Interface:
- Ausführen beliebiger Datenbank-Statements (analog zu Oracle dbms_jobs)
- Stored Procedures zu geplanten Zeitpunkten ausführen
- Automatische Wiederholung von Jobs in frei konfigurierbaren Intervallen
- Benachrichtigung über Erfolg oder Misserfolg per eMail
- Der Job Scheduler berücksichtigt die Rechte des Benutzers, der Jobs startet
- Individuelle Berechtigungen für das Einstellen von Jobs
Lesen Sie mehr über dieses Feature in der Dokumentation für MySQL Job Scheduling (PDF).
Maintenance Monitoring:
- Automatisierte Datenbank-Statistiken (analyze table)
- Konsistenzprüfung (repair table)
- Überwachung von Replikationsinstanzen: Scheduler meldet Fehler in der MySQL-Replikation und versendet Benachrichtigungen an die Administratoren
Lesen Sie mehr über dieses Feature auf der Web-SiteMySQL job solutions.
|
|
|
Job Scheduler Roadmap
In der PowerPoint Präsentation (englisch)
und PDF Präsentation (englisch)
finden Sie die geplanten Weiterentwicklungen für Features des
Open Source Job Schedulers. Neue Features entstehen aus dem konkreten Bedarf der Unternehmen,
die den Open Source Job Scheduler einsetzen.
Setzen Sie den Open Source Job Scheduler bereits ein oder beabsichtigen Sie dies in nächster Zeit, dann
profitieren auch Sie von den stetigen Open Source Weiterentwicklungen. Es ist allein Ihre
Unterstützung, die es uns ermöglicht die Entwicklung des Job Schedulers in großen Schritten
voranzubringen.
Werden Sie aktiv für das Open Source Konzept und entscheiden Sie sich dafür, Budgets für die Entwicklung von
Features oder den Kauf von Lizenzen bereitzustellen. Weiter ist Ihre Hilfe bei der Entwicklung der Roadmap notwendig,
Ihr Feedback trägt dazu bei die Priorisierung der Features festzulegen.
Schreiben Sie uns, was Sie von den geplanten Features halten, welche Priorität Sie bei der Entwicklung setzen und
welche anderen Features Sie wünschen.
Wir sind an Ihren Kommentaren interessiert, bitte senden Sie Ihren Beitrag an
info@sos-berlin.com
|
|
