Rollenwechsel während einer Datenbankspiegelungssitzung (SQL Server)

Im Kontext einer Datenbankspiegelungssitzung können Prinzipal- und Spiegelrollen in einem Prozess, der als Rollenwechsel bezeichnet wird, in der Regel austauschbar sein. Beim Rollenwechsel fungiert der Spiegelserver als Failoverpartner für den Prinzipalserver, übernimmt die Hauptrolle, stellt seine Kopie der Datenbank wieder her und stellt sie als neue Prinzipaldatenbank online bereit. Der frühere Prinzipalserver nimmt, wenn verfügbar, die Spiegelrolle an, und seine Datenbank wird zur neuen Spiegeldatenbank. Möglicherweise können die Rollen entweder als Reaktion auf mehrere Fehler oder für administrative Zwecke hin- und herwechseln.

Hinweis

In diesem Thema wird davon ausgegangen, dass Sie mit den Betriebsmodi für die Datenbankspiegelung vertraut sind. Weitere Informationen finden Sie unter Betriebsmodi für die Datenbankspiegelung.

Die folgende Abbildung zeigt die Spiegelungspartner Partner_A und Partner_B, die über eine Reihe von automatischen oder manuellen Failovers ihre Haupt- und Spiegelrollen austauschen.

Von Bedeutung

Nach einem Rollenwechsel müssen Aufträge, die in der ehemaligen Prinzipaldatenbank ausgeführt wurden, auf dem neuen Prinzipalserver neu erstellt werden, um dort ausgeführt zu werden. Weitere Informationen finden Sie unter Verwaltung von Anmeldungen und Aufträgen nach dem Rollenwechsel (SQL Server).

Es gibt drei Arten von Rollenwechsel: automatisches Failover, manuelles Failover und erzwungener Dienst (mit möglichen Datenverlusten). Die Unterstützung für jedes Formular hängt vom Betriebsmodus der Sitzung ab.

Hinweis

Wenn Sie mit diesen Betriebsmodi nicht vertraut sind, lesen Sie die Betriebsmodi für die Datenbankspiegelung.

• Manuelles Failover

  Der Hochsicherheitsmodus unterstützt manuelles Failover. Wenn die Datenbank synchronisiert wird, kann der Datenbankbesitzer ein manuelles Failover initiieren.

  Manuelles Failover wird für administrative Zwecke bereitgestellt. Weitere Informationen finden Sie unter "Manuelles Failover" weiter unten in diesem Thema.

• Automatisches Failover

  In Anwesenheit eines Zeugen unterstützt der Hochsicherheitsmodus das automatische Failover. Automatisches Failover tritt nur bei Ausfall des Hauptservers auf, wenn der Zeugen- und der Spiegelserver weiterhin verbunden sind und die Datenbank bereits synchronisiert wurde. Weitere Informationen finden Sie unter "Automatisches Failover" weiter unten in diesem Thema.

• Erzwungener Dienst (mit möglichen Datenverlusten)

  Das Erzwingen des Dienstes wird im Hochsicherheitsmodus unterstützt, wenn kein Zeuge konfiguriert ist, und im Hochleistungsmodus. Beim Verlust des Prinzipalservers kann der Datenbankbesitzer die Datenbank verfügbar machen, indem er den Dienst zum Spiegelserver erzwingt (mit möglichen Datenverlusten).

  Hinweis

  Es wird empfohlen, die WITNESS-Eigenschaft im Hochleistungsmodus auf OFF festzulegen. Andernfalls muss der Spiegelserver, um die Datenbank online zu bringen, mit dem Zeugen verbunden sein.

  Weitere Informationen finden Sie unter "Erzwungener Dienst" (mit möglichem Datenverlust) weiter unten in diesem Thema.

In der folgenden Tabelle wird zusammengefasst, welche Arten von Failover unter den einzelnen Betriebsmodi unterstützt werden.

	Hochleistung	Hochsicherheitsmodus ohne Zeugen	Hochsicherheitsmodus mit einem Zeugen
Automatisches Failover	Nein	Nein	Ja
Manuelles Failover	Nein	Ja	Ja
Erzwungener Dienst	Ja	Ja	Nein

