Verwalten von Postfachdatenbankkopien

Gilt für: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Letztes Änderungsdatum des Themas: 2015-03-09

Die Datenbankmobilität ist eine neue Architektur in Microsoft Exchange Server 2010, bei der das Konzept der Speichergruppen beseitigt und eine Exchange 2010-Postfachdatenbank vom Postfachserver losgelöst wurde. Da Speichergruppen aus Exchange 2010 entfernt wurden, arbeitet die fortlaufende Replikation jetzt auf Datenbankebene. In Exchange 2010 werden Transaktionsprotokolle auf mindestens einen Postfachserver repliziert und in mindestens einer Kopie einer Postfachdatenbank wiedergegeben, die auf diesen Servern gespeichert wird. Verschiedene bei der fortlaufenden Exchange Server 2007-Replikation verwendete Konzepte bleiben in Exchange 2010 erhalten. Dies umfasst die Konzepte zu Abweichungen, die Verwendung von "AutoDatabaseMountDial" sowie von öffentlichen und privaten Netzwerken.

Verwalten von Datenbankkopien

Nachdem mehrere Kopien einer Datenbank erstellt wurden, können Sie die Exchange-Verwaltungskonsole und die Exchange-Verwaltungsshell verwenden, um den Zustand und Status der einzelnen Kopien zu überwachen und andere Verwaltungsaufgaben auszuführen, die den Datenbankkopien zugeordnet sind. Einige der Verwaltungsaufgaben, die Sie möglicherweise ausführen müssen, umfassen das Anhalten oder Fortsetzen einer Datenbankkopie, das Seeding einer Datenbankkopie, das Überwachen von Datenbankkopien, das Konfigurieren der Einstellungen von Datenbankkopien und das Entfernen einer Datenbankkopie.

Anhalten und Fortsetzen von Datenbankkopien

Es gibt verschiedene Gründe, z. B. das Ausführen geplanter Wartungsmaßnahmen, die das Anhalten und Fortsetzen der fortlaufenden Replikationsaktivität für eine Datenbankkopie erforderlich machen können. Außerdem erfordern einige Verwaltungsaufgaben, z. B. das Seeding, dass Sie zuerst eine Datenbankkopie anhalten. Es wird außerdem empfohlen, dass alle Replikationsaktivitäten angehalten werden, wenn der Pfad für die Datenbank oder für ihre Protokolldateien geändert wird. Sie können die Aktivitäten für Datenbankkopien mithilfe der Exchange-Verwaltungskonsole anhalten und fortsetzen. Sie können auch die Cmdlets Suspend-DatabaseCopy und Resume-DatabaseCopy in der Shell ausführen. Genaue Anweisungen zum Anhalten oder Fortsetzen der fortlaufenden Replikationsaktivität für eine Datenbankkopie finden Sie unter Anhalten oder Fortsetzen der Kopie einer Postfachdatenbank.

Das Abschneiden von Protokollen tritt bei der aktiven Postfachdatenbankkopie nicht auf, wenn eine oder mehrere passive Kopien angehalten werden. Wenn Ihre geplanten Wartungsaktivitäten einen längeren Zeitraum (z. B. mehrere Tage) in Anspruch nehmen, kann eine beträchtliche Menge von Protokolldateien erstellt werden. Damit das Protokolllaufwerk nicht durch Transaktionsprotokolle überfüllt wird, können Sie die betroffene passive Datenbankkopie entfernen, anstatt sie anzuhalten. Nach Abschluss der geplanten Wartung können Sie die passive Datenbankkopie wieder hinzufügen.

Seeding von Datenbankkopien

Das Seeding, das auch als Aktualisieren bezeichnet wird, ist der Prozess, bei dem eine Datenbank (entweder eine leere Datenbank oder eine Kopie einer Produktionsdatenbank) an dem Speicherort der Zielkopie auf einem anderen Postfachserver in derselben Database Availability Group (DAG) wie die Produktionsdatenbank hinzugefügt wird. Dies wird die Basisdatenbank für die von diesem Server verwaltete Kopie.

Abhängig von der Situation kann das Seeding ein automatischer Prozess oder ein vom Administrator eingeleiteter, manueller Prozess sein. Wenn eine Datenbankkopie hinzugefügt wird, erfolgt automatisch das Seeding der Kopie, sofern der Zielserver und sein Speicher ordnungsgemäß konfiguriert sind. Wenn Sie das Seeding einer Datenbankkopie manuell ausführen und kein automatisches Seeding beim Erstellen der Kopie möchten, können Sie den Parameter SeedingPostponed beim Ausführen des Cmdlets Add-MailboxDatabaseCopy verwenden.

Für Datenbankkopien ist nach dem anfänglichen Seeding selten ein erneutes Seeding erforderlich. Wenn jedoch ein erneutes Seeding erforderlich ist oder Sie das Seeding für eine Datenbankkopie manuell ausführen möchten, anstatt dies automatisch vom System übernehmen zu lassen, dann können diese Aufgaben mithilfe des Assistenten zum Aktualisieren von Datenbankkopien in der Exchange-Verwaltungskonsole oder mithilfe des Cmdlets Update-MailboxDatabaseCopy in der Shell ausgeführt werden. Vor dem Seeding einer Datenbankkopie müssen Sie zunächst die Postfachdatenbankkopie anhalten. Genaue Anweisungen zum Seeding einer Datenbankkopie finden Sie unter Aktualisieren einer Kopie einer Postfachdatenbank.

