SQL Server 2008 Internals - Microsoft Press

Kapitel 4

Kalen Delaney

Ki K m al b e A M da erl n D ic m y e ro L so Ma . T lane IS ft ch rip y, BN SQ a p P n C a 97 L S ic u on ul 8- er nd or S. 3- ve B C R 86 r e un an 64 20 n N ni da 5- 08 e ng l, 65 In va ha 6- ter re m, 3 na z ls

Protokollierung und Wiederherstellung

In diesem Kapitel: Grundlagen von Transaktionsprotokollen

208

Änderungen der Protokollgröße

214

Sichern und Wiederherstellen einer Datenbank

225

Zusammenfassung

237

207

208

Kapitel 4:


In Kapitel 3, »Datenbanken und Datenbankdateien«, habe ich die Datendateien behandelt, in denen die Informationen von SQL Server-Datenbanken aufbewahrt werden. Daneben hat jede Datenbank jedoch auch mindestens eine Datei, in der das Transaktionsprotokoll gespeichert wird. Ich habe in Kapitel 3 die Transaktionsprotokolle von SQL Server und die Protokolldateien erwähnt, aber nicht genau erklärt, inwiefern sich Transaktionsprotokolldateien von Datendateien unterscheiden und wie SQL Server sie verwendet. In diesem Kapitel zeige ich die Struktur der Protokolldateien auf und beschreibe, wie Transaktionsinformationen darin aufgezeichnet werden. Außerdem erläutere ich, wie Protokolldateien wachsen und wie Sie sie verkleinern können. Darüber hinaus sehen wir uns an, wie Protokolldateien bei der Sicherung und Wiederherstellung eingesetzt werden und welchen Einfluss das Wiederherstellungsmodell einer Datenbank auf sie hat.

Grundlagen von Transaktionsprotokollen Ki K m al b e A M da erl n D ic m y e ro L so Ma . T lane IS ft ch rip y, BN SQ a p P n C a 97 L S ic u on ul 8- er nd or S. 3- ve B C R 86 r e un an 64 20 n N ni da 5- 08 e ng l, 65 In va ha 6- ter re m, 3 na z ls

Transaktionsprotokolle zeichnen Änderungen an einer Datenbank auf und speichern genügend Informationen, damit SQL Server die Datenbank wiederherstellen kann. Diese Wiederherstellung (recovery) erfolgt jedes Mal, wenn die SQL Server-Instanz gestartet wird, und kann außerdem bei jeder Wiederherstellung (restore) einer Datenbank oder eines Protokolls von einer Sicherung auftreten. Bei dieser Form der Wiederherstellung werden die Datendateien mit dem Protokoll abgestimmt. Jegliche Änderungen an den Daten, für die laut Protokoll ein Commit erfolgt ist, müssen in den Datendateien erscheinen, während Änderungen ohne Commit nicht darin vorkommen dürfen. Das Protokoll enthält auch die erforderlichen Informationen, um eine Operation mit einem Rollback zurückzunehmen, falls SQL Server vom Client die Anforderung erhält, eine Transaktion rückgängig zu machen (mit dem Befehl ROLLBACK TRAN), oder falls ein Fehler, z.B. ein Deadlock, intern zu einem Rollback führt. HINWEIS In der englischen Terminologie wird zwischen restore (der Wiederherstellung von einer Sicherung) und recovery (dem automatischen Abgleich beim Neustart oder nach der Wiederherstellung von einer Sicherung) unterschieden. In der offiziellen deutschen Terminologie von SQL Server sind beide Begriffe mit Wiederherstellung wiedergegeben.

Physisch besteht das Transaktionsprotokoll aus mindestens einer Datei, die beim Erstellen oder Ändern einer Datenbank mit dieser verknüpft werden. Vorgänge, die die Datenbank bearbeiten, schreiben Einträge in das Transaktionsprotokoll, die die durchgeführten Änderungen beschreiben (samt der Nummer der betroffenen Datenseiten) sowie die hinzugefügten oder entfernten Datenwerte, die Transaktion, in deren Rahmen die Änderungen erfolgten, und Datum und Uhrzeit zu Anfang und Ende der Transaktion angeben. Auch beim Auftreten bestimmter interner Ereignisse, z.B. beim Erreichen von Prüfpunkten, schreibt SQL Server Einträge ins Protokoll. Jedes Protokoll trägt eine Protokollfolgenummer (Log Sequence Number, LSN), die garantiert eindeutig ist. Alle Protokolleinträge zu einer Transaktion sind verknüpft, sodass sich zum Rückgängigmachen (Rollback) und zur Wiederholung (bei der Systemwiederherstellung) alle Teile der Transaktion leicht aufspüren lassen. Der Puffer-Manager sorgt dafür, dass zuerst das Transaktionsprotokoll und dann die Änderungen an der Datenbank geschrieben werden (vorausschauende oder Write-Ahead-Protokollierung). Dies ist möglich, da SQL Server die aktuelle Position im Protokoll anhand der LSN nachverfolgt. Bei jeder Seitenänderung wird die LSN des Protokolleintrags für diesen Vorgang in den Header der Datenseite geschrieben. Modifizierte Seiten können nur dann auf die Festplatte geschrieben werden, wenn die LSN auf der Seite kleiner oder gleich

Grundlagen von Transaktionsprotokollen

209

der LSN für den zuletzt im Protokoll erfassten Eintrag ist. Der Puffer-Manager stellt auch sicher, dass die Protokollseiten in einer bestimmten Reihenfolge geschrieben werden, damit unabhängig davon, wann ein Systemfehler auftritt, stets klar ist, welche Protokollblöcke anschließend verarbeitet werden müssen.


Die Protokolleinträge für eine Transaktion werden auf die Festplatte geschrieben, bevor die Commitbestätigung an den Clientprozess gesendet wird, aber die eigentlichen Datenänderungen sind möglicherweise noch nicht physisch in die Datenseiten geschrieben worden. Die Schreibvorgänge im Protokoll erfolgen zwar asynchron, doch zum Zeitpunkt des Commits muss der Thread darauf warten, dass die Schreibvorgänge bis zu dem Punkt abgeschlossen sind, an dem der Commiteintrag in das Protokoll für die Transaktion geschrieben wurde. (SQL Server muss auf den Schreibvorgang für den Commiteintrag warten, um sicher zu sein, dass sich die relevanten Protokolleinträge sicher auf der Festplatte befinden.) Die Schreibvorgänge auf den Datenseiten erfolgen vollständig asynchron, d.h., sie werden dem Betriebssystem nur angekündigt, und SQL Server prüft später, ob sie abgeschlossen sind. Sie müssen nicht sofort durchgeführt werden, da das Protokoll alle Informationen enthält, um den Vorgang in dem Fall zu rekonstruieren, dass der Strom ausfällt oder das System abstürzt, bevor die Schreibvorgänge abgeschlossen sind. Falls das System jedes Mal auf den Abschluss einer E/A-Anforderung warten müsste, bevor es fortfahren kann, würde es sehr viel langsamer. Bei der Protokollierung werden Anfang und Ende der einzelnen Transaktionen gekennzeichnet (sowie evtl. in der Transaktion verwendete Sicherungspunkte). Zwischen der Anfangs- und Endmarkierung liegen die Informationen über die Änderungen an den Daten. Sie können die Form von »Vorher/Nachher«-Daten annehmen, aber auch auf die durchgeführte Operation verweisen, sodass sich die Wertänderungen nachvollziehen lassen. Das Ende einer typischen Transaktion wird mit einem Commiteintrag gekennzeichnet, was anzeigt, dass sich die Auswirkungen der Transaktion in den Datendateien der Datenbank wiederfinden müssen. Eine Transaktion, die aufgrund eines expliziten Rollbacks oder eines Ressourcenmangels (z.B. nicht ausreichendem Speicher) während der normalen Ausführung abgebrochen wurde (nicht durch einen Neustart des Systems), hebt ihre Operationen wieder auf, indem Sie Änderungen durchführt, die die ursprünglichen Bearbeitungen rückgängig machen. Einträge für solche Änderungen werden ebenfalls ins Protokoll geschrieben und dort als Kompensierungsprotokolleinträge gekennzeichnet. Wie bereits erwähnt, gibt es zwei Arten der Wiederherstellung, die beide dafür sorgen, dass Protokoll und Daten in Übereinstimmung sind. Die Neustartwiederherstellung wird bei jedem Start von SQL Server für jede Datenbank ausgeführt, da alle Datenbanken ihre eigenen Transaktionsprotokolle haben. Das SQL Server-Fehlerprotokoll zeichnet den Fortschritt der Neustartwiederherstellung auf und gibt an, wie viele Transaktionen in den einzelnen Datenbanken wiederhergestellt (Rollforward) und wie viele zurückgesetzt (Rollback) wurden. Dies wird manchmal auch Absturzwiederherstellung genannt, da ein Absturz oder eine unerwartete Beendigung des SQL Server-Dienstes die Wiederherstellung nach dem Neustart des Dienstes erfordert. Wurde der Dienst ohne offene Transaktionen in irgendeiner Datenbank ordnungsgemäß heruntergefahren, ist beim Neustart nur eine minimale Wiederherstellung nötig. In SQL Server 2008 erfolgt die Neustartwiederherstellung für mehrere Datenbanken parallel in jeweils eigenen Threads. Die andere Form, die Medienwiederherstellung, wird auf Anforderung durchgeführt, wenn eine Wiederherstellung von einer Sicherung erfolgt. Dadurch wird sichergestellt, dass sich die Daten aller mit Commit abgeschlossenen Transaktionen in der Sicherung des Transaktionsprotokolls widerspiegeln und sich nicht abgeschlossene Transaktionen auch nicht in den Daten zeigen. Über die Medienwiederherstellung spreche ich weiter hinten in diesem Kapitel.

210

Kapitel 4:


Beide Arten der Wiederherstellung müssen zwei verschiedene Fälle handhaben: wenn Transaktionen im Protokoll mit Commit abgeschlossen sind, aber noch nicht in die Datendateien geschrieben wurden, und wenn Änderungen in den Datendateien nicht auf per Commit abgeschlossene Transaktionen zurückgehen. Diese beiden Situationen können dadurch entstehen, dass Einträge für einen Commit bei jedem Commit einer Transaktion in die Protokolldateien auf der Festplatte geschrieben werden, die geänderten Datenseiten aber völlig asynchron davon auf die Festplatte übertragen werden, wenn in der Datenbank ein Prüfpunkt erscheint. Wie ich in Kapitel 1, »Architektur und Konfiguration von SQL Server 2008«, erwähnt habe, können Datenseiten auch zu anderen Zeitpunkten auf die Festplatte geschrieben werden, aber bei den regelmäßig auftretenden Prüfpunktvorgängen kann SQL Server sicher sein, dass alle geänderten Seiten dort gelandet sind. Prüfpunktvorgänge schreiben auch Protokolleinträge von laufenden Transaktionen auf die Festplatte, da solche zwischengespeicherten Protokolleinträge ebenfalls als modifiziert gelten.


Wenn der SQL Server-Dienst nach dem Commit einer Transaktion, aber vor dem Schreiben der Daten in die Datenseiten beendet wird, muss die Transaktion beim Neustart von SQL Server und der damit einhergehenden Wiederherstellung durch ein Rollforward rekonstruiert werden. SQL Server erledigt dies durch die erneute Anwendung der Änderungen, die im Transaktionsprotokoll verzeichnet sind. Alle Transaktionen, für die ein Rollforward erforderlich ist, werden zuerst verarbeitet (auch wenn manche von ihnen in der nächsten Phase wieder rückgängig gemacht werden müssen). Dies ist die Rollforwardphase der Wiederherstellung. Wenn ein Prüfpunkt vor dem Commit einer Transaktion auftritt, werden die noch nicht per Commit bestätigten Änderungen auf die Festplatte geschrieben. Wird der SQL Server-Dienst dann beendet, bevor ein Commit durchgeführt werden kann, findet der Wiederherstellungsvorgang in den Datendateien Änderungen aufgrund von nicht mit Commit abgeschlossenen Transaktionen und muss sie zurücksetzen, indem er die im Transaktionsprotokoll aufgezeichneten Änderungen rückgängig macht. Diese Aufhebung aller nicht abgeschlossenen Transaktionen wird Rollbackphase der Wiederherstellung genannt. HINWEIS Ich verwende den Begriff Wiederherstellung (recovery) im Folgenden im Sinne des Vorgangs, der beim Systemstart auftritt, was auch die häufigste Form dieses Abgleichs ist. Dieser Vorgang tritt jedoch auch als letzter Schritt bei der Wiederherstellung (restore) einer Datenbank aus einer Sicherung oder beim Anfügen einer Datenbank auf und kann auch manuell erzwungen werden. Außerdem wird diese Form der Wiederherstellung auch beim Erstellen eines Datenbanksnapshots, bei der Datenbankspiegelung und beim Wechsel zu einem Spiegel durchgeführt.

Weiter hinten in diesem Kapitel behandle ich einige besondere Aspekte des Abgleichs bei einer Datenbankwiederherstellung, nämlich die drei Wiederherstellungsmodelle, die Sie mit ALTER DATABASE festlegen können, und die Möglichkeit, eine benannte Markierung in das Protokoll einzufügen, um einen bestimmten Punkt zu kennzeichnen, bis zu dem die Wiederherstellung erfolgen soll. In den folgenden Abschnitten geht es um die Wiederherstellung (im Sinne des Abgleichs von Daten und Protokoll, also recovery) im Allgemeinen. Die Ausführungen gelten sowohl für den Abgleich beim Neustart des SQL Server-Dienstes als auch für den am Ende der Wiederherstellung einer Datenbank von einer Sicherung.

