Dieser Artikel beschreibt Erfahrungswerte hinsichtlich Problemen mit der Grösse des Transaction-Logs von Datenbanken beim Betrieb von Vertec On-Premises auf MS SQL Server. Die formulierten Massnahmen können sich auf die Wiederherstellung von Datenbanken aus Backups auswirken und sollten deshalb gut überlegt sein. Einstellungen hinsichtlich Transaction Logs an der Vertec-Datenbank sowie das Einrichten von Backups liegen beim Betrieb von Vertec On-Premises in der alleinigen Verantwortung des Kunden.

Der SQL Server von Microsoft ist so angelegt, dass sämtliche Transaktionen jeder Datenbank in ein entsprechendes Logfile geschrieben werden. Theoretisch wäre es möglich, anhand des Logfiles und einem älteren Backup der Datenbank den genauen Stand einer DB zu einem bestimmten Zeitpunkt zu rekonstruieren. Erfahrungsgemäss wird dies praktisch aber nie gemacht. Falls tatsächlich einmal ein Backup zurückgespielt werden muss, macht man das in der Regel mit einem vollständigen Backup der Datenbank. Dabei wird der Stand zum Zeitpunkt des Backups wieder hergestellt.

Die Erfahrung hat gezeigt, dass es hinsichtlich der Grösse der Logfile immer wieder zu Problemen kommt: Lässt man die Default-Einstellungen auf dem SQL Server stehen, wächst das Logfile unbeschränkt und füllt den Speicher der Festplatte. Ist diese voll, kann der SQL Server keine Transactions mehr annehmen, und der SQL Server funktioniert nicht mehr.

Um Probleme mit grossen Logfiles zu verhindern kann man die Vertec Datenbank mit dem Recovery-Modus (auf Deutsch Wiederherstellungsmodell) SIMPLE (auf Deutsch Einfach) anstatt FULL (auf Deutsch Vollständig) betreiben. Damit verhindert man, dass die Logfiles unlimitiert wachsen. Allerdings ist es auch im SIMPLE Modus absolut zentral, dass Backups der Datenbank gemacht werden. Im Folgenden werden die beiden relevanten Recovery-Modi genauer erläutert.

Das Transaction Log wächst unlimitiert und gefährdet damit die Systemstabilität, da beim Erreichen des totalen Disk-Spaces der SQL Server keine weiteren Transaktionen mehr annimmt - Vertec läuft nicht mehr. Wenn dieses Recovery Model gewählt wurde, dann muss man sich um das Management der Grösse des Transaction Logs kümmern.

Die beste Methode dabei ist wohl, dass gleich nach einem normalen Backup der Datenbank auch ein Backup des Transaction Logs durchgeführt wird. Beim Backup des Transaction Logs kann dieses gleich abgeschnitten (TRUNCATE) werden. Das ist gefahrlos möglich, da das gesamte Log zwischen 2 Backups ja nun auf dem Backup ist.

• Vorteil: man kann beim Restore (falls auch das Transaction-Log auf dem Backup ist) den Zustand der Datenbank zu jedem beliebigen Zeitpunkt wiederherstellen. Allerdings verliert man auch bei einem solchen Restore alle Änderungen, die nach diesem Zeitpunkt stattfanden.
• Nachteil: Man muss sich um das Transaction Log kümmern. Wenn man sich nicht um das Transaction Log kümmert, ist es irgendwann soweit, dass der SQL Server keine Transaktionen mehr annimmt und damit hat man einen totalen Betriebsausfall.

Nur der aktive Teil des Transaction Logs wird geführt, der inaktive Teil wird gelöscht. Ein sog. CHECKPOINT (der z.B. durch ein Backup der Datenbank gesetzt wird) trennt dabei den inaktiven vom aktiven Teil. Es wird also nur das Transaction Log seit dem letzten Backup geführt. Dieses kann aber manuell nicht gesichert und wiederhergestellt werden. Mit diesem Recovery Model steht also immer das letzte Backup zur Verfügung.

• Vorteil: Kein Management des Transaction Logs nötig. Totaler Betriebsausfall wegen Grösse des Transaction Logs unwahrscheinlich.

• Nachteil: Eine Herstellung der Datenbank ist nur zum Zeitpunkt des letzten Backups möglich.

Da normalerweise nur gesamte Backups zurückgespielt werden, reicht im Normalfall der SIMPLE-Modus aus (auch beim SIMPLE-Modell kann man nach dem letzten Backup jeden beliebigen Zeitpunkt wiederherstellen). Einstellungen hinsichtlich Transaction Logs an der Vertec-Datenbank sowie das Einrichten von Backups liegen in der alleinigen Verantwortung des Kunden.

Falls man auf einer bestehenden Datenbank schon ein sehr grosses Logfile hat und dieses verkleinern möchte, haben sich erfahrungsgemäss die beiden folgenden Möglichkeiten bewährt:

Wenn man auf dem SQL Server nur das Transaction Log sichert, kann dabei das Logfile erheblich verkleinert werden. Diese Methode ist nur möglich, wenn der Recovery-Modus der Datenbank auf FULL eingestellt ist, im SIMPLE-Modus steht diese Option nicht zur Verfügung. Beim Backup gibt man als Backup type Transaction Log an und bei den Optionen stellt man "Truncate the transaction log" ein. Das Transaction Log wird dadurch auf ein Minimum verkleinert.

Am Besten definiert man das Backup-Konzept standardmässig so, dass jedes Backup beim Recovery Mode FULL zwingend das Backup und Truncate des Transaction Logs beinhaltet.

Dieses Vorgehen ist nur möglich, wenn niemand auf die Datenbank zugreift, da sie komplett offline genommen werden muss. Vor der Durchführung sollte unbedingt ein vollständiges Backup der DB gemacht werden.

Trennen bzw. detachen Sie die Datenbank vom Server (via rechte Maustaste auf der DB > Tasks > Detach). Anschliessend muss das zur DB gehörende Logfile gelöscht oder unbenannt werden. Als nächstes wird die DB via Databases > Attach wieder hinzugefügt, in dem man zur DB gehörende Datenbankfile mit der Endung *.mdf auswählt und das Logfile mit der Endung *.ldf aus den Database details entfernt. So erstellt der SQL Server ein neues, fast leeres Logfile für die Datenbank.