Sichern schreibgeschützter Datenbanken

In diesem Thema wird das Sichern von Datenbanken behandelt, die schreibgeschützt sind oder zum Zeitpunkt der letzten Sicherung schreibgeschützt waren.

Bei einer schreibgeschützten Datenbank kann die primäre Datei während einer Sicherung nicht aktualisiert werden. Die bewährte Methode für eine schreibgeschützte Datenbank besteht in der Ausführung einer vollständigen Sicherung. Wenn eine Datenbank jedoch abwechselnd Schreibschutz und Lese-/Schreibzugriff aufweist, kann es sinnvoll sein, die Datenbank zu sichern, während sie über Lese-/Schreibzugriff verfügt. Dann können Sie – solange die Datenbank noch Lese-/Schreibzugriff aufweist und wenn der Umfang der Änderungen nur gering ist – differenzielle Sicherungen ausführen.

HinweisHinweis

Sie können die IsReadOnly-Eigenschaft einer Dateigruppe während einer Sicherung nicht ändern. Wenn Sie dies dennoch versuchen, treten Fehler auf.

Teilsicherungen nach dem Ändern einer Datenbank mit Lese-/Schreibberechtigung

Eine Teilsicherung einer schreibgeschützten Datenbank enthält nur die primäre Dateigruppe. Wenn die Datenbank später schreibgeschützt wird, können sekundäre Dateigruppen mit Lese-/Schreibzugriff vorhanden sein, die nicht in der Teilsicherung enthalten sind. Wenn Sie in diesem Fall versuchen, eine differenzielle Teilsicherung zu erstellen, tritt bei der Sicherung ein Fehler auf. Bevor Sie eine differenzielle Teilsicherung der Datenbank erstellen können, müssen Sie eine weitere Teilsicherung erstellen. Die neue Teilsicherung enthält alle sekundären Dateigruppen mit Lese-/Schreibzugriff und kann als Basis für differenzielle Teilsicherungen dienen.

Differenzielle Sicherungen schreibgeschützter Datenbanken

Für schreibgeschützte Datenbanken sind separate vollständige Sicherungen einfacher zu verwalten als wenn sie zusammen mit differenziellen Sicherungen verwendet werden. Wenn eine Datenbank schreibgeschützt ist, können mit Sicherungen und sonstigen Vorgängen die Metadaten in der Datei nicht geändert werden. Deshalb werden die für eine differenzielle Sicherung erforderlichen Metadaten, z. B. die Protokollfolgenummer (Log Sequence Number, LSN), mit der die differenzielle Sicherung beginnt (die Basis-LSN für differenzielle Sicherung), in der master-Datenbank gespeichert. Wenn die differenzielle Basis erstellt wird, während die Datenbank schreibgeschützt ist, zeigt das differenzielle Bitmuster mehr Änderungen an als tatsächlich seit der Basissicherung erfolgt sind. Die zusätzlichen Daten werden durch die Sicherung gelesen, jedoch nicht in die Sicherung geschrieben, da die in der backupset-Systemtabelle gespeicherte differential_base_lsn verwendet wird, um zu ermitteln, ob die Daten seit der Basissicherung tatsächlich geändert wurden.

Wenn eine schreibgeschützte Datenbank neu erstellt, wiederhergestellt oder getrennt und dann angefügt wird, gehen die Informationen zur differenziellen Basis verloren. Dies passiert, da die master-Datenbank nicht mit der Benutzerdatenbank synchronisiert wird. Mit SQL Server Database Engine (Datenbankmodul) kann dieses Problem nicht erkannt oder verhindert werden. Spätere differenzielle Sicherungen basieren nicht auf der letzten vollständigen Sicherung und können zu unerwarteten Ergebnissen führen. Zum Einrichten einer neuen differenziellen Basis wird empfohlen, eine vollständige Datenbanksicherung zu erstellen.

Bewährte Methoden für die Verwendung differenzieller Sicherungen mit einer schreibgeschützten Datenbank

Wenn Sie eine vollständige Sicherung einer schreibgeschützten Datenbank erstellt haben und nachfolgend eine differenzielle Sicherung erstellen möchten, sichern Sie die master-Datenbank.

Wenn die master-Datenbank verloren geht, stellen Sie sie wieder her, bevor Sie differenzielle Sicherungen einer Benutzerdatenbank wiederherstellen.

Wenn Sie eine schreibgeschützte Datenbank, für die Sie später differenzielle Sicherungen verwenden möchten, trennen und anfügen, sollten Sie möglichst bald eine vollständige Datenbanksicherung der schreibgeschützten Datenbank und der master-Datenbank erstellen.