Die Phasen der Wiederherstellung Während der Wiederherstellung werden nur Änderungen untersucht, die seit dem letzten Prüfpunkt vorgenommen wurden oder im Gange waren, um zu bestimmen, ob sie rekonstruiert oder rückgängig gemacht werden müssen. Alle vor dem letzten Prüfpunkt entweder durch Commit oder Rollback abgeschlossenen Transaktionen werden bereits korrekt in den Datenseiten widergespiegelt, sodass sie während der Wiederherstellung unberücksichtigt bleiben können.

211



Der Wiederherstellungsalgorithmus besteht aus drei Phasen, in denen es immer um den letzten Prüfpunkteintrag im Transaktionsprotokoll geht. Eine Darstellung dieser Phasen sehen Sie in Abbildung 4.1. 1. Phase 1: Analyse Die erste Phase geht vom letzten Prüfpunkteintrag im Transaktionsprotokoll aus vorwärts. Bei diesem Durchgang wird eine Tabelle der modifizierten Seiten (Dirty Page Table, DPT) erstellt, in der die Seiten verzeichnet sind, die bei der Beendigung von SQL Server möglicherweise modifiziert waren. Auch eine Tabelle der aktiven Transaktionen wird angelegt. Sie enthält die Transaktionen, die bei der Beendigung von SQL Server noch nicht mit Commit abgeschlossenen waren. 2. Phase 2: Rollforward In dieser Phase kehrt die Datenbank zu dem Zeitpunkt zurück, den Sie bei der Beendigung des SQL Server-Dienstes hatte. Ausgangspunkt für diesen vorwärts gerichteten Durchgang ist der Beginn der ältesten noch nicht mit Commit abgeschlossenen Transaktion. Die kleinste LSN in der DPT markiert den frühesten Zeitpunkt, für den SQL Server eine Operation auf einer Seite wiederholen muss. Damit die notwendigen Sperren erworben werden können, müssen jedoch alle protokollierten Operationen seit dem Beginn der ältesten offenen Transaktion rekonstruiert werden. (Vor SQL Server 2005 wurden dazu nur Zuweisungssperren benötigt. In SQL Server 2005 und später müssen jedoch alle Sperren für die offenen Transaktionen erneut erworben werden.) 3. Phase 3: Rollback In dieser Phase wird die Liste der aktiven Transaktionen genutzt (also der Transaktionen, für die bei der Beendigung von SQL Server noch kein Commit ausgeführt war), die in Phase 1 (Analyse) erstellt wurde. Alle diese aktiven Transaktionen werden einzeln durch ein Rollback zurückgenommen. SQL Server im Transaktionsprotokoll folgt den Verknüpfungen zwischen den verschiedenen Einträgen für eine Transaktion. Jede der bei der Beendigung von SQL Server offene Transaktion wird aufgehoben, sodass sich keine der durch sie verursachten Änderungen in der Datenbank zeigen.

Analyse

Phase

Rollforward

(Erwerb von Sperren für aktive Transaktionen)

Rollback

Protokollbeginn

Älteste Transaktion

Prüfpunkt Kleinste Wieder- Absturz herstellungs-LSN Protokoll/Zeit

Abbildung 4.1 Die drei Phasen des Widerherstellungsvorgangs von SQL Server

SQL Server verwendet das Protokoll, um die vorgenommenen Datenänderungen und die bei der Bearbeitung der Objekte angewandten Sperren nachzuverfolgen. Dadurch ist die so genannte schnelle Wiederherstellung beim Neustart von SQL Server möglich (nur in der Enterprise und der Developer Edition). Bei der schnellen Wiederherstellung ist die Datenbank sofort nach dem Abschluss der Rollforwardphase wieder verfügbar. Die Sperren, die bei den ursprünglichen Änderungen Verwendung fanden, können wieder erworben werden, um andere Prozesse am Zugriff auf die Daten zu hindern, deren Änderungen noch rückgängig gemacht werden müssen. Alle anderen Daten in der Datenbank dagegen sind zugänglich. Bei der Medienwiederherstellung ist die schnelle Wiederherstellung nicht möglich, aber bei der Wiederherstellung für die Datenbankspiegelung, bei der es sich um ein Mittelding der Medien- und der Neustartwiederherstellung handelt.

212

Kapitel 4:


SQL Server verwendet mehrere Threads, um die Wiederherstellung für mehrere Datenbanken gleichzeitig durchzuführen, damit Datenbanken mit höheren Kennungen nicht warten müssen, bis alle anderen Datenbanken mit niedrigeren Kennungen vollständig wiederhergestellt sind, bevor sie selbst an der Reihe sind.

Seiten-LSNs und Wiederherstellung


Im Header jeder Datenbankseite befindet sich eine LSN, die den Ort im Transaktionsprotokoll angibt, an dem sich der letzte Protokolleintrag zu Änderungen an Zeilen auf der Seite befindet. Jeder Protokolleintrag für Änderungen an einer Datenseite weist zwei LSNs auf: Neben der für den Protokolleintrag selbst verzeichnet er auch die LSN, die sich auf der Datenseite befand, bevor die in dem Eintrag vermerkte Änderung eintrat. Während der Wiederholung der Transaktionen in der Rollforwardphase werden die LSNs der einzelnen Protokolleinträge mit den LSNs der Datenseiten verglichen, auf denen die im Eintrag vermerkten Änderungen durchgeführt wurden. Ist die Seiten-LSN gleich der LSN der früheren Seite im Protokolleintrag, wird die im Protokolleintrag vermerkte Operation erneut ausgeführt. Sollte die LSN auf der Seite dagegen größer oder gleich der LSN des Protokolleintrags sein, führt SQL Server die Rollforwardoperation nicht aus. Diese beiden Möglichkeiten sehen Sie in Abbildung 4.2. Die LSN auf der Seite kann nicht zwischen der LSN für den Eintrag und dem Wert für die frühere LSN liegen.

Seite 1:25

Datenseite

LSN: 2:200:7

Op: Update... Seite 1:25 Zeile: 4 LSN: 2:210:6

Transaktionsprotokoll

Früh. LSN 2:200:7

Der Protokolleintrag mit LSN 2:210:6 verweist auf Seite 1:25, die eine LSN von 2:200:7 hat, was kleiner als die Protokoll-LSN ist. Die im Protokolleintrag vermerkte Aktualisierung muss also nachvollzogen werden.

Seite 1:42

Datenseite LSN: 2:300:10

Op: Update... Seite 1:42 Zeile: 10 LSN: 2:290:6

Transaktionsprotokoll

Früh. LSN 2:260:3

Der Protokolleintrag mit LSN 2:290:6 verweist auf Seite 1:42, die eine LSN von 2:300:10 hat. Die Seiten-LSN ist größer als die Protokoll-LSN. Daher wurde diese Seite nach der angezeigten Transaktion auf die Festplatte geschrieben, weshalb sie nicht nachvollzogen werden muss.

Abbildung 4.2 Die LSNs werden verglichen, um zu entscheiden, ob der Protokolleintrag bei der Wiederherstellung verarbeitet werden muss

Da die Wiederherstellung den letzten Prüfpunkteintrag im Protokoll findet (sowie die Transaktionen, die zu diesem Zeitpunkt noch aktiv waren) und von dort aus vorwärts schreitet, ist die Wiederherstellungszeit kurz, und alle mit Commit abgeschlossenen Änderungen vor dem Prüfpunkt können aus dem Protokoll entfernt


213

oder archiviert werden. Anderenfalls würde die Wiederherstellung lange dauern und die Transaktionsprotokolle könnten unverhältnismäßig groß werden. Ein Transaktionsprotokoll kann nicht hinter der letzten offenen Transaktion abgeschnitten werden, gleichgültig, wie viele Prüfpunkte seit diesem Zeitpunkt gesetzt worden sind und wie viele andere Transaktionen gestartet und abgeschlossen wurden. Solange eine Transaktion offen ist, muss das Protokoll aufbewahrt werden, da es noch nicht klar ist, ob die Transaktion jemals abgeschlossen wird. Möglicherweise muss diese Transaktion irgendwann mit einem Rollback zurückgenommen oder mit einem Rollforward rekonstruiert werden. HINWEIS Das Abschneiden des Transaktionsprotokolls ist eine logische Operation, die lediglich Teile des Protokolls als nicht mehr notwendig markiert, sodass der Platz dafür wiederverwendet werden kann. Dies ist kein physischer Vorgang, weshalb die Größe der Protokolldateien auf der Festplatte dadurch auch nicht verringert wird. Dazu müssen Sie die Dateien verkleinern.

Lesen des Protokolls


Manche SQL Server-Administratoren haben erlebt, dass sich das Transaktionsprotokoll anscheinend nicht abschneiden ließ, selbst nachdem es gesichert wurde. Dieses Problem liegt häufig daran, dass ein Benutzer eine Transaktion öffnet und sie dann vergisst. Aus diesem Grund sollten Sie als Anwendungsentwickler dafür sorgen, dass Transaktionen kurz sind. Ein weiterer möglicher Grund dafür, dass sich das Protokoll nicht abschneiden lässt, kann eine Tabelle sein, für die eine Transaktionsreplikation erfolgt, während der Protokollleser der Replikation noch nicht alle relevanten Protokolleinträge verarbeitet hat. Diese Situation tritt jedoch weniger häufig ein, da beim Einsatz des Protokolllesers gewöhnlich nur eine Wartezeit von wenigen Sekunden auftritt. Mit DBCC OPENTRAN können Sie nach der frühesten offenen Transaktion oder der ältesten replizierten Transaktion suchen, die noch nicht verarbeitet ist, und dann Korrekturmaßnahmen ergreifen (indem Sie z.B. den störenden Prozess beenden oder die gespeicherte Prozedur sp_repldone ausführen, um die replizierten Transaktionen zu entfernen). Probleme bei der Transaktionsverwaltung und einige mögliche Lösungen beschreibe ich in Kapitel 10, »Transaktionen und Parallelverarbeitung«. Die Verkleinerung des Protokolls ist Thema des nächsten Abschnitts.

Das Protokoll enthält zwar Einträge über alle Änderungen an einer Datenbank, es ist aber nicht als Überwachungswerkzeug gedacht, sondern dient dazu, die Wiederherstellbarkeit bei Anweisungs- oder Systemfehlern zu garantieren, und Systemadministratoren die Möglichkeit zu geben, eine Sicherung der Änderungen an einer SQL Server-Datenbank zu erstellen. Wenn Sie eine lesbare Aufzeichnung der Änderungen an einer Datenbank brauchen, müssen Sie eine eigene Überwachung durchführen. Dies können Sie durch eine Ablaufverfolgung von SQL Server-Aktivitäten, durch die Verwendung von SQL Server Profiler und durch die Nachverfolgungsmechanismen von SQL Server erreichen, die in Kapitel 2, »Änderungsnachverfolgung, Ablaufverfolgung und erweiterte Ereignisse«, beschrieben wurden. HINWEIS Vielleicht kennen Sie Drittanbieterprogramme, die Transaktionsprotokolle lesen und alle in einer Datenbank erfolgten Operationen anzeigen können und Ihnen sogar erlauben, beliebige dieser Vorgänge rückgängig zu machen. Die Entwickler dieser Programme haben Zehntausende von Stunden damit zugebracht, sich Dumps von Transaktionsprotokollen auf Byteebene anzusehen und mit der Ausgabe des undokumentierten Befehls DBCCLOG zu vergleichen. Nachdem das erste Produkt dieser Art auf den Markt kam, hat Microsoft mit den Entwicklern zusammengearbeitet, was das Leben für sie bei den nachfolgenden Versionen einfacher machte. Für SQL Server 2008 gibt es solche Programme allerdings noch nicht.

214

Kapitel 4:


Auch wenn Sie meinen, dass es interessant oder vielleicht sogar nützlich sein könnte, die Transaktionsprotokolle direkt zu lesen, so enthalten sie doch gewöhnlich viel zu viel Informationen. Wenn Sie schon im Vorfeld wissen, dass Sie nachverfolgen möchten, was Ihr SQL Server-Computer im Einzelnen tut, ist es besser, wenn Sie eine Ablaufverfolgung mit den entsprechenden Filtern definieren, um nur die für Sie sinnvollen Informationen zu erfassen.

Änderungen der Protokollgröße Unabhängig davon, wie viele physische Dateien für das Transaktionsprotokoll vorhanden sind, behandelt SQL Server es stets als zusammenhängenden Stream. Wenn Sie z.B. mit dem Befehl DBCC SHRINKDATABASE (siehe Kapitel 3) bestimmen, wie stark sie das Protokoll verkleinern können, werden die Protokolldateien nicht einzeln betrachtet, sondern das gesamte Protokoll.


