News zu Servicewelten
Wenn für Routineaufgaben zeitgesteuerte 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 irgendeinem Grund nicht zur Verfügung steht?
Mögliche Szenarien hierfür können sein:
Unserer Erfahrung nach ist der wohl häufigste Fall eine Umgebung, in der verschiedene Schritte auf einem SQL Server Express automatisiert werden müssen. Daher wird das Thema auch anhand einer kleinen und schlichten Sicherungslösung demonstriert.
Die erläuterte Lösung wurde bewusst simpel gehalten, um in erster Linie das grundlegenden Prinzip zu veranschaulichen. Im Praxiseinsatz empfiehlt es sich, die einzelnen Kommandos nicht als lange Parameter anzugeben, sondern stattdessen Skripte zu verwenden. In einem echten Szenario würde es darauf hinauslaufen, 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 unterbringt, welches von der SQLCmd.exe ausgelesen 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.
Außerdem häufen sich mit der Zeit entsprechend 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.
Wie können also Aktionen zur Verwaltung von Routineaufgaben ausgeführt werden, außer von Hand? Die Lösung ist naheliegender, 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 zeitgesteuerte Ausführung von wiederkehrenden 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 verarbeitet 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 verwendenden Datenbank
-U für den Benutzernamen (bei SQL-Logins im gemischten Modus)
-P für das dazugehörigen Kennwort
und entweder …
-Q für das/die SQL-Statements als direkter Parameter
oder …
-i für eine Textdatei mit SQL-Statements, welche eingelesen 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.
BACKUP DATABASE … TO DISK … WITH …
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.
Da die T‑SQL-Logik in diesem Beispiel ausgesprochen simpel ist, werden die Dateinamen der Backup-Container nicht dynamisch generiert. Daher muß dieser Aspekt durch den Taskplaner abgedeckt werden.
Will man beispielsweise nach jedem Werktag ein Vollbackup anfertigen lassen, so richtet man kurzerhand fünf Vorgänge ein, welche jeweils ein individuelles Vollbackup auslösen.
Einrichtung – exemplarisch dargestellt für einen Vorgang
Name und Beschreibung sind zwar nicht weiter von Bedeutung, sollten jedoch möglichst sinnvoll gewählt sein.
Die Einstellung zur erzwungenen 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 individuellen Parametern. Diese sind aufgrund ihrer Länge nachfolgend noch einmal vollständig abgebildet.
…aussehen.
Anmerkung
Der ein oder andere Server-Administrator mag hier einwenden, dass man auch jene fünf Einzelaufgaben zusammenfassen könnte. Das stimmt natürlich, allerdings ist der gezeigte Weg auch nur ein Bespiel und soll leicht verständlich sein. Außerdem kann man so die Sicherungs-Zeitpunkte individuell konfigurieren – etwa falls zur gleichen Zeit ein anderer Vorgang stattfindet und die Datenbank-Sicherung mit ein bis zwei Stunden Verschiebung starten soll.
Bleibt noch das Backup des Transaktionsprotokolls. Doch auch das ist keine Kunst – nur etwas aufwändiger, 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 erfolgreiches Backup, allerdings 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.
Kurze Erläuterung:
Der T‑SQL-Befehl macht nichts Anderes, als die aktuelle Systemzeit in einen ganzzahligen Wert zu konvertieren. Diese Zahl wird anschließend als Teil des Dateinamens verwendet, der für die jeweilige Backupdatei vorgesehen ist.
| der Verzeichnisname | der Dateiame |
\\FileServer\Share\ | ExampleDB1-###############.trn |
| der komplette Pfad einer .trn-Backupdatei | |
Dabei gilt: “#” steht für variable Anteile.
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, protokolliert die einzelnen Schritte sorgfältig und verschickt auf Wunsch E‑Mails über die Ergebnisse. Kurz: Er ist ein komfortabler Verwalter der einzelnen Aufgaben, aber die Arbeit machen andere. Entweder die SQL Server Engine direkt oder externe Programme, welche bereits im Windows vorhanden bzw. installiert sind.
Wie die vorgestellte 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 vorzuziehen 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 aufgegriffen und dann durch den Einsatz anderer Werkzeuge/Technologien realisiert sowie ergänzt.
Du hast verschiedene Anwendungen, die aus unterschiedlichen 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.
Share this article