View Full Version : Performance, Zugriffspfade
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
... 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
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.
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.
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
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.
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 .
@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..
Lange Rede kurzer Sinn:
Welches Release hast du?
Sind die PTF's ggf. nicht aktuell?
Prüf doch mal ob es zu aktualisierende PTF's gibt.
Wann ist der letzte RCLSTG mal gelaufen?
Wenn ich auf der mir zur Verfügung stehenden Maschine einen SQL auf eine Tabelle mit 41 Mio Sätzen loslasse der einen Tablescan erfordert, läuft dieser ca. 20 Sekunden.
Wie lange läuft bei dir dann also ein
Select * from TableA where FeldA <> 'XXXX'
und
Select * from TableB where FeldA <> 'XXXX'
v6r1.
ptfs sind laut systemer alle installiert ,
rclstg vor ewigkeiten gemacht worden . ist auch schwierig weil die maschine 24 Stunden durchlaufen muss. per sql etwa 10 Sek .
hab jetzt einen test nach dem anderen gefahren . immer wieder mit parameter gespielt.
ergebniss ist das gleiche . 1 lauf dauert lange. 2 lauf millisekunden . .
naja ich hoff jetzt mal das die umstellung auf V7r1 was bringt . mal schauen ...