Fehlerbehandlung: Datenbankserver mithilfe des Verbindungsparameters "CommLinks=TCPIP" suchen

Hinweis

Sie sollten den CommLinks-Verbindungsparameter (LINKS) nur dann verwenden, wenn Sie andere TCP/IP-Protokolloptionen als HOST oder ServerPort (PORT) angeben müssen. Verwenden Sie andernfalls den Host-Verbindungsparameter. Siehe Host-Verbindungsparameter.

Sie können nicht sowohl CommLinks als auch Host in der Verbindungszeichenfolge angeben.

Der Host-Verbindungsparameter unterscheidet sich von der HOST-Protokolloption. Die HOST-Protokolloption wird vom CommLinks-Verbindungsparameter verwendet. Siehe Host-Protokolloption (IP) (nur clientseitig).

Ein SQL Anywhere-Client, der versucht, einen Server über TCP/IP unter Verwendung der CommLinks-Verbindungsparameter zu finden, führt dabei folgende Schritte aus:

Wenn der Datenbankserver nicht gefunden wird, teilt das System in einer Meldung mit, dass der Server nicht gefunden wurde. Wenn ein anderer Fehler auftritt, schlägt der Verbindungsversuch fehl, ohne dass weitere Schritte versucht werden. Siehe Datenbankserver nicht gefunden.

Wenn sich der Client mit dem Datenbankserver erfolgreich verbunden hat, versucht er, eine Verbindung mit der Datenbank herzustellen. Siehe Fehlerbehandlung: Datenbankserver suchen.

Schritt 1: Überprüfen Sie den Datenbankserver-Adressencache (sasrv.ini) Wenn die Verbindungszeichenfolge die HOST-Protokolloption, nicht aber den ServerName-Verbindungsparameter enthält, wird die LocalOnly-Protokolloption auf YES oder die DoBroadcast-Protokolloption auf NONE gesetzt. Danach versucht der SQL Anywhere-Client eine direkte TCP/IP-Verbindung. Das heißt, dass der SQL Anywhere-Client nicht den Datenbankserver-Adressencache oder den LDAP-Server verwendet. Siehe Schritt 3: Versuchen, eine TCP/IP-Verbindung mit der/den in der HOST-Protokolloption angegeben Adresse(n) herzustellen.
Der Client überprüft die sasrv.ini-Datei auf einen Eintrag, der mit dem Datenbankservernamen übereinstimmt, der vom Verbindungsparameter ServerName festgelegt wird. Wenn die Verbindungszeichenfolge auch die HOST-Protokolloption enthält, muss der Cacheeintrag ebenfalls mit der angegebenen Hostadresse übereinstimmen.

Wenn kein übereinstimmender Cacheeintrag gefunden wird, versucht der Client, den Datenbankserver mit LDAP zu finden. Siehe Schritt 2: Im LDAP-Server den Servernamen abfragen.

Wenn ein entsprechender Cacheeintrag gefunden wird, versucht der Client eine TCP/IP-Verbindung mit der IP-Adresse, die im Cache gelistet ist.
- Wenn der Client eine Verbindung zum Datenbankserver über diese IP-Adresse aufnimmt und die VerifyServer-Protokolloption nicht aktiviert ist, kommt die Verbindung zustande. Siehe VerifyServerName-Protokolloption (VERIFY) (nur clientseitig).
- Wenn der Client eine Verbindung zum Datenbankserver über diese IP-Adresse aufnimmt und VerifyServer auf Ja gesetzt ist (Standardwert), vergleicht der Client den Datenbankservernamen mit dem von ServerName angegebenen Wert. Wenn der Datenbankservername übereinstimmt, kommt die Verbindung erfolgreich zustande. Wenn der Datenbankservername nicht übereinstimmt, entfernt der Client den Eintrag aus der sasrv.ini-Datei und der Client versucht, den Datenbankserver direkt über TCP/IP mit LDAP zu finden. Siehe Schritt 2: Im LDAP-Server den Servernamen abfragen.
- Wenn der Client keine Verbindung herstellen kann, entfernt er den Eintrag aus seiner sasrv.ini-Datei und versucht, den Datenbankserver mit LDAP zu finden. Siehe Schritt 2: Im LDAP-Server den Servernamen abfragen.
Hinweis

