Verwalten von Datenbankkopien

GILT FÜR:2016 2019 Subscription Edition

In Exchange Server können Sie die Exchange-Verwaltungskonsole (EAC) oder die Exchange-Verwaltungsshell verwenden, um Postfachdatenbankkopien hinzuzufügen, nachdem eine Datenbankverfügbarkeitsgruppe (DAG) erstellt, konfiguriert und mit Postfachservermitgliedern aufgefüllt wurde.

Verwalten von Datenbankkopien

Nachdem mehrere Kopien einer Datenbank erstellt wurden, können Sie das EAC oder die Exchange-Verwaltungsshell verwenden, um die folgenden Aufgaben auszuführen:

• Überwachen Sie die Integrität und status jeder Kopie.
• Führen Sie andere Verwaltungsaufgaben im Zusammenhang mit Datenbankkopien aus. Zum Beispiel:
  • Anhalten oder Fortsetzen einer Datenbankkopie.
  • Seeding für eine Datenbankkopie.
  • Überwachen von Datenbankkopien.
  • Konfigurieren von Datenbankkopiereinstellungen
  • Entfernen sie eine Datenbankkopie.

Anhalten und Fortsetzen von Datenbankkopien

Aus einer Vielzahl von Gründen, z. B. der Durchführung einer geplanten Wartung, müssen Sie die kontinuierliche Replikationsaktivität für eine Datenbankkopie möglicherweise anhalten und fortsetzen. Außerdem erfordern einige Verwaltungsaufgaben, z. B. das Seeding, dass Sie zuerst eine Datenbankkopie anhalten. Es wird empfohlen, alle Replikationsaktivitäten anzuhalten, wenn der Pfad der Datenbank oder ihrer Protokolldateien geändert wird. Sie können die Datenbankkopieraktivität anhalten und fortsetzen, indem Sie das EAC verwenden oder die Cmdlets Suspend-MailboxDatabaseCopy und Resume-MailboxDatabaseCopy in der Exchange-Verwaltungsshell ausführen. Ausführliche Schritte zum Anhalten oder Fortsetzen der kontinuierlichen Replikation für eine Datenbankkopie finden Sie unter Anhalten oder Fortsetzen einer Postfachdatenbankkopie.

Seeding von Datenbankkopien

Seeding, auch bekannt als Aktualisieren, ist, wenn eine leere Datenbank oder eine Kopie der Produktionsdatenbank dem Zielkopierspeicherort auf einem anderen Postfachserver in derselben DAG wie die aktive Datenbank hinzugefügt wird. Diese Datenbank wird zur Basisdatenbank für die von diesem Server verwaltete Kopie.

Abhängig von der Situation kann das Seeding einer Datenbank ein automatischer Prozess oder ein von Ihnen eingeleiteter, manueller Prozess sein. Wenn eine Datenbankkopie hinzugefügt wird, wird für die Kopie automatisch ein Seeding ausgeführt, wenn der Zielserver und sein Speicher ordnungsgemäß konfiguriert sind. Sie können den Parameter SeedingPostponed für das Cmdlet Add-MailboxDatabaseCopy verwenden, um ein manuelles Seeding für eine Datenbankkopie durchzuführen und beim Erstellen der Kopie kein automatisches Seeding durchzuführen.

Für Datenbankkopien ist nach dem anfänglichen Seeding selten ein erneutes Seeding erforderlich. Wenn jedoch ein erneutes Seeding erforderlich ist, oder um eine Datenbankkopie manuell zu seeden, anstatt die Kopie automatisch vom System zu seeden, haben Sie zwei Möglichkeiten:

• Verwenden Sie den Assistenten zum Aktualisieren des Kopierens von Postfachdatenbanken im EAC.
• Verwenden Sie das Cmdlet Update-MailboxDatabaseCopy in der Exchange-Verwaltungsshell.

Vor dem Seeding einer Datenbankkopie müssen Sie zunächst die Postfachdatenbankkopie anhalten. Ausführliche Anweisungen zum Seeding einer Datenbankkopie finden Sie unter Aktualisieren einer Postfachdatenbankkopie.

Nach Abschluss eines manuellen Seedvorgangs wird die Replikation für die Datenbankkopie des Postfachs mit Seeding automatisch fortgesetzt. Wenn die Replikation nicht automatisch fortgesetzt werden soll, können Sie den Parameter ManualResume im Cmdlet Update-MailboxDatabaseCopy verwenden.

