Verwalten von Postfachdatenbankkopien

Artikel
04/04/2023

Gilt für: Exchange Server 2013

Nachdem eine Datenbankverfügbarkeitsgruppe (DAG) erstellt, konfiguriert und mit Postfachservermitgliedern aufgefüllt wurde, können Sie das Exchange Admin Center (EAC) oder die Exchange-Verwaltungsshell verwenden, um Postfachdatenbankkopien auf flexible und präzise Weise hinzuzufügen.

Verwalten von Datenbankkopien

Nachdem mehrere Kopien einer Datenbank erstellt wurden, können Sie das EAC oder die Shell verwenden, um die Integrität und den Status jeder Kopie zu überwachen und andere Verwaltungsaufgaben im Zusammenhang mit Datenbankkopien auszuführen. 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

Aus einer Vielzahl von Gründen, z. B. geplante Wartungen, kann es erforderlich sein, die fortlaufende Replikationsaktivität für eine Datenbankkopie anzusetzen und fortzusetzen. Darüber hinaus erfordern einige administrative Aufgaben, z. B. das Seeding, dass Sie zuerst eine Datenbankkopie anhalten. Es wird empfohlen, dass alle Replikationsaktivitäten angehalten werden, wenn der Pfad für die Datenbank oder ihre 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 Shell 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 der Prozess, bei dem eine Datenbank, entweder eine leere Datenbank oder eine Kopie der Produktionsdatenbank, dem Zielkopierspeicherort auf einem anderen Postfachserver in derselben DAG wie die aktive Datenbank 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 manueller Prozess sein, den Sie initiieren. Wenn eine Datenbankkopie hinzugefügt wird, erfolgt automatisch das Seeding der Kopie, sofern der Zielserver und sein Speicher ordnungsgemäß konfiguriert sind. Wenn Sie ein manuelles Seeding für eine Datenbankkopie durchführen möchten und beim Erstellen der Kopie kein automatisches Seeding ausführen möchten, können Sie den Parameter SeedingPostponed verwenden, wenn Sie das Cmdlet Add-MailboxDatabaseCopy ausführen.

Datenbankkopien müssen selten nach dem anfänglichen Seeding erneut eingereet werden. Wenn jedoch ein erneutes Seeding erforderlich ist oder Wenn Sie eine Datenbankkopie manuell seeden möchten, anstatt das System automatisch ein Seeding für die Kopie durchführen zu lassen, können diese Aufgaben mithilfe des Assistenten zum Aktualisieren des Kopierens von Postfachdatenbanken im EAC 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. Ausführliche Anweisungen zum Seeding einer Datenbankkopie finden Sie unter Aktualisieren einer Postfachdatenbankkopie.

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

Beim Ausführen eines Seedvorgangs können Sie auswählen, ob das Seeding für die Postfachdatenbankkopie, der Inhaltsindexkatalog für die Postfachdatenbankkopie oder sowohl die Datenbankkopie als auch die Kopie des Inhaltsindexkatalogs festgelegt werden sollen.

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 beim Ausführen des Cmdlets Update-MailboxDatabaseCopy den Parameter DatabaseOnly, um nur für die Postfachdatenbankkopie ein Seeding auszuführen, ohne ein Seeding für den Inhaltsindexkatalog auszuführen. Damit das Seeding nur für den Inhaltsindexkatalog ausgeführt wird, verwenden Sie den CatalogOnly-Parameter beim Ausführen des Update-MailboxDatabaseCopy-Cmdlets.

Auswählen der Seedingquelle

Jede fehlerfreie Datenbankkopie kann als Seedingquelle für eine zusätzliche Kopie dieser Datenbank verwendet werden. Dies ist besonders nützlich, wenn Sie über eine DAG verfügen, die über mehrere physische Standorte erweitert wurde. Stellen Sie sich beispielsweise eine DAG-Bereitstellung mit vier Mitgliedern vor, bei der sich zwei Mitglieder (MBX1 und MBX2) in Portland, Oregon und zwei Mitglieder (MBX3 und MBX4) in New York, New York, befinden. Eine Postfachdatenbank mit dem Namen DB1 ist auf MBX1 aktiv, und es gibt passive Kopien von DB1 unter 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. Dadurch vermeiden Sie seeding über die WAN-Verbindung (Wide Area Network) zwischen Portland und New York.

