Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.

SQL Anywhere 12.0.1 (Deutsch) » SQL Anywhere Server - Datenbankadministration » Datenbank starten und Verbindung mit ihr herstellen » SQL Anywhere-Datenbankverbindungen » Verbindungsfehlerbehandlung

 

SQL Anywhere-Datenbankserver mit dem CommLinks=TCPIP-Verbindungsparameter ermitteln

Hinweis

In den meisten Fällen müssen Sie den HOST-Verbindungsparameter verwenden. Siehe Verbindungsparameter Host.

Sie sollten den Verbindungsparameter CommLinks (LINKS) nur dann verwenden, wenn Sie andere TCP/IP-Optionen als Host oder ServerPort (PORT) angeben müssen. Sie können nicht sowohl CommLinks als auch Host in einer 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 Finden der Datenbank.

  • 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 eingestellt 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: Versuch einer TCP/IP-Verbindung mit der (den) Adresse(n), die in der Host-Protokolloptionen angegeben ist/sind.

    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 auch 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 Caching der Datenbankserver-Adressinformationen der sasrv.ini-Datei im Cache für schnellere Verbindungen.

    • 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 Mit einem LDAP-Server verbinden.

  • Schritt 3: Versuch einer TCP/IP-Verbindung mit der (den) Adresse(n), die in der Host-Protokolloptionen angegeben ist/sind   Wenn die Host-Protokolloption nicht angegeben ist, versucht der SQL Anywhere-Client, den Server mit 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 werden, versucht der Client, sich mit jeder Adresse in der Reihenfolge zu verbinden, in der sie in der Host-Protolloption angegeben werden. Der Client versucht, Verbindungen aufzunehmen, 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 für die angegebene Adresse und Portnummer. 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:

    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.