Auswählen der Seedingziele

Wenn Sie einen Seedvorgang ausführen, können Sie Folgendes auswählen:

• Seeding für die Postfachdatenbankkopie.
• Seeding des Inhaltsindexkatalogs für die Postfachdatenbankkopie.
• Seeding sowohl für die Datenbankkopie als auch für den Inhaltsindexkatalog.

Das Standardverhalten des Assistenten zum Aktualisieren von Postfachdatenbankkopien und des Cmdlets Update-MailboxDatabaseCopy ist es, das Seeding sowohl für die Postfachdatenbankkopie als auch für die Inhaltsindex-Katalogkopie auszuführen.

Verwenden Sie den Parameter DatabaseOnly im Cmdlet Update-MailboxDatabaseCopy , um nur die Postfachdatenbankkopie zu seeden, ohne das Seeding für den Inhaltsindexkatalog auszuführen.

Verwenden Sie den CatalogOnly-Parameter im Cmdlet Update-MailboxDatabaseCopy , um nur die Kopie des Inhaltsindexkatalogs zu seeden.

Auswählen der Seedingquelle

Sie können jede fehlerfreie Datenbankkopie als Seedingquelle für eine andere Kopie dieser Datenbank verwenden. Diese Option ist besonders nützlich, wenn Sie eine DAG auf mehrere physische Standorte erweitert haben.

Betrachten Sie beispielsweise die folgende DAG-Bereitstellung mit vier Mitgliedern:

• MBX1 und MBX2 befinden sich in Portland, Oregon.
• MBX3 und MBX4 befinden sich in New York, New York.
• Eine Postfachdatenbank mit dem Namen DB1 ist auf MBX1 aktiv.
• Es gibt passive Kopien von DB1 auf MBX2 und MBX3.

Beim Hinzufügen einer Kopie von DB1 zu MBX4 können Sie die Kopie auf MBX3 als Quelle für das Seeding verwenden. Diese Option vermeidet seeding über die WAN-Verbindung (Wide Area Network) zwischen Portland und New York.

Um beim Hinzufügen einer neuen Datenbankkopie eine bestimmte Kopie als Quelle für das Seeding zu verwenden, können Sie die folgenden Schritte ausführen:

• Verwenden Sie den Parameter SeedingPostponed im Cmdlet Add-MailboxDatabaseCopy , um die Datenbankkopie hinzuzufügen. Andernfalls wird für die Datenbankkopie explizit ein Seeding mit der aktiven Kopie der Datenbank als Quelle erstellt.

• Sie können den zu verwendenden Quellserver im Assistenten zum Aktualisieren des Kopierens von Postfachdatenbanken im EAC angeben, oder Sie können den Parameter SourceServer im Cmdlet Update-MailboxDatabaseCopy verwenden, um den gewünschten Quellserver für das Seeding anzugeben.

  Im vorherigen Beispiel würden Sie MBX3 als Quellserver angeben. Andernfalls wird die Datenbankkopie explizit aus der aktiven Kopie der Datenbank aus seeded.

Seeding und Netzwerke

Zusätzlich zum Auswählen eines bestimmten Quellservers für das Seeding einer Postfachdatenbankkopie können Sie über die Exchange-Verwaltungsshell auch angeben, welche DAG-Netzwerke zu verwenden sind. Sie können die Komprimierungs- und Verschlüsselungseinstellungen des DAG-Netzwerks während des Seedvorgangs überschreiben.

Sie können die netzwerke angeben, die für das Seeding verwendet werden sollen, indem Sie den Network-Parameter im Cmdlet Update-MailboxDatabaseCopy und die gewünschten DAG-Netzwerke angeben. Wenn Sie den Network-Parameter nicht verwenden, verwendet das System das folgende Standardverhalten für die Auswahl eines Netzwerks, das für den Seedingvorgang verwendet werden soll:

• Wenn sich Quellserver und Zielserver im selben Subnetz befinden und ein Replikationsnetzwerk konfiguriert ist, das das Subnetz enthält, wird das Replikationsnetzwerk verwendet.

• Wenn sich der Quellserver und der Zielserver in unterschiedlichen Subnetzen befinden, wird das Clientnetzwerk (MAPI) für das Seeding verwendet, selbst wenn ein Replikationsnetzwerk mit diesen Subnetzen konfiguriert ist.

