Aus dem Kurs: SQL Server 2019 Grundkurs: Administration

SQL Server-Agent

Eine der wichtigen weiteren Komponenten des SQL Servers ist natürlich der SQL Server-Agent, der ungemein zum Thema Architektur und Services natürlich insofern beiträgt, dass es die Komponente für die Automatisierung ist, Architektur/Service, insofern ist es ein eigener Windows-Dienst und er ist natürlich abhängig vom SQL Server-Dienst, aber es wird in einem eigenen Windows-Konto als Dienst separat ausgeführt. Das heißt, den Agent-Dienst einzeln kann ich beenden, dann habe ich natürlich keine zeitliche Automatisierung, die läuft, also klar, wenn der Dienst beendet ist. Wenn ich den SQL Server beende, wird der Agent mit beendet, weil er abhängig vom SQL Server ist. Es ist die Komponente für die Automatisierung, sprich, sogenannte Aufträge oder Jobs, die in SQL Server ausgeführt werden, liegen hier drin, entweder, dass ich sie in Form von Wartungsplänen anlege und sie dann hier automatisch im Agent als Aufträge landen oder ich unter Aufträge im Agent halt eigene Jobs anlege. Ob das dann T-SQL-Skript oder was auch immer sind, das ist dann die Frage, was ich hier ausführen möchte. Der Agent verfügt über ein Zeitplanungsmodul, um diese Aufträge auszuführen. Ich könnte damit also meine Backups timen, Voll-Backups, vielleicht am Wochenende nächtlich die Diff-Sicherung, stündlich Transaktionsprotokoll- sicherungen. Das lässt sich realisieren. Ich kann Operatoren hinterlegen, die per E-Mail benachrichtigt werden. Warnungen einrichten zu Leistungsstatus oder kritischen Ereignissen, zum Beispiel Inkonsistenz einer Datenbank und ich kann ein Mail-Profil nutzen, um natürlich dann auch automatisiert via Mail Operatoren zu benachrichtigen, wenn also bestimmte eingerichtete Warnungen hier entweder aufschlagen oder Schwellenwerte bei Leistungsstatus-Warnungen erreicht werden. Der Agent im Detail etwas näher mal geschaut: Wir hatten gesagt, Aufträge ist das, worum es geht, also Jobs, und diese Jobs können also in Form von T-SQL sein. Ich kann also SSIS, also ETL-Prozesse mit den SQL Server Integration Services, ein eigener Windows-Dienst auch, laufen lassen, also SSIS-Pakete, wobei die Wartungspläne eben auch in Form solcher SSIS-Pakete hinterlegt sind. Ich kann PowerShell-Skripte ausführen, Commands und solche Sachen, das sind also einzelne Schritte dann in Aufträgen. Einen Job, ein Auftrag besteht also immer aus ein oder mehreren Schritten, die Ausführung selbst erfolgt im Kontext eines Benutzers. Das heißt also, wenn das Zeitplan-Modul natürlich dann, ich sag mal jetzt so, einen Job ausführt, dann ist es entweder ein T-SQL-Schritt, das wird dann im Kontext des Dienstkontos des Agent des Benutzers ausgeführt, kann aber über Proxy-Konten auch dann für die einzelnen Submodule wie PowerShell oder SSIS oder CMD dann sagen, dedizierte Benutzer, dass diese Schritte dann im Kontext dieser User ausgeführt werden. Interaktiv, also aus dem Management Studio oder getimt und letztendlich die Automatisierung. In den Eigenschaften des Agent dann so bestimmte Kriterien, die man definieren kann, also ein Mail-Profil, wenn Datenbank-E-Mail aktiv ist, was hinterlegt werden kann, damit ich dann Benutzer benachrichtige, bzw. grundsätzlich zum Agent solche Dinge wie: Wann ist eine CPU im Leerlauf? Also diese Bedingungen zu definieren, wenn die Nutzung unter so und so viel Prozent mit einer Zeitdauer von X liegt. Das wiederum ist wichtig, weil zum Beispiel ein Auftrag initiiert werden kann, indem man sagt: "Führe den doch bitte aus, wenn die CPU im lastarmen Zustand ist." Wird in der Praxis so gut wie nicht gemacht. Man timt das Ganze mehr. Das mal so einführend erstmal zum Thema: Was ist der SQL Server-Agent? Was können wir mit ihm machen? In den folgenden Filmen zeige ich Ihnen dann im Detail, wie die einzelne Sachen im Agent aussehen und verwendet werden.

Inhalt