Jobsteuerung mit dem Microsoft SQL-Server (Teil II):

Ereignisgesteuerte Transaktionsprotokoll- Sicherung

Im ersten Teil unserer kleinen Artikelserie (ORDIX News 4/2005) über Jobsteuerung behandelten wir deren grundlegende Aspekte. Dieser Beitrag betrachtet zunächst die beiden Objekttypen Operatoren und Warnungen. Anschließend zeigen wir an einem Beispiel die vielfältigen Einsatzmöglichkeiten der Jobsteuerung auf. Dabei wird der SQL-Server Agent dazu genutzt, einen Datenbankausfall aufgrund eines vollgelaufenen Transaktionsprotokolls zu verhindern, indem dieses automatisch gesichert wird.

Operatoren

Beim Objekttyp Operatoren handelt es sich um tatsächliche Personen, die vom SQL-Server Agenten über die Ausführung von Aufträgen oder das Auftreten von Warnungen informiert werden. Es gibt mehrere Möglichkeiten, Operatoren zu informieren:

Um E-Mail nutzen zu können, muss auf dem System ein MAPI-1- kompatibler E-Mail-Client installiert sein (beispielsweise Outlook oder der Exchange Client).

Für Paging wird zusätzlich zum MAPI-1-kompatiblen E-Mail-Client noch eine Drittanbieter-Software benötigt, die für die Umsetzung von E-Mails in Pager-Nachrichten sorgt.

Anhand eines kleinen Bespiels zeigen wir im Quelltext in Abbildung 1, wie man den Operator per "NET SEND" informiert. Dabei richten wir einen Operator "Administrator vom Dienst" ein und senden die Nachrichten mit Hilfe des "NET SEND"-Befehls an ihn. Die Nachricht erscheint dann direkt auf dem Bildschirm des Rechners "Adminrechner".

Warnungen

Vom Objekttyp Warnungen gibt es prinzipiell zwei Arten: Ereignis- und Leistungsstatuswarnungen.

Schwerwiegende Fehler des SQL-Servers (ab Schweregrad 19) oder "RAISERROR WITH LOG"-Anweisungen werden im Windows Anwendungsprotokoll eingetragen. Zusätzlich können Einträge mit der Prozedur "xp_logevent" erzeugt werden.

Die Einträge im Windows-Anwendungsprotokoll werden vom SQL-Server Agenten ausgelesen und mit einer Liste von Meldungen verglichen (SQL-Server Ereigniswarnungen), die der Anwender selbst definiert. Wird eine Übereinstimmung gefunden, so wird zunächst die betreffende Warnung ausgelöst.

In der Standardinstallation sind zu Demonstrationszwecken bereits einige Warnungen vordefiniert, so auch die in Abbildung 2 dargestellte Warnung.

Abb. 2: Vorinstallierte SQL-Server Ereigniswarnung (vergrößern!).

Leistungsstatuswarnung

Im Rahmen der Installation des MS SQL-Servers werden im Windows-Systemmonitor zusätzliche Leistungsindikatoren hinzugefügt, die eine Vielzahl von Parametern des SQLServers überwachen. Unter anderem werden folgende Werte ermittelt:

• Anzahl der gleichzeitig angemeldeten Benutzer
• Reservierung und Verwendung des Arbeitsspeichers
• Prozentsatz der Seiten, die ohne Festplattenzugriff aus dem Arbeitsspeicher entnommen werden (Caching)
• Prozentsatz (Füllgrad) der verwendeten (Transaktions-)Protokolldatei
• Größe der (Transaktions-)Protokolldatei(en) in KB
• Größe der Datendatei(en) in KB

Für alle Parameter können Schwellwerte definiert werden, so dass beim Erreichen, über- oder Unterschreiten dieser Schwellwerte eine entsprechende Warnung (SQL-Server-Leistungsstatuswarnung) ausgelöst wird.

Reaktion auf eine Warnung

Immer wenn eine Warnung ausgelöst wird − unabhängig davon, ob es sich um eine Ereigniswarnung oder eine Leistungsstatuswarnung handelt − wird zunächst ein zugehöriger Zähler hochgezählt. Dieser Zähler kann jederzeit im Enterprise Manager abgefragt werden (siehe Abbildung 2, Bereich "Verlauf"). Er sagt aus, wie oft die jeweilige Warnung bereits ausgelöst wurde.

