Freigeben über

Datenbankspiegelung (SQL Server)

Gilt für:SQL Server

Vorsicht

Diese Funktion wird in einer zukünftigen Version von SQL Serverentfernt. Nutzen Sie diese Funktionen bei Neuentwicklungen nicht mehr, und planen Sie die Änderung von Anwendungen, die diese Funktion zurzeit verwenden. Verwenden Sie für hohe Verfügbarkeit stattdessen AlwaysOn-Verfügbarkeitsgruppen.

Wichtig

Datenbankspiegelung in SQL Server ist nicht dasselbe wie die Datenbankspiegelung in Microsoft Fabric. Die Spiegelung in Fabric bietet eine bessere analytische Leistung, die Möglichkeit, Ihren Datenbestand mit OneLake in Fabric zu vereinheitlichen und offenen Zugriff auf Ihre Daten im Delta-Parquet-Format.

Mit dem Feature "Mirroring to Microsoft Fabric" können Sie Ihren vorhandenen Datenbestand kontinuierlich direkt in OneLake in Fabric replizieren, einschließlich Daten aus SQL Server 2016+, Azure SQL-Datenbank, Azure SQL Managed Instance, Cosmos DB, Oracle, Snowflake und weiteren Datenbanken.

Die Datenbankspiegelung ist eine Lösung zum Verbessern der Verfügbarkeit einer SQL Server-Datenbank. Die Datenbankspiegelung wird auf Datenbankbasis implementiert und ist nur für Datenbanken mit dem vollständigen Wiederherstellungsmodell geeignet.

Informationen zur Unterstützung der Datenbankspiegelung, zu Einschränkungen, zu Voraussetzungen und zu Empfehlungen für die Konfiguration von Partnerservern sowie für die Bereitstellung der Datenbankspiegelung finden Sie unter Voraussetzungen, Einschränkungen und Empfehlungen für die Datenbankspiegelung.

Vorteile der Datenbankspiegelung

Die Datenbankspiegelung ist eine einfache Strategie, die folgende Vorteile bietet:

  • Erhöht die Verfügbarkeit einer Datenbank.

    Im Falle eines unvorhersehbaren Zwischenfalls wird beim Modus für hohe Sicherheit mit automatischem Failover die Standbykopie der Datenbank (ohne Datenverlust) rasch online gebracht. In den anderen Betriebsmodi hat der Datenbankadministrator die Möglichkeit, den Dienst (mit möglichem Datenverlust) für die Standbykopie der Datenbank zu erzwingen. Weitere Informationen finden Sie weiter unten in diesem Thema unter Rollenwechsel.

  • Erhöht den Datenschutz.

    Die Datenbankspiegelung bietet eine vollständige oder nahezu vollständige Datenredundanz, abhängig davon, ob es sich beim Betriebsmodus um den Modus für hohe Sicherheit oder den Modus für hohe Leistung handelt. Weitere Informationen finden Sie später in diesem Thema unter Betriebsmodi.

    Ein Datenbankspiegelungspartner, der in SQL Server 2008 (10.0.x) Enterprise oder einer höheren Version ausgeführt wird, versucht automatisch, bestimmte Fehlertypen zu beheben, die das Lesen einer Datenseite verhindern. Der Partner, der eine Seite nicht lesen kann, fordert vom anderen Partner eine neue Kopie an. Ist diese Anforderung erfolgreich, wird die nicht lesbare Seite durch die Kopie ersetzt. Dadurch kann der Fehler normalerweise behoben werden. Weitere Informationen finden Sie unter Automatische Seitenreparatur (Verfügbarkeitsgruppen: Datenbankspiegelung).

  • Verbessert die Verfügbarkeit der Produktionsdatenbank bei Upgrades.

    Um Ausfallzeiten für eine gespiegelte Datenbank zu minimieren, können Sie für die SQL Server-Instanzen, auf denen die Failoverpartner gehostet werden, nacheinander ein Upgrade ausführen. Auf diese Weise kommt es nur bei einem Failover zu einer Ausfallzeit. Diese Art des Upgrades wird als paralleles Upgradebezeichnet. Weitere Informationen finden Sie unter Upgrading Mirrored Instances.

Begriffe und Definitionen zur Datenbankspiegelung