• Wenn sich der Quellserver und der Zielserver in unterschiedlichen Rechenzentren 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, können Sie diese Werte überschreiben, indem Sie die Parameter NetworkCompressionOverride und NetworkEncryptionOverride im Cmdlet Update-MailboxDatabaseCopy verwenden.

Seedingprozess

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

1. Datenbankeigenschaften aus Active Directory werden gelesen, um die angegebene Datenbank und die angegebenen Server zu überprüfen. Um zu überprüfen, ob die Quell- und Zielserver Exchange Server ausgeführt werden, sind beide Mitglieder derselben DAG und dass die angegebene Datenbank keine Wiederherstellungsdatenbank ist. Die Datenbankdateipfade 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 vorläufigen Überprüfungen erfolgreich sind, werden Sie aufgefordert, den Vorgang zu bestätigen, bevor Sie fortfahren. 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. Der Microsoft Exchange-Replikationsdienst aktualisiert die Statusinformationen für die Datenbank, um eine status des Seedings widerzuspiegeln.

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

10. Eine TCP-Anforderung zum Seeding der Datenbank wird vom Microsoft Exchange-Replikationsdienst auf dem Zielserver an den Microsoft Exchange-Replikationsdienst auf dem Quellserver übergeben. Diese Anforderung und die nachfolgende Kommunikation zum Seeding der Datenbank erfolgen in einem DAG-Netzwerk, das als Replikationsnetzwerk konfiguriert ist.

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 befindet, das als temporäres Seeding bezeichnet wird.

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 in einer neuen Instanz der Datenbankkopie auf dem Zielserver vorhanden 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 an und fordert an, dass die Indizierung angehalten wird.

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 Katalogdaten in ein temporäres Verzeichnis namens 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 im EAC auf der Seite Eigenschaften anzeigen. Sie können auch die Cmdlets Get-MailboxDatabase und Set-MailboxDatabaseCopy in der Exchange-Verwaltungsshell verwenden, um Datenbankkopiereinstellungen anzuzeigen und zu konfigurieren. Beispiel: Wiedergabeverzögerungszeit, Kürzungsverzögerung und Aktivierungspräferenzreihenfolge. Ausführliche Schritte zum Anzeigen und Konfigurieren von Datenbankkopiereinstellungen finden Sie unter Konfigurieren von Kopiereigenschaften für Postfachdatenbanken.

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 Features zur temporären Erstellung von Protokolldateien führen, wirkt sich die Verwendung einer dieser Features auf Ihren Speicherentwurf aus.

Wiedergabeverzögerung

Die Wiedergabeverzögerung ist eine Eigenschaft einer Postfachdatenbankkopie, die die Dauer (in Minuten) angibt, um die die Protokollwiedergabe für die Datenbankkopie verzögert wird. Der Wiedergabeverzögerungstimer startet, wenn eine Protokolldatei in die passive Kopie repliziert wird und die Überprüfung erfolgreich besteht. 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, die mit einer Wiedergabeverzögerung größer als 0 (null) konfiguriert ist, wird als verzögerte Kopie der Postfachdatenbank oder einfach als verzögerte Kopie bezeichnet.

Eine Strategie, die Datenbankkopien und die Beweissicherungsfeatures in Exchange Server verwendet, kann Schutz vor einer Reihe von Fehlern bieten, die normalerweise zu Datenverlusten führen würden. Diese Features können jedoch keinen Schutz vor Datenverlusten aufgrund logischer Beschädigung bieten. Obwohl logische Beschädigungen selten sind, kann sie zu Datenverlusten führen. Verzögerte Kopien sind so konzipiert, dass Datenverluste aufgrund logischer Beschädigungen verhindert werden. Im Allgemeinen gibt es zwei Arten von logischen Beschädigungen:

• Logische Beschädigung der Datenbank: Die Prüfsumme der Datenbankseiten stimmt überein, aber die Daten auf den Seiten sind logisch falsch. Diese Situation tritt auf, wenn ESE versucht, eine Datenbankseite zu schreiben. Obwohl das Betriebssystem eine Erfolgsmeldung zurückgibt, werden die Daten entweder nie auf den Datenträger geschrieben oder an die falsche Stelle geschrieben. Diese Bedingung 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 Speicherbeschädigung: Daten werden auf eine Weise hinzugefügt, gelöscht oder bearbeitet, die der Benutzer nicht erwartet. Nicht-Microsoft-Anwendungen verursachen in der Regel diese Fälle. Es wird im Allgemeinen als Korruption in dem Sinne betrachtet, dass der Benutzer es 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 Beweissicherungsfunktion in Exchange Server bietet Schutz vor logischer Speicherbeschädigung (da es verhindert, dass Inhalte von einem Benutzer oder einer Anwendung endgültig gelöscht werden). Es kann jedoch Szenarien geben, in denen ein Benutzerpostfach so beschädigt ist, dass es einfacher wäre, die Datenbank auf einen Zeitpunkt vor der Beschädigung wiederherzustellen und dann das Benutzerpostfach zu exportieren, um nicht beschädigte Daten abzurufen.

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 eine Datenbankkopie mit einer Wiedergabeverzögerung (einer verzögerten Kopie) verwendet werden soll, hängt davon ab, welche Nicht-Microsoft-Anwendungen Sie verwenden, und vom Verlauf Ihrer organization mit logischer Speicherbeschädigung.

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

• Die Wiedergabeverzögerungszeit ist ein vom Administrator konfigurierter Wert. Standardmäßig ist die Wiedergabeverzögerung deaktiviert.

• Die Einstellung für die Wiedergabeverzögerung weist eine Standardeinstellung von null Tagen und eine maximale Einstellung von 14 Tagen auf.

• Verzögerte Kopien werden nicht als hochverfügbare Kopien betrachtet. Stattdessen sind sie für Notfallwiederherstellungszwecke konzipiert, um vor logischer Speicherbeschädigung zu schützen.

• Je größer die festgelegte Wiedergabeverzögerung, desto länger ist der Datenbankwiederherstellungsprozess. Die Wiederherstellung einer Datenbank kann mehrere Stunden dauern:

  • Die Anzahl der Protokolldateien, die wiedergegeben werden sollen.
  • Die Geschwindigkeit, mit der Ihre Hardware sie wiedergeben kann.

• Es wird empfohlen, dass Sie bestimmen, ob verzögerte Kopien für Ihre allgemeine Strategie für die Notfallwiederherstellung von entscheidender Bedeutung sind. Wenn die Verwendung dieser Kopien für Ihre Strategie von entscheidender Bedeutung ist, empfehlen wir die Verwendung mehrerer verzögerter Kopien oder die Verwendung eines redundanten Arrays unabhängiger Datenträger (RAID), um eine einzelne verzögerte Kopie zu schützen, wenn Sie nicht über mehrere verzögerte Kopien verfügen. Wenn Sie einen Datenträger verlieren oder eine Beschädigung auftritt, verlieren Sie ihren verzögerten Zeitpunkt nicht.

• Verzögerte Kopien können nicht mit dem Single-Page-Wiederherstellungsfeature von ESE gepatcht werden. Wenn bei einer verzögerten Kopie eine Datenbankseitenbeschädigung auftritt (z. B. ein Fehler -1018), muss die Kopie erneut eingereet werden. Beim erneuten Einsenden wird der verzögerte Aspekt der Kopie verloren.

Wenn die Datenbank alle Protokolldateien wiedergeben und die Datenbankkopie aktuell machen soll, ist das Aktivieren und Wiederherstellen einer verzögerten Postfachdatenbankkopie ein einfacher Prozess. Wenn Sie Protokolldateien bis zu einem bestimmten Zeitpunkt wiedergeben möchten, ist der Vorgang schwieriger, da Sie Protokolldateien manuell bearbeiten und Exchange Server Database Utilities (Eseutil.exe) ausführen müssen.

Ausführliche Schritte zum Aktivieren einer verzögerten Postfachdatenbankkopie finden Sie unter Aktivieren einer verzögerten Postfachdatenbankkopie.

Abschneideverzögerung

Die Kürzungsverzögerungszeit ist die Eigenschaft einer Postfachdatenbankkopie, die die Zeit für die Verzögerung des Protokolllöschens für die Datenbankkopie in Minuten angibt, nachdem die Protokolldatei in die Datenbankkopie wiedergegeben wurde. Der Zeitgeber für die Abschneideverzögerung startet, wenn eine Protokolldatei für die passive Kopie repliziert, erfolgreich überprüft und 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

Die Protokollkürzung funktioniert in Exchange 2016 und Exchange 2019 genauso wie in Exchange 2010. 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 wurde erfolgreich gesichert, oder die Zirkelprotokollierung ist aktiviert.
• 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 haben die Protokolldatei überprüft.
• Alle anderen Kopien (mit Ausnahme von verzögerten Kopien) haben die Protokolldatei wiedergegeben.

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 wird für die aktive Kopie abgeschnitten.

