Performance, Zugriffspfade

[CKA]

Hallo,

ich hätte mal eine Frage rund ums Thema Performance und Zugriffspfade etc.

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.

So wie ich es verstehe speichert oder anders gesagt cached doch die I-Series den Zugriffspfad damit der zweite Aufruf viel schneller geht . Ist ja wie bei einer View.
Oder ist das falsch ?

Wo speichert die Iseries die Zugriffspfade und wie lange werden diese gehalten ?
Wann werden diese gelöscht und durch welche Aktionen werden diese dann wieder gelöscht.

Wie würdet ihr das Problem mit dem ersten Aufruf lösen .

Vielen Dank für eure Antworten .

[AG1965_2]

Wenn Du ein DSPFD dieser Dateien machst, was steht dann bei "MAINT" (Zugriffspfadwartung)?
Wenn hier etwas Anderes als *IMMED steht, sollten sich solche Effekte beobachten lassen.
In diesen Minuten noch nie auf einer zweiten Session mit WRKACTJOB nachgesehen, was der Job in der Zeit denn tut? Steht dann da "IDX-FILEx"?
Ist die Wartezeit nach einem SIGNOFF wieder da? Oder profitieren andere Jobs, die dasselbe Programm aufrufen, davon, dass schon ein anderer Job das Programm aufgerufen hat oder warten die beim ersten Mal genau so lange?
Wenn beide Dateien MAINT(*IMMED) haben, tippe ich auf eine ganz andere Ursache, z.B. irgendein Init für einen neuen Arbeitstag oder dergleichen.

[Fuerchau]

Ggf. ist das nicht die ganze Wahrheit, die obige DDS sieht etwas rudimentär aus.
Ein statischer Zugriffspfad wird bei Join's ggf. abgelehnt wenn der Select/Omit aus mehreren Dateien kommt. In diesem Fall fordert der CRTLF aber auch einen DYNSLT in der LF.
Bei DYNSLT (Dynamic Select) wirkt das Ganze halt wie eine View!
Dabei wird beim SETLL/CHAIN der Zugriffspfad aufgebaut, beim READ/READE wird mit den "statischen" Informationen weiter gearbeitet. Der nächste SETTL/CHAIN macht dann wieder einen neuen Select, wobei dieser dann ggf. schneller ist.

[KingofKning]

Welches OS hast Du denn?GG

[CKA]

beide haben MAINT(*IMMED),
Nur der erste Aufruf dauert sehr lange. Die anderen von anderen Usern etc geht dann "sehr schnell".
Ich vermute auch das da irgendwas initalisiert wird , deshlab auch meine Frage wann werden die Pfade gelöscht usw , und wie würdet ihr das lösen ?


OS = V6R1m0,

@Fuerchau: Nein das ist die ganze Beschreibung der Datei und die kann man auch so umwandeln

[KingofKning]

Die ganzen Optimierungsvarianten wurden hier alle schon mal vorgestellt. Ziehen aber in der Regeln erst ab V6R1 deswegen sind sie nichts für mich.Die Frage wäre ob die Tabellen mit SQL erzeugt mehr Möglichkeiten bieten.Ansonsten hier mal im Forum mit Stichworten wie Zugriffspfad , Optimierung , Cache suchen.GG

[Fuerchau]

Was heißt "beide haben MAINT(*IMMED)"?
Es geht nicht um die beiden PF's sondern um die LF!
So wie die Beschreibung aussieht handelt es sich doch um eine LF die 2 PF's als MultiFormat-LF definiert.
Wie ist hier die MAINT definiert?

Durch MAINT(*IMMED) wird bei jeder Veränderung einer PF auch der Index sofort gepflegt.
Bei *REBLD wird der Index beim Open neu erstellt, bei Änderungen aktualisiert und nach dem Close wird nichts mehr gemacht.
*DLY funktioniert ähnlich, wobei hier nur Änderungen aktualisiert werden. Bei erreichen eines Schwellenwertes wird dann komplett neu aufgebaut.

*DLY wird eher dann benötigt, wenn eine LF nicht so häufig verwendet wird.
Die Insert/Update-Rate sinkt, je mehr LF's eben definiert sind, wobei ich auf der AS/400 da weniger Probleme festgestellt habe als bei anderen Datenbanken, 100 LF's sind da noch nicht so zeitkritisch.

Gelöscht werden die Pfade nur beim DLTF.

[CKA]

Die LF ist auch mit Maint(*immed).

"Gelöscht werden die Pfade nur beim DLTF."
Ja klar, werden diese nicht wirklich gelöscht aber
Hmmm was cached er dann beim ersten Aufruf, oder warum dauert dann der erste Aufruf am nächsten Tag so lange ??? Es wird kein IPL gefahren.

[B.Hauser]

Zufällig in der DDS-Beschreibung irgendwo DYNSLT (Dynamic Select) hinterlegt?

Birgitta

[CKA]

nein , die LF sieht genauso aus . Habe nur die Namen usw ausgetauscht . Ansonsten 1:1 identisch.

[andreaspr@aon.at]

Hallo,

Es gibt verschiedene Gründe warum es beim 1. Mal länger dauern kann:

Es gibt den QAQQINI Eintrag IGNORE_DERIVED_INDEX.
*YES: LFs mit Select/Omit werden von der SQE verwendet
*NO: LFs mit Select/Omit werden von der SQE NICHT verwendet

Es kann also sein, dass deine LF gar nicht verwendet wird und das System sich einen eigenen temporären Index aufbaut.
Dieser ist normaler weise bis zum nächsten neustart verfügbar. Nach einem Neustart ist dieser gelöscht.

Wenn du mit dem DB-Monitor drüber schaust, kannst du erkennen ob z.B. ein temporärer Index verwendet wird.

Oder Tabelle/Index muss erst mal in den Speicher geladen werden.

lg Andreas

[CKA]

Was verstehst du unter Neustart ?? Wie gesagt wir fahren hier kein IPL.

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

RPG-Programme verwenden doch die Datei die angegeben ist oder ? Oder verwendet RPG im hintergrund noch zusätzliche LF's die beim ersten Aufruf den select auswerten ?
S FeldC CMP(Lt 60)
FeldD CMP(NE 'D')


Ist doch ein unterschied ob ich mit SQL oder mit RPG auf eine Datei zugreife oder ? RPG kennt doch den Optimizer gar nicht oder liege ich da falsch ?