Zur Hauptseite ... Zum Onlinearchiv ... Zum Abonnement ... Zum Newsletter ... Zu den Tools ... Zum Impressum ... Zum Login ...

Achtung: Dies ist nicht der vollständige Artikel, sondern nur ein paar Seiten davon. Wenn Sie hier nicht erfahren, was Sie wissen möchten, finden Sie am Ende Informationen darüber, wie Sie den ganzen Artikel lesen können.

Kompletten Artikel lesen?

Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

E-Mail:

Gedrucktes Heft

Diesen Beitrag finden Sie in Ausgabe 2/2007.

Unser Angebot für Sie!

Lesen Sie diesen Beitrag und 500 andere sofort im Onlinearchiv, und erhalten Sie alle zwei Monate brandheißes Access-Know-how auf 72 gedruckten Seiten! Plus attraktive Präsente, zum Beispiel das bald erscheinende Buch 'Access 2010 - Das Grundlagenbuch für Entwickler'!

Diesen Beitrag twittern

Zusammenfassung

Konfigurieren Sie eine Datensicherung, die im Falle eines Crashs den Datenverlust minimiert.

Techniken

SQL Server Management Studio Express, T-SQL, Taskplaner

Voraussetzungen

SQL Server Express Edition Advanced oder SQL Server Express Edition mit SQL Server Management Studio Express

Beispieldatei

-

Shortlink

545

Datensicherung mit dem MS SQL Server

Bernd Jungbluth, Horn

Datenbanken enthalten wertvolle und relevante Daten eines Unternehmens. Aus diesem Grund ist eine Datensicherung dieser Daten unabdingbar. Dies gilt auch für die Datenbanken des Microsoft SQL Servers. Mit einer normalen Systemsicherung jedoch können die Datenbankdateien des SQL Servers nicht gesichert werden, da die Dateien durch den permanenten Zugriff des SQL Servers für das Sicherungsprogramm gesperrt sind. So stellt sich also die Frage, wie Sie die Datenbankdateien dennoch sichern können.

Die Lösung ist recht simpel: Die Datenbanksicherung wird vom SQL Server selbst ausgeführt und die daraus resultierenden Sicherungsdateien werden von der Systemsicherung archiviert. SQL Server bietet für die Sicherung der Datenbanken umfangreiche Funktionen und ermöglicht dadurch verschiedene Sicherungsstrategien.

Die Sicherungstypen des SQL Servers

Wie auch bei den Sicherungen der Backup-Systeme gibt es beim SQL Server die beiden Sicherungstypen Vollsicherung und differenzielle Sicherung. Während die Vollsicherung immer die komplette Datenbank sichert, werden bei der differenziellen Sicherung nur die Änderungen seit der letzten Vollsicherung beziehungsweise der letzten differenziellen Sicherung berücksichtigt.

Ergänzend zu diesen beiden Sicherungstypen gibt es noch die Transaktionsprotokollsicherung (weitere Informationen siehe Kasten). Diese ist jedoch abhängig vom Wiederherstellungsmodell der Datenbank.

Microsoft SQL Server bietet die Wiederherstellungsmodelle Vollständig, Einfach und Massenprotokolliert, die Sie in den Datenbankoptionen definieren können.

Anhand dieser drei Modelle regeln Sie den Umfang der Transaktionsprotokollierung - und damit auch den im Falle eines Crashs möglichen Datenverlust.

Die Wiederherstellungsmodelle

Welches Wiederherstellungsmodell für Ihre Datenbank sinnvoll ist, können nur Sie selbst entscheiden. Beim Wiederherstellungsmodell Vollständig werden alle Aktionen im Transaktionsprotokoll gespeichert, während bei Massenprotokolliert von bestimmten Aktionen wie Massenimporten lediglich die einzelnen Batches des Massenimports im Transaktionsprotokoll festgehalten werden. Einfach geht sogar noch einen Schritt weiter und speichert keine der Aktionen im Transaktionsprotokoll. Eine Transaktionsprotokollsicherung kann also nur bei den Wiederherstellungsmodellen Vollständig und Massenprotokolliert konfiguriert werden.