Nach einem Rollenwechsel müssen bestimmte Metadaten für beide Partner vorhanden sein, um sicherzustellen, dass alle Datenbankbenutzer auf die neue Prinzipaldatenbank zugreifen können. Darüber hinaus müssen Sicherungsaufträge auf dem neuen Prinzipalserver erstellt werden, um sicherzustellen, dass die Datenbank weiterhin in ihrem regulären Zeitplan gesichert wird. Weitere Informationen finden Sie unter Verwaltung von Anmeldungen und Aufträgen nach dem Rollenwechsel (SQL Server).

Während eines Rollenwechsels hängt es davon ab, wie lange das Datenbank-Mirroring außer Betrieb ist, und zwar von der Art des Rollenwechsels und der Ursache. Weitere Informationen finden Sie unter Schätzen der Dienstunterbrechung während des Rollenwechsels (Datenbankspiegelung).

Manuelles Failover

Manuelles Failover trennt die Clients von der Datenbank und kehrt die Rollen der Partner zurück. Nur der Hochsicherheitsmodus unterstützt manuelles Failover.

Aufrechterhalten der Verfügbarkeit während Upgrades

Der Datenbankadministrator kann manuelles Failover für das Upgrade von Hardware oder Software verwenden, ohne die Verfügbarkeit zu beeinträchtigen. Um die Datenbankspiegelung für Softwareupgrades zu verwenden, muss der Spiegelserver und/oder das System bereits die Upgrades erhalten haben.

Hinweis

Die Datenbankspiegelung sollte in der Lage sein, ein rollierendes Upgrade durchzuführen, dies ist jedoch nicht gewährleistet, da zukünftige Änderungen unbekannt sind. Weitere Informationen finden Sie unter Minimieren der Ausfallzeiten für gespiegelte Datenbanken beim Upgrade von Serverinstanzen.

Die folgende Abbildung zeigt eine Instanz der Verwendung eines manuellen Failovers zur Verwaltung der Datenbankverfügbarkeit, während Sie ein Upgrade einer Datenbankserverinstanz durchführen. Wenn das Upgrade abgeschlossen ist, kann ein Administrator optional einen Failover zur ursprünglichen Serverinstanz durchführen. Dies ist nützlich, wenn der Administrator die Spiegelungssitzung beenden und den Spiegelserver an anderer Stelle verwenden möchte. Auf diese Weise kann eine einzelne Serverinstanz wiederholt verwendet werden, wenn eine Reihe von Datenbankserverinstanzen aktualisiert wird.

Für ein manuelles Failover erforderliche Bedingungen

Manuelles Failover erfordert, dass die Transaktionssicherheit auf "VOLLSTÄNDIG" festgelegt ist (d. a. Hochsicherheitsmodus). Wenn die Partner verbunden sind und die Datenbank bereits synchronisiert ist, wird manuelles Failover unterstützt.

Funktionsweise des manuellen Failovers

Manuelles Failover initiiert die folgende Abfolge von Aktionen:

1. Der Prinzipalserver trennt Clients von der Prinzipaldatenbank, sendet das Ende des Protokolls an den Spiegelserver und setzt, in Vorbereitung auf die Spiegelrolle, den Spiegelstatus auf "SYNCHRONIZING".

2. Der Spiegelserver zeichnet die Protokollsequenznummer (LSN) des letzten Protokolldatensatzes auf, der vom Prinzipal als Failover-LSN empfangen wurde.

   Hinweis

   Um diesen LSN anzuzeigen, wählen Sie die mirroring_failover_lsn Spalte aus sys.database_mirroring (Transact-SQL) aus.

3. Wenn ein Protokoll in der Redo-Warteschlange wartet, beendet der Spiegelserver den Roll forward der Spiegeldatenbank. Die erforderliche Zeit hängt von der Geschwindigkeit des Systems, der jüngsten Arbeitsauslastung und der Menge der Protokolleinträge in der Redo-Warteschlange ab. Bei einem synchronen Betriebsmodus kann die Failoverzeit reguliert werden, indem die Größe der Redo-Warteschlange eingeschränkt wird. Dies kann jedoch dazu führen, dass der Prinzipalserver verlangsamt wird, damit der Spiegelserver auf dem Laufenden bleibt.

   Hinweis

   Um die aktuelle Größe der Redo-Warteschlange zu erfahren, verwenden Sie den Leistungsindikator " Redo Queue " im Leistungsobjekt für die Datenbankspiegelung (weitere Informationen finden Sie unter Monitoring Database Mirroring (SQL Server)).

