Übersicht über die Datenbankspiegelung

Artikel
12/15/2008

Aktualisiert: 05. Dezember 2005

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.

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

Die Datenbankspiegelung verwaltet zwei Kopien einer einzelnen Datenbank, die sich auf verschiedenen Instanzen von SQL Server-Datenbankmodul (Serverinstanzen) befinden müssen. In der Regel befinden sich diese Serverinstanzen auf Computern an verschiedenen Standorten. Eine Serverinstanz stellt Clients die Datenbank bereit (der Prinzipalserver), während die andere Serverinstanz als unmittelbar betriebsbereiter oder als betriebsbereiter Standbyserver dient (der Spiegelserver), abhängig von der Konfiguration und dem Status der Spiegelungssitzung. Wird eine Datenbank-Spiegelungssitzung 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 Server 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 zumindest beinahe 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".
Erhöht die Verfügbarkeit einer Datenbank.
Im Falle eines unvorhersehbaren Zwischenfalls wird im Modus für hohe Sicherheit mit automatischem Failover die Standbykopie der Datenbank vom Failover rasch online gebracht (ohne Datenverlust). 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 der Datenbank so kurz wie möglich zu halten, können Sie die Instanzen von SQL Server, die an einer Datenbank-Spiegelungssitzung teilnehmen, sequenziell aktualisieren, sodass nur eine Ausfallzeit eines einzelnen Failovers erzeugt wird. Diese Form der Aktualisierung wird als paralleles Update bezeichnet. Weitere Informationen finden Sie unter Gewusst wie: Installieren eines Service Packs auf einem System mit minimaler Ausfallzeit für gespiegelte Datenbanken.

Funktionsweise der Datenbankspiegelung

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 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 für die Spiegeldatenbank wiederholt. Diese Wiederholung erfolgt, indem jeder aktive Transaktionsprotokoll-Datensatz 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 physikalischen Protokolldatensatzes.

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, für die ein Commit ausgeführt wurde, auf beiden Partnern ein Commit ausgeführt, jedoch mit dem Risiko erhöhter Transaktionswartezeit.

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. Nachdem die Datenbanken synchronisiert wurden, wird für eine Transaktion, für die ein Commit ausgeführt wurde, auf beiden Partnern ein Commit ausgeführt, jedoch mit dem Risiko erhöhter Transaktionswartezeit.

Der zweite Betriebsmodus, der Modus für hohe Leistung, wird asynchron ausgeführt. Der Spiegelserver versucht, mit den Protokolldatensätzen Schritt zu halten, die vom Prinzipalserver gesendet werden. Die Spiegeldatenbank befindet sich dabei gegenüber der Prinzipaldatenbank möglicherweise etwas im Rückstand, aber die Differenz zwischen den Datenbanken ist normalerweise gering. Sie kann jedoch größer werden, wenn der Prinzipalserver stark ausgelastet ist oder wenn das System des Spiegelservers überlastet ist.

Sobald im Modus für hohe Leistung der Prinzipalserver einen Protokolldatensatz an den Spiegelserver sendet, wird vom Prinzipalserver eine Bestätigung an den Client gesendet, ohne auf eine Bestätigung vom Spiegelserver zu warten. 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. Ein solcher asynchroner Betrieb bewirkt, dass der Prinzipalserver mit minimaler Transaktionswartezeit ausgeführt werden kann, wobei jedoch das Risiko eines möglichen Datenverlustes besteht.

Alle Datenbank-Spiegelungssitzungen unterstützen nur einen Prinzipalserver und einen Spiegelserver. Die folgende Abbildung veranschaulicht diese Konfiguration.

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 einfach das automatische Failover, indem er überprüft, ob der Prinzipalserver betriebsbereit ist und funktioniert. 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".

Transaktionssicherheit und Betriebsmodi

Von der Transaktionssicherheitseinstellung ist abhängig, ob ein Betriebsmodus asynchron oder synchron ist. 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 Transact-SQL zum Konfigurieren der Datenbankspiegelung verwenden, müssen Sie mit den Einstellungen für die Transaktionssicherheit vertraut sein. 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.

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 nach dem Onlineschalten der neuen Prinzipaldatenbank die Clientanwendungen schnell wiederhergestellt werden, indem erneut eine Verbindung mit der Datenbank hergestellt wird.

Unterstützung der Datenbankspiegelung

Datenbankspiegelungspartner und -zeugen werden nur in SQL Server 2005 Standard Edition SP1 und höheren Versionen sowie in SQL Server 2005 Enterprise Edition SP1 und höheren Versionen unterstützt. Die Partner müssen jedoch die gleiche Version verwenden. Die asynchrone Datenbankspiegelung (Modus für hohe Leistung) wird nur in SQL Server 2005 Enterprise Edition SP1 und höheren Versionen unterstützt. Zeugen werden auch in SQL Server 2005 Workgroup Edition SP1 und höheren Versionen sowie in SQL Server 2005 Express Edition SP1 und höheren Versionen unterstützt.

Zugehörige Themen zur Datenbankspiegelung

Siehe auch

Andere Ressourcen

Herstellen von Clientverbindungen mit einer gespiegelten Datenbank
Datenbankspiegelung und weitere Features und Komponenten
sp_dbcmptlevel (Transact-SQL)

Hilfe und Informationen

Informationsquellen für SQL Server 2005