In Exchange Server tritt keine Protokollkürzung bei einer aktiven Postfachdatenbankkopie auf, wenn mindestens eine passive Kopie angehalten wird. Wenn geplante Wartungsaktivitäten einen längeren Zeitraum in Anspruch nehmen (z. B. mehrere Tage), kann es zu erheblichen Protokolldateien kommen. 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.

Exchange Server verfügt jetzt über ein Feature namens lose Kürzung, das standardmäßig deaktiviert ist. Während des normalen Betriebs behält jede Datenbankkopie Protokolle bei, die an andere Datenbankkopien gesendet werden müssen, bis alle Kopien einer Datenbank bestätigen:

• Sie haben die Protokolldateien (passive Kopien) wiedergegeben.
• Sie haben die Protokolldateien (verzögerte Kopien) erhalten.

Dieses Verhalten ist das Standardverhalten beim Abschneiden von Protokollen. Wenn eine Datenbankkopie aus irgendeinem Grund offline geht, sammeln sich die Protokolldateien auf den Datenträgern an, die von anderen Kopien der Datenbank verwendet werden. Wenn die betreffende Datenbankkopie über einen längeren Zeitraum hinweg offline bleibt, kann dies dazu führen, dass die anderen Datenbankkopien nicht mehr über ausreichend Speicherplatz verfügen.

Das Abschneidungsverhalten unterscheidet sich, wenn lose Kürzung und Zirkelprotokollierung aktiviert sind. Jede Datenbankkopie verfolgt ihren eigenen freien Speicherplatz und wendet ungenaues Abschneiden an, wenn der freie Speicherplatz zur Neige geht.

• Für die aktive Kopie wird der älteste Nachzügler (die passive Datenkkopie, die in der Protokollwiedergabe am weitesten zurückliegt) ignoriert und beim Abschneiden werden die ältesten verbleibenden passiven Kopien respektiert. Die aktive Datenbankkopie ist dort, wo das globale Abschneiden berechnet wird.

• Wenn bei einer passiven Kopie der Speicherplatz knapp wird, werden die Protokolldateien unabhängig voneinander abgeschnitten, indem die konfigurierten Parameter verwendet werden, die weiter unten in der Tabelle Registrierungswert beschrieben werden. Die passiven Kopien versuchen, die Kürzungsentscheidung für die aktive Kopie zu berücksichtigen. Trotz der Implikation des Namens MinCopiesToProtect ignoriert Exchange nur den ältesten bekannten Nachzügler zum Zeitpunkt der Kürzung.

Wenn die Offlinedatenbank wieder online geschaltet wird, werden die fehlenden Protokolldateien aus den anderen fehlerfreien Kopien gelöscht, und ihre Datenbankkopie status ist FailedAndSuspended. Wenn in diesem Fall Autoreseed konfiguriert ist, wird die betroffene Kopie automatisch erneut eingeset. Wenn Autoreseed nicht konfiguriert ist, muss die Datenbankkopie manuell von einem Administrator seeded werden.

Wenn die Zirkelprotokollierung deaktiviert ist, berücksichtigt die lose Kürzung alle sicherungen. Durch die lose Kürzung werden keine Protokolldateien entfernt, die nicht gesichert wurden.

Das Abschneiden ist ein empfohlenes Feature für eine bevorzugte Architektur, in der keine Sicherungen verwendet werden und die Zirkelprotokollierung aktiviert ist.

Die erforderliche Anzahl von fehlerfreien Kopien, der Schwellenwert für freien Festplattenspeicher und die Anzahl der zu speichernden Protokolle sind konfigurierbare Parameter. Standardmäßig beträgt der Schwellenwert für freien Festplattenspeicher 204.800 MB (200 GB), und die Anzahl der zu speichernden Protokolle beträgt 100.000 (100 GB) für passive Kopien sowie 100.000 (100 GB) für aktive Kopien.