Der Dateiname für den Datenbankserver-Adressencache ist unter Unix .sasrv.ini. Siehe Fehlerbehandlung: Datenbankserver-Adressinformationen für schnellere Verbindungen in sasrv.ini zwischenspeichern.
- Schritt 1: Beispiel Angenommen, es gibt einen Computer mit dem Hostnamen kangaroo und der IP-Adresse 10.25.13.5. Ein Datenbankserver namens joey läuft auf diesem Computer auf Port 49152.
  Für die Verbindungszeichenfolge CommLinks=TCPIP(Host=kangaroo);ServerName=joey findet der Client einen Eintrag in seiner sasrv.ini-Datei, der mit dem Servernamen joey übereinstimmt. Die IP-Adresse im Cache ist 10.25.13.5:49152. Der Client vergleicht die Adresse des angegebenen Hostnamens mit 10.25.13.5. Die Adressen stimmen überein, sodass der Client eine Verbindung über TCP/IP mit 10.25.13.5:49152 einrichtet und dann prüft, ob der verbundene Server joey heißt. Die Verbindung ist erfolgreich.
Schritt 2: Im LDAP-Server den Servernamen abfragen Ein SQL Anywhere-Client fragt im LDAP-Server einen Eintrag ab, der mit dem ServerName-Verbindungsparameter übereinstimmt, wenn die Computer, auf denen der SQL Anywhere-Client und der Datenbankserver laufen, so konfiguriert sind, dass sie einen LDAP-Server verwenden. Siehe Verbindungen mit LDAP als Namensserver.
Schritt 3: Versuchen, eine TCP/IP-Verbindung mit der/den in der HOST-Protokolloption angegeben Adresse(n) herzustellen Wenn die HOST-Protokolloption nicht angegeben ist, versucht der SQL Anywhere-Client, den Server mithilfe von UDP-Serversuchanforderungen zu finden. Siehe Schritt 4: UDP-Datenbankserver-Suchanforderungen absetzen.
Der SQL Anywhere-Client versucht, eine Verbindung über TCP/IP mit den in der HOST-Protokolloption angegebenen Adressen herzustellen. Wenn mehrere Adressen angegeben sind, versucht der Client, sich mit jeder Adresse in der Reihenfolge zu verbinden, in der sie in der HOST-Protokolloption angegeben werden. Der Client versucht, Verbindungen herzustellen, bis eine Verbindung erfolgreich ist oder alle Adressen aufgebraucht sind.

Wenn die Verbindungszeichenfolge einen Port (in der HOST-Protokolloption oder in der ServerPort-Verbindungseigenschaft) enthält, versucht der Client, eine TCP/IP-Verbindung mit der angegebenen Adresse und Portnummer herzustellen. Wenn kein Port angegeben ist, versucht der Client eine TCP/IP-Verbindung an der angegebenen Adresse über den Standardport 2638.
- Wenn der Client eine Verbindung zum Datenbankserver über die angegebene IP-Adresse aufnimmt und die VerifyServer-Protokolloption nicht aktiviert ist, kommt die Verbindung zustande. Siehe VerifyServerName-Protokolloption (VERIFY) (nur clientseitig).
- Wenn der Client über die angegebene Adresse eine Verbindung mit dem Datenbankserver herstellt, vergleicht der Client den Namen des Datenbankservers mit dem von ServerName angegebenen Wert. Wenn der Datenbankservername übereinstimmt, kommt die Verbindung zustande und der Client aktualisiert seine sasrv.ini-Datei. Wenn der Datenbankservername nicht übereinstimmt, versucht der Client eine Verbindung über UDP-Serversuchanforderungen. Siehe Schritt 4: UDP-Datenbankserver-Suchanforderungen absetzen.
- Wenn der Client keine Verbindung herstellen kann und ein ServerName-Parameter angegeben ist, versucht der Client eine Verbindung über UDP-Serversuchanforderungen. Siehe Schritt 4: UDP-Datenbankserver-Suchanforderungen absetzen.
- Wenn der Client keine Verbindung herstellen kann und der ServerName-Parameter nicht angegeben wurde, schlägt die Verbindung fehl.
- Schritt 3: Beispiel Angenommen, es gibt einen Computer mit dem Hostnamen kangaroo und der IP-Adresse 10.25.13.5. Ein Datenbankserver namens joey läuft auf diesem Computer auf Port 49152. Dies ist das erste Mal, dass sich der Client mit diesem Server verbindet, daher gibt es keine im Cache gespeicherte Adresse in seiner sasrv.ini-Datei.
  Für die Verbindungszeichenfolge CommLinks=TCPIP(Host=kangaroo:49152);ServerName=joey verbindet sich der Client über TCP/IP mit 10.25.13.5:49152 und prüft dann, ob der verbundene Server joey heißt. Die Verbindung ist erfolgreich, daher aktualisiert der Client seine sasrv.ini-Datei.
