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?

[holgerscherer]

also die beiden PF haben zusammen 36 GB . Rund 40 Millionen Datensätze . ...
Das einzigste was rutergefahren wird ist die Qinter. Aber mit dem kann es doch auch nicht zusammenhängen oder ?

Und nachts laufen keine Sicherungen, die den Hauptspeicher ein wenig anderweitig belasten? Im Zweifel (wenn die angesprochenen Optimierungsmöglichkeiten nicht greifen, und Ressourcen verfügbar sind) mit SETOBJACC experimentieren.

-h

[andreaspr@aon.at]

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

Wieso soll es so etwas bei der AS/400 nicht geben??
Wird eine Anwendung gestartet, werden auch bei der AS/400 die benötigten Objekte in den Speicher geladen.
Wenn die Daten Nachts nicht benötigt werden und eventuell ein paar Nacht-Batch Jobs laufen werden diese automatisch vom System aus dem Speicher entfernt.
Dieses Phänomen ist nicht selten.
Lese Optimierungen gibt es da evtl. wenn man SSDs verwendet und mit CHGPF die entsprechenden Tabellen beforzugt dieser Speichereinheit zuweist.

[Fuerchau]

Dann schreib doch ein kleines Miniprogramm und lass es als Prestart-Job im QINTER laufen.
Dies macht nichts anderes als Open der Datei und schlafen bis zum Ende des Subsystems.

SETOBJACC bringt nur dann etwas, wenn ein eigener Speicherpool verfügbar ist. Ansonsten können die Daten sehr schnell wieder verdrängt werden. Ins besonders, wenn Speicher sowieso schon knapp ist.
SETOBJACC hat auch den Nachteil, dass die gesamte Datei bzw. der gesamte Index in den Speicher geladen wird. Bei wie hier Millionen von Datensätzen, von denen sicherlich nicht alle benötigt werden, wird dann viel zu viel geladen.

Was mich noch interessiert:
Wenn das Programm mehrere Minuten "hängt", was macht die AS/400 dann laut Callstack?
Ist sie im Indexaufbau oder wo sonst?

Was die beiden PF's angeht:
Wird REUSEDLT(*YES) verwendet und sind viele gelöschte Sätze vorhanden?

[BenderD]

... eigentlich mag ich mich nicht in Kaffesatz Diskussionen einmischen, aber hier ist wieder mal viel Quatsch im Umlauf:
- Record level access ist ISAM (index sequential accdess method) oder sequentiell, das geht alles an Query Optrimizer, QAQQINI etc. vorbei
- bei sequentiellem Zugriff können gelöschte Sätze den Zugriff belasten (wenn am Anfang der Daten ein paarhundert Millionen gelöschte kommen => DSPFD *MBRLIST zeigt die gelöschten an). Cashing Phänomene gibt es da nicht, das ist immer gleich langsam/schnell.
- Zugriffspfad Aufbau kann durchaus Minuten dauern (wenn die Datenmengen groß sind, der Zugriffspfad teuer ist (viele Felder, berechnete Werte etc.), hier gibt es auch bei RLA caching Phänomene, insbesondere weil Access pathes geshared werden. Hier ist ja schon DYNSLT und maint <> *immed genannt und m.E: nicht eindeutig beantwortet worden.
- GigaByte und zig Millionen Sätze sind keine großen Datenmengen für aktuelle Hardware, da fängt groß bei einigen hundertmillionen Sätzen und einigen hundert GigyByte an
- mehrere Minuten zu Beginn eines Programmes sind kein Paging Phänomen, die AS/400 paged sich inkrementell in einen Kontext ein. bei Dateien und Zugriffspfaden sind das Millisekunden, bei Programmen (JVM, schlechtes ACTGRP Design) können das Sekunden sein, niemals Minuten

D*B

[CKA]

Hallo,
zuerst mal Danke für eure Antworten.

@pikachu . Warum der beiden ? Es ist eine LF die ganz normal als IF eingebunden wird.
@holgerscherer. Doch es laufen Sicherungen und es wird vor dem Start der Sicherung die Qinter heruntergefahren.
@furechau : er fängt an Sätze zu lesen aber EXTREM langsam . Wie gesagt erster Aufruf dauert mehrere Minuten und dann gehts schnell . Kann mir wirklich nur vorstellen so wie pikachu geschrieben hat das er beim ersten lesen alles in den Speicher überträgt und deshalb beim 2ten lesen schon alles im Speicher hat. Aber ja er hat 700000 gelöschte Sätze REUSEDLT = (*YES)
@Bender. alle LF Dateien stehen auf maint = *immed.

[CKA]

Wollte gestern auch einen kleinen Test fahren .
Die LF durchlesen von Anfang bis Ende .

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


ftestdds if e k disk
d time1 s z
d time2 s z
d time3 s 6 0
/free
time1 = %timestamp();
setll *start testdds ;
read testdds ;
dow not %eof(testdds );
read testdds ;
enddo;
time2 = %timestamp();
time3= %diff(time2:time1:*seconds);
dsply time3;
*inlr = *on;

/end-free

bin echt verwirrt.

[Fuerchau]

Dies sieht auf jeden Fall nicht nach einem statischen Index sondern einem dynamischen Index aus.
D.h., dass auf jeden Fall DYNSLT verwendet wird, auch wenn es nirgends steht.

Ich kenne aus anderen Anwendungen auch Multiformat-LF's, allerdings gibt es da nicht das Problem.

Poste doch mal die originale DDS der LF, schließlich sind wir ja hier unter uns.