Artikel
09/24/2010

Erzwungener Dienst (mit möglichem Datenverlust)

Im Rahmen der Datenbankspiegelung wird das Erzwingen des Dienstes (bei möglichem Datenverlust) als eine Methode der Notfallwiederherstellung bereitgestellt, bei der Ihnen die Verwendung eines Spiegelservers als betriebsbereiter Standbyserver ermöglicht wird. Das Erzwingen des Dienstes ist nur möglich, wenn keine Verbindung in einer Spiegelungssitzung zwischen Prinzipalserver und Spiegelserver besteht. Da es beim Erzwingen des Dienstes zu Datenverlusten kommen kann, sollte diese Methode unter Vorbehalt und selten angewendet werden.

Die Unterstützung des erzwungenen Dienstes hängt wie folgt vom Betriebsmodus und dem Status der Sitzung ab:

In der Regel unterstützt der Modus für hohe Leistung das Erzwingen des Dienstes, wenn keine Verbindung mit dem Prinzipalserver besteht. Obwohl nicht erforderlich, kann jedoch ein Zeuge für eine Sitzung im Modus für hohe Leistung eingerichtet werden. In diesem Fall ist zum Erzwingen des Dienstes erforderlich, dass der Spiegelserver und der Zeuge miteinander verbunden sind.
Der Modus für hohe Sicherheit mit automatischem Failover unterstützt das Erzwingen des Dienstes, wenn keine Verbindung mit dem Prinzipalserver besteht.
Der Modus für hohe Sicherheit mit automatischem Failover unterstützt das Erzwingen des Dienstes, wenn eine Verbindung zwischen Spiegelserver und Zeuge besteht und keiner der beiden mit dem Prinzipalserver verbunden ist (solange der Spiegelserver gerade kein Rollback der Spiegeldatenbank ausgeführt hat, als zuletzt eine Verbindung mit dem Prinzipalserver bestand).

Es wird empfohlen, den Dienst nur dann zu erzwingen, wenn Sie den Dienst für die Datenbank sofort wiederherstellen müssen und bereit sind, das Risiko des Datenverlustes in Kauf zu nehmen. Die Auswirkungen aus dem Erzwingen des Dienstes sind vergleichbar mit dem Entfernen der Spiegelung, außer dass durch das Erzwingen des Dienstes das erneute Synchronisieren der Datenbanken (bei möglichem Datenverlust) vereinfacht wird, wenn die Spiegelung fortgesetzt wird. Durch das Erzwingen des Dienstes wird ein sanfter Übergang von der Prinzipalrolle zur Spiegeldatenbank gestartet. Der Spiegelserver nimmt die Rolle des Prinzipalservers an und bietet seine Datenbankkopie den Clients sofort an. Die neue Prinzipaldatenbank wird ohne einen Spiegel ausgeführt (sie wird also ungeschützt ausgeführt).

Wichtig
Wurde der Prinzipalserver nur von der Datenbank-Spiegelungssitzung getrennt, wird jedoch weiter ausgeführt, greifen einige Clients möglicherweise weiterhin auf die ursprüngliche Prinzipaldatenbank zu. Vor dem Erzwingen des Dienstes müssen Sie verhindern, dass Clients weiterhin auf den ursprünglichen Prinzipalserver zugreifen. Andernfalls ist es nach dem Erzwingen des Dienstes möglich, dass die ursprüngliche Prinzipaldatenbank und die aktuelle Prinzipaldatenbank unabhängig voneinander aktualisiert werden.

Wurde der Prinzipalserver nur von der Datenbank-Spiegelungssitzung getrennt, wird jedoch weiter ausgeführt, greifen einige Clients möglicherweise weiterhin auf die ursprüngliche Prinzipaldatenbank zu. Vor dem Erzwingen des Dienstes müssen Sie verhindern, dass Clients weiterhin auf den ursprünglichen Prinzipalserver zugreifen. Andernfalls ist es nach dem Erzwingen des Dienstes möglich, dass die ursprüngliche Prinzipaldatenbank und die aktuelle Prinzipaldatenbank unabhängig voneinander aktualisiert werden.

