Verwalten der fortlaufenden lokalen Replikation

Gilt für: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Letztes Änderungsdatum des Themas: 2007-08-20

Zusätzlich zur Verwaltung und Administration der täglichen Aufgaben einer Exchange-Organisation gibt es spezifische Aufgaben für die fortlaufende lokale Replikation (Local Continuous Replication, LCR). Im Allgemeinen fallen die folgenden Verwaltungsaufgaben für LCR an:

• Konfigurieren des Datenträgerspeichers für LCR und Verwalten der Datenträgervolumes.

• Aktivieren und Deaktivieren von LCR.

• Überwachen der Replikationsaktivität.

• Bereitstellen, Aufheben der Bereitstellung, Erstellen und Entfernen von Datenbanken.

• Verschieben des Speicherorts für die Speicherung von Speichergruppen oder Datenbankdateien, wenn eine Speichergruppe LCR-aktiviert ist.

• Anzeigen der Status und Konfigurationsinformationen für eine LCR-aktivierte Speichergruppe oder Datenbank.

• Überprüfen des Status einer aktiven oder passiven Kopie von LCR-Daten.

• Verwalten der Replikations- und Wiedergabeaktivitäten.

• Aktivieren der passiven Kopie.

Konfigurieren der Datenträgerspeicher für die lokale fortlaufende Replikation

Für LCR sind keine besonders konfigurierten Datenträgerspeicher erforderlich. Es wird empfohlen, die Kopien soweit voneinander zu isolieren, wie es praktikabel ist. Für LCR ist Speicher erforderlich, der angemessene Leistungen und Kapazitäten bereitstellt. Für beide Kopien der für LCR aktivierten Speichergruppen und Datenbanken sollten gleichwertige Speicherlösungen konfiguriert werden. Es wird außerdem empfohlen, die Konfigurationsverfahren zu befolgen, die der Speicherlieferant bereitstellt, um die Konfiguration abzuschließen.

Verwalten von Datenträgervolumes

Bei der Verwaltung einer LCR-Umgebung ist es möglicherweise erforderlich, Datenträgervolumes zu verwalten, die mit Ihrem Servercomputer mit Exchange verbunden sind. Das Datenträgervolume muss z. B. zu Wartungszwecken oder aus anderen Gründen vorübergehend vom System getrennt werden. Wenn Wartungsarbeiten an dem Datenträgervolume ausgeführt werden müssen, das die aktive Kopie der Speichergruppe enthält, sollte die Bereitstellung der Datenbank in der aktiven Kopie der Speichergruppe aufgehoben werden. Wenn Wartungsarbeiten an den Datenträgervolumes ausgeführt werden müssen, die die passive Kopie der Speichergruppe enthalten, sollte jegliche E/A für den Datenträger beendet werden, indem die Replikation angehalten wird. Weitere Informationen zum Verwalten von Datenträgervolumes finden Sie unter Vorbereiten von Datenträgerverwaltungsaktivitäten für eine LCR-Kopie.

Aktivieren der fortlaufenden lokalen Replikation

Die Verwendung von LCR beginnt mit der Aktivierung einer Speichergruppe für LCR. Führen Sie diese Aufgabe mithilfe der Exchange-Verwaltungskonsole oder der Exchange-Verwaltungsshell aus.

Um LCR verwenden zu können, müssen Sie die Speichergruppe für LCR aktivieren. Ausführliche Anweisungen zum Aktivieren einer vorhandenen Speichergruppe für fortlaufende lokale Replikation finden Sie unter Aktivieren der fortlaufenden lokalen Replikation für vorhandene Speichergruppen. Ausführliche Anweisungen zum Erstellen einer neuen LCR-aktivierten Speichergruppe finden Sie unter Aktivieren der fortlaufenden lokalen Replikation für eine neue Speichergruppe.

Deaktivieren der fortlaufenden lokalen Replikation

