SQL Performance

[BenderD]

Hallo,

erstmal würde ich alle nicht Verknüpfungen in den Join Bedingungen in die where Klausel aufnehmen.
Für die Join Felder werden in jedem Fall Indexe benötigt, ansonsten geht das immer in den Wind (ein Cross Join, schon ist man bei Milliarden von Sätzen!!!); wenn ich da nichts übersehen habe, dann landen die CAT Felder alle in der Where Klausel, nicht so toll, aber nicht tödlich. Bei dem order By ist der upper natürlich schädlich, den könnte man durch ein zusätzliches Feld (kann man durch Trigger pflegen, ohne Änderung der Anwendung, die verwendet eine View ohne das Feld) wegbekommen. Über dieses Feld muss natürlich ebenfalls ein Index da sein.
Wenn ich das richtig sehe, werden alle Dateien über denselben Key verjoint, sprich der Pessimizer sollte eigentlich in Abhängigkeit von der where Klausel (wie sieht die übrigens aus???) die Table mit der höchsten Selektivität nach links stellen, was bei vielen Treffern wegen dem Order by auf die erste problematisch werden kann. Dann könnte es einen Versuch wert sein die Sortierung "breiter" zu machen und über einen kompletten Key der ersten Table zu ziehen, oder per QAQQINI (force Join order) die erste Tabelle nach links zu zwingen.
Falls die beteiligten Tabellen "viele" (= etliche zig) Indexe haben sollte man auch mal ein Auge darauf haben, ob der Optimizer einen Timeout bekommt.
Für die relevanten (= die mit der höchsten Selektivität) Where Klausel Felder werden natürlich ebenfalls passende Indexe benötigt.

mfg

Dieter Bender

Die View sieht so aus:
CREATE VIEW PPGIDPV
(RSPD00, RSPF00, IITM00, JDSC00, QPR100, QPR200,
EANR00, IBON00, OABC00, OCOA00, IACG00, USPL00,
WCST00, PSTY00, STVL00, SUPO00, COSS00,
PRDT1N, ITTY1N,
PLNU1N, PLNG1N, PURU1N, BYGG1N, FXSU1N, OPRP1N, DISP1N,
OQUI1N, LOTI1N, IDRE1N, SRQF1N, BTFL1N, SPTT1N, PRCI1N,
QCFW1N, HDSP1N, CRPF1N, PRCP1N, GICP1N, STQF1N, STQE1N,
RTGN1N, RTSS1N,
ITMS1I,
TXT11G, TXT21G, TXT31G)
AS SELECT
RSPD00, RSPF00, IITM00, JDSC00, QPR100, QPR200,
EANR00, IBON00, OABC00, OCOA00, IACG00, USPL00,
WCST00, PSTY00, STVL00, SUPO00, COSS00,
PRDT1N, ITTY1N,
PLNU1N, PLNG1N, PURU1N, BYGG1N, FXSU1N, OPRP1N, DISP1N,
OQUI1N, LOTI1N, IDRE1N, SRQF1N, BTFL1N, SPTT1N, PRCI1N,
QCFW1N, HDSP1N, CRPF1N, PRCP1N, GICP1N, STQF1N, STQE1N,
RTGN1N, RTSS1N,
ITMS1I,
cast(
(case when t1.TEXT1G is null then ' ' else t1.text1g end)
as char(50)) as text1,
cast(
(case when t2.TEXT1G is null then ' ' else t2.text1g end)
as char(50)) as text2,
cast(
(case when t3.TEXT1G is null then ' ' else t3.text1g end)
as char(50)) as text3
FROM GIDPF300
LEFT OUTER JOIN GIDPF01N ON
ITNR1N = IITM00 AND
LGNT1N||SCPB1N = 'ATAT'
LEFT OUTER JOIN GIDPF01I ON
ITNR1I = IITM00 AND
LGNT1I||SCPB1I||CMPN1I = '000000'
LEFT OUTER JOIN GIDPF01g as t1 ON
t1.ITNR1G = IITM00 AND
t1.ITNR1G = IITM00 AND
t1.LGNT1G||t1.SCPB1G||t1.CMPN1G = '000000' AND
t1.TXTY1G = ' ' and t1.TXTP1G = 'IDS' and t1.LNGG1G = 'DE' AND
t1.posn1G = '0010'
LEFT OUTER JOIN GIDPF01g as t2 ON
t2.ITNR1G = IITM00 AND
t2.LGNT1G||t2.SCPB1G||t2.CMPN1G = '000000' AND
t2.TXTY1G = ' ' and t2.TXTP1G = 'IDS' and t2.LNGG1G = 'DE' AND
t2.posn1G = '0020'
LEFT OUTER JOIN GIDPF01g as t3 ON
t3.ITNR1G = IITM00 AND
t3.LGNT1G||t3.SCPB1G||t3.CMPN1G = '000000' AND
t3.TXTY1G = ' ' and t3.TXTP1G = 'IDS' and t3.LNGG1G = 'DE' AND
t3.posn1G = '0030'

Satzanzahl
GIDPF300 - 1,8 Millionen
GIDPF01N - 450.000
GIDPF01I - 320.000
GIDPF01G - 2,1 Millionen

Wenn jemand eine Idee hat, wie man optimieren kann - her damit.

Das einzige was im SQL "fix" ist, ist am Ende ORDER BY (aber auch wieder abhängig von der Eingabe: upper(JDSC00) oder IITM00) und neu "optimize for 20 rows".

[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

[Fuerchau]

Wenn ich beim "left join" die Beziehung in die Where-Klausel verlege, wird daraus in "inner join".

Hier allerdings sind in der Join-Beziehung Felder aus der linken Tabelle mit Konstanten an Stelle von Feldern auf der rechten Seite benannt.

Solche Bedingungen stellen keine Beziehung dar und gehören in die Where-Klausel.

[BenderD]

Hallo,

der Knackpunkt sind nicht die Felder, sondern die Join Bedingungen, where Klauseln und order by Kriterien. Wie kommst du bei 6 Joins auf die 1,8 Millionen Sätze? wenn das tatsächlich die relevante Größenordnung ist, dann ist das nicht viel. Bei neuerem Release könnte auch die ach so famose neue Query Engine das Problem sein (manchmal helfen PTFs)

Dieter Bender

Dynamisches SQL aus einem ganz einfachen Grund:

In der View befinden sich 46 Felder aus 6 physischen Dateien, die - je nach Anforderung - in unterschiedlichsten Kombinationen selektiert werden.

Die View beinhaltet dzt 1,8 Millionen Sätze.

Die Ablehnung der Indexe erfolgt übrigens immer mit Code '4' - braucht zu viel Zeit - gleichzeitig wird ein Index mit den gleichen Feldern immer wieder empfohlen.

Bei der Maschine handelt es sich um eine 570 mit 4 Prozessoren und 64 GB Hauptspeicher - also kein langsamer Rechner.