Nachdem das manuelle Seeding abgeschlossen ist, wird die Replikation für die Postfachdatenbankkopie, für die das Seeding durchgeführt wurde, automatisch fortgesetzt. Wenn die Replikation nicht automatisch fortgesetzt werden soll, können Sie den Parameter ManualResume beim Ausführen des Cmdlets Update-MailboxDatabaseCopy verwenden.

Auswählen der Seedingziele

Wenn Sie einen Seedingvorgang ausführen, können Sie das Seeding für die Postfachdatenbankkopie, für den Inhaltsindexkatalog der Postfachdatenbankkopie oder sowohl für die Datenbankkopie als auch für die Inhaltsindex-Katalogkopie auswählen. Das Standardverhalten des Assistenten zum Aktualisieren von Datenbankkopien und des Cmdlets Update-MailboxDatabaseCopy ist es, das Seeding sowohl für die Postfachdatenbankkopie als auch für die Inhaltsindex-Katalogkopie auszuführen. Damit das Seeding nur für die Postfachdatenbankkopie und nicht für den Inhaltsindexkatalog ausgeführt wird, verwenden Sie den Parameter DatabaseOnly beim Ausführen des Cmdlets Update-MailboxDatabaseCopy. Damit das Seeding nur für den Inhaltsindexkatalog ausgeführt wird, verwenden Sie den Parameter CatalogOnly beim Ausführen des Cmdlets Update-MailboxDatabaseCopy.

Auswählen der Seedingquelle

In Exchange 2007 konnte mithilfe der fortlaufenden Replikation das Seeding nur für eine Datenbankkopie ausgeführt werden, indem die aktive Kopie der Datenbank kopiert wurde. In Exchange 2010 kann jede fehlerfreie Datenbankkopie als Seedingquelle für eine zusätzliche Kopie dieser Datenbank verwendet werden. Dies ist v. a. hilfreich, wenn Sie eine DAG besitzen, die sich über mehrere physikalische Standorte erstreckt. Stellen Sie sich z. B. eine Bereitstellung einer DAG mit vier Mitgliedern vor, bei der sich zwei Mitglieder (MBX1 und MBX2) in Portland, Oregon, befinden, während sich die anderen beiden Mitglieder (MBX3 und MBX4) in New York, New York, befinden. Auf MBX1 ist eine Postfachdatenbank mit der Bezeichnung DB1 aktiv, und es befinden sich passive Kopien von DB1 auf MBX2 und MBX3. Beim Hinzufügen einer Kopie von DB1 zu MBX4 haben Sie die Möglichkeit, die Kopie auf MBX3 als Quelle für das Seeding zu verwenden, wobei Sie das Seeding über den WAN-Link (Wide Area Network) zwischen Portland und New York vermeiden.

Sie würden wie folgt vorgehen, wenn Sie beim Hinzufügen einer neuen Datenbankkopie eine bestimmte Kopie als Quelle für das Seeding verwenden:

• Verwenden Sie den Parameter SeedingPostponed beim Ausführen des Cmdlets Add-MailboxDatabaseCopy, um die Datenbankkopie hinzuzufügen. Wenn der Parameter SeedingPostponed nicht verwendet wird, erfolgt das explizite Seeding der Datenbankkopie mithilfe der aktiven Kopie der Datenbank als Quelle.

• Verwenden Sie den Parameter SourceServer beim Ausführen des Cmdlets Update-MailboxDatabaseCopy, und geben Sie den gewünschten Quellserver für das Seeding an. Im vorherigen Beispiel würden Sie "MBX3" als Quellserver angeben. Wenn der Parameter SourceServer nicht verwendet wird, erfolgt das explizite Seeding der Datenbankkopie mithilfe der aktiven Kopie der Datenbank als Quelle.

Seeding und Netzwerke

Zusätzlich zum Auswählen eines bestimmten Quellservers für das Seeding einer Postfachdatenbankkopie können Sie auch angeben, welche DAG-Netzwerke zu verwenden sind. Außerdem können Sie die Einstellungen für die Komprimierung und Verschlüsselung des DAG-Netzwerks während des Seedingvorgangs optional außer Kraft setzen.

Wenn Sie die für das Seeding zu verwendenden Netzwerke angeben, verwenden Sie den Parameter Network beim Ausführen des Cmdlets Update-MailboxDatabaseCopy, und geben Sie die zu verwendenden DAG-Netzwerke an. Wenn Sie den Parameter Network nicht verwenden, verwendet das System das folgende Standardverhalten zum Ausführen eines Netzwerks, das für den Seedingvorgang verwendet wird:

• Wenn sich Quell- und Zielserver in demselben Subnetz befinden und ein Replikationsnetzwerk konfiguriert wurde, das dieses Subnetz einbezieht, dann wird das Replikationsnetzwerk verwendet.

• Wenn sich Quell- und Zielserver in unterschiedlichen Subnetzen befinden, dann wird das Clientnetzwerk (MAPI) für das Seeding verwendet, auch wenn ein Replikationsnetzwerk konfiguriert wurde, das diese Subnetze einbezieht.