Sie können LCR für eine Speichergruppe mithilfe der Exchange-Verwaltungskonsole oder der Exchange-Verwaltungsshell deaktivieren. Ausführliche Anweisungen zum Deaktivieren von LCR finden Sie unter Deaktivieren der fortlaufenden lokalen Replikation.

Optimieren der Standardkonfiguration des Transportpapierkorbs

Bei dem Transportpapierkorb handelt es sich um ein Feature der Serverfunktion Hub-Transport, das kürzlich zugestellte E-Mail-Nachrichten nach einem ungeplanten Ausfall übermittelt. Der Hub-Transport-Server pflegt eine Warteschlange mit E-Mail-Nachrichten, die einem Postfach zuletzt zugestellt wurden:

• Auf einem Postfachclusterserver in einer CCR-Umgebung

• In einer LCR-aktivierten Speichergruppe

Der Transportpapierkorb sollte bei Verwendung der fortlaufenden Clusterreplikation (CCR) oder der fortlaufenden lokalen Replikation (LCR) aktiviert sein. Der Transportpapierkorb wird unternehmensweit aktiviert, indem die Menge des pro Speichergruppe verfügbaren Speichers sowie die Aufbewahrungszeit im Transportpapierkorb festgelegt wird.

Mithilfe des Cmdlets Set-TransportConfig können Sie die Standardkonfigurationseinstellungen für den Transportpapierkorb ändern, die auf Speichergruppenebene angewendet werden.

Es wird empfohlen, den Parameter MaxDumpsterSizePerStorageGroup, der die maximale Größe der Transportpapierkorb-Warteschlange für jede Speichergruppe angibt, auf das 1,5-fache der Größe der Nachricht zu konfigurieren, die maximal gesendet werden kann. Wenn beispielsweise die maximale Größe einer Nachricht 10 MB beträgt, sollten Sie den Parameter MaxDumpsterSizePerStorageGroup auf einen Wert von 15 MB festlegen.

Es wird weiterhin empfohlen, den Parameter MaxDumpsterTime, der angibt, wie lange eine E-Mail-Nachricht in der Transportpapierkorb-Warteschlange verbleiben soll, auf einen Wert von 00:00:00 zu konfigurieren, was 7 Tagen entspricht. Nachrichten werden aus dem Transportpapierkorb entfernt, wenn die im Parameter MaxDumpsterSizePerStorageGroup festgelegte Größe erreicht ist. Ansonsten werden die Nachrichten aus dem Transportpapierkorb entfernt, wenn der im Parameter MaxDumpsterTime festgelegte Zeitraum abgelaufen ist. Dies sollte genügen, um einem umfangreichen Ausfall ohne E-Mail-Verluste entgegenzuwirken.

Bei der Verwendung des Transportpapierkorb-Features wird auf dem Hub-Transport-Server zusätzlicher Speicherplatz benötigt, um die Transportpapierkorb-Warteschlangen aufnehmen zu können. Der benötigte Speicherplatz entspricht ungefähr dem Wert des Parameters MaxDumpsterSizePerStorageGroup multipliziert mit der Anzahl der Speichergruppen auf allen Postfachclusterservern in einer CCR-Umgebung und allen LCR-aktivierten Speichergruppen am Active Directory-Verzeichnisdienststandort, der den Hub-Transport-Server enthält. In einer CCR-Umgebung werden Anforderungen für eine erneute Zustellung aus dem Transportpapierkorb auf allen Hub-Transport-Servern am Standort automatisch durchgeführt. In einer LCR-Umgebung wird die Anforderung für eine erneute Zustellung aus allen Hub-Transport-Servern am Standort als Teil des TasksRestore-StorageGroupCopy durchgeführt.

Ausführliche Anweisungen zum Aktivieren und Konfigurieren des Transportpapierkorbs finden Sie unter Konfigurieren des Transportpapierkorbs. Weitere Informationen zum Cmdlet Restore-StorageGroupCopy finden Sie unter Restore-StorageGroupCopy.

Überwachen der Replikationsaktivität