Wenn Sie beim Hinzufügen einer neuen Datenbankkopie eine bestimmte Kopie als Quelle für das Seeding verwenden möchten, gehen Sie wie folgt vor:

Verwenden Sie den Parameter SeedingPostponed , wenn Sie das Cmdlet Add-MailboxDatabaseCopy ausführen, um die Datenbankkopie hinzuzufügen. Wenn der SeedingPostponed-Parameter nicht verwendet wird, wird die Datenbankkopie explizit mit der aktiven Kopie der Datenbank als Quelle seeded.
Sie können den Quellserver angeben, den Sie als Teil des Assistenten zum Aktualisieren des Kopierens von Postfachdatenbanken im EAC verwenden möchten, oder Sie können den Parameter SourceServer verwenden, wenn Sie das Cmdlet Update-MailboxDatabaseCopy ausführen, um den gewünschten Quellserver für das Seeding anzugeben. Im vorherigen Beispiel würden Sie „MBX3" als Quellserver angeben. Wenn der SourceServer-Parameter nicht verwendet wird, 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 auch die Shell verwenden, um anzugeben, welche DAG-Netzwerke verwendet werden sollen, und optional die Komprimierungs- und Verschlüsselungseinstellungen des DAG-Netzwerks während des Seedvorgangs außer Kraft setzen.

Hinweis

Das Seeding eines Kontextindexkatalogs ist nur über ein MAPI-Netzwerk möglich. Dies gilt auch, wenn Sie den -Network Parameter im Cmdlet Update-MailboxDatabaseCopy verwenden.

Um die Netzwerke anzugeben, die Sie für das Seeding verwenden möchten, verwenden Sie den Network-Parameter , wenn Sie das Cmdlet Update-MailboxDatabaseCopy ausführen, und geben Sie die zu verwendenden DAG-Netzwerke an. 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 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 sind, Verschlüsselung und Komprimierung nur für die Kommunikation in verschiedenen Subnetzen zu verwenden. 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 der Cmdlets Add-MailboxDatabaseCopy oder Update-MailboxDatabaseCopy initiieren, werden die folgenden Aufgaben ausgeführt:

Datenbankeigenschaften aus Active Directory werden gelesen, um die angegebene Datenbank und die angegebenen Server zu überprüfen. Um zu überprüfen, ob auf den Quell- und Zielservern Exchange 2013 ausgeführt wird, sind beide Mitglieder derselben DAG, und die angegebene Datenbank ist keine Wiederherstellungsdatenbank. Die Datenbankdateipfade werden ebenfalls gelesen.
Vom Microsoft Exchange-Replikationsdienst auf dem Zielserver werden Vorbereitungen für Prüfungen zum erneuten Seeding getroffen.
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.
Der Microsoft Exchange-Replikationsdienst gibt die Statusinformationen vom Zielserver an die Verwaltungsschnittstelle zurück, von der aus das Cmdlet ausgeführt wurde.
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.
Der Seedingvorgang wird vom Microsoft Exchange-Replikationsdienst auf dem Zielserver gestartet.
Der Microsoft Exchange-Replikationsdienst hält die Datenbankreplikation für die aktive Datenbankkopie an.
Die Statusinformationen für die Datenbank werden vom Microsoft Exchange-Replikationsdienst aktualisiert, um den Status für das Seeding anzugeben.
Wenn der Zielserver nicht bereits über die Verzeichnisse für die Zieldatenbank und die Protokolldateien verfügt, dann werden diese erstellt.
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.
Der Microsoft Exchange-Replikationsdienst auf dem Quellserver startet eine ESE-Streamingsicherung (Extensible Storage Engine) über die Schnittstelle des Microsoft Exchange-Informationsspeicherdiensts.
Der Microsoft Exchange-Informationsspeicherdienst sendet die Datenbankdaten als Stream an den Microsoft Exchange-Replikationsdienst.
Die Datenbankdaten werden vom Microsoft Exchange-Replikationsdienst des Quellservers zum Microsoft Exchange-Replikationsdienst das Zielservers verschoben.
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.
Die Streamingsicherung auf dem Quellserver endet, wenn das Ende der Datenbank erreicht wurde.
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.
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.
Der Microsoft Exchange-Replikationsdienst auf dem Zielserver sendet eine Anforderung zum Seeding des Katalogs an den Microsoft Exchange-Replikationsdienst auf dem Quellserver.
Auf dem Quellserver fordert der Microsoft Exchange-Replikationsdienst die Verzeichnisinformationen vom Microsoft Exchange-Suchdienst sowie das Anhalten der Indizierung an.
Der Microsoft Exchange-Suchdienst auf dem Quellserver gibt die Verzeichnisinformationen des Suchkatalogs an den Microsoft Exchange-Replikationsdienst zurück.
Der Microsoft Exchange-Replikationsdienst auf dem Quellserver liest die Katalogdateien aus dem Verzeichnis.
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.
Wenn sich im Verzeichnis auf dem Zielserver vorhandene Katalogdateien befinden, werden diesem vom Microsoft Exchange-Replikationsdienst auf dem Zielserver gelöscht.
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.
Der Microsoft Exchange-Replikationsdienst verschiebt die vollständigen Katalogdaten an ihren endgültigen Speicherort.
Der Microsoft Exchange-Replikationsdienst auf dem Zielserver fährt mit der Suchindizierung für die Zieldatenbank fort.
Der Microsoft Exchange-Replikationsdienst auf dem Zielserver gibt einen Fertigstellungsstatus zurück.
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 Shell verwenden, um Datenbankkopiereinstellungen anzuzeigen und zu konfigurieren, z. B. Wiedergabeverzögerungszeit, Kürzungsverzögerungszeit und Aktivierungseinstellungsreihenfolge. 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 zu einer temporären Ansammlung an Protokolldateien führen, beeinflussen beide den Speicherentwurf.

Wiedergabeverzögerung