• Wenn sich Quell- und Zielserver in verschiedenen Datencentern befinden, wird das Clientnetzwerk (MAPI) für das Seeding verwendet.

Auf der Ebene der DAG sind DAG-Netzwerke für die Verschlüsselung und Komprimierung konfiguriert. Die Standardeinstellungen geben an, dass die Verschlüsselung und Komprimierung nur für die Kommunikation in unterschiedlichen Subnetzen verwendet wird. Wenn sich Quelle und Ziel in unterschiedlichen Subnetzen befinden und die DAG mit den Standardwerten für NetworkCompression und NetworkEncryption konfiguriert ist, dann können Sie diese Werte mithilfe der Parameter NetworkCompressionOverride und NetworkEncryptionOverride beim Ausführen des Cmdlets Update-MailboxDatabaseCopy entsprechend außer Kraft setzen.

Seedingprozess

Wenn Sie einen Seedingprozess mithilfe des Cmdlets Add-MailboxDatabaseCopy oder Update-MailboxDatabaseCopy starten, werden die folgenden Tasks ausgeführt:

1. Es werden Datenbankeigenschaften aus Active Directory gelesen, um die angegebene Datenbank und die Server zu überprüfen. Außerdem wird überprüft, dass die Quell- und Zielserver Exchange 2010 ausführen, dass beide Mitglieder derselben DAG sind und dass die angegebene Datenbank keine Wiederherstellungsdatenbank ist. Die Dateipfade der Datenbank werden ebenfalls gelesen.

2. Vom Microsoft Exchange-Replikationsdienst auf dem Zielserver werden Vorbereitungen für Prüfungen zum erneuten Seeding getroffen.

3. Der Microsoft Exchange-Replikationsdienst auf dem Zielserver prüft das Vorhandensein von Datenbank- und Transaktionsprotokolldateien in den Dateiverzeichnissen, die von den Active Directory-Prüfungen in Schritt 1 gelesen werden.

4. Der Microsoft Exchange-Replikationsdienst gibt die Statusinformationen vom Zielserver an die Verwaltungsschnittstelle zurück, von der aus das Cmdlet ausgeführt wurde.

5. Wenn alle einleitenden Prüfungen bestanden wurden, werden Sie zur Bestätigung des Vorgangs aufgefordert, bevor dieser fortgesetzt wird. Wenn Sie den Vorgang bestätigen, wird der Prozess fortgesetzt. Wenn während der einleitenden Prüfungen ein Fehler auftritt, wird der Fehler gemeldet, und der Vorgang schlägt fehl.

6. Der Seedingvorgang wird vom Microsoft Exchange-Replikationsdienst auf dem Zielserver gestartet.

7. Der Microsoft Exchange-Replikationsdienst hält die Datenbankreplikation für die aktive Datenbankkopie an.

8. Die Statusinformationen für die Datenbank werden vom Microsoft Exchange-Replikationsdienst aktualisiert, um den Status für das Seeding anzugeben.

9. Wenn der Zielserver nicht bereits über die Verzeichnisse für die Zieldatenbank und die Protokolldateien verfügt, dann werden diese erstellt.

10. Vom Microsoft Exchange-Replikationsdienst auf dem Zielserver wird eine Anforderung für das Seeding der Datenbank an den Microsoft Exchange-Replikationsdienst auf dem Quellserver mithilfe von TCP übergeben. Diese Anforderung und die nachfolgende Kommunikation für das Seeding der Datenbank erfolgen in einem DAG-Netzwerk, das als Replikationsnetzwerk konfiguriert wurde.

11. Der Microsoft Exchange-Replikationsdienst auf dem Quellserver startet eine ESE-Streamingsicherung (Extensible Storage Engine) über die Schnittstelle des Microsoft Exchange-Informationsspeicherdiensts.

12. Der Microsoft Exchange-Informationsspeicherdienst sendet die Datenbankdaten als Stream an den Microsoft Exchange-Replikationsdienst.

13. Die Datenbankdaten werden vom Microsoft Exchange-Replikationsdienst des Quellservers zum Microsoft Exchange-Replikationsdienst das Zielservers verschoben.

14. Der Microsoft Exchange-Replikationsdienst auf dem Zielserver schreibt die Datenbankkopie in ein temporäres Verzeichnis, das sich im Hauptdatenbankverzeichnis temp-seeding befindet.

15. Die Streamingsicherung auf dem Quellserver endet, wenn das Ende der Datenbank erreicht wurde.

16. Der Schreibvorgang auf dem Zielserver wird abgeschlossen, und die Datenbank wird aus dem Verzeichnis "temp-seeding" an den endgültigen Speicherort verschoben. Das Verzeichnis "temp-seeding" wird gelöscht.

