Ich erinnere mich an einen Nachmittag, an dem das Telefon klingelte und die Ruhe in meiner DBA-Kabine jäh durchbrach. Es war ein Entwickler, der in Panik geraten war und versehentlich einige Daten gelöscht hatte. Könnten wir eine schnelle Wiederherstellung durchführen? Ich navigierte zum Speicherort der Sicherungskopie, musste aber feststellen, dass die letzte Sicherung von der Vorwoche stammte. Es stellte sich heraus, dass der Sicherungsauftrag des SQL Server-Agenten seit mehreren Tagen blockiert war und nie abgeschlossen wurde. Er lief sogar noch!

Es gelang uns schließlich, die Daten wiederherzustellen, aber es war klar, dass wir ein tieferes Problem hatten. Ein ähnliches Problem hatten wir erst in der Woche zuvor, als ein nächtlicher Ladevorgang zu lange dauerte und zu einer Überlastung der Ressourcen führte. Ich war ziemlich stolz auf unser automatisiertes Datenbankwartungssystem. Es war solide, die Aufträge schlugen nur sehr selten fehl, und wenn doch, erhielten wir immer sofort eine Fehlermeldung. Ich begann jedoch zu erkennen, dass dies allein nicht ausreichte. Unsere Agentenaufträge wurden zwar fast immer erfolgreich abgeschlossen, aber die Dauer der Aufträge schwankte sehr stark, was uns nicht bewusst war.

Wir mussten nicht nur wissen, wann Aufträge fehlschlugen, sondern auch, wann sie ein untypisches Verhalten zeigten. Kurz gesagt, wir mussten eine Möglichkeit finden, die Dauer von SQL Server Agent-Aufträgen im Laufe der Zeit zu verfolgen und bei Anomalien gewarnt zu werden.

Verfolgung von Agentenauftragsdaten

Der SQL Server Agent ist eine integrierte Planungsfunktion für SQL Server. Er legt die Kontrolle über die Automatisierung in die Hände von DBAs, von denen die meisten ihn zur Automatisierung einer Vielzahl von SQL Server-Wartungsvorgängen verwenden. Die Einrichtung von SQL Server Agent und die Erstellung von Aufträgen und Zeitplänen ist relativ einfach. Es gibt eine ganze Treppenserie, die Ihnen den Einstieg erleichtert, falls Sie Hilfe benötigen.

Wenn Sie alles eingerichtet haben und es läuft, wie können Sie dann das Verhalten Ihrer Aufträge verfolgen? Dazu gibt es mehrere Möglichkeiten, entweder über die grafische Benutzeroberfläche von SQL Server Management Studio (SSMS) oder über T-SQL-Abfragen. Schauen wir uns diese an.

Job Activity Monitor

Das naheliegendste Tool, das Sie ausprobieren sollten, ist der Job Activity Monitor, der sich im Ordner SQL Server Agent in SSMS befindet.

Abbildung 1 - Öffnen des Job Activity Monitor in SQL Server Management Studio

Wenn Sie darauf doppelklicken, können Sie den Status aller in Ihrem System definierten Aufträge einsehen. Sie können Filter anwenden, um nach Aufträgen zu suchen, z. B. nach dem Auftragsnamen oder dem Status, dem Zeitpunkt der letzten Ausführung oder der nächsten geplanten Ausführung usw. So können Sie sehen, ob ein Auftrag läuft und ob er erfolgreich ausgeführt wurde. Es sagt jedoch nichts über das Verhalten dieses Auftrags im Laufe der Zeit aus. Läuft dieser Auftrag länger als gewöhnlich? Das ist von hier aus schwer zu sagen. Deshalb gehen Sie zum Log File Viewer.

Um das Fenster Log File Viewer zu öffnen, klicken Sie mit der rechten Maustaste auf einen beliebigen Auftrag in SQL Server Agent und wählen Sie View History aus dem Kontextmenü. Dies ist ein allgemeines Fenster, in dem Sie die Protokolle für SQL Server Agent selbst, die Aufträge in Agent und SQL Mail anzeigen können. Auch hier können Sie nach einem bestimmten Auftrag filtern oder sogar den Auftragsverlauf durchsuchen.

Abbildung 2 - Verlauf der Datenbanksicherungen im Log File Viewer

Um herauszufinden, ob ein Auftrag ungewöhnlich lange gelaufen ist, scrollen Sie einfach durch die Dauer des Auftrags im Zeitverlauf. Abbildung 3 zeigt einen Ausschnitt aus dem Verlauf meines Sicherungsauftrags.

Abbildung 3 - Überprüfung der Dauer von Sicherungsaufträgen im Log File Viewer

Es zeigt sich, dass der Auftrag zwar in der Regel in ein oder zwei Sekunden abgeschlossen ist, in einigen Fällen aber auch 2 oder sogar 3 Minuten gedauert hat. Dies ist eine ziemlich radikale Abweichung vom normalen Verhalten.

Das Problem dabei ist, dass das Herumblättern im Fenster und der Versuch, diese Informationen aufzuspüren, zeitaufwändig ist. Anstatt die grafische Benutzeroberfläche zu verwenden, könnte es einfacher sein, die Daten mit T-SQL aufzuspüren

