Freigeben über

Verwenden der Datenbankspiegelung in SQL Server Native Client

  • Artikel

Gilt für: SQL Server Azure SQL-Datenbank Azure SQL Managed Instance Azure Synapse Analytics Analytics Platform System (PDW)

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.

Wichtig

SQL Server Native Client (SNAC) wird nicht ausgeliefert mit:

  • SQL Server 2022 (16.x) und höhere Versionen
  • SQL Server Management Studio 19 und spätere Versionen

Der SQL Server Native Client (SQLNCLI oder SQLNCLI11) und der Microsoft OLE DB-Legacyanbieter für SQL Server (SQLOLEDB) werden für neue Anwendungsentwicklungen nicht empfohlen.

Für neue Projekte verwenden Sie einen der folgenden Treiber:

Informationen zu SQLNCLI, das als Komponente der SQL Server-Datenbank-Engine (Versionen 2012 bis 2019) verfügbar ist, finden Sie in dieser Ausnahme für den Supportlebenszyklus.

Die in SQL Server 2005 (9.x) 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 keinen Code schreiben oder eine andere Aktion ausführen muss, 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. SQL Server Native Client versucht nicht, ein Failover in die Partnerdatenbank auszuführen, wenn dies nicht der Fall 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 OLE DB-Anbieter von SQL Server Native Client unterstützt die Datenbankspiegelung über Verbindungs- und Verbindungszeichenfolge Attribute. 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 Verbindungszeichenfolgenstichwörtern mit SQL Server Native Client.

Der Failovercache wird beibehalten, solange 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 SQL Server Native Client OLE DB-Anbieterunterstützung für die Datenbankspiegelung finden Sie unter Initialisierungs- und Autorisierungseigenschaften.

ODBC-Treiber für SQL Server Native Client

Der ODBC-Treiber für SQL Server Native Client unterstützt die Datenbankspiegelung über Verbindungs- und Verbindungszeichenfolge Attribute. Insbesondere wurde das attribut SQL_COPT_SS_FAILOVER_PARTNER für die Verwendung mit den Funktionen SQLSetConnectAttr und SQLGetConnectAttr hinzugefügt, und das schlüsselwort Failover_Partner wurde als neues Verbindungszeichenfolge 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)