17. Auf dem Zielserver leitet der Microsoft Exchange-Replikationsdienst eine Anforderung mittels Proxyweiterleitung an den Microsoft Exchange-Suchdienst weiter, um den Inhaltsindexkatalog für die Datenbankkopie einzubinden, sofern dieser vorhanden ist. Wenn veraltete Katalogdateien einer früheren Instanz der Datenbankkopie vorhanden sind, schlägt der Einbindungsvorgang fehl, sodass der Katalog vom Quellserver repliziert werden muss. Wenn der Katalog nicht vorhanden ist, wie es bei einer neuen Instanz der Datenbankkopie auf dem Zielserver der Fall ist, ist entsprechend eine Kopie des Katalogs erforderlich. Der Microsoft Exchange-Replikationsdienst weist den Microsoft Exchange-Suchdienst an, die Indizierung für die Datenbankkopie anzuhalten, während ein neuer Katalog von der Quelle kopiert wird.

18. Der Microsoft Exchange-Replikationsdienst auf dem Zielserver sendet eine Anforderung zum Seeding des Katalogs an den Microsoft Exchange-Replikationsdienst auf dem Quellserver.

19. Auf dem Quellserver fordert der Microsoft Exchange-Replikationsdienst die Verzeichnisinformationen vom Microsoft Exchange-Suchdienst sowie das Anhalten der Indizierung an.

20. Der Microsoft Exchange-Suchdienst auf dem Quellserver gibt die Verzeichnisinformationen des Suchkatalogs an den Microsoft Exchange-Replikationsdienst zurück.

21. Der Microsoft Exchange-Replikationsdienst auf dem Quellserver liest die Katalogdateien aus dem Verzeichnis.

22. Der Microsoft Exchange-Replikationsdienst auf dem Quellserver verschiebt die Katalogdaten mithilfe einer Verbindung über das Replikationsnetzwerk zum Microsoft Exchange-Replikationsdienst auf dem Zielserver. Nachdem der Lesevorgang abgeschlossen ist, sendet der Microsoft Exchange-Replikationsdienst eine Anforderung an den Microsoft Exchange-Suchdienst, um die Indizierung der Quelldatenbank fortzusetzen.

23. Wenn sich im Verzeichnis auf dem Zielserver vorhandene Katalogdateien befinden, werden diesem vom Microsoft Exchange-Replikationsdienst auf dem Zielserver gelöscht.

24. Der Microsoft Exchange-Replikationsdienst auf dem Zielserver schreibt die Katalogdateien in das temporäre Verzeichnis CiSeed.Temp, bis die Daten vollständig übertragen wurden.

25. Der Microsoft Exchange-Replikationsdienst verschiebt die vollständigen Katalogdaten an ihren endgültigen Speicherort.

26. Der Microsoft Exchange-Replikationsdienst auf dem Zielserver fährt mit der Suchindizierung für die Zieldatenbank fort.

27. Der Microsoft Exchange-Replikationsdienst auf dem Zielserver gibt einen Fertigstellungsstatus zurück.

28. Das letzte Ergebnis des Vorgangs wird an die Verwaltungsschnittstelle übergeben, von der aus das Cmdlet aufgerufen wurde.

Konfigurieren von Datenbankkopien

Nachdem eine Datenbankkopie erstellt wurde, können Sie ihre Konfigurationseinstellungen bei Bedarf anzeigen und ändern. Sie können einige Konfigurationsinformationen für eine Datenbankkopie in der Exchange-Verwaltungskonsole auf der Seite Eigenschaften anzeigen. Sie können auch die Cmdlets Get-MailboxDatabase und Set-MailboxDatabaseCopy in der Shell verwenden und damit die Einstellungen der Datenbankkopie anzeigen und konfigurieren, z. B. die Wiedergabeverzögerung, die Abschneideverzögerung und die Aktivierungseinstellungsreihenfolge. Genaue Anweisungen zum Anzeigen und Konfigurieren der Einstellungen von Datenbankkopien finden Sie unter Konfigurieren der Eigenschaften von Postfachdatenbankkopien.

Verwenden von Optionen für die Wiedergabe- und Abschneideverzögerung

Postfachdatenbankkopien unterstützen die Verwendung von Wiedergabeverzögerungen und Abschneideverzögerungen, die jeweils innerhalb von Minuten konfiguriert werden können. Durch das Festlegen einer Wiedergabeverzögerung können Sie bei einer Datenbankkopie zu einem bestimmten Zeitpunkt zurückkehren. Durch das Festlegen einer Abschneideverzögerung können Sie anhand der Protokolle für eine passive Datenbankkopie die verlorenen Protokolldateien für die aktive Datenbankkopie wiederherstellen. Da beide Funktionen zu einer temporären Ansammlung an Protokolldateien führen, beeinflussen beide den Speicherentwurf.

Wiedergabeverzögerung

Die Wiedergabeverzögerung ist eine Eigenschaft einer Postfachdatenbankkopie, die die Dauer (in Minuten) angibt, die die Protokollwiedergabe für die Datenbankkopie verzögert wird. Der Zeitgeber für die Wiedergabeverzögerung startet, wenn eine Protokolldatei für die passive Kopie repliziert und erfolgreich überprüft wurde. Durch die Verzögerung der Wiedergabe von Protokollen für die Datenbankkopie haben Sie die Möglichkeit, die Datenbank zu einem bestimmten Zeitpunkt in der Vergangenheit wiederherzustellen. Eine Postfachdatenbankkopie mit einer Wiedergabeverzögerung von mehr als 0 wird als verzögerte Postfachdatenbankkopie oder einfach als verzögerte Kopie bezeichnet.