Die passive Kopie einer Datenbank ist nur von Nutzen, wenn sie aktuell ist. Zwar erfordert LCR keine besondere Überwachung, es wird jedoch empfohlen, alle Speichergruppen regelmäßig zu überprüfen, damit sichergestellt ist, dass sie Protokolldateien ordnungsgemäß replizieren. Das Microsoft Exchange Server 2007 Management Pack für Microsoft Operations Manager 2005 enthält Warnmeldungen für mehrere wichtige Probleme, die in LCR-Umgebungen auftreten können:

• Der Microsoft Exchange-Replikationsdienst wird nicht ausgeführt. Beachten Sie, dass das Ereignis, das diese Warnung generiert, nach dem Beenden des Diensts nicht wiederholt angezeigt wird. Daher gehen alle mit ihm verbundenen Warnungen verloren, wenn es gelöscht wird.

• Die passive Kopie weist den Status "Fehler" auf.

• Die passive Kopie befindet sich in einem ordnungsgemäßen Zustand, ist jedoch beim Kopier- oder Wiedergabevorgang des Protokolls in erheblichem Rückstand.

Alle oben genannten Warnmeldungen, die durch das Exchange 2007 Management Pack generiert werden, sollten so schnell wie möglich überprüft und Fehler gegebenenfalls behoben werden.

Eine Alternative zum Verwenden des Exchange 2007 Management Packs für Microsoft Operations Manager 2005 besteht im regelmäßigen Ausführen eines Skripts, das das Cmdlet Get-StorageGroupCopyStatus in der Exchange-Verwaltungsshell ausführt. Das Cmdlet Get-StorageGroupCopyStatus gibt Warteschlangenlängen zurück, die die Anzahl der von der aktiven Kopie generierten Protokolle berücksichtigen. Aus Leistungsgründen enthalten die Leistungsindikatoren für die Warteschlangenlänge nur Informationen, die dem Microsoft Exchange-Replikationsdienst bekannt sind. In seltenen Fällen stimmen diese Angaben nicht mit dem Status der aktiven Kopie überein. Weitere Informationen zum Cmdlet Get-StorageGroupCopyStatus finden Sie unter "Anzeigen von Statusinformationen" weiter unten in diesem Thema.

Bereitstellen, Aufheben der Bereitstellung, Erstellen und Entfernen von Datenbanken

Gelegentlich müssen Datenbanken in einer LCR-Umgebung bereitgestellt werden, oder die Bereitstellung muss aufgehoben werden. Wenn für die Speichergruppe oder Datenbank Neukonfiguration oder Wartung erforderlich ist, müssen Sie die Dienste für den Zeitraum dieser Aktivitäten blockieren, die mit beiden interagieren. Dies ist möglicherweise erforderlich, um eine Neukonfiguration vorzunehmen oder um Probleme mit dem Server oder der Datenbank zu beheben. Beim Aufheben der Bereitstellung einer Datenbank wird diese fixiert, und es können keine weiteren Änderungen vorgenommen werden. Weder die Datenbank noch die Protokolldateien werden während dieser Zeit geändert.

Sie möchten der Speichergruppe, die für LCR aktiviert ist, eine Datenbank hinzufügen. Dieser Vorgang ähnelt dem Vorgang des Hinzufügens einer Datenbank in einer eigenständigen Konfiguration mit der Ausnahme, dass der zusätzliche Pfad zur Verfügung gestellt werden muss.

Sie möchten eine Datenbank aus einer Speichergruppe entfernen, die für LCR aktiviert ist. Der Vorgang entspricht dem zum Entfernen einer Datenbank in einer eigenständigen Konfiguration verwendeten Vorgang mit der Ausnahme, dass zwei Kopien der Daten entfernt werden müssen: die aktiver Kopie der Datenbank und die passive Kopie der Datenbank. Ausführliche Anweisungen zum Entfernen einer Datenbank aus einer Speichergruppe, die für LCR aktiviert ist, finden Sie unter Entfernen einer Datenbank aus einer LCR-aktivierten Speichergruppe.

