Artikel
03/30/2012

Datenbank-Spiegelungssitzungen

Eine Datenbankspiegelung findet im Kontext einer Datenbank-Spiegelungssitzung statt. Dieses Thema setzt voraus, dass Sie mit den Rollen Prinzipal, Spiegel und Zeuge, den Betriebsmodi und dem Rollenwechsel bei der Datenbankspiegelung vertraut sind. Weitere Informationen finden Sie unter Übersicht über die Datenbankspiegelung.

Wenn die Spiegeldatenbank bereit ist und die Serverinstanzen konfiguriert sind, kann der Datenbankbesitzer die Datenbankspiegelung starten. Sobald die Spiegelung gestartet wird, beginnt jeder Partner, in seiner Datenbank Statusinformationen zu dieser Datenbank sowie zum anderen Partner und ggf. zum Zeugen zu verwalten. Diese Statusinformationen ermöglichen es den Serverinstanzen, eine Beziehung aufrechtzuerhalten, die als Datenbank-Spiegelungssitzung bezeichnet wird. Während der Datenbank-Spiegelungssitzung überwachen sich die Serverinstanzen gegenseitig. Die Statusinformationen werden verwaltet, bis der Datenbankbesitzer die Sitzung beendet. Weitere Informationen finden Sie unter Spiegelungsstatus und unter Überwachen der Datenbankspiegelung..

Beim Start einer Datenbank-Spiegelungssitzung identifiziert der Spiegelserver die Protokollfolgenummer (Log Sequence Number, LSN) des letzten Transaktionsprotokolls, das auf die Spiegeldatenbank angewendet wurde, und fordert beim Prinzipalserver das Transaktionsprotokoll für alle ggf. vorhandenen nachfolgenden Transaktionen an. Der Prinzipalserver sendet alle aktiven Protokolldatensätze als Antwort an den Spiegelserver, die sich seit dem letzten Protokoll, das in der Spiegeldatenbank wiederhergestellt wurde oder das an den Spiegelserver gesendet wurde, angesammelt haben. Nicht gesendete Protokolle, die sich auf dem Protokolldatenträger der Prinzipaldatenbank angesammelt haben, werden als Sendewarteschlange bezeichnet.

Der Spiegelserver schreibt das eingehende Protokoll unverzüglich auf den Datenträger, wo es gespeichert wird, bis es auf die Spiegeldatenbank angewendet wird. Die Protokolle, die auf dem Datenträger des Spiegelservers warten, werden als Wiederholungswarteschlange bezeichnet. Die Menge der nicht wiederhergestellten Protokolle in der Wiederholungswarteschlange ist ein Hinweis auf die erforderliche Zeit zur Ausführung eines Failovers zur Spiegeldatenbank. Weitere Informationen finden Sie unter Schätzen der Dienstunterbrechung beim Rollenwechsel.

Der Prinzipalserver macht die Prinzipaldatenbank weiterhin für Clients und Clientverbindungen verfügbar. Nach dem Start der Spiegelung schreibt der Prinzipalserver jedes Mal, wenn ein Client die Prinzipaldatenbank aktualisiert, die Transaktion in das Protokoll der Prinzipaldatenbank und sendet diesen Protokolldatensatz an den Spiegelserver. Der Spiegelserver schreibt dann den Protokolldatensatz unmittelbar als letzten Datensatz in die Wiederholungswarteschlange auf dem Datenträger.

Im Hintergrund wiederholt der Spiegelserver das Protokoll der Spiegeldatenbank, wobei er mit dem ältesten Protokolldatensatz beginnt und so schnell wie möglich alle Datensätze durchläuft. Das Wiederholen des Protokolls umfasst die sequenzielle Anwendung der Protokolldatensätze in der Warteschlange auf die Spiegeldatenbank, wobei mit dem ältesten Datensatz begonnen wird. Jeder Protokolldatensatz wird nur einmal wiederholt. Während der Spiegelserver das Protokoll wiederholt, wird für die Spiegeldatenbank ein ständiges Rollforward ausgeführt. Wenn der Prinzipalserver das Protokoll für die Prinzipaldatenbank abschneidet oder verkleinert, verkleinert auch der Spiegelserver das Protokoll an der gleichen Stelle im Protokolldatenstrom.