Brauchen Sie denn überhaupt eine Transaktionsprotokollsicherung? Auch das können wieder nur Sie selbst entscheiden. Es kommt auf Ihre Datenbank oder vielmehr auf das Einsatzgebiet Ihrer Datenbank an. Wenn Sie bei einem Crash der Datenbank mit der letzten Vollsicherung beziehungsweise der letzten differenziellen Sicherung zufrieden sind, dann benötigen Sie keine Transaktionsprotokollsicherung. Können Sie aber auf die seit der letzten Sicherung erfassten oder geänderten Daten nicht verzichten, wird die Transaktionsprotokollsicherung interessant. Denn damit können Sie alle Transaktionen seit der letzten Vollsicherung beziehungsweise der letzten differenziellen Sicherung ebenfalls sichern und anhand dieser die Transaktionen wieder ausführen lassen.

Wenn Sie nun beispielsweise täglich eine Vollsicherung und alle 15 Minuten eine Transaktionsprotokollsicherung ausführen lassen, können Sie nach einem Crash durch die Wiederherstellung der Vollsicherung und der einzelnen Transaktionsprotokollsicherungen die Daten bis zum Zeitpunkt der letzten Transaktionsprotokollsicherung wiederherstellen. Im schlimmsten Fall fehlen bei dieser Konfiguration die Datenänderungen der letzten 15 Minuten. Sofern Sie bei dem Crash noch die Möglichkeit haben, manuell eine Transaktionsprotokollsicherung zu erstellen, können Sie die Daten sogar bis zum Zeitpunkt des Crashs wiederherstellen. Dieses Szenario wird von den Wiederherstellungsmodellen Vollständig und Massenprotokolliert unterstützt und funktioniert natürlich auch in der Kombination Vollsicherung mit differenziellen Sicherungen plus Transaktionsprotokollsicherungen.

Es ist auch möglich, mit der Transaktionsprotokollsicherung eine Datenbank bis zu einem bestimmten Zeitpunkt wiederherzustellen. Dieses Feature wird aber nur vom Wiederherstellungsmodell Vollständig unterstützt.

Transaktionsprotokollsicherungen machen also durchaus Sinn.

Sicherungstypen kombinieren

Nun haben Sie drei Sicherungstypen des SQL Servers kennen gelernt. Bleibt die Frage offen, wann Sie welche Methode beziehungsweise welche Kombination einsetzen. Auf diese Frage gibt es keine Pauschalantwort, da es auch hier wieder auf den Zweck und Inhalt der Datenbank ankommt.

Wann eine Transaktionsprotokollsicherung Sinn macht, haben Sie bereits erfahren - und eine Vollsicherung ist die Basissicherung, an der kein Weg vorbeiführt.

Bleibt noch die differenzielle Sicherung: Sie ist eine Option, die meist bei relativ großen Datenbanken eingesetzt wird, da hierbei nur die Änderungen seit der letzten Vollsicherung beziehungsweise der letzten differenziellen Sicherung gespeichert werden. Bei großen Datenbanken wird die Vollsicherung meist zu "downtimes" - also wenn die Datenbank nicht voll ausgelastet ist - ausgeführt, um während der Sicherung nicht die Antwortzeiten der Datenbank zu verschlechtern. Zusätzlich zur Vollsicherung werden dann im "normalen" Betrieb eine oder sogar mehrere differenzielle Sicherungen gestartet.

So könnte eine Vollsicherung jede Nacht und eine differenzielle Sicherung um die Mittagszeit eine Variante sein. Benötigt die Vollsicherung länger als die in der Nacht verfügbaren Stunden, könnte diese auch nur am Wochenende erfolgen und täglich eine oder mehrere differenzielle Sicherungen ausgeführt werden. Beides kann mit den Transaktionsprotokollsicherungen kombiniert werden. Je kleiner die zu sichernden Datenmengen sind, desto kürzer ist der Sicherungsvorgang und umso geringer der damit verbundene Perfomanceverlust. Pro Sicherung wird aber auch ein Sicherungssatz erzeugt, was im Fall der Fälle eine Wiederherstellung der Datenbank aufwändiger gestaltet. Hier ist der Spagat zwischen einem performanten System und schneller Wiederverfügbarkeit nach einem Crash zu meistern.

Wo ist der SQL Server Agent?

Um es direkt vorwegzunehmen: Den SQL Server Agent gibt es im Gegensatz zur MSDE in der SQL Server 2005 Express Edition (SSEE) nicht mehr. Dieser nützliche Helfer war dafür zuständig, bestimmte Aufträge zu definierten Zeiten auszuführen. Für Datenbanksicherungen ein optimaler und in der SSEE auch schmerzlich vermisster Dienst. Um die Sicherungsaufträge zu bestimmten Zeitpunkten automatisch ausführen zu lassen, bleibt Ihnen bei der SSEE nur der Umweg über das Betriebssystem-Tool Geplante Tasks. Dafür steht Ihnen mit der SSEE nun endlich ein Verwaltungstool - das SQL Server Management Studio Express (SSMSE) - zur Verfügung. Sie müssen also nicht mehr die Datensicherung mit T-SQL-Skripten ansteuern, sondern starten diese direkt aus dem SSMSE. Natürlich können Sie auch weiterhin die T-SQL-Befehle nutzen.

