Am 14. September 2017 haben wir eine überarbeitete Fassung unserer Datenschutzrichtlinie veröffentlicht. Wenn Sie video2brain.com weiterhin nutzen, erklären Sie sich mit diesem überarbeiteten Dokument einverstanden. Bitte lesen Sie es deshalb sorgfältig durch.

SQL Server 2016 Grundkurs: Administration

Wiederherstellungsmodelle

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Lassen Sie sich in diesem Video von Daniel Caesar erklären, welche Rolle die Wiederherstellungsmodelle beim Sichern und Wiederherstellen von SQL Server-Datenbanken spielen.
08:22

Transkript

Eines der wichtigsten Themen im Administrativen Bereich ist das Thema "Backup" und "Recovery", um letztendlich jederzeit sicherzustellen, dass Datenbanken wieder hergestellt werden können. Welche Rolle dabei die SQL Server Wiederherstellungsmodelle spielen, das sehen Sie in diesem Video. Das Wiederherstellungsmodell lässt sich für jede Datenbank separat festlegen. Dazu wählen Sie im "Objekt-Explorer" einfach die entsprechende Datenbank aus, gehen mit der rechten Maustaste darauf, anschließend auf die "Eigenschaften" und haben dann im Datenbankeigenschaftsdialog unter "Optionen" hier oben das Wiederherstellungsmodell. Ich möchte Ihnen an einem kleinen Beispiel verdeutlichen, welche Auswirkung diese Einstellung hat. Im Moment steht es auf "Vollständig". Das ist also der vordefinierte Wert. Ich gehe mal auf meine Datenbank mit der rechten Maustaste zum Kontextmenü, wähle "Tasks", wähle "Sichern". Anschließend gelangen wir in den Dialog für eine Datenbanksicherung. Hier bei "Sicherungstyp" ist jetzt erkennbar, dass ich die Möglichkeit habe, meine Datenbank vollständig zu sichern, dass ich differenzierte Sicherungen ausführen kann und eine Transaktionsprotokoll-Sicherung. Wenn ich diesen Dialog jetzt abbreche, ändere für meine Datenbank das Wiederherstellungsmodell auf "Einfach" und bestätige das, gehe im Anschluss wieder mit der rechten Maustaste auf die Datenbank, auf "Task", auf "Sichern" in den Dialog zum Backup, dann schauen wir einfach mal, was sich jetzt verändert hat. Wir werden nämlich jetzt feststellen, dass bei "Sicherungstyp" nur noch zwei Möglichkeiten der Sicherung zur Verfügung stehen nämlich "Vollständig" und "Differenziell". Das heißt, das Umstellen des Vollständigen auf einfaches Modell hat bewirkt, dass ich vor meiner Backup-Strategie lediglich vollständige und differenzielle Sicherung, aber keine Transaktionsprotokoll-Sicherung mehr ausführen kann. Um an dieser Stelle das Verständnis etwas zu vertiefen, macht es Sinn, dass man sich mal das Konzept des SQL Server-Transaktionsprotokolls näher anschaut. Transaktionsprotokolle stellen einen Verlauf von Aktionen bereit, die vom Datenbank-Managementsystem ausgeführt wurden. Was ist das? Das sind letztendlich meine Transaktionen, Insert, Update, Delete, die ich hier im Prinzip aus einer Applikation heraus ausführe oder vielleicht mit dem Management Studio, und die in Transaktionsprotokolle aufgezeichnet werden. Das heißt, meine Applikation sendet Änderungen an das Datenbankmodul. Die Änderungen werden zunächst im Puffercache ausgeführt. Der Puffercache ist vom SQL Server der Arbeitsspeicher. Das heißt, dort werden die Datenseiten reingeladen, wenn es jetzt Änderungen, Update, Inserte dort gibt, erfolgen die Änderungen zunächst im Arbeitsspeicher, also speichere im Puffercache. Anschließend werden diese Änderungen persistiert, indem sie im Transaktionsprotokoll aufgezeichnet werden. Das Transaktionsprotokoll wird im Grunde genommen sequenziell geschrieben. Die Änderungen, die also im Rahmen jetzt ausgeführt werden, sind dann persistent im Transaktionsprotokoll enthalten. Zu einem späteren Zeitpunkt werden sogenannte Prüfpunkte ausgeführt. Dieser Prüfpunktprozess, der zu einem späteren Zeitpunkt ausgeführt wird, schriebt dann die Änderungen ins Datafile, dass sie dann entsprechend persistiert sind. Zum einen ist es so, solange wie die Änderungen jetzt noch nicht im Datenfile persistent sind, wenn es jetzt zum Absturz des Systems kommen würde und SQL Server erneut startet, ist sichergestellt, dass die Änderungen im Transaktionsprotokoll aufgezeichnet sind, was jetzt im Prinzip comitted ist und noch nicht im Datenfile steht, wird anschließend dann mit einem "Roll Forward" nachgeschrieben. Wo noch kein Commit stattgefunden hat, gibt es im Grunde genommen "Roll back", sodass ich SQL Server wieder in einen konsistenten Zustand bringen kann. Das zeigt aber auch, wie wichtig dieses Transaktionsprotokoll ist, und die Wiederherstellungsmodelle entscheiden darüber, kann ich mein Transaktionsprotokoll zusätzlich sichern, also spräche ich, ich habe Vollbackups, ich habe differenzierte Backups, ich habe Log Backup, das Ganze liegt im Safe. Und wenn ich wieder herstellen will, kann ich natürlich aus meinen Vollbackups, aus den Diffs und auch aus den Transaktionsprotokollen entsprechend dann eine Zeitpunkt genauer wieder Herstellungen ausführen oder befindet sich meine Datenbank zum Beispiel im einfachen Wiederherstellungsmodell, wo es mir nur möglich ist, vollständige Backups und differenzielle Backups dann durchzuführen. Wenn wir uns also die Wiederherstellungsmodellen in einer Übersicht mal anschauen, kann man hier sehr schön entnehmen, dass das einfache Modell ermöglicht beziehungsweise erfordert keine Protokollensicherung. Was heißt das? Ich habe es ja eben gezeigt. Ich kann mein Transaktionsprotokoll ja auch gar nicht sichern im einfachen Modell, schneide Protokolle automatisch ab, das heißt, ich muss mich also nicht darum kümmern, dass meine Transaktionsprotokolle anwachsen, dass ich sie separat sichern muss, das also meine Platten gegebenenfalls durch meine Protokolle zulaufen, und die Speicherplatzanforderungen werden gering gehalten. Im vollständigen Modell habe ich das ganze Gegenteil. Dies erfordert Protokollensicherung, das heißt also, hier habe ich nicht nur die Möglichkeit, meine Logs zu sichern, sondern ich soll sie sogar sichern, ansonsten wäre es doch etwas widersprüchlich. Ich sage, bitte fahre vollständiges Modell, das ich Vollbackups, Diffbackups und Log-Backups machen kann und führe sie nicht aus. Das wäre dann ein Widerspruch, denn mir geht es hier darum, dass ich mit Hilfe der Transaktionsprotokolle gegebenenfalls im Disaster-Recovery-File eine Zeitpunkt genauer wieder Herstellung machen kann, indem ich sage, ich spiele mein Vollbackup zurück, ich spiele mein Diff zurück und dann habe ich vielleicht stündlich meine Transaktionsprotokolle gesichert, die ich dann natürlich in Anzahl und Reihenfolge auch wieder herstelle um nah an den Systemabsturz, den Crash oder das Löschen einer Tabelle oder wie auch immer heranzukommen. Das heißt also, Vollständig erfordert Protokollensicherung für meine Verwaltbarkeit, damit sie abgeschnitten werden. Häufiger Fehler von Administratoren ist sichere, aber meine Transaktionsprotokolle wachsen trotzdem weiter an, weil ich eine Vollsicherung und keine Transaktionsprotokollesicherung ausführe. Vermeidet Datenverlust auf Grund einer beschädigten oder fehlenden Datendatei und ermöglicht die Wiederherstellung des Zustandes zu einem bestimmten Zeitpunkt, das hatte ich eben erwähnt. Das Ganze geschieht dann mit Hilfe des Transaktionsprotokolls. Die Variante "Massenprotokolliert" liegt dazwischen, denn wenn wir ein vollständiges Modell haben, werden auch alle Transaktionen protokolliert, und hier stellen Sie sich vor, Sie haben nachts vielleicht eine Massenladevorgang, wo Sie 10 Millionen Datensätze laden und jeder einzelne würde protokolliert werden mit einem Insert, und das würde unsere Logs natürlich in Norm aufblenden. Und für solche Szenarien besteht die Möglichkeit, das Modell zu wechseln in dem massenprotokollierten Modus, das heißt, normale Transaktionen werden dann geloggt, aber solche Massenladevorgänge sind halt ausgeklammert. Ist auch nicht notwendig, weil dafür habe ich ja vielleicht meine Datei oder meinen Ort, wo ich sie her lade, kann das jederzeit wieder holen. Normale Transaktion wie Insert, Update, die aus Anwendung kommen, sind natürlich protokolliert. Es geht hier speziell um Massenladenvorgänge, und das ist ein Spezialfall. Schluss und letztendlich basieren die Kapazitätsanforderungen hinsichtlicher Planung natürlich auf der entsprechenden Strategie, welches Wiederherstellungsmodell verwende ich für meine Datenbank, dann die Häufigkeit der Sicherung des Protokolls, weil das Protokoll an sich intern immer abgeschnitten wird, wenn Logsicherungen stattfinden. Wie stelle ich das also ein? Mache ich das stündlich, dreimal am Tag, halbstündlich, unter der Transaktion, die natürlich innerhalb einer Datenbank dann ausgeführt sind, mal Anzahl der Datenbanken auf einer SQL Server-Instanz. In diesem Video haben Sie gesehen, was sich hinter dem Thema SQL Server Wiederherstellungmodelle verbirgt, welchen Einfluss das Wiederherstellungsmodell auf meine Backup- und Recoverystrategie und die Kapazitätsplanung hat.

SQL Server 2016 Grundkurs: Administration

Erlernen Sie die Administration des SQL Server 2016 vom Umgang mit dem Management Studio bis zu Automatisierung und Monitoring.

6 Std. 10 min (60 Videos)
Derzeit sind keine Feedbacks vorhanden...
 
Hersteller:
Software:
Exklusiv für Abo-Kunden
Erscheinungsdatum:08.05.2017

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!