Schritt 4: UDP-Datenbankserver-Suchanforderungen absetzen Der SQL Anywhere-Client sendet UDP-Datenbankserver-Suchanforderungen nur aus, wenn die Verbindungszeichenfolge den ServerName-Verbindungsparameter enthält und die DoBroadcast-Protokolloption auf DIRECT oder ALL eingestellt ist.
- Wenn "DoBroadcast=DIRECT" eingestellt ist oder die HOST-Protokolloption angegeben wurde, sendet der Client UDP-Serversuchpakete an die angegebene(n) Adresse(n). Wenn ein Port angegeben ist (in der HOST-Protokolloption oder der ServerPort-Protokolloption), wird die UDP-Serversuchanforderung an den angegebenen Port gesendet. Andernfalls wird die Anforderung an den Standardport 2638 gesendet.
- Wenn "DoBroadcast=ALL" eingestellt ist und keine HOST-Protokolloption angegeben wurde, ermittelt der Client die Broadcast-Adresse des Subnetzes für jede IP-Adresse. Wenn die ServerPort-Protokolloption angegeben ist, sendet der Client UDP-Broadcast-Serversuchpakete an den angegebenen Port. Andernfalls werden die UDP-Broadcast-Pakete an den Standardport 2638 gesendet.
Außer wenn beim Start des Datenbankservers die Option -sb 0 Option angegeben wurde, warten alle Datenbankserver am Port 2638 auf UDP-Pakete. Wenn ein Datenbankserver eine UDP-Serversuchanforderung empfängt, vergleicht der Datenbankserver seinen Namen mit dem angegebenen Namen im Anforderungspaket. Wenn die Namen übereinstimmen, sendet der Datenbankserver ein UDP-Antwortpaket zurück, das seine IP-Adresse und die Portnummer enthält. Nur der übereinstimmende Datenbankserver sendet ein Antwortpaket.

Standardmäßig wartet der Client bis zu fünf Sekunden auf eine UDP-Antwort. Wenn keine Antworten ankommen, werden die UDP-Pakete jede Sekunde erneut gesendet, bis bei diesem Prozess eine Zeitüberschreitung eintritt.

Wenn der Client das UDP-Antwortpaket empfängt, versucht der Client eine TCP/IP-Verbindung mit der Adresse und dem Port, die im Paket angegeben sind.

Wenn sich der Client mit einem Datenbankserver verbinden kann, kommt die Verbindung erfolgreich zustande. Der Client aktualisiert seine sasrv.ini-Datei.
Hinweis

UDP-Pakete können folgende Datenbankserver nicht finden:
- Einen Datenbankserver, der sich in einem anderen Subnetz befindet. UDP-Serversuch-Broadcast-Pakete können den Datenbankserver nur finden, wenn das Broadcast Repeater-Dienstprogramm verwendet wird. Siehe Broadcast Repeater-Dienstprogramm (dbns16).
- Einen Datenbankserver unter Mac OS X, der nicht am Port 2638 auf Verbindungen wartet. Siehe ServerPort-Protokolloption (PORT).
- Einen Datenbankserver, der mit der Option -sb 0 gestartet wurde. Siehe Datenbankserveroption -sb .
- Einen Datenbankserver, dessen UDP-Anforderungen durch eine Firewall, einen Router oder ein Gateway blockiert sind. Siehe Firewall-Verbindungen.
In beiden Fällen sollte die Angabe der Adresse des Datenbankservers (einschließlich der Portnummer) in der HOST-Protokolloption eine erfolgreiche Verbindung des Clients ermöglichen.
- Schritt 4: Beispiel Angenommen, es gibt einen Computer mit dem Hostnamen kangaroo und der IP-Adresse 10.25.13.5. Ein Datenbankserver namens joey läuft auf diesem Computer auf Port 49152. Dies ist das erste Mal, dass sich der Client mit diesem Server verbindet, daher gibt es keine im Cache gespeicherte Adresse in seiner sasrv.ini-Datei. Die Verbindung wird von einem PC auf demselben Subnetz wie kangaroo versucht und die Broadcast-Adresse für dieses Subnetz ist 10.25.13.255.
  Für die Verbindungszeichenfolge CommLinks=TCPIP;ServerName=joeysendet der Client UDP-Server-Broadcast-Anforderungen an die Broadcast-Adresse 10.25.13.255:2638. Der Datenbankserver joey wartet an der UDP-Adresse 10.25.13.5.2638 auf Verbindungen und antwortet mit der Adresse 10.25.13.5:49152. Der Client stellt eine Verbindung über TCP/IP mit 10.25.13.5:49152 her. Die Verbindung ist erfolgreich, daher aktualisiert der Client seine sasrv.ini-Datei.

Kommentieren Sie diese Seite in DocCommentXchange.