Zum Aktivieren der Funktion zum ungenauen Abschneiden und Konfigurieren der zugehörigen Parameter muss die Windows-Registrierung auf jedem DAG-Mitglied bearbeitet werden. Es gibt drei Registrierungswerte, die konfiguriert werden können und alle unter „HKLM\Software\Microsoft\ExchangeServer\v15\BackupInformation" gespeichert werden. Der BackupInformation-Schlüssel mit den folgenden DWORD-Werten ist standardmäßig nicht vorhanden und muss manuell erstellt werden. Die DWORD-Registrierungswerte unter „BackupInformation“ werden in der folgenden Tabelle beschrieben:

Bei Verwendung des LooseTruncation_MinLogsToProtect Registrierungswerts unterscheidet sich das Verhalten bei aktiven und passiven Datenbankkopien.

• Aktiv: Die Anzahl der zusätzlichen Protokolle, die vor den Protokollen aufbewahrt werden, die für die geschützten passiven Kopien erforderlich sind, und der erforderliche Bereich der aktiven Kopie.
• Passiv: Die Anzahl der Protokolle, die aus dem neuesten verfügbaren Protokoll verwaltet werden. Ein Zehntel dieser Zahl wird auch verwendet, um Protokolle vor dem erforderlichen Bereich dieser passiven Kopie zu verwalten.

Die beiden Grenzwerte gelten, um sicherzustellen, dass verzögerte Datenbankkopien nicht zu viel Speicherplatz in Anspruch nehmen, da ihr erforderlicher Bereich in der Regel sehr groß ist.

Datenbankaktivierungsrichtlinie

Es gibt Szenarien, in denen Sie eine Postfachdatenbankkopie erstellen und verhindern möchten, dass das System diese Kopie automatisch aktiviert. Beispiel: Nach einem Fehler:

• Sie stellen eine oder mehrere Postfachdatenbankkopien in einem alternativen oder Standby-Rechenzentrum bereit.
• Sie konfigurieren eine verzögerte Datenbankkopie zu Wiederherstellungszwecken.
• Sie führen Eine Wartung oder ein Serverupgrade durch.

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.

Diese Konfiguration ermöglicht es dem System, die Währung der Datenbank durch Protokollversand und Wiedergabe beizubehalten, verhindert jedoch, dass das System die Kopie automatisch aktiviert und verwendet. Ein Administrator muss kopien, die für die Aktivierung blockiert wurden, manuell aktivieren.

Sie können den Parameter DatabaseCopyAutoActivationPolicy auf Blocked für Folgendes festlegen:

• Ein ganzer Server mithilfe des Cmdlets Set-MailboxServer .
• Eine einzelne Datenbankkopie mithilfe des Cmdlets Set-MailboxDatabaseCopy .

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

Auswirkungen von Postfachverschiebungen auf die fortlaufende Replikation

Bei einer Postfachdatenbank mit hoher Auslastung und hoher Protokollgenerierungsrate besteht ein größeres Risiko von Datenverlust, wenn die Replikation in die passiven Datenbankkopien nicht mit der Protokollgenerierung Schritt halten kann. Ein Szenario, in dem eine hohe Protokollgenerierungsrate auftreten kann, sind Postfachverschiebungen. Exchange Server enthält eine Datengarantie-API, die von Diensten wie dem Exchange-Postfachreplikationsdienst (MRS) verwendet wird, um die Integrität der Datenbankkopierarchitektur basierend auf dem Wert des DataMoveReplicationConstraint-Parameters zu überprüfen, der vom System oder einem Administrator festgelegt wurde. Diese Datengarantie-API kann für folgende Aufgaben verwendet werden:

• Überprüfen der Replikationsintegrität: Bestätigt, dass die erforderliche Anzahl von Datenbankkopien verfügbar ist.

• Replikationsleerung überprüfen: Bestätigt, dass die erforderlichen Protokolldateien anhand der erforderlichen Anzahl von Datenbankkopien wiedergegeben werden.

Bei der Ausführung gibt die API die folgenden Statusinformationen für die aufrufende Anwendung zurück:

• Wiederholen: Gibt an, dass vorübergehende Fehler vorliegen, die verhindern, dass eine Bedingung anhand der Datenbank überprüft wird.

• Zufrieden: Gibt an, dass die Datenbank die erforderlichen Bedingungen erfüllt oder die Datenbank nicht repliziert wird.

• NotSatisfied: Gibt an, dass die Datenbank die erforderlichen Bedingungen nicht erfüllt. Darüber hinaus wird für die aufrufende Anwendung angegeben, weshalb die Antwort NotSatisfied zurückgegeben wurde.

