Übersicht über die Datenbankspiegelung

Die Datenbankspiegelung ist in erster Linie eine Softwarelösung zur Steigerung der Datenbankverfügbarkeit. Die Datenbankspiegelung wird auf Datenbankbasis implementiert und kann nur für Datenbanken herangezogen werden, die das vollständige Wiederherstellungsmodell verwenden. Die Datenbankspiegelung wird vom einfachen und vom massenprotokollierten Wiederherstellungsmodell nicht unterstützt. Daher werden alle Massenvorgänge immer vollständig protokolliert. Die Datenbankspiegelung funktioniert mit jedem unterstützten Datenbank-Kompatibilitätsgrad.

HinweisHinweis

Die Datenbanken master, msdb, tempdb oder model können nicht gespiegelt werden.

Die Datenbankspiegelung verwaltet zwei Kopien einer Datenbank, die sich auf verschiedenen Serverinstanzen von SQL Server Database Engine (Datenbankmodul) befinden müssen. In der Regel befinden sich diese Serverinstanzen auf Computern an verschiedenen Standorten. Eine Serverinstanz liefert die Daten der Datenbank an Clients (der Prinzipalserver). Die andere Instanz fungiert je nach Konfiguration und Status der Spiegelungssitzung als (unmittelbar) betriebsbereiter Standbyserver (der 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. Wird die Sitzung nicht synchronisiert, steht der Spiegelserver in der Regel als betriebsbereiter Standbyserver zur Verfügung (bei möglichem Datenverlust).

Vorteile der Datenbankspiegelung

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

  • 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 weiter unten in diesem Thema unter "Betriebsmodi".

    Ein Datenbankspiegelungspartner, der unter SQL Server 2008 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. Wenn die Anforderung erfolgreich ist, wird die nicht lesbare Seite durch die Kopie ersetzt. Dadurch kann der Fehler normalerweise behoben werden. Weitere Informationen finden Sie unter Automatische Seitenreparatur während einer Datenbank-Spiegelungssitzung.

  • 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".

  • Verbessert die Verfügbarkeit der Produktionsdatenbank bei Updates.

    Um die Ausfallzeit einer gespiegelten Datenbank zu minimieren, können Sie die an einer Datenbankspiegelungssitzung beteiligten Instanzen von SQL Server sequenziell aktualisieren. Auf diese Weise kommt es nur bei einem Failover zu einer Ausfallzeit. Diese Art des Upgrades wird als paralleles Upgrade bezeichnet. Weitere Informationen finden Sie unter Gewusst wie: Installieren eines Service Packs auf einem System mit minimaler Ausfallzeit der gespiegelten Datenbanken.

Funktionsweise der Datenbankspiegelung

Der Prinzipal- und der Spiegelserver kommunizieren und kooperieren als Partner in einer Datenbankspiegelungssitzung. 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 Prinzipalserver bezeichnet, und die Kopie der Datenbank ist die aktuelle Prinzipaldatenbank. Der Partner, der Besitzer der Spiegelrolle ist, wird als Spiegelserver bezeichnet, 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-, Aktualisierungs- 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 komprimiert der Prinzipalserver komprimiert den Datenstrom von Transaktionsprotokoll-Datensätzen vor dem Senden davon an den Spiegelserver. Diese Protokollkomprimierung erfolgt in allen Spiegelungssitzungen.

Betriebsmodi

Eine Datenbank-Spiegelungssitzung wird entweder im synchronen oder im asynchronen Betrieb 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. In dem einen Modus, dem Modus für hohe Sicherheit werden synchrone Vorgänge unterstützt. 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. Die Spiegeldatenbank hinkt eventuell hinter der Prinzipaldatenbank hinterher. 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. Der Prinzipalserver wartet dabei nicht auf eine Bestätigung des Spiegelservers. 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.

Partner in einer Datenbank-Spiegelungssitzung

Der Modus für hohe Sicherheit mit automatischem Failover erfordert eine dritte Serverinstanz, die als Zeuge bezeichnet wird. Im Gegensatz zu den beiden Partnern stellt der Zeuge die Datenbank nicht bereit. 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 Spiegelserver und der Zeuge auch nach dem Trennen vom Prinzipalserver miteinander verbunden bleiben.

Die folgende Abbildung zeigt eine Konfiguration mit einem Zeugen.

Spiegelungssitzung mit einem Zeugen

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

HinweisHinweis

Damit eine neue Spiegelungssitzung eingerichtet bzw. einer bestehenden Spiegelungskonfiguration ein Zeuge hinzugefügt werden kann, muss auf allen beteiligten Serverinstanzen dieselbe Version von SQL Server ausgeführt werden. Nach dem Upgrade auf SQL Server 2008 oder eine spätere Version können sich die Versionen der beteiligten Instanzen jedoch unterscheiden. Weitere Informationen finden Sie unter Vorgehensweise: Minimieren der Ausfallzeit von gespiegelten Datenbanken beim Aktualisieren von Serverinstanzen.

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 Transaktionssicherheitseinstellungen automatisch konfiguriert, wenn Sie den Betriebsmodus auswählen.

Wenn Sie die Datenbankspiegelung mit Transact-SQL konfigurieren, müssen Sie wissen, wie die Transaktionssicherheit eingestellt wird. Die Transaktionssicherheit wird durch die SAFETY-Eigenschaft der ALTER DATABASE-Anweisung gesteuert. Für eine Datenbank, die gespiegelt wird, ist SAFETY auf FULL oder OFF festgelegt.

  • Wurde die Option SAFETY auf FULL festgelegt, erfolgt die Datenbankspiegelung nach der anfänglichen Synchronisierungsphase im synchronen Betrieb. Wird ein Zeuge im Modus für hohe Sicherheit eingerichtet, unterstützt die Sitzung automatisches Failover.

  • Wurde die Option SAFETY auf OFF festgelegt, erfolgt die Datenbankspiegelung im asynchronen Betrieb. Die Sitzung wird im Modus für hohe Leistung ausgeführt, und die Option WITNESS sollte ebenfalls auf OFF festgelegt sein.

Weitere Informationen finden Sie unter Transact-SQL-Einstellungen und Datenbankspiegelungs-Betriebsmodi.

Rollenwechsel

Im Kontext einer Datenbank-Spiegelungssitzung können die Prinzipal- und Spiegelrollen normalerweise im Rahmen des so genannten Rollenwechsels ausgetauscht 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 die Verbindung zum Prinzipalserver verliert, der Zeuge jedoch 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.

    Wichtiger HinweisWichtig

    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.

Interoperabilität und Koexistenz mit anderen Datenbankmodulfunktionen

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

Unterstützung der Datenbankspiegelung

Seit SQL Server 2005 Service Pack 1 (SP1) werden Partner und Zeugen für Datenbankspiegelungen von der Standard und Enterprise Edition unterstützt. Die Partner müssen jedoch die gleiche Edition verwenden; die asynchrone Datenbankspiegelung (Hochleistungsmodus) wird nur von der Enterprise Edition unterstützt. Zeugen werden auch von der Workgroup und Express Edition unterstützt.