4. Der Spiegelserver wird zum neuen Hauptserver, und der frühere Hauptserver wird zum neuen Spiegelserver.

5. Der neue Hauptserver setzt alle nicht abgeschlossenen Transaktionen zurück und stellt seine Kopie der Datenbank als Hauptdatenbank bereit.

6. Der frühere Prinzipal übernimmt die Spiegelrolle, und die ehemalige Prinzipaldatenbank wird zur Spiegeldatenbank. Der neue Spiegelserver synchronisiert die neue Spiegeldatenbank schnell neu mit der neuen Prinzipaldatenbank.

   Hinweis

   Sobald der neue Spiegelserver die Datenbanken resynchronisiert hat, ist das Failover wieder möglich, jedoch in die entgegengesetzte Richtung.

Nach dem Failover müssen Clients erneut eine Verbindung mit der aktuellen Prinzipaldatenbank herstellen. Weitere Informationen finden Sie unter Verbinden von Clients mit einer Datenbankspiegelungssitzung (SQL Server).

So initiieren Sie manuelles Failover

• Manuelles Fehlschlagen einer Datenbankspiegelungssitzung (SQL Server Management Studio)

• Manuelles Fehlschlagen einer Datenbankspiegelungssitzung (Transact-SQL).

Automatisches Failover

Automatisches Failover wird nur in Datenbankspiegelungssitzungen unterstützt, die mit einem Zeugen im Hochsicherheitsmodus ausgeführt werden (Hochsicherheitsmodus mit automatischem Failover). Im Hochsicherheitsmodus mit automatischem Failover erfolgt nach der Synchronisierung der Datenbank ein automatisches Failover, wenn die Prinzipaldatenbank nicht mehr verfügbar ist. Ein automatisches Failover bewirkt, dass der Mirror-Server die Rolle des Hauptservers übernimmt und seine Kopie der Datenbank als Hauptdatenbank online bringt. Wenn die Datenbank synchronisiert werden muss, wird der Datenverlust während des Failovers verhindert, da jede transaktion, die für die Prinzipaldatenbank zugesichert wird, auch für die Spiegeldatenbank zugesichert wird.

Von Bedeutung

Damit das automatische Failover die Zuverlässigkeit verbessert, müssen sich die Spiegel- und Prinzipaldatenbanken auf verschiedenen Computern befinden.

Für ein automatisches Failover erforderliche Bedingungen

Für das automatische Failover sind die folgenden Bedingungen erforderlich:

• Die Datenbankspiegelungssitzung muss im Hochsicherheitsmodus ausgeführt werden und muss einen Zeugen besitzen. Weitere Informationen finden Sie unter Betriebsmodi für die Datenbankspiegelung.

• Die Spiegeldatenbank muss bereits synchronisiert sein. Dadurch wird sichergestellt, dass das gesamte an den Spiegelserver gesendete Protokoll auf den Datenträger geschrieben wurde.

• Der Prinzipalserver hat die Kommunikation mit der restlichen Datenbankspiegelungskonfiguration verloren, während der Spiegel und der Zeuge das Quorum beibehalten. Wenn jedoch alle Serverinstanzen die Kommunikation verlieren und der Zeuge und der Spiegelserver später wieder kommunizieren, tritt kein automatisches Failover auf.

  Hinweis

  Weitere Informationen finden Sie unter Quorum: Auswirkungen eines Zeugen auf die Datenbankverfügbarkeit (Datenbankspiegelung).

• Der Spiegelserver hat den Verlust des Prinzipalservers erkannt.

  Wie der Spiegelserver einen Fehler des Prinzipalservers erkennt, hängt davon ab, ob es sich um einen harten oder weichen Fehler handelt. Weitere Informationen finden Sie unter Mögliche Fehler während der Datenbankspiegelung.