Verschieben des Speicherorts von Speichergruppen- und Datenbankdateien

Sie können entweder mithilfe der Exchange-Verwaltungsshell oder der Exchange-Verwaltungskonsole den Speicherort einer Datenbank in einer LCR-aktivierten Speichergruppe ändern. In einer LCR-Konfiguration gibt es zwei Datenbankdateien, eine pro Kopie. Die Speicherorte für beide Kopien können unabhängig voneinander oder gleichzeitig geändert werden.

Für die Neukonfiguration des Speicherorts der Protokoll- und Systemdateien einer Speichergruppe und des Speicherorts der Datenbankdateien in einer LCR-Umgebung werden ähnliche Verfahren angewandt. Ausführliche Anweisungen zum Ändern des Speicherorts von Protokoll- und Systemdateien für eine LCR-aktivierte Speichergruppe finden Sie unter Verschieben einer Speichergruppe in eine Umgebung mit fortlaufender lokaler Replikation. Ausführliche Anweisungen zum Ändern des Speicherorts von Datenbankdateien in einer LCR-Umgebung finden Sie unter Verschieben einer Datenbank in einer Umgebung mit fortlaufender lokaler Replikation.

Anzeigen von Statusinformationen

Nachdem die LCR für eine Speichergruppe aktiviert wurde, können mithilfe der Exchange-Verwaltungskonsole oder der Exchange-Verwaltungsshell der LCR-spezifische Konfigurationseinstellungen für die Speichergruppe und ihre Datenbank angezeigt werden.

Statusinformationen für LCR

Exchange 2007 gibt eine Reihe von Statusinformationen für LCR-Kopien aus. In der folgenden Tabelle werden die Statusinformationen beschrieben, die für LCR-aktivierte Speichergruppen verfügbar sind. Ausführliche Anleitungen zum Abrufen von Statusinformationen finden Sie unter Anzeigen des Status einer fortlaufenden lokalen Replikationskopie. In der folgenden Tabelle werden die Eigenschaften in der Reihenfolge aufgeführt, in der sie auftreten, wenn die vollständige Ausgabe des Cmdlets Get-StorageGroupCopyStatus der Exchange-Verwaltungsshell angezeigt wird.

Für LCR-aktivierte Speichergruppen verfügbare Statusinformationen

Der Zustand einer LCR-Kopie lässt sich schnell durch Prüfen der Werte von SummaryCopyStatus, CopyQueueLength, ReplayQueueLength und LastInspectedLogTime einschätzen. Diese Eigenschaften zeigen an, ob die LCR-Kopie ordnungsgemäß funktioniert, und ob die LCR-Kopie sowohl in den Kopier- als auch in den Wiedergabeprotokollen relativ aktuell ist. Wenn der folgende Zustand eintritt, müssen Sie die Ursache dafür ermitteln und das Problem korrigieren:

• Die Kopie befindet sich während eines erheblichen Zeitraums in einem nicht fehlerfreien Zustand.

• Die Länge der Kopiewarteschlange ist größer als 5.

• Die Länge der Wiedergabewarteschlange ist größer als 20.

• Die Protokollzeit der letzten Überprüfung zeigt keine aktuelle Uhrzeit an. Dies kann durch zwei wahrscheinliche Ursachen bewirkt werden: In der Speichergruppe werden nicht viele Änderungen durchgeführt, oder der Microsoft Exchange-Replikationsdienst wurde beendet.

Die Werte für die Länge der Wiedergabe- und Kopiewarteschlange sind als Leistungsindikatoren verfügbar. Es handelt sich dabei um die Leistungsindikatoren CopyQueueLength und ReplayQueueLength unter dem Leistungsobjekt MSExchange-Replikation. Weitere Informationen zum Überwachen von Leistungsindikatoren für LCR finden Sie unter Anzeigen von Leistungsindikatoren für die fortlaufende lokale Replikation.

Es gibt einige sehr seltene Szenarien, in denen der Replikationsstatus irreführend sein kann. Im Folgenden finden Sie eine Liste dieser Szenarien:

