Verwenden der Datenbankspiegelung

Hinweis

Dieses Feature wird in einer künftigen Version von Microsoft SQL Server entfernt. 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 eingeführte Datenbankspiegelung ist eine Lösung zum Erhöhen der Datenbankverfügbarkeit und Datenredundanz. SQL Server Native Client bietet implizite Unterstützung für die Datenbankspiegelung, sodass der Entwickler nach der Konfiguration für die Datenbank keinen Code schreiben oder andere Aktionen ausführen muss.

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. SQL Server Native Client versucht nicht, ein Failover auf die Partnerdatenbank durchzuführen, wenn dies nicht geschehen ist.

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.

SQL Server Native Client OLE DB-Anbieter

Der SQL Server Native Client OLE DB-Anbieter unterstützt die Datenbankspiegelung über Verbindungs- und Verbindungszeichenfolgenattribute. Die SSPROP_INIT_FAILOVERPARTNER-Eigenschaft wurde dem DBPROPSET_SQLSERVERDBINIT-Eigenschaftensatz hinzugefügt, und das FailoverPartner-Schlüsselwort ist ein neues Verbindungszeichenfolgen-Attribut für DBPROP_INIT_PROVIDERSTRING. Weitere Informationen finden Sie unter Verwenden von Schlüsselwörtern für Verbindungszeichenfolgen mit SQL Server Native Client.

Der Failovercache wird so lange verwaltet, wie der Anbieter geladen wird, d. h. bis CoUninitialize aufgerufen wird, oder solange die Anwendung über einen Verweis auf ein Objekt verfügt, das vom SQL Server Native Client OLE DB-Anbieter verwaltet wird, z. B. ein Datenquellenobjekt.

Ausführliche Informationen zur Unterstützung SQL Server Native Client OLE DB-Anbieters für die Datenbankspiegelung finden Sie unter Initialisierungs- und Autorisierungseigenschaften.

ODBC-Treiber für SQL Server Native Client

Der SQL Server Native Client ODBC-Treiber unterstützt die Datenbankspiegelung über Verbindungs- und Verbindungszeichenfolgenattribute. Insbesondere wurde das attribut SQL_COPT_SS_FAILOVER_PARTNER für die Verwendung mit den Funktionen SQLSetConnectAttr und SQLGetConnectAttr hinzugefügt. und der Failover_Partner Schlüsselwort (keyword) wurde als neues Verbindungszeichenfolgen-Attribut hinzugefügt.

Der Failovercache wird beibehalten, solange der Anwendung mindestens ein Umgebungshandle zugeordnet ist. Umgekehrt geht er verloren, wenn die Zuordnung des letzten Umgebungshandles aufgehoben wird.

Hinweis

Der ODBC-Treiber-Manager wurde verbessert, um die Spezifikation des Failoverservernamens zu unterstützen.

Weitere Informationen

SQL Server Native Client-Funktionen
Verbinden von Clients mit einer Datenbank-Spiegelungssitzung (SQL Server)
Datenbankspiegelung (SQL Server)