Bis zu diesem Zeitpunkt wird alles im Hintergrund abgewickelt, der Operator nicht explizit informiert und somit hat er das Problem gegebenenfalls noch nicht realisiert.

Möchte man aber, dass noch eine andere Reaktion neben dem Hochzählen des Zählers stattfindet, kann man zusätzlich zu jeder Warnung zwei Reaktionstypen definieren:

Zum einen kann ein Auftrag ausgeführt werden. Zum anderen kann die Warnung − zusammen mit einer zusätzlichen Nachricht − an einen Operator weitergeleitet werden.

Soweit zu den Grundlagen, die wir im Folgenden anhand eines Beispiels anwenden werden.

Das Problem des "vollen" Transaktionsprotokolls

Alle produktiven Datenbanken (von reinen Analysesystemen einmal abgesehen) sollten als Datenbank-Wiederherstellungs-Modell "Vollständig" eingestellt haben. Dadurch werden alle durchgeführten Transaktionen im Transaktionsprotokoll gespeichert. Die Protokolldatei wird somit stetig größer.

Problematisch wird das, wenn die konfigurierte maximale Größe der Protokolldatei erreicht oder die genutzte Festplatte voll ist. Dann können keine Änderungen mehr in der Datenbank vorgenommen werden.

Die einzige Möglichkeit, den Speicherplatz innerhalb der Protokolldatei wieder freizugeben, ist, eine Sicherung des Transaktionsprotokolls durchzuführen.

Lösung: Wir sichern bei Bedarf

In unserem Fall kann es natürlich nicht ausreichen, einen Zähler hochzuzählen, den unter Umständen niemand bemerkt. Wir werden also zusätzliche Reaktionen definieren.

Zum einen werden wir folgenden Auftrag einrichten: Der Inhalt des Transaktionsprotokolls soll immer dann auf eine andere Festplatte (oder einen anderen Rechner) gesichert werden, wenn die Protokolldatei zu einem bestimmten Prozentsatz (hier 70 %) gefüllt ist.

So wird zum einem verhindert, dass die Protokolldatei oder die Festplatte vollläuft, zum anderen können die Transaktionen so früher von einem externen Datensicherungsprogramm auf ein Band geschrieben werden und gehen bei einem Systemausfall nicht verloren.

Das Ergebnis ist dann vergleichbar mit dem Archiver unter Oracle, der die Protokolldateien (Online Redologs) zyklisch in so genannte Archivelogs sichert.

Zum anderen werden wir bei einem Fehlschlag des Backups eine Warnung per "NET SEND" an den bereits eingerichteten Operator senden.

Schritt 1: Ein Sicherungsmedium erstellen

Zunächst werden wir ein Sicherungsmedium erstellen. Das ist eine Datei, die wie ein Bandlaufwerk genutzt werden kann und in die wir sichern werden. Neue Sicherungen werden dabei immer an die Datei angefügt. Natürlich kann als Sicherungsmedium auch ein angeschlossenes Bandlaufwerk genutzt werden.

Neben der Sicherung in eine Datei auf dem lokalen Server kann auch, wie in unserem Beispiel in Abbildung 3, eine Datei auf einem entfernten System verwendet werden, wenn diese über eine Netzwerkfreigabe erreichbar ist. Dabei ist darauf zu achten, dass das Dienste-Konto des SQL-Servers ausreichende Rechte hat, in die Datei zu schreiben.

Die Sicherungsmedien können auch über den Enterprise Manager erstellt und verwaltet werden (siehe Abbildung 4).

Schritt 2: Das Backup-Skript als Auftrag

Im zweiten Schritt erstellen wir nun den Auftrag (siehe Abbildung 5), der als Kern die Anweisung zur Sicherung des Transaktionsprotokolls enthält.

