extrem langsame Datenübertragung von IBM i

[TheDevil]

Hallo.
Neue Virenschutzsoftware auf dem Rechner des Kollegen ?
Releasewechsel auf 7.2 ?
Wir haben hier auch derzeit das Phänomen das z. B. SQL Abfragen über die ODBC Schnittstelle mal schnell und dann wieder verdammt langsam laufen. Dies aber erst nach einen Wechsel von 7.1. auf 7.2.
Wir und IBM sind am suchen wie die Karnickel aber haben dazu z. B. auch noch nichts gefunden.
Gruß,
Ralf

[Fuerchau]

Das liegt zum großen Teil an dem neuen Optimizer.
Ich habe auch schon festgestellt, dass das zwangscasten in einen passenden Typ beim
join xxx on ...
where yyy ...
zu besseren Ergebnissen führt.
Aus historischen Gründen ist ein Feld mal Decimal (gepackt), mal Numeric (gezont). Dies führt ggf. zur Nichtverwendung von Indizes.
Ein anderer z.T. fataler Fehler ist der Vergleich eines Zeichenfeldes mit einem numerischen Wert.

Beispiel (aus der XPPS-Welt):

where WKNR = 001 ...

Hier hat der Programmierer schlicht die Hochkomma vergessen.
"Früher" hat der Optimiizer automatisch "where WKNR = cast(001 as char(3))" gemacht und konnte somit einen Index über WKNR machen.
Der heutige Optimizer macht daraus "where cast(WKNR as decimal(3, 0)) = 001".
Wie man sieht, der Unterschied führt dazu, dass eine Indexverwendung nicht mehr möglich ist.
Woher ich das weiß?
Ganz einfach: in den Daten gab es leider ein WKNR mit Blank, was zu einem Dezimalfehler führte.
Mit Debugger stand dann im Fehlertext "Fehler bei Datenumsetzung cast(WKNR...".
Mit Indexverwendung wäre die DB an dem Satz gar nicht vorbeigekommen.
Somit konnte ich den SQL korrigieren und es ging wieder gewohnt fix.

Ich kann hier nur ähnliches vermuten, dass Typanpassungen vorgenommen werden, die eine Indexverwendung verhindern. Warum der Optimizer nun die Felder an Stelle der Konstanten castet entzieht sich mir völlig.
Das ist schon fast wieder wie bei einem V5R2!-Kunden bei dem ich grundsätzlich bei Beziehungen passend zum Schlüssel casten muss um performant zu sein.