Verwenden der Datenbankspiegelung

Hinweis
Diese Funktion wird in zukünftigen Versionen von Microsoft SQL Server nicht mehr bereitgestellt. Verwenden Sie diese Funktion beim Entwickeln neuer Anwendungen nicht, und planen Sie das Ändern von Anwendungen, in denen es zurzeit verwendet wird. Verwenden Sie stattdessen AlwaysOn-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 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.

Die Datenbankspiegelung wird auf Datenbankbasis implementiert und verfügt über 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 als Prinzipaldatenbank und die Standbykopie als Spiegeldatenbank bezeichnet. 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 ein Fehler auf dem Prinzipalserver auftritt, kann die Datenbank des Spiegelservers die Rolle der Prinzipaldatenbank übernehmen. Diesen Vorgang nennt man Failover. 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
Für Informationen über Versuche des Erstverbindungsaufbaus zu einer Spiegeldatenbank und spätere Versuche der Verbindungswiederherstellung finden Sie unter Verbinden von Clients mit einer Datenbank-Spiegelungssitzung (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 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.

SQL Server Native Client OLE DB-Anbieter

Der SQL Server Native Client OLE DB-Anbieter unterstützt die Datenbankspiegelung durch Attribute für Verbindungen und Verbindungszeichenfolgen. 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 aufrechterhalten, solange der Anbieter geladen wird, also bis CoUninitialize aufgerufen wird, oder solange die Anwendung über einen Verweis auf ein vom SQL Server Native Client OLE DB-Anbieter verwaltetes Objekt, wie z. B. ein Datenquellobjekt, verfügt.

Einzelheiten über die Unterstützung der Datenbankspiegelung durch den SQL Server Native Client OLE DB-Anbieter finden Sie unter Initialisierungs- und Autorisierungseigenschaften.

ODBC-Treiber für SQL Server Native Client

Der ODBC-Treiber von SQL Server Native Client unterstützt die Datenbankspiegelung durch Attribute für Verbindungen und Verbindungszeichenfolgen. Konkret bedeutet das, das SQL_COPT_SS_FAILOVER_PARTNER-Attribut wurde zur Verwendung mit der SQLSetConnectAttr-Funktion und der SQLGetConnectAttr-Funktion hinzugefügt. Zudem wurde das Failover_Partner-Schlüsselwort als neues Attribut für Verbindungszeichenfolgen 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.

Siehe auch

Konzepte

Verbinden von Clients mit einer Datenbank-Spiegelungssitzung (SQL Server)

Datenbankspiegelung (SQL Server)

Andere Ressourcen

SQL Server Native Client-Funktionen