SQL-Optimizer

[Fuerchau]

Nun ja, einer meiner Kunden hat nun auf V7R1 gewechselt.
Leider hat nun wieder mal der SQL-Optimizer pessimistisch zugeschlagen.
SQL's die mit V6R1 schnell liefen laufen nun mit V7R1 wieder zäh.
Die Analyse wird mal wieder was dauern.

Außerdem hat sich das Verhalten bzgl. "Auto-Casts" grundsätzlich geändert!
Früher wurden Konstanten eher dem Feldtyp angeglichen, nun macht SQL dies umgekehrt.

Beispiel 1:
Durch einen Fehler wurde im SQL
"where ... WERK = 001 ..."
kodiert.
Da WERK nun mal CHAR(3) ist, wurde die 001 automatisch in CHAR gecastet und es konnte ein Index verwendet werden.
Nun wird aber das Feld WERK in DECIMAL gecasted und es wird kein Index sondern ein Tablescan durchgeführt!
Zusätzlich kommt es vor, dass das Feld WERK Zeichen enthält die beim Cast in Decimal zu Fehler führen und den SQL somit abwürgen.
Diese Änderung wurde zum Glück relativ früh festgestellt und behoben.

Beispiel 2:
select ...
case Preisdimension
when 2 then 10
when 3 then 100
else 1 end
...

Auch hier wurde leider der Fehler gemacht, die 2 und 3 nicht als Zeichenkonstante zu definieren, das das Feld Preisdimension vom Typ CHAR(1) ist.
Bis V6R1 lief dieser SQL aber problemlos, da die Konstante in CHAR(1) konvertiert wurde. Nun wird das Feld Preisdimension aber in Decimal gecastet, was bei nicht numerischem Inhalt wieder mal zum Absturz führte.
In diesem Fall wurde hier ein SQLCOD im embedded SQL gesetzt. So konnte dann nach ein paar Tagen festgestellt werden, dass ein Batchprogramm bei einem bestimmten Satz nicht mehr weiter gearbeitet hat sondern sich ganz normal fertig meldete.

Das Gemeine an solchen Änderungen ist, dass sich diese erst so nach und nach überhaupt feststellen lassen und nicht dokumentiert sind.

Was sich die IBM dabei nun überlegt hat kann ich nicht mehr nachvollziehen.
Auf jeden Fall müssen nun wieder viele SQL's, die schon von V5R4 nach V6R1 neu optimiert wurden nach und nach wieder neu für V7R1 optimiert werden.

Zumindest wird man dabei nicht arbeitslos.
Mal sehen, was dann V7R2 diesbezüglich bringen wird.

[holgerscherer]

Was sich die IBM dabei nun überlegt hat kann ich nicht mehr nachvollziehen.

Ich würde sagen, die dachten sich "wir machen es sauber nach Standard", denn die können ja nicht in Microsoft-Manier immer ihre Software so optimieren, dass die Fehler des Programmierers weggebügelt werden ;-)

-h

[Fuerchau]

Nun, was die Autocast's angeht, so habe ich diesbezüglich bei MS-SQL-Server, Oracle und Firebird immer eins auf die Finger bekommen, wenn die Konstante nicht dem Feldtyp entspricht.
Ausnahme ist allerdings immer der Date-Typ, der im SQL-Standard in Hochkomma angegeben werden muss.
Bei MS (SQLServer und Access) kennt der noch das amerikanische Datumformat #mm/dd/yy#.

Wie gesagt, das gemeine ist, dass die Änderungen nicht dokumentiert sind und man erstmal auf die Schnauze fällt.

[BenderD]

... was SQL Standard angeht empfehle ich PostgreSQL, die sind eng am ANSI SQL und weisen in der Doku überall daraufhin, wo sie vom Standard abweichen.

D*B