Eine Strategie, in der die Datenbankkopie und die Funktionen für die Aufbewahrung für eventuelle Rechtsstreitigkeiten in Exchange 2010 verwendet werden, kann vor einer Vielzahl von Fehlern schützen, die gewöhnlich zu Datenverlusten führen würden. Diese Funktionen können jedoch bei logischen Beschädigungen, die zwar sehr selten sind, jedoch möglicherweise zu Datenverlusten führen, keinen Schutz vor einem Datenverlust bieten. Verzögerte Kopien sind dazu gedacht, Datenverluste bei logischen Beschädigungen zu vermeiden. Im Allgemeinen gibt es zwei Arten von logischen Beschädigungen:

• Logische Beschädigung der Datenbank   Die Prüfsumme der Datenbankseiten stimmt überein, doch die Daten auf den Seiten sind logisch gesehen falsch. Dies kann vorkommen, wenn ESE versucht, eine Datenbankseite zu schreiben, und die Daten entweder niemals auf den Datenträger geschrieben wurden oder sie sich am falschen Speicherort befinden, auch wenn vom Betriebssystem eine Nachricht zur erfolgreichen Ausführung zurückgegeben wurde. Dies wird als verlorene Leerung bezeichnet. Damit bei verlorenen Leerungen keine Daten verloren gehen, bezieht ESE einen Mechanismus zur Erkennung verlorener Leerungen zusammen mit einer Funktion zum Patchen von Seiten (Einzelseitenwiederherstellung) in die Datenbank ein.

• Logische Beschädigung des Speichers   Es werden Daten auf eine Weise hinzugefügt, gelöscht oder geändert, die der Benutzer nicht erwartet. Diese Fälle werden im Allgemeinen durch Anwendungen von Drittanbietern verursacht. Es handelt sich im Allgemeinen nur insofern um eine Beschädigung, als der Benutzer sie als Beschädigung betrachtet. Der Exchange-Speicher betrachtet die Transaktion, die zur logischen Beschädigung geführt hat, als eine Folge gültiger MAPI-Operationen. Die Funktion für die Aufbewahrung für eventuelle Rechtsstreitigkeiten in Exchange 2010 bietet einen Schutz vor logischen Beschädigungen des Speichers (da verhindert wird, dass Inhalte von einem Benutzer oder einer Anwendung permanent gelöscht werden). Es gibt jedoch auch Szenarien, in denen ein Benutzerpostfach so beschädigt wird, dass es einfacher ist, die Datenbank zu einem Zeitpunkt vor der Beschädigung wiederherzustellen, um dann das Benutzerpostfach zu exportieren, damit nicht beschädigte Daten abgerufen werden können.

Durch die Kombination aus Datenbankkopien, Aufbewahrungsrichtlinien und ESE-Wiederherstellungen einzelner Seiten verbleibt nur die seltene, jedoch katastrophale logische Beschädigung des Speichers. Ihre Entscheidung, ob Sie eine Datenbankkopie mit Wiedergabeverzögerung (eine verzögerte Kopie) verwenden, hängt davon ab, welche Anwendungen von Drittanbietern Sie einsetzen und welche Erfahrungen Ihre Organisation mit logischen Beschädigungen des Speichers gemacht hat.

Wenn Sie verzögerte Kopien verwenden, beachten Sie die folgenden Konsequenzen für deren Verwendung:

• Anders als bei der fortlaufenden Standbyreplikation (Standby Continuous Replication, SCR) in Exchange 2007, die eine hartcodierte Wiedergabeverzögerung von 50 Protokolldateien aufweist, gibt es keine hartcodierte Anzahl von verzögerten Protokolldateien. Stattdessen ist die Wiedergabeverzögerung ein vom Administrator konfigurierter Wert, der standardmäßig deaktiviert ist.

• Die Einstellung für die Wiedergabeverzögerung besitzt eine Standardeinstellung von 0 Tagen sowie eine maximale Einstellung von 14 Tagen.

• Verzögerte Kopien werden nicht als hochverfügbare Kopien betrachtet. Stattdessen wurden sie zur Notfallwiederherstellung entworfen, um vor logischen Beschädigungen des Speichers zu schützen.

• Je größer die Wiedergabeverzögerung, desto länger ist der Datenbankwiederherstellungsprozess. Je nach der Anzahl der Protokolldateien, die während der Wiederherstellung wiedergegeben werden müssen, und nach der Geschwindigkeit, mit der Ihre Hardware diese wiedergeben kann, sind möglicherweise einige Stunden oder mehr für die Wiederherstellung einer Datenbank erforderlich.

• Es wird empfohlen, dass Sie ermitteln, ob verzögerte Kopien für ihre Gesamtstrategie zur Wiederherstellung entscheidend sind. Wenn deren Verwendung für ihre Strategie entscheidend ist, wird empfohlen, mehrere verzögerte Kopien zu verwenden. Sie können auch RAID (Redundant Array of Independent Disks) verwenden, um eine einzelne verzögerte Kopie zu schützen, wenn Sie nicht über mehrere verzögerte Kopien verfügen. Falls Sie einen Datenträger verlieren oder eine Beschädigung auftritt, verlieren Sie nicht Ihren verzögerten Zeitpunkt in der Vergangenheit.

