ODBC Verbindung V5R4 vs. V6R1 Performance Probleme

[fighter3582]

Also um dies noch ein wenig genauer auszuführen:

Wir haben die Datenbank mit den Indexwerten unseres Archivsystems auf Basis der DB2/400 Datenbank. Von einem Windows 2008R2 Server machen wir einen ODBC Zugriff auf diese Datenbanken. Dies hat unter V5R4 auch reibungslos und schnell funktioniert. Jetzt nach dem Update auf V6R1 ist dieser Zugriff sehr langsam. Dauert teilweise bis zu 3-5 Minuten. Wir haben alle Kum PTF´s Hiper PTF Gruppen PTF und Datenbank PTF´s die für V6R1 verfügbar waren installiert. Meiner Meinung nach kann es nur etwas mit der Einstellung unter V6R1 zu tun haben. Wie gesagt hat es unter V5R4 reibungslos funktioniert und ich habe Kunden, bei denen es unter V7R1 ebenfalls reibungslos läuft.

[BenderD]

.. da stellt sich zuerst die Frage, was da solange dauert: und Zeiten im Minutenbereich deuten da in Richtung ernsthaftester Netzwerkprobleme, oder Aufbau temporärer Indexe und/oder full table scans bei großen Datenbeständen oder ernsthafteste Ressourcen Engpässe des Servers, oder Bugs in der Query engine. Netzwerk und Server Engpässe müssten auch auf andere Applikationen/Zugriffe durchschlagen, Bugs scheinen auszuscheiden. Dann ist der nächste Schritt der Einsatz des Database Monitors (STRDBMON), dann hat man in einem Tag raus, wo der Hund begraben ist.

D*B

[andreaspr@aon.at]

Ich würde nicht unbedingt NUR in der DB2 den Fehler suchen.
Das Problem könnte AUCH in der Windows 2008.. Büchse sein.
Läuft das gleiche Programm auf einem anderen Rechner auch so langsam?
Ich weis auch nicht wie alt der ODBC-Treiber auf dem Win2008er ist und in wie fern der mit 6.1 Probleme machen könnte, wenn dieser aus der Steinzeit kommt.
Wenn das Login am System schon so lange dauert klingt das für mich nicht nach einem SQE oder CQE Problem.

Probier einfach das PGM auf einem anderen PC aus. Das ist schnell und einfach zu testen!

Nachtrag: Ab 6.1 ist in der QAQQINI der Eintrag IGNORE_DERIVED_INDEX per Default auf *YES. Davor war dieser auf *NO.
Du kannst auch probieren diesen auf *NO zu setzen. Wenn ihr NUR Indize mit Select/Omit habt könnte das auch ein Problem darstellen.
Da ab 7.1 die SQE auch mit diesen Indize arbeiten kann, gibt es das Problem da nicht mehr.

lg Andreas

[Fuerchau]

Ich greife selber auch mit dem ODBC-Treiber von V5R4 auf ein System V6R1 ohne Probleme zu.
Nochmal: Der ODBC-treiber spielt da überhaupt keine Rolle!

Bzgl. IGNORE_DERIVED_INDEX begibt man sich ggf. auf die richtige Spur.
Durch die Änderung des Defaults und meistens der Nichtexistenz der QAQQINI in der QUSRSYS ergibt sich da schon mal das eine oder andere Problem.

QAQQINI per CRTDUPOBJ aus der QSYS in die QUSRSYS kopieren (Defaulteinstellung von CHGQRYA) und den Wert mal versuchsweise auf *YES ändern (per SQL-Update oder -Insert).

[B.Hauser]

QAQQINI per CRTDUPOBJ aus der QSYS in die QUSRSYS kopieren (Defaulteinstellung von CHGQRYA) und den Wert mal versuchsweise auf *YES ändern (per SQL-Update oder -Insert).

Der Standardwert für IGNORE_DERIVED_INDEX in der QAQQINI wurde mit Release 6.1 auf *YES geändert!

Birgitta