Typischer Fall eines erzwungenen Dienstes

Die folgende Abbildung veranschaulicht einen typischen Fall eines erzwungenen Dienstes (mit möglichem Datenverlust).

Diensterzwingung mit möglichem Datenverlust

In der Abbildung fällt der ursprüngliche Prinzipalserver (Partner_A) aus und steht dem Spiegelserver (Partner_B) nicht mehr zur Verfügung, wodurch die Spiegeldatenbank getrennt wird. Nachdem sichergestellt wurde, dass Partner_A Clients nicht zur Verfügung steht, erzwingt der Datenbankadministrator den Dienst, mit möglichem Datenverlust, auf Partner_B. Partner_B wird zum Prinzipalserver, und die Datenbank wird ungeschützt (d. h. ungespiegelt) ausgeführt. An diesem Punkt können Clients die Verbindung mit Partner_B wieder herstellen.

Wenn Partner_A wieder zur Verfügung steht, stellt er die Verbindung mit dem neuen Prinzipalserver erneut her, tritt der Sitzung wieder bei und übernimmt die Rolle des Spiegelservers. Die Spiegelungssitzung wird sofort angehalten, ohne dass die neue Spiegeldatenbank synchronisiert wird. Durch das Anhalten der Sitzung kann der Datenbankadministrator entscheiden, ob die Sitzung fortgesetzt, oder in Extremfällen, die Spiegelung entfernt und der Versuch unternommen werden soll, Daten aus der früheren Prinzipaldatenbank zu retten. In diesem Fall entscheidet sich der Datenbankadministrator für das Fortsetzen der Spiegelung. An dieser Stelle übernimmt Partner_A die Rolle des Spiegelservers und führt einen Rollback der früheren Prinzipaldatenbank zu dem Zeitpunkt der letzten erfolgreich synchronisierten Transaktion aus. Wenn Transaktionen, für die ein Commit ausgeführt wurde, vor dem Erzwingen des Dienstes nicht auf den Datenträger des Spiegelservers geschrieben wurden, gehen sie verloren. Partner_A führt dann einen Rollforward der neuen Spiegeldatenbank aus, indem alle Änderungen, die in der neuen Prinzipaldatenbank vorgenommen wurden, seitdem der frühere Spiegelserver die Rolle des neuen Prinzipalservers übernommen hat, angewendet werden.

Hinweis
Wurde im Modus für hohe Leistung ein Zeuge konfiguriert (dies ist nicht notwendig), ist das Erzwingen des Dienstes nur möglich, wenn der Zeuge derzeit mit dem Spiegelserver verbunden ist.

Risiken beim Erzwingen des Dienstes

Sie sollten unbedingt bedenken, dass durch das Erzwingen des Dienstes Daten verloren gehen können. Zu einem Datenverlust kann es kommen, weil der Spiegelserver nicht mit dem Prinzipalserver kommunizieren und somit nicht sicherstellen kann, dass beide Datenbanken synchronisiert sind. Durch das Erzwingen des Dienstes wird ein neuer Wiederherstellungs-Verzweigungspunkt gestartet. Da sich die ursprüngliche Prinzipaldatenbank und die Spiegeldatenbank auf verschiedenen Wiederherstellungsverzweigungen befinden, enthält jede Datenbank nun Daten, die in der jeweils anderen Datenbank nicht vorhanden sind: Die ursprüngliche Prinzipaldatenbank enthält die Änderungen, die noch nicht aus der Sendewarteschlange an die frühere Spiegeldatenbank gesendet wurden (die nicht gesendeten Protokolle). Die frühere Spiegeldatenbank enthält die Änderungen, die nach dem Erzwingen des Dienstes vorgenommen wurden.

Hinweis
Weitere Informationen zu Wiederherstellungsverzweigungen finden Sie unter Wiederherstellungspfade.