Virtuelle Protokolldateien Das Transaktionsprotokoll für eine Datenbank wird in Form einer Reihe von virtuellen Protokolldateien (Virtual Log File, VLF) gehandhabt, deren Größe von SQL Server intern auf der Grundlage der Gesamtgröße aller Protokolldateien und dem Wachstumsinkrement bei Vergrößerungen bestimmt wird. Bei der Erstellung hat ein Transaktionsprotokoll stets zwischen 2 und 16 VLFs. Beträgt die Dateigröße 1 MB oder weniger, dividiert SQL Server die Größe der Protokolldatei durch die VLF-Mindestgröße (31 * 8 KB), um die Anzahl der VLFs zu ermitteln. Bei einer Protokolldateigröße zwischen 1 und 64 MB teilt SQL Server das Protokoll in vier VLFs auf. Ist die Datei größer als 64 MB, aber kleiner oder gleich 1 GB, werden 8 VLFs erstellt. Dateien mit mehr als 1 GB erhalten 16 VLFs. Bei der Vergrößerung wird dieselbe Formel angewendet, um zu bestimmen, wie viele neue VLFs hinzugefügt werden müssen. Ein Protokoll wächst stets in Einheiten von ganzen VLFs und kann auch nur zu einer VLF-Grenze hin verkleinert werden. (Abbildung 4.3 zeigt eine physische Protokolldatei mit mehreren VLFs.) Eine VLF kann folgende vier Zustände annehmen: 쐍 Aktiv

Der aktive Teil des Protokolls beginnt bei der kleinsten LSN für eine aktive (nicht mit Commit abgeschlossene) Transaktion und endet hinter der letzten geschriebenen LSN. VLFs, die irgendeinen Teil des aktiven Protokolls enthalten, werden selbst als aktiv bezeichnet. (Nicht verwendeter Platz im physischen Protokoll gehört zu keiner VLF.) In Abbildung 4.3 sehen Sie zwei aktive VLFs.

쐍 Wiederherstellbar

Der Teil des Protokolls vor der ältesten aktiven Transaktion wird nur dazu gebraucht, um eine Folge von Protokollsicherungen zur Wiederherstellung (restore) der Datenbank in einen früheren Zustand zu unterhalten.

쐍 Wiederverwendbar

Wenn keine Sicherungen von Transaktionsprotokollen geführt werden oder wenn Sie das Protokoll bereits gesichert haben, werden VLFs vor der ältesten aktiven Transaktion nicht mehr benötigt und können wiederverwendet werden. Beim Abschneiden oder Sichern des Transaktionsprotokolls werden wiederherstellbare VLFs in wiederverwendbare umgewandelt. Um zu bestimmen, welche VLFS wiederverwendbar sind, werden zu den aktiveren Transaktionen nicht nur die offenen gezählt. Die früheste aktive Transaktion kann auch eine für die Replikation gekennzeichnete, aber noch nicht verarbeitete Transaktion sein, der Anfang eines Protokollsicherungsvorgangs oder der Beginn eines der von SQL Server regelmäßig durchgeführten internen Diagnosescans.

215


쐍 Nicht verwendet

Eine oder mehr VLFs am Ende des physischen Protokolls sind möglicherweise noch nicht verwendet worden, wenn noch nicht genügend Aktivitäten protokolliert wurden oder wenn frühere VLFS wiederverwendet worden sind.

VLF 1

VLF 2

VLF 3

VLF 4

Nicht verwendeter Platz

Physische Protokolldatei Abgeschnitten

Kleinste Letzter Ende des logiLSN Prüfpunkt schen Protokolls Aktuelle Position im Protokoll


Beginn des logischen Protokolls (erste aktive VLF)

Abbildung 4.3 Mehrere VLFs in einer physischen Protokolldatei

Überwachen von virtuellen Protokolldateien

Die Haupteigenschaften von virtuellen Protokolldateien können Sie überwachen, indem Sie den undokumentierten Befehl DBCC LOGINFO ausführen. Er nimmt keine Parameter entgegen, weshalb Sie ihn in der Datenbank ausführen müssen, zu der Sie Informationen wünschen. Für jede VLF wird eine Zeile zurückgegeben. In der Datenbank AdventureWorks2008 habe ich die folgenden acht Zeilen als Ergebnis bekommen (nicht alle Spalten sind dargestellt): FileId

FileSize

StartOffset

FSeqNo

Status

CreateLSN

-------- ---------- -------------- ----------- -------- ------------------2

458752

8192

42

2

0

2

458752

466944

41

0

0

2

458752

925696

43

2

0

2

712704

1384448

44

2

0

2

4194304

2097152

47

2

44000000085601161

2

4194304

6291456

46

2

44000000085601161

2

4194304

10485760

40

2

44000000085601161

2

4194304

14680064

0

0

44000000085601161

Anhand der Anzahl der Zeilen kann ich ablesen, wie viele VLFs sich in meiner Datenbank befinden. Die Spalte FileID zeigt an, welche der physischen Dateien des Protokolls die betreffende VLF enthält, wobei es in meiner AdventureWorks2008-Datenbank nur eine einzige physische Protokolldatei gibt. Die Werte für FileSize und StartOffset sind in Bytes angegeben. Die erste VLF beginnt also nach einem Offset von 8192 Bytes,

216

Kapitel 4:


was der Anzahl der Bytes in einer Seite entspricht. Die erste physische Seite einer Protokolldatei enthält nur Headerinformationen, keine Protokolleinträge, sodass die erste VLF auf der zweiten Seite beginnt. Für die meisten Zeilen ist die Spalte FileSize eigentlich überflüssig, da sich die Dateigröße einfach durch Subtraktion der StartOffset-Werte zweier aufeinander folgender VLFs berechnen lässt. Die Zeilen werden in der Reihenfolge der physischen Anordnung aufgeführt, aber das ist nicht immer die Reihenfolge, in der die VLFs verwendet wurden. Die Verwendungsreihenfolge (logische Reihenfolge) können Sie in der Spalte FSeqNo (File Sequence Number, also Dateifolgenummer) ablesen.


In der vorstehenden Ausgabe sehen Sie, dass die Zeilen in der physischen Reihenfolge nach ihrem Startoffset aufgelistet sind, die aber nicht mit der logischen Reihenfolge übereinstimmt. Der Wert für FSeqNo zeigt an, dass die siebente VLF in der (logischen) Verwendungsreihenfolge die erste ist und die letzte in der Verwendungsreihenfolge die fünfte in der physischen Anordnung. Die Spalte Status zeigt an, ob eine VLF wiederverwendbar ist. Ein Status von 2 bedeutet aktiv oder wiederherstellbar, ein Status von 0 wiederverwendbar oder noch nicht verwendet. (Eine überhaupt noch nicht verwendete VLF hat einen FSeqNo-Wert von 0, wie Sie in der achten Zeile der Beispielausgabe sehen.) Wie bereits erwähnt, werden wiederverwendbare VLFs beim Abschneiden oder Sichern des Transaktionsprotokolls in wiederverwendbare verwandelt, sodass sich der Status 2 bei allen VLFs, die keine aktiven Protokolleinträge enthalten, in 0 ändern. Es gibt daher auch eine Möglichkeit, um zu erkennen, welche VLFs noch aktiv sind: VLFs, die nach dem Sichern oder Abschneiden immer noch den Status 2 aufweisen, müssen Einträge zu aktiven Transaktionen enthalten. VLFs mit dem Status 0 können für neue Protokolleinträge wiederverwendet werden, sodass das Protokoll nicht vergrößert werden muss, um mit der Datenbankaktivität Schritt zu halten. Wenn jedoch alle VLFs im Protokoll den Status 2 aufweisen, muss SQL Server neue VLFs hinzufügen, um weitere Transaktionsaktivitäten aufzuzeichnen. Die letzte Spalte in der zuvor gezeigten Ausgabe von DBCC LOG heißt CreateLSN und enthält einen LSNWert, nämlich die aktuelle LSN zu dem Zeitpunkt, als die VLF zum Transaktionsprotokoll hinzugefügt wurde. Ein CreateLSN-Wert von 0 bedeutet, dass die VLF Teil der ursprünglichen Protokolldatei war, die beim Erstellen der Datenbank angelegt wurde. Sie können ablesen, wie viele VLFs bei einer Operation hinzugefügt wurden, indem Sie sich die VLFs ansehen, die denselben CreateLSN-Wert aufweisen. In meiner Beispielausgabe zeigen die CreateLSN-WErte, dass meine Protokolldatei einmal vergrößert wurde und dabei vier neue VLFs auf einmal hinzugefügt wurden.

Mehrere Protokolldateien Ich habe bereits erwähnt, dass SQL Server mehrere physische Protokolldateien als einen zusammenhängenden Stream behandelt. Das bedeutet, dass alle VLFs in einer physischen Datei verwendet werden, bevor eine VLF aus der zweiten Datei zum Einsatz kommt. Für ein gut verwaltetes Protokoll, das regelmäßig gesichert oder abgeschnitten wird, brauchen Sie möglicherweise niemals eine andere als die erste Protokolldatei. Wenn eine neue VLF gebraucht wird, aber keine der bereits vorhandenen VLFs in einem Satz von mehreren physischen Protokolldateien wiederverwendbar ist, fügt SQL Server die neuen nach dem Umlaufprinzip (RoundRobin) an die einzelnen physischen Protokolldateien an. Die Reihenfolge, in der die einzelnen physischen Dateien verwendet erden, können Sie an der Ausgabe von DBCC LOGINFO ablesen. Die erste Spalte (file_id) gibt die Kennung der physischen Datei an. Wenn wir die Ausgabe von DBCC LOGINFO in eine Tabelle schreiben, können wir sie auf eine Weise sortieren, die für uns sinnvoll ist. Der folgende Code erstellt die Tabelle sp_loginfo für die Ausgabe von DBCC LOGINFO. Da die Tabelle in der Datenbank master erstellt wird und ihr Name mit sp_ beginnt, kann sie von jeder Datenbank aus bearbeitet werden.

217


USE master GO IF EXISTS (SELECT 1 FROM sys.tables WHERE name = 'sp_LOGINFO') DROP TABLE sp_loginfo; GO CREATE TABLE sp_LOGINFO (FileId tinyint, FileSize bigint, StartOffset bigint, FSeqNo int, Status tinyint, Parity tinyint,


CreateLSN numeric(25,0) ); GO

Der folgende Code erstellt die neue Datenbank TWO_LOGS und kopiert dann eine umfangreiche Tabelle der Beispieldatenbank AdventureWorks2008 dort hinein, wodurch das Protokoll vergrößert wird: USE Master GO

IF EXISTS (SELECT * FROM sys.databases WHERE name = 'TWO_LOGS') DROP DATABASE TWO_LOGS; GO CREATE DATABASE TWO_LOGS ON PRIMARY (NAME = Data , FILENAME =

'C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\ TWO_LOGS.mdf', SIZE = 100 MB) LOG ON (NAME = TWO_LOGS1, FILENAME = 'C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\ TWO_LOGS1.ldf', SIZE = 5 MB, MAXSIZE = 2 GB), (NAME = TWO_LOGS2, FILENAME = 'C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\ TWO_LOGS2.ldf', SIZE = 5 MB); GO

218

Kapitel 4:


Wenn Sie DBCC LOGINFO ausführen, können Sie erkennen, dass der Befehl die VLFs nach der Dateikennung sortiert zurückgibt. Ursprünglich befinden sich auch die Dateifolgenummern (FSeqNo) in der richtigen Reihenfolge. USE TWO_LOGS GO DBCC LOGINFO; GO

Jetzt können wir einige Zeilen in die Datenbank einfügen, indem wir Sie aus einer anderen Tabelle kopieren: SELECT * INTO Orders FROM AdventureWorks2008.Sales.SalesOrderDetail; GO

TRUNCATE TABLE sp_LOGINFO; INSERT INTO sp_LOGINFO EXEC ('DBCC LOGINFO'); GO


Wenn Sie DBCC LOGINFO erneut ausführen, ist die Ausgabe nach wie vor nach der Dateikennung geordnet, auch wenn es nach der SELECT INTO-Operation jetzt viel mehr Zeilen für jede Kennung gibt. Die FSeqNoWerte dagegen sind jetzt durcheinander. Wir können jedoch die Ausgabe von DBCC LOGINFO in der Tabelle sp_loginfo speichern und nach FSeqNo sortieren:

-- Nicht verwendete VLFs haben den Status 0, weshalb CASE sie ans Ende zwingt SELECT * FROM sp_LOGINFO ORDER BY CASE FSeqNo WHEN 0 THEN 9999999 ELSE FSeqNo END; GO

Die Ausgabe von SELECT lautet: FileId StartOffset

FSeqNo

Status CreateLSN

------ -------------------- ----------- ------ ----------------2

8192

43

0

0

2

1253376

44

0

0

2

2498560

45

0

0

2

3743744

46

0

0

3

8192

47

0

0

3

1253376

48

0

0

3

2498560

49

0

0

3

3743744

50

0

0

2

5242880

51

0

50000000247200092

왘

219


5496832

52

0

50000000247200092

3

5242880

53

0

51000000035600288

3

5496832

54

0

51000000035600288

2

5767168

55

0

53000000037600316

2

6021120

56

0

53000000037600316

3

5767168

57

0

56000000010400488

3

6021120

58

0

56000000010400488

2

6356992

59

0

58000000007200407

2

6610944

60

0

58000000007200407

3

6356992

61

0

60000000025600218

3

6610944

62

0

60000000025600218

2

7012352

63

0

62000000023900246

2

7266304

64

0

62000000023900246

3

7012352

