Asynchrone Datenbankspiegelung (Modus für hohe Leistung)
.gif "Hinweis") Hinweis |
|---|
Asynchrone Datenbankspiegelung wird nur von SQL Server 2005 Enterprise Edition Service Pack 1 (SP1) und höheren Versionen unterstützt. |
Wenn die Transaktionssicherheit auf OFF festgelegt ist, wird die Datenbank-Spiegelungssitzung asynchron ausgeführt. Im asynchronen Betrieb wird nur ein Betriebsmodus unterstützt, nämlich der Modus für hohe Leistung. Dieser Modus verbessert die Leistung auf Kosten der hohen Verfügbarkeit. Im Modus für hohe Leistung werden nur der Prinzipalserver und der Spiegelserver verwendet. Probleme auf dem Spiegelserver haben nie Auswirkungen auf den Prinzipalserver. Bei einem Ausfall des Prinzipalservers wird die Spiegeldatenbank als DISCONNECTED gekennzeichnet, steht jedoch als betriebsbereit zur Verfügung.
Im Modus für hohe Leistung wird nur eine Form des Rollenwechsels unterstützt: erzwungener Dienst (mit möglichem Datenverlust), der den Spiegelserver als betriebsbereiten Standbyserver verwendet. Der erzwungene Dienst ist eine der möglichen Antworten auf einen Fehler des Prinzipalservers. Da Datenverlust möglich ist, sollten Sie andere Alternativen in Betracht ziehen, bevor Sie den erzwungenen Dienst für den Spiegelserver verwenden. Weitere Informationen finden Sie im Abschnitt zu Antworten auf Fehler des Prinzipalservers weiter unten in diesem Thema.
Die folgende Abbildung veranschaulicht die Konfiguration einer Sitzung im Modus für hohe Leistung.
.gif "Reine Partnerkonfiguration einer Sitzung")
Sobald im Modus für hohe Leistung der Prinzipalserver das Protokoll für eine Transaktion an den Spiegelserver sendet, wird vom Prinzipalserver eine Bestätigung an den Client gesendet, ohne auf eine Bestätigung vom Spiegelserver zu warten. Für Transaktionen wird ein Commit ausgeführt, ohne darauf zu warten, dass der Spiegelserver das Protokoll auf dem Datenträger speichert. Im asynchronen Betrieb kann der Prinzipalserver mit minimaler Transaktionslatenzzeit ausgeführt werden.
Der Spiegelserver versucht mit den Protokolldatensätzen Schritt zu halten, die vom Prinzipalserver gesendet werden. Die Spiegeldatenbank kann sich jedoch in einem gewissen zeitlichen Abstand zur Prinzipaldatenbank befinden, wobei der Abstand zwischen den Datenbanken normalerweise gering ist. Diese Differenz kann jedoch umfangreich werden, wenn der Prinzipalserver stark ausgelastet ist oder wenn der Spiegelserver überlastet ist.
Wann eignet sich der Modus für hohe Leistung?
Der Modus für hohe Leistung kann bei der Wiederherstellung im Notfall hilfreich sein, wenn der Prinzipalserver und der Spiegelserver durch eine beträchtliche Distanz voneinander getrennt sind und wenn kleine Fehler den Prinzipalserver nicht beeinträchtigen sollen.
| Hinweis |
|---|
Protokollversand kann eine Ergänzung zur Datenbankspiegelung darstellen und ist eine empfehlenswerte Alternative zur asynchronen Datenbankspiegelung. Weitere Informationen zu den Vorteilen des Protokollversands finden Sie unter Hochverfügbarkeitslösungen: Übersicht. Informationen zum Verwenden des Protokollversands zusammen mit der Datenbankspiegelung finden Sie unter Datenbankspiegelung und Protokollversand. |
Auswirkung eines Zeugen im Modus für hohe Leistung
Wenn Sie Transact-SQL zum Konfigurieren des Modus für hohe Leistung verwenden und die SAFETY-Eigenschaft auf OFF festgelegt ist, sollte unbedingt auch für die WITNESS-Eigenschaft OFF festgelegt sein. Ein Zeuge kann im Modus für hohe Leistung vorhanden sein, er stellt jedoch keinen Vorteil, sondern ein Risiko dar.
Wenn der Zeuge von der Sitzung getrennt wird und einer der Partner ausfällt, ist die Datenbank nicht mehr verfügbar. Dies ist darauf zurückzuführen, dass die Sitzung ein aus mindestens zwei Serverinstanzen bestehendes Quorum benötigt, wenn ein Zeuge festgelegt ist, obwohl der Modus für hohe Leistung keinen Zeugen erfordert. Wenn die Sitzung das Quorum verliert, kann sie die Datenbank nicht bedienen.
Wenn ein Zeuge in einer Sitzung im Modus für hohe Leistung festgelegt ist, hat das Erzwingen eines Quorums folgende Auswirkungen:
Wenn der Spiegelserver ausfällt, muss der Prinzipalserver mit dem Zeugen verbunden sein. Andernfalls schaltet der Prinzipalserver die Datenbank so lange offline, bis entweder der Zeuge oder der Spiegelserver wieder mit der Sitzung verbunden ist.
Wenn der Prinzipalserver ausfällt, wird für das Erzwingen des Dienstes auf dem Spiegelserver eine Verbindung des Spiegelservers mit dem Zeugen benötigt.
| Hinweis |
|---|
Weitere Informationen zu den Quorumtypen finden Sie unter Quorum: Auswirkungen eines Zeugen auf die Datenbankverfügbarkeit. |
Antworten auf Fehler des Prinzipalservers
Bei einem Fehler des Prinzipalservers hat der Datenbankbesitzer folgende Möglichkeiten:
Die Datenbank nicht verfügbar belassen, bis der Prinzipalserver wieder verfügbar ist.
Falls die Prinzipaldatenbank und das zugehörige Transaktionsprotokoll intakt sind, werden mit dieser Methode alle Transaktionen, für die ein Commit ausgeführt wurde, auf Kosten der Verfügbarkeit beibehalten.
Beenden der Datenbank-Spiegelungssitzung, manuelles Aktualisieren der Datenbank und dann Starten einer neuen Datenbank-Spiegelungssitzung.
Falls die Prinzipaldatenbank verloren gegangen ist, aber der Prinzipalserver noch ausgeführt wird, versuchen Sie sofort das Protokollfragment in der Prinzipaldatenbank zu sichern. Falls die Sicherung des Protokollfragments erfolgreich ist, ist das Entfernen der Spiegelung vermutlich die beste Alternative. Nachdem Sie die Spiegelung entfernt haben, können Sie das Protokoll in der ehemaligen Spiegeldatenbank wiederherstellen, wodurch alle Daten erhalten bleiben.
HinweisFalls bei der Sicherung des Protokollfragments ein Fehler auftrat und Sie nicht auf die Wiederherstellung des Prinzipalservers warten können, sollten Sie den Dienst erzwingen. Dies hat den Vorteil, dass der Sitzungsstatus erhalten bleibt.
Erzwingen des Dienstes (mit möglichem Datenverlust) auf dem Spiegelserver.
Das Erzwingen des Dienstes ist ausschließlich eine Maßnahme im Rahmen der Wiederherstellung im Notfall und sollte nur selten verwendet werden. Das Erzwingen des Dienstes ist nur möglich, wenn der Prinzipalserver heruntergefahren ist, es sich um eine asynchrone Sitzung handelt (die Transaktionssicherheit ist auf OFF festgelegt) und die Sitzung keinen Zeugen aufweist (WITNESS ist auf OFF festgelegt) oder der Zeuge mit dem Spiegelserver verbunden ist (er also ein Quorum besitzt).
Durch das Erzwingen des Dienstes nimmt der Spiegelserver die Rolle des Prinzipalservers an und bietet die Datenbankkopie den Clients an. Wenn der Dienst erzwungen wird, gehen alle Transaktionsprotokolle verloren, die der Prinzipalserver noch nicht an den Spiegelserver gesendet hat. Deshalb sollten Sie das Erzwingen des Dienstes für Situationen vorbehalten, in denen ein möglicher Datenverlust akzeptabel ist und die sofortige Verfügbarkeit der Datenbank von entscheidender Bedeutung ist. Informationen zur Funktionsweise des erzwungenen Dienstes und bewährte Methoden zum Verwenden finden Sie unter Erzwungener Dienst (mit möglichem Datenverlust).