Wir kümmern uns in diesem Beispiel nur um die Datensicherung der Transaktionen, aber natürlich könnte als zweiter Schritt innerhalb des Auftrages auch die Sicherung der erstellten Datei mit Hilfe eines zusätzlichen Datensicherungsprogramms auf ein Band angestoßen werden.

Wenn Sie − unabhängig vom Füllgrad der Protokolldatei − in regelmäßigen Abständen eine Sicherung des Transaktionsprotokolls durchführen möchten, so können Sie jetzt einen Zeitplan für diesen Job einrichten. Das hätte den Vorteil, dass auch in Zeiten mit nur wenigen Transaktionen alle Transaktionen nach einem festgelegten Zeitraum gesichert werden.

Schritt 3: Eine Warnung zur Überwachung

Warnungen können entweder mit dem Enterprise Manager oder der Prozedur sp_add_alert erstellt werden. Bei der Verwendung der Prozedur bestimmen die verwendeten Parameter, ob eine Ereigniswarnung oder eine Leistungsstatuswarnung erstellt wird (siehe Abbildung 6).

-- Warnung erstellen
EXEC msdb..sp_add_alert
	@name = 'Log-Archivierung notwendig (Produktion)',
	@performance_condition = 'SQLServer:Databases|Percent Log Used|
	Produktion|>|70',
	@job_name = 'Log-Archivierung (Produktion)',
	@delay_between_responses = 60

Wir verwenden − neben dem notwendigen Parameter name für den Namen der Warnung − den Parameter performance_condition zur Definition des zu überwachenden Leistungsobjektes, des Schwellwertes sowie des Vergleichsoperators.

Zusätzlich geben wir mit dem Parameter job_name den Namen des als Reaktion auszuführenden Auftrages an.

Der Parameter delay_between_responses bewirkt, dass innerhalb des in Sekunden angegebenen Zeitraums der Auftrag auch dann nicht erneut ausgeführt wird, wenn die Warnung wiederholt ausgelöst wird.

In unserem Fall hat der im Auftrag ausgeführte Befehl BACKUP LOG... also eine Minute Zeit, das Transaktions-Protokoll zu sichern und den Speicherplatz wieder freizugeben, bevor ein erneuter Sicherungsbefehl abgesetzt wird.

Abb. 7: Die im Beispiel definierte SQL-Server Leistungsstatuswarnung.(vergrößern!)

Wie diese Warnung im Enterprise Manager definiert wird, zeigt Abbildung 7.

Damit ist unser Ziel erreicht und eine zu mehr als 70 Prozent gefüllte Protokolldatei löst die definierte Leistungsstatuswarnung aus, die wiederum den Auftrag anstößt, der das Transaktionsprotokoll sichert.

Schritt 4: Der Operator wird
per "NET SEND" benachrichtigt

Bei einem Fehler während der Bearbeitung des Auftrags, also in unserem Beispiel bei einem fehlgeschlagenen Backup-Versuch, wird zwar ein Eintrag im Windows-Ereignisprotokoll erzeugt, eine automatische Benachrichtigung erfolgt jedoch nicht. Hier kommt nun der zu Anfang angelegte Operator ins Spiel.

Dieser Operator wird bei einem Fehlschlag unseres Auftrages benachrichtigt. Dazu ist der Auftrag mit dem Befehl in Abbildung 8 zu ändern.

-- Operator benachrichtigen
EXEC msdb..sp_update_job
	@job_name = 'Log-Archivierung (Produktion)',
	@notify_level_netsend = 2 -- bei Fehler
	@notify_netsend_operator_name = 'Administrator vom Dienst'

Fazit

Der SQL-Server Agent bietet neben dem Funktionsumfang einer klassischen Jobsteuerung − Ausführung von Datenbankbefehlen zu vorgegebenen Zeitpunkten − zusätzliche Möglichkeiten, unter anderem:

• Ausführung eines Auftrages als Reaktion auf das Auftreten eines definierten Ereignisses.
• Benachrichtigung von Operatoren auf verschiedenen Kommunikationswegen.

Natürlich sollten Sie beim Stichwort Sicherung nicht nur an die Sicherung des Transaktionsprotokolls denken. Auch die Datenbank-Vollsicherung ist immens wichtig.

Andreas Jordan (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen