Herstellen der Anfangsverbindung mit einer Datenbank-Spiegelungssitzung

Neu: 14. April 2006

Für die Anfangsverbindung mit einer Spiegeldatenbank muss ein Client eine Verbindungszeichenfolge bereitstellen, die zumindest den Namen einer Serverinstanz nennt. Dieser erforderliche Servername sollte die aktuelle Prinzipalserverinstanz identifizieren und wird auch als erster Partnername bezeichnet.

Optional kann in der Verbindungszeichenfolge auch der Name einer anderen Serverinstanz bereitgestellt werden, um die aktuelle Spiegelserverinstanz zu identifizieren, die dann verwendet wird, wenn der erste Partner während des ersten Verbindungsversuchs nichtverfügbar ist. Der zweite Name wird auch als Failoverpartnername bezeichnet.

In der Verbindungszeichenfolge muss darüber hinaus ein Datenbankname bereitgestellt werden. Die ist notwendig, um Failoverversuche des Datenzugriffsanbieters zu ermöglichen.

Beim Erhalt einer Verbindungszeichenfolge speichert der Datenzugriffsanbieter den Namen des ersten Partners sowie ggf. des Failoverpartners in einem Cache im flüchtigen Speicher des Clients (bei verwaltetem Code ist der Cache auf die Anwendungsdomäne begrenzt). Anschließend wird der Name des ersten Partnernamens vom Datenzugriffsanbieter nie mehr aktualisiert. Wenn der Client den Failoverpartnernamen bereitstellt, speichert der Datenzugriffsanbieter auch diesen Namen zeitweise, falls der Anbieter keine Verbindung über den Namen des ersten Partners herstellen kann.

Eine Datenbank-Spiegelungssitzung schützt nicht vor clientspezifischen Serverzugriffsproblemen, wie z. B. wenn ein Clientcomputer Probleme mit der Kommunikation mit dem Netzwerk hat. Ein Verbindungsversuch mit einer Spiegeldatenbank kann aus den verschiedensten Gründen fehlschlagen, die nicht mit dem Datenzugriffsanbieter zusammenhängen. So kann beispielsweise ein Verbindungsversuch fehlschlagen, weil die Prinzipalserverinstanz inaktiv ist (was bei einem Failover der Datenbank der Fall ist) oder ein Netzwerkfehler aufgetreten ist.

Bei einem Verbindungsversuch verwendet der Datenzugriffsanbieter zunächst den Namen des ersten Partners. Steht die angegebene Serverinstanz zur Verfügung und bildet die aktuelle Prinzipalserverinstanz, ist der Verbindungsversuch in der Regel erfolgreich.

Hinweis:
Wird die Spiegelungssitzung angehalten, stellt der Client normalerweise eine Verbindung mit dem Prinzipalserver her und downloadet den Namen des Partners. Die Datenbank steht dem Client jedoch erst nach dem Fortsetzen der Spiegelung wieder zur Verfügung.

Wenn dieser Versuch nicht erfolgreich ist, verwendet der Datenzugriffsanbieter beim nächsten Verbindungsversuch den Namen des Failoverpartners (sofern vorhanden). Identifiziert einer der Partnernamen den aktuellen Prinzipalserver richtig, kann der Datenzugriffsanbieter die Anfangsverbindung normalerweise erfolgreich herstellen. Beim Abschließen der Verbindung überträgt der Datenzugriffsanbieter den Serverinstanznamen des aktuellen Spiegelservers per Download. Dieser Name wird als Failoverpartnername im Cache gespeichert und überschreibt die vom Client bereitgestellten Failoverpartnernamen (sofern vorhanden). Der Failoverpartnername wird danach vom .NET Framework-Datenprovider für SQL Server nicht mehr aktualisiert. Im Gegensatz hierzu wird der Cache von SQL Native Client immer aktualisiert, wenn eine nachfolgende Verbindung oder das Zurücksetzen einer Verbindung einen anderen Partnernamen zurückgibt.

In der folgenden Abbildung wird eine Clientverbindung mit dem ersten Partner, Partner_A, für eine gespiegelte Datenbank namens Db_1 dargestellt. Die Abbildung stellt einen Fall dar, in dem der vom Client bereitgestellte Name des ersten Partners den aktuellen Prinzipalserver, Partner_A, korrekt identifiziert. Der Anfangsverbindungsversuch ist erfolgreich, und der Datenzugriffsanbieter speichert den Namen des Spiegelservers (derzeit Partner_B) als Failoverpartnername im lokalen Cache. Schließlicht stellt der Client die Verbindung mit der Prinzipalkopie der Db_1-Datenbank her.

Der Anfangsverbindungsversuch kann beispielsweise aufgrund eines Netzwerkfehlers oder einer inaktiven Serverinstanz fehlschlagen. Da der erste Partner nicht verfügbar ist, muss für den Client ein Failoverpartnername in der Verbindungszeichenfolge angegeben sein, damit der Datenzugriffsanbieter versucht, die Verbindung mit dem Failoverpartner herzustellen.

