V6R1 SQL Prozeduren teilweise langsamer

[Dschainers]

Hallo,

nach der Umstellung von V5R4 auf V6R1 laufen unsere SQL Prozeduren teilweise viel langsamer.

Die Prozedur macht nichts anderes als Daten von einer Datei in eine andere zu schreiben. Wenn der Satz schon vorhanden ist wird ein UPDATE ausgeführt andernfalls ein INSERT.

Wir glauben, es liegt am UPDATE, dass alles langsamer ist.

Gibt es da Erfahrungswerte oder schon Lösungen??

Vielen Dank

[TARASIK]

Hallo,
das neueste Cumtape und das neueste Datenbank Gruppenptf bereits installiert ?
rclstg *dbxref schon gelaufen ?

[andreaspr@aon.at]

sind das sql-tabellen oder dds?
bei 6.1 gibt es in der qaqqini ein paar einträge die sich mit 5.4 unterscheiden (zb ignore_derivide_index), wenn ihr mit sql-tabellen fährt, ist das egal, bei dds gibt es einen geringen prozentsatz wo es sehrwohl performance probleme haben kann.

ansonsten würd ich mal ein monitoring aufsetzen und dieses analysieren wo die langen wartezeiten sind. bzw. auch den zugriffspfad ansehen.

lg andreas

[Dschainers]

Aktuelle CumPTF und Grp PTF sind installiert.

RCLSTG wurde nicht ausgeführt

Indexe sind angelegt.

Manchmal funktionierts auch sehr gut, und manchmal dauerts und dauerts....

Evtl. werde ich mal einen CALL bei der IBM aufmachen.

[B.Hauser]

Ich würde zunächst die Prozeduren nochmals erstellen.
1. Mit Release V5R4 wurde ein sogenannter Expression Evaluator eingeführt, durch den SET-Anweisungen, die zuvor in ein Dummy-Select-Statement konvertiert wurden (und damit optimiert werden mussten) direkt ausgeführt werden können. Dazu muss allerdings das Objekt neu erstellt werden.

2. ggf. lief/läuft bei der internen Konvertierung auf 6.1 irgendwas schief.

3. Wie Andreas schon sagt, wurde die SQE auch mit Release 6.1 erweitert, d.h. Statements, die zuvor mit der CQE ausgeführt wurden werden jetzt u.U. mit der SQE ausgeführt. Die SQE kann jedoch keine Zugriffswege verwenden, die in DDS beschriebenen logischen Dateien mit SELECT/OMIT-Anweisungen liegen. Die SQE erachtet u.U. Zugriffswege, die von der CQE verwendet wurden als nicht optimal und liest die Tabelle komplett durch (Table Scan). Prüfe also, ob alle benötigten Zugriffswege vorhanden sind. ggf. werden temporäre Indices (sogenannte MTIs = Maintained Temporary Indexes) gebildet. Beides Table Scan und MTI kostet Performance.

Wenn alles nicht hilft, mach einen CALL bei IBM auf.

Birgitta

[Dschainers]

Vielen Dank für die Antworten.
Das Problem war, dass unsere Sortierfolge *LANGIDSHR ist.
Die von unserem Programm erzeugten SQL Prozeduren ab V6R1 aber *HEX drin hatten, dies haben wir geändert und jetzt läufts wieder besser.

Dschainers