SQL Performance

[Dirschl]

(wie sieht die übrigens aus???)

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

[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

[Fuerchau]

Auch für das Upper/like im where gilt, dass das nicht so tragisch ist, wenn es vorher bereits Schlüsseleinschränkungen gibt:

where k1=w1 and k2=w2 and upper(k3) like '....'

Über K1 und K2 sollte dann natürlich ein Index vorhanden sein.

übrigens:

like '0301__03____________%'
==
like '0301__03%'

[Dirschl]

übrigens:

like '0301__03____________%'
==
like '0301__03%'

Ist mir schon klar - war nur reine Bequemlichkeit beim programmieren - es können auch noch weiter hinten in dem Feld Einschränkungen kommen - dürfte aber von der Performance egal sein.

@BenderD
Mit dem Umbau hab ich kein fachliches Problem - ist mir schon klar wie das zu lösen ist - nur ich DARF NICHT!

[Fuerchau]

Wenn ich mir die View so anschaue, stellt sich mir die Frage ob tatsächlich "LEFT JOIN" benötigt wird.

Left join heißt ja, dass auf der rechten Seite durchaus Sätze fehlen dürfen, also NULL zurückkommt.

Die Bedingungen sehen allerdings mehr so aus, dass ein "inner join" besser erscheint.

Dann würde ich die Beziehung auch eher in die Where-Klausel legen:

select ...
from file1 a, File2 b
where a.key=b.key and ...

[Dirschl]

Left join heißt ja, dass auf der rechten Seite durchaus Sätze fehlen dürfen, also NULL zurückkommt.

Das Join auf GIDPF01G (3x) kann tatsächlich NULL zurückbringen - diese Sätze sind sehr oft nicht vorhanden!
Daher auch die Case-Abfrage auf NULL (mittlerweile auf "coalesce" umgebaut).

[BenderD]

@Baldur:
den left outer kann man nicht weglassen, das sind 1 zu 0 bis n Beziehungen zwischen der ersten Table und ihren Satelliten und von denen, die es gibt, will man nur bestimmte haben. Von daher war die Formulierung in der join Klausel durchaus adäquat und dies darf das Problem eigentlich nicht verursachen.

@Dirschl:
wielange läuft denn nun genau die Abfrage:
SELECT * FROM PPGIDPV WHERE
RSPD00 = 'ATAT ' and RSPF00 = 'J' and ITTY1N <> 'VO' and
QPR100 like '0301__03____________%' order by IITM00 optimize for 20 rows
und wenn das länger als 1 sec dauert, welche Indexe hast du genau auf der RSPD00 und was wird für ein Access Plan generiert (sieht man unter debug, oder mit dem DBMON)?

Dieter Bender

PS: die Abfragen mit Like und Wildcard % am Anfang, die kann man eigentlich nur mit Hardware (Prozessor und parallel Database Feature, oder Platte für zusätzliche Riesen Indexe) flott machen.

Wenn ich mir die View so anschaue, stellt sich mir die Frage ob tatsächlich "LEFT JOIN" benötigt wird.

Left join heißt ja, dass auf der rechten Seite durchaus Sätze fehlen dürfen, also NULL zurückkommt.

Die Bedingungen sehen allerdings mehr so aus, dass ein "inner join" besser erscheint.

Dann würde ich die Beziehung auch eher in die Where-Klausel legen:

select ...
from file1 a, File2 b
where a.key=b.key and ...

[Dirschl]

@BenderD
Aktuelle Messung: ca. 1 sec

Die Zeiten schwanken etwas, sind aber im Vergleich zu gestern aufgrund der Umbauten wesentlich schneller.

Im Debug sehe ich keinen Zugriffsplan - vom DBMON habe ich leider keine Ahnung.

Die Selektionsfelder befinden sich bei dieser Abfrage alle in der Datei GIDPF300 - lt. Debug verwendet er 2 Indexe.

[Fuerchau]

Das ist doch i.O., oder ?
Noch schneller gehts doch gar nicht.

[Dirschl]

Das ist doch i.O., oder ?
Noch schneller gehts doch gar nicht.

Ist richtig!

Diverse Schwankungen die ich bei den Messungen noch festgestellt habe, werde ich jetzt einfach mal ignorieren und als gegeben hinnehmen (die SQL-Performance werde ich wohl nie kapieren - obwohl ich mittlerweile auf dieser Maschine sehr viel mit SQL arbeite - aber ich muss nicht alles kapieren )

Besten Dank für Eure Hilfe!

[Fuerchau]

Schwankungen resultieren ggf. aus anderen Job's, oder hast du die Maschine für dich alleine ?

[Dirschl]

Ist mir schon klar, dass andere Job's die Schwankungen theoretisch verursachen können.

ABER: Die Maschinie "fadisiert" sich üblicherweise - und Schwankungen um das 3-5 -fache - bei gleicher Auslastung - lassen sich nicht durch andere Job's erklären - und schon gar nicht nach 18:00 Uhr!

Aber was soll's - ist halt so (habe auch schon mal festgestellt, dass nach einem Betriebssystemwechsel die SQL-Performance zusammengebrochen ist - hat plötzlich 10-15 mal solange gedauert wie vorher!)

Anderes Problem:

Kann ich eigentlich einen Index über ein Teilfeld legen (z.B: Index über Substr(qpr100, 4, 16).