Der Wert des DataMoveReplicationConstraint-Parameters für die Postfachdatenbank bestimmt, wie viele Datenbankkopien als Teil der Anforderung ausgewertet werden sollen. Der DataMoveReplicationConstraint-Parameter weist die folgenden möglichen Werte auf:

• None: Wenn Sie eine Postfachdatenbank erstellen, wird dieser Wert standardmäßig festgelegt. Bei Festlegung dieses Werts werden die Bedingungen der Datengarantie-API ignoriert. Diese Einstellung sollte nur für Postfachdatenbanken verwendet werden, die nicht repliziert werden.

• SecondCopy: Dies ist der Standardwert, wenn Sie die zweite Kopie einer Postfachdatenbank hinzufügen. Bei Festlegung dieses Werts muss mindestens eine passive Datenbankkopie die Bedingungen der Datengarantie-API erfüllen.

• SecondDatacenter: Wenn dieser Wert festgelegt ist, muss mindestens eine passive Datenbankkopie an einem anderen Active Directory-Standort die Bedingungen der Datengarantie-API erfüllen.

• AllDatacenters: Wenn dieser Wert festgelegt ist, muss mindestens eine passive Datenbankkopie an jedem Active Directory-Standort die Bedingungen der Datengarantie-API erfüllen.

• AllCopies: Wenn dieser Wert festgelegt ist, müssen alle Kopien der Postfachdatenbank die Bedingungen der Datengarantie-API erfüllen.

Überprüfen der Replikationsintegrität

Wenn die Datengarantie-API ausgeführt wird, um die Integrität der Infrastruktur der Datenbankkopien auszuwerten, werden verschiedene Elemente ausgewertet.

In allen Szenarien muss die passive Datenbankkopie die folgenden Bedingungen erfüllen:

• Fehlerfreier Status.

• Wiedergabewarteschlange mit einer Dauer von 10 Minuten des Wiedergabeverzögerungszeitraums.

• Länge der Kopiewarteschlange von weniger als 10 Protokollen.

• Durchschnittliche Länge der Kopiewarteschlange von weniger als 10 Protokollen. Die durchschnittliche Länge der Kopierwarteschlange wird basierend darauf berechnet, wie oft die Anwendung die Datenbank abgefragt status.

Überprüfen von Replikationslöschvorgängen

Die Datengarantie-API kann auch verwendet werden, um zu überprüfen, ob die erforderlichen Datenbankkopien die erforderlichen Transaktionsprotokolle wiedergegeben haben. Dies wird überprüft, indem der zuletzt wiedergegebene Protokollzeitstempel mit dem Des Commit-Zeitstempels des aufrufenden Diensts (in den meisten Fällen ist dies der Zeitstempel der letzten Protokolldatei, die erforderliche Daten enthält) plus zusätzliche fünf Sekunden (um Systemzeitabweichungen oder -abweichungen zu behandeln). Wenn der Wiedergabezeitstempel größer als der Commitzeitstempel ist, wird der DataMoveReplicationConstraint-Parameter erfüllt. Wenn der Wiedergabezeitstempel kleiner als der Commitzeitstempel ist, wird DataMoveReplicationConstraint nicht erfüllt.

Bevor Sie eine große Anzahl von Postfächern in oder aus Replikationsdatenbanken innerhalb einer DAG verschieben, sollten Sie den DataMoveReplicationConstraint-Parameter für jede Postfachdatenbank gemäß der folgenden Tabelle konfigurieren:

Ausgleichen von Datenbankkopien

Aufgrund des inhärenten Charakters von DAGs ändern aktive Postfachdatenbankkopien als Ergebnis von Datenbankwechseln und Failovern während der gesamten Lebensdauer einer DAG mehrmals den Host. 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.

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 Aktivierungseinstellungen der gehosteten Datenbanken ausgeglichen.

Sie können das Skript "RedistributeActiveDatabases.ps1" verwenden, um die aktiven Datenbankkopien 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 angegeben ist, versucht das Skript, Datenbanken ohne Berücksichtigung des Active Directory-Standorts in ihre bevorzugte Kopie zu verschieben (basierend auf der Aktivierungspräferenz).

