Funktionsweise von Datenbanksnapshots
Ein Datenbanksnapshot bietet eine schreibgeschützte, statische Ansicht einer Quellendatenbank zum Zeitpunkt der Snapshoterstellung ohne diejenigen Transaktionen, für die kein Commit ausgeführt wurde. Für Transaktionen, für die kein Commit ausgeführt wurde, wird in einem neu erstellten Datenbanksnapshot ein Rollback ausgeführt, da die Wiederherstellung von Database Engine (Datenbankmodul) nach dem Erstellen des Snapshots ausgeführt wird (in der Datenbank enthaltene Transaktionen sind nicht betroffen).
Datenbanksnapshots sind von der Quelldatenbank abhängig. Die Snapshots einer Datenbank müssen sich auf der gleichen Serverinstanz wie die Datenbank selbst befinden. Ist diese Datenbank außerdem aus irgendeinem Grund nicht verfügbar, stehen die zugehörigen Datenbanksnapshots ebenfalls nicht zur Verfügung.
Snapshots können zur Berichterstellung verwendet werden. Sie können auch bei einem Benutzerfehler auf einer Quellendatenbank die Quellendatenbank in den Zustand zurückversetzen, in der sie zum Zeitpunkt der Snapshoterstellung gewesen ist. Der Datenverlust wird auf Aktualisierungen beschränkt, die seit der Snapshoterstellung durchgeführt worden sind. Außerdem sollten Sie einen Datenbanksnapshot erstellen, bevor Sie eine wesentliche Datenbankänderung vornehmen, wie beispielsweise die Änderung des Schemas oder der Tabellenstruktur. Weitere Informationen zu Snapshots finden Sie unter Typische Verwendungen von Datenbanksnapshots.
Das Verständnis der Funktionsweise von Snapshots ist zwar nicht unbedingt nötig, kann jedoch hilfreich sein. Datenbanksnapshots arbeiten auf der Ebene der Datenseiten. Bevor eine Seite der Quellendatenbank zum ersten Mal geändert wird, wird die Originalseite der Quellendatenbank auf den Snapshot kopiert. Dieser Vorgang wird als Kopie bei Schreibvorgang bezeichnet. Im Snapshot wird die Originalseite gespeichert, wodurch die Datensätze in dem Zustand erhalten werden, wie sie zum Zeitpunkt der Snapshoterstellung vorhanden waren. Nachfolgende Aktualisierungen von Datensätzen in einer geänderten Seite wirken sich nicht auf den Inhalt des Snapshots aus. Der gleiche Vorgang wird für jede Seite wiederholt, die zum ersten Mal geändert wird. Auf diese Weise bleiben im Snapshot die Originalseiten für alle Datensätze erhalten, die seit dem Erstellen des Snapshots geändert worden sind.
Um die kopierten Originalseiten zu speichern, wird vom Snapshot mindestens eine Datei mit geringer Dichte verwendet. Ursprünglich ist eine Datei mit geringer Dichte im Wesentlichen eine leere Datei, die keine Benutzerdaten enthält und für die noch kein Speicherplatz für Benutzerdaten auf einem Speichermedium zugeordnet worden ist. Je mehr Seiten in der Quellendatenbank aktualisiert werden, desto größer wird die Datei. Wenn ein Snapshot erstellt wird, verbraucht die Datei mit geringer Dichte nur wenig Speicherplatz. Bei nachfolgenden Aktualisierungen der Datenbank kann eine Datei mit geringer Dichte allerdings sehr groß werden. Weitere Informationen zu Dateien mit geringer Dichte finden Sie unter Grundlegendes zur Größe von Dateien mit geringer Dichte in Datenbanksnapshots.
Die folgende Abbildung veranschaulicht einen Kopie-bei-Schreibvorgang. Die hellgrauen Rechtecke im Snapshotdiagramm repräsentieren potenziellen Platz in einer Datei mit geringer Dichte, der bis jetzt noch nicht zugeordnet wurde. Beim Empfang der ersten Aktualisierung einer Seite in der Quellendatenbank wird von Database Engine (Datenbankmodul) ein Schreibvorgang auf der Datei ausgeführt und vom Betriebssystem Platz in den Dateien mit geringer Dichte des Snapshots zugeordnet und die Originalseiten dorthin kopiert. Von Database Engine (Datenbankmodul) wird die Seite dann in der Quellendatenbank aktualisiert. Die folgende Abbildung veranschaulicht einen solchen Kopie-bei-Schreibvorgang.
.gif "Lesevorgang für den Snapshot nach Aktualisierung der Seite")
.gif "Wichtiger Hinweis") Wichtig |
|---|
Da Datenbanksnapshots keine redundanten Speicherungen darstellen, schützen sie nicht vor Datenträgerfehlern oder vor anderen Beschädigungsformen. Das Erstellen regelmäßiger Sicherungen und das Testen des Wiederherstellungsplans sind für den Schutz einer Datenbank von entscheidender Bedeutung. Wenn Sie die Quelldatenbank zu dem Zeitpunkt wiederherstellen müssen, an dem Sie einen Datenbanksnapshot erstellt haben, implementieren Sie eine Sicherungsrichtlinie, die Ihnen dies ermöglicht. |
Lesevorgänge auf einem Datenbanksnapshot
Für den Benutzer scheint sich ein Datenbanksnapshot niemals zu ändern, weil von Lesevorgängen auf einem Datenbanksnapshot immer auf die Originaldatenseiten zugegriffen wird, unabhängig von deren Speicherort.
Wenn die Seite noch nicht auf der Quellendatenbank aktualisiert wurde, wird von einem Lesevorgang auf dem Snapshot die Originalseite von der Quellendatenbank gelesen. Die folgende Abbildung zeigt einen Lesevorgang auf einem neu erstellten Snapshot, dessen Datei mit geringer Dichte dementsprechend keine Seiten enthält. Von diesem Lesevorgang wird nur von der Quellendatenbank gelesen.
.gif "Lesevorgang vor dem Kopieren der ersten Seite in den Snapshot")
Nachdem eine Seite aktualisiert worden ist, wird von einem Lesevorgang weiterhin auf die Originalseite zugegriffen, die sich dann in einer Datei mit geringer Dichte befindet. Die folgende Abbildung veranschaulicht einen Lesevorgang auf dem Snapshot, von dem auf eine Seite zugegriffen wird, nachdem sie in der Quellendatenbank aktualisiert worden ist. Vom Lesevorgang wird die Originalseite von der Datei mit geringer Dichte vom Snapshot gelesen.
.gif "Kopie bei Schreibvorgang")
Auswirkung des Aktualisierungsmusters auf das Wachstum des Datenbanksnapshots
Wenn Ihre Quellendatenbank einigermaßen groß ist und Sie sich Gedanken über den Speicherplatzverbrauch machen, sollten Sie zu einem bestimmten Zeitpunkt einen alten Snapshot durch einen neuen ersetzen. Die ideale Lebensspanne eines Snapshots hängt von der Wachstumsrate und dem Speicherplatz ab, der für seine Dateien mit geringer Dichte verfügbar ist. Der Speicherplatz, der für einen Snapshot erforderlich ist, hängt davon ab, wie viele verschiedene Seiten in der Quellendatenbank während der Lebensdauer des Snapshots aktualisiert werden. Wenn nur eine kleine Untermenge von Seiten regelmäßig aktualisiert wird, verlangsamt sich deshalb die Wachstumsrate mit der Zeit, und der Speicherplatzbedarf des Snapshots beleibt relativ gering. Wenn im Gegensatz dazu alle Originalseiten mit der Zeit mindestens ein Mal aktualisiert werden, wächst der Snapshot bis zur Größe der Quellendatenbank. Wenn der auf dem Datenträger verfügbare Speicherplatz fast vollständig belegt ist, stehen die Snapshots im Wettbewerb um Speicherplatz. Wenn sich der Datenträger füllt, schlagen Schreibvorgänge auf alle Snapshots fehl.
.gif "Hinweis") Hinweis |
|---|
Informationen zur aktuellen und potenziellen Größe von Snapshots finden Sie unter Grundlegendes zur Größe von Dateien mit geringer Dichte in Datenbanksnapshots. |
Aus diesem Grund ist es nützlich, die typischen Aktualisierungsmuster für eine Datenbank zu kennen, wenn geplant wird, wie viel Speicherplatz während der geplanten Lebensdauer eines Snapshots erforderlich ist. Bei einigen Datenbanken kann die Aktualisierungsrate einigermaßen konstant sein. Viele der Seiten einer Inventardatenbank können beispielsweise täglich aktualisiert werden, womit die tägliche oder wöchentliche Ersetzung von alten Snapshots sinnvoll wird. Bei anderen Datenbanken kann das Verhältnis von aktualisierten Seiten während des Geschäftszyklus variieren. Eine Katalogdatenbank kann beispielsweise primär vierteljährlich aktualisiert werden, wobei nur von Zeit zu Zeit weitere Aktualisierungen vorgenommen werden. Das Erstellen von Snapshots vor und nach jedem vierteljährlichen Update wäre eine logische Strategie. Der Snapshot vor der Aktualisierung würde ein Zurücksetzen zulassen, wenn ein signifikanter Fehler auftritt, und der Snapshot nach dem Aktualisieren könnte für die Berichterstellung während des nächsten Quartals verwendet werden.
Die folgende Abbildung veranschaulicht die Auswirkungen zweier unterschiedlicher Aktualisierungsmuster auf die Größe eines Snapshots. Das Aktualisierungsmuster A spiegelt eine Umgebung wider, in der nur 30 Prozent der Originalseiten während der Lebensspanne des Snapshots aktualisiert werden. Das Aktualisierungsmuster B spiegelt eine Umgebung wider, in der 80 Prozent der Originalseiten während der Lebensspanne des Snapshots aktualisiert werden.
.gif "Alternative Aktualisierungsmuster und Snapshotgrößen")
Metadaten zu Datenbanksnapshots
Bei Datenbanksnapshots beinhalten Datenbankmetadaten die source_database_id-Eigenschaft, die in einer Spalte der sys.databases-Katalogsicht gespeichert wird. Weitere Informationen zu dieser Eigenschaft finden Sie unter sys.databases (Transact-SQL).
Im Allgemeinen gibt ein Datenbanksnapshot keine eigenen Metadaten frei. Metadaten von der entsprechenden Quellendatenbank werden allerdings offen gelegt. Zu diesen Metadaten gehören beispielsweise die Daten, die von der folgenden Anweisung zurückgegeben werden:
USE <database_snapshot> SELECT * FROM sys.database_files
Dabei ist <database_snapshot>der Name eines Datenbanksnapshots.
Die einzige Ausnahme besteht bei Verwendung der Volltextsuche oder der Datenbankspiegelung in der Quelldatenbank. Hierbei wird eine Eigendeaktivierung auf Snapshots vorgenommen, indem einige Werte in den Metadaten des Snapshots geändert werden.
Siehe auch