Im Allgemeinen wird die Spiegeldatenbank durch Wiederholen schnell auf den Stand der Prinzipaldatenbank gebracht. Ob die Spiegeldatenbank den aktuellen Stand der Prinzipaldatenbank tatsächlich erreicht, hängt vom Betriebsmodus der Sitzung ab. Im synchronen Modus für hohe Sicherheit wartet der Prinzipalserver zum Bestätigen neuer Transaktionen darauf, dass sie auf den Protokolldatenträger des Spiegelservers geschrieben werden. Nachdem die angesammelten Protokolldatensätze an den Spiegelserver gesendet wurden, wird die Spiegeldatenbank mit der Prinzipaldatenbank synchronisiert.

Wenn der Prinzipalserver während einer Sitzung nicht in der Lage ist, jeden Protokolldatensatz sofort zu senden, werden nicht gesendete Protokolldatensätze in der Sendewarteschlange angesammelt. Im synchronen Modus für hohe Sicherheit werden neue, nicht gesendete Protokolle nach der Synchronisierung nur dann angesammelt, wenn die Spiegelung angehalten oder unterbrochen wird. Im asynchronen Modus für hohe Leistung hingegen werden nicht gesendete Protokolle angesammelt, wenn der Spiegelserver während der Spiegelung zurückfällt und wenn die Spiegelung angehalten oder unterbrochen wird. Die Menge der nicht gesendeten Protokolle ist ein Hinweis auf den möglichen Datenverlust, falls der Prinzipalserver ausfallen sollte.

Hinweis
Wenn beim Wiederholen ein Fehler erzeugt wird, hält der Spiegelserver die Sitzung an, indem er die Datenbank in den Status SUSPENDED versetzt. Vor dem Fortsetzen der Sitzung muss der Datenbankbesitzer die Ursache des Fehlers beseitigen.

Gleichzeitige Sitzungen

Eine Serverinstanz kann an mehreren gleichzeitigen Datenbank-Spiegelungssitzungen (eine pro gespiegelter Datenbank) mit denselben oder mit anderen Serverinstanzen teilnehmen. Häufig dient eine Serverinstanz ausschließlich als Partner oder als Zeuge in allen Datenbank-Spiegelungssitzungen. Da jedoch jede Sitzung von den anderen Sitzungen unabhängig ist, kann eine Serverinstanz in einigen Sitzungen als Partner und in anderen Sitzungen als Zeuge fungieren. Betrachten Sie beispielsweise die folgenden vier Sitzungen zwischen drei Serverinstanzen (SSInstance_1, SSInstance_2 und SSInstance_3). Jede Serverinstanz dient in manchen Sitzungen als Partner und in anderen Sitzungen wiederum als Zeuge.

Serverinstanz	Sitzung für Datenbank A	Sitzung für Datenbank B	Sitzung für Datenbank C	Sitzung für Datenbank D
SSInstance_1	Zeuge	Partner (Server)	Partner (Server)	Partner (Server)
SSInstance_2	Partner (Server)	Zeuge	Partner (Server)	Partner (Server)
SSInstance_3	Partner (Server)	Partner (Server)	Zeuge	Zeuge

Die folgende Abbildung veranschaulicht zwei Serverinstanzen, die zusammen als Partner an zwei Spiegelungssitzungen teilnehmen. Eine Sitzung wird für eine Datenbank namens Db_1 und die andere für eine Datenbank namens Db_2 ausgeführt.

Zwei Serverinstanzen in zwei gleichzeitigen Sitzungen

Jede der Datenbanken ist unabhängig von den anderen. Beispielsweise könnte eine Serverinstanz zunächst der Spiegelserver für zwei Datenbanken sein. Wenn eine dieser Datenbanken ein Failover ausführt, wird die Serverinstanz zum Prinzipalserver für die Datenbank, die das Failover ausgeführt hat, während sie der Spiegelserver für die andere Datenbank bleibt.

Betrachten Sie als weiteres Beispiel eine Serverinstanz, die der Prinzipalserver für zwei oder mehr Datenbanken ist, die im Modus für hohe Sicherheit mit automatischem Failover ausgeführt werden. Wenn in der Serverinstanz ein Fehler auftritt, wird für alle Datenbanken automatisch ein Failover zu ihren jeweiligen Spiegeldatenbanken ausgeführt.