• Verzögerte Kopien können nicht mit der ESE-Funktion zur Wiederherstellung einzelner Seiten gepatcht werden. Wenn bei einer verzögerten Kopie die Beschädigung einer Datenbankseite auftritt (z. B. der Fehler -1018), dann muss für diese Kopie das erneute Seeding ausgeführt werden (wodurch der verzögerte Aspekt der Kopie verloren geht).

Das Aktivieren und Wiederherstellen einer verzögerten Postfachdatenbankkopie ist ein einfacher Vorgang, wenn die Datenbank alle Protokolldateien wiedergeben und die Datenbankkopie auf den aktuellen Stand gebracht werden soll. Wenn Sie die Protokolldateien nur bis zu einem bestimmten Zeitpunkt wiedergeben möchten, ist der Vorgang komplizierter, da Sie die Protokolldateien manuell bearbeiten und das Tool "Eseutil" ausführen müssen.

Genaue Anweisungen zum Aktivieren einer verzögerten Postfachdatenbankkopie finden Sie unter Aktivieren einer verzögerten Kopie einer Postfachdatenbank.

Abschneideverzögerung

Die Abschneideverzögerung ist eine Eigenschaft einer Postfachdatenbankkopie, die die Dauer (in Minuten) angibt, die das Löschen des Protokolls für die Datenbankkopie verzögert wird. Der Zeitgeber für die Abschneideverzögerung startet, wenn eine Protokolldatei für die passive Kopie repliziert und erfolgreich überprüft wurde sowie erfolgreich in der Kopie der Datenbank wiedergegeben wurde. Durch die Verzögerung beim Abschneiden von Protokolldateien von der Datenbankkopie haben Sie die Möglichkeit, eine Wiederherstellung nach Fehlern durchzuführen, die die Protokolldateien für die aktive Kopie der Datenbank betreffen.

Datenbankkopien und Abschneiden der Protokolldateien

Das Abschneiden der Protokolldateien funktioniert in Exchange 2010 auf die gleiche Weise wie in Exchange 2007. Das Abschneideverhalten wird durch die Einstellungen für die Wiedergabe- und Abschneideverzögerung der Kopie bestimmt.

Die folgenden Kriterien müssen für das Abschneiden der Protokolldatei einer Datenbankkopie erfüllt sein, wenn die die Standardwerte (0 = deaktiviert) der Verzögerungseinstellungen beibehalten werden:

• Die Protokolldatei muss erfolgreich gesichert worden sein, oder die Umlaufprotokollierung muss aktiviert sein.

• Die Protokolldatei muss sich unterhalb des Prüfpunkts (die für die Wiederherstellung erforderliche minimale Protokolldatei) für die Datenbank befinden.

• Alle anderen verzögerten Kopien müssen die Protokolldatei geprüft haben.

• Alle anderen Kopien (nicht verzögerte Kopien) müssen die Protokolldatei wiedergegeben haben.

Die folgenden Kriterien müssen erfüllt sein, damit das Abschneiden für eine verzögerte Datenbankkopie erfolgt:

• Die Protokolldatei muss sich unterhalb des Prüfpunkts für die Datenbank befinden.

• Die Protokolldatei muss älter sein als "ReplayLagTime" + "TruncationLagTime".

• Die Protokolldatei muss für die aktive Kopie abgeschnitten worden sein.

Datenbankaktivierungsrichtlinie

Es gibt Szenarien, in denen Sie möglicherweise eine Postfachdatenbankkopie erstellen und das System daran hindern möchten, diese Kopie bei einem Fehler automatisch zu aktivieren. Beispiel:

• Wenn Sie eine oder mehrere Postfachdatenbankkopien in einem zweiten oder in einem Ersatzdatencenter bereitstellen.

• Wenn Sie eine Datenbankkopie als verzögerte Kopie für Wiederherstellungszwecke konfigurieren.

• Wenn Sie die Wartung oder Aktualisierung eines Servers durchführen.

In jedem der vorangehenden Szenarien verfügen Sie über Datenbankkopien, die nicht automatisch vom System aktiviert werden sollen. Damit das System am automatischen Aktivieren einer Postfachdatenbankkopie gehindert wird, können Sie die Kopie so konfigurieren, dass sie für die Aktivierung blockiert (angehalten) ist. Dadurch kann das System die Aktualität der Datenbank mithilfe von Protokollversand und -wiederherstellung aufrecht erhalten, doch es wird daran gehindert, die Kopie automatisch zu aktivieren und zu verwenden. Für die Aktivierung blockierte Kopien müssen von einem Administrator manuell aktiviert werden. Sie können die Richtlinie für die Datenbankaktivierung mithilfe des Cmdlets Set-MailboxServer konfigurieren, um den Parameter DatabaseCopyAutoActivationPolicy auf "Blockiert" festzulegen.

Weitere Informationen zum Konfigurieren der Richtlinie für die Datenbankaktivierung finden Sie unter Konfigurieren der Aktivierungsrichtlinie für die Kopie einer Postfachdatenbank.

Ausgleichen von Datenbankkopien

