Verwenden der Datenbankspiegelung
Gilt für: 
SQL Server
Hinweis
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 stattdessen Always On-Verfügbarkeitsgruppen.
Die in SQL Server 2005 (9.x) eingeführte Datenbankspiegelung ist eine Lösung zum Erhöhen der Datenbankverfügbarkeit und Datenredundanz. Der OLE DB-Treiber für SQL Server stellt implizite Unterstützung für die Datenbankspiegelung bereit, weshalb Entwickler weder Code schreiben noch andere Aktionen ausführen müssen, nachdem sie für die Datenbank konfiguriert wurde.
Bei einer Datenbankspiegelung, die für Datenbanken einzeln implementiert wird, befindet sich eine Kopie einer SQL Server-Produktionsdatenbank auf einem Standbyserver. Bei dem Server handelt es sich je nach Konfiguration und Status der Datenbankspiegelungs-Sitzung um einen unmittelbar betriebsbereiten oder einfach betriebsbereiten Standbyserver. Ein unmittelbar betriebsbereiter Standbyserver unterstützt schnelles Failover ohne Verlust von Transaktionen mit ausgeführtem Commit, und ein betriebsbereiter Standbyserver unterstützt das Erzwingen eines Diensts (bei möglichem Datenverlust).
Die Produktionsdatenbank wird Prinzipaldatenbank genannt. Die Standbykopie wird Spiegeldatenbank genannt. Die Prinzipaldatenbank und die Spiegeldatenbank müssen sich auf unterschiedlichen Instanzen von SQL Server (Serverinstanzen) befinden und sollten sich nach Möglichkeit auch auf unterschiedlichen Computern befinden.
Die Produktionsserverinstanz, die als Prinzipalserver bezeichnet wird, kommuniziert mit der Standbyserverinstanz, dem so genannten Spiegelserver. Der Prinzipal- und der Spiegelserver agieren in einer Datenbankspiegelungs-Sitzung als Partner. Wenn der Prinzipalserver ausfällt, kann der Spiegelserver seine Datenbank über einen so genannten Failover als Prinzipaldatenbank bestimmen. Beispiel: Partner_A und Partner_B sind zwei Partnerserver. Die Prinzipaldatenbank befindet sich anfänglich auf dem Prinzipalserver Partner_A und die Spiegeldatenbank auf dem Spiegelserver Partner_B. Wenn Partner_A offline geht, kann die Datenbank auf Partner_B ein Failover ausführen, um zur aktuellen Prinzipaldatenbank zu werden. Sobald Partner_A wieder mit der Sitzung verbunden ist, übernimmt er wieder die Rolle des Spiegelservers und seine Datenbank wird zur Spiegeldatenbank.
Alternative Konfigurationen für die Datenbankspiegelung bieten unterschiedliche Leistungs- und Datensicherheitsstufen und unterstützen unterschiedliche Formen des Failover. Weitere Informationen finden Sie unter Datenbankspiegelung (SQL Server).
Beim Angeben des Spiegeldatenbanknamens ist es möglich, einen Alias zu verwenden.
Hinweis
Informationen über Versuche des Erstverbindungsaufbaus sowie Versuche der erneuten Verbindung mit einer Spiegeldatenbank finden Sie unter Verbinden von Clients mit einer Datenbankspiegelungssitzung (SQL Server).
Überlegungen zur Programmierung
Wenn auf dem Prinzipaldatenbankserver ein Fehler auftritt, empfängt die Clientanwendung als Antwort auf API-Aufrufe Fehlermeldungen. Dadurch wird angezeigt, dass die Verbindung zur Datenbank unterbrochen ist. Wenn dieser Fall eintritt, gehen alle Datenbankänderungen, für die kein Commit ausgeführt wurde, verloren und für die aktuelle Transaktion wird ein Rollback durchgeführt. Dann sollte die Anwendung die Verbindung beenden (oder das Datenquellobjekt freigeben) und erneut herstellen. Die Verbindung wird transparent zur Spiegeldatenbank umgeleitet, die jetzt als Prinzipalserver fungiert.
Wenn eine Verbindung hergestellt wurde, teilt der Prinzipalserver die Identität seines Failoverpartners, der bei einem Failover einspringt, dem Client mit. Wenn eine Anwendung versucht, nach dem Failover des Prinzipalservers eine Verbindung aufzubauen, kennt der Client die Identität des Failoverpartners nicht. Um Clients die Möglichkeit zu geben, in dieser Situation Abhilfe zu schaffen, können sie die Identität des Failoverpartners mithilfe einer Initialisierungseigenschaft und eines zugeordneten Schlüsselworts für die Verbindungszeichenfolge selbst angeben. Das Clientattribut wird nur in dieser Situation verwendet; wenn der Prinzipalserver verfügbar ist, wird es nicht verwendet. Wenn der vom Client angegebene Failoverpartnerserver nicht auf einen Server verweist, der als Failoverpartner fungiert, wird die Verbindung vom Server abgewiesen. Um es Anwendungen zu ermöglichen, sich an Konfigurationsänderungen anzupassen, kann die Identität des tatsächlichen Failoverpartners durch Überprüfung des Attributs nach dem Verbindungsaufbau bestimmt werden. Sie sollten die Partnerinformationen zwischenspeichern, um die Verbindungszeichenfolge zu aktualisieren, oder eine Wiederholungsstrategie für den Fall entwerfen, dass der erste Versuch des Verbindungsaufbaus fehlschlägt.
Hinweis
Sie müssen die von einer Verbindung zu verwendende Datenbank explizit angeben, wenn Sie diese Funktion in einem DSN, einer Verbindungszeichenfolge oder einer/m Verbindungseigenschaft/-attribut verwenden möchten. Der OLE DB-Treiber für SQL Server versucht sonst nicht, bei einem Fehler zur Partnerdatenbank zu wechseln.
Die Spiegelung ist eine Funktion der Datenbank. Anwendungen, die mehrere Datenbanken verwenden, sind möglicherweise nicht in der Lage, diese Funktion zu nutzen.
Außerdem erfolgt bei den Servernamen keine Unterscheidung nach Groß-/Kleinschreibung, bei Datenbanknamen jedoch schon. Sie müssen daher auf die Übereinstimmung der Groß-/Kleinschreibung in DSNs und Verbindungszeichenfolgen achten.
OLE DB-Treiber für SQL Server
Der OLE DB-Treiber für SQL Server unterstützt die Datenbankspiegelung durch Attribute für Verbindungen und Verbindungszeichenfolgen. Die Eigenschaft SSPROP_INIT_FAILOVERPARTNER wurde dem DBPROPSET_SQLSERVERDBINIT-Eigenschaftensatz hinzugefügt, und das Schlüsselwort FailoverPartner ist ein neues Verbindungszeichenfolgen-Attribut für DBPROP_INIT_PROVIDERSTRING. Weitere Informationen finden Sie unter Verwenden von Schlüsselwörtern für Verbindungszeichenfolgen mit dem OLE DB-Treiber für SQL Server.
Der Failovercache wird aufrechterhalten, solange der Anbieter geladen wird, also bis CoUninitialize aufgerufen wird, oder solange die Anwendung über einen Verweis auf ein vom OLE DB-Treiber für SQL Server verwaltetes Objekt, wie z.B. ein Datenquellobjekt, verfügt.
Ausführliche Informationen zur Unterstützung des OLE DB-Treibers für SQL Server für die Datenbankspiegelung finden Sie unter Initialisierungs- und Autorisierungseigenschaften.
Weitere Informationen
OLE DB-Treiber für SQL Server-Features
Verbinden von Clients mit einer Datenbank-Spiegelungssitzung (SQL Server)
Datenbankspiegelung (SQL Server)