Performance, Zugriffspfade

[Fuerchau]

Der Index scheint ja angelegt zu sein. Aber irgendwas stimmt damit tatsächlich nicht wenn du solche Antwortzeiten hast.
Werden denn viele Änderungen an den PF's durchgeführt?
Bevor das Programm die LF öffnet, steht beim DSPFD dann "Zugriffspfad gültig . . . . . . . . . . : Ja"?
Wenn nicht liegt genau da dann das Problem.

Vielleicht kommst du um die Meldung an IBM nicht herum.

[CKA]

ich kann mir das jetzt wirklich nur so erklären .
Er muss die Daten beim ersten Aufruf des Tages in den Speicher laden und das dauert ewig lange . Sind sie mal drinnen Dasnn gehts "ratz fatz" . Ist ja bei einer View die über X Dateien geht und Millonen Datensätze durchratern muss das gleiche , Erster Aufruf Dauert immer extrem länger als der Zweite ..

[Pikachu]

Geht das beim ersten Aufruf Satz für Satz sehr langsam oder dauert das erst sehr lang und geht dann ratz-fatz?

[Fuerchau]

Gegen "ratz fatz" spricht die extrem lange Laufzeit des obigen Mini-RPG's.
Bei einer View kann ich das tatsächlich mit Indizes extrem beschleunigen.
Ich hatte gerade einen akuten Fall in dem ein komplexer SQL (incl. derived Table mit Group by) ca. 10 Sätze je Sekunde lieferte.
Nach Berücksichtigung der vorhandenen Keystrukturen und Ergänzung um vorgeschlagene Schlüssel werden nun ca. 1500 Sätze je Sekunde geliefert.
Also obige LF kann als View mit Indizes und per SQL die gewünschten Ergebnisse sehr schnell liefern.
Eine View kann zwar per Native-IO bearbeitet werden aber auf Grund des fehlenden "order by" eben nur Sequentiell und ohne SETLL.

[B.Hauser]

Wie bereits mehrfach festgestellt muss der Zugriffsweg warum auch immer zunächst aufgebaut werden (DYNSLT).

Bei einer View bzw. mit SQL funktioniert das Ganze aber anders. Der Optimizer verwendet immer beides, d.h. View und sucht sich die optimalen Zugriffswege aus. Wenn Du die richtigen Zugriffswege (SQL Indices oder logische Dateien) bereitstellst ist auch der erste Aufruf schnell (zwar etwas langsamer als die folgenden, aber unwesentlich). Wenn die richtigen Zugriffswege nicht vorhanden sind und der Optimizer entweder alle Sätze verarbeiten oder zunächst temporäre Indices aufbauen muss, dann hast Du die in etwa doe gleiche Situation wie bei Verwendung einer logischen Datei mit dynamischem Select (DYNSLT) oder rebuild.

Hast Du eigentlich mal versucht die logische Datei neu zu erstellen?
Ich denke zwar nicht, dass folgendes einen großen Einfluss auf Deine logische Datei und die Performance unter native I/O hat, aber immerhin versuchen kann man es.

Wenn Du in Release 6.1 oder höher bist, erstelle zwei SQL Indices mit den Schlüssel-Werten aus Deiner logischen Datei und füge außerdem eine Where-Bedingung mit der entsprechenden SELECT-/OMIT Anweisgung hinzu. Nachdem Du diese Indices erstellt hast, lösche deine logische Datei und erstelle sie neu.

Sofern Du noch nicht unter 6.1 arbeitest erstellst Du die SQL Indices ohne die Where-Bedingung und erstellst die logische Datei im Anschluss neu.

Das Ziel dieser Aktion ist, dass die logische Datei den Zugriffsweg der Indices mitbenutzen und aufgrund der größern Pagesize von Indices, diese größere Pageszie vererbt bekommt und davon profitieren kann.

Birgitta

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

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.

FRCRATIO steuert wann Daten rausgeschrieben werden, FRCACCPATH die Aktualisierung der Zugriffspfade, jeweils im persistenten Speicher (= Platte). Dass da Beschädigungen bei abnormal Systemende auftreten können, hat die Ursache darin, dass Jobs abnormal beendet werden. Beim abnormalen Systemende ist steuerbar was alles wann im Laufe des IPLs aufgeräumt wird.
Erfolgt die Beschädigung beim abnormal End eines Jobs, was bei intaktem Betriebssystem selten sein sollte, wird der Rebuild des Access Pathes durchgeführt bei der ersten Benutzung duchgeführt.

Das mit der Laufzeit von 7 Stunden passt so oder so nicht zur restlichen Beschreibung des Problems, die mehr von vermuteten Ursachen, als von beobachtetem Verhalten ausgeht.

Was die Power der Maschine angeht: warum sollte die beim zweiten Aufruf zunehmen?

D*B

[AG1965_2]

Irgendwie werd' ich das Gefühl nicht los, dass die Maschine zum Onkel Doktor will. WRKPRB enthält nix?
Interessant wäre es, nun 2 neue Dateien mit obigen logischen zu erstellen. Kleines RPG-Programm zum Füllen mit einer signifikanten Anzahl Sätze schreiben, Testprogramm zum Lesen. Wenn das dann schnell ist, ist es definitiv was Anderes oder die files sind kaputt.
Wenn sich das dann genau so benimmt wie die vorhandenen Dateien, könnten es dann noch Interessierte ausprobieren, wie schnell/langsam das bei ihnen ist, bevor man den Arzt ruft.
Und ich sehe auch nicht ein, warum da ein DYNSLT passieren sollte, wenn die logischen Dateien wirklich so aussehen.

[CKA]

also nochmal .
DIE LF SIEHT 100% so aus !! und @Bender das sind keine vermutungen das sind Fakten . KAnn auch nichts dafür das dieses MINI PGM 7 STD über die Datei ratert . DAS IST AUCH FAKT. Kannst ja gerne zu uns in die Firma kommen und dich davon überzeugen das ich hier keinen Müll schreibe !!


Ich verstehe ja dieses Verhalten selber nicht. Habe die Files weg kopiert , neue logische erstellt,
mit SQL Inidizes getestst usw bringt nix . 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. Die anderen Parameter (Recovery, usw) bringen mir doch nur bei einem IPL was und das wird nicht gefahren .

[CKA]

@pikachu: Geht beim ersten Aufruf Satz für Satz sehr langsam .
@fuerchau Zugriffspfad gültig . . . . . . . . . . : da steht ein ja ..

wie gesagt ich kann mir echt nur vorstellen das es beim ersten aufruf zuviele Sätze sind ..
Aber wir stellen eh bald auf V7r1 um . Mal schauen ob das was bewirkt . Warum auch immer..