Ich erinnere mich noch gut an einen Nachmittag, als das Telefon in meiner DBA-Kabine klingelte und die Ruhe abrupt beendet war. Ein panischer Entwickler meldete sich: Er hatte versehentlich Daten gelöscht und brauchte dringend eine Wiederherstellung. Also öffnete ich den Speicherort für unsere Backups - nur um festzustellen, dass das letzte Backup eine Woche alt war. Der Grund: Der Sicherungsjob des SQL Server Agent war seit Tagen blockiert und lief noch immer, ohne je abgeschlossen zu werden.
Am Ende konnten wir die Daten retten, aber mir wurde klar, dass ein tieferliegendes Problem existierte. Schon in der Woche zuvor war ein nächtlicher Ladejob viel zu lange gelaufen und hatte die Ressourcen stark belastet. Eigentlich war ich ziemlich stolz auf unsere automatisierte Datenbankwartung. Die Jobs liefen fast immer zuverlässig, und im Fehlerfall bekamen wir sofort Meldung. Doch nach und nach wurde mir bewusst: Allein zu wissen, dass ein Job erfolgreich abgeschlossen wurde, reicht nicht. Die Laufzeiten schwankten enorm - und das war uns bisher entgangen.
Wir mussten also nicht nur sehen, wann Jobs fehlschlugen, sondern auch, wenn sie sich ungewöhnlich verhielten. Mit anderen Worten: Wir brauchten eine Möglichkeit, die Dauer von SQL Server Agent-Jobs über die Zeit hinweg zu verfolgen und bei Auffälligkeiten gewarnt zu werden.
Daten zu Agent-Jobs nachverfolgen
Der SQL Server Agent ist die integrierte Planungsfunktion von SQL Server. Er gibt DBAs die Kontrolle über Automatisierung - die meisten nutzen ihn für Wartungsaufgaben. Die Einrichtung von Jobs und Zeitplänen ist recht unkompliziert. Falls Sie Unterstützung brauchen: Es gibt eine ausführliche Stairway-Serie, die Sie Schritt für Schritt anleitet.
Sobald alles läuft, stellt sich die Frage: Wie behalten Sie den Überblick über das Verhalten Ihrer Jobs? Dafür gibt es mehrere Möglichkeiten - entweder über die SSMS-Oberfläche oder per T-SQL-Abfragen. Schauen wir uns beide Ansätze an.
Job Activity Monitor
Das naheliegendste Tool ist der Job Activity Monitor, den Sie im Ordner SQL Server Agent in SSMS finden.
Abbildung 1 - Öffnen des Job Activity Monitor in SQL Server Management Studio
Ein Doppelklick zeigt Ihnen den Status aller definierten Jobs. Sie können Filter setzen, etwa nach Name, Status, letzter Ausführung oder nächster geplanter Ausführung. So sehen Sie schnell, ob ein Job läuft und ob er erfolgreich war. Aber: Einen Überblick über das Laufzeitverhalten im Zeitverlauf bekommen Sie hier nicht. Läuft ein Job heute länger als sonst? Das bleibt unklar. Deshalb lohnt sich ein Blick in den Log File Viewer.
Um den Log File Viewer zu öffnen, klicken Sie mit der rechten Maustaste auf einen Job im SQL Server Agent und wählen View History. Dieses Fenster zeigt die Protokolle des SQL Server Agent, der Jobs und von SQL Mail. Auch hier können Sie nach bestimmten Jobs filtern oder die Historie durchsuchen.
Abbildung 2 - Verlauf der Datenbanksicherungen im Log File Viewer
Um zu erkennen, ob ein Job ungewöhnlich lange gelaufen ist, können Sie im Verlauf einfach die Dauer der Ausführungen vergleichen. Abbildung 3 zeigt ein Beispiel aus dem Verlauf meines Backup-Jobs.
Abbildung 3 - Überprüfung der Laufzeiten von Sicherungsjobs im Log File Viewer
Normalerweise war der Job in ein bis zwei Sekunden fertig, doch gelegentlich dauerte er auch zwei oder drei Minuten - eine deutliche Abweichung vom Standardverhalten.
Das Problem: Sich durch diese Einträge im Fenster zu klicken, kostet Zeit. Oft ist es einfacher, die Informationen direkt per T-SQL auszulesen.
Die Historie der SQL Server Agent-Jobs wird in der Systemdatenbank msdb gespeichert. Listing 1 zeigt eine Abfrage, die die Daten abruft und nach Dauer sortiert.
USE msdb;SELECT j.name , jh.sql_severity , jh.run_duration , jh.run_date , jh.run_timeFROM dbo.sysjobs AS jJOIN dbo.sysjobhistory AS jhON jh.job_id = j.job_idORDER BY jh.run_duration DESC;
Listing 1 - Abfrage zum Sortieren der Job-Historie nach Dauer
Die Ergebnisse dieser Abfrage sehen Sie in Abbildung 4.
Abbildung 4 - Historie der Backup-Jobs, sortiert nach Dauer
So lassen sich längste Laufzeiten und deren Zeitpunkte leicht identifizieren. Allerdings gibt es einen Haken: In dbo.sysjobhistory sind Auftragsdatum und Auftragszeit als Strings gespeichert. Um damit sinnvoll arbeiten zu können, braucht es also einen CAST oder CONVERT.
Diese Technik macht es zwar einfacher, Job-Laufzeiten nachträglich auszuwerten, aber unser Hauptproblem bleibt: Solche Abweichungen lösen keine Warnung aus, weil sie technisch gesehen kein Fehler sind. Genau hier kommt ein Tool wie Redgate Monitor ins Spiel.
Job-Laufzeiten mit Redgate Monitor überwachen
Hätte Redgate Monitor auf meinem Server gelaufen, wäre bei dem lang laufenden Job sofort ein Alarm ausgelöst worden:
Abbildung 5 - Offene Alarme in der Redgate Monitor Übersicht
Ein Klick auf die Meldung liefert weitere Details:
Abbildung 6 - Warnung "Ungewöhnliche Auftragsdauer" in Redgate Monitor
Hier sehen wir, dass der Alarm "Ungewöhnliche Auftragsdauer" heißt und aktuell mit niedriger Priorität eingestuft ist. Ein Klick darauf zeigt noch detailliertere Informationen:
Abbildung 7 - Details zum Job mit ungewöhnlicher Laufzeit
Wir bekommen deutlich mehr Einblicke als über den SQL Agent. So sehen wir genaue Datums- und Zeitangaben, die tatsächliche Dauer, die ermittelte Basislinie - hier der Median der letzten zehn Läufe mit 1 Sekunde - und die Abweichung davon, in diesem Fall satte 18.000%.
Darüber hinaus können wir selbst festlegen, wann welche Alarmstufe ausgelöst wird, indem wir die Standardeinstellungen für diesen Alarm anpassen:
Abbildung 8 - Anpassung der Einstellungen für die Warnung "Ungewöhnliche Auftragsdauer"
In der Alarmbeschreibung wird deutlich: Redgate Monitor berechnet für jeden Job eine Basislaufzeit aus den letzten zehn Durchläufen. Standardmäßig gibt es eine Warnung mit niedriger Priorität, wenn ein Job um mehr als 50 % abweicht. Für Jobs, die kürzer als zwei Minuten laufen, wird jedoch keine Warnung erzeugt.
Dieses Verhalten lässt sich aber anpassen: Sie können den Schweregrad von niedrig auf mittel oder hoch ändern und definieren, ab welcher Abweichung eine Warnung ausgelöst wird. Ebenso lässt sich eine Mindestdauer festlegen, unterhalb derer keine Warnung erscheint.
Und das Beste: Sie können auch mehrere Schwellenwerte festlegen und so Warnungen in unterschiedlichen Stufen für verschiedene Abweichungen einrichten.
Abbildung 9 - Konfiguration mehrerer Warnschwellenwerte in Redgate Monitor
Fazit
Als DBAs müssen wir das Verhalten unserer Jobs verstehen - und zwar nicht nur, wenn sie fehlschlagen. Wir sollten sofort benachrichtigt werden, wenn ein Prozess deutlich länger läuft als üblich und dadurch das System oder das Unternehmen beeinträchtigt.
Indem wir auch auf ungewöhnliches Verhalten achten und flexibel steuern, wann und warum Warnungen ausgelöst werden, behalten wir unsere Jobs besser im Griff - und ersparen uns unangenehme Überraschungen.