• Eine Speichergruppe, die nicht aktiv ist (d. h. sich nicht ändert), kann als "Fehlerfrei" gemeldet werden, obwohl sie unter Umständen nicht fehlerfrei ist. Diese Situation könnte eintreten, weil der fehlerhafte Zustand erst erkannt werden kann, wenn ein Protokoll wiedergegeben wird.

• Während der Initialisierung der Replikation wird der Replikationsstatus bewertet und ist möglicherweise nicht mehr genau. Nach Abschluss der Initialisierung wird der Status aktualisiert.

• Der Wert des Felds LastLogGenerated kann falsch sein, wenn die Bereitstellung einer Datenbank aufgehoben wird. Es werden aber alle Protokolle mit Endbenutzerinhalten repliziert, wenn die Speichergruppenkopie repliziert wird.

• Wenn in der Mitte eines Protokollstreams mindestens ein Protokoll fehlt, setzt die passive Kopie ihre Wiederherstellungsversuche fort. Hierdurch wechselt der Replikationsstatus zwischen den Zuständen Fehler und Fehlerfrei. Die Wiedergabe- und Kopiewarteschlangen wachsen weiterhin an.

• Unter manchen äußerst seltenen Umständen kann ein Protokoll erfolgreich überprüft werden, aber dennoch nicht fehlerfrei wiedergegeben werden. In dieser Situation wechselt das System während der Wiederherstellungsversuche ständig zwischen den Zuständen Fehler und Fehlerfrei. Die Wiedergabe- und Kopiewarteschlangen wachsen weiterhin an.

Anzeigen von Konfigurationsinformationen

Konfigurationsinformationen von LCR-aktivierten Speichergruppen und Datenbanken können mithilfe der Exchange-Verwaltungskonsole und der Exchange-Verwaltungsshell angezeigt werden. Zu den Konfigurationsinformationen gehören:

• Speichergruppen   Der Speicherort der LCR-Transaktionsprotokolldateien und LCR-Systemdateien.

• Datenbanken   Der Speicherort der LCR-Datenbankkopie.

Außerdem können Sie bestimmen, ob eine Speichergruppe oder Datenbank dafür konfiguriert ist, eine LCR-Kopie zu besitzen. Ausführliche Anleitungen zum Anzeigen der LCR-Konfigurationseinstellungen finden Sie unter Anzeigen von Konfigurationseinstellungen für die fortlaufende lokale Replikation.

Überprüfen der Integrität der passiven Kopie

Wenn Sie LCR verwenden, wird empfohlen, die Integrität der passiven Kopie regelmäßig zu überprüfen, indem eine physikalische Konsistenzprüfung der Datenbank und der Transaktionsprotokolldateien ausgeführt wird. Bei einer physikalischen Konsistenzprüfung werden die Transaktionsprotokolle und die Datenbankdateien auf Beschädigungen überprüft. Sie können die Überprüfung mithilfe der Exchange Server-Dienstprogramme (Eseutil.exe) ausführen. Ausführliche Anweisungen zum Verwenden von Eseutil.exe zum Überprüfen der Transaktionsprotokolle und Datenbankdateien auf physikalische Fehler finden Sie unter Überprüfen einer fortlaufenden lokalen Replikationskopie mithilfe von ESEUTIL.

Verwalten von Replikation und Wiedergabe

Für das Verwalten der Protokolldateireplikation und -wiedergabe in einer LCR-Umgebung sind die folgenden Hauptaktivitäten erforderlich:

• Anhalten der Replikation für die Speichergruppenkopie

• Neustarten der Replikation für die Speichergruppenkopie

Anhalten und Neustarten der Änderungen für die Speichergruppenkopie und ihre Datenbank

