View Full Version : View vs LF / Performance
Hi *all
ich habe ein, für mich seltsames Verhalten bei einer Kunden AS400 entdeckt.
Wir lesen mit Leseprogrammen. Diese werden von einem Generator erzeugt und sind daher immer richtig. Es gibt Leseprogramme die ein LF lesen (Setll read ...) und eines, das via SQL in einer vom Kunden wählbaren Sortfolge liest. Ganz neu gibt es eins, das jede beliebige Datei und damit auch View's (vom Kunden erstellt) liest.
Nun ist aufgefallen, das das lesen einer VIEW mit dem 'ich kann alles' Programm um Faktor 20 schneller geht als das lesen mit dem SQL Leseprogramm. Die Sortfolge ist in beiden Fällen gleich, der Feldvorrat der View ist 1:1 der des PF, die LF's haben den Satzformatnamen wie das PF (und somit auch alle Felder).
Da das 'ich kann alles' Pgm erheblich mehr 'drumherrum' macht, als die Pgmme, die Speziell für die Datei ausgelegt sind, versteh ich nix.
Es ist eine 520 mit 1000/60 CPW mit V5R3
Klar, die Verarbeitung von SQL-Beschriebenen Dateien ist schneller als DDS aber so heftig ??
gibt's ne Erklährung oder ein PTF ?
Die Datenbank ist (auch sonst im 'normalen' Betrieb grotten lahm (DDS Dateien, wenig SQL)
Danke
Robi
Also, für SQL macht es keinen Unterschied, ob die Datei DDS oder SQL-basiert ist.
Was die Performance angeht, so kann man einiges aus dem Joblog entnehmen, wenn man das Programm mittels STRDBG startet.
Also, für SQL macht es keinen Unterschied, ob die Datei DDS oder SQL-basiert ist.
Das dachte ich auch, (scheintbar) ist es nicht so!
Beide SQL-Lesevorgänge verwenden Lt. STRDBG den selben Index. Das Verhalten ist jederzeit nachvollziebar
(auf der Kunden AS400, bei uns nicht(aber unsere is auch ein bisserl schneller))
Das 'ich kann alles' Leseprogramm hatte das 'nur-eine-Datei' Leseprogram als Mutter, das zusammenbauen der Satzauswahl , das lesen usw. ist identisch
noch ne idee ?
Robi
Das ist ja genau das Problem.
Auf Kundenmaschinen sind die Datenbestände oft sehr viel größer, so dass eine Analyse nur auf dem Kundensystem möglich ist (auch mit STRDBG).
Es gibt ggf. einen winzigen Unterschied zwischen DDS und SQL und der betrifft REUSEDLT, der bei DDS häufig auf *NO steht, bei SQL immer auf *YES ist.
Ansonsten bezieht SQL seine Informationen grundsätzlich aus dem Repository (QSYS2/QSYS*-Dateien), daher macht dies für SQL keinen Unterschied.
Sicherlich gibt es noch den Unterschied der CPW's.
Erfolgt der SQL im Dialog, bin ich bei 60CPW beschränkt.
Verwende ich für dynamisches SQL CLI (also die C-SQL-Funktionen), kann ich den SQL in einen Batch-Serverjob verlegen, so dass dafür die Batch-CPW genutzt werden kann.
jetzt liegst Du falsch.
Reuse in einer VIEW ?
Nochmal :
-Ein PF (mit reuse)
-Eine VIEW mit allen Feldern des PF, ohne Satzauswahl
-Embeddet SQL auf die PF, verwendet Index 29 (strdbg)benötigt 15 sekunden
-Embeddet SQL auf die VIEW, voll dynamisch, alles zur Laufzeit ermittelt, verwendet Index 29 (strdbg) benötigt 1 Sekunde.
Hätt ich's nicht gesehen, würd ich es nicht glauben!
Werde mit einem entsprechend großen Datenbestand versuchen das bei uns nachzubilden.
Robi
Wie sieht denn der embedded SQL und der generierte SQL aus ?
Vielleicht wird ja im embedded SQL selber noch eine Satzauswahl getroffen, die im generierten SQL mittels where bereits durchgeführt wird ?
Somit könnte der Unterschied in den Anzahl Operationen liegen, die benötigt werden.
Schau mal mittels DSPJOB->14 bei den geöffneten Dateien auf die Anzahl IO's !
PS:
Der REUSEDLT betrifft natürlich die PF, aber ich kann eben eine PF per DDS oder SQL erstellen, und dann kommt es bei der Verwendung dieses Parameters eben zu diesem Unterschied.
Die IO's werd ich nochmal prüfen (montag)
Die SQL-Statements sind ohne group, ohne having mit völlig identischem 'where feld = ... and(feld = ...or feld = ...)
(sehr lang aber ziemlich trivial und absolut gleich, da sie vom selben Programm zur Laufzeit zusammengebaut werden
mal sehn was der test bei uns bringt
es ist mir unbegreiflich !!
Robi
Hallo Robi,
nur nochmal um sicher zu gehen:
Die dynamischen SQLs verwenden entweder direkt die physische Datei oder die SQL view?
Sie verwenden jedoch nicht die logischen Dateien oder?
Wenn logische Dateien verwendet würden, gäbe es eine Erklärung:
Der Query Dispatcher, der entscheidet, ob ein SQL-Statement mit der CQE (classical query engine) oder der SQE (SQL query engine) ausgeführt wird, reroutet ein SQL-Statement gnadenlos an die CQE, wenn eine logische Datei angesprochen wird. Dieses Rerouting bewirkt z.T. gewaltige Performance-Einbußen. (Allerdings nicht in dem Maße, wie Du es beschreibst!)
Birgitta
@Birgitta
Das würde aber obige Situation nicht erklären.
Da die voll dynamischen SQL's auf die VIEW gehen, würden diese also an die CQE gehen und damit langsamer laufen, sie sind aber eindeutig schneller !!!
Der embedded SQL geht an die PF, würde also die SQE gehen, läuft aber langsamer.
Wie erklärt sich das mit deiner Theorie ?
Wenn man den voll dynmaischen SQL also an die PF bindet, läuft dieser dann genauso langsam wie der embedded SQL ?
@Brigitta
Das eine Pgm liest mit embedded SQL das PF (langsam)
Dieses Pgm wurde bei der Erstellung der Datei generiert und kennt die Datei und die Felder.
Das andere Pgm liest die VIEW, weis nix, und muß daher alles aus Dateien lesen, zusammenbauen und dann das SQL-Statement bilden.
Was noch aufgefallen ist:
Der Job, den ich in diesem Zusammenhang in einem anderen Post genannt habe schreibt permannent die hier betroffene PF
Kann es sein, daß die PF Behandlung genauer sein will als die VIEW Behandlung und dadurch langsamer wird?
Der Job schreibt Daten, die in der Sortfolge meines Subfile's sich 'dazwischen' mischen
Bsp.: der Unique key ist LFNR und wird permanennt hochgezählt, die Anzeige erfolgt nach auftrag, position, LFNR
@Fuerchau
PS: Bei der Erstellung des 'ich-kann-alles' Pgm's war Du hier im Forum helfend beteiligt. http://www.rlpforen.de/showthread.php?t=6996
Und das Ding ist super geworden !!!
Der Performancetest bei uns ist in Arbeit,
werde das Ergebnis posten, allerdings ohne das ein job permanennt daten 'dazwischen' schiebt
Robi