So funktioniert ein automatisches Failover

Unter den vorstehenden Bedingungen initiiert das automatische Failover die folgende Abfolge von Aktionen:

1. Wenn der Prinzipalserver weiterhin ausgeführt wird, ändert er den Status der Prinzipaldatenbank in DISCONNECTED und trennt alle Clients von der Prinzipaldatenbank.

2. Die Zeugen- und Spiegelserver registrieren, dass der Prinzipalserver nicht verfügbar ist.

3. Wenn ein Protokoll in der Redo-Warteschlange wartet, beendet der Spiegelserver den Roll forward der Spiegeldatenbank.

   Hinweis

   Die Zeit, die benötigt wird, um das Logbuch anzuwenden, hängt von der Geschwindigkeit des Systems, der letzten Arbeitsauslastung und der Menge des Logs in der Redo-Warteschlange ab.

4. Die frühere Spiegeldatenbank geht als neue Hauptdatenbank online, und bei der Wiederherstellung werden alle nicht abgeschlossenen Transaktionen bereinigt, indem sie so schnell wie möglich zurückgesetzt werden. Sperrungen isolieren diese Transaktionen.

5. Wenn der frühere Hauptserver wieder zur Sitzung hinzustößt, erkennt er, dass sein Failover-Partner jetzt die Hauptaufgabe besitzt. Der ehemalige Hauptserver übernimmt die Rolle des Spiegels, wodurch seine Datenbank zur Spiegeldatenbank wird. Der neue Spiegelserver synchronisiert die neue Spiegeldatenbank so schnell wie möglich mit der Prinzipaldatenbank. Sobald der neue Spiegelserver die Datenbanken neu synchronisiert hat, ist failover wieder möglich, aber in umgekehrter Richtung.

Die folgende Abbildung zeigt eine einzelne Instanz des automatischen Failovers.

Zunächst sind alle drei Server verbunden (die Sitzung verfügt über ein vollständiges Quorum). Partner_A ist der Prinzipalserver und Partner_B der Spiegelserver. Partner_A (oder die Hauptdatenbank auf Partner_A) wird nicht verfügbar. Der Zeuge und Partner_B erkennen beide an, dass der Verantwortliche nicht mehr verfügbar ist, das Quorum der Sitzung bleibt bestehen. Partner_B wird zum Prinzipalserver und stellt seine Kopie der Datenbank als neue Prinzipaldatenbank zur Verfügung. Schließlich stellt Partner_A erneut eine Verbindung mit der Sitzung her und erkennt, dass Partner_B jetzt die Hauptposition besitzt. Partner_A übernimmt dann die Spiegelrolle.

Nach dem Failover müssen Clients erneut eine Verbindung mit der aktuellen Prinzipaldatenbank herstellen. Weitere Informationen finden Sie unter Verbinden von Clients mit einer Datenbankspiegelungssitzung (SQL Server).

Hinweis

Transaktionen, die mithilfe des Microsoft Distributed Transaction Coordinator vorbereitet wurden, aber immer noch nicht zugesichert werden, wenn ein Failover auftritt, werden als abgebrochen betrachtet, nachdem die Datenbank fehlgeschlagen ist.

So deaktivieren Sie das automatische Failover (SQL Server Management Studio)

Öffnen Sie die Seite "Database PropertiesMirroring ", und ändern Sie den Betriebsmodus, indem Sie eine der folgenden Optionen auswählen:

• Hohe Sicherheit ohne automatisches Failover (synchron)

  In diesem Modus wird die Datenbank weiterhin synchronisiert, und manuelles Failover bleibt möglich.

• Hohe Leistung (asynchron)

  In diesem Modus liegt die Spiegeldatenbank möglicherweise etwas hinter der Prinzipaldatenbank, und manuelles Failover ist nicht mehr möglich.

So deaktivieren Sie das automatische Failover (mit Transact-SQL)

An jedem Punkt in einer Datenbankspiegelungssitzung kann der Datenbankbesitzer das automatische Failover deaktivieren, indem er den Zeugen ausschaltet.