Es kann erforderlich sein, die Replikationsaktivitäten des Transaktionsprotokolls anzuhalten und dann neu zu starten. Die Transaktionsprotokollreplikation (einschließlich Wiedergabe) wird auf Speichergruppenebene gesteuert. Da eine Speichergruppe nur eine Datenbank enthalten kann, ist die Replikation auf eine Datenbank begrenzt. Die Transaktionsprotokollreplikation tritt auf, wenn der Microsoft Exchange-Replikationsdienst ausgeführt wird, eine Speichergruppe für LCR aktiviert wurde und sowohl die aktive Kopie als auch die passive Kopie betriebsbereit sind. Wenn die aktive oder die passive Kopie nicht mehr verfügbar ist, müssen Sie die Replikation beenden. Außerdem erfordern einige Verwaltungsaufgaben, z. B. das Seeding, dass die Replikation für eine für LCR aktivierte Speichergruppe angehalten wird. Wenn Sie den gesamten Zugriff auf die Datendateien der passiven Kopie beenden müssen, müssen Sie die Replikation anhalten.

Gelegentlich kann es erforderlich sein, die Aktivitäten der passiven Kopie zu steuern. Dies ist möglicherweise erforderlich, um eine Neukonfiguration vorzunehmen oder um Probleme mit dem Server oder der Datenbank zu beheben. Das Anhalten der Protokollwiedergabe ist ebenfalls erforderlich, um eine physikalische Konsistenzprüfung der passiven Kopie auszuführen. Wenn es erforderlich ist, die Aktualisierungen der Datenbankkopie zu steuern, muss die Replikation für die Speichergruppenkopie angehalten werden. Die Replikation muss ggf. außerdem angehalten werden, die Protokolle der passiven Kopie bearbeitet werden. Weil eine Speichergruppe nur eine einzige Datenbank enthalten kann, werden Aktionen, die sich auf das Wiedergabeverhalten auswirken, auf Speichergruppenebene gesteuert.

Es empfiehlt sich, alle Replikationsaktivitäten anzuhalten, wenn der Standort der Speichergruppe oder Datenbank geändert wird.

Weitere Informationen Anhalten von Replikationsänderungen an LCR-Kopien finden Sie unter Anhalten der Replikation einer LCR-aktivierten Speichergruppe. Weitere Informationen zum Neustarten von Replikationsänderungen an LCR-Kopien finden Sie unter Erneutes Starten der Replikation einer LCR-aktivierten Speichergruppe. Weitere Informationen zum Ausführen einer Integritätsüberprüfung für die Transaktionsprotokolle und Datenbankdateien der passiven Kopie finden Sie unter Überprüfen einer fortlaufenden lokalen Replikationskopie mithilfe von ESEUTIL.

Aktivieren der passiven Kopie

LCR ermöglicht die Wiederherstellung nach Beschädigung der aktiven Kopie einer Speichergruppe, indem die passive Kopie der Speichergruppe aktiviert wird. Wenn die Transaktionsprotokolle der aktiven Kopie der Speichergruppe nicht fehlerhaft sind, sollte aufgrund kein Datenverlust auftreten. Wenn die Transaktionsprotokolle aus der aktiven Kopie der Speichergruppe nicht verfügbar sind, kann die Wiederherstellung der Speichergruppe nur bis zu dem Zeitpunkt erfolgen, der mit den letzten nicht fehlerhaften Änderungen übereinstimmt, die die passive Kopie empfangen hat. Eine weitere Einschränkung besteht darin, dass keine fehlerhaften Produktions-Transaktionsprotokolldateien vorhanden sein bzw. keine Dateien vor diesem Zeitpunkt fehlen dürfen.

Die Wiederherstellung nach einem Produktionsspeichergruppen-Fehler ist am einfachsten, wenn Volumebereitstellungspunkte des NTFS-Dateisystems zum Speichern der Kopie der fortlaufenden lokalen Replikation verwendet werden. Indem Sie Volumebereitstellungspunkte verwenden, können Sie eine Zielpartition in einem Ordner auf einem anderen physikalischen Datenträger bereitstellen. Volumebereitstellungspunkte sind für Programme transparent, z. B. auch für Exchange 2007.