Aufgrund der inhärenten Merkmale von DAGs werden die Hosts von aktiven Postfachdatenbankkopien durch Datenbankswitchover und -failover mehrfach während der Lebensdauer der DAG geändert. Dadurch kann die Verteilung der aktiven Postfachdatenbankkopien der DAGs aus dem Gleichgewicht geraten. Die folgende Tabelle zeigt als Beispiel eine DAG mit vier Datenbanken und vier Kopien jeder Datenbank (insgesamt 16 Datenbanken auf jedem Server) sowie einer unausgeglichenen Verteilung aktiver Datenbankkopien.

DAG mit unausgeglichener Verteilung aktiver Kopien

Im vorausgehenden Beispiel sind vier Kopien jeder Datenbank vorhanden, daher gibt es nur vier mögliche Werte für die Aktivierungseinstellungen (1, 2, 3 oder 4). Die Spalte Anzahl von Datenbanken mit diesen Einstellungen zeigt die Anzahl von Datenbanken mit diesen Werten. Auf EX3 gibt es beispielsweise 13 Datenbankkopien mit der Aktivierungseinstellung 1, zwei Kopien mit der Aktivierungseinstellung 2, eine Kopie mit der Aktivierungseinstellung 3 und keine Kopie mit der Aktivierungseinstellung 4.

Diese DAG ist also weder hinsichtlich der Anzahl von aktiven Datenbanken, die von jedem DAG-Mitglied gehostet werden, der Anzahl von passiven Datenbanken, die von jedem DAG-Mitglied gehostet werden, oder der Anzahl von gehosteten Datenbanken mit diesen Einstellungen ausgeglichen.

Sie können das Skript RedistributeActiveDatabases.ps1 verwenden, um die aktiven Postfachdatenbankkopien innerhalb einer DAG auszugleichen. Das Skript verschiebt Datenbanken zwischen ihren Kopien, um die Anzahl von eingebundenen Datenbanken auf jedem Server in einer DAG auszugleichen. Falls erforderlich, versucht das Skript auch einen Ausgleich aktiver Datenbanken an den Standorten durchzuführen.

Das Skript stellt zwei Optionen zum Ausgleich aktiver Datenbankkopien in einer DAG bereit:

• BalanceDbsByActivationPreference   Wenn diese Option aktiviert wurde, versucht das Skript, die Datenbanken auf die bevorzugte Kopie zu verschieben (basierend auf der Aktivierungseinstellung), ohne dabei den Active Directory-Standort zu berücksichtigen.

• BalanceDbsBySiteAndActivationPreference   Wenn diese Option aktiviert wurde, versucht das Skript, die Datenbanken auf die bevorzugte Kopie zu verschieben und einen Ausgleich der aktiven Datenbanken innerhalb jedes Active Directory-Standorts zu erreichen.

Nach Ausführen des Skripts mit der ersten Option wird die vorher unausgeglichene DAG ausgeglichen, wie in der folgenden Tabelle gezeigt.

DAG mit ausgeglichener Verteilung aktiver Kopien

Wie in der vorherigen Tabelle gezeigt, ist diese DAG jetzt bezüglich der Anzahl aktiver und passiver Datenbanken auf jedem Server und der Aktivierungseinstellungen auf den Servern ausgeglichen.

In der folgenden Tabelle werden die verfügbaren Parameter für das Skript RedistributeActiveDatabases.ps1 aufgelistet.

Skriptparameter "RedistributeActiveDatabases.ps1"

RedistributeActiveDatabases.ps1 – Beispiele

In diesem Beispiel wird die aktuelle Datenbankverteilung für eine DAG, einschließlich der Anzahl von Datenbanken mit diesen Einstellungen, veranschaulicht.

RedistributeActiveDatabases.ps1 -DagName DAG1 -ShowDatabaseDistributionByServer | Format-Table

In diesem Beispiel werden die aktiven Postfachdatenbankkopien in der DAG mithilfe von Aktivierungseinstellungen neu verteilt und ausgeglichen.

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference

In diesem Beispiel werden die aktiven Postfachdatenbankkopien in der DAG mithilfe von Aktivierungseinstellungen neu verteilt und ausgeglichen. Außerdem wird eine Zusammenfassung der Verteilung erstellt.

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution

Überwachen von Datenbankkopien

Eine Datenbankkopie stellt Ihre erste Verteidigungsmaßnahme dar, wenn ein Fehler auftritt, der sich auf die aktive Kopie einer Datenbank auswirkt. Es ist daher äußerst wichtig, den Zustand und Status von Datenbankkopien zu überwachen, damit sichergestellt ist, dass sie bei Bedarf verfügbar sind. Sie können einige Informationen zum Zustand und Status in der Exchange-Verwaltungskonsole auf der Seite Eigenschaften für eine Datenbankkopie anzeigen. Sie können auch das Cmdlet Get-MailboxDatabaseCopyStatus in der Shell verwenden, um eine Vielzahl von Statusinformationen für eine Datenbankkopie anzuzeigen.

Weitere Informationen zum Überwachen von Datenbankkopien finden Sie unter Überwachen von hoher Verfügbarkeit und Ausfallsicherheit für Standorte.

Entfernen einer Datenbankkopie