65

0

64000000037100225

3

7266304

66

0

64000000037100225

2

7733248

67

0

66000000037600259

2

7987200

68

0

66000000037600259

2

8241152

69

0

66000000037600259

3

7733248

70

0

68000000035500288

3

7987200

71

0

68000000035500288

3

8241152

72

0

68000000035500288

2

8519680

73

0

71000000037300145

2

8773632

74

0

71000000037300145

2

9027584

75

0

71000000037300145

3

8519680

76

0

75000000018700013

3

8773632

77

2

75000000018700013

3

9027584

0

0

75000000018700013


2

Sie können jetzt erkennen, dass nach der Verwendung der ursprünglichen acht VLFs (denen mit dem CreateLSN-Wert von 0) die neuen VLFs abwechseln den einzelnen physischen Dateien zugeschlagen werden. Aufgrund des Protokollwachstums werden jedes Mal mehrere neue VLFs erstellt, zuerst in Datei 2, dann in 3. Die letzte zu Datei 3 hinzugefügte VLF wurde noch nicht verwendet. Es gibt also wirklich keinen Grund, mehrere physische Protokolldateien zu verwenden, wenn Sie ausreichende Tests durchgeführt und die optimale Größe des Transaktionsprotokolls für die Datenbank bestimmt haben. Wenn Sie jedoch feststellen, dass das Protokoll stärker wachsen muss, als Sie erwartet haben, und das Volume mit dem Protokoll noch über ausreichend freien Platz dafür verfügt, können Sie dort eine zweite Protokolldatei anlegen.

220

Kapitel 4:


Automatisches Abschneiden von virtuellen Protokolldateien Unter den folgenden Umständen geht SQL Server davon aus, dass Sie keine Folge von Protokollsicherungen unterhalten: 쐍 Sie haben die Datenbank auf das Wiederherstellungsmodell SIMPLE (Einfach) eingestellt und damit fest-

gelegt, dass das Protokoll regelmäßig abgeschnitten wird. 쐍 Sie haben niemals eine vollständige Datenbanksicherung durchgeführt.

Wenn eine dieser beiden Bedingungen erfüllt ist, schneidet SQL Server das Transaktionsprotokoll der Datenbank immer dann ab, wenn es »voll genug« ist. (Was das bedeutet, erkläre ich in Kürze.) Die Datenbank ist dann im Modus mit automatischem Abschneiden.


Abschneiden bedeutet, dass alle Protokolleinträge vor der ältesten aktiven Transaktion ungültig gemacht werden und alle VLFS, die keinen Teil des aktiven Protokolls enthalten, als wiederverwendbar gekennzeichnet werden. Die physische Protokolldatei wird dabei jedoch nicht verkleinert. Wenn Ihre Datenbank bei der Replikation die Rolle des Verlegers innehat, kann die älteste offene Transaktion auch eine für die Replikation vorgesehene, aber noch nicht replizierte Transaktion sein. »Voll genug« bedeutet, dass es mehr Protokolleinträge gibt, als bei einem Systemstart in einem sinnvollen Zeitraum – dem so genannten Wiederherstellungsintervall – rückgängig gemacht werden können. Das Wiederherstellungsintervall können Sie manuell mit der gespeicherten Prozedur sp_configure oder in SQL Server Management Studio festlegen, wie Sie in Kapitel 1 gelernt haben. Am besten lassen Sie SQL Server diesen Wert jedoch automatisch einrichten. In den meisten Fällen beträgt das Wiederherstellungsintervall eine Minute. Standardmäßig zeigt sp_configure null Minuten an, was bedeutet, dass SQL Server den Wert automatisch festlegt. SQL Server nutzt dabei den Schätzwert, dass 10 MB an Transaktionen in einer Minute wiederhergestellt werden können. Der eigentliche Abschneidevorgang wird durch den Prüfpunktprozess aufgerufen, der normalerweise »schläft« und nur bei Bedarf aufgeweckt wird. Jedes Mal, wenn ein Benutzerthread den Protokoll-Manager aufruft, prüft dieser die Größe des Protokolls. Übersteigt die Größe den Umfang, der innerhalb des Wiederherstellungsintervalls wiederhergestellt werden kann, wird der Prüfpunktthread aufgerufen. Dieser versieht die Datenbank mit einem Prüfpunkt und schneidet den inaktiven Teil des Protokolls ab. Sollte das Protokoll einer Datenbank im Modus mit automatischem Abschneiden jemals über 70% gefüllt werden, weckt der Protokoll-Manager ebenfalls den Prüfpunktthread auf, um einen Prüfpunkt zu erzwingen. Eine Vergrößerung des Protokolls ist sehr viel aufwändiger als das Abschneiden, weshalb SQL Server es wann immer möglich abschneidet. HINWEIS Falls der Protokoll-Manager nie gebraucht wird, so wird auch der Prüfpunktprozess niemals aufgeweckt und das Protokoll nie abgeschnitten. Bei einer Datenbank im Modus mit automatischem Abschneiden, deren Transaktionsprotokoll nur VLFs mit dem Status 2 aufweist, findet kein Wechsel in den Status 0 statt, bevor irgendwelche Protokollierungsaktivitäten auftreten.

Wenn das Protokoll regelmäßig abgeschnitten wird, kann SQL Server den Platz in der physischen Datei verwenden, indem er zu einer früheren VLF zurückkehrt, wenn das Ende der physischen Protokolldatei erreicht ist. Dadurch verwendet SQL Server den Platz in der Protokolldatei, der nicht mehr zur Sicherung und Wiederherstellung (restore) verwendet wird, zyklisch wieder. Meine AdventureWorks2008-Datenbank befindet sich in diesem Zustand, da ich niemals eine vollständige Datenbanksicherung dafür durchgeführt habe.

221


Unterhalten eines wiederherstellbaren Protokolls Wenn Sie eine Folge von Protokollsicherungen unterhalten, kann der Teil des Protokolls vor der kleinsten LSN nicht überschrieben werden, bevor die betreffenden Einträge gesichert worden sind. Der VLF-Status bleibt bei 2, bis eine Sicherung geschieht. Danach wechselt der Status auf 0, sodass SQL Server an den Anfang der Datei zurückkehren kann. Abbildung 4.4 zeigt diesen Zyklus in vereinfachter Form. Wie Sie anhand der FSeqNoWerte in der zuvor gezeigten Ausgabe aus der Datenbank AdventureWorks2008 gesehen haben, verwendet SQL Server die Protokolldateien nicht immer in ihrer physischen Anordnung.

Physische Protokolldatei

VLF 2

VLF 3

VLF 4


VLF 1

Kleinste LSN

Aktuelle Position Ende des logiBeginn des im Protokoll schen Protokolls logischen Protokolls

Letzter Prüfpunkt

Abbildung 4.4 Der aktive Teil des Protokolls wird zyklisch am Anfang der physischen Datei fortgesetzt

HINWEIS Wenn sich eine Datenbank nicht im Modus mit automatischem Abschneiden befindet und Sie keine regelmäßigen Protokollsicherungen durchführen, wird das Transaktionsprotokoll niemals abgeschnitten. Falls Sie nur vollständige Datenbanksicherungen vornehmen, müssen Sie das Protokoll manuell abschneiden, um es auf einer handhabbaren Größe zu belassen.