Die Wiedergabeverzögerungszeit ist eine Eigenschaft einer Postfachdatenbankkopie, die die Zeitspanne in Minuten angibt, um die Protokollwiedergabe für die Datenbankkopie zu verzögern. 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, die Datenbankkopien und die Beweissicherungsfeatures in Exchange 2013 verwendet, kann Schutz vor einer Reihe von Fehlern bieten, die normalerweise 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, aber die Daten auf den Seiten sind logisch 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 Speicherbeschädigung: Daten werden auf eine Weise hinzugefügt, gelöscht oder bearbeitet, 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. Das Beweissicherungsfeature in Exchange 2013 bietet Schutz vor logischer Speicherbeschädigung (da es verhindert, dass Inhalte von einem Benutzer oder einer Anwendung endgültig 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.

Verzögerte Kopien können in Exchange 2013 für sich selbst sorgen, wenn Sie die automatische Protokollwiedergabe aufrufen, um die Protokolldateien in bestimmten Szenarien wiederzugeben:

Wenn ein Schwellenwert für zu wenig Speicherplatz erreicht wird
Wenn die verzögerte Kopie eine physische Beschädigung aufweist und ein Seitenpatching erforderlich ist
Wenn für mehr als 24 Stunden weniger als drei fehlerfreie Kopien (nur aktiv oder passiv; verzögerte Datenbankkopien werden nicht gezählt) zur Verfügung stehen

Das Patchen von Seiten ist für verzögerte Kopien über diese automatische Wiedergabefunktion verfügbar. Wenn das System ermittelt, dass für eine verzögerte Kopie ein Seitenpatching erforderlich ist, werden die Protokolle automatisch in die verzögerte Kopie wiedergegeben, um das Seitenpatching auszuführen. Verzögerte Kopien rufen die automatische Wiedergabefunktion auch auf, wenn ein Schwellenwert bezüglich zu wenig Speicherplatz erreicht wird und wenn die verzögerte Kopie während eines bestimmten Zeitraums die einzige verfügbare Kopie ist.

Die Wiedergabe für verzögerte Kopien ist standardmäßig deaktiviert und kann durch Ausführung des folgenden Befehls aktiviert werden:

Set-DatabaseAvailabilityGroup <DAGName> -ReplayLagManagerEnabled $true

Nach der Aktivierung wird eine Wiedergabe durchgeführt, wenn weniger als drei Kopien zur Verfügung stehen. Sie können den Standardwert 3 ändern, indem Sie den folgenden DWORD-Registrierungswert bearbeiten.

HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagManagerNumAvailableCopies

Sie müssen den folgenden Registrierungswert konfigurieren, um die Wiedergabe bei Erreichen von Schwellenwerten in Bezug auf zu wenig Speicherplatz zu aktivieren:

HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagLowSpacePlaydownThresholdInMB

Starten Sie nach der Konfiguration einer dieser Registrierungseinstellungen den Microsoft Exchange DAG-Verwaltungsdienst neu, damit die Änderungen übernommen werden.

Betrachten Sie beispielsweise eine Umgebung, in der eine bestimmte Datenbank über 4 Kopien (3 hochverfügbare Kopien und 1 verzögerte Kopie) verfügt und die Standardeinstellung für ReplayLagManagerNumAvailableCopies verwendet wird. Wenn eine nicht verzögerte Kopie aus irgendeinem Grund außer Betrieb ist (z. B. wird sie angehalten usw.), spielt die verzögerte Kopie ihre Protokolldateien in 24 Stunden automatisch ab.

Wenn Sie verzögerte Kopien verwenden möchten, ohne den ReplayLagManagerEnabled Parameter zu aktivieren, beachten Sie die folgenden Auswirkungen:

Die Wiedergabeverzögerung ist 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 festgelegte 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 bestimmen, ob verzögerte Kopien für Ihre allgemeine Strategie für die Notfallwiederherstellung wichtig 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 den 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 sie erneut eingeset werden (wodurch der verzögerte Aspekt der Kopie verloren geht).

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

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

Abschneideverzögerung

Die Kürzungsverzögerungszeit ist eine Eigenschaft einer Postfachdatenbankkopie, die angibt, wie lange das Löschen des Protokolls für die Datenbankkopie verzögert wird, nachdem die Protokolldatei in der 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 2013 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 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 (keine verzögerten 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.

In Exchange 2013 tritt keine Protokollkürzung für eine aktive Postfachdatenbankkopie auf, wenn mindestens eine passive Kopie angehalten wird. Wenn geplante 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.

Exchange 2013 Service Pack 1 (SP1) führt ein neues Feature namens lose Kürzung ein, das standardmäßig deaktiviert ist. Während des Normalbetriebs verwaltet jede Datenbankkopie Protokolle, die an die anderen Datenbankkopien gesendet werden müssen, bis alle Kopien der Datenbank die Wiedergabe (passive Kopien) oder den Empfang (verzögerte Kopien) der Protokolldateien bestätigen. Dies ist das Standardverhalten für das Abschneiden der Protokolle. 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.

Wenn loses Abschneiden aktiviert ist, unterscheidet sich das Kürzungsverhalten. 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. 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 bei einer passiven Kopie der Speicherplatz knapp wird, werden die Protokolldateien unabhängig voneinander abgeschnitten, indem die unten beschriebenen konfigurierten Parameter verwendet werden.

Wenn die Offllinedatenbank wieder online geht, fehlen hier die Protokolldateien, die von den anderen fehlerfreien gelöscht werden, und daher erhält diese Datenbankkopie den Status FailedAndSuspended. In diesem Fall wird AutoReseed konfiguriert, und für die betreffende Kopie wird automatisch ein erneutes Seeding durchgeführt. Wenn AutoReseed nicht konfiguriert ist, muss der Administrator manuell ein erneutes Seeding für die Datenbankkopie durchführen.

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, die alle unter HKLM\Software\Microsoft\ExchangeServer\v15\BackupInformationgespeichert werden. Der Schlüssel „BackupInformation" mit den folgenden DWORD-Werten ist standardmäßig nicht vorhanden, sondern muss manuell erstellt werden. Die DWORD-Registrierungswerte unter „BackupInformation“ werden in der folgenden Tabelle beschrieben:

Registrierungswert	Beschreibung	Standardwert
LooseTruncation_MinCopiesToProtect	Dieser Schlüssel dient zur Aktivierung des ungenauen Abschneidens. Er steht für die Anzahl der passiven Kopien, die vor dem ungenauen Abschneiden auf der aktiven Kopie einer Datenbank geschützt werden sollen. Durch Festlegen dieses Schlüsselwerts auf 0 wird das ungenaue Abschneiden deaktiviert.	0
LooseTruncation_MinDiskFreeSpaceThresholdInMB	Schwellenwert für verfügbaren Festplattenspeicher (in MB) zum Auslösen der Funktion zum ungenauen Abschneiden. Wenn weniger freier Festplattenspeicher vorhanden ist, als hier angegeben, wird die Funktion zum ungenauen Abschneiden aktiviert.	Falls dieser Registrierungswert nicht konfiguriert ist, wird der Standardwert von 200 GB für das ungenaue Abschneiden verwendet.
LooseTruncation_MinLogsToProtect	Die minimale Anzahl von Protokolldateien, die für fehlerfreie Kopien, deren Protokolle abgeschnitten werden, aufbewahrt werden sollen. Wenn dieser Registrierungswert konfiguriert ist, gilt der konfigurierte Wert sowohl für aktive als auch für passive Kopien.	Falls dieser Registrierungswert nicht konfiguriert ist, wird der Standardwert von 100.000 für passive Datenbankkopien und 100.000 für aktive Datenbankkopien verwendet.

Beachten Sie bei Verwendung des LooseTruncation_MinLogsToProtect Registrierungswerts, dass sich das Verhalten bei aktiven und passiven Datenbankkopien unterscheidet. Bei der aktiven Datenbankkopie ist dies 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. Bei einer passiven Datenbankkopie ist dies 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 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 alternativen Datencenter 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 Datenbankaktivierungsrichtlinie für einen gesamten Server konfigurieren, indem Sie das Cmdlet Set-MailboxServer oder eine einzelne Datenbankkopie verwenden, indem Sie das Cmdlet Set-MailboxDatabaseCopy verwenden, um den Parameter DatabaseCopyAutoActivationPolicy auf Blocked festzulegen.

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 2013 enthält eine Datengarantie-API, die von Diensten wie dem Microsoft 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 wurden.

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.

Wenn der DataMoveReplicationConstraint-Parameter auf... festgelegt ist	Dann für eine bestimmte Datenbank...	Bedingungen
`SecondCopy`	Mindestens eine passive Datenbankkopie für eine replizierte Datenbank muss die Bedingungen in der nächsten Spalte erfüllen.	Die passive Datenbank muss folgende 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 Kopiewarteschlange wird basierend auf der Anzahl von Abfragen des Datenbankstatus durch die Anwendung berechnet.
`SecondDatacenter`	Mindestens eine passive Datenbankkopie an einem anderen Active Directory-Standort muss die Bedingungen in der nächsten Spalte erfüllen.
`AllDatacenters`	Die aktive Kopie muss eingebunden sein, und eine passive Kopie an jedem Active Directory-Standort muss die Bedingungen in der nächsten Spalte erfüllen.
`AllCopies`	Die aktive Kopie muss eingebunden sein, und alle passiven Datenbankkopien müssen die Bedingungen in der nächsten Spalte erfüllen.

Ü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 weitere 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, empfiehlt es sich, den DataMoveReplicationConstraint-Parameter für jede Postfachdatenbank wie folgt zu konfigurieren:

Wenn Sie bereitstellen...	Legen Sie DataMoveReplicationConstraint auf fest.
Postfachdatenbanken, die keine Datenbankkopien aufweisen	`None`
Eine DAG innerhalb eines einzelnen Active Directory-Standorts	`SecondCopy`
Eine DAG, die sich über mehrere Rechenzentren erstreckt, unter Verwendung eines verteilten Active Directory-Standorts	`SecondCopy`
Eine DAG, die sich über zwei Active Directory-Standorte erstreckt, und Sie verfügen über hochverfügbare Datenbankkopien an jedem Standort.	`SecondDatacenter`
Eine DAG, die sich über zwei Active Directory-Standorte erstreckt, sowie ausschließlich verzögerte Datenbankkopien am zweiten Standort	`SecondCopy` Der Grund dafür ist, dass die Datengarantie-API einen Commit der Daten erst garantiert, wenn die Protokolldatei in die Datenbankkopie wiedergegeben wird. Außerdem tritt aufgrund der Verzögerung mit dieser Einschränkung bei der Verschiebungsanforderung ein Fehler auf, sofern der Wert der verzögerten Datenbankkopie "ReplayLagTime" nicht auf weniger als 30 Minuten festgelegt wird.
Eine DAG, die sich über mindestens drei Active Directory-Standorte erstreckt, sowie Datenbankkopien mit hoher Verfügbarkeit an jedem Standort	`AllDatacenters`

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

Server	Anzahl von Aktive Datenbanken	Anzahl von Passive Datenbanken	Anzahl von eingebundene Datenbanken	Anzahl von Datenbanken mit diesen Einstellungen
EX1	5	11	5	4, 4, 3, 5
EX2	1	15	1	1, 8, 6, 1
EX3	12	4	12	13, 2, 1, 0
EX4	1	15	1	1, 1, 5, 9

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 meisten bevorzugte Kopie zu verschieben, während gleichzeitig versucht wird, aktive Datenbanken an jedem Active Directory-Standort auszugleichen.

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

Server	Anzahl von Aktive Datenbanken	Anzahl von Passive Datenbanken	Anzahl von eingebundene Datenbanken	Anzahl von Datenbanken mit diesen Einstellungen
EX1	4	12	4	4, 4, 4, 4
EX2	4	12	4	4, 4, 4, 4
EX3	4	12	4	4, 4, 4, 4
EX4	4	12	4	4, 4, 4, 4

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.

Skriptparameter "RedistributeActiveDatabases.ps1"

Parameter	Beschreibung
DagName	Gibt den Namen der DAG an, die Sie wieder ausgleichen möchten. Wird dieser Parameter ausgelassen, wird die DAG verwendet, der der lokale Server angehört.
BalanceDbsByActivationPreference	Gibt an, dass das Skript Datenbanken auf die bevorzugte Kopie verschieben soll, ohne dabei den Active Directory-Standort zu berücksichtigen.
BalanceDbsBySiteAndActivationPreference	Gibt an, dass das Skript die aktiven Datenbanken auf die bevorzugte Kopie verschieben und gleichzeitig einen Ausgleich der aktiven Datenbanken innerhalb jedes Active Directory-Standorts erreichen soll.
ShowFinalDatabaseDistribution	Gibt an, dass ein Bericht zu aktuellen Datenbankverteilung nach abgeschlossener Neuverteilung angezeigt werden soll.
AllowedDeviationFromMeanPercentage	Gibt die zulässige Variation aktiver Datenbanken zwischen Standorten an, ausgedrückt als Prozentsatz. Der Standardwert ist 20 %. Wenn beispielsweise 99 Datenbanken auf drei Standorte verteilt wären, wäre die ideale Verteilung 33 Datenbanken an jedem Standort. Wenn die zulässige Abweichung 20 % beträgt, versucht das Skript, die Datenbanken so auszugleichen, dass jede Website nicht mehr als 10 % mehr oder weniger als diese Zahl aufweist. 10% von 33 ist 3,3, was auf 4 aufgerundet wird. Daher versucht das Skript, zwischen 29 und 37 Datenbanken an jedem Standort zu haben.
ShowDatabaseCurrentActives	Gibt an, dass das Skript einen Bericht für jede Datenbank erstellt, in dem beschrieben wird, wie die Datenbank verschoben wurde und ob sie jetzt auf der bevorzugten Kopie aktiv ist.
ShowDatabaseDistributionByServer	Gibt an, dass das Skript einen Bericht zu jedem Server mit der zugehörigen Datenbankverteilung erstellt.
RunOnlyOnPAM	Gibt an, dass das Skript nur auf dem DAG-Mitglied mit der Rolle "Primary Active Manager" (PAM) ausgeführt wird. Das Skript überprüft, ob es von einem PAM ausgeführt wird. Wenn es nicht von einem PAM ausgeführt wird, wird das Skript beendet.
LogEvents	Gibt an, dass das Skript ein Ereignis (MsExchangeRepl-Ereignis "4115") protokolliert, das eine Zusammenfassung der Aktionen enthält.
IncludeNonReplicatedDatabases	Gibt an, dass das Skript bei der Bestimmung der Neuverteilung aktiver Datenbanken nicht replizierte Datenbanken (Datenbanken ohne Kopien) umfassen soll. Obwohl nicht replizierte Datenbanken nicht verschoben werden können, beeinflussen sie möglicherweise die Verteilung replizierter Datenbanken.
Confirm	Die Option "Confirm" kann zum Unterdrücken der Bestätigungsaufforderung verwendet werden, die standardmäßig angezeigt wird, wenn dieses Skript ausgeführt wird. Verwenden Sie zum Unterdrücken dieser Bestätigungsaufforderung die folgende Syntax: -Confirm:$False. Sie müssen einen Doppelpunkt ( : ) in die Syntax einfügen.

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

Eine Datenbankkopie stellt Ihre erste Verteidigungsmaßnahme dar, wenn ein Fehler auftritt, der sich auf die aktive Kopie einer Datenbank auswirkt. Daher ist es wichtig, die Integrität und den Status von Datenbankkopien zu überwachen, um sicherzustellen, dass sie bei Bedarf verfügbar sind. Sie können eine Vielzahl von Informationen anzeigen, einschließlich der Länge der Kopierwarteschlange, der Wiedergabewarteschlangenlänge, des Status und des Status des Inhaltsindexes, indem Sie die Details einer Datenbankkopie im EAC untersuchen. 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 Datenbankverfügbarkeitsgruppen.

Entfernen einer Datenbankkopie

Eine Datenbankkopie kann jederzeit mithilfe des EAC 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 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. Sie können einen Wechsel durchführen, indem Sie den Link Aktivieren im EAC oder das Cmdlet Move-ActiveMailboxDatabase in der Shell verwenden.

Es gibt mehrere interne Überprüfungen, die vor dem Aktivieren einer passiven Kopie ausgeführt werden:

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. Mit diesem Parameter können Sie die aktive Kopie in eine Datenbankkopie in einem fehlerhaften Zustand 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. Bei Verwendung dieses Parameters wird der Seedingvorgang abgebrochen und als nicht erfolgreich eingestuft.
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 überschreiben 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 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 Datenbankwechsel durchführen, haben Sie auch die Möglichkeit, die Einstellungen für die Einbindungswählfunktion zu überschreiben, die für den Server konfiguriert sind, auf dem die passive Datenbankkopie gehostet wird, die aktiviert wird. 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.

Freigeben über