OLE DB-Treiber für SQL Server-Unterstützung für Hochverfügbarkeit, Notfallwiederherstellung

  • Artikel

Gilt für:SQL ServerAzure SQL-DatenbankAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)

OLE DB-Treiber herunterladen

In diesem Artikel wird die OLE DB-Treiber für SQL Server-Unterstützung für Always On-Verfügbarkeitsgruppen erläutert. Weitere Informationen zu Always-On-Verfügbarkeitsgruppen finden Sie unter Verfügbarkeitsgruppenlistener, Clientkonnektivität und Anwendungsfailover (SQL Server), Erstellung und Konfiguration von Verfügbarkeitsgruppen (SQL Server), Failoverclustering und Always-On-Verfügbarkeitsgruppen (SQL Server) und Aktive sekundäre Replikate: Lesbare sekundäre Replikate (Always-On-Verfügbarkeitsgruppen).

Sie können den Verfügbarkeitsgruppenlistener einer bestimmten Verfügbarkeitsgruppe in der Verbindungszeichenfolge angeben. Wenn ein OLE DB-Treiber für SQL Server-Anwendung mit einer Datenbank in einer Verfügbarkeitsgruppe verbunden ist, die ein Failover ausführt, wird die ursprüngliche Verbindung unterbrochen, und die Anwendung muss eine neue Verbindung herstellen, um die Arbeit nach dem Failover fortzusetzen.

Wenn Sie keine Verbindung zu einem verfügbaren Gruppenlistener herstellen und mehrere IP-Adressen einem Hostnamen zugeordnet sind, durchläuft der OLE DB-Treiber für SQL Server nacheinander alle IP-Adressen, die dem DNS-Eintrag zugeordnet sind. Dies kann zeitaufwändig sein, wenn die erste vom DNS-Server zurückgegebene IP-Adresse an keine Netzwerkschnittstellenkarte (NIC) gebunden ist. Beim Herstellen einer Verbindung zu einem verfügbaren Gruppenlistener versucht der OLE DB-Treiber für SQL Server, Verbindungen zu allen IP-Adressen parallel herzustellen, und wenn ein Verbindungsversuch erfolgreich ist, verwirft der Treiber alle ausstehenden Verbindungsversuche.

Hinweis

Das Erhöhen des Verbindungstimeouts sowie die Implementierung von Verbindungswiederholungslogik erhöhen die Wahrscheinlichkeit, dass eine Anwendung eine Verbindung zu einer Verfügbarkeitsgruppe herstellt. Da zudem eine Verbindung aufgrund eines Verfügbarkeitsgruppenfailovers fehlschlagen kann, empfiehlt sich die Implementierung von Verbindungswiederholungslogik, wodurch im Fall einer fehlgeschlagenen Verbindung bis zur erneuten Verbindung Wiederholungsversuche erfolgen.

Verbinden mit MultiSubnetFailover

Geben Sie immer MultiSubnetFailover=Yes an, wenn Sie eine Verbindung mit einem SQL Server Always On-Verfügbarkeitsgruppenlistener oder einer SQL Server-Failoverclusterinstanz herstellen. MultiSubnetFailover ermöglicht ein schnelleres Failover für alle Always On-Verfügbarkeitsgruppen und die Failoverclusterinstanz in SQL Server und reduziert die Failoverzeit für einzelne und Multisubnetz-Always On-Topologien erheblich. Während eines Multisubnetzfailovers versucht der Client Verbindungen parallel. Während eines Subnetzfailovers versucht der OLE DB-Treiber für SQL Server die TCP-Verbindung wiederherzustellen.

Die MultiSubnetFailover-Verbindungseigenschaft gibt an, dass die Anwendung in einer Verfügbarkeitsgruppe oder einer Failoverclusterinstanz bereitgestellt wird und der OLE DB-Treiber für SQL Server versucht, eine Verbindung mit der Datenbank auf der primären SQL Server-Instanz herzustellen, indem mit allen IP-Adressen der Verfügbarkeitsgruppe Verbindungsversuche unternommen werden. Wenn MultiSubnetFailover=Yes für eine Verbindung angegeben wird, wiederholt der Client TCP-Verbindungsversuche schneller als dies bei den standardmäßigen TCP-Neuübertragungsintervallen des Betriebssystems der Fall ist. Auf diese Weise kann die Verbindung nach einem Failover einer Always On-Verfügbarkeitsgruppe oder einer Failoverclusterinstanz schneller wiederhergestellt werden. Diese Einstellung gilt sowohl für Einzelsubnetz- als auch Multisubnetz-Verfügbarkeitsgruppen und -Failoverclusterinstanzen.