Die einfachste Möglichkeit, um herauszufinden, ob sich eine Datenbank im Modus mit automatischem Abschneiden befindet oder nicht, besteht darin, sich die Spalte last_log_backup_lsn der Katalogsicht sys.database_recovery_status anzusehen. Ist der Wert in dieser Spalte NULL, befindet sich die Datenbank im Modus mit automatischem Abschneiden. Den Unterschied zwischen einer Datenbank in diesem Modus und einer anderen können Sie beobachten, indem Sie in der Datenbank pubs das einfache Skript ausführen, das Sie am Ende dieses Absatzes finden. Das Experiment funktioniert jedoch nur, wenn Sie noch keine vollständige Sicherung von pubs angelegt haben. Wenn Sie die Datenbank mit dem Skript Instpubs.sql installiert und noch nie geändert haben, liegt die Größe der Transaktionsprotokolldatei bei etwa 0,75 MB, was die Größe bei der Erstellung ist. Das folgende Skript erstellt eine neue Tabelle in pubs, fügt drei Datensätze ein und aktualisiert diese dann 1000 Mal. Jede Aktualisierung ist eine individuelle Transaktion, und jede von ihnen wird in das Transaktionsprotokoll geschrieben. Trotzdem werden Sie feststellen, dass das Protokoll nicht vergrößert wird und dass die Anzahl der VLFs selbst nach dem Schreiben von 3000 Aktualisierungseinträgen nicht wächst. (Wenn Sie pubs bereits gesichert haben, müssen Sie die Datenbank neu erstellen, bevor Sie dieses Beispiel ausprobieren können. Führen Sie dazu das Skript Instpubs.sql erneut aus, dass Sie von der Begleitwebsite http://www.SQLServerInternals.com/ companion herunterladen können.) Während sich die Anzahl der VLFs nicht ändert, wechseln jedoch die FSeqNo-Werte, denn während die VLFs wiederverwendet werden, erhalten Sie eine neue Folgenummer.

222

Kapitel 4:


USE pubs; -- Wir sehen uns zuerst die VLFs für pubs an DBCC LOGINFO; -- Jetzt überprüfen wir, dass sich pubs im Modus mit automatischem -- Abschneiden befindet SELECT last_log_backup_lsn FROM master.sys.database_recovery_status WHERE database_id = db_id('pubs'); GO CREATE TABLE newtable (a int); GO INSERT INTO newtable VALUES (10); INSERT INTO newtable VALUES (20); GO SET NOCOUNT ON DECLARE @counter int; SET @counter = 1 ; WHILE @counter < 1000 BEGIN


INSERT INTO newtable VALUES (30);

UPDATE newtable SET a = a + 1; SET @counter = @counter + 1; END;

Sichern Sie jetzt die Datenbank pubs, nachdem Sie sich vergewissert haben, dass für sie nicht das Wiederherstellungsmodell SIMPLE festgelegt ist. Die Wiederherstellungsmodelle bespreche ich weiter hinten in diesem Kapitel, aber jetzt können Sie pubs einfach auf das geeignete Wiederherstellungsmodell setzen, indem Sie den folgenden Befehl geben: ALTER DATABASE pubs SET RECOVERY FULL;

Mit der folgenden Anweisung führen Sie die Sicherung durch, wobei Sie den gezeigten Pfad durch den für Ihre SQL Server-Installation oder dem zu einem beliebigen Speicherort für Sicherungen ersetzen: BACKUP DATABASE pubs to disk = 'c:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\backup\pubs.bak';

Nachdem Sie die vollständige Sicherung erstellt haben, können Sie bestätigen, dass sich die Datenbank nicht mehr im Modus mit automatischem Abschneiden befinden, indem Sie sich die Sicht database_recovery_status anschauen:

223


SELECT last_log_backup_lsn FROM master.sys.database_recovery_status WHERE database_id = db_id('pubs');

Jetzt sollten Sie in last_log_backup_lsn einen Nicht-NULL-Wert sehen, der anzeigt, dass Protokollsicherungen erwartet werden. Als Nächstes führen Sie das Aktualisierungsskript ab der DECLARE-Anweisung erneut aus. Nun sollten Sie erkennen, dass die physische Protokolldatei vergrößert wurde, um die hinzugefügten Protokolleinträge aufzunehmen, und dass es mehr VLFs gibt. Der ursprüngliche Platz im Protokoll konnte nicht wiederverwendet werden, da SQL Server davon ausgeht, dass Sie die Informationen bis zur nächsten Transaktionsprotokollsicherung aufbewahren. Sie können jetzt versuchen, das Protokoll wieder zu verkleinern. Als Erstes müssen Sie es dazu abschneiden, was Sie dadurch erledigen, dass Sie das Wiederherstellungsmodell wie folgt auf SIMPLE setzen:


ALTER DATABASE pubs SET RECOVERY SIMPLE;

Wenn Sie dann den folgenden Befehl oder DBCC SHRINKDATABASE für pubs eingeben, verkleinert SQL Server die Protokolldatei: DBCC SHRINKFILE (2);

Die Größe der physischen Protokolldatei ist jetzt wieder verringert. Wenn ein Protokoll abgeschnitten, aber kein Verkleinerungsbefehl ausgeführt wird, kennzeichnet SQL Server den von den abgeschnittenen Einträgen eingenommenen Platz für die Wiederverwendung, ändert die Größe der physischen Datei aber nicht. In SQL Server 7.0, wo diese Protokollierungsarchitektur zum ersten Mal eingeführt wurde, führten die vorstehenden Befehle nicht immer dazu, dass die physische Protokolldatei verkleinert wurde. Wenn sich das Protokoll nicht verkleinern ließ, lag das daran, dass sich sein aktiver Teil am Ende der physischen Datei befand. Die physische Verkleinerung kann aber nur vom Ende der Datei her begonnen werden, und der aktive Teil lässt sich niemals verkleinern. Um hier Abhilfe zu schaffen, mussten Sie nach dem Abschneiden des Protokolls Platzhaltertransaktionen eingeben, um den aktiven Teil des Protokolls wieder an den Anfang der Datei zu verschieben. In den Versionen nach SQL Server 7.0 ist dies jedoch nicht mehr notwendig. Wenn bereits ein Verkleinerungsbefehl eingegeben wurde, wird beim Abschneiden des Protokolls intern eine Reihe von NO-OP- (oder Platzhalter-) Protokolleinträgen eingefügt, um das aktive Protokoll vom Ende der physischen Datei hinweg zu verschieben. Die Verkleinerung erfolgt dann, sobald das Protokoll nicht mehr gebraucht wird.

Automatisches Verkleinern des Protokolls Denken Sie daran, dass Abschneiden nicht Verkleinern bedeutet. Eine Datenbank sollte so abgeschnitten werden, dass sie sich höchstmöglich verkleinern lässt. Wenn das Protokoll automatisch abgeschnitten wird und die Option für die automatische Verkleinerung aktiviert ist, wird das Protokoll in regelmäßigen Abständen physisch verkleinert.

224

Kapitel 4:


Ist die Option für die automatische Verkleinerung aktiviert, wird der entsprechende Vorgang alle 30 Minuten (wie in Kapitel 3 beschrieben) aufgerufen und bestimmt die Größe, auf die das Protokoll verkleinert werden kann. Der Protokoll-Manager sammelt Statistiken über den maximalen Betrag an Protokollplatz, der während des 30-minütigen Zeitraums zwischen den Verkleinerungen verwendet wird. Als Ziel für die Verkleinerung legt der Prozess dann 125% des tatsächlich verwendeten, maximalen Protokollplatzes oder die Mindestgröße des Protokolls fest, falls diese größer ist. (Die Mindestgröße ist diejenige, die das Protokoll beim Erstellen hatte oder diejenige, auf die es manuell vergrößert oder verkleinert wurde.) Das Protokoll wird dann auf diese Größe reduziert, sobald die Gelegenheit dazu besteht, also wenn es abgeschnitten oder gesichert wird. Es ist möglich, die automatische Verkleinerung zu aktivieren, ohne dass sich die Datenbank im Modus mit automatischem Abschneiden befindet, allerdings ist dann nicht sichergestellt, dass das Protokoll dann auch wirklich verkleinert wird. Wenn das Protokoll z.B. niemals gesichert wird, werden keine der VLFs als wiederverwendbar gekennzeichnet, sodass eine Verkleinerung nicht möglich ist.


Ein letzter Hinweis: Wenn sich eine Datenbank im Modus mit automatischem Abschneiden befindet, ist damit nicht sichergestellt, dass das Protokoll nicht wachsen kann. (Es ist gerade das Gegenteil, von dem Sie ausgehen können: Wenn sich die Datenbank nicht im Modus mit automatischem Abschneiden befindet, wird das Protokoll wachsen!) Automatisches Abschneiden bedeutet nur, dass die wiederherstellbaren VLFs in regelmäßigen Abständen als wiederverwendbar gekennzeichnet werden. VLFs im aktiven Zustand sind davon jedoch nicht betroffen. VLFs, die Protokolleinträge für die Zeit nach dem Beginn einer lang andauernden Transaktion enthalten (z.B. einer Transaktion, für die ein Commit vergessen wurde), werden als aktiv betrachtet und können nicht wiederverwendet werden. Eine einzige nicht mit Commit abgeschlossene Transaktion kann aus einem Transaktionsprotokoll mit handhabbarer Größe eines machen, das mehr Festplattenplatz verbraucht als die Datenbank selbst und ständig weiter anwächst.

Die Größe der Protokolldatei

Die derzeitige Größe der Protokolldateien aller Datenbanken sowie den prozentualen Anteil des benutzten Platzes in der Protokolldatei können Sie einsehen, indem Sie den Befehl DBCC SQLPERF('logspace') ausführen. Da es sich um einen DBCC-Befehl handelt, ist es schwer, die Zeilen zu filtern, um nur diejenigen für eine einzige Datenbank angezeigt zu bekommen. Stattdessen können Sie auch die dynamische Verwaltungssicht sys.dm_os_performance_counters verwenden und den prozentualen Füllungsgrad für die Protokolle der einzelnen Datenbanken abrufen: SELECT instance_name as [Database], cntr_value as "LogFullPct" FROM sys.dm_os_performance_counters WHERE counter_name LIKE 'Percent Log Used%' AND instance_name not in ('_Total', ‘mssqlsystemresource') AND cntr_value > 0;

Die letzte Bedingung dient dazu, alle Datenbanken auszufiltern, für die keine Protokolldateigröße angezeigt wird. Dazu gehören Datenbanken, die nicht zur Verfügung stehen, da sie nicht mit dem Abgleichvorgang wiederhergestellt wurden oder sich im verdächtigen Zustand befinden, sowie Datenbanksnapshots, die keine Transaktionsprotokolle haben.


225

Sichern und Wiederherstellen einer Datenbank Dieses Buch ist, wie Sie sicherlich bereits festgestellt haben, keine Schritt-für-Schritt-Anleitung für Datenbankadministratoren. Die Bibliografie im Begleitmaterial führt verschiedene hervorragende Bücher auf, aus denen Sie den Mechanismus der Datenbanksicherung und -wiederherstellung (restore) lernen und empfohlene Vorgehensweise zum Aufstellen eines Sicherungs- und Wiederherstellungsplans für Ihre Organisation gewinnen können. Einige wichtige Aspekte der Sicherung und Wiederherstellung helfen jedoch zu erkennen, welcher Sicherungsplan sich besser für Ihre Bedürfnisse eignet als andere. Hierbei geht es meistens um die Rolle des Transaktionsprotokolls bei der Sicherung und Wiederherstellung, weshalb ich die Hauptaugenmerke in diesem Abschnitt beschreibe.

Arten von Sicherungen Ki K m al b e A M da erl n D ic m y e ro L so Ma . T lane IS ft ch rip y, BN SQ a p P n C a 97 L S ic u on ul 8- er nd or S. 3- ve B C R 86 r e un an 64 20 n N ni da 5- 08 e ng l, 65 In va ha 6- ter re m, 3 na z ls

Für wie viel Fehlertoleranz Sie in Ihrem Datenbanksystem auch immer gesorgt haben, so ist dies doch kein Ersatz für regelmäßige Sicherungen. Sicherungen schaffen Abhilfe bei den Auswirkungen von versehentlichen oder böswilligen Datenänderungen, Programmierfehlern und Naturkatastrophen (wenn Sie die Sicherungen an einem anderen Ort lagern). Wenn Sie zugunsten des schnellstmöglichen Zugriffs auf die Datendateien auf Fehlertoleranz verzichten, stellen Sicherungen eine Lösung für den Fall dar, dass die Datendateien beschädigt werden. Außerdem sind Sicherungen die bevorzugte Möglichkeit, um Datenbanken zu anderen Rechnern oder Instanzen zu kopieren. Wie viele verloren gegangene Daten wiederhergestellt werden können, hängt von der Art der Sicherung ab. In SQL Server 2008 gibt es vier Haupttypen von Sicherungen (und einige Varianten davon): 쐍 Vollständige Sicherung

Bei einer vollständigen Datenbanksicherung werden im Grunde genommen alle Seiten einer Datenbank auf ein Sicherungsgerät kopiert, bei dem es sich um eine lokale Datei, eine Datei im Netzwerk oder ein lokales Bandlaufwerk handeln kann.

쐍 Differenzielle Sicherung

Bei einer differenziellen Sicherung werden nur die Blöcke auf das Sicherungsgerät kopiert, die sich seit der letzten vollständigen Sicherung geändert haben. SQL Server erkennt, welche Blöcke das sind, indem er die Bits auf den DCM-Seiten (Differential Changed Map) aller Datendateien in der Datenbank untersucht. DCM-Seiten sind große Bitmaps, bei denen jedes Bit für einen Block in einer Datei steht, ähnlich wie bei den GAM- (Global Allocation Map) und SGAM-Seiten (Shared GAM), die ich in Kapitel 3 besprochen habe. Bei jeder vollständigen Sicherung werden die Bits auf der DCM-Seite auf 0 zurückgeschaltet. Sobald sich eine Seite in einem Block ändert, wird das entsprechende Bit auf der DCM-Seite auf 1 gesetzt.

쐍 Protokollsicherung

In den meisten Fällen werden bei einer Protokollsicherung alle Protokolleinträge kopiert, die seit der letzten vollständigen oder Protokollsicherung geschrieben wurden. Das genaue Verhalten des Befehls BACKUP LOG hängt jedoch von den Einstellungen für das Wiederherstellungsmodell der Datenbank ab. Wiederherstellungsmodelle behandle ich in Kürze.

쐍 Datei- und Dateigruppensicherung

Datei- und Dateigruppensicherungen sollen für eine höhere Flexibilität bei der Planung und bei der Handhabung der Medien im Vergleich mit vollständigen Sicherungen sorgen, vor allem bei sehr umfangreichen Datenbanken. Diese Art von Sicherung ist auch für große Datenbanken nützlich, die Daten mit verschiedenen Aktualisierungseigenschaften enthalten, bei denen also manche Dateigruppen sowohl Lese- als auch Schreibvorgänge zulassen, andere aber schreibgeschützt sind.

226

Kapitel 4:


Weitere Informationen

Ausführliche Informationen über das Definieren von Sicherungsgeräten, das Anfertigen von Sicherungen und die Planung von Sicherungen, die in regelmäßigen Abständen erfolgen sollen, finden Sie in der SQL Server-Onlinedokumentation und in den SQL Server-Administrationsbüchern, die in der Quellenangabe zum Onlinebegleitmaterial aufgeführt sind. Eine vollständige Sicherung kann erfolgen, während die Datenbank in Gebrauch ist. Hierbei handelt es sich um eine so genannte »Fuzzysicherung«, also eine »verschwommene« Sicherung, weil sie kein genaues Abbild der Datenbank zu einem bestimmten Zeitpunkt erstellt. Die Sicherungsthreads kopieren einfach die Blöcke, und wenn andere Prozesse Änderungen an diesen Blöcken vornehmen müssen, während die Sicherung noch läuft, so können sie dies tun.


Um die Konsistenz bei vollständigen, differenziellen und Dateisicherungen zu erhalten, zeichnen SQL Server auch die jeweils aktuelle Protokollfolgenummer (Log Sequence Number, LSN) zu Beginn und am Ende der Sicherung auf. Dadurch kann der Sicherungsprozess auch die relevanten Teile des Protokolls erfassen, also diejenigen von der ältesten aktiven Transaktion zum Zeitpunkt der ersten aufgezeichneten LSN bis zur zweiten LSN. Was in der Protokollsicherung aufgezeichnet wird, hängt wie bereits erwähnt vom verwendeten Wiederherstellungsmodell ab. Bevor wir uns also den Einzelheiten der Protokollsicherung widmen, sehen wir uns zunächst die Wiederherstellungsmodelle an.

Wiederherstellungsmodelle

In Kapitel 3 habe ich bei der Erörterung der Datenbankoptionen gesagt, dass die Option RECOVERY drei mögliche Werte hat, nämlich FULL, BULK_LOGGED und SIMPLE. Der Wert, den Sie auswählen, bestimmt die Größe des Transaktionsprotokolls, die Geschwindigkeit und Größe der Protokollsicherungen (bzw., ob Sie das Protokoll überhaupt sichern können) und die Gefahr eines Verlustes mit Commit abgeschlossener Transaktionen bei einem Medienausfall.

Das Wiederherstellungsmodell FULL Das Wiederherstellungsmodell FULL (in Management Studio Vollständig) weist das geringste Verlustrisiko im Fall beschädigter Datendateien auf. Ist eine Datenbank in diesem Modus, werden alle Operationen aufgezeichnet. Das bedeutet, dass nicht nur jede Zeile protokolliert wird, die mit INSERT eingefügt, mit DELETE gelöscht oder mit UPDATE geändert wird, sondern sämtliche Zeilen, die über eine bcp- oder BULK INSERTOperation eingefügt werden. Wenn das Medium einer Datenbankdatei ausfällt, Sie eine Datenbank mit dem Wiederherstellungsmodell FULL wiederherstellen müssen und Sie eine vollständige Sicherung der Datenbank und danach regelmäßige Transaktionsprotokollsicherungen angefertigt haben, können Sie die Datenbank auf den Zustand jedes beliebigen Zeitpunkts bis zur letzten Protokollsicherung wiederherstellen. Falls die Protokolldatei nach dem Ausfall der Datendatei noch verfügbar ist, können Sie sogar die letzten vor dem Versagen mit Commit abgeschlossenen Transaktionen wiederherstellen. In SQL Server 2008 gibt es so genannte Protokollmarkierungen, mit denen Sie Referenzpunkte im Transaktionsprotokoll kennzeichnen können. Beim Wiederherstellungsmodell FULL können Sie eine Datenbank zielgenau auf den Zustand bei einer dieser Markierungen zurücksetzen.


227

Im Wiederherstellungsmodell FULL protokolliert SQL Server auch alle CREATE INDEX-Vorgänge. Eine Wiederherstellung von einem Transaktionsprotokoll, in dem Indexerstellungen vorhanden sind, erfolgt viel schneller, da der Index nicht neu angelegt werden muss – alle Indexseiten sind schon als Teil der Datenbanksicherung erfasst. Vor SQL Server 2000 wurde nur die Tatsache aufgezeichnet, dass ein Index angelegt wurde, sodass bei der Wiederherstellung von einer Protokollsicherung der gesamte Index neu erstellt werden musste.

Das Wiederherstellungsmodell BULK_LOGGED

쐍 SELECT INTO


Das Wiederherstellungsmodell BULK_LOGGED (Massenprotokolliert) erlaubt Ihnen, eine Datenbank im Fall eines Medienausfalls komplett wiederherzustellen, bietet aber auch optimale Leistung und geringsten Platzverbrauch bei bestimmten Massenoperationen. Im Wiederherstellungsmodell FULL werden diese Vorgänge vollständig protokolliert, bei BULK_LOGGED nur minimal. Dies ist sehr viel effizienter als die normale Protokollierung, da die Daten beim Schreiben in eine Benutzerdatenbank gewöhnlich zweimal geschrieben werden: einmal im Protokoll und einmal in der Datenbank selbst. Das liegt daran, dass das Datenbanksystem ein Rollforward/Rollback-Protokoll verwendet, um Transaktionen bei Bedarf zu rekonstruieren oder rückgängig zu machen. Bei der minimalen Protokollierung werden nur die Informationen aufgezeichnet, die für einen Rollback der Transaktionen gebraucht werden; eine zeitpunktgenaue Wiederherstellung ist dabei nicht möglich. Als Massenoperationen gelten die folgenden: Dieser Befehl erstellt eine neue Tabelle in der standardmäßigen Dateigruppe.

쐍 Massenimportvorgänge wie die folgenden: 쐍 Der Befehl BULK INSERT 쐍 Das Programm bcp

쐍 Der Befehl INSERT INTO ... SELECT, wenn Daten mit der Funktion OPENROWSET(BULK...) abgefragt

werden.

쐍 Der Befehl INSERT INTO ... SELECT, wenn mehr als ein Seitenblock von Daten in eine Tabelle ohne nicht

gruppierte Indizes und ohne den Hinweis TABLOCK eingefügt wird. Ist die Zieltabelle leer, kann sie einen gruppierten Index haben, anderenfalls nicht. (Diese Option ist nützlich, um eine neue Tabelle in einer anderen als der Standarddateigruppe mit minimaler Protokollierung zu erstellen. Beim Befehl SELECT INTO können Sie keine Dateigruppe angeben.) 쐍 Teilaktualisierungen an Spalten mit Datentypen für große Werte (die wir in Kapitel 7, »Besondere Spei-

cherformate«, behandeln). 쐍 WRITE-Klauseln in UPDATE-Anweisungen beim Einfügen oder Anhängen neuer Daten. 쐍 Die Anweisungen WRITETEXT und UPDATETEXT beim Einfügen oder Anhängen neuer Daten in LOB-

Datenspalten (text, ntext und image). Wenn vorhandene Daten aktualisiert werden, findet jedoch keine minimale Protokollierung statt. 쐍 Folgende Indexoperationen: 쐍 CREATE INDEX, auch für Indizes von Sichten 쐍 ALTER INDEX REBUILD und DBCC DBREINDEX 쐍 DROP INDEX. Die Erstellung eines neuen Heaps wird minimal protokolliert, die Aufhebung der Zu-

weisung einer Seite jedoch stets vollständig.

228

Kapitel 4:


Wenn Sie eine dieser Massenoperationen ausführen, protokolliert SQL Server nur die Tatsache, dass der Vorgang auftrat, sowie Informationen über die Platzzuweisungen. Jede Datendatei in einer SQL Server 2008Datenbank weist mindestens eine BCM-Seite (Bulk Changed Map) auf, die auch ML-Map-Seite (Minimally Logged Map) genannt und wie die GAM- und SGAM-Seiten aus Kapitel 3 sowie die in diesem Kapitel erwähnten DCM-Seiten gehandhabt wird. Jedes Bit auf einer BCM-Seite steht für einen Block, und wenn es 1 lautet, heißt das, dass der Block durch eine minimal protokollierte Massenoperation seit der letzten Transaktionsprotokollsicherung geändert wurde. BCM-Seiten erscheinen als die achte Seite einer Datendatei und danach alle 511.230 Seiten. Alle Bits einer CM-Seite werden auf 0 zurückgesetzt, wenn eine Transaktionsprotokollsicherung erfolgt.


Aufgrund der minimalen Protokollierung können die Massenoperationen selbst möglicherweise sehr viel schneller ausgeführt werden als im Wiederherstellungsmodell FULL, doch eine Garantie für diese höhere Geschwindigkeit gibt es nicht. Sicher ist nur, dass das Protokoll selbst kleiner ist. In manchen Fällen kann die Operation bei minimaler Protokollierung sogar langsamer ablaufen als bei vollständiger. SQL Server erzwingt, dass die Datenseiten auf die Festplatte geschrieben werden, bevor ein Commit für die Transaktion erfolgt. Dies kann sehr aufwändig sein, vor allem wenn die E-/A-Vorgänge für diese Seiten zufällig verteilt sind. Bei der vollständigen Protokollierung dagegen erfolgen die E/A-Vorgänge stets hintereinander. Wenn Sie nicht über ein schnelles E/A-Teilsystem verfügen, kann die minimale Protokollierung den Vorgang merklich langsamer machen als bei der vollständigen. Im Allgemeinen bedeutet minimale Protokollierung nicht, dass überhaupt nichts aufgezeichnet wird, und es heißt auch nicht, dass die Protokollierung für alle Vorgänge minimiert wird. Es handelt sich dabei um eine Funktion, die den Umfang der Protokollierung für die zuvor genannten Operationen verringert, und wenn Sie ein hochleistungsfähiges E/A-Teilsystem haben, wird dadurch wahrscheinlich auch die Leistung verbessert. Auf einfacheren Rechnern erfolgen minimal protokollierte Vorgänge langsamer als vollständig protokollierte. Wenn sich eine Datenbank im Modus BULK_LOGGED befindet, Sie aber in Wirklichkeit gar keine Massenoperationen durchgeführt haben, können Sie Ihre Datenbank auf den Zustand eines beliebigen Zeitpunkts und jeder beliebigen Protokollmarkierung zurücksetzen, da das Protokoll eine vollständige Abfolge von Einträgen über alle Änderungen an der Datenbank enthält. Der Nachteil eines kleineren Protokolls zeigt sich, wenn Sie das Protokoll sichern. SQL Server kopiert dann nicht nur den Inhalt des Transaktionsprotokolls auf das Sicherungsmedium, sondern durchsucht auch die BCM-Seiten und sichert alle geänderten Blöcke zusammen mit dem Protokoll. Die Protokolldatei selbst bleibt klein, die Sicherung des Protokolls aber kann ein Mehrfaches an Größe aufweisen. Die Protokollsicherung braucht also mehr Zeit und kann sehr viel mehr Platz einnehmen als im Modus FULL. Die Zeit, die die Wiederherstellung einer Protokollsicherung im Modus BULK_LOGGED braucht, entspricht jedoch der im Modus FULL. Die Operationen müssen nicht wiederholt werden, denn alle erforderlichen Informationen zur Wiederherstellung sämtlicher Daten- und Indexstrukturen sind in der Protokollsicherung zu finden.

Das Wiederherstellungsmodell SIMPLE Das Wiederherstellungsmodell SIMPLE (Einfach) bietet die einfachste Möglichkeit zur Sicherung und Wiederherstellung. Das Transaktionsprotokoll wird abgeschnitten, sobald ein Prüfpunkt auftritt, und dies geschieht in regelmäßigen, kurzen Abständen. Daher können Sie nur solche Arten von Sicherungen durchführen, die keine Protokollsicherungen erfordern, also vollständige und differenzielle Sicherungen, vollständige und differenzielle Teilsicherungen sowie Sicherungen von schreibgeschützten Dateigruppen. Wenn Sie versuchen, im Modus SIMPLE das Protokoll zu sichern, erhalten Sie eine Fehlermeldung. Da das Protokoll


229

nicht für Sicherungszwecke gebraucht wird, können einzelne Abschnitte wiederverwendet werden, sobald die darin enthaltenen Transaktionen mit einem Commit oder einem Rollback abgeschlossen sind und die Transaktionen nicht mehr für den Abgleich nach einem Server- oder Transaktionsfehler gebraucht werden. Tatsächlich wird das Protokoll abgeschnitten, sobald Sie die Datenbank in den Modus SIMPLE schalten. SIMPLE bedeutet jedoch nicht, dass keine Protokollierung stattfindet. »Einfach« ist in diesem Fall Ihre Vorgehensweise bei der Sicherung, da Sie sich nicht um Protokollsicherungen kümmern müssen. Im Modus SIMPLE werden jedoch alle Operationen aufgezeichnet, auch wenn es dabei für einige von ihnen weniger Einträge gibt als im Modus FULL. Das Protokoll einer Datenbank mag im Modus SIMPLE weniger stark wachsen als bei FULL, da die zuvor besprochenen Massenoperationen auch hier nur minimal protokolliert werden. Das bedeutet jedoch nicht, dass Sie in diesem Modus kein Auge auf die Größe des Protokolls haben müssten. Wie bei jedem Wiederherstellungsmodell können die Protokolleinträge für aktive Transaktionen und für Transaktionen, die nach der ältesten offenen Transaktion begannen, nicht abgeschnitten werden. Bei umfangreichen oder lang andauernden Transaktionen brauchen Sie trotzdem noch viel Platz für das Protokoll.


Kompatibilität mit Datenbankoptionen Microsoft hat diese Wiederherstellungsmodelle in SQL Server 2000 als Ersatz für die Datenbankoptionen select into/bulkcopy und trunc. log on chkpt. eingeführt. Bei SQL Server 7.0 und früher mussten Sie die Option select into/bulkcopy aktivieren, um SELECT INTO- und Massenkopieroperationen durchführen zu können. Die Option trunc. log on chkpt. schnitt das Transaktionsprotokoll zwangsweise bei jedem Prüfpunkt in der Datenbank ab und wurde nur für den Einsatz auf Test- und Entwicklungssystemen, aber nicht auf Produktionsservern empfohlen. Diese Optionen können Sie mit der Prozedur sp_dboption immer noch setzen, aber nicht mit ALTER DATABASE. Bei jüngeren Versionen als SQL Server 7.0 führt eine Änderung dieser Optionen mit sp_dboption jedoch zu einer Änderung des Wiederherstellungsmodells und umgekehrt. Zur Änderung des Wiederherstellungsmodells für eine Datenbank wird die Verwendung von ALTER DATABASE empfohlen: ALTER DATABASE Datenbankname

SET RECOVERY [FULL | BULK_LOGGED | SIMPLE]

Um herauszufinden, in welchem Modus sich die Datenbank befindet, können Sie die Sicht sys.databases zu Rate ziehen. Die folgende Abfrage gibt das Wiederherstellungsmodell und den Status von AdventureWorks2008 zurück: SELECT name, database_id, suser_sname(owner_sid) as owner , state_desc, recovery_model_desc FROM sys.databases WHERE name = 'AdventureWorks2008'

Wie bereits erwähnt, können Sie das Wiederherstellungsmodell über die Datenbankoptionen ändern. Wenn sich eine Datenbank beispielsweise im Modus FULL befindet und Sie die Option select into/bulkcopy auf true setzen, wechselt das Wiederherstellungsmodell zu BULK_LOGGED. Wenn Sie anders herum ihre Datenbank mit ALTER DATABASE in den Modus FULL schalten, wird dadurch der Wert der Option select into/bulkcopy geändert. In SQL Server 2008 Standard und Enterprise Edition hat die Datenbank model zu Anfang das Wiederherstellungsmodell FULL, sodass sich alle neuen Datenbanken ebenfalls in diesem Modus befinden. Den Modus von model und jeglichen Benutzerdatenbanken können Sie mit ALTER DATABASE ändern.

230

Kapitel 4:


Damit Sie den größten Nutzen aus dem Transaktionsprotokoll ziehen können, ist es möglich, zwischen den Modi FULL und BULK_LOGGED umzuschalten, ohne sich Sorgen machen zu müssen, dass Ihre Sicherungsskripts versagen. Vor SQL Server 2000 konnten Sie das Transaktionsprotokoll nicht mehr sichern, sobald Sie einen SELECT INTO-Befehl ausgeführt oder einen Massenkopiervorgang vorgenommen hatten. Wenn Sie also ein Skript für die automatische Protokollsicherung hatten, das regelmäßig ausgeführt wurde, funktionierte es nicht mehr, sondern rief eine Fehlermeldung hervor. Dies kann jetzt nicht mehr geschehen. Sie können SELECT INTO und Massenkopiervorgänge in jedem Wiederherstellungsmodell ausführen, und Sie können das Protokoll sowohl im Modus FULL als auch in BULK_LOGGED sichern. Wenn Sie normalerweise im Modus FULL arbeiten, aber gelegentlich schnell eine Massenoperation durchführen müssen, können Sie zwischen den Modi umschalten. Sie wechseln dann einfach zu BULK_LOGGED und bezahlen den Preis dafür später, wenn Sie das Protokoll sichern, denn diese Sicherung dauert dann länger und ist umfangreicher.


Wenn Sie eine Folge von Protokollsicherungen unterhalten möchten, können Sie jedoch nicht so einfach in den Modus SIMPLE und zurück umschalten. Der Wechsel zu SIMPLE ist kein Problem, doch wenn Sie den Modus wieder auf FULL oder BULK_LOGGED ändern möchten, müssen Sie Ihr Sicherungsverfahren planen und sich darüber im Klaren sein, dass es keine ununterbrochene Kette von Protokollsicherungen bis zu diesem Punkt mehr gibt. Falls Sie also mit ALTER DATABASE von SIMPLE zu FULL oder BULK_LOGGED wechseln, sollten Sie erst eine vollständige Datenbanksicherung durchführen. Denken Sie daran, dass das Transaktionsprotokoll im Modus SIMPLE regelmäßig abgeschnitten wird. Dieses Wiederherstellungsmodell wird für Produktionsdatenbanken nicht empfohlen, für deren Transaktionen Sie ein Maximum an Wiederherstellbarkeit brauchen. Sinnvoll ist SIMPLE nur für Testzwecke und in der Entwicklung sowie für kleine Datenbanken, in denen hauptsächlich gelesen wird. Ich empfehle Ihnen, für Produktionsdaten FULL oder BULK_LOGGED zu verwenden und bei Bedarf zwischen diesen beiden Modi umzuschalten.

Auswählen des Sicherungstyps

Wenn Sie dafür verantwortlich sind, einen Sicherungsplan für die Daten aufzustellen, müssen Sie sich nicht nur für ein Wiederherstellungsmodell, sondern auch für den Sicherungstyp entscheiden. Ich habe die drei Haupttypen bereits erwähnt, nämlich vollständige, differenzielle und Protokollsicherung, wobei Sie alle drei zusammen verwenden können. Um irgendeine Form von vollständiger Wiederherstellung der Daten durchführen zu können, müssen Sie gelegentlich eine vollständige Sicherung anlegen, die Sie als Ausgangspunkt für andere Arten von Sicherungen verwenden. Ergänzend können Sie zwischen differenziellen und Protokollsicherungen wählen oder eine Kombination von beiden verwenden. Als Entscheidungshilfe finden Sie hier die Merkmale dieser beiden letztgenannten Typen: Für differenzielle Sicherungen gilt: 쐍 Sie sind schneller, falls in der Umgebung viele Änderungen an denselben Daten erfolgen. Es werden nur

die jeweils letzten Änderungen gesichert, während die Protokollsicherung jede einzelne Aktualisierung erfasst. 쐍 Sie erfassen die gesamte B-Struktur für neue Indizes, während Protokollsicherungen die einzelnen Schritte

zum Aufbau des Index aufzeichnen. 쐍 Sie sind kumulativ. Bei der Wiederherstellung nach einem Medienausfall muss nur die letzte differen-

zielle Sicherung eingespielt werden, da sie alle Änderungen seit der letzten vollständigen Datenbanksicherung enthält.

231


Für Protokollsicherungen gilt: 쐍 Sie erlauben eine zeitpunktgenaue Wiederherstellung der Datenbank, da sie die gesamte Folge von Ein-

trägen für alle Änderungen enthalten. 쐍 Sie können auch noch nach dem Ausfall des Datenbankmediums angelegt werden, sofern das Protokoll

noch zur Verfügung steht. Dadurch können Sie eine Wiederherstellung genau bis zum Auftreten des Fehlers durchführen. Für die letzte Protokollsicherung (das so genannte Fragment) müssen Sie im Befehl BACKUP LOG die Option WITH NO_TRUNCATE angeben, wenn die Datenbank selbst nicht mehr zur Verfügung steht. 쐍 Sie sind sequenziell und diskret. Jede Protokollsicherung enthält völlig andere Einträge als die anderen.

Wenn Sie eine Datenbank nach einem Medienausfall anhand von Protokollsicherungen wiederherstellen, müssen Sie alle dieser Sicherungen in der Reihenfolge ihrer Erstellung wiedereinspielen.


Denken Sie daran, dass Sie komprimierte Sicherungen anlegen können, wie in Kapitel 1 kurz erwähnt wurde. Dadurch können Sie die benötigte Zeit und den erforderlichen Platz für die Sicherung (für vollständige, differenzielle und Protokollsicherungen) auf dem Sicherungsgerät deutlich verringern. Der Algorithmus für die Komprimierung von Sicherungen unterscheidet sich jedoch sehr stark von dem für die Komprimierung von Zeilen- und Seitendaten. Auf die Unterschiede gehe ich ausführlicher in Kapitel 7 ein.

Wiederherstellen einer Datenbank

Wie oft Sie die einzelnen Arten von Sicherungen durchführen, bestimmt zwei Dinge, nämlich wie schnell Sie eine Datenbank wiederherstellen können und wie viel Kontrolle Sie darüber haben, welche Transaktionen wiederhergestellt werden. Betrachten Sie den Zeitplan in Abbildung 4.5. Hier wird die Datenbank an Sonntagen vollständig gesichert und das Protokoll täglich. Differenzielle Sicherungen erfolgen jeweils Dienstag und Donnerstag. Nehmen wir jetzt an, dass am Freitag ein Laufwerksfehler auftritt. Wenn dabei die Protokolldateien nicht beeinträchtigt werden oder Sie sie mit RAID 1 auf einen Spiegel übertragen haben, sollten Sie jetzt noch das Fragment des Protokolls mit der Option NO_TRUNCATE sichern.

Protokollsicherung

Sonntag

Vollständige Datenbanksicherung

Montag

Dienstag

Differenzielle Datenbanksicherung

Mittwoch Sunday

Donnerstag

Differenzielle Datenbanksicherung

Freitag

Samstag

Abbildung 4.6 Kombinierte Verwendung von Protokoll- und differenziellen Sicherungen zur Verringerung der Wiederherstellungszeit

232

Kapitel 4:


WARNUNG Im Wiederherstellungsmodell BULK_LOGGED werden bei der Sicherung des Protokolls auch alle Daten gesichert, die durch die Massenoperation geändert wurden, sodass Sie hierbei mehr als nur die Protokolldatei zur Verfügung haben müssen, um das Protokollfragment zu sichern, nämlich auch alle Dateigruppen, in die bei der Massenoperation Daten eingefügt wurden.

Um die Datenbank nach dem Ausfall wiederherzustellen, müssen Sie zunächst die vollständige Sicherung vom Sonntag wiedereinspielen. Dabei geschieht zweierlei: Alle Daten-, Index- und Protokollblöcke werden von dem Sicherungsmedium in die Datenbankdateien kopiert, und alle Transaktionen im Protokoll werden angewandt. Sie müssen entscheiden, ob unvollständige Transaktionen mit einem Rollback zurückgenommen werden sollen. Dazu geben Sie im Befehl RESTORE die Option WITH RECOVERY an, wodurch unvollständige Transaktionen aufgehoben werden und die Datenbank für die Verwendung geöffnet wird. Weitere Wiederherstellungen sind dann nicht möglich. Sollen unvollständige Transaktionen nicht zurückgenommen werden, geben Sie die Option WITH NORECOVERY an. Die Datenbank bleibt dann in einem inkonsistenten Zustand und ist nicht verwendbar.


Wenn Sie WITH NORECOVERY wählen, können Sie anschließend die nächste Sicherung anwenden. In der Situation aus Abbildung 4.5 stellen Sie die differenzielle Sicherung vom Donnerstag wieder her, wodurch alle geänderten Blöcke in die Datendateien kopiert werden. Die differenzielle Sicherung schließt auch die Protokolleinträge für den Zeitraum ein, in dem der Sicherungsvorgang lief, sodass Sie wieder entscheiden müssen, ob die Datenbank abgeglichen werden soll. Vollständige Transaktionen werden stets wiedereingespielt, aber Sie müssen angeben, ob unvollständige zurückgenommen werden sollen. Nach der Wiederherstellung der differenziellen Sicherung müssen Sie anschließend die Protokollsicherungen, die danach angelegt wurden, in der richtigen Reihenfolge anwenden. Dazu gehört auch das Protokollfragment, dass Sie ggf. nach dem Ausfall gesichert haben. HINWEIS Die Medienwiederherstellung (recovery, also der Abgleich) ähnelt der Neustartwiederherstellung, die ich weiter vorn in diesem Kapitel beschrieben habe, doch dies ist ein reiner Rollforwardvorgang. Es wird eine Analyse durchgeführt, um zu sehen, wie viel Arbeit zu erledigen ist, und dann ein Rollforwarddurchlauf, um vollständige Transaktionen wiedereinzuspielen und die Datenbank in den Zustand zurückzuversetzen, den sie beim Abschluss der Sicherung hatte. Anders als bei der Neustartwiederherstellung können Sie steuern, wann das Rollback erfolgt. Es sollte nicht durchgeführt werden, bevor das Rollforward für alle Sicherungen geschehen ist. Sobald Sie nach dem Rollforwarddurchlauf RESTORE WITH RECOVERY angeben, wird die Datenbank neu gestartet, wobei SQL Server die Neustartwiederherstellung durchführt, um unvollständige Transaktionen zurückzunehmen. Außerdem muss SQL Server unter Umständen nach dem vollständigen Abgleich einige Metadaten anpassen, weshalb der Zugriff auf die Datenbank erst nach dem Abschluss aller Phasen dieser Wiederherstellung möglich ist. Mit anderen Worten, Sie können bei RESTORE keine Option für die »schnelle« Wiederherstellung angeben.

Sichern und Wiederherstellen von Dateien und Dateigruppen In SQL Server 2008 können Sie auch einzelne Dateien und Dateigruppen sichern. Das ist vor allem bei extrem großen Datenbanken sinnvoll, bei denen Sie dann einfach jeden Tag eine andere Datei oder Dateigruppe sichern können, sodass Sie diesen Vorgang für die Gesamtdatenbank nicht so häufig ausführen müssen. Auch wenn sich ein Medienfehler nur auf ein einziges Laufwerk beschränkt und die Wiederherstellung der gesamten Datenbank zu lange dauern würde, ist diese Möglich von großem Nutzen.


233

Beachten Sie beim Sichern und Wiederherstellen von Dateien und Dateigruppen folgende Punkte: 쐍 Beschreibbare Dateien und Dateigruppen können nur dann gesichert werden, wenn sich die Datenbank

im Wiederherstellungsmodus FULL oder BULK_LOGGED befindet, da Sie nach der Wiederherstellung einer Datei oder Dateigruppe die Protokollsicherungen einspielen müssen, die Sie im Modus SIMPLE nicht anlegen können. Schreibgeschützte Dateigruppen und die Dateien darin lassen sich jedoch im Modus SIMPLE sichern. 쐍 Sie können auch aus einer vollständigen Datenbanksicherung einzelne Dateien und Dateigruppen wie-

derherstellen. 쐍 Unmittelbar vor der Wiederherstellung einer einzelnen Datei oder Dateigruppe müssen Sie das Transak-

tionsprotokoll sichern, denn Sie brauchen eine ununterbrochene Kette von Protokollsicherungen seit dem Zeitpunkt, an dem die Datei oder Dateigruppe gesichert wurde. 쐍 Nach der Wiederherstellung einer Dateigruppen- oder Dateisicherung müssen Sie alle Transaktionspro-


tokolle zwischen dem Anlegen der Sicherung und der Wiederherstellung anwenden. Dadurch stellen Sie sicher, dass die wiederhergestellten Dateien mit dem Rest der Datenbank synchron sind. Nehmen wir an, Sie haben die Dateigruppe FG1 am Montag um 10.00 Uhr gesichert. Die Datenbank wird weiterhin verwendet, wobei Transaktionen verarbeitet werden, die Daten in FG1 und anderen Dateigruppen ändern. Sie sichern das Protokoll um 16.00 Uhr. Daraufhin laufen weitere Transaktionen ab, die Daten in FG1 und anderen Dateigruppen ändern. Um 18.00 Uhr verlieren Sie aufgrund eines Medienfehlers eine oder mehrere der Dateien, aus denen sich FG1 zusammensetzt. Um die Wiederherstellung durchführen zu können, müssen Sie zunächst das Fragment des Protokolls mit den Änderungen sichern, die zwischen 16.00 und 18.00 Uhr stattfanden. Dabei verwenden Sie die Option WITH NO_TRUNCATE, Sie können aber auch WITH NORECOVERY angeben. In letzterem Fall wird die Datenbank in den Zustand RESTORING versetzt, was verhindert, dass sich versehentliche Änderungen im Hintergrund störend auf den Wiederherstellungsvorgang auswirken. FG1 können Sie wiederherstellen, indem Sie den Befehl RESTORE DATABASE verwenden und dabei nur die betreffende Dateigruppe angeben. Die Datenbank befindet sich danach nicht in einem konsistenten Zustand, da die wiederhergestellte Dateigruppe FG1 nur die bis 10.00 vorgenommenen Änderungen enthält, der Rest der Datenbank aber die Änderungen bis 18.00 Uhr. SQL Server weiß aber, wann die letzte Änderung an der Datenbank erfolgt ist, da auf jeder Seite in einer Datenbank die LSN des Protokolleintrags zu dieser Änderung gespeichert ist. Beim Wiederherstellen einer Dateigruppe merkt sich SQL Server die höchste LSN in der Datenbank. Sie müssen die Protokollsicherungen einspielen, bis mindestens diese höchste LSN in der Datenbank erreicht ist, und das ist erst der Fall, wenn Sie die Protokollsicherung von 18.00 Uhr anwenden.

Teilsicherungen Eine Teilsicherung kann als vollständige oder differenzielle Sicherung erfolgen, umfasst aber nicht alle Dateigruppen, sondern nur die Daten in der primären und allen beschreibbaren Dateigruppen. Außerdem können Sie schreibgeschützte Dateien angeben, die ebenfalls gesichert werden sollen. Wenn die gesamte Datenbank als schreibgeschützt gekennzeichnet ist, enthält eine Teilsicherung nur die primäre Dateigruppe. Teilsicherungen sind vor allem bei sehr großen Datenbanken im Wiederherstellungsmodus SIMPLE nützlich, da Sie damit einzelne Dateigruppen sichern können, ohne Protokollsicherungen vornehmen zu müssen.

234

Kapitel 4:


Seitenwiederherstellung In SQL Server 2008 können Sie auch einzelne Seiten wiederherstellen. Wenn SQL Server eine beschädigte Seite erkennt, kennzeichnet er sie als verdächtig und legt Informationen über sie in der Tabelle suspect_pages der Datenbank msdb ab. Beschädigte Seiten können in folgenden Situationen erkannt werden: 쐍 Eine Abfrage muss eine Seite lesen. 쐍 DBCC CHECKDB oder DBCC CHECKTABLE wird ausgeführt. 쐍 BACKUP oder RESTORE wird ausgeführt. 쐍 Sie versuchen, eine Datenbank mit DBCC DBREPAIR zu reparieren.


Verschiedene Arten von Fehlern können es erforderlich machen, eine Seite als verdächtig zu kennzeichnen und in die Tabelle suspect_pages einzutragen. Dazu gehören Prüfsummenfehler und zerrissene Seiten sowie interne Konsistenzprobleme wie eine beschädigte Seitenkennung im Seitenheader. Die Spalte event_type in der Tabelle suspect_pages gibt den Grund für den Zustand der Seite und ihre Aufnahme in die Tabelle suspect_pages an. In der SQL Server-Onlinedokumentation werden die folgenden möglichen Werte für die Spalte event_type aufgeführt: Wert von event_type

Beschreibung

1

Fehler 823 aufgrund eines CDC-Fehlers des Betriebssystems oder Fehler 824 aufgrund einer anderen Ursache als einer falschen Prüfsumme oder einer zerrissenen Seite (z.B. beschädigte Seitenkennung)

2

Falsche Prüfsumme

3

Zerrissene Seite

4

Wiederhergestellt (Die Seite wurde wiederhergestellt, nachdem sie als beschädigt gekennzeichnet worden war.)

5

Repariert (DBCC hat die Seite repariert.)

7

Zuweisung durch DBCC aufgehoben

Einige der von suspect_pages aufgezeichneten Fehler können vorübergehender Natur sein, z.B. ein E/A-Fehler aufgrund eines herausgezogenen Kabels. Personen mit den entsprechenden Berechtigungen, z.B. Administratoren mit der Serverrolle sysadmin, können Zeilen aus dieser Tabelle löschen. Außerdem erfordert nicht jeder Fehler, der in suspect_pages eingetragen wird, die Seite wiederherzustellen. Ein Problem in zwischengespeicherten Daten, z.B. in einem nicht gruppierten Index, kann durch Neuerstellung des Index gelöst werden. Falls ein Mitglied der Rolle sysadmin einen nicht gruppierten Index löscht und neu erstellt, werden die beschädigten Daten repariert, was aber in der Tabelle suspect_pages nicht angezeigt wird. Die Seitenwiederherstellung dient eigens dazu, Seiten zu ersetzen, die aufgrund einer ungültigen Prüfsumme oder eines zerrissenen Schreibvorgangs als verdächtig gekennzeichnet wurden. Zwar können Sie mehrere Datenbankseiten auf einmal wiederherstellen, doch ist es nicht sinnvoll, viele einzelne Seiten zu ersetzen. Wenn es viele beschädigte Seiten gibt, sollten Sie lieber eine vollständige Datei- oder Datenbankwiederherstellung durchführen. Außerdem sollten Sie die Ursache der Fehler herausfinden. Entdecken Sie beispielsweise Hinweise auf einen bevorstehenden Geräteausfall, sollten Sie die Wiederherstellung der Datei oder Datenbank an einem anderen Speicherort vornehmen. Nach der Seitenwiederherstellung müssen Sie eine


235

Protokollwiederherstellung vornehmen, um die neuen Seiten auf den Stand der restlichen Datenbank zu bringen. Wie bei Dateiwiederherstellungen werden die Protokollsicherungen auf die Datenbankdateien angewandt, die wiederhergestellte Seiten enthalten. Während einer Onlineseitenwiederherstellung bleibt die Datenbank online, nur die wiederhergestellten Daten sind offline. Es können jedoch nicht alle beschädigten Seiten wiederhergestellt werden, während die Datenbank online bleibt. HINWEIS

Die Onlineseitenwiederherstellung ist nur in SQL Server 2008 Enterprise Edition möglich.


In der SQL Server-Onlinedokumentation werden die folgenden grundlegenden Schritte für eine Seitenwiederherstellung angegeben: 1. Finden Sie die Kennungen der beschädigten und wiederherzustellenden Seiten heraus, um im weiteren Verlauf des Vorgangs auf die Seiten verweisen zu können. In einer Fehlermeldung aufgrund einer falschen Prüfsumme oder einer zerrissenen Seite wird die Seitenkennung angegeben, Sie können sie aber auch in der Tabelle suspect_pages finden. 2. Beginnen Sie die Seitenwiederherstellung mit einer vollständigen, einer Dateigruppen- oder einer Dateisicherung, die die betreffenden Seiten enthält. Dazu führen Sie in der Anweisung RESTORE DATABASE in der Klausel PAGE die Kennungen aller wiederherzustellenden Seiten auf. In einer einzigen Datei können Sie höchstens 1000 Seiten wiederherstellen. 3. Wenden Sie alle verfügbaren differenziellen Sicherungen für die wiederherzustellenden Seiten an. 4. Wenden Sie alle nachfolgenden Protokollsicherungen an. 5. Erstellen Sie eine neue Protokollsicherung der Datenbank, die die letzte LSN der wiederhergestellten Seiten enthält, also den Punkt, an dem die letzte wiederhergestellte Datei offline geschaltet wurde. Die letzte LSN, die als Teil des ersten Wiederherstellungsvorgangs in dieser Abfolge gesetzt wurde, ist die Ziel-LSN für die Rollforwardphase. Das Onlinerollforward der Datei mit der betreffenden Seite kann an dieser Ziel-LSN enden. In der Spalte Rollforward_target_lsn von sys.master_files finden Sie jeweils die aktuelle Ziel-LSN für das Rollforward. 6. Stellen Sie die neue Protokollsicherung wieder her. Sobald Sie diese Sicherung angewendet haben, ist die Seitenwiederherstellung abgeschlossen und die Seite verwendbar. Die Seitenwiederherstellung wirkt sich auf alle beschädigten Seiten aus. Alle anderen Seiten tragen in ihrem Header eine jüngere LSN, weshalb sie in der Rollforwardphase nicht erfasst werden. Eine Rollbackphase gibt es bei der Seitenwiederherstellung nicht.

Teilwiederherstellung In Notfallsituationen können Sie in SQL Server 2008 eine Teilwiederherstellung einer Datenbank vornehmen. Beschreibung und Syntax ähneln zwar der für die Sicherung und Wiederherstellung von Dateien und Dateigruppen, doch gibt es einen großen Unterschied. Wenn Sie Dateien und Dateigruppen wiederherstellen, gehen Sie von einer vollständigen Datenbank aus und ersetzen darin eine oder mehrere Dateien oder Dateigruppen durch zuvor gesicherte Versionen. Bei der Teilversion haben Sie keine vollständige Datenbank als Ausgangspunkt, sondern stellen einzelne Dateigruppen an einem anderen Speicherort wieder her. Die primäre Dateigruppe, die alle Systemtabellen enthält, muss dabei sein. Dateigruppen, die Sie nicht wiederherstellen, werden als offline behandelt, wenn Sie versuchen, auf die Daten darin zu verweisen. Sie können

236

Kapitel 4:


Protokoll- und differenzielle Sicherungen wiederherstellen, um die Daten in den Dateigruppen auf den Zustand an einem späteren Zeitpunkt zu bringen. Damit haben Sie die Möglichkeit, Daten einer Teilmenge von Tabellen nach einer versehentlichen Löschung oder Änderung der Tabellendaten wiederherzustellen, indem Sie die Daten der verlorenen Tabellen aus der teilweise wiederhergestellten Datenbank entnehmen und in die ursprüngliche Datenbank zurückkopieren.

Wiederherstellung mit STANDBY Bei der normalen Wiederherstellung haben Sie die Wahl, ob Sie anschließend den Abgleichvorgang (recovery) ausführen, um nicht abgeschlossene Transaktionen aufzuheben, oder nicht. Wenn Sie den Abgleich durchführen, können Sie keine weiteren Protokollsicherungen einspielen, aber die Datenbank ist vollständig nutzbar. Verzichten Sie auf den Abgleich, ist die Datenbank inkonsistent, sodass SQL Server Ihnen nicht gestattet, sie zu benutzen. Aufgrund der Art und Weise, wie Protokollsicherungen angelegt werden, müssen Sie sich jeweils für eine dieser beiden Möglichkeiten entscheiden.


Beispielsweise überlappen Protokollsicherungen in SQL Server 2008 einander nicht. Jede Protokollsicherung beginnt dort, wo die vorhergehende endet. Stellen Sie sich eine Transaktion vor, die an einer einzigen Tabelle Hunderte von Aktualisierungen vornimmt. Wenn Sie das Protokoll während und nach der Aktualisierung sichern, enthält das erste Protokoll den Anfang der Transaktion sowie einige der Aktualisierungen und das zweite die restlichen Aktualisierungen und den Commit. Nehmen wir jetzt an, dass Sie diese Protokollsicherungen nach der Wiederherstellung der kompletten Datenbank anwenden müssen. Wenn Sie nach der Wiederherstellung der ersten Protokollsicherung einen Abgleich durchführen, wird die Transaktion zurückgenommen. Falls Sie dann versuchen sollten, die zweite Protokollsicherung einzuspielen, würde sie in der Mitte einer Transaktion beginnen, sodass SQL Server keine Informationen über deren Anfang hätte. An dieser Stelle ist ein weiterer Abgleich der Transaktionen nicht möglich, da die erforderlichen Operationen wahrscheinlich von Aktualisierungen abhängen, die Sie zum Teil verloren haben. Aus diesem Grund lässt SQL Server keine weiteren Wiederherstellungen zu. Die Alternative besteht darin, keinen Abgleich durchzuführen, um den ersten Teil der Transaktion zurückzunehmen, sondern diese Transaktion stattdessen unvollständig zu lassen. SQL Server bemerkt, dass die Datenbank inkonsistent ist, und erlaubt keinem Benutzer, sie zu verwenden, bis Sie sie endgültig wiederhergestellt haben. Lassen sich diese beiden Ansätze vielleicht kombinieren? Es wäre schön, wenn Sie eine Protokollsicherung wiederherstellen und sich dann die Daten ansehen könnten, bevor Sie weitere Protokollsicherungen einspielen, vor allem, wenn Sie eine zeitpunktgenaue Wiederherstellung versuchen, aber den richtigen Zeitpunkt nicht kennen. In SQL Server gibt es die Option STANDBY, mit der Sie einen Abgleich der Datenbank vornehmen und trotzdem weitere Protokollsicherungen anwenden können. Wenn Sie bei der Wiederherstellung einer Protokollsicherung WITH STANDBY = '' angeben, nimmt SQL Server unvollständige Transaktionen zurück, vermerkt die dabei ausgeführten Vorgänge aber in einer so genannten Standbydatei. Bei einem nachfolgenden Wiederherstellungsvorgang wird die Standbydatei gelesen, um die zurückgenommenen Operationen wieder anzuwenden, bevor das nächste Protokoll wiederhergestellt wird. Falls für diese Wiederherstellung ebenfalls WITH STANDBY angegeben ist, werden unvollständige Transaktionen ebenfalls zurückgenommen, aber ein Bericht über diesen Vorgang aufgezeichnet. Nach der Wiederherstellung mit der Option WITH STANDBY können Sie keine Daten ändern (SQL Server gibt eine Fehlermeldung aus, wenn Sie das versuchen), aber Sie können sie lesen und mit der Wiederherstellung weiterer Protokolle fortfahren. Das letzte Protokoll muss mit der Option WITH RECOVERY wiederhergestellt werden (ohne Standbydatei), damit die Datenbank vollständig verwendbar ist.

237

Zusammenfassung

Zusammenfassung


Neben den Datendateien weist jede Datenbank in einer SQL Server-Instanz mindestens eine Protokolldatei auf, in der Änderungen an der Datenbank nachverfolgt werden. (Datenbanksnapshots haben jedoch keine Protokolldateien, da unmittelbar an ihnen keine Änderungen vorgenommen werden.) SQL Server verwendet das Transaktionsprotokoll, um die Konsistenz der Daten sowohl logisch als auch physisch sicherzustellen. Außerdem können Administratoren das Transaktionsprotokoll sichern, was eine effizientere Datenbankwiederherstellung ermöglicht. Administratoren und Datenbankbesitzer können außerdem das Wiederherstellungsmodell für die Datenbank festlegen, um zu bestimmen, wie ausführlich das Transaktionsprotokoll geführt wird.