Fehler in einer Transaktionsprotokoll- oder Datenbankdatei, die Teil einer LCR-Kopie ist, können entweder durch Fehler bei einem Wiedergabevorgang oder durch eine Konsistenzüberprüfung entdeckt werden. Die ggf. auszuführenden Korrekturmaßnahmen hängen von der Art der Fehler ab:

• Wenn der Fehler in einer Protokolldatei auftritt, die bereits wiedergegeben wurde, kann die fehlerhafte Protokolldatei einfach ignoriert werden. Wenn Sie jedoch dateisystembasierte Sicherungen der LCR-Kopie verwenden, sollten Sie zuerst alle Protokolldateien löschen, die wiedergegeben wurden.

• Wenn sich die Fehler in der Protokolldatei einer aktiven Kopie befinden, die noch nicht wiedergegeben wurde, muss ein erneutes Seeding der LCR-Speichergruppe ausgeführt werden. Exchange versucht, eine Protokolldatei erneut zu kopieren, wenn Fehler erkannt werden. Wenn die Fehler durch den automatischen Kopiervorgang nicht behoben werden, muss ein erneutes Seeding der Speichergruppe ausgeführt werden. Ferner wird empfohlen, die Integrität der Quelltransaktionsprotokolle und der Datenbankdatei zu prüfen. Für das Überprüfen von Exchange-Datendateien müssen die Dateien offline sein und dürfen nicht für den Benutzerzugriff verfügbar sein.

• Wenn die Datenbank fehlerhaft ist, muss ein erneutes Seeding der Speichergruppe erfolgen.

Ausführliche Anweisungen zum Aktivieren des passiven Knotens einer Datenbank finden Sie unter Wechseln zur passiven Kopie einer Datenbank.

Einschätzen des Replikationsstatus zum Zeitpunkt des Fehlers

Nach einem Fehler oder einer Beschädigung einer Datenbankkopie müssen Sie einschätzen, ob der Betrieb sofort mithilfe der passiven Kopie fortgesetzt werden soll. LCR stellt wichtige Informationen zur Verfügung, die Sie bei dieser Entscheidung unterstützen:

• Status der Kopie zum Zeitpunkt des Fehlers

• Wiedergabe- und Kopiewarteschlangen zum Zeitpunkt des Fehlers

• Die Protokollzeit der letzten Überprüfung zum Zeitpunkt des Fehlers

Die entsprechenden Informationen können mithilfe des Cmdlets Get-StorageGroupCopyStatus abgerufen werden. Genaue Anweisungen zum Abrufen dieser Informationen finden Sie unter Anzeigen des Status einer fortlaufenden lokalen Replikationskopie.

Die Länge der Kopiewarteschlange enthält die besten verfügbaren Informationen zur aktiven Kopie zum Zeitpunkt des Fehlers. Basierend auf diesen Informationen und Ihrer Einschätzung der Wiederherstellungszeit für die fehlerhafte Datenbank müssen Sie entscheiden, ob die verfügbare Kopie bereitgestellt werden soll:

• Wenn die Länge der Wiedergabewarteschlange erheblich ist, bedeutet dies, dass die Wiederherstellung zeitaufwendig sein kann. Dies ist jedoch kein Hinweis darauf, dass erhebliche Datenverluste zu befürchten sind.

• Wenn die Länge der Kopiewarteschlange erheblich ist, bedeutet dies, dass eine große Anzahl von Protokollen verloren gegangen ist. Wenn die Datenbank bereitgestellt wird, wird sie im Zeitrahmen ungefähr des letzten kopierten Protokolls wiederhergestellt (diese Angabe kann auch mithilfe des Cmdlets Get-StorageGroupCopyStatus abgerufen werden).

• Wenn die Protokollzeit der letzten Überprüfung weit vor dem Zeitpunkt des Fehlers liegt, wurde der Microsoft Exchange-Replikationsdienst wahrscheinlich beendet, und die Warteschlangeninformationen sind ungenau.