Artikel
03/30/2012

Erneutes Herstellen einer Verbindung mit einer Datenbank-Spiegelungssitzung

Wenn eine bereits bestehende Verbindung mit einer Datenbank-Spiegelungssitzung aus irgendeinem Grund ausfällt, z. B. wegen eines Datenbank-Spiegelungsfailovers, und die Anwendung versucht, erneut eine Verbindung mit dem ersten Server herzustellen, kann der Datenzugriffsanbieter versuchen, die Verbindung mit dem im Clientcache enthaltenen Namen des Failoverpartners herzustellen. Die Verbindung wird jedoch nicht automatisch wiederhergestellt. Die Anwendung muss über den Fehler informiert werden. Anschließend muss die Anwendung die fehlgeschlagene Verbindung schließen und eine neue Verbindung mit den gleichen Attributen für die Verbindungszeichenfolge öffnen. An diesem Punkt leitet der Datenzugriffsanbieter die Verbindung an den Failoverpartner um. Wenn die durch diesen Namen identifizierte Serverinstanz aktuell als Prinzipalserver fungiert, ist der Verbindungsversuch im Allgemeinen erfolgreich. Wenn unklar ist, ob für eine Transaktion ein Commit oder ein Rollback ausgeführt wurde, muss die Anwendung wie bei einer erneuten Verbindung zu einer eigenständigen Serverinstanz den Status der Transaktion überprüfen.

Das erneute Herstellen einer Verbindung ähnelt der ursprünglichen Verbindung, für die in der Verbindungszeichenfolge der Name eines Failoverpartners angegeben wurde. Wenn der erste Verbindungsversuch nicht gelingt, werden abwechselnd mit dem Namen des ersten Partners und mit dem Namen des Failoverpartners weitere Verbindungsversuche unternommen, bis der Client entweder eine Verbindung mit dem Prinzipalserver herstellt oder beim Datenzugriffsanbieter ein Timeout auftritt.

Hinweis
SQL Server Native Client überprüft zwar, ob die Verbindung mit einer Prinzipalserverinstanz hergestellt wird, aber nicht, ob diese Instanz der Partner der Serverinstanz ist, die im ersten Partnernamen der Verbindungszeichenfolge angegeben war.

Wenn die Verbindungen TCP/IP verwenden und der Client Windows XP oder später verwendet, wird durch den Algorithmus für zu wiederholende Verbindungsversuche bestimmt, wie viel Zeit für die Verbindungsversuche in jeder Runde zur Verfügung steht. Weitere Informationen finden Sie unter Verwenden von Schlüsselwörtern für Verbindungszeichenfolgen mit SQL Server Native Client.

Wichtig
Wenn die Verbindung des Clients zur Datenbank getrennt wird, versucht der Datenzugriffsanbieter nicht, die Verbindung wiederherzustellen. Der Client muss eine neue Verbindungsanforderung ausgeben. Außerdem verliert eine Anwendung, falls sie nach dem Verlust der Verbindung herunterfährt, die im Cache enthaltenen Partnernamen. Wurde die Verbindung getrennt, weil der Prinzipalserver nicht mehr verfügbar war, kann die Anwendung die Verbindung zum Spiegelserver nur noch herstellen, wenn in ihrer Verbindungszeichenfolge der Name des Failoverpartners angegeben wird.

Wenn die Verbindung des Clients zur Datenbank getrennt wird, versucht der Datenzugriffsanbieter nicht, die Verbindung wiederherzustellen. Der Client muss eine neue Verbindungsanforderung ausgeben. Außerdem verliert eine Anwendung, falls sie nach dem Verlust der Verbindung herunterfährt, die im Cache enthaltenen Partnernamen. Wurde die Verbindung getrennt, weil der Prinzipalserver nicht mehr verfügbar war, kann die Anwendung die Verbindung zum Spiegelserver nur noch herstellen, wenn in ihrer Verbindungszeichenfolge der Name des Failoverpartners angegeben wird.

Auswirkungen einer Umleitung auf eine Clientanwendung

Nach einem Failover leitet der Datenzugriffsanbieter die Verbindung an die aktuelle Prinzipalserverinstanz um. Die Umleitung ist für die Clients jedoch transparent. Für einen Client stellt sich eine umgeleitete Verbindung wie eine Verbindung mit der durch den ersten Partnernamen identifizierten Serverinstanz dar. Wenn der erste Partner zu diesem Zeitpunkt gerade als Spiegelserver fungiert, kann es so aussehen, als wäre der Client mit dem Spiegelserver verbunden und würde die Spiegeldatenbank aktualisieren. Tatsächlich wurde der Client jedoch an den Failoverpartner umgeleitet, bei dem es sich um die aktuelle Prinzipaldatenbank handelt, und der Client aktualisiert die neue Prinzipaldatenbank.

Nach der Umleitung an den Failoverpartner erhält ein Client möglicherweise unerwartete Ergebnisse, wenn er mithilfe einer Transact-SQL USE-Anweisung eine andere Datenbank verwendet. Dies kann der Fall sein, wenn die aktuelle Prinzipalserverinstanz (der Failoverpartner) über einen anderen Satz Datenbanken verfügt als der ursprüngliche Prinzipalserver (der erste Partner).