So deaktivieren Sie den Zeugen

• Entfernen des Zeugen aus einer Datenbankspiegelungssitzung (SQL Server)

  Hinweis

  Wenn Sie den Zeugen deaktivieren und die vollständige Transaktionssicherheit beibehalten, wird die Sitzung ohne automatisches Failover in den Hochsicherheitsmodus versetzt.

Erzwungener Dienst (mit möglicher Datenverlust)

Die Datenbankspiegelung bietet die erzwungene Bereitstellung des Dienstes (mit möglichen Datenverlusten) als Katastrophenwiederherstellungsmethode, mit der Sie einen Mirror-Server als Warmstandby-Server verwenden können. Das Erzwingen einer Dienstaktion ist nur möglich, wenn der Hauptserver in einer Spiegelungssitzung vom Spiegelserver getrennt wurde. Da das Erzwingen des Dienstes mit möglichen Datenverlusten verbunden ist, sollte es vorsichtig und sparsam verwendet werden.

Die Unterstützung für erzwungenen Dienst hängt vom Betriebsmodus und dem Status der Sitzung wie folgt ab:

• In der Regel unterstützt der Hochleistungsmodus das Erzwingen des Dienstes, wenn der Hauptserver getrennt ist. Allerdings, obwohl nicht notwendig, kann ein Zeuge bei einer Hochleistungsmodussitzung vorhanden sein. In diesem Fall erfordert das Erzwingen des Dienstes, dass der Spiegelserver und der Zeugenserver miteinander verbunden sind.

• Der Modus für hohe Sicherheit ohne automatisches Failover unterstützt das Erzwingen des Dienstes, wenn der Hauptserver getrennt wird.

• Der Hochsicherheitsmodus mit automatischem Failover unterstützt das Erzwingen des Dienstes, wenn der Spiegelserver und der Zeuge miteinander verbunden sind und keiner der beiden mit dem Prinzipalserver verbunden ist (vorausgesetzt, der Spiegelserver hat beim letzten Verbindungsaufbau mit dem Prinzipalserver nicht gerade die Spiegelungsdatenbank zurückgesetzt).

Es wird empfohlen, den Dienst nur dann zu erzwingen, wenn Sie den Dienst sofort in die Datenbank wiederherstellen müssen und bereit sind, Datenverluste zu riskieren. Die Auswirkung der erzwungenen Bereitstellung ähnelt der Abschaltung der Spiegelung, mit der Ausnahme, dass die erzwungene Bereitstellung die Resynchronisierung der Datenbanken erleichtert, wenn die Spiegelung fortgesetzt wird, und dabei das Risiko möglicher Datenverluste besteht. Das Erzwingen des Dienstes initiiert einen reibungslosen Übergang der Primärrolle zur Spiegeldatenbank. Der Spiegelserver übernimmt die Rolle des Hauptservers und stellt den Clients sofort seine Kopie der Datenbank zur Verfügung. Die neue Hauptdatenbank wird ohne Spiegelung ausgeführt (d. h. sie läuft ungeschützt).

Von Bedeutung

Wenn der Hauptserver lediglich von der Spiegelungssitzung getrennt wurde und weiterhin aktiv ist, greifen einige Clients möglicherweise immer noch auf die ursprüngliche Hauptdatenbank zu. Bevor Sie den Dienst erzwingen, ist es wichtig, zu verhindern, dass Clients auf den ursprünglichen Prinzipalserver zugreifen. Andernfalls können nach dem erzwungenen Dienst die ursprüngliche primäre Datenbank und die aktuelle primäre Datenbank unabhängig voneinander aktualisiert werden.

Typischer Fall des erzwungenen Dienstes

Die folgende Abbildung zeigt einen typischen Fall von erzwungenem Dienst (mit möglichen Datenverlusten).

In der Abbildung wird der ursprüngliche Hauptserver, Partner_A, für den Spiegelserver Partner_B nicht verfügbar, wodurch die Spiegeldatenbank getrennt wird. Nachdem sichergestellt wurde, dass Partner_A nicht für Clients verfügbar ist, erzwingt der Datenbankadministrator den Dienst mit möglichen Datenverlusten auf Partner_B. Partner_B wird zum Prinzipalserver und läuft mit der Datenbank freigelegt (d. h. nicht gespiegelt). Zu diesem Zeitpunkt können Clients eine erneute Verbindung mit Partner_B herstellen.