• BalanceDbsBySiteAndActivationPreference: Wenn diese Option angegeben ist, versucht das Skript, aktive Datenbanken in die am häufigsten bevorzugte Kopie zu verschieben, während gleichzeitig versucht wird, aktive Datenbanken innerhalb jedes Active Directory-Standorts auszugleichen.

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

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 sind die verfügbaren Parameter für das Skript "RedistributeActiveDatabases.ps1" aufgeführt.

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 einer DAG mithilfe von Aktivierungseinstellungen neu verteilt und ausgeglichen, ohne dass eine Eingabe erforderlich ist.

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -Confirm:$False

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

Sie können eine Vielzahl von Informationen anzeigen, z. B. die Länge der Kopierwarteschlange, die Länge der Wiedergabewarteschlange, status und Informationen zum Inhaltsindexstatus, indem Sie die Details einer Datenbankkopie im EAC untersuchen. Sie können auch das Cmdlet Get-MailboxDatabaseCopyStatus in der Exchange-Verwaltungsshell verwenden, um eine Vielzahl von status Informationen für eine Datenbankkopie anzuzeigen.

Weitere Informationen zum Überwachen von Datenbankkopien finden Sie unter Überwachen von Datenbankverfügbarkeitsgruppen.

Entfernen einer Datenbankkopie

Eine Datenbankkopie kann jederzeit mithilfe des EAC oder mithilfe des Remove-MailboxDatabaseCopy -Cmdlets in der Exchange-Verwaltungsshell 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 die aktive Kopie einer Datenbank hostet, 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 rechte Spalte auf der Registerkarte Datenbankkopien im EAC überprüfen. Ein Switchover kann über den Link Aktivieren im EAC oder über das Move-ActiveMailboxDatabase -Cmdlet in der Exchange-Verwaltungsshell ausgeführt werden.

Es werden mehrere interne Überprüfungen durchgeführt, bevor eine passive Kopie aktiviert wird. In einigen Fällen wird der Switchover der Datenbank blockiert oder abgebrochen. In anderen Fällen können Sie die Cmdlets für verwenden, um einige Prüfungen zu verschieben oder zu überspringen.

• Der Status der Datenbankkopie wird überprüft. Wenn die Datenbankkopie einen fehlerhaften Status aufweist, wird der Switchover blockiert. Sie können dieses Verhalten überschreiben und die Integritätsprüfung umgehen, indem Sie den SkipHealthChecks-Parameter des Cmdlets Move-ActiveMailboxDatabase verwenden. Mithilfe dieses Parameters können Sie die aktive Kopie in eine Datenbankkopie mit einem fehlerhaften Status verschieben.

• Für die aktive Datenbankkopie wird überprüft, ob sie gegenwärtig eine Seedingquelle für passive Kopien der Datenbank ist. Wenn die aktive Kopie gegenwärtig als Seedingquelle verwendet wird, wird der Switchovervorgang blockiert. Sie können dieses Verhalten überschreiben und die Seedingquellenüberprüfung umgehen, indem Sie den SkipActiveCopyChecks-Parameter des Cmdlets Move-ActiveMailboxDatabase verwenden. Dieser Parameter ermöglicht das Verschieben einer aktiven Kopie, die als Seedingquelle verwendet wird. Die Verwendung dieses Parameters bewirkt, dass der Seedingvorgang abgebrochen wird und als fehlgeschlagen betrachtet wird.

• 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 überschreiben und diese Überprüfungen umgehen, indem Sie den SkipLagChecks-Parameter des Cmdlets Move-ActiveMailboxDatabase verwenden. 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 Suchkatalogüberprüfung umgehen, indem Sie den SkipClientExperienceChecks-Parameter des Cmdlets Move-ActiveMailboxDatabase verwenden. Dieser Parameter führt dazu, dass diese Suche die Systemdiagnose für den Katalog überspringt. Wenn sich der Suchkatalog für die Datenbankkopie, die Sie aktivieren, in einem fehlerhaften oder nicht verwendbaren Zustand befindet und Sie diesen Parameter verwenden, um die Katalogintegritätsprüfung zu überspringen und die Datenbankkopie zu aktivieren, müssen Sie den Suchkatalog entweder durchforsten oder erneut seeden.

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. Mithilfe des MountDialOverride-Parameters des Cmdlets Move-ActiveMailboxDatabase wird der Zielserver angewiesen, seine eigenen Einbindungswähleinstellungen zu überschreiben und die durch den MountDialOverride-Parameter angegebenen Einstellungen zu verwenden.

Genaue Anweisungen zum Ausführen eines Switchovers für eine Datenbankkopie finden Sie unter Aktivieren einer Kopie einer Postfachdatenbank.