Statisches SQL bei ersten Aufruf langsam

[rauschi1405]

Hallo Zusammen,

habe ein Problem mit statischen SQL. Wir haben uns in der Firma einen Maskengenerator geschrieben. Nun haben wird das Problem das beim ersten Aufruf sämtliche SQL sehr langsam sind. Beim zweiten sind diese um den Faktor 10 schneller. Hierbei handelt es sich um Prozeduren eines Serviceprogrammes die einzeln augerufen werden und externe Werte aus den verschiedensten Dateien ermitteln.

mfg
Heinz

[BenderD]

Hallo Zusammen,

habe ein Problem mit statischen SQL. Wir haben uns in der Firma einen Maskengenerator geschrieben. Nun haben wird das Problem das beim ersten Aufruf sämtliche SQL sehr langsam sind. Beim zweiten sind diese um den Faktor 10 schneller. Hierbei handelt es sich um Prozeduren eines Serviceprogrammes die einzeln augerufen werden und externe Werte aus den verschiedensten Dateien ermitteln.

mfg
Heinz

... tja, da macht ihr was falsch!

[bofrost]

Hallo rauschi1405,

Im iSeries Navigator gibt es einige möglichkeiten SQL zu analysieren und optimieren vlt. hilft dir der Link ja weiter: http://publib.boulder.ibm.com/infoce...2Fqueryopt.htm

[B.Hauser]

Die ersten Aufrufe sind immer langsamer als die Folge-Aufrufe!
Das liegt daran, dass beim ersten Aufruf immer ein Full Open erfolgt, d.h. ein Access Plan wird basierend auf den vorhandenen Zugriffswegen und Datenkostellationen erstellt oder valiediert. Die im Access Plan beschriebenen temporären Objekte werden erstellt und mit Daten gefüllt, der ODP wird geöffnet. Der zweite Aufruf ist i.d.R. um einiges schneller, da der ODP nach dem ersten Aufruf zwar gelöscht wird, aber z.B. temporäre Indices erhalten bleiben und der Access Plan lediglich validiert wird. Ab dem 3. Aufruf sollte es auf alle Fälle flutschen!

Allerdings ein Faktor 1:10 zwischen erstem und zweiten Aufruf deutet meist darauf hin, dass die Abfragen mit der alten CQE ausgeführt werden, und dass in diesem Zusammenhang temporäre Indices erstellt werden. Das Erstellen von temporären Indices ist der zeitaufwändigste Prozess überhaupt und dauert genauso lange wie das erstellen eines permanenten Zugriffswegs.

Ohne genauere Analyse über Database Monitor kann allerdings an dieser Stelle nicht viel mehr gesagt werden.

Birgitta

[Fuerchau]

Hallo Zusammen,

habe ein Problem mit statischen SQL. Wir haben uns in der Firma einen Maskengenerator geschrieben. Nun haben wird das Problem das beim ersten Aufruf sämtliche SQL sehr langsam sind. Beim zweiten sind diese um den Faktor 10 schneller. Hierbei handelt es sich um Prozeduren eines Serviceprogrammes die einzeln augerufen werden und externe Werte aus den verschiedensten Dateien ermitteln.

mfg
Heinz

Serviceprpgramme sind im ersten Aufruf langsamer, da diese ja ggf. erst Initialisierungsarbeiten durchführen.
Vielleicht greifen diese ja wieder mit RLA statt SQL zu, machen viele Dateien auf usw. usf.
Beim nächsten Aufruf geht das dann halt schneller.

[BenderD]

... initialisieren von Servieprogrammen, Dateien öffnen, etc. das liegt bei korrekter Vorgehensweise alles unter der Messbarkeitsschwelle. Da ist handwerklicher Murks im Spiel!!! Aber ohne solide Informationen ist das ein nutzloses Ratespiel und blanke Zeitverschwendung...

[rauschi1405]

Hallo,
habe jetzt mal mit dem Index-Adviser geprüft ob temporäre Indexe erstellt werden. Dies ist nicht def Fall.
Fr. Hauser wie funktioniert das mit dem Database-Monitor.
Könnte es daran liegen das bei uns in der QAQQINI der Wert IGNORE_DERIVED_INDEX auf *DEFAULT steht. Welche Analysen könnte ich noch durchführen.

mfg

[BenderD]

... falls es sich wirklich um static SQL handelt, dann genügt bereits ein Blick in die Packages (PRTSQLINF). Mit dem schrauben an defaults ohne vorhergehende Analyse, wäre ich aüßerst vorsichtig, da das an anderer Stelle unerwünschte Auswirkungen haben kann. Im übrigen sind die Angaben zu dem, was ihr da treibt bei weitem zu dürftig, um da solide Ratschläge geben zu können.

D*B

[Fuerchau]

Da du was von "Maskengenerator" erwähnst, frage ich mich was denn die Serviceprogramme so beim 1. Aufruf eben alles treiben müssen:
- laden von Ressourcen
- Analysieren von DDS-Masken
- API-Aufrufe
- u.v.m
Beim nächsten Aufruf liegen diese Daten bereits im Speicher so dass eben alles schneller geht.

[B.Hauser]

Fr. Hauser wie funktioniert das mit dem Database-Monitor.
Könnte es daran liegen das bei uns in der QAQQINI der Wert IGNORE_DERIVED_INDEX auf *DEFAULT steht. Welche Analysen könnte ich noch durchführen.

mfg

Die einfachste Möglichkeit mit Datenbanken Monitoren zu arbeiten, ist den System i Navigator zu verwenden.
Die Aufzeichnung kann unter Datenbank - SQL Performance Montiors --> Rechtsclick --> Neu --> Performance Monitors gestartet werden.
Die zu sammelnden Daten können (und sollten) eingschränkt werden. Ebenso sollte die Aufzeichnung nicht allzu lange dauern, da riesige Mengen an Daten gesammelt werden.

Zur Analyse stellt der System i Navigator ebenfalls einige Tools zur Verfügung.
... aufgrund der Vielzahl an gesammelten Daten, kann die Analyse bzw. die Zusammenfassung der Daten einen "Hauch" dauern.

Birgitta