Wird der Dienst aufgrund eines Fehlers des Prinzipalservers erzwungen, hängt der potenzielle Datenverlust davon ab, ob Transaktionsprotokolle vorhanden sind, die vor dem Fehler nicht an den Spiegelserver gesendet wurden. Im Modus für hohe Sicherheit ist dies nur bis zum Synchronisieren der Spiegeldatenbank möglich. Im Modus für hohe Leistung besteht immer die Möglichkeit, dass sich nicht gesendete Protokolle ansammeln.

Die Auswirkungen aus dem Erzwingen des Dienstes hängen teilweise davon ab, ob die Sitzung über einen Zeugen verfügt.

Ohne einen Zeugen kann der Dienst erzwungen werden, wenn die Verbindung der Partner beispielsweise aufgrund einer unterbrochenen Netzwerkverbindung getrennt wird. Wird der ursprüngliche Prinzipalserver weiterhin ausgeführt, haben beide Partner die Rolle des Prinzipals inne. Clients, die eine Verbindung mit dem neuen Prinzipalserver herstellen, greifen auf die aktuelle Datenbankversion zu, während Clients, die eine Verbindung mit dem ursprünglichen Prinzipalserver herstellen, auf die ursprüngliche Prinzipaldatenbank zugreifen. In dieser Situation steigt die Wahrscheinlichkeit eines Datenverlusts. Wenn es den Partnern möglich ist, die Verbindung wiederherzustellen, nimmt der ursprüngliche Server die Rolle des Spiegelservers an und ändert den Status seiner Datenbank zu "Wird wiederhergestellt", ehe die Spiegelung angehalten wird. Wenn die Sitzung fortgesetzt wird, gehen Transaktionen in der ursprünglichen Datenbank, deren Protokolle sich zum Zeitpunkt der letzten Verbindungsunterbrechung in der Sendewarteschlange befanden, verloren. Außerdem gehen alle Transaktionen verloren, die nach dem Erzwingen des Dienstes stattfanden.
Ist ein Zeuge vorhanden und der Spiegelserver wird sowohl vom Prinzipalserver als auch vom Zeugen getrennt, wird der Prinzipalserver ungeschützt ausgeführt, solange die Verbindung zwischen Prinzipalserver und Zeuge weiter besteht. Wird die Verbindung des Prinzipalservers mit dem Zeugen dann getrennt, stellt er die Datenbank nicht länger bereit. Wenn der Spiegelserver die Verbindung mit dem Zeugen wiederherstellt, ist es danach möglich, den Dienst zu erzwingen. Wird der Dienst erzwungen, gehen alle Änderungen verloren, die während des ungeschützten Ausführens des ursprünglichen Prinzipalservers vorgenommen wurden, sobald der ursprüngliche Prinzipalserver die Verbindung wiederherstellt.

Weitere Informationen finden Sie nachfolgend in diesem Thema unter "Umgang mit potenziellem Datenverlust".

Umgang mit potenziellem Datenverlust

Sobald der frühere Prinzipalserver verfügbar ist, können Sie nach dem Erzwingen des Dienstes versuchen, den potenziellen Datenverlust zu verwalten, vorausgesetzt die Datenbank ist unbeschädigt. Der jeweilige Ansatz für die Verwaltung des potenziellen Datenverlusts hängt davon ab, ob der ursprüngliche Prinzipalserver die Verbindung zu seinem Partner wiederhergestellt hat und wieder an der Spiegelungssitzung teilnimmt. Vorausgesetzt, dass der ursprüngliche Prinzipalserver auf die neue Prinzipalinstanz zugreifen kann, wird die Verbindung automatisch und transparent wiederhergestellt.

Der ursprüngliche Prinzipalserver hat die Verbindung wiederhergestellt