Eine Datenbankkopie kann jederzeit mithilfe der Exchange-Verwaltungskonsole oder mithilfe des Cmdlets Remove-MailboxDatabaseCopy in der Shell entfernt werden. Nachdem Sie eine Datenbankkopie entfernt haben, müssen Sie manuell alle Datenbank- und Transaktionsprotokolldateien von dem Server entfernen, von dem die Datenbankkopie entfernt wurde. Genaue Anweisungen zum Entfernen einer Datenbankkopie finden Sie unter Entfernen einer Postfachdatenbankkopie.

Datenbankswitchover

Der Postfachserver, der den Host für die aktive Kopie einer Datenbank darstellt, wird als Postfachdatenbankmaster bezeichnet. Die Aktivierung einer passiven Datenbankkopie ändert den Postfachdatenbankmaster für die Datenbank und macht aus der passiven Kopie eine neue, aktive Kopie. Dieser Prozess wird als Datenbankswitchover bezeichnet. Bei einem Datenbankswitchover wird die Einbindung einer aktiven Kopie einer Datenbank auf einem Postfachserver aufgehoben und eine passive Kopie dieser Datenbank als neue aktive Postfachdatenbank auf einem anderen Postfachserver eingebunden. Wenn Sie einen Switchover ausführen, können Sie die Wahleinstellung für die Datenbankeinbindung für den neuen Postfachdatenbankmaster optional außer Kraft setzen.

Sie können schnell erkennen, welcher Postfachserver der aktuelle Postfachdatenbankmaster ist, indem Sie die Spalte Kopiestatus unter der Registerkarte Datenbankkopien in der Exchange-Verwaltungskonsole überprüfen. Nur die aktive Kopie besitzt den Status Eingebunden. Alle anderen Datenbankkopien zeigen den aktuellen Status der Replikation für die Datenbankkopie an. Sie können einen Switchover mithilfe des Assistenten zum Verschieben des Postfachdatenbankmasters in der Exchange-Verwaltungskonsole oder mithilfe des Cmdlets Move-ActiveMailboxDatabase in der Shell ausführen.

Es gibt verschiedene interne Prüfungen, die ausgeführt werden, bevor eine passive Kopie aktiviert wird:

• Der Status der Datenbankkopie wird überprüft. Wenn die Datenbankkopie einen fehlerhaften Status aufweist, wird der Switchover blockiert. Sie können dieses Verhalten außer Kraft setzen und die Systemdiagnose mithilfe des Parameters SkipHealthChecks des Cmdlets Move-ActiveMailboxDatabase umgehen. Mithilfe dieses Parameters können Sie die aktive Kopie in eine Datenbankkopie mit einem fehlerhaften Status verschieben.

• Die Länge der Kopie- und Wiedergabewarteschlange für die Datenbankkopie wird überprüft, um sicherzustellen, dass ihre Werte den konfigurierten Kriterien entsprechen. Die Datenbankkopie wird auch überprüft, damit sichergestellt ist, dass sie momentan nicht als Seedingquelle verwendet wird. Wenn die Werte für die Warteschlangenlänge nicht den konfigurierten Kriterien entsprechen oder die Datenbank derzeit als Seedingquelle verwendet wird, wird der Switchover blockiert. Sie können dieses Verhalten außer Kraft setzen und diese Prüfungen mithilfe des Parameters SkipLagChecks des Cmdlets Move-ActiveMailboxDatabase umgehen. Dieser Parameter ermöglicht es, dass eine Kopie aktiviert wird, die über nicht den Kriterien entsprechende Wiedergabe- und Kopiewarteschlangen verfügt.

• Der Status des Suchkatalogs (Inhaltsindex) für die Datenbankkopie wird überprüft. Wenn der Suchkatalog nicht auf dem neuesten Stand ist, sich in einem fehlerhaften Zustand befindet oder beschädigt ist, wird der Switchover blockiert. Sie können dieses Verhalten außer Kraft setzen und die Überprüfung des Suchkatalogs mithilfe des Parameters SkipClientExperienceChecks des Cmdlets Move-ActiveMailboxDatabase umgehen. Dieser Parameter führt dazu, dass diese Suche die Systemdiagnose für den Katalog überspringt. Wenn sich der Suchkatalog für die von Ihnen zu aktivierende Datenbankkopie in einem fehlerhaften oder nicht zu verwendenden Zustand befindet und Sie diesen Parameter zum Überspringen der Systemdiagnose für den Katalog verwenden und dann die Datenbankkopie aktivieren, müssen Sie den Suchkatalog erneut durchforsten oder das Seeding für den Katalog erneut ausführen.

Wenn Sie einen Datenbankswitchover ausführen, haben Sie auch die Möglichkeit, die Wahleinstellungen für die Einbindung außer Kraft zu setzen, die für den Server konfiguriert wurden, der den Host für die zu aktivierende passive Datenbankkopie darstellt. Der Parameter MountDialOverride des Cmdlets Move-ActiveMailboxDatabase weist den Zielserver an, die eigenen Wahleinstellungen für die Einbindung außer Kraft zu setzen und die vom Parameter MountDialOverride angegebenen Einstellungen zu verwenden.

Genaue Anweisungen zum Ausführen eines Switchovers für eine Datenbankkopie finden Sie unter Aktivieren einer Kopie einer Postfachdatenbank. Weitere Informationen zum Datenbankswitchover finden Sie unter Switchover und Failover.

 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.