Automatisches Failover

Entspricht dem Prozess, bei dem im Fall eines Ausfalls des Prinzipalservers der Spiegelserver die Rolle des Prinzipalservers übernimmt und die zugehörige Kopie der Datenbank als Prinzipaldatenbank online zur Verfügung gestellt wird.

Failoverpartner

Entspricht den zwei Serverinstanzen (Prinzipalserver bzw. Spiegelserver), die als Rollenwechselpartner für eine gespiegelte Datenbank fungieren.

Erzwungener Dienst

Ein Failover, das vom Datenbankbesitzer beim Fehler des Prinzipalservers initiiert wird, der den Dienst in die Spiegeldatenbank überträgt, während er sich in einem unbekannten Zustand befindet.

Modus mit hoher Leistung

Die Sitzung für die Datenbankspiegelung erfolgt asynchron und verwendet nur den Prinzipalserver und Spiegelserver. Die einzige Art des Rollenwechsels ist der erzwungene Dienst (mit möglichem Datenverlust).

Modus für hohe Sicherheit

Die Sitzung für die Datenbankspiegelung erfolgt synchron und verwendet optional einen Zeugen sowie den Prinzipalserver und Spiegelserver.

Manuelles Failover

Entspricht einem Failover, das vom Datenbankbesitzer initiiert wird, während der Prinzipalserver weiter ausgeführt wird, und das Dienste von der Prinzipaldatenbank an die Spiegeldatenbank überträgt, während die beiden Datenbanken in synchronisiertem Zustand sind.

Spiegeldatenbank

Steht für die Kopie der Datenbank, die in der Regel vollständig mit der Prinzipaldatenbank synchronisiert wird.

Spiegelserver

Entspricht in einer Datenbank-Spiegelungskonfiguration der Serverinstanz, auf der sich die Spiegeldatenbank befindet.

Prinzipaldatenbank

Steht im Fall der Datenbankspiegelung für eine Datenbank mit Lese-/Schreibzugriff, deren Transaktionsprotokoll-Datensätze für eine schreibgeschützte Datenbankkopie (eine Spiegeldatenbank) übernommen werden.

Prinzipalserver

Bei der Datenbankspiegelung der Partner, dessen Datenbank derzeit die Prinzipaldatenbank ist.

Redo queue

Steht für empfangene Transaktionsprotokoll-Datensätze, die auf dem Datenträger eines Spiegelservers warten.

Rolle

Der Prinzipalserver und Spiegelserver führen komplementäre Prinzipal- und Spiegelungsrollen aus. Von einer dritten Serverinstanz wird optional die Rolle des Zeugen übernommen.

Rollenwechsel

Entspricht der Übernahme der Prinzipalrolle durch den Spiegelserver.

Warteschlange senden

Entspricht nicht gesendeten Transaktionsprotokoll-Datensätzen, die auf dem Protokolldatenträger des Prinzipalservers gesammelt wurden.

Session

Entspricht der Beziehung, die bei der Datenbankspiegelung zwischen dem Prinzipalserver, Spiegelserver und ggf. dem Zeugenserver (sofern vorhanden) auftritt.

Entspricht nach dem Start oder Fortsetzen einer Spiegelungssitzung dem Prozess, durch den Protokolldatensätze der Prinzipaldatenbank, die sich auf dem Prinzipalserver angesammelt haben, an den Spiegelserver gesendet werden. Der Spiegelserver schreibt diese Protokolldatensätze so schnell wie möglich auf den Datenträger, um wieder auf den Stand des Prinzipalservers zu kommen.

Transaktionssicherheit

Entspricht einer spiegelungsspezifischen Datenbankeigenschaft, die bestimmt, ob eine Datenbank-Spiegelungssitzung synchron oder asynchron ausgeführt wird. Es gibt zwei Sicherheitsstufen: FULL und OFF.

Zeuge

Ist nur für den Modus mit hoher Sicherheit bestimmt und entspricht einer optionalen SQL Server-Instanz, durch die der Spiegelserver den Zeitpunkt für die Initiierung eines automatischen Failovers erkennen kann. Im Gegensatz zu den beiden Failoverpartnern dient der Zeuge nicht der Datenbank. Die Unterstützung des automatischen Failovers ist die einzige Aufgabe des Zeugen.

Übersicht über die Datenbankspiegelung

Die Datenbankspiegelung verwaltet zwei Kopien einer einzelnen Datenbank, die sich in verschiedenen Instanzen des SQL Server-Datenbankmoduls befinden. In der Regel befinden sich diese Instanzen auf Computern an unterschiedlichen Speicherorten. Beim Starten der Datenbankspiegelung initiiert eine Instanz eine Beziehung, die als Datenbankspiegelungssitzung bezeichnet wird, mit einer anderen Instanz.

Eine Serverinstanz liefert die Daten der Datenbank an Clients. Dies ist der Prinzipalserver. Die andere Instanz fungiert je nach Konfiguration und Status der Spiegelungssitzung als (unmittelbar) betriebsbereiter Standbyserver ( Spiegelserver). Wird eine Datenbankspiegelungssitzung synchronisiert, stellt die Datenbankspiegelung einen unmittelbar betriebsbereiten Standbyserver bereit, der schnelle Failover unterstützt, ohne dass Daten aus Transaktionen, für die ein Commit ausgeführt wurde, verloren gehen. Wenn die Sitzung nicht synchronisiert wird, ist der Spiegelserver in der Regel als warmer Standbyserver (mit möglichen Datenverlusten) verfügbar.

Der Prinzipal- und der Spiegelserver kommunizieren und kooperieren als Partner in einer Datenbank-Spiegelungssitzung. Die beiden Partner führen sich ergänzende Rollen für die Sitzung aus: die Prinzipalrolle und die Spiegelrolle. Ein Partner übernimmt jeweils die Prinzipalrolle und ein anderer Partner die Spiegelrolle. Jeder Partner wird als Besitzer seiner aktuellen Rolle beschrieben. Der Partner, der Besitzer der Prinzipalrolle ist, wird als Prinzipalserverbezeichnet, und die Kopie der Datenbank ist die aktuelle Prinzipaldatenbank. Der Partner, der Besitzer der Spiegelrolle ist, wird als Spiegelserverbezeichnet, und die Kopie der Datenbank ist die aktuelle Spiegeldatenbank. Wird die Datenbankspiegelung in einer Produktionsumgebung bereitgestellt, ist die Prinzipaldatenbank die Produktionsdatenbank.

Bei der Datenbankspiegelung wird jeder Einfüge-, Update- und Löschvorgang, der für die Prinzipaldatenbank ausgeführt wird, so schnell wie möglich in der Spiegeldatenbank wiederholt . Diese Wiederholung erfolgt, indem ein Datenstrom von aktiven Transaktionsprotokoll-Datensätzen an den Spiegelserver gesendet wird, der die Protokolldatensätze der Reihe nach und so schnell wie möglich auf die Spiegeldatenbank anwendet. Im Gegensatz zur Replikation, die auf der logischen Ebene erfolgt, erfolgt die Datenbankspiegelung auf der Ebene des physischen Protokolldatensatzes. Ab SQL Server 2008 (10.0.x) komprimiert der Prinzipalserver den Datenstrom der Transaktionsprotokoll-Datensätze, bevor der Datenstrom an den Spiegelserver gesendet wird. Diese Protokollkomprimierung erfolgt in allen Spiegelungssitzungen.

Hinweis

Eine Serverinstanz kann an mehreren gleichzeitigen Datenbank-Spiegelungssitzungen mit den gleichen oder anderen Partnern teilnehmen. Eine Serverinstanz kann bei manchen Sitzungen als Partner und bei anderen Sitzungen als Zeuge dienen. Die Spiegelserverinstanz muss die gleiche Edition von SQL Server ausführen.

In diesem Abschnitt:

Betriebsmodi

Eine Datenbank-Spiegelungssitzung wird entweder im synchron oder asynchron ausgeführt. Im asynchronen Betrieb wird für die Transaktionen ein Commit ausgeführt, ohne darauf zu warten, dass der Spiegelserver das Protokoll auf den Datenträger schreibt, wodurch die Leistung maximiert wird. Im synchronen Betrieb wird für eine Transaktion auf beiden Partnern ein Commit ausgeführt, jedoch mit dem Risiko einer erhöhten Transaktionslatenzzeit.

Es existieren zwei Betriebsmodi für die Datenbankspiegelung. Einer der Modi, der Modus für hohe Sicherheit unterstützt synchrone Vorgänge. Zu Beginn einer Sitzung im Modus für hohe Sicherheit synchronisiert der neue Spiegelserver die neue Spiegeldatenbank so schnell wie möglich mit der Prinzipaldatenbank. Sobald die Datenbanken synchronisiert wurden, wird für eine Transaktion auf beiden Partnern ein Commit ausgeführt, jedoch mit dem Risiko einer erhöhten Transaktionslatenzzeit.

Der zweite Betriebsmodus, der Modus für hohe Leistung, wird asynchron ausgeführt. Der Spiegelserver versucht, mit den Protokolldatensätzen, die vom Prinzipalserver gesendet werden, Schritt zu halten. Bei der Spiegeldatenbank kann im Vergleich zur Prinzipaldatenbank zu etwas Verzögerung auftreten. Der Abstand zwischen den beiden Datenbanken ist jedoch im Allgemeinen sehr klein. Er kann jedoch erheblich größer werden, wenn der Prinzipalserver stark ausgelastet ist oder wenn das System des Spiegelservers überlastet ist.

Sobald der Prinzipalserver im Modus für hohe Leistung einen Protokolldatensatz an den Spiegelserver sendet, wird vom Prinzipalserver eine Bestätigung an den Client gesendet. Es wartet nicht auf eine Bestätigung vom Spiegelserver. Dies bedeutet, dass für die Transaktionen ein Commit ausgeführt wird, ohne darauf zu warten, dass der Spiegelserver das Protokoll auf den Datenträger schreibt. Dieser asynchrone Betrieb bewirkt, dass der Prinzipalserver mit minimaler Transaktionslatenzzeit ausgeführt werden kann, wobei jedoch das Risiko eines möglichen Datenverlustes besteht.

Alle Datenbank-Spiegelungssitzungen unterstützen nur einen Prinzipalserver und einen Spiegelserver. Diese Konfiguration wird in der folgenden Abbildung dargestellt.

Screenshot von Partnern in einer Datenbankspiegelungssitzung.

Der Modus für hohe Sicherheit mit automatischem Failover erfordert eine dritte Serverinstanz, die als Zeugebezeichnet wird. Im Gegensatz zu den beiden Partnern dient der Zeuge nicht der Datenbank. Der Zeuge unterstützt das automatische Failover dadurch, dass er überprüft, ob der Prinzipalserver aktiv und funktionsfähig ist. Der Spiegelserver initiiert das automatische Failover nur, wenn der Spiegel und der Zeuge miteinander verbunden bleiben, nachdem beide vom Prinzipalserver getrennt wurden.

Die folgende Abbildung zeigt eine Konfiguration mit einem Zeugen.

Screenshot einer Spiegelungssitzung, die einen Zeugen enthält.

Weitere Informationen finden Sie weiter unten in diesem Thema unter Rollenwechsel.

Hinweis

Damit eine neue Spiegelungssitzung eingerichtet oder einer bestehenden Spiegelungskonfiguration ein Zeuge hinzugefügt werden kann, muss auf allen beteiligten Serverinstanzen dieselbe Version von SQL Server ausgeführt werden. Wenn Sie jedoch ein Upgrade auf SQL Server 2008 (10.0.x) oder eine höhere Version durchführen, können die Versionen der beteiligten Instanzen variieren. Weitere Informationen finden Sie unter Upgrading Mirrored Instances.

Transaktionssicherheit und Betriebsmodi

Ob ein Betriebsmodus asynchron oder synchron ist, hängt von der Transaktionssicherheitseinstellung ab. Wenn Sie ausschließlich SQL Server Management Studio zum Konfigurieren der Datenbankspiegelung verwenden, werden die Einstellungen für die Transaktionssicherheit automatisch konfiguriert, wenn Sie den Betriebsmodus auswählen.

Wenn Sie die Datenbankspiegelung mit Transact-SQL konfigurieren, müssen Sie wissen, wie die Transaktionssicherheit eingerichtet wird. Transaktionssicherheit wird durch die SAFETY Eigenschaft der ALTER DATABASE Anweisung gesteuert. In einer Datenbank, die gespiegelt wird, SAFETY ist entweder FULL oder OFF.

  • Wenn die Option auf "FULL" festgelegt ist, ist der SAFETY Datenbankspiegelungsvorgang synchron, nach der ersten Synchronisierungsphase. Wird ein Zeuge im Modus für hohe Sicherheit eingerichtet, unterstützt die Sitzung automatisches Failover.

  • Wenn die Option auf ist, ist der Datenbankspiegelungsvorgang asynchron. Die Sitzung wird im Hochleistungsmodus ausgeführt, und die WITNESS Option sollte ebenfalls sein OFF.

Weitere Informationen finden Sie unter Database Mirroring Operating Modes.

Rollenwechsel

Im Kontext einer Datenbank-Spiegelungssitzung können die Prinzipal- und Spiegelrollen normalerweise im Rahmen des so genannten Rollenwechselsausgetauscht werden. Beim Rollenwechsel wird die Prinzipalrolle auf den Spiegelserver übertragen. Der Spiegelserver dient beim Rollenwechsel als Failoverpartner für den Prinzipalserver. Wenn ein Rollenwechsel stattfindet, übernimmt der Spiegelserver die Prinzipalrolle und schaltet seine Kopie der Datenbank als neue Prinzipaldatenbank online. Der ehemalige Prinzipalserver übernimmt, falls er verfügbar ist, die Spiegelrolle, und die zugehörige Datenbank wird zur neuen Spiegeldatenbank. Potenziell können die Rollen wiederholt hin- und hergewechselt werden.

Es stehen die folgenden drei Arten des Rollenwechsels zur Verfügung:

  • Automatisches Failover

    Voraussetzung dafür sind der Modus für hohe Sicherheit und die Präsenz des Spiegelservers und eines Zeugen. Die Datenbank muss bereits synchronisiert worden sein, und der Zeuge muss mit dem Spiegelserver verbunden sein.

    Aufgabe des Zeugen ist es, zu überprüfen, ob ein bestimmter Partnerserver betriebsbereit ist und funktioniert. Wenn der Spiegelserver seine Verbindung mit dem Prinzipalserver verliert, der Zeuge aber weiterhin mit dem Prinzipalserver verbunden ist, initiiert der Spiegelserver kein Failover. Weitere Informationen finden Sie unter Datenbank-Spiegelungszeuge.

  • Manuelles Failover

    Voraussetzung ist der Modus für hohe Sicherheit. Die Partner müssen miteinander verbunden sein, und die Datenbank muss bereits synchronisiert worden sein.

  • Erzwungener Dienst (mit möglichem Datenverlust)

    Das Erzwingen des Diensts ist im Modus für hohe Leistung und im Modus für hohe Sicherheit mit automatischem Failover möglich, wenn ein Ausfall des Prinzipalserver aufgetreten ist und der Spiegelserver zur Verfügung steht.

    Wichtig

    Der Modus für hohe Leistung wurde so konzipiert, dass er ohne einen Zeugen ausgeführt werden kann. Ist jedoch ein Zeuge vorhanden, muss dieser mit dem Spiegelserver verbunden sein, damit der Dienst erzwungen werden kann.

In einem Rollenwechselszenario können die Clientanwendungen schnell wiederhergestellt werden, nachdem die neue Prinzipaldatenbank online geschaltet wurde, indem erneut eine Verbindung mit der Datenbank hergestellt wird.

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_2und 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 Partner Partner
SSInstance_2 Partner Zeuge Partner Partner
SSInstance_3 Partner Partner 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_1und die andere für eine Datenbank namens Db_2ausgeführt.

Screenshot von 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, die sowohl als Partner als auch als Zeugen ausgeführt werden soll, sicher, dass der Endpunkt für die Datenbankspiegelung beide Rollen unterstützt (weitere Informationen finden Sie unter Dem Datenbankspiegelungsendpunkt (SQL Server)). 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, können Datenbanken nicht als Gruppe fehlschlagen.

Clientverbindungen

Unterstützung für Clientverbindungen für Sitzungen mit Datenbankspiegelung wird vom Microsoft .NET-Datenanbieter für SQL Server bereitgestellt. Weitere Informationen finden Sie unter Verbinden von Clients mit einer Datenbankspiegelungs-Sitzung (SQL Server).

