SQL-Optimizer V7R1 und kein Ende

[Fuerchau]

Die Performanceunterschiede diesbezüglich betreffen nicht den SQL selber, sondern meist das Abrufen von Metadaten über das Record/Resultset.
Hier gibt's natürlich unterschiedliche Implementationen, die je nach Datenbank auch verschieden gelöst werden müssen.
Beim AS/400 CLI (die Basis für ODBC) reicht meist ein Describe-Befehl um alle Felder zu beschreiben.
Laut ODBC-Funktionen (CLI) kann ich allerdings auch jedes Feld einzeln abrufen, was halt jedes Mal einen zusätzlichen Netzcall zur AS/400 auslöst. Je mehr Felder ich habe, desto länger dauert das dann halt.
Mache ich z.B. einen "Select * from table where 1=0" von der AS/400 kommt der sehr schnell zurück und ich habe die Feldliste quasi sofort. Mache ich das selbe bei Oracle oder Firebird, führt das erst mal zum Tablescan. Anschließend wird für jedes Feld ein einzelner SQL abgesetzt, und das dauert dann schon mal.

[Fuerchau]

Nun hat der Kunde die o.g. PTF's eingespielt und der SQL läuft nun überhaupt nicht mehr.
Fehler:
SQL0802 - Data conversion or data mapping error.

Nun müssen wir das Ganze wieder von vorne analysieren und den SQL umarbeiten.

[TARASIK]

Für diesen Fehler gibt es diese Fixes:

MF58386,MF58012,MF58026,SI51315,SI52705,MF57453,
SI52257

[Fuerchau]

Da der Kunde V7R1 hat und PTF's nur am WE laden kann, dauert das alles zu lange.
Wir haben den SQL umgebaut und einen Index erstellt, nun fluppt es wieder.

Hintergrund:
with xTbl as (
select k1, k2, k3
,min(dec(substr(f1, 1, 7), 7, 0)) f1
,min(dec(substr(f1, 8, 4), 4, 0)) f2
from mytable
where ...
Group by k1, k2, k3
)
select * from tbl1
inner join xTbl on ...

In der Where-Klausel werden nur Daten gefiltert, bei denen in F1 auch nur numerische Werte vorhanden sind. Bei V6R1 hatte ich aber auch schon mal festgestellt, dass die DEC-Funktion ggf. VOR der Where-Klausel zuschlägt.
Dies liegt wohl am irgendwo Optimizer.

Nun habe ich den SQL mit V7R1-Methoden umgebaut, was zum selben Ergebnis führt:
select * from tbl1 a,
lateral (
select dec(substr(f1, 1, 7), 7, 0) f1, dec(substr(f1, 8, 4), 4, 0) f2
from mytable b
where a.k1 = b.k1 and ...
fetch first 1 rows only -- nur der 1. Satz interessiert
) xTbl

"Lateral" bietet einen scalaren subselect mit mehr als 1 Feld!

Zusätzlich muss noch gesagt werden, dass der ODBC-Treiber doch eine Rolle spielt.
Auf einem PC-Server ist CA-V6R1 installiert, da läuft ein SQL mit ca. 10 Sätzen/Sekunde.
Auf einem neueren PC-Server ist CA-V7R1 installiert, da läuft der selbe SQL mit ca. 350 Sätzen/Sekunde.

M.a.W: Im QZDASOINIT-Job optimiert SQL unterschiedlich, ob ich mit dem "alten" oder neuen Treiber ankomme.
Ich finde, das gehört sich einfach nicht. Die Treiberversion sollte da keine Rolle spielen.

[BenderD]

In der Where-Klausel werden nur Daten gefiltert, bei denen in F1 auch nur numerische Werte vorhanden sind. Bei V6R1 hatte ich aber auch schon mal festgestellt, dass die DEC-Funktion ggf. VOR der Where-Klausel zuschlägt.

Das kann man wohl meist mit einem Case Construct umgehen.

Zusätzlich muss noch gesagt werden, dass der ODBC-Treiber doch eine Rolle spielt.
Ich finde, das gehört sich einfach nicht. Die Treiberversion sollte da keine Rolle spielen.

Ich habe mich zwar nicht tiefergehend mit ODBC Treibern der AS/400 befasst, aber selbstredend hat der Treiber durchaus Einfluss, da sie auch unterschiedlich arbeiten und cachen. Ein paar Beispiele:
- manche Treiber cachen und sparen so prepares
- mancher Treiber zieht Sätze einzeln, andere können Blöcke (was auch Einfluss auf den Optimize hat)
- manche Treiber können Batch updates, andere nicht
- Treiber holen sich die MetaData durchaus unterschiedlich
- technische Casts von Daten (unterschiedliche OS haben unterschiedliche Charachter Encodings und implementieren numerische Daten unterschiedlich) kann so ein Treiber selber machen oder an die DB abtreten

Da sind schon ein paar Sachen bei, die zu unterschiedlichen Optimierungen/Pessimierungen führen können - solange das brummt. denkt da keiner drüber nach.

D*B