SQL Performance

[BenderD]

Hallo,

wenn ich das richtig lese, sind die Felder der where Klausel alle aus der ersten Table.
Das erste der Beispiele sollte eigentlich schnell sein (< 1 sec), ansonsten liegt klar ein Problem mit Indexen vor, oder der Query Optimizer hat einen Schuss (was bei der famosen SQE recht häufig ist). Dann muss das ausanalysiert werden, bevor man sich mit weiterem beschäftigt.

Das zweite Beispiel hat durch den order by upper(...) eine Laufzeitkomponente, die von der Größe des Resultsets abhängt. So ganz schlimm dürfte das aber nicht sein, wenn ein Index über JODSC00 vorhanden ist (der logischerweise dieses Feld als erstes haben muss).

Das dritte Beispiel erzwingt durch das UPPER(JDSC00) like '%/2 LI%' in der Where Klausel einen Full Table scan, unabhängig von allen eventuell vorhandenen Indexen, das kann nicht schnell gehen!

Das mit der Datenbank, das kann EDV fachlich gesehen kein Problem sein, allenfals politisch hierarchisch:
- neue Datei GIDPF301 mit zusätzlichem Feld UJDSC00
- View GIDPF300 mit allen Feldern ausser UJDSC00
- Trigger an GIDPF301 anhängen der UJDSC00 mit upper(JDSC00) füllt
- Umbau deiner View

Angemerkt sei an dieser Stelle noch, dass das durchaus ein typischer Fall für eine View ist, die sind nämlich für den Programmierer (für den wirds einfacher), und nicht für die Datenbank (die wird dafür gekauft, dass sie das abkann).

Zum Beispiel so:

SELECT * FROM PPGIDPV WHERE
RSPD00 = 'ATAT ' and RSPF00 = 'J' and ITTY1N <> 'VO' and
QPR100 like '0301__03____________%' order by IITM00 optimize for 20 rows

oder

SELECT * FROM PPGIDPV WHERE
RSPD00 = 'ATAT ' and RSPF00 = 'J' and IITM00 >= 'H000015'
and ITTY1N <> 'VO' and UPPER(JDSC00) >= 'BA 148/2 '
order by upper(JDSC00) optimize for 20 rows

oder

SELECT * FROM PPGIDPV WHERE
RSPD00 = 'ATAT ' and RSPF00 = 'J' and
UPPER(JDSC00) like '%/2 LI%' order by upper(JDSC00) optimize for 20 rows

Die Cat-Anweisungen in der View habe ich bereits umgebaut. Wurde damit schneller.

Das die UPPER-Anweisung stört ist mir klar - kann aber leider die Datenbank nicht umbauen