Strategien für die Datenbankwiederherstellung

  • Artikel

 

Letztes Änderungsdatum des Themas: 2006-06-12

In diesem Abschnitt wird die Struktur einer Datenbank erläutert. Darüber hinaus befasst er sich mit Strategien zur Datenbankwiederherstellung.

Grundlagen der Datenbankstruktur

Die Datenbankstruktur setzt sich aus Seitenebenen, ESE-Tabellenebenen (Extensible Storage Engine) und Anwendungsebenen zusammen. Im Folgenden erhalten Sie eine kurze Beschreibung jeder Ebene:

Seitenebene: Die Datei enthält eine geordnete Reihe von Seiten (normalerweise 4 KB oder ein Vielfaches von 4 KB groß), wobei jede Seite eine gemeinsame Organisationsstruktur aufweist. Jede Seite verfügt über Seitenkopfinformationen und Seitendaten. Zu den Seitenkopfinformationen gehören Prüfsummen der Seite, über die Exchange in der Lage ist, die Datenintegrität zu prüfen und Einzelbitfehler auf der Seite zu korrigieren.

ESE-Tabellenebene: Seitengruppen sind Tabellen zugeordnet, die vom ESE-Datenbankmodul verwaltet werden. Eine typische Exchange-Datenbank enthält Tausende von Einzeltabellen.

Anwendungsebene: Bei ESE handelt es sich um eine Allzweckdatenbank, die von unterschiedlichen Anwendungen genutzt werden kann. Beispielsweise greifen sowohl Exchange als auch der Verzeichnisdienst Active Directory auf ESE zu. Das ESE-Datenbankmodul speichert die Informationen so in seinen Tabellen, wie es von der jeweiligen Anwendung instruiert wird. ESE selbst kennt weder die anwendungsdefinierten Beziehungen zwischen Tabellen, noch die Bedeutung der in jeder Tabelle gespeicherten Daten.

Grundlagen der Strategien für die Datenbankwiederherstellung

Die einfachste Strategie zur Wiederherstellung einer beschädigten Datenbankdatei besteht darin, eine als fehlerfreie bekannte Kopie der Datenbank aus der Sicherung wiederherzustellen und dann ein Rollforward der Datenbank aus nachfolgend erzeugten Transaktionsprotokolldateien vorzunehmen. Zur Verwendung dieser Strategie müssen die folgenden drei Voraussetzungen erfüllt sein:

  • Es ist eine als fehlerfrei bekannte Sicherung der Datenbank vorhanden.
  • Sämtliche seit der Sicherung generierten Transaktionsprotokolldateien sind verfügbar und unbeschädigt.
  • Das Problem in der Datenbank wurde nicht von einer logischen Beschädigung oder einer unabsichtlichen Löschung verursacht. Wenn Nachrichten beispielsweise von einem Virenscanner beschädigt oder gelöscht wurden, sind diese Beschädigungen und Löschungen Bestandteil des Transaktionsprotokolldatensatzes und werden nach dem Wiederherstellen aus der Sicherung ebenfalls wieder in die Datenbank eingespielt.

Nachstehend werden weitere Strategien zur Datenbankwiederherstellung beschrieben.

Verschieben von Postfächern

Wenn Sie ein Exchange-Postfach in eine andere Datenbank verschieben, wird der Inhalt des Postfachs vom Exchange-Informationsspeicher genau so wie bei seiner Erstellung verarbeitet. Beschädigte Elemente werden übersprungen. Aus diesem Grund ist das Verschieben aller Postfächer in eine neue Datenbank eine hervorragende Strategie zum Entfernen beschädigter Elemente, während gleichzeitig die Menge der geretteten Benutzerinhalte maximiert wird.

Nachdem ein Postfach verschoben wurde, werden die Outlook-Clientprofile automatisch aktualisiert und verweisen nun auf die neue Datenbank oder den neuen Server. Zu diesem Zweck muss der vorherige Server mit seinem gegenwärtig ausgeführten Informationsspeicherdienst online bleiben, bis sich alle Clients einmal angemeldet haben und umgeleitet wurden. Bleibt der vorherige Server nicht online, müssen die Outlook-Clientprofile manuell oder mithilfe von Skripts aktualisiert werden.

Vorherige Offline- oder Cachemodus-Clientdateien funktionieren nach dem Verschieben eines Postfachs auch weiterhin. Darüber hinaus bleiben beim Verschieben eines Postfachs auch die Clientregeln erhalten.

