View Full Version : Performance, Zugriffspfade
andreaspr@aon.at
14-10-14, 14:24
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
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 ?
Nicht alle lesen Deine Nachrichten ganz genau, so wie Du die Antworten nicht ganz genau liest.
Das ist das Lästige an Menschen. :-)
andreaspr@aon.at
14-10-14, 14:59
ps: Wir greifen über ein RPGLE-Programm auf die Datei zu .
keyed setll
keyed READE
DOW NOT EOF(DATEI)
OK, dann fallen die SQE "Optimierungen" weg wenn ihr mit Native I/O arbeitet.
Aber auch ohne IPL und SQL kann es eben daran liegen, dass die Tabelle/LF erst in den Speicher geladen werden muss.
Wie groß sind denn die entsprechenden LF (in byte ... bzw. GB)?
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 ?
Die Idee mit dem Speicher und der Größe lass mal weg, solche Probleme gibt's bei der AS/400 nicht.
Eine LF mit mehreren Satzformaten wird von SQL überhaupt nicht unterstützt.
Wenn du einen "Select * from MyLf" machst, nimmt SQL die dahinterliegende PF (in diesem Fall nur die 1. PF) und ergänzt diesen dann in der Whereklausel mit den Select/Omit-Definitionen.
Es kann also eigentlich nur an der Definition der LF liegen, dass hier DYNSLT evtl. automatisch angewendet wird. Erklärbar ist das aber so nicht.
Manchmal hilft ja auch ein Neuerstellen weil intern irgendwas kaputt/verbogen ist (RCLSTG).
Benenne die Datei mal um und lege die LF neu an.
Es müsste ein Hinweis kommen "Zugriffspfad wird aufgebaut".
Fehlt dieser, wird eben DYNSLT verwendet, aber ich weiß dann nicht warum.
Wie sehen die Dateidefinitionen der beiden logischen Dateien im RPG-Programm aus?
holgerscherer
15-10-14, 01:55
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
andreaspr@aon.at
15-10-14, 08:43
Die Idee mit dem Speicher und der Größe lass mal weg, solche Probleme gibt's bei der AS/400 nicht.
Wieso soll es so etwas bei der AS/400 nicht geben??
Wird eine Anwendung gestartet, werden auch bei der AS/400 die benötigten Objekte in den Speicher geladen.
Wenn die Daten Nachts nicht benötigt werden und eventuell ein paar Nacht-Batch Jobs laufen werden diese automatisch vom System aus dem Speicher entfernt.
Dieses Phänomen ist nicht selten.
Lese Optimierungen gibt es da evtl. wenn man SSDs verwendet und mit CHGPF die entsprechenden Tabellen beforzugt dieser Speichereinheit zuweist.
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?