SQL-Fehler CPF427F nach Systemwechsel

[BenderD]

Hallo,

hört sich nach neuer Query Engine, auch als "die phantastische SQE" bekannt, die zuweilen einen Hang zum full table scan hat, an. Neueste group PTFs für die Database einspielen, wenn die schon drin sind, auf die nächsten hoffen...
Ich vermute mal, dass es auch keine vagabundierende QAQQINI ist, als Workaround geht höchstens noch reichlich order by auf vorhandene Zugriffspfade, wenn man diese Freiheit denn hat.

mfg

Dieter Bender

Hallo,

"leider" auf *nomax, darin liegt es also nicht.
Uns ist jetzt aufgefallen, daß auch die noch funktionierenden SQL-Abfragejobs über ODBC jetzt viel länger laufen als vorher und gehörig CPU ziehen.
Ansonsten ist das neue System aber viel schneller als das Alte.
Irgendwas beim Systemwechsel muß da nicht sauber funktioniert haben, obwohl ich keinerlei Meldungen diesbezüglich hatte.

mfg
H. Lossin

[Fuerchau]

Das Problem hatten wir auch.
Lösungsvorschlag der IBM:
Anlegen einer LF mit Select-Bedingung. Dies führt dazu, dass der alte Optimizer verwendet wird (warum auch immer).
Es hat zumindest funktioniert.

Eine QAQQINI wird von ODBC nur bedingt verwendet, das QRYTIMLMT jedenfalls nicht. Die QueryTimout des ODBC-Aufrufes (ADO-Commandobjekt) wird verwendet.

[BenderD]

Vorsicht: beide Fehler in der Datenbank existieren weiterhin:
- SQE macht full table scan trotz index (BTW, das versucht sie schin unter V5R3 nach jedem Group PTF)
- irgendwoher zieht er sich die QRYTIMLMT(600)

Im übrigen wirkt eine globale QAQQINI auch auf ODBC, oder man kann sie setzen, je nach Treiber, in jedem Fall per stored Procedure.
letzteres wäre auch noch ein Versuch für einen Workaround, vermutlich allerdings mit katastrophalen Folgen für die Systemlast.

Das sieht mir alles nach einem KO Kriterium für die Installation von V5R4 aus, wenn man massiv SQL verwendet, zumindest im Database Server Umfeld.

mfg

Dieter Bender

Das Problem hatten wir auch.
Lösungsvorschlag der IBM:
Anlegen einer LF mit Select-Bedingung. Dies führt dazu, dass der alte Optimizer verwendet wird (warum auch immer).
Es hat zumindest funktioniert.

Eine QAQQINI wird von ODBC nur bedingt verwendet, das QRYTIMLMT jedenfalls nicht. Die QueryTimout des ODBC-Aufrufes (ADO-Commandobjekt) wird verwendet.

[Fuerchau]

Bei ODBC-Zugriffen (zumindest aus Windows mit OLEDB/ODBC-Treibern) wird das Default-QueryTimeout im Connection-Objekt festgelegt.
Dieses überschreibt einen Eintrag in der QAQQINI bzw. den Systemwert.
Pro Command-Objekt (Query-Objekt) kann das Timeout wieder geändert werden.