View Full Version : SQL-Optimizer V7R1 und kein Ende
Leider zeigt der Kunde da nicht das geringste Verständnis für die Aufwände, um diesen SQL zu überarbeiten, damit er für V7R1 passt.
... da muss er sich halt beim Lieferant der Datenbank beschweren, entweder hat die Datenbank oder ein Index ein defect Problem.
Wenn er da nicht durchdringt oder ihm das zu lange dauert, gibt es da vielleicht schon noch Software technische (Selektivität über UDTF vorziehen) oder Datenbanktechnische (mehr Redundanz über MQT) Möglichkeiten, eventuell auch in der Kombination.
D*B
Wie gesagt, es dreht sich nur um SQL per ODBC und kann auch nicht mit ILERPG abgelöst werden
Hast du den die Möglichkeit es in einem embeddet SQL (oder sogar interaktiv in eine andere Tabelle)
auszuprobieren? Zur Klärung der Frage: Ist es die DB oder ist es der ODBC Treiber.
Robi
@Robi
SQL kann nie von einem ODBC-Treiber ausgeführt werden. Dieser stellt ja nur die Verbindung zum System her und reicht dies dann an die DB weiter.
Man sieht das dann auch schön im Joblog des QZDASOINT.
Zumindest hat der Kunde mal versprochen, die DB-/PTF's noch zu installieren, ich werde berichten.
Ok, trotzdem gib es zwischen verschiedenen Treibern teilweise erhebliche performance Unterschiede.
Und ich meine, das wir mal den Fall hatten, wo ein ODBC Treiber ein SQL deutlich schneller ausführte als ein JDBC Treiber. Eine andere Anforderung (selbe AS400, selber PC) aber vom JDBC schneller bedient wurde. Daher denke ich schon, das der Treiber am Rande mitspielt.
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.
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.
Für diesen Fehler gibt es diese Fixes:
MF58386,MF58012,MF58026,SI51315,SI52705,MF57453,
SI52257
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.
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