Steht der Failoverpartnername in diesem Fall nicht zur Verfügung, wird der ursprüngliche Verbindungsversuch so lange fortgesetzt, bis das Netzwerkverbindungstimeout erreicht ist oder ein Fehler zurückgegeben wird (wie bei einer nicht gespiegelten Datenbank).

Wird der Failoverpartnername in der Verbindungszeichenfolge bereitgestellt, hängt das Verhalten des Datenzugriffsanbieters wie folgt vom Netzwerkprotokoll und Betriebssystem des Clients ab:

• Bei TCP/IP werden Verbindungsversuche von einem für die Datenbankspiegelung spezifischen Algorithmus für zu wiederholende Verbindungsversuche gesteuert, sofern Microsoft Windows XP oder höher auf dem Client ausgeführt wird. Der Algorithmus für zu wiederholende Verbindungsversuche gibt die maximale Zeitdauer (die Wiederholungszeit) an, die zum Öffnen einer Verbindung in einem bestimmten Verbindungsversuch zugeteilt wurde. Weitere Informationen finden Sie unter Algorithmus für zu wiederholende Verbindungsversuche (für TCP/IP-Verbindungen).
• Andere Netzwerkprotokolle und Clients, die nicht unter Microsoft Windows XP oder höher ausgeführt werden
  Tritt ein Fehler auf oder ist der erste Partner nicht verfügbar, wartet der Anfangsverbindungsversuch bis das Netzwerkverbindungstimeout oder das Anmeldungstimeout für den Datenzugriffsanbieter abgelaufen ist. Die Wartedauer liegt in der Regel zwischen 20 und 30 Sekunden. Ohne Timeout des Datenzugriffsanbieters versucht dieser, eine Verbindung mit dem Failoverpartner herzustellen. Läuft das Verbindungstimeout vor dem erfolgreichen Herstellen der Verbindung ab oder der Failoverpartner ist nicht verfügbar, schlägt der Verbindungsversuch fehl. Steht der Failoverpartner innerhalb des Anmeldungstimeouts zur Verfügung und stellt nun den Prinzipalserver dar, verläuft der Verbindungsversuch in der Regel erfolgreich.

Verbindungszeichenfolgen für eine gespiegelte Datenbank

Die vom Client bereitgestellte Verbindungszeichenfolge enthält Informationen, die der Datenzugriffsanbieter zum Herstellen der Verbindung mit der Datenbank verwendet. In diesem Abschnitt werden die Schlüsselwörter erläutert, die zum Herstellen einer Verbindung mit einer gespiegelten Datenbank mithilfe einer ODBC-Treiberverbindung für SQL Native Client relevant sind. Informationen zu allen Schlüsselwörtern für Verbindungszeichenfolgen finden Sie unter Using Connection String Keywords with SQL Native Client.

Network-Attribut

Die Verbindungszeichenfolge sollte das Network-Attribut zur Angabe des Netzwerkprotokolls enthalten. So wird sichergestellt, dass das angegebene Netzwerkprotokoll zwischen Verbindungen mit verschiedenen Partnern dauerhaft gespeichert wird. TCP/IP ist das Protokoll, das sich am besten zum Herstellen einer Verbindung mit einer gespiegelten Datenbank eignet. Um sicherzustellen, dass der Client TCP/IP für jede Verbindung mit den Partnern anfordert, stellt eine Verbindungszeichenfolge das folgende Attribut bereit:

Network=dbmssocn; 

Wichtig:
Es wird empfohlen, TCP/IP an oberster Stelle der Protokollliste eines Clients zu belassen. Wenn die Verbindungszeichenfolge jedoch das Network-Attribut angibt, wird die Reihenfolge der Liste dadurch außer Kraft gesetzt.

Um alternativ sicherzustellen, dass der Client Named Pipes für jede Verbindung mit den Partnern anfordert, stellt eine Verbindungszeichenfolge das folgende Attribut bereit:

Network=dbnmpntw; 

Wichtig:
Da Named Pipes den TCP/IP-Wiederholungsalgorithmus nicht verwenden, erreicht ein Verbindungsversuch mit Named Pipes häufig zuerst ein Timeout, ehe eine Verbindung mit einer gespiegelten Datenbank hergestellt wird.

Server-Attribut

Die Verbindungszeichenfolge muss ein Server-Attribut enthalten, das den Namen des ersten Partners bereitstellt, der die aktuelle Prinzipalserverinstanz identifizieren sollte.

Die einfachste Art, die Serverinstanz zu identifizieren, besteht darin, ihren Namen (<server_name>[\<SQL_Server_instance_name>]) anzugeben. Beispiel:

Server=Partner_A;

- oder -

Server=Partner_A\Instance_2;

Wenn jedoch der Systemname verwendet wird, muss der Client ein DNS-Lookup ausführen, um die IP-Adresse des Servers zu erhalten, und eine SQL Server Browser-Abfrage, um die Portnummer des Servers, auf dem sich der Partner befindet, abzurufen. Diese Lookups und Abfragen können durch Angabe der IP-Adresse und Portnummer des Partners im Server-Attribut anstelle des Servernamens umgangen werden. Diese Vorgehensweise wird empfohlen, um die Möglichkeit externer Verzögerungen beim Verbinden mit diesem Partner zu minimieren.