Wenn Partner_A verfügbar wird, verbindet er sich erneut mit dem neuen Hauptserver, tritt der Sitzung wieder bei und übernimmt die Rolle des Spiegels. Die Spiegelungssitzung wird sofort angehalten, ohne die neue Spiegeldatenbank synchronisiert zu haben. Durch das Anhalten der Sitzung kann der Datenbankadministrator entscheiden, ob die Sitzung fortgesetzt werden soll oder in extremen Fällen die Spiegelung entfernt und versucht wird, Daten aus der ehemaligen Prinzipaldatenbank zu retten. In diesem Fall wählt der Datenbankadministrator aus, die Spiegelung fortzusetzen. Zu diesem Zeitpunkt übernimmt Partner_A die Rolle des Spiegelservers und setzt die frühere Prinzipaldatenbank zum Zeitpunkt der letzten erfolgreich synchronisierten Transaktion zurück; Wenn zugesicherte Transaktionen nicht auf den Datenträger auf dem Spiegelserver geschrieben wurden, bevor der Dienst erzwungen wurde, gehen sie verloren. Partner_A leitet dann die neue Spiegeldatenbank weiter, indem alle Änderungen angewendet werden, die an der neuen Prinzipaldatenbank vorgenommen wurden, da der frühere Spiegelserver zum neuen Prinzipalserver wurde.

Hinweis

Obwohl für den Hochleistungsmodus kein Zeuge erforderlich ist, ist eine erzwungene Dienstaktivierung nur möglich, wenn der Zeuge derzeit mit dem Spiegelserver verbunden ist.

Risiken des Erzwingens des Diensts

Es ist wichtig zu verstehen, dass das Erzwingen des Diensts zu Datenverlust führen kann. Datenverlust ist möglich, da der Spiegelserver nicht mit dem Prinzipalserver kommunizieren kann und daher nicht garantieren kann, dass die beiden Datenbanken synchronisiert werden. Das erzwungene Starten des Dienstes beginnt einen neuen Wiederherstellungszweig. Da sich die ursprüngliche Prinzipaldatenbank und die Spiegeldatenbank auf unterschiedlichen Wiederherstellungs-Forks befinden, enthält jede Datenbank jetzt Daten, die die andere Datenbank nicht enthält: Die ursprüngliche Prinzipaldatenbank enthält alle Änderungen, die noch nicht aus der Sendewarteschlange an die frühere Spiegeldatenbank (das nicht gesendete Protokoll) gesendet wurden; Die ehemalige Spiegeldatenbank enthält alle Änderungen, die nach dem Erzwungenen Dienst auftreten.

Wenn der Dienst erzwungen wird, da der Prinzipalserver fehlgeschlagen ist, hängt der potenzielle Datenverlust davon ab, ob Transaktionsprotokolle vor dem Fehler nicht an den Spiegelserver gesendet wurden. Im Modus mit hoher Sicherheit ist dies nur möglich, bis die Spiegeldatenbank synchronisiert wird. Unter dem Hochleistungsmodus ist das angesammelte nicht gesendete Protokoll immer möglich.

Die Auswirkungen der Erzwingung des Diensts hängen teilweise davon ab, ob die Sitzung einen Zeugen hat:

• Wenn kein Zeuge vorhanden ist, kann der Dienst erzwungen werden, wenn die Partner getrennt werden, z. B. weil ihre Netzwerkverbindung unterbrochen ist. Wenn der ursprüngliche Primärserver noch läuft, haben beide Partner die Hauptrolle inne. Clients, die eine Verbindung mit dem neuen Prinzipalserver herstellen, greifen auf die aktuelle Version der Datenbank zu, während Clients, die mit dem ursprünglichen Prinzipalserver verbunden sind, auf die ursprüngliche Prinzipaldatenbank zugreifen. Diese Situation erhöht das Potenzial für Datenverluste. Wenn die Partner eine erneute Verbindung herstellen dürfen, übernimmt der ursprüngliche Prinzipalserver die Spiegelrolle und ändert den Status der Datenbank in "Wiederherstellen", bevor die Spiegelung angehalten wird. Wenn die Sitzung fortgesetzt wird, gehen Transaktionen in der ursprünglichen Hauptdatenbank verloren, deren Protokolle sich seit der letzten Trennung in der Sendewarteschlange befanden. Darüber hinaus gehen auch alle Transaktionen verloren, die nach dem erzwungenen Ende des Dienstes erfolgten.

