View vs LF / Performance

[Robi]

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

[Fuerchau]

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.

[Robi]

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

[Fuerchau]

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.

[Robi]

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

[Fuerchau]

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.

[Robi]

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

[B.Hauser]

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

[Fuerchau]

@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 ?

[Robi]

@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

[Robi]

sch... ade
neue erkentnis :
Diseer permanennt schreibende Job schreibt nach Aussage des Kunden bisher in die Testumgebung!
Daher kann der Performance unterschied nicht daher kommen
Robi

[Fuerchau]

So, noch mal ein paar Klarstellungen:

Eine VIEW ist ja kein Index, kann also für Optiierungszwecke nicht verwendet werden sondern dient ausschließlich der Sicht auf die Daten.
Enthält eine View nichts weiter als einen "select * from myfile" kann ich sie mir auch sparen.
Eine View ist nur dann sinnvoll, wenn sie eine ANDERE Sicht der Daten enthält.
Ansonsten geht der SQL nämlich sowieso auf die PF.

Enthält eine View bereits eigene Where-Klauseln, "kann" es kritsch werden, insbesonders dann, wenn zusätzlich noch Group und Having enthalten ist.
Wenn man dann noch einen Select auf die View mit Where und/oder Group macht erzwingt man einen Tablescan.

Dies scheint aber auf deine View so nicht zuzutreffen.
Mich würde die Syntax der View (SQL-Befehl) mal interessieren.

Andererseits gibt es noch ein Problem mit Sortierfolgen.
Am häufigsten wird die Sortierfolge *HEX verwendet, was die schnellste ist.

Wenn man allerdings *LANGID verwendet, wirds kompliziert, da in diesen Fällen erst Zugriffspfade aufgebaut werden müssen.
Hilfreich sind dann tatsächlich LF's die bereits *LANGID-Sortierfelder enthalten. View's gehen nicht, da diese keinen OrderBy enthalten dürfen.

Zur Performancesteigerung hilft nur eine LF bzw. ein Index (CREATE INDEX) !

Nun noch mal zu deinem RPG-Programm:

Prüfe mal die SQL-Umwandlungsoptionen bzw. die "set option"-Anweisung.

Führe das Programm noch mal mittels STRDBG UPDPROD(*YES) aus, dazu muss ein Programm nicht debugfähig sein, es kommt nur auf die Joblog-Meldungen an.

Ab V5R2 werden nicht immer Zugriffspfade aufgebaut, sondern Hash-Tabellen verwendet. Leider gibt es da keine Zeitangaben, wie lange er dafür gebraucht hat.
Desweiteren kannst du die Zeiten zwischen den Meldungen (F1 auf der Nachricht) mal festhalten um festzustellen, wieviel Zeit zwischen den einzelnen Schritten bis hin zu "ODP erstellt" und sogar zu "n Zeilen abgerufen" und vergleiche dies zwischen den beiden Programmen.

Das parallele Schreiben hat in soweit keine Auswirkungen, als dass bei einem Vorwärts-Cursor ein Schnappschuss gebildet wird.