Weitere Informationen zu Verbindungszeichenfolgen-Schlüsselwörtern finden Sie unter Using Connection String Keywords with SQL Server Native Client (Verwenden von Verbindungszeichenfolgen-Schlüsselwörtern mit dem OLE DB-Treiber für SQL Server).

Das Angeben von MultiSubnetFailover=Yes für ein anderes Verbindungsziel als einen Verfügbarkeitsgruppenlistener oder eine Failoverclusterinstanz kann die Leistung beeinträchtigen und wird nicht unterstützt.

Befolgen Sie beim Herstellen einer Verbindung mit einem Server in einer Verfügbarkeitsgruppe oder einer Failoverclusterinstanz die folgenden Richtlinien:

  • Verwenden Sie die MultiSubnetFailover -Verbindungseigenschaft, wenn Sie eine Verbindung mit einem Einzelsubnetz oder Multisubnetz herstellen. Dadurch wird die Leistung für beide verbessert.

  • Um eine Verbindung mit einer Verfügbarkeitsgruppe herzustellen, geben Sie in der Verbindungszeichenfolge den Verfügbarkeitsgruppenlistener der Verfügbarkeitsgruppe als Server an.

  • Ein Verbindungsversuch mit einer mit mehr als 64 IP-Adressen konfigurierten SQL Server -Instanz verursacht einen Verbindungsfehler.

  • Das Verhalten einer Anwendung, die die MultiSubnetFailover -Verbindungseigenschaft verwendet, wird nicht vom Authentifizierungstyp beeinflusst: SQL Server -Authentifizierung, Kerberos-Authentifizierung oder Windows-Authentifizierung.

  • Sie können den Wert von loginTimeout erhöhen, um die Failoverzeit zu berücksichtigen und Wiederholungsversuche für Anwendungsverbindungen zu reduzieren.

  • Verteilte Transaktionen werden nicht unterstützt.

Wenn das schreibgeschützte Routing nicht aktiviert ist, scheitert das Herstellen der Verbindung mit einem sekundären Replikatspeicherort in einer Verfügbarkeitsgruppe in den folgenden Situationen:

  1. Wenn der sekundäre Replikatspeicherort nicht zum Akzeptieren von Verbindungen konfiguriert ist.

  2. Wenn eine Anwendung ApplicationIntent=ReadWrite verwendet (weiter unten erläutert), und der sekundäre Replikatspeicherort für schreibgeschützten Zugriff konfiguriert ist.

Es kann keine Verbindung hergestellt werden, wenn ein primäres Replikat so konfiguriert ist, dass schreibgeschützte Arbeitslasten abgelehnt werden, und die Verbindungszeichenfolge ApplicationIntent=ReadOnlyenthält.

Aktualisieren zur Verwendung von Multisubnetzclustern aus Datenbankspiegelung

Ein Verbindungsfehler tritt auf, wenn die Verbindungsschlüsselwörter MultiSubnetFailover und Failover_Partner in der Verbindungszeichenfolge vorhanden sind. Es tritt auch ein Fehler auf, wenn MultiSubnetFailover verwendet wird und SQL Server eine Failoverpartnerantwort zurückgibt, die angibt, dass es Teil eines Datenbankspiegelungspaars ist.

Wenn Sie eine OLE DB-Treiber für SQL Server-Anwendung aktualisieren, die derzeit Datenbankspiegelung in einem Multisubnetzszenario verwendet, müssen Sie die Failover_Partner-Verbindungseigenschaft entfernen und durch MultiSubnetFailover, festgelegt auf Yes, ersetzen, sowie den Servernamen in der Verbindungszeichenfolge durch einen Verfügbarkeitsgruppenlistener ersetzen. Wenn eine Verbindungszeichenfolge Failover_Partner und MultiSubnetFailover=Yesverwendet, generiert der Treiber einen Fehler. Wenn eine Verbindungszeichenfolge jedoch Failover_Partner und MultiSubnetFailover=No (oder ApplicationIntent=ReadWrite) verwendet, verwendet die Anwendung Datenbankspiegelung.

Der Treiber gibt einen Fehler zurück, wenn die Datenbankspiegelung in der primären Datenbank in der Verfügbarkeitsgruppe verwendet wird, und wenn MultiSubnetFailover=Yes in der Verbindungszeichenfolge verwendet wird, die statt mit einem Verfügbarkeitsgruppenlistener eine Verbindung mit einer primären Datenbank herstellt.

