View Full Version : Verbindung zur Datenbank bricht ab
Hallo zusammen,
seit wir unsere DDV-M Standleitung (FrameRelay) zwischen zwei i5 Maschinen auf eine IP Company Connect Verbindung mit Watchguard-VPN-Endgeräten umgestellt haben, bricht nach einer gewissen Zeit auf meinem PC die Verbindung im System i Navigator (SQL Prozeduren ausführen) zur entfernten i5 Datenbank ab.
Fehler SQL-Status: 08S01
Vendorencode: -99999
Nachricht: Kommunikations-Link-Fehler. (Software caused connection abort: recv failed)
Ähnliche Probleme haben wir bei anderen PC-Anwendungen, die über ODBC auf die entfernte i5 zugreifen.
Die i5 hat V5R4 (bekommt demnächst 7.1).
Auf dem Win-7-PC ist iAccess 7.1 mit aktuellem ServicePack inst. Unter iAccess V5R4 oder V6R1 tritt das Problem aber in Verbindung mit Win 7 oder XP genauso auf.
Es sieht so aus, als ob das ganze irgendwie mit den vorgestarteten Jobs (QZDASOINIT) zu tun haben könnte.
Leider bin ich hier nicht so tief im Thema und auch Google konnte nicht helfen.
Besten Dank für jeden Tipp.
Gruß Carsten
Hallo Carsten,
vielleicht hilft Dir dieser Link weiter:
http://www-912.ibm.com/s_dir/slkbase.nsf/1ac66549a21402188625680b0002037e/69cff834353af23e86256dde005cb32d?OpenDocument&Highlight=2,08S01
Da IP keine statische Verbindung ist, kann es durchaus zu Unterbrechungen kommen.
Normalerweise regelt dann die VPN, dass die Verbindung wiederhergestellt wird.
Jetzt liegt es allerdings an der VPN, den Clientport entsprechend wieder zu verwenden. Tut sie das nicht, ist das eine neue Verbindung und hat keinen Bezug zu aktuellen Verbindung, was den Timeout auslöst.
In der 5250-Sitzung (.ws-Profil) kann man einen Keepalive eintragen, manchmal hilfts.
In Windows kann man hierzu einen Keepalive einstellen:
Einstellung der TCP-Keepalive-Zeit für Windows-Server (http://www.consic.de/support/keepalive.htm)
Ob der hilft, liegt ggf. am VPN ob dieser auch durchgelassen wird.
Bei ODBC-Anwendungen sieht die Welt leider nicht ganz so gut aus.
Hier kann es beim ConnectionPooling zum Problem kommen, dass die unterbrochene Verbindung nicht wieder hergestellt werden kann.
Ich habe es mir mittlerweile angewöhnt, das ConnectionPooling abzuschalten.
Per eigenem Timer wird die Verbindung geschlossen, wenn innerhalb einer bestimmten Zeit kein SQL ausgelöst wurde. Bei einer erneuten Anfrage wird die Verbindung dann halt wieder geöffnet.
@timeout: casus knacksus ist doch zunächst wie lange da nix zurückkommt, häufig gibt es ernsthafte Designfehler in stored Procedures, oder Implementierungsfehler in der Datenbank (UDTF lässt grüßen).
@connection Pool: abbrechende Verbindungen während der Ausführung einer Anfrgae haben mit dem Pool nix zu tun. Ansonsten sind ordentliche (JDBC) Pools konfigurierbar, dass sie idletime überwachen bis hin zu einem keep alive check vor Ausführung, mit neu verbinden, falls erforderlich.
Wenn so morsche Bohlen wie Oops Nerv oder stored Procedures im Spiel sind, oder die Anwendung Designmängel haben könnte, ist zunächst weitere Ursachenforschung von Nöten. Ein Startpunkt können die Joblogs der Serverjobs sein.
D*B
Ich habe schon mit verschiedensten VPN's (Cisco, HOB, OpenVPN, WindowsVPN) genau die selben Probleme.
Manchmal hilft ein kleines VBS, dass z.B. jede Minute einen SQL losschickt, damit die VPN offen bleibt.
Manche VPN's haben halt Timeouts, wenn innerhalb einer Zeit kein Transfer stattfindet, dann wird die VPN getrennt.
Wobei durchaus auch "echte" Transfers geprüft werden, ein Ping oder Keepalive diesbezüglich ignoriert wird.
Das Wiederverbinden der VPN mit den selben Client-Ports klappt da eher selten.
Wenn die AS/400 dann noch eine Unterbrechung feststellt, werden auch die dortigen QZDA-Jobs getrennt.
Da hilft mitunter auch kein automatischer Reconnect des ConnectionPools (neue SQL-Sitzung), da bestimmte sitzungspezifische Einstellungen (APP-Initialisierungen mit diversen Info's in der QTEMP) nicht automatisch wieder da sind.
Sicherlich mag das auch als Design-Fehler gelten, aber die QTEMP bietet sich nun mal an, um das "Aufräumen" zu vereinfachen:).
... typische TCP/IP Timeouts liegen im Bereich von > 5 Minuten bis zu einer Stunde. Wenn eine SQL Anforderung in der Zeit noch nix zurückbringt, ist das für mich ein Designfehler, auch wenn solcher Unfug gerne in stored Procedures reinprogrammiert wird (Sticjhwort: Rückgabe Array statt offener Cursor). Wenn ein SQL Statemnet da nix zurückbringt, fehlt es an einem Index.
Wenn eine Transaktion länger als ein paar Sekunden nix von der Datenbank will, liegt meist ebenfalls ein Designfehler vor (Stichwort: dem Benutzer innerhalb einer Transaktion die Kontrolle geben).
Keep alive checks eines ordentlichen Pools lassen sich konfigurieren, üblich ist da eine relativ billige Abfrage; stellt man nun den entsprechenden Schwellenwert kleiner als den TCP Timeout, wird bei Bedarf automatisch reconnected.
Was Ooops Nerv angeht, der hält die Connection offen, weil er keinen Pool kann (hier haben wir den Murks!!!), wenn ich hier länger nix gemacht habe, muss ich per Hand reconnecten, oder renne auf den Hammer.
Folgerungen:
- ordentliches Werkzeug statt Spielzeug verwenden
- Schluss mit dem Missbrauch von stored-Procedures (meistens ist das Stuss!!!)
- in Applikationen pro Transaction eine frische Connection vom Pool holen
- Datenbanktransaktionen dürfen Benutzertransaktionen nicht überlappen
D*B
"- Schluss mit dem Missbrauch von stored-Procedures (meistens ist das Stuss!!!)
":
Sag das mal der IBM, die Schema-Abfragen per ODBC auch auf stored Procedures umgestellt haben, was nun ab und zu zu Query-Timeouts selbst auf leere Dateien führt, da die stored Procedure leider zu lange benötigt um Spalteninformationen aus der SYSCOLUMNS (mehrere Millionen Sätze) abzurufen (V7R1!).
ODBC-Anwendungen sollten natürlich immer mit Verbindungsabbrüchen und einem (Auto)Reconnect zurecht kommen.
Bei 5250-Anwendungen ist das eher lässtig.
Der Timeout bewegt sich aber häufig im Default bei 2 Stunden.
Hier könnte man halt auf der AS/400 die Inaktivitätszeiten nutzen und bei einer Inaktivität von 90 Minuten die Sitzung disconnecten (DSCJOB).
Bei der erneuten Anmeldung wird dann auch korrekt wieder aufgesetzt.
Sag das mal der IBM, die Schema-Abfragen per ODBC auch auf stored Procedures umgestellt haben, was nun ab und zu zu Query-Timeouts selbst auf leere Dateien führt, da die stored Procedure leider zu lange benötigt um Spalteninformationen aus der SYSCOLUMNS (mehrere Millionen Sätze) abzurufen (V7R1!).
... das ist so ein Fall von Dummfug, der dummfugigsten Sorte
Danke für die vielen Antworten und Lösungsansätze.
Den KeepAlive über das Utility cwbcopwr habe ich getestet, leider ohne Erfolg.
Die andere KeepAlive Einstelllung von Fuerchau über Windows habe ich so interpretiert, dass dies nur für Windows Server gilt, wir haben die Probleme aber am Client. Es gibt bereits eine ähnliche Einstellung in meinem Win 7, die aber wohl nichts bewirkt, zumindest nicht Richtung i5.
Als Workaround würde ich jetzt gerne regelmäßig eine simple SQL-Abfrage absetzen wollen, um die Verbindung aufrecht zu erhalten. Wie bzw. womit kann ich das am einfachsten realisieren?
Um der Sache weiter auf den Grund zu gehen, werde ich den Dienstleister kontaktieren, der die VPN Verbindung eingerichtet hat.
Allen ein schönes Wochenende.
Gruß Carsten
Am einfachsten mit einem kleinen VBScript (.vbs, .wsh).
Mittels "CreateObject" eine ADODB-Connection erstellen und in einer Schleife einfach jede Minute (sleep-Funktion in wsh) einen "select count(*) from sysibm.sysdummy1" absetzen.