View Full Version : Performance, Zugriffspfade
nein bring ich auch nicht durcheinander .
Ich bin mir halt nur nicht sicher wie die AS/400 im Hintergrund den Select der LF'S verarbeitet .
S s1 CMP(LT 60)
s2 CMP(NE 'D')
Werden die Daten im Hintergrund per SQL selektiert, alle nicht benötigten Sätze und S s1 CMP(LT 60)
s2 CMP(NE 'D') schon mal ausgefiltert und der Rest in den Speicher geladen oder ,oder, oder wie treiben die das . Das wäre interessant .
@robi muss ich mal ausprobieren . Aber was würde das dann im Umkehrschluss heissen wenn ich die RPG-Zyklus IP etc geschichte laufen lassen . Bringt mir ja nicht viel wenn da schneller läuft.
Oder welche erkenntnis könnte man dann rausziehen ?
Bei Native-IO ist SQL überhaupt nicht im Spiel.
Da werden die guten alten klassischen Zugriffe verwendet.
Wenn ein Index angelegt ist werden über den Schlüssel direkt nur diese Sätze gelesen.
Wenn kein Index angelegt ist oder immer wieder temporär aufgebaut wird, werden eben die Sätze der PF's sequentiell verarbeitet und die Bedingungen geprüft.
Warum nimmst du denn nicht einfach SQL und legst die Indizes die SQL vorschlägt dann an?
Wenn es dann (deutlich) schneller ist könntest du immerhin dein Pgm darauf umstellen oder das in ein lesepgm packen das du rufst.
Erkentnis könnte sein: Diese Art des verketteten Zugriffs ist "suboptimal". :mad:
Also 2 Felder zusätzlich an die Datei, Trigger drauf der die Felder in abh. von "s1 LT 60" und "S2 ne D" setzt, die verknüpfen und die beiden Felder im key nach vorne.
Robi
(der weiß das das meistens keine alternative ist)
Wie groß sind denn die F1-F7 Felder
habe beim crtlf noch das entdeckt (hat mich noch nie interessiert )
Größe des Zugriffspfads . . . . *MAX1TB *MAX1TB, *MAX4GB
Log. Seitengröße d. Zugr.pfads *KEYLEN *KEYLEN, 8, 16, 32, 64...
Zugriffspfadwartung . . . . . . *IMMED *IMMED, *DLY, *REBLD
Zugriffspfad wiederherstellen . *NO, *AFTIPL, *IPL
Schlüsselzugriffspfad erzwing. *NO *NO, *YES
ist dein lf ggf hier zu klein?
robi
größe des Zugriffspfads . . . . der LF steht auf *MAX1TB
Index size . . . . . . . . . . . . . . : 762617856
12 0
12 0
1
5
6
7 0
8
Im Normalfall würde die AS/400 meckern, wenn dieser Bereich zu klein wird und kein Indexeintrag mehr möglich ist. Dann ist die Daten nämlich voll!
Zum Vergleich:
Ich habe hier eine Datei mit ca. 41Mio Sätzen, einen Index mit 10 Feldern, Indexgröße z.Zt. 2,3 GB, da ist also noch Luft.
DB ist da schon andere Größenordnungen gewöhnt (PF mit 1000 Mio-Sätzen).
Der Index scheint ja angelegt zu sein. Aber irgendwas stimmt damit tatsächlich nicht wenn du solche Antwortzeiten hast.
Werden denn viele Änderungen an den PF's durchgeführt?
Bevor das Programm die LF öffnet, steht beim DSPFD dann "Zugriffspfad gültig . . . . . . . . . . : Ja"?
Wenn nicht liegt genau da dann das Problem.
Vielleicht kommst du um die Meldung an IBM nicht herum.
ich kann mir das jetzt wirklich nur so erklären .
Er muss die Daten beim ersten Aufruf des Tages in den Speicher laden und das dauert ewig lange . Sind sie mal drinnen Dasnn gehts "ratz fatz" . Ist ja bei einer View die über X Dateien geht und Millonen Datensätze durchratern muss das gleiche , Erster Aufruf Dauert immer extrem länger als der Zweite ..
Geht das beim ersten Aufruf Satz für Satz sehr langsam oder dauert das erst sehr lang und geht dann ratz-fatz?
Gegen "ratz fatz" spricht die extrem lange Laufzeit des obigen Mini-RPG's.
Bei einer View kann ich das tatsächlich mit Indizes extrem beschleunigen.
Ich hatte gerade einen akuten Fall in dem ein komplexer SQL (incl. derived Table mit Group by) ca. 10 Sätze je Sekunde lieferte.
Nach Berücksichtigung der vorhandenen Keystrukturen und Ergänzung um vorgeschlagene Schlüssel werden nun ca. 1500 Sätze je Sekunde geliefert.
Also obige LF kann als View mit Indizes und per SQL die gewünschten Ergebnisse sehr schnell liefern.
Eine View kann zwar per Native-IO bearbeitet werden aber auf Grund des fehlenden "order by" eben nur Sequentiell und ohne SETLL.