Freigeben über

Betriebsmodi für Datenbankspiegelung

In diesem Thema werden die synchronen und asynchronen Betriebsmodi für Datenbankspiegelungssitzungen beschrieben.

Hinweis

Eine Einführung in die Datenbankspiegelung finden Sie unter Datenbankspiegelung (SQL Server).

Begriffe und Definitionen

In diesem Abschnitt werden einige Begriffe vorgestellt, die für dieses Thema von zentraler Bedeutung sind.

Modus mit hoher Leistung
Die Datenbankspiegelungssitzung funktioniert asynchron und verwendet nur den Prinzipalserver und den Spiegelserver. Die einzige Form des Rollenwechsels ist erzwungener Dienst (mit möglichen Datenverlusten).

Modus für hohe Sicherheit
Die Datenbankspiegelungssitzung wird synchron ausgeführt und verwendet optional einen Zeugen sowie den Prinzipalserver und den Spiegelserver.

Transaktionssicherheit
Eine spiegelungsspezifische Datenbankeigenschaft, die bestimmt, ob eine Datenbankspiegelungssitzung synchron oder asynchron ausgeführt wird. Es gibt zwei Sicherheitsstufen: FULL und OFF.

Zeuge
Für die Verwendung nur im Hochsicherheitsmodus, einer optionalen Instanz von SQL Server, mit der der Spiegelserver erkennen kann, ob ein automatisches Failover initiiert werden soll. Im Gegensatz zu den beiden Failoverpartnern dient der Zeuge nicht der Datenbank. Die Unterstützung des automatischen Failovers ist die einzige Rolle des Zeugen.

Asynchrone Datenbankspiegelung imHigh-Performance-Modus

In diesem Abschnitt wird beschrieben, wie die asynchrone Datenbankspiegelung funktioniert, wenn die Verwendung des Hochleistungsmodus geeignet ist und wie Sie reagieren, wenn der Prinzipalserver fehlschlägt.

Hinweis

Die meisten Editionen von SQL Server 2014 unterstützen nur synchrone Datenbankspiegelung ("Nur Safety Full"). Informationen zu Editionen, die die Datenbankspiegelung vollständig unterstützen, finden Sie unter "Hohe Verfügbarkeit (AlwaysOn)" in Features, die von den Editionen von SQL Server 2014 unterstützt werden.

Wenn die Transaktionssicherheit auf OFF festgelegt ist, wird die Datenbankspiegelungssitzung asynchron ausgeführt. Asynchroner Vorgang unterstützt nur einen Betriebsmodus mit hoher Leistung. Dieser Modus verbessert die Leistung auf Kosten einer hohen Verfügbarkeit. Der Hochleistungsmodus verwendet nur den Prinzipalserver und den Spiegelserver. Probleme auf dem Spiegelserver wirken sich nie auf den Prinzipalserver aus. Beim Verlust des Hauptservers wird die Spiegeldatenbank als GETRENNT markiert, ist aber als warmer Bereitschaftszustand verfügbar.

Der Hochleistungsmodus unterstützt nur eine Form des Rollenwechsels: erzwungener Dienst (mit möglichem Datenverlust), der den Spiegelserver als warmer Standbyserver verwendet. Der erzwungene Dienst ist eine der möglichen Antworten auf den Fehler des Prinzipalservers. Da Datenverlust möglich ist, sollten Sie andere Optionen berücksichtigen, bevor Sie auf die Spiegelung zurückgreifen. Weitere Informationen finden Sie unter "Reagieren auf Fehler des Prinzipals" weiter unten in diesem Thema.

Die folgende Abbildung zeigt die Konfiguration einer Sitzung im Hochleistungsmodus.

Konfiguration einer Sitzung nur für Partner

Im Hochleistungsmodus sendet der Principalserver, sobald er das Protokoll für eine Transaktion an den Spiegelserver übermittelt hat, eine Bestätigung an den Client, ohne auf eine Bestätigung vom Spiegelserver zu warten. Transaktionen werden verbindlich gemacht, ohne dass auf den Spiegelserver gewartet wird, damit das Protokoll auf den Datenträger geschrieben wird. Bei asynchronen Vorgängen kann der Prinzipalserver mit minimaler Transaktionslatenz ausgeführt werden.

Der Spiegelserver versucht, die vom Prinzipalserver gesendeten Protokolldatensätze auf dem Laufenden zu halten. Die Spiegeldatenbank kann jedoch etwas hinter der Prinzipaldatenbank liegen, obwohl die Lücke zwischen den Datenbanken in der Regel klein ist. Die Lücke kann jedoch erheblich werden, wenn der Prinzipalserver unter einer hohen Arbeitslast liegt oder das System des Spiegelservers überlastt wird.

Wann ist High-Performance Modus geeignet?

Der Modus mit hoher Leistung kann in einem Notfallwiederherstellungsszenario hilfreich sein, in dem die Prinzipal- und Spiegelserver durch einen erheblichen Abstand voneinander getrennt sind und keine kleinen Fehler auf den Prinzipalserver auswirken sollen.

Hinweis

Der Protokollversand kann eine Ergänzung zur Datenbankspiegelung sein und ist eine günstige Alternative zur asynchronen Datenbankspiegelung. Informationen zu den Vorteilen des Protokollversands finden Sie unter High Availability Solutions (SQL Server). Informationen zur Verwendung des Protokollversands mit Datenbankspiegelung finden Sie unter Datenbankspiegelung und Protokollversand (SQL Server).

Auswirkungen eines Zeugen auf High-Performance Modus

Wenn Sie Transact-SQL verwenden, um den Hochleistungsmodus zu konfigurieren, empfehlen wir dringend, dass die WITNESS-Eigenschaft ebenfalls auf OFF festgelegt ist, wann immer die SAFETY-Eigenschaft auf OFF gesetzt wird. Ein Zeuge kann mit einem Hochleistungsmodus koexistieren, aber der Zeuge bietet keinen Nutzen und führt zu Risiken.

Wenn der Zeuge aus der Sitzung getrennt wird, weil ein Partner ausfällt, wird die Datenbank nicht mehr zugänglich. Dies liegt daran, dass die Sitzung ein Quorum erfordert, das aus zwei oder mehr Serverinstanzen besteht, auch wenn der Hochleistungsmodus keinen Zeugen erfordert. Wenn das Quorum der Sitzung verloren geht, kann sie die Datenbank nicht bedienen.

Wenn ein Zeuge in einer Sitzung im Hochleistungsmodus eingesetzt wird, bedeutet die Erfüllung des Quorums Folgendes:

  • Wenn der Spiegelserver verloren geht, muss der Hauptserver mit dem Zeugen verbunden sein. Andernfalls stellt der Hauptserver seine Datenbank offline, bis entweder der Zeugen- oder der Spiegelserver der Sitzung wieder beitritt.

  • Wenn der Hauptserver verloren geht, erfordert es, dass der Service auf den Spiegelserver umgestellt wird und der Spiegelserver mit dem Zeugen verbunden ist.

Hinweis

Informationen zu den Typen von Quorums finden Sie unter Quorum: Wie sich ein Zeugen auf die Datenbankverfügbarkeit auswirkt (Datenbankspiegelung).

Reagieren auf Fehler des Prinzipals

