Abfrage greift auf eine View mit 25 Mio Zeilen zu und läuft einfach ewig.

Wie kann ich die Performance steigern?

DROP table NEUE_TABELLE;

CREATE table NEUE_TABELLE as

SELECT a.zeitstempel, a.vertragsnummer, a.vertragsversion,

a.datum1,a.herkunft,a.einheit,

SUM (a.einheit2) as einheit2,

SUM (a.einheit3) as einheit3,

a.sondernummer, a.sondernummer2,

a.nummer2,

CASE WHEN a.datum1 in ('N') then ('00000000')

ELSE NULL

END as Del_Kz

FROM VIEW_auf_Tabelle

WHERE a.datum1 IN ('N')

AND a.herkunft in ('XXX')

AND substr(organisation,1,2) in ('YY')

GROUP BY a.zeitstempel, a.vertragsnummer, a.vertragsversion,

a.datum1,a.herkunft,a.einheit,

a.sondernummer, a.sondernummer2,

a.nummer2,

CASE WHEN a.datum1 in ('N') then ('00000000')

ELSE NULL

END

;

CREATE INDEX NEUE_TABELLE ON NEUE_TABELLE (vertragsnummer);

analyze table NEUE_TABELLE ESTIMATE STATISTICS SAMPLE 50 PERCENT;

Abfrage greift auf eine View mit 25 Mio Zeilen zu und läuft einfach ewig.

Wie kann ich die Performance steigern?

Hallo

- Wie sehen den die Indizies auf der Ursprungstabelle aus ? Und deren Statistiken. Die Indizies und Stats der neuen Tabellen sind ja erst mal irreleveant. Zum Testen kannst du ja das CTAS weglassen....

Gruss

1.Tabelle Index auf Vertragsnummer

2. Tabelle Index auf Vertragsnummer,Vertragsversion,

3.Tabelle Index auf Vertragsnummer,Vertragsversion

4.Tabelle Index auf Produkt(im sql nicht abgefragt)

5.Tabelle Index auf ...(im sql nicht abgefragt)

6.Tabelle Index auf sparten (im sql nicht abgefragt,dafür aber ein attribut aus der tabelle)

CTAS = create table??

1.Tabelle Index auf Vertragsnummer

2. Tabelle Index auf Vertragsnummer,Vertragsversion,

3.Tabelle Index auf Vertragsnummer,Vertragsversion

4.Tabelle Index auf Produkt(im sql nicht abgefragt)

5.Tabelle Index auf ...(im sql nicht abgefragt)

6.Tabelle Index auf sparten (im sql nicht abgefragt,dafür aber ein attribut aus der tabelle)

CTAS = create table??

CTAS = Create Table As Select

- Sind die Statistiken aktuell ? (Auf der Ursprungstabelle)

Gruss

Ja, die Statistiken sind sogar ziemlich aktuell! Stand gestern! Dachte ich sollte lieber das sql umformulieren?

Ja, die Statistiken sind sogar ziemlich aktuell! Stand gestern! Dachte ich sollte lieber das sql umformulieren?

- Die Frage ist natürlich, was macht die View schon ? Ist es eine "einfache" Abbildung der Tabelle oder wird auch schon einiges gemacht ?

Gruss

Die View bildet per right outer join die Tabellen ab mit 4 kriterien (Where Kriterium in ('x','y'....).

Abfrage greift auf eine View mit 25 Mio Zeilen zu und läuft einfach ewig.

Wie kann ich die Performance steigern?

Wie groß ist die erwartete Ergebnismenge?

Da mindestens ein Sort im Spiel ist, würden mich auch die Größen der PGA interessieren.

Welches deiner (evtl. Kombination) Kriterien in der WHERE Klausel schränkt die Datenmenge am effektivsten ein?

Wie sieht der Ausführungsplan aus und passen die Kardinalitäten die dort angegeben werden?

Unabhängig davon: Ein solches SQL ist kaum für eine Ad Hoc Abfrage geeignet. Ich würde vorschlagen, dass Du anstelle einer View eine temporär genutzte Tabelle befüllst, diese indizierst und dann dort dein SQL absetzt.

Eine View mit Outer Join auf 4 Tabellen hat nicht unbedingt den Ruf extrem performant zu sein.

Dim

PS: Was bedeutet "läuft ewig" und was wäre "läuft schnell genug" in Sekunden bzw. Minuten ausgedrückt?

Die View bildet per right outer join die Tabellen ab mit 4 kriterien (Where Kriterium in ('x','y'....).

BTW, welche DB verwendest du überhaupt ? Wenn du Oracle benutzt, wäre es evtl sinnvoll, die zugrundeliegende View als Materialized View zu implementieren. Dies würde ich sicher mal testen.

Gruss