News zu Servicewelten

DBA Tipp: Zeitgesteuerte Aufgaben im MS SQL Server ohne SQL Server Agent auslösen

Wenn für Routineaufgaben zeitge­steuerte Vorgänge im Hintergrund ausgelöst werden sollen kommt im Normalfall der SQL Server Agent zum Einsatz. Beispiele hierfür sind Backups oder Datenbankpflege (Index-Erneuerung). Was passiert aber außerhalb des Normalfalles, wenn der SQL Server Agent aus irgend­einem Grund nicht zur Verfügung steht?

Mögliche Szenarien hierfür können sein:

  • Der SQL Server Agent startet nicht und eine Reparaturinstallation ist nicht unmit­telbar möglich.
  • Die T‑SQL-Befehle sind in hohem Maße abhängig von den Rückgabewerten oder Ergebnissen anderer Programme.
  • Ein Vorgang soll in leicht abgewan­delter Form auf verschie­denen Datenbank-Servern (Hosts) durch­ge­führt werden.
  • Bei Verwendung eines SQL Server Express, oder auch eines SQL Server Express LocalDB.
  • Eine Ad-Hoc-Lösung auf Hosts, welche nicht aus der Ferne adminis­triert werden können und auch kein SSMS instal­liert haben.


Unserer Erfahrung nach ist der wohl häufigste Fall eine Umgebung, in der verschiedene Schritte auf einem SQL Server Express automa­ti­siert werden müssen. Daher wird das Thema auch anhand einer kleinen und schlichten Sicherungslösung demonstriert.

Die erläu­terte Lösung wurde bewusst simpel gehalten, um in erster Linie das grund­le­genden Prinzip zu veran­schau­lichen. Im Praxiseinsatz empfiehlt es sich, die einzelnen Kommandos nicht als lange Parameter anzugeben, sondern statt­dessen Skripte zu verwenden. In einem echten Szenario würde es darauf hinaus­laufen, dass die SQLCmd.exe nicht direkt, sondern innerhalb eines Windows-Befehlsskripts (.Cmd) gestartet wird. Außerdem erhöht es den Komfort spürbar, wenn man auch die T‑SQL-Befehle in einem kurzen SQL-Skript unter­bringt, welches von der SQLCmd.exe ausge­lesen wird. Dazu dient der Parameter -i gefolgt vom Pfad-/Dateinamen der SQL-Skriptdatei.

Zu beachten sind zudem folgende zwei Voraussetzungen hinsichtlich des Benutzerkontos welches verwendet wird, um das Dienstprogramm zu starten.

  1. Auf dem Server, der den Task ausführt (sprich: die SQLCmd.exe startet) muss das Benutzerkonto über die Berechtigung “Als Stapelverarbeitungsauftrag anmelden” verfügen. Darauf weißt der Aufgabenplaner beim Anlegen der Aufgabe auch hin.
  2. Im SQL Server, der die Befehle bearbeitet, muss zu jenem Benutzerkonto eine Anmeldung (Login) auf Instanzebene angelegt sein, das der Serverrolle “server­admin” angehört.

Außerdem häufen sich mit der Zeit entspre­chend viele Sicherungen an, da die gesicherten Transaktionsprotokolle ja nicht überschrieben werden (im Gegensatz zu den Vollsicherungen.) Doch dieses Problem ist nicht Bestandteil dieses DBA Tipps.

Windows Task Scheduler als Lösung

Wie können also Aktionen zur Verwaltung von Routineaufgaben ausge­führt werden, außer von Hand? Die Lösung ist nahelie­gender, als man vielleicht denkt. Denn obwohl der Aufgabenplaner (englisch “Task Scheduler”) bereits im Windows Server 2008 eine Art Generalüberholung bekam, findet er im Allgemeinen wenig Beachtung. Für die zeitge­steuerte Ausführung von wieder­keh­renden Aufgaben eines SQL Servers ist er jedoch gut geeignet, da im Alltag die meisten solcher Aufgaben simple T‑SQL-Statements sind. Und genau die kann man auch anders absetzen, wie sich gleich zeigt.

Mit Hilfe von zwei kleinen Dienstprogrammen im Lieferumfang des SQL Serves können SQL-Befehle per Kommandozeile zum SQL Server geschickt werden. Nämlich die SQLCmd.exe sowie deren PowerShell-Variante invoke-SQLCmd. Beides sind Werkzeuge, um T‑SQL-Befehle abzusetzen, welche dann vom SQL Server wie gewohnt verar­beitet werden.

Die SQLCmd.exe kennt viele Parameter, doch die wichtigsten sind:

-S für die Angabe der SQL-Serverinstanz
-d für die Angabe der zu verwen­denden Datenbank
-U für den Benutzernamen (bei SQL-Logins im gemischten Modus)
-P für das dazuge­hö­rigen Kennwort

und entweder …

-Q für das/die SQL-Statements als direkter Parameter

oder …

-i für eine Textdatei mit SQL-Statements, welche einge­lesen wird.

Ausgerüstet mit diesem Werkzeug kann man sich eine schlichte aber funktionale Lösung schaffen, um sowohl Datenbanken als auch Transaktionsprotokolle eines SQL Servers zu sichern – ohne den SQL Server Agent zu verwenden.

Vorgehensweise am Beispiel eines Backups

Wenn man sich bewusst macht, dass die Vollsicherung einer Datenbank nichts weiter benötigt, als ein … 
BACKUP DATABASE … TO DISK … WITH …
… versteht man schnell, dass es nur darauf ankommt, einen solchen Befehl irgendwie an den SQL Server abzusetzen. Und genau da setzt das genannte Dienstprogramm an. Denn wenn man die dafür nötigen Paramter angibt, kann man durch … 
SQLCmd.exe   -S ExampleServer\MSSQL   -Q "BACKUP DATABASE [ExampleDB] TO DISK = '\\FilesServer\Share\ExampleBackup.bak' WITH NAME='Full-Backup-of-ExampleDB', CHECKSUM;"

… im Grunde das Gleiche erreichen, was auch ein “echter” SQL Server Agent Job tun würde.

Anmerkung für SSMS-Benutzer

Hierdurch wird sehr gut deutlich, dass eine Datenbank-Sicherung keine “interne Aktion” des SQL Server Agents ist, sondern lediglich eine SQL-Anweisung. Besonders den Fans von Wartungsplänen sei an ’s Herz gelegt, sich dies einmal klar zu machen.

Es spricht also nichts dagegen, wenn der Windows Aufgabenplaner diesen Programmaufruf (mitsamt Parametern) übernimmt. Natürlich muss man bei einer solchen Lösung einige zusätz­liche Details beachten. Dazu bitte den Hinweis am Ende beachten. 

Teil 1 – Komplettsicherung

Da die T‑SQL-Logik in diesem Beispiel ausge­sprochen simpel ist, werden die Dateinamen der Backup-Container nicht dynamisch generiert. Daher muß dieser Aspekt durch den Taskplaner abgedeckt werden.
Will man beispiels­weise nach jedem Werktag ein Vollbackup anfer­tigen lassen, so richtet man kurzerhand fünf Vorgänge ein, welche jeweils ein indivi­du­elles Vollbackup auslösen.

Einrichtung – exempla­risch darge­stellt für einen Vorgang

Name und Beschreibung sind zwar nicht weiter von Bedeutung, sollten jedoch möglichst sinnvoll gewählt sein.

Die Einstellung zur erzwun­genen Beendigung des Tasks ist optional und kann auch an die realen Verhältnisse angepasst werden. Normalerweise sollte jedoch auch ein Vollbackup in circa vier Stunden abgeschlossen sein.

Die Aktion besteht im Aufruf des Programms mit indivi­du­ellen Parametern. Diese sind aufgrund ihrer Länge nachfolgend noch einmal vollständig abgebildet.

Wenn alle fünf Sicherungen (ergo: Vorgänge) korrekt vorbe­reitet wurden, sollte es so … 
… bezie­hungs­weise so … 

…aussehen.

Anmerkung