Wenn der Hauptakteur fehlschlägt, hat der Datenbankbesitzer mehrere Optionen:

  • Lassen Sie die Datenbank unzugänglich, bis die Hauptperson wieder verfügbar ist.

    Wenn die Prinzipaldatenbank und das Transaktionsprotokoll intakt sind, behält diese Option alle zugesicherten Transaktionen auf Kosten der Verfügbarkeit bei.

  • Beenden Sie die Datenbankspiegelungssitzung, aktualisieren Sie die Datenbank manuell, und beginnen Sie dann eine neue Datenbankspiegelungssitzung.

    Wenn die Prinzipaldatenbank verloren geht, der Prinzipalserver aber noch ausgeführt wird, versuchen Sie sofort, den Tail des Protokolls in der Prinzipaldatenbank zu sichern. Wenn die Sicherung des Transaktionsprotokoll-Endes erfolgreich ist, kann das Entfernen der Datenbankspiegelung die beste Alternative sein. Nach dem Entfernen der Spiegelung können Sie das Protokoll in der ehemaligen Spiegeldatenbank wiederherstellen, wodurch alle Daten erhalten bleiben.

    Hinweis

    Wenn die Sicherung des Tailprotokolls fehlgeschlagen ist und Sie nicht warten können, bis der Hauptserver wiederhergestellt wird, erwägen Sie die erzwungene Dienstausführung, um den Sitzungsszustand zu erhalten.

  • Erzwingen Sie den Dienst (mit möglichen Datenverlusten) auf dem Spiegelserver.

    Der erzwungene Dienst ist streng eine Notfallwiederherstellungsmethode und sollte sparsam verwendet werden. Das Erzwingen des Dienstes ist nur möglich, wenn der Prinzipalserver ausgefallen ist, die Sitzung asynchron ist (Transaktionssicherheit ist auf OFF gesetzt), und entweder die Sitzung keinen Zeugen hat (die WITNESS-Eigenschaft ist auf OFF gesetzt) oder der Zeuge mit dem Spiegelserver verbunden ist (d. h., sie erreichen ein Quorum).

    Das Erzwingen des Dienstes bewirkt, dass der Spiegelserver die Rolle des Hauptservers übernimmt und seine Kopie der Datenbank für Clients bereitstellt. Wenn der Dienst erzwungen wird, gehen alle Transaktionsprotokolle, die der Prinzipal noch nicht an den Spiegelserver gesendet hat, verloren. Daher sollten Sie den erzwungenen Dienst auf Situationen beschränken, in denen möglicher Datenverlust akzeptabel ist und die sofortige Datenbankverfügbarkeit von entscheidender Bedeutung ist. Informationen zur Funktionsweise des erzwungenen Diensts und zu bewährten Methoden für die Verwendung finden Sie unter Rollenwechsel während einer Datenbankspiegelungssitzung (SQL Server).

Synchrone Datenbankspiegelung (High-Safety-Modus)

In diesem Abschnitt wird beschrieben, wie die synchrone Datenbankspiegelung funktioniert, einschließlich der alternativen Hochsicherheitsmodi (mit automatischem Failover und ohne automatischem Failover) und enthält Informationen zur Rolle des Zeugen in automatischem Failover.

Wenn die Transaktionssicherheit auf FULL festgelegt ist, läuft die Datenbankspiegelungssitzung im Hochsicherheitsmodus und arbeitet synchron nach einer anfänglichen Synchronisierungsphase. In diesem Abschnitt werden die Details der Datenbankspiegelungssitzungen beschrieben, die für synchronen Betrieb konfiguriert sind.

Um einen synchronen Vorgang für eine Sitzung zu erzielen, muss der Spiegelserver die Spiegeldatenbank mit der Prinzipaldatenbank synchronisieren. Wenn die Sitzung beginnt, beginnt der Prinzipalserver, sein aktives Protokoll an den Spiegelserver zu senden. Der Spiegelserver schreibt alle eingehenden Protokolldatensätze so schnell wie möglich auf den Datenträger. Sobald alle empfangenen Protokolldatensätze auf den Datenträger geschrieben wurden, werden die Datenbanken synchronisiert. Solange die Partner in der Kommunikation bleiben, bleiben die Datenbanken synchronisiert.

Hinweis

