<\/p>\n
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.<\/b><\/p>\n
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.<\/p>\n
Wie auch bei den Sicherungen der Backup-Systeme gibt es beim SQL Server die beiden Sicherungstypen Vollsicherung <\/b>und differenzielle Sicherung<\/b>. 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. <\/p>\n
Ergänzend zu diesen beiden Sicherungstypen gibt es noch die Transaktionsprotokollsicherung (weitere Informationen siehe Kasten). Diese ist jedoch abhängig vom Wiederherstellungsmodell der Datenbank.<\/p>\n
Microsoft SQL Server bietet die Wiederherstellungsmodelle Vollständig<\/b>, Einfach <\/b>und Massenprotokolliert<\/b>, die Sie in den Datenbankoptionen definieren können.<\/p>\n
Anhand dieser drei Modelle regeln Sie den Umfang der Transaktionsprotokollierung – und damit auch den im Falle eines Crashs möglichen Datenverlust.<\/p>\n
Welches Wiederherstellungsmodell für Ihre Datenbank sinnvoll ist, können nur Sie selbst entscheiden. Beim Wiederherstellungsmodell Vollständig <\/b>werden alle Aktionen im Transaktionsprotokoll gespeichert, während bei Massenprotokolliert <\/b>von bestimmten Aktionen wie Massenimporten lediglich die einzelnen Batches des Massenimports im Transaktionsprotokoll festgehalten werden. Einfach <\/b>geht sogar noch einen Schritt weiter und speichert keine der Aktionen im Transaktionsprotokoll. Eine Transaktionsprotokollsicherung kann also nur bei den Wiederherstellungsmodellen Vollständig <\/b>und Massenprotokolliert <\/b>konfiguriert werden. <\/p>\n
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. <\/p>\n
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 <\/b>und Massenprotokolliert <\/b>unterstützt und funktioniert natürlich auch in der Kombination Vollsicherung mit differenziellen Sicherungen plus Transaktionsprotokollsicherungen.<\/p>\n
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 <\/b>unterstützt.<\/p>\n
Transaktionsprotokollsicherungen machen also durchaus Sinn.<\/p>\n
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. <\/p>\n
Wann eine Transaktionsprotokollsicherung Sinn macht, haben Sie bereits erfahren – und eine Vollsicherung ist die Basissicherung, an der kein Weg vorbeiführt. <\/p>\n
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.<\/p>\n
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.<\/p>\n
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<\/b>. 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.<\/p>\n
Wiederherstellungsmodell ändern<\/p>\n
In den folgenden Abschnitten erfahren Sie, wie Sie Vollsicherungen, differenzielle Sicherungen und Transaktionsprotokollsicherungen konfigurieren und manuell oder automatisch über Geplante Tasks <\/b>starten.<\/p>\n
Als Beispieldatenbank wird hierfür die gute alte Northwind-Datenbank genutzt. Die Beispiele können aber auch mit jeder x-beliebigen Datenbank nachvollzogen werden. <\/p>\n
Die Northwind-Datenbank des SQL Servers (nicht zu verwechseln mit der Access-Version) nutzt in der Standardeinstellung das Wiederherstellungsmodell Einfach<\/b>. Für die folgenden Beispiele benötigen Sie aber das Modell Vollständig<\/b>. <\/p>\n
Das Wiederherstellungsmodell einer Datenbank ändern Sie im Dialog Eigenschaften<\/b>, den Sie über den gleichnamigen Kontextmenübefehl der Datenbank öffnen. In diesem Dialog wechseln Sie zur Seite Optionen <\/b>und wählen dort im Listenfeld Wiederherstellungsmodell <\/b>den Eintrag Vollständig <\/b>aus (siehe Bild 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.<\/p>\n
![\"pic001.tif\"](\"..\/fileadmin\/_temp_\/2007_02\/SicherungVonSQLServerDatenbanken-web-images\/pic001_opt.jpeg\")
<\/p>\n
Bild 1: Wiederherstellungsmodell einer SQL Server-Datenbank ändern<\/span><\/b><\/p>\n Eine Vollsicherung ist – wie bereits erwähnt – die Basis für weitere differenzielle Sicherungen wie auch für die Transaktionsprotokollsicherungen. <\/p>\n 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<\/b>. Der Dialog Datenbank sichern <\/b>wird geöffnet.<\/p>\n Dort bestimmen Sie im Listenfeld Sicherungstyp <\/b>die Art der Sicherung. In diesem Fall können Sie für die Vollsicherung den Eintrag Vollständig <\/b>beibehalten. <\/p>\n Mit dieser Sicherung soll die komplette Datenbank gesichert werden. Aus diesem Grund behalten Sie die Auswahl Datenbank <\/b>in der Gruppe Sicherungskomponente <\/b>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.<\/p>\n Bei jeder Sicherung wird ein Sicherungssatz erstellt, dem Sie in der Gruppe Sicherungssatz <\/b>einen Namen und eine Beschreibung geben können.<\/p>\n Ein Sicherungssatz ist das Ergebnis einer Sicherung und beinhaltet neben Informationen über den Sicherungsvorgang auch die gesicherten Daten. <\/p>\n 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.<\/p>\n <\/p>\n Der Vorteil einer einzigen Datei liegt auf der Hand: Alle Sicherungssätze sind in einer Datei versammelt, was die Wiederherstellung einer Datenbank vereinfacht. <\/p>\n Der Nachteil ist allerdings auch nicht zu übersehen: Ist diese Datei korrupt oder „aus unerklärli-chen Gründen“ verschwunden, gibt es auch keine Möglichkeit der Wiederherstellung. <\/p>\n Ein weiterer Nachteil ist die mit jeder Sicherung zunehmende Größe der Sicherungsdatei. Mit den Optionen in der Gruppe Sicherungssatz läuft ab <\/b>können Sie dieses Wachstum kontrollieren. Hier können Sie einen festen Zeitpunkt angeben, ab dem die Sicherungssätze überschrieben werden sollen. Oder Sie legen über die Anzahl der Tage fest, ab wann alte Sicherungssätze mit neuen überschrieben werden. <\/p>\n Sie können beispielsweise in einer Datei Vollsicherungen, differenzielle Sicherungen und Transaktionsprotokollsicherungen von zwei Tagen speichern. Diese Datei wird jede Nacht von der Backup-Software auf Band oder auf einem anderen Laufwerk gesichert. So haben Sie die aktuelle Sicherung immer griffbereit und die Sicherung der Vortage auf den entsprechenden Bändern beziehungsweise Laufwerken.<\/p>\n Natürlich kann der SQL Server die Sicherungen auch direkt auf Bänder speichern. Dabei sollten Sie aber bedenken, dass eine Sicherung auf Band mehr Performance beansprucht als eine Sicherung auf der Festplatte. Dieser Aspekt ist besonders dann wichtig, wenn Sie Ihre Sicherungen im laufenden Betrieb durchführen. Der Einfachheit halber wird in diesem Beispiel nur die Datei als Sicherungsmedium beschrieben.<\/p>\n Die letzte Einstellung auf dieser Seite des Dialogs (siehe Bild 2) ist das Sicherungsziel. Neben dem bereits erwähnten Bandlaufwerk steht hier noch die Option Festplatte <\/b>zur Verfügung. Als Datei wird bereits eine Datei namens Northwind.bak<\/b> im Standardverzeichnis für Datenbanksicherungen angeboten. Sofern Sie die Sicherungsdatei in einem anderen Verzeichnis speichern möchten, müssen Sie die vorgeschlagene mit Entfernen <\/b>löschen und über Hinzufügen <\/b>eine neue bestimmen. Sinnvollerweise sollte sich die Sicherungsdatei nicht unbedingt auf demselben Laufwerk wie die Datenbankdateien befinden. Besser wäre natürlich eine externe Festplatte oder ein Verzeichnis auf einem anderen Rechner. <\/p>\n Bild 2: Konfiguration einer Vollsicherung <\/span><\/b><\/p>\n Und wenn gerade das Stichwort „ein Verzeichnis auf einem anderen Rechner“ gefallen ist, so muss an dieser Stelle noch mit einem alten Gerücht aufgeräumt werden: Es ist durchaus möglich, die Backup-Dateien auf einem Netzlaufwerk zu sichern. Dabei müssen der Pfad und Dateiname lediglich als UNC-Pfad angegeben werden (etwa: \\\\Backups\\Liegen\\Hier\\Northwind.bak<\/b>).<\/p>\n Über die Schaltfläche Hinzufügen <\/b>können noch weitere Sicherungsdateien für diese Sicherung definiert werden. Sollte der Festplattenplatz für diese Sicherung nicht ausreichen, wird die Sicherung auf die angegebenen Dateien – und somit auf verschiedene Platten – verteilt.<\/p>\n Die Schaltfläche Inhalt <\/b>bietet Ihnen einen Einblick in die Sicherungsdatei. Sie haben darüber die Möglichkeit, sich die Kopfdaten der einzelnen Sicherungssätze anzusehen.<\/p>\n Die grundlegende Konfiguration für eine Vollsicherung ist hiermit eigentlich abgeschlossen. Auf der Seite Optionen <\/b>gibt es aber noch einige weitere interessante Konfigurationsmöglichkeiten.<\/p>\n Da wäre an erster Stelle die Art und Weise zu nennen, wie die Sicherungen auf das Sicherungsmedium geschrieben werden sollen. Auf der ersten Seite haben Sie zwar definiert, ab wann alte Sicherungssätze mit neuen überschrieben werden sollen, aber hier bestimmen Sie in der Gruppe Medium überschreiben<\/b>, ob die neuen Sicherungssätze an die bereits vorhandenen angefügt oder ob die alten Sicherungssätze bei jeder Sicherung gelöscht werden sollen. <\/p>\n Dabei können Sie bei der Sicherung auf dem Medium den Mediensatznamen überprüfen lassen. Dieser wird bei der ersten Sicherung mit auf das Medium – in diesem Fall in die Datei – geschrieben. Stimmt die im Feld Mediensatzname <\/b>angegebene Bezeichnung mit dem Mediensatznamen nicht überein, wird die Sicherung nicht ausgeführt. Bei der bisherigen Konfiguration würde bei der ersten Sicherung der Mediensatzname leer bleiben und somit müsste bei den folgenden Sicherungen – sofern Sie diese Extraprüfung haben möchten – immer auf einen leeren Namen geprüft werden.<\/p>\n Mit der Option Auf neuen Mediensatz sichern und alle vorhandenen Sicherungssätze löschen <\/b>wird auch die auf der Seite Allgemein <\/b>unter Ziele <\/b>angegebene Datei genutzt. Jedoch wird diese dabei komplett geleert und ein Medienname vergeben. Diesen tragen Sie im Feld Name für neuen Mediensatz <\/b>ein. Ergänzend dazu können Sie eine ausführliche Beschreibung angeben. Wenn Sie sich nach der ersten Sicherung über Inhalt <\/b>die Kopfdaten der Sicherungssätze anzeigen lassen, sehen Sie dort auch den Mediennamen. Bild 3 zeigt einen solchen Einblick in ein Sicherungsmedium.<\/p>\n Bild 3: Inhalt eines Sicherungsmediums<\/span><\/b><\/p>\n Sofern Sie also mit Mediennamen und ihrer Überprüfung arbeiten möchten, müssen Sie bei der ersten Sicherung die Option Auf neuen Mediensatz sichern und alle vorhandenen Sicherungssätze löschen <\/b>auswählen und einen Mediennamen vergeben. Bei jeder folgenden Sicherung aktivieren Sie dann die Option Auf vorhandenen Mediensatz sichern <\/b>und tragen zum Vergleich den Mediensatznamen in das gleichnamige Feld ein. Dadurch wird verhindert, dass die Sicherung aus Versehen auf dem falschen Medium – also in der falschen Datei – landet. Aber wie bereits erwähnt: Dies ist nur notwendig, wenn Sie diese Extraprüfung möchten. Ansonsten können Sie die Voreinstellung beibehalten.<\/p>\n Eine weitere Prüfung – aber auf anderer Basis – wird in der Gruppe Zuverlässigkeit <\/b>konfiguriert. Hier gibt es die Möglichkeit, den Sicherungsvorgang selbst zu prüfen. Die erste Option Sicherung nach dem Abschluss überprüfen <\/b>prüft lediglich, ob der Sicherungssatz vollständig und lesbar ist. Eine ausführlichere Prüfung findet über die Option Vor dem Schreiben auf die Medien Prüfsumme bilden <\/b>statt. Hierbei wird die Sicherung wirklich überprüft, denn beim Sichern wird für jede Datenseite eine Prüfsumme erstellt und diese mit der Prüfsumme der in der Sicherung angekommenen Datenseite verglichen. Das hört sich nicht nur nach mehr Aufwand an, sondern ist es auch und wirkt sich folglich auch auf die Performance aus. Zusätzlich zur Prüfsumme können Sie festlegen, ob bei einem Fehler die Sicherung fortgesetzt oder abgebrochen werden soll.<\/p>\n Die Optionen der Gruppe Transaktionsprotokoll <\/b>betreffen die Transaktionsprotokollsicherung und werden später beschrieben. <\/p>\n Sofern Sie mit einem Bandlaufwerk arbeiten, sind die letzten beiden Optionen dieser Seite noch relevant. Hier bestimmen Sie, ob das Band nach dem Sicherungsvorgang entladen und vorher gegebenenfalls zurückgespult werden soll. <\/p>\n Genug der Konfiguration – Sie können die Sicherung nun mit einem Klick auf OK<\/b> starten. Dabei wird die Sicherungsdatei Northwind.bak <\/b>in dem angegebenen Pfad angelegt.<\/p>\n Nun möchten Sie bestimmt nicht für jede Sicherung den SSMSE starten und jedesmal die Sicherung konfigurieren und per OK<\/b> in Gang bringen. Schon gar nicht zu eventuell erforderlichen „downtimes“ – also mitten in der Nacht oder gar am Wochenende. Wie bereits erwähnt, fehlt der SSEE der SQL Server Agent, der diese Aufgaben automatisch erledigen könnte. Doch das Betriebssystem bietet mit den Geplanten Tasks <\/b>auch eine Möglichkeit, die Datenbanksicherungen zu automatisieren.<\/p>\n Der Taskplaner des Betriebssystems führt ein Programm zu einem bestimmten Zeitpunkt aus. Wohlgemerkt ein Programm – kein T-SQL-Skript, das ein Backup einer Datenbank ausführt. <\/p>\n Mit der SSEE steht Ihnen das Kommandozeilen-Tool sqlcmd <\/b>zur Verfügung. sqlcmd <\/b>ist der Nachfolger von osql<\/b>, das mit der MSDE ausgeliefert wurde.<\/p>\n Über sqlcmd <\/b>können Sie eine Verbindung zum SQL Server und zur entsprechenden Datenbank aufbauen, T-SQL ausführen und die Verbindung wieder beenden. Dies ist für die automatische Sicherung über den Taskplaner auch völlig ausreichend. Sie benötigen dazu nur die Syntax für den T-SQL-Aufruf über sqlcmd<\/b> und das T-SQL-Statement für die Datensicherung. Und das können Sie mit dem SSMSE recht einfach erstellen lassen. Klicken Sie im Dialog Datenbank sichern <\/b>nach der Konfiguration der Datensicherung auf die Schaltfläche Skript<\/b>. Dadurch wird für die konfigurierte Datensicherung ein T-SQL-Skript erstellt. Dieses wird dann noch mit der Syntax des sqlcmd <\/b>kombiniert. Für das Beispiel ergibt dies folgenden Befehl:<\/p>\n Natürlich muss der Befehl noch an Ihre Umgebung angepasst werden. Hier eine kurze Agenda der Parameter:<\/p>\n sqlcmd <\/b>bietet noch weitere Optionen, die Sie in der Onlinehilfe des SQL Servers finden (siehe Kasten Die Online-Hilfe des SQL Servers<\/b>).<\/p>\n Doch nun zurück zum geplanten Task, der die Vollsicherung jede Nacht um 1:00 Uhr automatisch ausführen soll. Neue geplante Tasks legen Sie über die Systemsteuerung mit dem Eintrag Geplante Tasks\/Geplanten Task hinzufügen <\/b>an. Dadurch wird ein Assistent gestartet, mit dem Sie das Programm bestimmen, das zu einem bestimmten Zeitpunkt ausgeführt werden soll. Die eigentliche Konfiguration beginnt auf der zweiten Seite des Assistenten. Hier wählen Sie über die Schaltfläche Durchsuchen <\/b>das Kommandozeilen-Tool sqlcmd <\/b>aus. Sie finden das Tool bei einer Standardinstallation unter C:\\Programme\\Microsoft SQL Server\\90\\Tools\\Binn<\/b>. <\/p>\n Nach der Auswahl verzweigen Sie zur nächsten Seite, auf der Sie dem Task einen Namen geben und den Turnus bestimmen können. Hier würde sich als Name Vollsicherung – Northwind<\/b> anbieten und als Turnus Täglich<\/b>. Auf der folgenden Seite bestimmen Sie die Startzeit des Tasks – in diesem Fall 01:00 Uhr<\/b>. Das war eigentlich bereits der letzte Schritt der Konfiguration des Turnus.<\/p>\n Wenn da nicht noch die Sache mit der Berechtigung wäre, denn der Task wird unter einem bestimmten Account ausgeführt, den Sie im letzten Schritt des Assistenten angeben. <\/p>\n Zum Schluss zeigt Ihnen der Assistent noch eine Übersicht Ihrer Konfiguration an und bietet dort auch die Möglichkeit, zu den erweiterten Eigenschaften des neuen Tasks zu wechseln.<\/p>\n Bis jetzt beinhaltet der Task lediglich den Aufruf des Tools sqlcmd <\/b>– ohne Parameter. Um diese noch zu ergänzen, müssen Sie zu den erweiterten Eigenschaften wechseln. Dort überschreiben Sie den Eintrag in Ausführen mit dem oben angegebenen Befehl <\/b>und speichern den Task mit OK<\/b>. <\/p>\n Nun wird jede Nacht um 1:00 Uhr eine Vollsicherung der Datenbank Northwind ausgeführt. Vorausgesetzt der Rechner ist auch an.<\/p>\n Die Konfiguration einer differenziellen Sicherung unterscheidet sich nicht wesentlich von einer Vollsicherung.<\/p>\n Auch dieser Sicherungstyp wird über den Datenbank sichern<\/b>-Dialog der Datenbank konfiguriert. Sie müssen hier lediglich den Sicherungstyp Differenziell <\/b>auswählen. Die restlichen Optionen haben die gleiche Auswirkung wie die der Vollsicherung.<\/p>\n Entscheidend bei der Konfiguration ist, ob Sie den Sicherungssatz der differenziellen Sicherung in die Sicherungsdatei der Vollsicherung mit aufnehmen oder in einer eigenen Sicherungsdatei speichern möchten. <\/p>\n Auch hier können Sie das T-SQL-Statement für die Sicherung skripten und dann in einem eigenen Task für die automatische Ausführung täglich um 12:00 Uhr konfigurieren.<\/p>\n Auch die Transaktionsprotokollsicherung wird nach dem bekannten Verfahren konfiguriert. Hier wählen Sie im Datenbank sichern<\/b>-Dialog den Sicherungstyp Transaktionsprotokollsicherung<\/b>.<\/p>\n Sofern auch dieser Sicherungssatz in das Sicherungsmedium Northwind.bak <\/b>aufgenommen werden soll, behalten Sie das bereits ausgewählte Ziel bei.<\/p>\n Für die Transaktionsprotokollsicherung gibt es auf der Seite Optionen <\/b>noch eine weitere Konfigurationsmöglichkeit. Diese ist für die normale Transaktionsprotokollsicherung zwar bereits korrekt vorbelegt, aber die Bedeutung der beiden Optionen in der Gruppe Transaktionen <\/b>soll Ihnen nicht vorenthalten werden. <\/p>\n Die bereits gewählte Option Transaktionsprotokoll abschneiden <\/b>sorgt dafür, dass das Protokoll nach der Sicherung verkleinert wird – wohlgemerkt das Transaktionsprotokoll, nicht die LDF-Datei.<\/p>\n Die Option Protokollfragment sichern und Datenbank in Wiederherstellungsstatus belassen <\/b>ist für den Fall der Fälle gedacht und bietet die Möglichkeit, bei einem Crash eine abschließende Transaktionsprotokollsicherung durchzuführen. <\/p>\n Dabei wird das Transaktionsprotokoll nicht abgeschnitten beziehungsweise verkleinert, sondern lediglich gesichert, damit nach der Wiederherstellung das Transaktionsprotokoll im ursprünglichen Zustand wieder verfügbar ist.<\/p>\n Es fehlt nun nur noch ein Task, der die Transaktionsprotokollsicherung alle 15 Minuten ausführt. Dazu skripten Sie wieder die Konfiguration und erstellen einen neuen Task. Dabei gibt es – was die fünfzehnminütige Ausführung angeht – ein kleines Problem.<\/p>\n Der Assistent bietet auf den ersten Blick keine Zeiteinheit namens Minute <\/b>an. Sie müssen den Task zunächst als Täglich ab einer bestimmten Uhrzeit <\/b>definieren und am Schluss in die erweiterten Einstellungen wechseln. Dort können Sie im Zeitplan eine zusätzliche Erweiterung öffnen (siehe Bild 4).<\/p>\n Bild 4: Taskplaner alle 15 Minuten<\/span><\/b><\/p>\n Wenn der Taskplaner die Transaktionsprotokollsicherung täglich im Zeitraum von 2:00 bis 0:45 des folgenden Tages alle 15 Minuten ausführen soll, müssen Sie einen Zeitplan Täglich um 2:00 Uhr <\/b>mit Wiederholungen alle 15 Minuten bis 0:45 Uhr definieren.<\/p>\n Voilà – nun haben Sie eine Datenbanksicherung, bei der täglich nachts eine Vollsicherung, mittags eine differenzielle und tagsüber alle 15 Minuten eine Transaktionsprotokollsicherung ausgeführt wird.<\/p>\n Alle Sicherungen werden in einer einzigen Datei gespeichert, die nach zwei Tagen den ältesten Eintrag mit dem neuesten überschreibt. Diese Datei kann wie jede andere Datei Ihres Systems von einer Sicherungssoftware archiviert werden.<\/p>\n Sie sind nun also in der Lage, anhand der Sicherungsdatei eine Datenbank bis zur letzten Transaktionsprotokollsicherung wiederherzustellen.<\/p>\n Sofern Sie also im Fall der Fälle keine abschließende Transaktionsprotokollsicherung mehr durchführen können, fehlen Ihnen bei dieser Konfiguration maximal 15 Minuten.<\/p>\n Wie Sie die Daten wiederherstellen, erfahren Sie in einer der nächsten Ausgaben von Access im Unternehmen.<\/p>\n Transaktionsprotokoll<\/p>\n<\/td>\n<\/tr>\n Was genau ist die Aufgabe des Transaktionsprotokolls Jede Anweisung an eine SQL Server Datenbank wird zunächst im Transaktionsprotokoll gespeichert und erst dann in der Datenbank ausgeführt. Sofern diese Ausführung erfolgreich ist, wird sie im Transaktionsprotokoll als „erledigt“ gekennzeichnet. Schlägt sie jedoch aus irgendeinem Grunde fehl, können anhand des Transaktionsprotokolls alle mit der Anweisung geänderten Daten wieder in den Ausgangszustand zurückgesetzt werden.<\/p>\n Da jede Anweisung im Transaktionsprotokoll festgehalten wird, werden die Transaktionsprotokolldateien (Dateiendung LDF) schnell sehr groß. Erst mit einer Datenbanksicherung werden die inaktiven – also die bereits erledigten – Transaktionen aus dem Transaktionsprotokoll entfernt und dieses wird dadurch wieder verkleinert. Wichtig ist hierbei, dass das Transaktionsprotokoll selbst und nicht die LDF-Datei klein gehalten wird. Die LDF-Datei hat eine definierte Größe, in der das Transaktionsprotokoll wachsen kann. Benötigt das Transaktionsprotokoll mehr Platz, wird die LDF-Datei dementsprechend vergrößert. Eine Sicherung bewirkt nun zwar eine Verkleinerung des Transaktionsprotokolls, aber nicht das Verkleinern der LDF-Datei. Diese muss mit Task\/Verkleinern\/Dateien <\/b>aus dem Kontextmenü der Datenbank extra verkleinert werden. Somit sichert eine Transaktionsprotokollierung nicht nur die Transaktionen der letzten Sicherung, sondern verhindert auch das Anwachsen der LDF-Datei.<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Die Onlinehilfe des SQL Servers<\/p>\n<\/td>\n<\/tr>\n Die Books Online – wie die Hilfe bei SQL Server 2000 heißt – ist bei SQL Server 2005 nun wirklich eine Online-Hilfe, d. h. wenn Sie auf F1 <\/b>drücken, wird eine Internetverbindung hergestellt. Es steht aber auch eine lokale Hilfe zur Verfügung. Diese ist ein eigenständiges Programm, das Sie unter http:\/\/www.microsoft.com\/germany\/technet\/downloads\/sql\/default.mspx <\/b>downloaden und lokal installieren können. Diese Hilfe wird ständig aktualisiert. Es lohnt sich also, öfter mal auf der Seite nachzuschauen. <\/p>\n Nach der Installation steht sie in der Programmgruppe des SQL Servers und im SSMSE zur Verfügung. Wenn Sie das erste Mal im SSMSE F1 <\/b>drücken, können Sie in einem Dialog angeben, ob in Zukunft die lokale oder die Online-Hilfe geöffnet werden soll. Erscheint dieser Dialog nicht, können Sie diese Einstellung auch direkt im Optionen<\/b>-Dialog unter Hilfe\/Online <\/b>ändern, den Sie in der Hilfe mit Extras\/Optionen <\/b>starten.<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n","protected":false},"excerpt":{"rendered":" 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.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[66022007,662007,44000038,44000022],"tags":[],"class_list":["post-55000545","post","type-post","status-publish","format-standard","hentry","category-66022007","category-662007","category-Sicherheit","category-SQL_Server_und_Co"],"yoast_head":"\nDie Vollsicherung <\/h2>\n
![\"pic002.tif\"](\"..\/fileadmin\/_temp_\/2007_02\/SicherungVonSQLServerDatenbanken-web-images\/pic002_opt.jpeg\")
<\/p>\n![\"pic003.tif\"](\"..\/fileadmin\/_temp_\/2007_02\/SicherungVonSQLServerDatenbanken-web-images\/pic003_opt.jpeg\")
<\/p>\nAutomatische Sicherungen<\/h2>\n
sqlcmd\r\n-S WXPSP2\\SQLEXPRESS -E -d Northwind\r\n-Q "BACKUP DATABASE [Northwind] TO DISK = N''E:\\Backup\\Northwind.bak'' WITH DESCRIPTION = N''Vollsicherung - 1mal täglich - um 01:00 Uhr'', RETAINDAYS = 2, NOFORMAT, NOINIT, NAME = N''Northwind - Vollsicherung'', SKIP, NOREWIND, NOUNLOAD, STATS = 10"<\/pre>\n
\n
Die differenzielle Sicherung<\/h2>\n
Die Transaktionsprotokollsicherung<\/h2>\n
![\"pic005.tif\"](\"..\/fileadmin\/_temp_\/2007_02\/SicherungVonSQLServerDatenbanken-web-images\/pic005_opt.jpeg\")
<\/p>\nZusammenfassung und Ausblick<\/h2>\n
\n\n
\n \n \n \n \n\n
\n \n \n \n