Stellen Sie beim Einrichten einer Serverinstanz für den Betrieb sowohl als Partner als auch als Zeuge sicher, dass der Endpunkt der Datenbankspiegelung beide Rollen unterstützt (weitere Informationen finden Sie unter Datenbank-Spiegelungsendpunkt). Stellen Sie außerdem sicher, dass das System über genügend Ressourcen verfügt, um Ressourcenkonflikte zu reduzieren.

Hinweis
Da gespiegelte Datenbanken voneinander unabhängig sind, ist für die Datenbanken kein Failover als Gruppe möglich.

Für eine Datenbank-Spiegelungssitzung erstellte Threads

Die Threads, die von einer Serverinstanz für eine Datenbank-Spiegelungssitzung erstellt werden, sind zum Teil von den Spiegelungsrollen abhängig, die die Serverinstanz ausführt. Eine Sitzung verfügt über einige oder alle der folgenden Threads:

Ein globaler Thread für die Datenbank-Spiegelungskommunikation. Dieser Thread wird von Service Broker gestartet.
Serverinstanz agiert als Spiegelungspartner (Prinzipalserver oder Spiegelserver):
- Ein Thread pro gespiegelter Datenbank für Ereignisverarbeitung.
- Ein Thread pro gespiegelter Datenbank für asynchrone Tasks (z. B. Protokollsendung oder Protokollschreibung), die anderenfalls den Ereignisthread blockieren würden.
Immer, wenn die Instanz als Spiegelserver agiert:
- Ein Wiederholungs-Manager-Thread, der das Protokoll zum Wiederholen übermittelt, Seiten-Read-Aheads durchführt, Sperren zurückerhält usw.
- In SQL Server Standard: ein Wiederholungsthread pro Spiegeldatenbank; und in SQL Server Enterprise: ein Wiederholungsthread pro Spiegeldatenbank für vier CPUs. Diese Threads führen die tatsächliche Protokollwiederholung durch.
Instanz agiert als Zeuge:
- Ein globaler Thread für die Verarbeitung der Zeugenmeldungen für alle Spiegelungssitzungen, in denen die Instanz als Zeuge agiert.

Voraussetzungen für eine Datenbank-Spiegelungssitzung

Bevor eine Spiegelungssitzung beginnen kann, muss der Datenbankbesitzer oder Systemadministrator die Spiegeldatenbank erstellen, Endpunkte und Anmeldungen einrichten und in einigen Fällen Zertifikate erstellen und einrichten. Weitere Informationen finden Sie unter Einrichten der Datenbankspiegelung.

Um eine Spiegeldatenbank minimal zu erstellen, müssen Sie eine vollständige Sicherung der Prinzipaldatenbank und eine nachfolgende Protokollsicherung erstellen und diese dann mithilfe von WITH NORECOVERY auf der Spiegelserverinstanz wiederherstellen. Bevor Sie mit der Spiegelung beginnen können, müssen Sie jede zusätzliche Protokollsicherung, die nach der erforderlichen Protokollsicherung erstellt wurde, manuell anwenden (immer mithilfe von WITH NORECOVERY). Nachdem Sie die letzte Protokollsicherung angewendet haben, können Sie mit der Spiegelung beginnen. Weitere Informationen finden Sie unter Vorbereiten einer Spiegeldatenbank auf die Spiegelung.

Auswirkungen des Anhaltens einer Sitzung auf das Transaktionsprotokoll des Prinzipals

Der Datenbankbesitzer kann eine Sitzung jederzeit anhalten. Durch Anhalten bleibt der Sitzungsstatus erhalten, während die Spiegelung entfernt wird. Wenn eine Sitzung angehalten wird, sendet der Prinzipalserver keine neuen Protokolldatensätze an den Spiegelserver. Alle diese Datensätze bleiben aktiv und werden im Transaktionsprotokoll der Prinzipaldatenbank gesammelt. Während eine Datenbank-Spiegelungssitzung angehalten wird, kann das Transaktionsprotokoll nicht abgeschnitten werden. Wird die Datenbank-Spiegelungssitzung zu lange angehalten, kann es somit sein, dass das Protokoll vollständig aufgefüllt wird.

Weitere Informationen finden Sie unter Anhalten und Fortsetzen der Datenbankspiegelung.

Clientverbindungen

Unterstützung für Clientverbindungen wird vom Microsoft .NET-Datenanbieter für SQL Server bereitgestellt. Weitere Informationen finden Sie unter Herstellen von Clientverbindungen mit einer gespiegelten Datenbank.