View Full Version : Performance-Problem Datenbank
Hallo,
ich habe ein großes Performance-Problem.
Situation :
-Physische Datei mit ca. 140 Mio. Datensätzen soll reorganisiert werden.
-18 logische Files hängen an der Datei
-der Reorg-Lauf mit RPG-Programm, das eine der 18 LF liesst und dann mit delete
löscht hat in 41 Stunden ganze 5 Mio Sätze geschafft !!??
Wer hat Erfahrungen mit solchen Datenmengen ?
Die Dateien haben (bewusst vom Entwickler so implementiert) den Parameter FRCRATIO=1 - kann dieser Parameter solche Auswirkungen haben ?
Ich bin für jeden Hinweis dankbar !
FRCRATIO=1 erzwingt für jeden Write/Update/delete ein sofortiges physisches Schreiben.
Da es sich hier um einen Delete-Lauf handelt, könnte ggf. vor Aufruf des Programmes ein OVRDBF für die LF gemacht werden.
Ich habe dies bei einer anderen Anwendung genauso gemacht und konnte damit die Laufzeit des Programmes von 18 Stunden auf 50 Minuten reduzieren (es waren allerdings mehrere Datei betroffen).
Ein CPYF wurde von 5 Minuten auf 5 Sekunden beschleunigt.
Danke für die schnelle Antwort !
Der FRCRATIO-Parameter hängt sowohl an der PF als nach an den LF.
Indem ich ein "delete" auf eine der 18 LF mache, muss doch auch in der PF und den anderen 17 LF gelöscht werden !?
Muss demzufolge auch ein OVRDBF auf alle LF und die PF gemacht werden ?
Mit freundlichen Grüßen
G. Gottlöber
Nein, da ein OVRDBF nur auf tatsächlich vom Programm geöffnete Dateien wirkt.
Da es den FRCRATIO sowohl bei LF als auch bei PF gibt, kann eben von Fall zu Fall bzw. Open zu Open entschieden werden.
Eine Möglichkeit wäre alle für das REORG nicht benötigten LF mit RMVM zu deaktivieren und nachhher mit ADDLFM zu aktivieren.
Bei der automatischen EURO-Umstellung habe ich mit folgendem OVR gute Erfahrung gemacht:
OVRDBF FILE(&FILET) TOFILE(&LIB/&FILE) MBR(*ALL) +
NBRRCDS(1000) SEQONLY(*YES 1000)
Dafür eignet sich ein "CHGLF xxx MAINT(*IMMED/*DLY) " besser.
Durch FRCRATION(*NONE) steigt aber auch die Performance bezüglich der Zugriffspfade.
Dafür eignet sich ein "CHGLF xxx MAINT(*IMMED/*DLY) " besser.
Durch FRCRATION(*NONE) steigt aber auch die Performance bezüglich der Zugriffspfade.
Eindeutig die bessere Lösung. Mit MAINT(*DLY) die Zugriffspfade quasi "abhängen" und nach dem Reorg wieder anhängen. Es sei denn, die Zugriffspfade werden für den Reorg benötigt. Ansonsten empfiehls sich ggf. der andere Weg. Nämlich kopieren der "alten" Datei, löschen der neuen und nur ein hineinkopieren der eigentlich benötigten Datensätze. Dabei mit den logischen genauso verfahren, da nicht für jeden Write eine Aktualisierung der Zugriffspfade erfolgt.
Ein OVRDBF ... SEQONLY überschreibt NICHT einen FRCRATION(1) !
Man beachte dann mal die Hinweise im Joblog.
Es gibt da nämlich die Hinweise "SEQONLY von X in 1 geändert".
Wenn in RPG/LE z.B. eine reine O-Datei geöffnet wird, versucht der Compiler die Datei geblockt zu verarbeiten.
Hat die Ausgabedatei aber einen FRCRATION(1) taucht automatisch obige Meldung auf und SEQONLY wird ignoriert.
NBRRCDS funktioniert auch nur, wenn die Datei in Eingangsfolge verarbeitet wird, also bei Schlüsselverarbeitung die Satzreihenfolge mit der Schlüsselfolge übereinstimmt (gilt heute eigentlich auch eher selten).
Ansonsten wird dieser Parameter nämlich auch ignoriert.
NBRRCDS(1000) kann hier ggf. zu Verlangsamung führen wenn das System durchaus größere Blocklängen erlauben würde.
Du hast recht. Bei der EURO-Umstellung sind die Dateien auch aus dem zweiten Grund in Eingangsfolge verarbeitet worden, weil es Ausnahmefälle gab, wo im Primärschlüssel der Betrag war und sonst ein Satz mehrmals drangekommen wäre.