Performance, Zugriffspfade

[CKA]

hier das Original : Copy and Paste . Ausser Feldamen usw geändert . Man weiss ja nie
Aber trotzdem ich verstehs nicht ganz . Ist das gleiche verhalten wie bei einer View nur das eine View nicht gekeyed etc ist . Erster Aufruf dauert Ewig , zweiter geht schnell, weil er eben so wie ich mir das vorstelle, Indizes , etc in den speicher schreibt und sich das merkt....

R r1 PFILE(PFFILE1)
K f1
K f2
K f3
K f4
K f5
K f6
K f7
S s1 CMP(LE 45)
s2 CMP(NE 'D')

R R2 PFILE(PFFILE2)
K f1
K f2
K f3
K f4
K f5
K f6
K f7
S s1 CMP(LT 60)
s2 CMP(NE 'D')

Ich verstehs nicht ganz .... Wie gesagt warum er beim ersten mal eine gefühlte ewigkeit braucht und beim 2 mal sehr schnell für alle User ist. Also muss er doch dieses ganze Drama in den Speicher laden .
Andererseits was ich nicht kapiere ist folgendes:
Habe die, alles in einer Testlib, PF's kopiert , alle LF's neu erstellt und dann mein Testpgm laufen lassen. NAch 7 STD noch nicht fertig . Sieht man auch am i/0 counter das er alle Sekunden nur ein paar Sätze liest . 50-150 Sätze .

[Fuerchau]

Es scheint aber ganz so, dass die AS/400 keinen Index aufbaut und daher dynamisch selektiert.
Über die Index-Felder F1 - F7 scheint es in den PF's auch keinen Index zu geben um den dynamischen Zugriff zu beschleunigen.
Wenn ich mir hier per DSPFD eine solche LF ansehe so finde ich folgende Hinweise:

Wartung des Zugriffspfads . . . . . . . . : MAINT *IMMED
Indexgröße . . . . . . . . . . . . . . : 32571392
Zugriffspfad gültig . . . . . . . . . . : Ja
Impl. gemeinsame Ben. des Zugriffspfads : Nein

Anzahl der Datenteildateien . . . . . . . : 6
Basiert auf Datei . . . . . . . . . . . . : WAKO
Bibliothek . . . . . . . . . . . . . . : RHDBD_16
Teildatei . . . . . . . . . . . . . . . : WAKO
Format der logischen Datei . . . . . . : WAKO1
Anzahl der Indexeinträge . . . . . . . : 9705
Basiert auf Datei . . . . . . . . . . . . : BEPM
Bibliothek . . . . . . . . . . . . . . : RHDBD_16
Teildatei . . . . . . . . . . . . . . . : BEPM
Format der logischen Datei . . . . . . : BEPM1
Anzahl der Indexeinträge . . . . . . . : 37121

Hier habe ich nun wiederum V7R1, da scheint das OS ein paar neue Funktionen bzgl. DYNSLT-Dateien zu haben denn diese weisen bei mir nun auch Indexeinträge auf. Bei passenden LF's sogar gemeinsame Index-Nutzung.

[Fuerchau]

Was den IO-Counter angeht so ist das auch nicht die Wahrheit.
Bei Input-Dateien wird geblockt und 1 IO entspricht dann einem Block, der je nach Satzlänge entsprechend viele Sätze hat.
Wie groß diese Blockgröße ist weiß ich nicht, ich schätze mal 32KB.
Außerdem zählt dieser nur die logischen IO's. Wieviele Plattenzugriffe sich dahinter verbergen erfährt man sowieso nicht.
Du müsstest die Datei als Update-File definieren, dann wird nicht geblockt (oder einen OVRDBF SEQONLY(*NO)) durchführen.

Bei DYNSLT (hier scheinbar automatisch) spielt die Existenz eines Keys über die PF's natürlich eine Rolle.
Zumal das OS hier eine klassische "Mehrwegeingabe", also das Mischen der Daten betreiben muss (im RPG also Input-Primary und Input-Secondary).

[CKA]

bei der zweiten PF , gibt es keine LF die diese Beiden Felder abdeckt .
S s1 CMP(LT 60)
s2 CMP(NE 'D')

ICh weiss ja nicht was die AS/400 im Hintergrund so treibt und was sie verwendet um die nicht benötigenten Sätze beim ersten Aufruf auszusortieren . Und das sind bei der weiten Datei mehr als 17 Millionen die nicht diesen Kriterien entsprechen .
Hab aber in meiner Testumgebung schon mal so eine LF angelegt . Hat aber nichts gebracht .
Also greift er im Hintergrunf bei Nativ anscheinend auch nicht auf diese LF zu um so schneller selektieren zu können . Fragen nichts als Fragen

[Robi]

Hast du die beiden LF mal einzelnd angelegt?
und endweder programiert oder mit dem guten alten MR (matching rekord) Input primary / input secondary gelesen.
Ist das ein Problem des zusammen lesens oder ein generelles mit der 2. LF
Robi

[Fuerchau]

Du darfst Native-IO und SQL nicht durcheinander bringen.
Bei Native-IO bestimmst du genau welche Datei, also auch LF, du verarbeitest.
Bei SQL kannst du zwar eine LF verwenden, aber SQL nimmt dann die PF, ergänzt die Whereklausel um die Select/Omits und sucht sich dann eine passende LF (ohne Select/Omit!!!) oder Index (hat (bisher) nie einen select/Omit, wobei das ja seit V6 wohl geht).
Außerdem unterstützt SQL keine Multiformat-LF's, dafür gibt's dann Views, die einen "Select ... Union all select ..." enthalten können.

Warum nun die AS/400 die Maintenance des Keys erst beim Open durchführt entzieht sich mir.
Andererseits deutet dein Langläuferprogramm darauf hin, dass gar kein Key angelegt wird.
Ich kann da auch nicht erklären was da bei dir falsch läuft.

Wenn du einen Wartungsvertrag hast dann gib doch mal eine Fehlermeldung an IBM ab.

[CKA]

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 ?

[Fuerchau]

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?

[Robi]

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".
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)

[Robi]

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

[CKA]

größe des Zugriffspfads . . . . der LF steht auf *MAX1TB
Index size . . . . . . . . . . . . . . : 762617856
12 0
12 0
1
5
6
7 0
8

[Fuerchau]

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).