• In Anwesenheit eines Zeugen, wenn der Spiegelserver sowohl vom Prinzipalserver als auch vom Zeugen getrennt ist, während die beiden Letzteren miteinander verbunden bleiben, läuft der Prinzipal ungeschützt. Wenn der Hauptserver dann vom Zeugen getrennt wird, hört der Server auf, die Datenbank zu bedienen. Anschließend wird das Erzwingen des Diensts möglich, wenn der Spiegelserver erneut eine Verbindung mit dem Zeugen herstellt. Wenn der Dienst erzwungen wird, gehen alle Änderungen verloren, die während des laufenden Betriebs des ursprünglichen Hauptservers vorgenommen wurden, wenn der ursprüngliche Hauptserver erneut eine Verbindung herstellt.

Weitere Informationen finden Sie unter Verwalten des potenziellen Datenverlusts weiter unten in diesem Thema.

Umgang mit potenziellem Datenverlust

Nachdem der Dienst erzwungen wurde und der ehemalige Prinzipalserver wieder verfügbar ist, vorausgesetzt, dass seine Datenbank unbeschädigt ist, können Sie versuchen, den potenziellen Datenverlust zu bewältigen. Der verfügbare Ansatz für die Verwaltung potenzieller Datenverluste hängt davon ab, ob der ursprüngliche Prinzipalserver eine erneute Verbindung mit seinem Partner hergestellt und die Spiegelungssitzung erneut verknüpft hat. Wenn der ursprüngliche Prinzipalserver auf die neue Prinzipalinstanz zugreifen kann, erfolgt die erneute Verbindung automatisch und transparent.

Der ursprüngliche Prinzipalserver hat eine erneute Verbindung hergestellt.

In der Regel wird nach einem Fehler beim Neustart des ursprünglichen Prinzipalservers die Verbindung mit dem Partner schnell erneut hergestellt. Beim erneuten Verbinden wird der ursprüngliche Prinzipalserver zum Spiegelserver. Die Datenbank wird zur Spiegeldatenbank und wechselt in den Wiederherstellungszustand, bevor die Sitzung angehalten wird. Die Spiegeldatenbank wird nicht zurückgesetzt, es sei denn, Sie setzen die Spiegelung fort.

Auf die wiederhergestellte Datenbank kann jedoch nicht zugegriffen werden; Daher können Sie sie nicht prüfen, um auszuwerten, welche Daten verloren gehen würden, wenn Sie die Spiegelung fortsetzen würden. Daher hängt die Entscheidung darüber, ob die Spiegelung fortgesetzt oder entfernt werden soll, davon ab, ob Sie überhaupt einen Datenverlust akzeptieren möchten.

• Wenn ein Verlust von Daten inakzeptabel wäre, sollten Sie die Spiegelung entfernen, um sie zu retten.

  Durch das Entfernen der Spiegelung kann der Datenbankadministrator die ursprüngliche Prinzipaldatenbank wiederherstellen und versuchen, die verloren gegangenen Daten wiederherzustellen. Wenn die ehemalige Spiegeldatenbank jedoch online ist, werden die ehemaligen Partner divergierende Datenbanken mit demselben Namen bedienen. Der Datenbankadministrator muss eine der Datenbanken für Clients unzugänglich machen, um weitere Abweichungen der Datenbank zu vermeiden und Clientfailoverprobleme zu verhindern.

