Performance, Zugriffspfade

[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 ?

[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

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

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

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