Verwenden Sie die Ereignisklasse "Datenbankspiegelungsstatusänderung ", um Zustandsänderungen in einer Datenbankspiegelungssitzung zu überwachen. Weitere Informationen finden Sie unter Database Mirroring State Change Event Class.

Nach Abschluss der Synchronisierung wird jede Transaktion, die auf der Prinzipaldatenbank ausgeführt wird, auch auf dem Spiegelserver ausgeführt, wodurch der Schutz der Daten gewährleistet wird. Dies wird erreicht, indem die Transaktion auf der Hauptdatenbank erst dann ausgeführt wird, wenn der Hauptserver eine Nachricht vom Spiegelserver erhält, dass er das Transaktionsprotokoll auf die Festplatte gesichert hat. Beachten Sie, dass die Wartezeit für diese Nachricht die Latenz der Transaktion erhöht.

Die für die Synchronisierung erforderliche Zeit hängt im Wesentlichen davon ab, wie weit die Spiegeldatenbank zu Beginn der Sitzung hinter der Prinzipaldatenbank lag (gemessen durch die Anzahl der vom Prinzipalserver empfangenen Protokolldatensätze), die Arbeitslast für die Prinzipaldatenbank und die Geschwindigkeit des Spiegelsystems. Nachdem eine Sitzung synchronisiert wurde, verbleibt das gehärtete Protokoll, das noch nicht in der Spiegeldatenbank erneut ausgeführt werden muss, in der Redo-Warteschlange.

Sobald die Spiegeldatenbank synchronisiert wird, ändert sich der Zustand der beiden Kopien der Datenbank in SYNCHRONIZED.

Die synchrone Operation wird wie folgt beibehalten:

  1. Beim Empfangen einer Transaktion von einem Client schreibt der Prinzipalserver das Protokoll für die Transaktion in das Transaktionsprotokoll.

  2. Der Prinzipalserver schreibt die Transaktion in die Datenbank und sendet den Protokolldatensatz gleichzeitig an den Spiegelserver. Der Hauptserver wartet auf eine Bestätigung vom Spiegelserver, bevor er dem Client eine der folgenden Aktionen bestätigt: ein Transaktionsabschluss oder ein Rollback.

  3. Der Spiegelserver schreibt das Protokoll fest auf die Festplatte und gibt eine Bestätigung an den Hauptserver zurück.

  4. Beim Empfangen der Bestätigung vom Spiegelserver sendet der Prinzipalserver eine Bestätigungsmeldung an den Client.

Der Hochsicherheitsmodus schützt Ihre Daten, indem die Daten zwischen zwei Orten synchronisiert werden müssen. Alle abgeschlossenen Transaktionen werden garantiert auf der Festplatte des Spiegelservers gespeichert.

High-Safety Modus ohne automatisches Failover

Die folgende Abbildung zeigt die Konfiguration des Hochsicherheitsmodus ohne automatisches Failover. Die Konfiguration besteht nur aus den beiden Partnern.

Partner kommunizieren ohne Zeuge

Wenn die Partner verbunden sind und die Datenbank bereits synchronisiert ist, wird manuelles Failover unterstützt. Wenn die Mirror Server Instanz ausfällt, ist die Principal Server Instanz nicht betroffen und läuft exponiert (d. h. ohne Spiegelung der Daten). Wenn der Hauptserver verloren geht, wird der Spiegel angehalten, der Dienst kann jedoch zum Spiegelserver umgeschaltet werden (mit möglichen Datenverlusten). Weitere Informationen finden Sie unter Rollenwechsel während einer Datenbankspiegelungssitzung (SQL Server).

High-Safety Modus mit automatischem Failover

Automatisches Failover bietet hohe Verfügbarkeit, indem sichergestellt wird, dass die Datenbank nach dem Verlust eines Servers noch bereitgestellt wird. Das automatische Failover erfordert, dass die Sitzung über eine dritte Serverinstanz verfügt, den Zeugen, der sich idealerweise auf einem dritten Computer befindet. Die folgende Abbildung zeigt die Konfiguration einer Sitzung mit hohem Sicherheitsmodus, die automatisches Failover unterstützt.