Der Verlauf von SQL Server Agent-Aufträgen wird in der msdb-Systemdatenbank gespeichert. Listing 1 zeigt eine Abfrage, die die Informationen abruft und sie in der Reihenfolge der Dauer anordnet.

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;

Liste 1 - eine Abfrage zum Sortieren des Verlaufs von SQL Server Agent-Aufträgen nach Dauer

Die von der Abfrage zurückgegebenen Daten sehen wie in Abbildung 4 dargestellt aus.

Abbildung 4 - Historie der Datenbank-Sicherungsaufträge, sortiert nach Dauer

Wir können jetzt die längste Auftragsdauer und den Zeitpunkt ihres Auftretens sehr leicht erkennen. Natürlich ist ein weiteres Problem aufgetreten. Die Daten in dbo.sysjobhistory für Auftragsdatum und Auftragszeit sind als Strings gespeichert. Um diese Daten nutzbar zu machen, müssen Sie also einen CAST und CONVERT durchführen.

Diese Technik macht es zwar einfacher, die Auftragsdauer im Nachhinein zu untersuchen, aber wir haben immer noch nicht das grundsätzliche Problem gelöst, dass unser Warnsystem derzeit keinen Alarm auslöst, sobald diese Abweichungen auftreten, weil es sich nur um eine Abweichung vom Standardverhalten handelt und nicht um einen Fehler. An dieser Stelle kann ein Tool wie Redgate Monitor helfen.

Redgate Monitor und Auftragsdauer

Wenn Redgate Monitor aktiviert war und auf meinem Server lief, wurde ein Alert ausgelöst, wenn der lange laufende Agent-Job auftrat:

Abbildung 5 - nicht gelöschte Alarme in der Redgate Monitor Übersicht

Wenn wir auf diese Meldung klicken, erhalten wir weitere Details:

Abbildung 6 - eine Warnung "Ungewöhnliche Auftragsdauer" in Redgate Monitor

Wir können sehen, dass die Warnung "Ungewöhnliche Auftragsdauer" heißt. Sie ist derzeit als Warnung mit niedrigem Schweregrad konfiguriert. Wenn ich auf die Warnung selbst klicke, erhalte ich noch mehr Details:

Abbildung 7 - Details der Arbeit, die eine ungewöhnliche Dauer hatte

Wir erhalten viel mehr Informationen, als in den Informationen von SQL Agent leicht verfügbar waren. Wir können sehen, dass die Datums- und Zeitangaben tatsächlich Datums- und Zeitangaben sind. Wir erhalten die Dauer des Laufs und die Basislinie, die der Median der letzten 10 Läufe ist, in diesem Fall 1 Sekunde. Wir erhalten auch die Abweichung von der Basislinie, 18000%, eine nicht unbedeutende Zahl.

Wir können sogar die Kontrolle darüber übernehmen, welche Alarmstufe ausgelöst wird und unter welchen Bedingungen, indem wir die Standardeinstellungen für den Alarm anpassen:

Abbildung 8 - Anpassen der Einstellungen für eine "Ungewöhnliche Auftragsdauer"-Warnung

In der Beschreibung des Alarms ist zu sehen, dass Redgate Monitor für jeden Auftrag eine Basisdauer berechnet, die auf der durchschnittlichen Dauer der letzten zehn Auftragsausführungen basiert. Standardmäßig wird eine Warnung der Stufe "Niedrig" ausgelöst, wenn ein Auftrag um mehr als 50 % von der Basisdauer abweicht. Bei Aufträgen, die in weniger als 2 Minuten ausgeführt werden, wird jedoch keine Warnung ausgelöst.

Im Abschnitt Alarmeinstellungen können wir dieses Verhalten jedoch anpassen. Wir können den Schweregrad der Warnung steuern und ihn je nach Bedarf von Niedrig auf Mittel oder Hoch ändern. Wir können auch die Größe der Abweichung angeben, die auftreten muss, damit die Warnung ausgelöst wird, sowie eine Mindestdauer, unterhalb derer keine Warnungen ausgelöst werden.

Das ist aber noch nicht alles. Wenn wir zu mehreren Warnschwellenwerten wechseln, können wir mehrere Warnstufen für unterschiedliche Abweichungen von der Basisdauer festlegen.

Abbildung 9 - Einstellung von Warnschwellenwerten in Redgate Monitor

Schlussfolgerung

Als DBAs müssen wir das Verhalten der Aufträge in unserem System verstehen, und wir müssen sofort gewarnt werden, wenn das Verhalten erheblich von der Norm abweicht. Es macht keinen Spaß, einen überraschenden Anruf zu erhalten, in dem man darüber informiert wird, dass ein wichtiger Prozess zu lange gelaufen ist und Probleme für das Unternehmen verursacht.

Indem wir sicherstellen, dass wir nicht nur Warnungen erhalten, wenn Aufträge fehlschlagen, sondern auch, wenn sie ein unregelmäßiges Verhalten zeigen, und indem wir genau steuern, warum und wann diese Warnungen ausgelöst werden, können wir die Auftragsaktivitäten auf unseren Servern viel besser kontrollieren und böse Überraschungen minimieren.