Auswirkungen des Anhaltens einer Sitzung auf das Prinzipaltransaktionsprotokoll

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 Protokolleinträge an den Spiegelserver. Alle diese Datensätze bleiben aktiv und werden im Transaktionsprotokoll der Prinzipaldatenbank gesammelt. Solange eine Datenbankspiegelungssitzung angehalten bleibt, 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 (SQL Server).

Einrichten der Datenbankspiegelungssitzung

Vor dem Beginn einer Spiegelungssitzung 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 (SQL Server).

Interoperabilität und Koexistenz mit anderen Datenbank-Engine-Funktionen

Die Datenbankspiegelung kann mit den folgenden Funktionen oder Komponenten von SQL Server verwendet werden.

In diesem Abschnitt

Voraussetzungen, Einschränkungen und Empfehlungen für die Datenbankspiegelung Beschreibt die Voraussetzungen und Empfehlungen zum Einrichten der Datenbankspiegelung.

Betriebsmodi für Datenbankspiegelung Enthält Informationen zu den synchronen und asynchronen Betriebsmodi für Datenbankspiegelungssitzungen und zum Wechseln von Partnerrollen während einer Datenbankspiegelungssitzung.

Datenbankspiegelungszeuge Beschreibt die Rolle eines Zeugen bei der Datenbankspiegelung, die Verwendung eines einzelnen Zeugen in mehreren Spiegelungssitzungen, Software- und Hardwareempfehlungen für Zeugen und die Rolle des Zeugen im automatischen Failover. Zudem sind auch Informationen zum Hinzufügen oder Entfernen eines Zeugen enthalten.

Rollenwechsel während einer Datenbankspiegelungssitzung (SQL Server) Enthält Informationen zum Wechseln von Partnerrollen während einer Datenbankspiegelungssitzung, einschließlich automatischem Failover, manuellem Failover und erzwungenem Dienst (mit möglichen Datenverlusten). Außerdem sind Informationen zur Einschätzung der Dienstunterbrechung beim Rollenwechsel enthalten.

Mögliche Fehler während der Datenbankspiegelung Erläutert physische, Betriebssystem- und SQL Server-Probleme, einschließlich schwerer Fehler und weicher Fehler, die zu einem Fehler in einer Datenbankspiegelungssitzung führen können. Erläutert, wie der Spiegelungstimeoutmechanismus auf Softwarefehler reagiert.

Der Datenbankspiegelungsendpunkt (SQL Server) Erläutert, wie der Endpunkt der Datenbankspiegelung funktioniert.

Einrichten der Datenbankspiegelung (SQL Server) Enthält Themen zu den Voraussetzungen, Empfehlungen und Schritten zum Einrichten der Datenbankspiegelung.

Verbinden von Clients mit einer Datenbankspiegelungssitzung (SQL Server) Enthält Themen, die Clientverbindungszeichenfolgenattribute und die Algorithmen zum Verbinden und erneuten Verbinden eines Clients mit einer gespiegelten Datenbank abdecken.

Anhalten und Fortsetzen der Datenbankspiegelung (SQL Server) Erläutert, was passiert, während die Datenbankspiegelung angehalten wird, einschließlich der Auswirkungen auf den Transaktionsprotokollabkürzung, und enthält Beschreibungen zum Anhalten und Fortsetzen der Datenbankspiegelung.

Entfernen der Datenbankspiegelung (SQL Server) Erläutert die Auswirkungen des Entfernens der Spiegelung und enthält Beschreibungen zum Beenden einer Sitzung.

Überwachen der Datenbankspiegelung (SQL Server) Enthält Informationen zur Verwendung des Datenbankspiegelungsmonitors oder der gespeicherten Prozeduren des Dbmmonitors zum Überwachen der Datenbankspiegelung oder -sitzungen.

Konfigurationstasks

Verwendung von SQL Server Management Studio

Verwenden von Transact-SQL

Verwenden von Transact-SQL oder SQL Server Management Studio

Verwaltungsaufgaben

Transact-SQL

SQL Server Management Studio

Verwandte Inhalte

  • Last updated on