Angeben der Anwendungsabsicht

Sie können das Schlüsselwort ApplicationIntent in Ihrer Verbindungszeichenfolge angeben. Es können die Werte ReadWrite (Standard) und ReadOnly zugewiesen werden.

Wenn Sie ApplicationIntent=ReadOnly festlegen, fordert der Client bei der Verbindungsherstellung eine Leseworkload an. Der Server erzwingt die Absicht zur Verbindungszeit und während einer USE-Datenbankanweisung.

Das Schlüsselwort ApplicationIntent funktioniert nicht mit schreibgeschützten Legacy-Datenbanken.

Ziele von ReadOnly

Wenn eine Verbindung ReadOnly auswählt, wird sie einer der folgenden speziellen Konfigurationen zugewiesen, die für die Datenbank ggf. vorhanden sind:

  • Always On: Eine Datenbank kann Leseworkloads in der Verfügbarkeitsgruppen-Zieldatenbank zulassen bzw. nicht zulassen. Diese Auswahl wird über die ALLOW_CONNECTIONS-Klausel der Transact-SQL-Anweisungen PRIMARY_ROLE und SECONDARY_ROLE gesteuert.

  • Georeplikation

  • Horizontale Leseskalierung

Wenn keins dieser speziellen Ziele verfügbar ist, erfolgt der Lesevorgang in der regulären Datenbank.

Das Schlüsselwort ApplicationIntent ermöglicht schreibgeschütztes Routing.

Schreibgeschütztes Routing

Das schreibgeschützte Routing ist eine Funktion, die die Verfügbarkeit des schreibgeschützten Replikats einer Datenbank sicherstellen kann. Zum Aktivieren des schreibgeschützten Routings gelten sämtliche der folgenden Voraussetzungen:

  • Sie müssen eine Verbindung mit einem Always On-Verfügbarkeitsgruppenlistener herstellen.

  • Das Schlüsselwort der ApplicationIntent-Verbindungszeichenfolge muss auf ReadOnly festgelegt werden.

  • Der Datenbankadministrator muss die Verfügbarkeitsgruppe für das schreibgeschützte Routing konfigurieren.

Mehrere Verbindungen, für die jeweils das schreibgeschützte Routing verwendet wird, werden ggf. nicht alle mit demselben schreibgeschützten Replikat hergestellt. Änderungen in der Datenbanksynchronisierung oder Änderungen in der Routingkonfiguration des Servers können zu Clientverbindungen mit anderen schreibgeschützten Replikaten führen.

Sie können sicherstellen, dass für alle schreibgeschützten Anforderungen eine Verbindung mit demselben schreibgeschützten Replikat hergestellt wird, indem Sie keinen Verfügbarkeitsgruppenlistener an das Verbindungszeichenfolgen-Schlüsselwort Server übermitteln. Geben Sie stattdessen den Namen der schreibgeschützten Instanz an.

Das schreibgeschützte Routing kann ggf. länger als das Herstellen einer Verbindung mit der primären Instanz dauern. Dies liegt daran, dass beim schreibgeschützten Routing zunächst eine Verbindung mit dem primären Replikat hergestellt wird und dann nach dem besten verfügbaren lesbaren sekundären Replikat gesucht wird. Da mehrere Schritte ausgeführt werden, sollten Sie das Timeout für login auf mindestens 30 Sekunden erhöhen.

OLE DB

Der OLE DB-Treiber für SQL Server unterstützt die beiden Schlüsselwörter ApplicationIntent und MultiSubnetFailover.

Die zwei OLE DB-Verbindungszeichenfolgenschlüsselwörter wurden hinzugefügt, um Always On-Verfügbarkeitsgruppen im OLE DB-Treiber für SQL Server zu unterstützen:

  • ApplicationIntent
  • MultiSubnetFailover

Weitere Informationen zu Verbindungszeichenfolgen-Schlüsselwörtern im OLE DB-Treiber für SQL Server finden Sie unter Verwenden von Verbindungszeichenfolgen-Schlüsselwörtern mit dem OLE DB-Treiber für SQL Server.

Application Intent

Die entsprechenden Verbindungseigenschaften sind:

  • SSPROP_INIT_APPLICATIONINTENT

  • DBPROP_INIT_PROVIDERSTRING