Normalerweise stellt der ursprüngliche Prinzipalserver nach einem Fehler beim Neustarten rasch die Verbindung zu seinem Partner wieder her. Beim Wiederherstellen der Verbindung wird der ursprüngliche Prinzipalserver zum Spiegelserver. Seine Datenbank wird zur Spiegeldatenbank und nimmt vor dem Anhalten der Sitzung des Status "Wird wiederhergestellt" an. Es wird nur dann ein Rollback der Spiegeldatenbank ausgeführt, wenn Sie die Spiegelung fortsetzen.

Der Zugriff auf die Datenbank, die wiederhergestellt wird, ist jedoch nicht möglich; deshalb können Sie sie nicht überprüfen, um festzustellen, welche Daten im Falle der fortgesetzten Spiegelung verloren gehen würden. Die Entscheidung, ob die Spiegelung fortgesetzt oder entfernt werden soll, hängt somit davon ab, ob Sie bereit sind, Datenverluste grundsätzlich in Kauf zu nehmen.

Wenn der Verlust von Daten inakzeptabel ist, sollten Sie die Spiegelung entfernen, um die Daten zu retten.

Durch das Entfernen der Spiegelung kann der Datenbankadministrator die ursprüngliche Prinzipaldatenbank wiederherstellen und den Versuch unternehmen, die Daten wiederherzustellen. Wird die frühere Spiegeldatenbank jedoch online geschaltet, stellen die früheren Partner unterschiedliche Datenbanken unter demselben Namen bereit. Der Datenbankadministrator muss dafür sorgen, dass Clients auf eine der Datenbanken nicht zugreifen können, um weitere Abweichungen der Datenbanken sowie Clientfailoverprobleme zu vermeiden.
Wenn der Verlust von Daten akzeptabel ist, können Sie die Spiegelung fortsetzen.

Beim Fortsetzen der Spiegelung wird in einem ersten Schritt ein Rollback der neuen Spiegeldatenbank ausgeführt, um die Datenbank zu synchronisieren. 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 hat die Verbindung nicht wiederhergestellt

Wenn Sie zeitweise verhindern können, dass der ursprüngliche Prinzipalserver wieder eine Verbindung über das Netzwerk mit dem neuen Prinzipalserver herstellt, können Sie die ursprüngliche Prinzipaldatenbank überprüfen und so feststellen, welche Daten im Falle einer fortgesetzten Spiegelung verloren gehen würden.

Der potenzielle Datenverlust ist akzeptabel

Ermöglichen Sie es dem ursprünglichen Prinzipalserver, die Verbindung mit seinem Partner wiederherzustellen. Durch das Wiederherstellen der Verbindung wird die Spiegelung angehalten. Wenn Sie mit der Spiegelung fortfahren möchten, setzen Sie die Sitzung einfach fort. Der frühere Prinzipalserver übernimmt die Rolle des Spiegelservers. Der neue Spiegelserver löscht den ursprünglichen Wiederherstellungs-Verzweigungspunkt, wobei alle Transaktionen verloren gehen, die nie an den früheren Spiegelserver gesendet wurden bzw. von ihm 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 fortsetzen, können Sie Daten auf dem ursprünglichen Prinzipalserver durch Entfernen der Spiegelung beibehalten. Sie sollten in diesem Fall versuchen, das Protokollfragment des Prinzipals zu sichern. Sie können dann den aktuellen Prinzipalserver (die frühere Spiegeldatenbank) durch Exportieren der in der ursprünglichen Prinzipaldatenbank zu erhaltenden Daten und Importieren der Daten in die aktuelle Prinzipaldatenbank aktualisieren. Es wird empfohlen, so schnell wie möglich eine vollständige Datenbanksicherung der aktualisierten Datenbank zu erstellen.

Wenn Sie die Spiegelung mit der aktualisierten Datenbank als erste Prinzipaldatenbank wieder aufnehmen möchten, 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. Deshalb wird empfohlen, zusätzliche Protokollsicherungen der Prinzipaldatenbank bis zum Starten der neuen Spiegelungssitzung zu verzögern.