ODBC Verbindung V5R4 vs. V6R1 Performance Probleme

[fighter3582]

Hallo Zusammen,

wir nutzen Windows seitig die ODBC Verbindung um auf die DB der i5 zuzugreifen. Unter V5R4M0 dauert das Anmelden an der DB über diese ODBC Verbindung nur weinige Sekunden. Jetzt aber stellen wir die ODBC Quelle um auf ein V6R1 System mit der gleichen DB im Hintergrund. Dann dauert das Anmelden an der DB 3 Minuten. Auch das INSERT oder ähnliches dauert ewig lange.

Hat jemand eine Idee woran dies liegen kann? Wie gesagt DB ist die gleiche. Die V6R1 Maschine ist von der Leistung her wesentlich schneller.

Ich verzweifel gerade ein wenig...

Gruß Fighter3582

[AS400.lehrling]

Hat sich eventuell etwas an den Zugriffspfaden, oder usr geändert

Gibt es Mitteilungen /Meldungen Qsysopr oder Qsecofr

Gruß AS400.lehrling

[andreaspr@aon.at]

Welche Version vom ODBC Treiber verwendet ihr?
Du könntest Probieren wie lange es mit der neuen Version dauert.

Oder es fehlen ein paar wichtige PTFs im System.

Ich würde zuerst mal mit dem ODBC Treiber anfangen.

lg Andreas

[BenderD]

... die Angaben sind ein wenig knapp:
- upgrade auf 6.1 oder Neu Installation?
- Mengenvolumen der Verbindungen?
- ein paar Sekunden ist auch schon viel zu lange! Das muss normal deutlich im Subsekunden Bereich liegen, ist das mal untersucht worden?

D*B

PS: PTF ist bei neuem Release immer ein Kandidat.

[Fuerchau]

Und der ODBC-Treiber selber ist überhaupt der letzte in der Kette und hat bzgl. Performance überhaupt keine Relevanz für die Verarbeitungszeit auf der AS/400.

Durch den Wegfall der CQE ab V6 und die teilweise Verwendung von LF's mit Select/Omit ergeben sich da leider neue "Optimierungen" der SQE die halt manchmal auch schlechter sind.

Hier hilft nur eine neue Analyse der SQL's (Visual Explain, Debug-Modus über ODBC-Konfig einstellbar) und die Maßnahmen zur Verbesserung der Performance ergreifen.

Ich hatte die Tage eine Order-By-Fehler, die Sortierung wurde überhaupt nicht durchgeführt.
Nach minimaler Umstellung klappte die Sortierung dann wieder.

Die SQE ist da leider auch nicht viel besser als die CQE.

[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