Wiederherstellungsmodell ändern

In den folgenden Abschnitten erfahren Sie, wie Sie Vollsicherungen, differenzielle Sicherungen und Transaktionsprotokollsicherungen konfigurieren und manuell oder automatisch über Geplante Tasks starten.

Als Beispieldatenbank wird hierfür die gute alte Northwind-Datenbank genutzt. Die Beispiele können aber auch mit jeder x-beliebigen Datenbank nachvollzogen werden.

Die Northwind-Datenbank des SQL Servers (nicht zu verwechseln mit der Access-Version) nutzt in der Standardeinstellung das Wiederherstellungsmodell Einfach. Für die folgenden Beispiele benötigen Sie aber das Modell Vollständig.

Das Wiederherstellungsmodell einer Datenbank ändern Sie im Dialog Eigenschaften, den Sie über den gleichnamigen Kontextmenübefehl der Datenbank öffnen. In diesem Dialog wechseln Sie zur Seite Optionen und wählen dort im Listenfeld Wiederherstellungsmodell den Eintrag Vollständig aus (Abb. 1). Nun sind die Voraussetzungen für das Beispiel geschaffen und Sie können mit der Sicherung beginnen, an der es kein Vorbeikommen gibt - der Vollsicherung.

pic001.tif

Abb. 1: Wiederherstellungsmodell einer SQL Server-Datenbank ändern

Die Vollsicherung

Eine Vollsicherung ist - wie bereits erwähnt - die Basis für weitere differenzielle Sicherungen wie auch für die Transaktionsprotokollsicherungen.

Um nun für die Northwind-Datenbank eine Vollsicherung zu konfigurieren und auch auszuführen, markieren Sie die Datenbank und wählen aus ihrem Kontextmenü den Befehl Task/Sichern. Der Dialog Datenbank sichern wird geöffnet.

Dort bestimmen Sie im Listenfeld Sicherungstyp die Art der Sicherung. In diesem Fall können Sie für die Vollsicherung den Eintrag Vollständig beibehalten.

Mit dieser Sicherung soll die komplette Datenbank gesichert werden. Aus diesem Grund behalten Sie die Auswahl Datenbank in der Gruppe Sicherungskomponente bei. Alternativ zur kompletten Datenbank können Sie auch einzelne Dateien und Dateigruppen einer Datenbank sichern. Dies macht besonders bei großen Datenbanken Sinn, die in der Regel aus mehreren Datenbank- und Transaktionsprotokoll-Dateien bestehen.

Bei jeder Sicherung wird ein Sicherungssatz erstellt, dem Sie in der Gruppe Sicherungssatz einen Namen und eine Beschreibung geben können.

Ein Sicherungssatz ist das Ergebnis einer Sicherung und beinhaltet neben Informationen über den Sicherungsvorgang auch die gesicherten Daten.

Jeder Sicherungssatz kann in einer eigenen Datei gespeichert werden oder aber es können mehrere Sicherungssätze in einer Datei zusammengefasst werden. Dabei ist es einerlei, ob es sich bei den Sicherungen um Vollsicherungen, differenzielle Sicherungen oder Transaktionsprotokollsicherungen handelt. Auch der Zeitraum ist unerheblich. So können durchaus Sicherungen von mehreren Tagen in einer Datei zusammenfasst werden.

Sie haben das Ende des frei verfügbaren Teils des Artikels erreicht. Lesen Sie weiter, um zu erfahren, wie Sie den vollständigen Artikel lesen und auf viele hundert weitere Artikel zugreifen können.

Sind Sie Abonnent?Jetzt einloggen ...
 

Kompletten Artikel lesen?

Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

E-Mail:

Verwandte Beiträge:

Anmeldung an SQL Server und Co.

Gespeicherte Prozeduren

Der DBMS-Connection-Wizard

Upsizing von Access nach SQL Server: Tabellen

Benutzerdefinierte Funktionen im MS SQL Server

Trigger

Access, MySQL und Berechtigungsverwaltung

DBMS-unabhängiger Zugriff auf SQL Server und Co.

Abfragen von Access zum SQL Server

© 2003-2015 André Minhorst Alle Rechte vorbehalten.