Der Zeuge und zwei Partner einer Sitzung

Im Gegensatz zu den beiden Partnern arbeitet der Zeuge nicht für die Datenbank. Der Zeuge unterstützt einfach das automatische Failover, indem er überprüft, ob der Prinzipalserver in Betrieb ist und funktioniert. Der Spiegelserver initiiert automatisches Failover nur, wenn der Spiegel und der Zeugen miteinander verbunden bleiben, nachdem beide vom Prinzipalserver getrennt wurden.

Wenn ein Zeuge festgelegt ist, erfordert die Sitzung ein Quorum - eine Beziehung zwischen mindestens zwei Serverinstanzen, die es der Datenbank ermöglichen, zugänglich gemacht zu werden. Weitere Informationen finden Sie unter Datenbankspiegelungszeuge und Quorum: Auswirkungen eines Zeugen auf die Datenbankverfügbarkeit (Datenbankspiegelung).

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

  • Die Datenbank ist bereits synchronisiert.

  • Der Fehler tritt auf, während alle drei Serverinstanzen verbunden sind, und der Zeugen-Server sowie der Spiegelserver bleiben verbunden.

Der Verlust eines Partners hat die folgende Wirkung:

  • Wenn der Prinzipalserver unter den oben genannten Bedingungen nicht verfügbar ist, tritt ein automatisches Failover auf. Der Spiegelserver wechselt zur Rolle des Prinzipals und bietet seine Datenbank als Prinzipaldatenbank an.

  • Wenn der Hauptserver nicht verfügbar ist und diese Bedingungen nicht erfüllt sind, könnte es möglich sein, den Dienst zwangsweise fortzusetzen, wobei mögliche Datenverluste auftreten können. Weitere Informationen finden Sie unter Rollenwechsel während einer Datenbankspiegelungssitzung (SQL Server).

  • Wenn der einzige Spiegelserver nicht verfügbar ist, werden Primär und Zeuge fortgesetzt.

Wenn die Sitzung ihren Zeugen verliert, erfordert quorum beide Partner. Wenn ein Partner das Quorum verliert, verlieren beide Partner das Quorum, und die Datenbank ist erst verfügbar, wenn das Quorum erneut eingerichtet wird. Diese Quorumsanforderung stellt sicher, dass die Datenbank bei Abwesenheit eines Zeugen nie ungeschützt ist, also ohne Spiegelung.

Hinweis

Wenn Sie erwarten, dass der Zeuge für einen erheblichen Zeitraum getrennt bleibt, empfehlen wir, den Zeugen aus der Sitzung zu entfernen, bis er verfügbar ist.

Transact-SQL-Einstellungen und Betriebsmodi der Datenbankspiegelung

In diesem Abschnitt wird eine Datenbankspiegelungssitzung in Bezug auf die ALTER DATABASE-Einstellungen und -Zustände der gespiegelten Datenbank und des Zeugen beschrieben, sofern vorhanden. Der Abschnitt richtet sich an Benutzer, die die Datenbankspiegelung hauptsächlich oder ausschließlich mithilfe von Transact-SQL verwalten, anstatt SQL Server Management Studio zu verwenden.

Tipp

Alternativ zur Verwendung von Transact-SQL können Sie den Betriebsmodus einer Sitzung im Objekt-Explorer mithilfe der Seite "Spiegelung " des Dialogfelds "Datenbankeigenschaften " steuern. Weitere Informationen finden Sie unter Einrichten einer Datenbank-Spiegelungssitzung mithilfe der Windows-Authentifizierung (SQL Server Management Studio).

Wie Transaktionssicherheit und Zeugenstatus den Betriebsmodus beeinflussen

