Performance, Zugriffspfade

[AG1965_2]

Nicht alle lesen Deine Nachrichten ganz genau, so wie Du die Antworten nicht ganz genau liest.
Das ist das Lästige an Menschen. :-)

[andreaspr@aon.at]

ps: Wir greifen über ein RPGLE-Programm auf die Datei zu .
keyed setll
keyed READE
DOW NOT EOF(DATEI)

OK, dann fallen die SQE "Optimierungen" weg wenn ihr mit Native I/O arbeitet.

Aber auch ohne IPL und SQL kann es eben daran liegen, dass die Tabelle/LF erst in den Speicher geladen werden muss.
Wie groß sind denn die entsprechenden LF (in byte ... bzw. GB)?

[CKA]

also die beiden PF haben zusammen 36 GB . Rund 40 Millionen Datensätze .
Wie gesagt ich verstehe nur nicht wann er den Cache/Speicher oder was auch immer löscht damit er am nächsten Tag alles nochmal neu laden muss .
Das einzigste was rutergefahren wird ist die Qinter. Aber mit dem kann es doch auch nicht zusammenhängen oder ?

[Fuerchau]

Die Idee mit dem Speicher und der Größe lass mal weg, solche Probleme gibt's bei der AS/400 nicht.

Eine LF mit mehreren Satzformaten wird von SQL überhaupt nicht unterstützt.
Wenn du einen "Select * from MyLf" machst, nimmt SQL die dahinterliegende PF (in diesem Fall nur die 1. PF) und ergänzt diesen dann in der Whereklausel mit den Select/Omit-Definitionen.

Es kann also eigentlich nur an der Definition der LF liegen, dass hier DYNSLT evtl. automatisch angewendet wird. Erklärbar ist das aber so nicht.

Manchmal hilft ja auch ein Neuerstellen weil intern irgendwas kaputt/verbogen ist (RCLSTG).
Benenne die Datei mal um und lege die LF neu an.
Es müsste ein Hinweis kommen "Zugriffspfad wird aufgebaut".
Fehlt dieser, wird eben DYNSLT verwendet, aber ich weiß dann nicht warum.

[Pikachu]

Wie sehen die Dateidefinitionen der beiden logischen Dateien im RPG-Programm aus?

[BenderD]

... sind zwar gefühlte hundert Jahre her, dass ich DDS und Rekord Löffel Ekzem verwendet habe, aber wenn ich mir die Parameter vom CRTLF so ansehe...RECOVER steht im default auf *NO und FRCACCPPTH ebenfalls: Wenn denn nun beim ENDSBS QINTER ein Job, der diese Datei geöffnet hat, hart runtergesägt wird und der Access Path dabei dirty gesetzt wird, dann wird der erste Open bestraft, anschließend geht es wieder normal bis zum erneuten damage.

D*B

[Fuerchau]

Das mit dem Recover hatte ich auch so vermutet, FRCACCPATH geht aber in die Richtung FRCRATIO(1) was also nur bei Systemausfall (ohne Journalisierung) hilft.
Dagegen spricht dann obiges Mini-RPG mit einer Laufzeit jenseits der 7 Stunden.
Die Laufzeit sollte nicht länger sein als das separate Lesen der 2 beteiligten PF's.
Wenn dieses allerdings auch so lange dauert ist die Maschine einfach zu schwach. Denn 1 Mio Sätze je Minute sollten mindestens drin sein, eher erheblich schneller.

[Fuerchau]

Was den Parameter ACCPTHSIZ angeht so hat der Default sich diesbezüglich auf *MAX1TB geändert. Ohne dass wir hier eingegriffen haben sind durch Release- und Hardwarewechsel die LF's (also Restore der Lib's) alle LF's auf *MAX1TB geändert!
Ob das bereits durch V6 oder erst bei V7 passiert ist kann ich nicht sagen.
Dies hat aber mit obigem Problem nichts zu tun.

[BenderD]

Auf unserem System gibt es eine LF-Datei mit folgendem Aufbau:

R RECA PFILE(FILEA)
K FeldA
K FeldB
K FeldC
K FeldD

S FeldC CMP(LE 45)
FeldD CMP(NE 'D')

R RECB PFILE(FILEB)
K FeldA
K FeldB
K FeldC
K FeldD
S FeldC CMP(Lt 60)
FeldD CMP(NE 'D')

In beiden PF's sind sehr viele Sätze enthalten.
Nun kommt es morgens beim ersten Aufruf des PGMS zu einer sehr langen Laufzeit (X-Minuten), der zweite Aufruf geht dann sehr schnell.

beide haben MAINT(*IMMED),
Nur der erste Aufruf dauert sehr lange. Die anderen von anderen Usern etc geht dann "sehr schnell".

Die LF ist auch mit Maint(*immed).

also die beiden PF haben zusammen 36 GB . Rund 40 Millionen Datensätze .

er fängt an Sätze zu lesen aber EXTREM langsam . Wie gesagt erster Aufruf dauert mehrere Minuten und dann gehts schnell . Aber ja er hat 700000 gelöschte Sätze REUSEDLT = (*YES)

Die LF durchlesen von Anfang bis Ende .

Dieses kleine PGM lief nach 7 Stunden immer noch !!!!!

Habe jetzt mal testweise den Select der ersten LF auf LT30 gestellt. Jetzt muss er (das hab ich per SQL ausgewertet) nur noch 20000 Sätze bearbeiten . Läuft beim ersten mal 25 Sekunden . Beim 2ten Aufruf im Millisekundenbereich . Wenn ich den Selcet wieder auf LE 45 stelle ,18 Millionen Sätze werden bearbeitet läuft mein Mini-Progrämmchen über 7 STD.

Geht beim ersten Aufruf Satz für Satz sehr langsam .

Ich habe mir mal die Mühe gemacht alle Beschreibungen des Phänomens zusammen zu kopieren und alle Hypothesen weggelassen. Fangen wir am Besten am Schluss an:

- für 20.000 Sätze braucht es 25 Sekunden, für 18 Millionen 7 Std. Das sind konsistent circa 1000 Sätze pro Sekunde. Das ist nicht gerade schnell, aber auch nicht absurd langsam. Je nach Hardware (Geschwindigkeit der Platten, Auslastung, konkurrierende Workload etc.) Falls die Cache Batterie kaputt ist, wäre das sogar normal.

- das Ausgangsprogramm mit SETLL und reade dauert beim ersten Aufruf Minuten, später Millisekunden. Es arbeitet mit SETLL und dann reade, liest also wohl relativ wenig Sätze. Das passt zu den Millisekunden (1000 Sätze pro Sekunde), aber nicht zu den Minuten. Da schließt sich die spannende Frage an, was macht das Programm sonst noch, bzw. wie sieht dieses Programm denn genau aus und was treibt das Programm in den Minuten? Wieviele Sätze verarbeitet das Programm bei den Minuten? Wieviele bei den Millisekunden? Woher genau kommt die Information über die Laufzeiten? Ist das reproduzierbar, wenn ja, wie?

D*B