• Wenn ein Datenverlust akzeptabel wäre, könnten Sie die Spiegelung fortsetzen.

  Das Fortsetzen der Spiegelung führt dazu, dass die neue Spiegeldatenbank zurückgesetzt wird, als erster Schritt bei der Synchronisierung der Datenbank. Waren zum Zeitpunkt des Fehlers Protokolldatensätze in der Sendewarteschlange enthalten, gehen die entsprechenden Transaktionen verloren, selbst wenn ein Commit für sie ausgeführt wurde.

Der ursprüngliche Prinzipalserver wurde nicht erneut verbunden.

Wenn Sie vorübergehend verhindern können, dass der ursprüngliche Prinzipalserver über das Netzwerk erneut mit dem neuen Prinzipalserver verbunden wird, können Sie die ursprüngliche Prinzipaldatenbank überprüfen, um zu bewerten, welche Daten verloren gehen würden, wenn die Spiegelung fortgesetzt wurde.

• Der potenzielle Datenverlust ist akzeptabel

  Zulassen, dass der ursprüngliche Prinzipalserver eine erneute Verbindung mit seinem Partner herstellt. Eine erneute Verbindung führt dazu, dass die Bildschirmspiegelung angehalten wird. Um mit der Spiegelung fortzufahren, setzen Sie die Sitzung einfach fort. Der ehemalige Prinzipalserver übernimmt die Spiegelrolle. Der neue Spiegelserver entfernt die ursprüngliche Wiederherstellungs-Verzweigung, wodurch alle Transaktionen verloren gehen, die nie an den oder vom ehemaligen Spiegelserver gesendet oder empfangen wurden.

• Ist der Datenverlust nicht akzeptabel, gehen Sie folgendermaßen vor:

  Wenn die ursprüngliche Prinzipaldatenbank wichtige Daten enthält, die verloren gehen würden, wenn Sie die Sitzung fortgesetzt haben, können Sie die Daten auf dem ursprünglichen Prinzipalserver beibehalten, indem Sie die Spiegelung entfernen. Es wird empfohlen, jetzt zu versuchen, das Ende der Protokolldaten des Hauptservers zu sichern. Anschließend können Sie die aktuelle Hauptdatenbank (die ehemalige Spiegeldatenbank) aktualisieren, indem Sie die Daten, die Sie aus der ursprünglichen Hauptdatenbank sichern möchten, exportieren und in die aktuelle Hauptdatenbank importieren. Es wird empfohlen, so schnell wie möglich eine vollständige Datenbanksicherung der aktualisierten Datenbank zu erstellen.

  Um die Spiegelung mit der aktualisierten Datenbank als erste Prinzipaldatenbank erneut herzustellen, verwenden Sie diese Sicherung (und mindestens eine nachfolgende Protokollsicherung), um eine neue Spiegeldatenbank zu erstellen. Jede Protokollsicherung, die nach dem Entfernen der Spiegelung erstellt wurde, muss angewendet werden. Daher wird empfohlen, zusätzliche Protokollsicherungen der Prinzipaldatenbank so lange zu verzögern, bis die neue Spiegelungssitzung gestartet wird.

Verwandte Aufgaben zum Verwalten eines erzwungenen Failovers

Dienst erzwingen

• Erzwingen des Diensts in einer Datenbankspiegelungssitzung (Transact-SQL).

So setzen Sie die Datenbankspiegelung fort

• Anhalten oder Fortsetzen einer Datenbank-Spiegelungssitzung (SQL Server)

So erstellen Sie eine neue Spiegeldatenbank

Vorbereiten einer Spiegeldatenbank für die Spiegelung (SQL Server)

So starten Sie die Datenbankspiegelung

• Einrichten der Datenbankspiegelung (SQL Server)

• Einrichten einer Datenbankspiegelungssitzung mithilfe der Windows-Authentifizierung (SQL Server Management Studio)

Siehe auch

Schätzen der Dienstunterbrechung während des Rollenwechsels (Datenbankspiegelung)
Mögliche Fehler während der Datenbankspiegelung
Verbinden von Clients mit einer Datenbank-Spiegelungssitzung (SQL Server)
Datenbankspiegelungszeuge
Vollständige Datenbankwiederherstellungen (vollständiges Wiederherstellungsmodell)
Betriebsmodi für Datenbankspiegelung
Spiegelungsstatus (SQL Server)