Der Betriebsmodus einer Sitzung wird durch die Kombination seiner Transaktionssicherheitseinstellung und des Zustands des Zeugen bestimmt. Der Datenbankbesitzer kann jederzeit die Transaktionssicherheitsstufe ändern und den Zeugen hinzufügen oder entfernen.

Transaktionssicherheit

Transaktionssicherheit ist eine spiegelungsspezifische Datenbankeigenschaft, die bestimmt, ob eine Datenbankspiegelungssitzung synchron oder asynchron ausgeführt wird. Es gibt zwei Sicherheitsstufen: FULL und OFF.

  • SICHERHEIT VOLL

    Die vollständige Transaktionssicherheit bewirkt, dass die Sitzung synchron im Hochsicherheitsmodus ausgeführt wird. Wenn ein Zeugen vorhanden ist, unterstützt eine Sitzung das automatische Failover.

    Wenn Sie eine Sitzung mit ALTER DATABASE-Anweisungen einrichten, beginnt die Sitzung mit der SAFETY-Eigenschaft, die auf FULL festgelegt ist. d. h., die Sitzung beginnt im Hochsicherheitsmodus. Nachdem die Sitzung begonnen hat, können Sie einen Zeugen hinzufügen.

    Weitere Informationen finden Sie unter Synchrone Datenbankspiegelung (ModusHigh-Safety) weiter oben in diesem Abschnitt.

  • SICHERHEIT DEAKTIVIERT

    Das Deaktivieren der Transaktionssicherheit bewirkt, dass die Sitzung asynchron im Hochleistungsmodus ausgeführt wird. Wenn die SAFETY-Eigenschaft auf OFF festgelegt ist, sollte die WITNESS-Eigenschaft auch auf OFF (Standardeinstellung) festgelegt werden. Informationen zu den Auswirkungen des Zeugen im Hochleistungsmodus finden Sie im Status des Zeugen weiter unten in diesem Thema. Weitere Informationen zum Ausführen mit deaktivierter Transaktionssicherheit finden Sie weiter oben in diesem Thema unter "Asynchrone Datenbankspiegelung (High-Performance Modus)".

Die Transaktionssicherheitseinstellung der Datenbank wird auf jedem Partner in der sys.database_mirroring Katalogansicht in den Spalten mirroring_safety_level und mirroring_safety_level_desc aufgezeichnet. Weitere Informationen finden Sie unter sys.database_mirroring (Transact-SQL).

Der Datenbankbesitzer kann die Transaktionssicherheitsstufe jederzeit ändern.

Der Zustand des Zeugen

Wenn ein Zeuge festgelegt wurde, ist das Quorum erforderlich, sodass der Zustand des Zeugen immer wichtig ist.

Wenn es vorhanden ist, hat der Zeuge einen von zwei Zuständen:

  • Wenn der Zeuge mit einem Partner verbunden ist, befindet sich der Zeuge im VERBUNDENEN Zustand relativ zu diesem Partner und hat ein Quorum mit diesem Partner. In diesem Fall kann die Datenbank zur Verfügung gestellt werden, auch wenn einer der Partner nicht verfügbar ist.

  • Wenn der Zeuge existiert, aber nicht mit einem Partner verbunden ist, befindet sich der Zeuge im UNKOWN- oder DISCONNECTED-Zustand relativ zu diesem Partner. In diesem Fall fehlt dem Zeuge ein Quorum mit diesem Partner, und wenn die Partner nicht miteinander verbunden sind, wird die Datenbank nicht verfügbar.

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

Der Status jedes Zeugen in einer Serverinstanz wird in der sys.database_mirroring Katalogansicht in den spalten mirroring_witness_state und mirroring_witness_state_desc aufgezeichnet. Weitere Informationen finden Sie unter sys.database_mirroring (Transact-SQL).

In der folgenden Tabelle wird zusammengefasst, wie der Betriebsmodus einer Sitzung von der Einstellung für die Transaktionssicherheit und vom Status des Zeugen abhängt.