Eine OLE DB-Treiber für SQL Server-Anwendung kann eine der Methoden verwenden, um die Anwendungsabsicht anzugeben:

  • IDBInitialize::Initialize
    IDBInitialize::Initialize verwendet den zuvor konfigurierten Satz von Eigenschaften, um die Datenquelle zu initialisieren und das Datenquellenobjekt zu erstellen. Geben Sie die Anwendungsabsicht als Anbietereigenschaft oder als einen Teil der erweiterten Eigenschaftenzeichenfolge an.

  • IDataInitialize::GetDataSource
    IDataInitialize::GetDataSource verwendet eine Eingabeverbindungszeichenfolge, die das Application Intent -Schlüsselwort enthalten kann.

  • IDBProperties::SetProperties
    Um den ApplicationIntent -Eigenschaftswert festzulegen, rufen Sie IDBProperties::SetProperties auf, indem Sie die SSPROP_INIT_APPLICATIONINTENT -Eigenschaft mit dem Wert "ReadWrite" oder "ReadOnly" oder die DBPROP_INIT_PROVIDERSTRING -Eigenschaft mit dem Wert angeben, der "ApplicationIntent=ReadOnly" oder "ApplicationIntent=ReadWrite" enthält.

Sie können die Anwendungsabsicht im Feld für die Eigenschaften der Anwendungsabsicht auf der Registerkarte Alle im Dialogfeld Datenverknüpfungseigenschaften angeben.

Wenn implizite Verbindungen hergestellt werden, verwendet die implizite Verbindung die Einstellung der Anwendungsabsicht der übergeordneten Verbindung. Auf ähnliche Weise erben mehrere aus der gleichen Datenquelle erstellte Sitzungen die Einstellung für die Anwendungsabsicht der Datenquelle.

MultiSubnetFailover

Die entsprechenden Verbindungseigenschaften sind:

  • SSPROP_INIT_MULTISUBNETFAILOVER

  • DBPROP_INIT_PROVIDERSTRING

Eine OLE DB-Treiber für SQL Server-Anwendung kann eine der folgenden Methoden verwenden, um die Option „MultiSubnetFailover“ festzulegen:

  • IDBInitialize::Initialize
    IDBInitialize::Initialize verwendet den zuvor konfigurierten Satz von Eigenschaften, um die Datenquelle zu initialisieren und das Datenquellenobjekt zu erstellen. Geben Sie die Anwendungsabsicht als Anbietereigenschaft oder als einen Teil der erweiterten Eigenschaftenzeichenfolge an.

  • IDataInitialize::GetDataSource
    IDataInitialize::GetDataSource verwendet eine Eingabeverbindungszeichenfolge, die das MultiSubnetFailover-Schlüsselwort enthalten kann.

  • IDBProperties::SetProperties
    Rufen Sie IDBProperties::SetProperties auf, und übergeben Sie dabei die Eigenschaft SSPROP_INIT_MULTISUBNETFAILOVER mit dem Wert VARIANT_TRUE oder VARIANT_FALSE oder die Eigenschaft DBPROP_INIT_PROVIDERSTRING mit einem Wert, der „MultiSubnetFailover=Yes“ oder „MultiSubnetFailover=No“ enthält, um den Eigenschaftswert MultiSubnetFailover festzulegen.

Beispiel

DBPROP rgPropMultisubnet;

rgPropMultisubnet.dwPropertyID = SSPROP_INIT_MULTISUBNETFAILOVER;
rgPropMultisubnet.dwOptions = DBPROPOPTIONS_REQUIRED;
rgPropMultisubnet.dwStatus = DBPROPSTATUS_OK;
rgPropMultisubnet.colid = DB_NULLID;
V_VT(&(rgPropMultisubnet.vValue)) = VT_BOOL;
V_BOOL(&(rgPropMultisubnet.vValue)) = VARIANT_TRUE;

DBPROPSET PropSet;

PropSet.rgProperties = &rgPropMultisubnet;
PropSet.cProperties = 1;
PropSet.guidPropertySet = DBPROPSET_SQLSERVERDBINIT;
IDBProperties* pIDBProperties = NULL;
hr = pIDBInitialize->QueryInterface(IID_IDBProperties, (void **)&pIDBProperties);
pIDBProperties->SetProperties(1, &PropSet);

Weitere Informationen

OLE DB-Treiber für SQL Server-Features
Verwenden von Verbindungszeichenfolgen-Schlüsselwörtern mit dem OLE DB-Treiber für SQL Server