Hinweis:
Eine SQL Server Browser-Abfrage ist erforderlich, wenn in der Verbindungszeichenfolge der benannte Instanzname und nicht der Port angegeben ist.

Zum Angeben der IP-Adresse und des Ports nimmt das Server-Attribut die Form Server=<ip_address>,<port> an, wie z. B. in:

Server=123.34.45.56,4724; 

Hinweis:
Die IP-Adresse kann im IPv4-Format (IP Version 4) oder im IPv6-Format (IP Version) vorliegen.

Database-Attribut

Zusätzlich muss die Verbindungszeichenfolge das Database-Attribut angeben, um den Namen der gespiegelten Datenbank bereitzustellen. Wenn die Datenbank beim Verbindungsversuch des Clients nicht verfügbar ist, wird eine Ausnahme ausgelöst.

Um beispielsweise eine Verbindung mit der AdventureWorks-Datenbank auf dem Prinzipalserver Partner_A herzustellen, verwendet der Client die folgende Verbindungszeichenfolge:

" Server=Partner_A; Database=AdventureWorks "

Hinweis:
Die Authentifizierungsinformationen fehlen in dieser Zeichenfolge. Weitere Informationen zu Schlüsselwörtern für die integrierte Authentifizierung finden Sie unter Using Connection String Keywords with SQL Native Client.

Wichtig:

Die Bündelung des Protokollpräfix mit dem Server-Attribute (Server=tcp:<servername>) ist inkompatibel mit dem Network-Attribut; die Angabe des Protokolls an beiden Stellen führt wahrscheinlich zu einem Fehler. Deshalb wird empfohlen, dass eine Verbindungszeichenfolge das Protokoll mithilfe des Network-Attributs angibt und nur der Servername im Server-Attribut ("Network=dbmssocn; Server=<servername>") angegeben wird.

Failover Partner-Attribut

Neben dem Namen des ersten Partners kann der Client auch den Namen des Failoverpartners angeben, der die aktuelle Spiegelserverinstanz identifizieren sollte. Der Failoverpartner wird durch das Failover Partner-Attribut angegeben. Die einfachste Art, die Serverinstanz zu identifizieren, ist über ihren Systemnamen, <server_name>[\<SQL_Server_instance_name>].

Alternativ können die IP-Adresse und die Portnummer im Failover Partner-Attribut bereitgestellt werden. Wenn der Anfangsverbindungsversuch während der ersten Verbindung mit der Datenbank fehlschlägt, wird beim Versuch, eine Verbindung mit dem Failoverpartner herzustellen, auf das Zurückgreifen auf DNS und SQL Server Browser verzichtet. Wenn eine Verbindung hergestellt wurde, wird der Failoverpartnername durch den Failoverpartnernamen überschrieben; bei einem Failover benötigen die umgeleiteten Verbindung somit DNS und SQL Server Browser.

Hinweis:
Wenn nur der erste Partnername angegeben wird, müssen Anwendungsentwickler weder zusätzliche Schritte ergreifen noch zusätzlichen Code schreiben, außer um wieder eine Verbindung herzustellen.

Hinweis:
Entwickler von Anwendungen mit verwaltetem Code geben den Namen des Failoverpartners im SqlConnection-Objekt unter ConnectionString an. Informationen zum Verwenden dieser Verbindungszeichenfolge finden Sie in der zum Microsoft .NET Framework SDK gehörigen Dokumentation zu ADO.NET im Kapitel zur Unterstützung der Datenbankspiegelung im .NET Framework-Datenprovider für SQL Server.

Beispiel für eine Verbindungszeichenfolge

Um beispielsweise eine Verbindung mithilfe von TCP/IP mit der AdventureWorks-Datenbank auf Partner_A oder Partner_B herzustellen, kann durch eine Clientanwendung die folgende Verbindungszeichenfolge bereitgestellt werden:

"Server=Partner_A; Failover Partner=Partner_B; Database=AdventureWorks; Network=dbmssocn"

Alternativ könnte der Client die IP-Adresse und Portnummer zum Identifizieren des ersten Partners, Partner_A verwenden; wenn die IP-Adresse beispielsweise 250.65.43.21 und die Portnummer 4734 lautet, sieht die Verbindungszeichenfolge wie folgt aus:

"Server=250.65.43.21,4734; Failover Partner=Partner_B; Database=AdventureWorks; Network=dbmssocn"

Siehe auch

Konzepte

Netzwerkprotokolle und TDS-Endpunkte
Übersicht über die Datenbankspiegelung
Mögliche Fehler während der Datenbankspiegelung

Andere Ressourcen

Herstellen einer Verbindung zum SQL Server-Datenbankmodul
Using Connection String Keywords with SQL Native Client
Verwenden des SQL Server-Browsers

Hilfe und Informationen

Informationsquellen für SQL Server 2005