Auswirkungen eines veralteten Failoverpartnernamens
Aktualisiert: 14. April 2006
Der Failoverpartner kann vom Datenbankadministrator jederzeit geändert werden. Deshalb kann es vorkommen, dass ein vom Client bereitgestellter Failoverpartnernamen nicht mehr auf dem neuesten Stand ist oder als veraltet betrachtet werden kann. Angenommen, ein Failoverpartner namens Partner_B wird durch eine andere Serverinstanz, Partner_C, ersetzt. Stellt nun ein Client Partner_B als Failoverpartnernamen bereit, gilt dieser Name als veraltet. Bei Bereitstellung eines veralteten Failoverpartnernamens durch den Client verhält sich der Datenzugriffsanbieter genau so, als wäre durch den Client überhaupt kein Failoverpartnername bereitgestellt worden.
Im folgenden Beispiel verwendet ein Client eine Verbindungszeichenfolge für vier aufeinander folgende Verbindungsversuche. Dabei wird in der Verbindungszeichenfolge als erster Partnername Partner_A und als Failoverpartnername Partner_B angegeben:
"Server=Partner_A; Failover Partner=Partner_B; Database=AdventureWorks"
In der folgenden Tabelle sind vier Partnerkonfigurationen aufgelistet, für die angegeben wird, ob die Verbindungszeichenfolge beim ersten Verbindungsaufbau des Clients funktionsfähig ist.
.gif "ms366350.note(de-de,SQL.90).gif") Hinweis: |
|---|
| Eine Anwendung kann Konfigurationsänderungen nachverfolgen und die Verbindungszeichenfolge entsprechend ändern. Dafür ist zusätzlicher Code erforderlich, doch sinkt der Verwaltungsaufwand. |
| Konfiguration | Prinzipalserver | Spiegelserver | Verhalten beim Versuch, eine Verbindung unter Angabe von Partner_A und Partner_B herzustellen |
|---|---|---|---|
Ursprüngliche Spiegelungskonfiguration. |
Partner_A |
Partner_B |
Partner_A wird im Cache als erster Partnername zwischengespeichert. Der Client kann die Verbindung mit Partner_A erfolgreich herstellen. Der Name des Spiegelservers Partner_B wird vom Client gedownloadet und zwischengespeichert, d. h., der vom Client bereitgestellte Failoverpartnername wird ignoriert. |
Bei Partner_A kommt es aufgrund eines Hardwarefehlers zu einem Failover (Clientverbindungen werden getrennt). |
Partner_B |
n.v. |
Partner_A ist weiterhin als erster Partnername zwischengespeichert. Da vom Client jedoch Partner_B als Failoverpartnername bereitgestellt wird, kann der Client die Verbindung zum aktuellen Prinzipalserver herstellen. |
Der Datenbankadministrator beendet die Spiegelung (Trennen der Clientverbindungen), ersetzt Partner_A durch Partner_C und startet die Spiegelung dann erneut. |
Partner_B |
Partner_C |
Der Versuch des Clients, eine Verbindung mit Partner_A herzustellen, schlägt fehl. Der daraufhin unternommene Verbindungsversuch des Clients mit Partner_B (dem aktuellen Prinzipalserver) verläuft jedoch erfolgreich. Der Name des aktuellen Spiegelservers, Partner_C, wird vom Datenzugriffsanbieter gedownloadet und als aktueller Failoverpartnername zwischengespeichert. |
Für den Dienst wird ein manuelles Failover zu Partner_C ausgeführt (Trennung der Clientverbindungen). |
Partner_C |
Partner_B |
Die Versuche des Clients, eine Verbindung mit Partner_A und anschließend mit Partner_B herzustellen, schlagen fehl. Schließlich wird das Timeout der Verbindungsanforderung erreicht, und sie schlägt fehl. |
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
Änderungsverlauf
| Version | Verlauf |
|---|---|
14. April 2006 |
|