Der ein oder andere Server-Administrator mag hier einwenden, dass man auch jene fünf Einzelaufgaben zusam­men­fassen könnte. Das stimmt natürlich, aller­dings ist der gezeigte Weg auch nur ein Bespiel und soll leicht verständlich sein. Außerdem kann man so die Sicherungs-Zeitpunkte indivi­duell konfi­gu­rieren – etwa falls zur gleichen Zeit ein anderer Vorgang statt­findet und die Datenbank-Sicherung mit ein bis zwei Stunden Verschiebung starten soll.

Teil 2 – Transaktionsprotokoll-Sicherungen

Bleibt noch das Backup des Transaktionsprotokolls. Doch auch das ist keine Kunst – nur etwas aufwän­diger, da hierbei die Dateinamen dynamisch zur Laufzeit generiert werden sollten. Sonst würde bei jedem neuen Backup das vorherige Backup überschrieben. Zwar ist dies keine Bedingung für ein erfolg­reiches Backup, aller­dings will man im Echtbetrieb sicherlich nicht nur ein Backup des Transaktionsprotokolls aufheben.

Um also diesen Aspekt abzubilden genügt eine kleine Änderung am T‑SQL-Befehl (sprich: der Teil hinter dem ‑Q-Parameter), sowie ein anderer Zeitplan. Im Regelfall werden Transaktionsprotokolle drei bis vier Mal stündlich gesichert.

Einrichtung

Diese Angaben dienen nur der Übersichtlichkeit.

Beim Auslöser (Trigger) muß diesmal auch eine Wiederholung gesetzt werden.

Auch hier ist der komplette Befehl im Bild nicht erkennbar und dafür im folgenden Bild in seiner vollen Länge dargestellt. 
Fertig einge­richtet sollte man Folgendes sehen: 

Kurze Erläuterung:

Der T‑SQL-Befehl macht nichts Anderes, als die aktuelle Systemzeit in einen ganzzah­ligen Wert zu konver­tieren. Diese Zahl wird anschließend als Teil des Dateinamens verwendet, der für die jeweilige Backupdatei vorge­sehen ist.

der Verzeichnisnameder Dateiame
\\FileServer\Share\ExampleDB1-###############.trn
der komplette Pfad einer .trn-Backupdatei

Dabei gilt: “#” steht für variable Anteile.

Fazit

Auch wenn es vielleicht auf den ersten Blick so aussehen mag, aber der SQL Server Agent erledigt die Aufgaben nicht selbst. Er schaut auf die Uhr, setzt die Dinge in Gang, proto­kol­liert die einzelnen Schritte sorgfältig und verschickt auf Wunsch E‑Mails über die Ergebnisse. Kurz: Er ist ein komfor­tabler Verwalter der einzelnen Aufgaben, aber die Arbeit machen andere. Entweder die SQL Server Engine direkt oder externe Programme, welche bereits im Windows vorhanden bzw. instal­liert sind.

Wie die vorge­stellte Lösung zeigt, ist man jedoch nicht auf den SQL Server Agent angewiesen, falls man bestimmte Vorgänge im SQL Server auslösen will. Natürlich wird niemand bestreiten, dass die Verwendung des SQL Server Agents wann immer es geht vorzu­ziehen ist. Allerdings gibt es im Alltag auch hin und wieder Anwendungsfälle, in denen man tatsächlich auf eine Alternative angewiesen ist. In einem weiteren DBA Tipp wird das hier gezeigte Beispiel erneut aufge­griffen und dann durch den Einsatz anderer Werkzeuge/Technologien reali­siert sowie ergänzt.

Du hast verschiedene Anwendungen, die aus unter­schied­lichen Gründen Vorgänge in deinen MS SQL Servern auslösen müssen, weißt jedoch nicht wie?

Ruf uns unter +49.371.909515–100 an. Unsere Spezialisten helfen dir gern weiter.

Hier findest du weitere inter­es­sante DBA Tipps oder Posts zum Thema SQL Server aus unserem News und Insights Bereich. 
icon-arrow_right_medium-violet-blue.svg

Share this article

Facebook 
Twitter 
LinkedIn 
XING 
WhatsApp 
Email