Betriebsmodus Transaktionssicherheit Zeugenstatus
Modus mit hoher Leistung AUS NULL (kein Zeugen)2
Hochsicherheitsmodus ohne automatisches Failover VOLL NULL (kein Zeuge)
Hochsicherheitsmodus mit automatischem Failover1 VOLL VERBUNDEN

1 Wenn die Verbindung zum Zeugen getrennt wird, empfehlen wir, ZEUGE DEAKTIVIEREN festzulegen, bis die Zeugenserverinstanz verfügbar ist.

2 Wenn ein Zeuge im Hochleistungsmodus vorhanden ist, nimmt der Zeuge nicht an der Sitzung teil. Um die Datenbank jedoch verfügbar zu machen, müssen mindestens zwei Serverinstanzen verbunden bleiben. Daher wird empfohlen, die WITNESS-Eigenschaft in Sitzungen im Hochleistungsmodus auf OFF einzustellen. Weitere Informationen finden Sie unter Quorum: Auswirkungen eines Zeugen auf die Datenbankverfügbarkeit (Datenbankspiegelung).

Anzeigen der Sicherheitseinstellungen und des Zustands des Zeugen

Um die Sicherheitseinstellung und den Status des Zeugen für eine Datenbank anzuzeigen, verwenden Sie die sys.database_mirroring Katalogansicht. Die relevanten Spalten sind wie folgt:

Faktor Spalten BESCHREIBUNG
Transaktionssicherheit mirroring_safety_level oder mirroring_safety_level_desc Transaktionssicherheitseinstellung für Aktualisierungen in der Spiegeldatenbank, einer von:

UNBEKANNT

AUS

VOLL

NULL= Datenbank ist nicht online.
Gibt es einen Zeugen? mirroring_witness_name Servername des Datenbankspiegelungszeugen oder NULL, der angibt, dass kein Zeuge vorhanden ist.
Zeugenstatus mirroring_witness_state oder mirroring_witness_state_desc Status des Zeugen in der Datenbank auf einem bestimmten Partner:

UNBEKANNT

VERBUNDEN

GETRENNT

NULL = kein Zeugen vorhanden ist oder die Datenbank nicht online ist.

Geben Sie beispielsweise auf dem Prinzipal- oder Spiegelserver Folgendes ein:

SELECT mirroring_safety_level_desc, mirroring_witness_name, mirroring_witness_state_desc FROM sys.database_mirroring

Weitere Informationen zu dieser Katalogansicht finden Sie unter sys.database_mirroring (Transact-SQL).

Faktoren, die das Verhalten beim Verlust des Prinzipalservers beeinflussen

In der folgenden Tabelle werden die kombinierten Auswirkungen der Transaktionssicherheitseinstellungen, der Status der Datenbank und der Status des Zeugen auf das Verhalten einer Spiegelungssitzung im Falle des Verlusts des Hauptservers zusammengefasst.

Transaktionssicherheit Spiegelungszustand der Spiegeldatenbank Zeugenstatus Verhalten beim Verlust des Hauptnutzers
VOLL SYNCHRONISIEREN VERBUNDEN Automatisches Failover tritt auf.
VOLL SYNCHRONISIEREN GETRENNT Spiegelserver stoppt; Failover ist nicht möglich, und die Datenbank kann nicht verfügbar gemacht werden.
AUS AUSGESETZT oder GETRENNT NULL (kein Zeuge) Der Dienst kann zum Spiegelserver gezwungen werden (mit möglichen Datenverlusten).
VOLL SYNCHRONISIEREN ODER ANGEHALTEN NULL (kein Zeuge) Der Dienst kann zum Spiegelserver gezwungen werden (mit möglichen Datenverlusten).

Verwandte Aufgaben

Siehe auch

Überwachen der Datenbankspiegelung (SQL Server)
Datenbankspiegelungszeuge

  • Last updated on