PDA

View Full Version : SQLCODE -805 beim Zugriff auf ein fernes System



Seiten : 1 [2] 3 4

mahones
31-03-20, 15:34
Danke, der PRTSQLINF hat mich auf die richtige Spur gebracht...
Ich habe beim CRTSQLRPGI die Parameter aber schon angepasst, denn ein nachträgliches CRTSQLPKG wollte mir nicht gelingen. Außerdem sind die Berechtigungen für den angegebenen User auch mit *ALL korrekt, denke ich.
Aber nach ein paar Anpassungen im Programm (z.B. RELEASE der RDB) klappt das mickrige SELECT nun zumindest. Jetzt schauen wir nach dem Verbindungsaufbau, denn der dauert noch seeehr lange.

BenderD
31-03-20, 15:44
Danke, der PRTSQLINF hat mich auf die richtige Spur gebracht...
Ich habe beim CRTSQLRPGI die Parameter aber schon angepasst, denn ein nachträgliches CRTSQLPKG wollte mir nicht gelingen. Außerdem sind die Berechtigungen für den angegebenen User auch mit *ALL korrekt, denke ich.
Aber nach ein paar Anpassungen im Programm (z.B. RELEASE der RDB) klappt das mickrige SELECT nun zumindest. Jetzt schauen wir nach dem Verbindungsaufbau, denn der dauert noch seeehr lange.

Bist Du sicher, dass das der Verbindungsaufbau ist? Fehlende Indexe werden beim verteilten Zugriff natürlich doppelt bestraft. Da würde ich mal ein PRTSQLINF auf das Package machen. Den Job unter debug laufen lassen und mal sehen, was es da so vor hat.

D*B

mahones
01-04-20, 11:01
Wir haben mittels DBMON gesehen, dass der CONNECT (laut SQL Statement summary) mehr als 10s dauert. OPEN, FETCH, etc. dauern nur einige ms.

Ist das Programm, bzw. der SQL-Zugriff als solches, damit aus dem Schneider?

Welche Einstellungen muss man sich dazu anschauen?

BenderD
01-04-20, 11:11
... das sollte alles im unteren millisekunden Bereich liegen. 10 sec ist gröbst daneben und selbst durch Netzwerk oder Subsystem Konfiguration kaum erklärbar. Was ist denn sonst so auf der Maschine los?

mahones
01-04-20, 11:34
Eigentlich nicht viel und erst recht nicht mehr als sonst.
Die Maschine ist (so sagten andere externe Partner) auch ausreichend groß dimensioniert.
(QMODEL > 42A, PRCFEAT > EP1F)
Beide Systeme befinden sich auf einer physischen Maschine, aber auf 2 LPAR
Die 128GB RAM sind auf 96 / 32 aufgeteilt...

BenderD
01-04-20, 12:00
... bleibt das bei mehreren connects nacheinander aus demselben Job genauso langsam? bei verschiedenen Jobs?

mahones
01-04-20, 13:18
Ja, wenn ich das Programm mehrmals hintereinander aufrufe (selbe Sitzung = selber Job), dauert jeder Aufruf so lange!
Wenn ich es parallel auf mehreren Sitzungen aufrufe, dauert jeder einzelne Aufruf auch so lange...

BenderD
01-04-20, 13:40
... da gabs mal was mit DNS Lookup - ich würde da mal software defect reklamieren.

mahones
01-04-20, 14:02
Ohoh, es geht immer weiter in Regionen, die mir unbekannt sind.
Heißt das übersetzt: "am besten ein Ticket bei der IBM aufmachen"?

Fuerchau
01-04-20, 14:15
Mach mal nur einen PING von deiner Maschine zur RDB-Maschine.
Im Joblog gibts dann die Antwortzeiten.
Wenn du per WRKRDBDIRE die IP statt des Namens im Feld IP-Adresse eingibst, sparst du die DNS und kannst den Unterschied messen da dann DNS nicht benötigt wird.