Das Verschieben eines Postfachs hat auf dem Zielserver den gleichen Effekt wie die gleichzeitige Neuübermittlung aller im Postfach befindlichen Elemente. Wenn Sie also viele Postfächer verschieben möchten, sollten Sie hierfür eine Zeit mit geringer Systemauslastung wählen und die Benutzer bereits im Vorfeld informieren, wann die Verschiebung erfolgt und wo sie Unterstützung erhalten, falls es anschließend zu Problemen mit der Anmeldung kommt.

Werden viele Postfächer verschoben, werden für die Zieldatenbank mehr als die übliche Anzahl Datenbank-Transaktionsprotokolldateien generiert. Aus diesem Grund sollten Sie den für Transaktionsprotokolle verfügbaren Festplattenspeicher auf dem Zielserver sorgfältig überwachen. Wenn der Festplattenspeicher für Transaktionsprotokolldateien langsam zur Neige geht, können Sie eine vollständige oder inkrementelle Onlinesicherung erstellen, um Protokolldateien zu löschen oder um vor dem Verschieben die Umlaufprotokollierung zu aktivieren und diese dann direkt nach dem Verschieben wieder zu deaktivieren.

Werden alle Postfächer in eine neue Datenbank verschoben und wird die vorherige Datenbank dann verworfen, maximieren Sie die Menge der geretteten Benutzerinhalte und minimieren gleichzeitig die Ausfallzeit der Datenbank.

Informationen über das Verschieben einer Exchange-Datenbank auf einen anderen Server oder in eine andere Sicherungsgruppe finden Sie unter Verschieben einer Exchange-Postfachdatenbank auf einen anderen Server oder in eine andere Speichergruppe.

Reparieren der Datenbank

Im Allgemeinen sollte eine Datenbank nur repariert werden, wenn eine Wiederherstellung der Datenbank mit anschließendem Rollforward nicht möglich ist. Häufig nimmt das Reparieren einer Datenbank mehr Zeit in Anspruch als das Wiederherstellen aus einer Sicherung.

Hinweis   Wenn die Datenbank schwer beschädigt ist, dauert eine Reparatur länger, und die Wahrscheinlichkeit einer erfolgreichen Reparatur ist geringer. Wenn Sie auf normaler Serverhardware der Unternehmensklasse eine nicht oder nur leicht beschädigte Datenbank reparieren, nimmt der Prozess in der Regel etwa eine Stunde für je 5 GB an Daten in Anspruch. Wenn Sie Reparaturzeiten als Teil des Entwurfs von Vereinbarungen zu Serviceleveln (Service Level Agreements, SLAs) berechnen, sollten Sie mit einer typischen Datenbank, die auf ähnlicher Hardware wie der in der Organisation für Exchange verwendeten ausgeführt wird, eigene Benchmarks erarbeiten. Wenn eine Datenbank schwer beschädigt ist, kann sich die Reparaturzeit um den Faktor 10 oder höher verlängern.

Weitere Informationen über die Verwendung von "Eseutil" zum Reparieren einer Datenbank finden Sie unter Reparaturmodus "Eseutil /P".

Wiederherstellen, Reparieren und Zusammenführen

Das Wiederherstellen, Reparieren und Zusammenführen einer Datenbank wird häufig als Hybridstrategie bezeichnet. Diese Methode kann verwendet werden, wenn Sie über eine als funktionierend bekannte Sicherung der Datenbank verfügen, nach der Sicherung jedoch nicht alle Transaktionsprotokolle generiert wurden.

In diesem Fall können Sie die Sicherung wiederherstellen und parallel die beschädigte Kopie der Datenbank in einer Speichergruppe für die Wiederherstellung auf dem gleiche Server oder auf einem Laborserver reparieren. Anschließend kann die Speichergruppe für die Wiederherstellung verwendet werden, um beide Kopien der Datenbank separat bereitzustellen und Daten aus der reparierten Datenbank mit den Daten der wiederhergestellten Datenbank zusammenzuführen.

Unter der Voraussetzung, dass die Reparatur erfolgreich verläuft, haben Sie mit dieser Strategie die Chance, beinahe ebenso viele Daten wie mit der Verwendung von Transaktionsprotokollen wiederherzustellen. Weitere Informationen über die verschiedenen Hybridstrategien unter Verwendung von Speichergruppen für die Wiederherstellung finden Sie im Handbuch zur Verwendung von Exchange 2003-Speichergruppen für die Wiederherstellung (https://go.microsoft.com/fwlink/?LinkId=47589).

Weitere Informationen

Weitere Informationen finden Sie unter den folgenden Themen im Handbuch zum Exchange Server-Datenbankdienstprogramm: