Performance - SQL-Abfrage nach längerer Pause/IPL nicht ausführbar

[andreaspr@aon.at]

Du solltest auch ein Datenbank-Monitor drüber laufen lassen.
Dann siehst du welche Zweige am meisten verbrauchen und ob MTIs verwendet werden.
(Auch wenn die Abfrage innerhalb von 500ms durch ist)

[Fuerchau]

Anstelle des komplexen Concats würde ich doch Einzelfelder empfehlen, wobei fehlende Felder im 1. Union-Select durch konstanten definiert werden können.

Die Sortierung bzw. der Concat kann dann im Hauptselect erfolgen, da dieses ggf. nur noch auf das Ergebnis angewendet wird.

[berndl]

Vielen Dank Euch allen für die Tipps - hier mal eine Zusammenfassung:

Ich hab folgende Änderungen vorgenommen:
* Die JOIN-Orgien sind jetzt in zwei SQL Views ausgelagert.
* Im rekursiven SQL nehm ich nur noch auf die Views bezug.
* Auf das Sortierkriterium hab ich einfach mal verzichtet
* Gem. Visual-Explain wurden nur vorhandene LFs (DDS) verwendet - konnte keine MTI finden (kenne mich hier aber nicht so aus).

WITH LISTE
(GESHID, BTLHID, PTAHID, PTAHIDALTK, PTASTUFE, VERTRETENER, EBENE, PTGPTAGRP, PTG4STEUER) AS
(
SELECT GES.GESHID, GES.BTLHID, GES.PTAHID, GES.PTAHIDALTK, GES.PTASTUFE, 0 AS VERTRETENER,
DEC(1) AS EBENE, GES.PTGPTAGRP, GES.PTG4STEUER
FROM GES1 AS GES
WHERE GES.GESHID=333661 AND GES.FIRHID=22 AND GES.GGPHID =39
UNION ALL
SELECT V.GESHID, V.VERTRETER, V.PTAHID, V.PTAHIDALTK, V.PTASTUFE,
V.VERTRETENER AS VERTRETENER, X.EBENE + 1, V.PTGPTAGRP, V.PTG4STEUER
FROM BTV1 V
INNER JOIN LISTE AS X ON V.GESHID = X.GESHID AND V.vertretener = X.BTLHID
WHERE V.GESHID=333661 AND V.FIRHID=22 AND V.GGPHID =39 AND X.EBENE <= 5
)
SELECT GESHID, BTLHID, PTAHID, PTAHIDALTK, PTASTUFE, VERTRETENER, EBENE,
PTGPTAGRP, PTG4STEUER
FROM LISTE;

---
Auswirkungen:
* Die Abfrage braucht ca. 10 - 20x länger (auch nach mehrfacher Ausführung), der Cache scheint jetzt nicht mehr genutzt zu werden
* Abfragen mit mehr als 20 Sätzen kommen innerhalb einer halben Stunde nicht mehr zurück (hab dann abgebrochen)
* Gem. VisualExplain wird statt SQL-Views weiterhin auf die DDS-LFs zugegriffen, obwohl alle verwendeten Felder in den Views sind.

Aus Zeitgründen hab ich das Ganze jetzt auf Left-Outer-Joins für max. 10 Ebenen umgestellt - auch wenn das nicht ganz sauber ist. Trotzdem nochmals herzlichen Dank für all die Ideen!

Kann mir jemand eine Einführungs-Lektüre zur SQL-Optimierung auf der AS empfehlen - ich glaube, ich brauch hier noch etwas Grundwissen zu VisualExplain / PerformanceMonitor und QAQQINI. Im Moment fehlt mir hier absolut der Überblick...

merci!

[andreaspr@aon.at]

Das wird dir sicher weiter helfen können:
http://publib.boulder.ibm.com/infoce...zajq/rzajq.pdf

Eine View siehst du im Visual Explain nicht als eigenes Objekt. Eine View selbst wirkt sich auch nicht auf die Performance aus, da das Select der View hergenommen wird.
Wenn du also ein

Select * from MyView

machst, siehst du im Visual Explain nicht MyView, sondern das Select, welches sich in MyView befindet.
Es ist das gleiche, wie wenn du das Select direkt abgesetzt hättest.

Views werden eher für Übersichtlichkeit und Berechtigungen verwendet.

lg Andreas

[B.Hauser]

Auswirkungen:
* Gem. VisualExplain wird statt SQL-Views weiterhin auf die DDS-LFs zugegriffen, obwohl alle verwendeten Felder in den Views sind.

Kann mir jemand eine Einführungs-Lektüre zur SQL-Optimierung auf der AS empfehlen - ich glaube, ich brauch hier noch etwas Grundwissen zu VisualExplain / PerformanceMonitor und QAQQINI. Im Moment fehlt mir hier absolut der Überblick...

merci!

1. Sind in der Visual Explain übersicht irgendwo temporary Indices aufgeführt? Wenn ja, so sind dies die MTI
2. Sofern DDS beschriebene logische Dateien verwendet werden, erstelle zusätzlich Indices mit den gleichen Key-Feldern wie die DDS beschriebenen logischen Dateien. Indices werden aufgrund der größeren Pagesize vom Optimizer bevorzugt.
Die bestehenden DDS beschriebenen logischen Dateien sollten anschließend gelöscht und neu erstellt werden. Dann können die logischen Dateien den gleichen Zugriffspfad wie die SQL Indices verwenden und erhalten zusätzlich eine Pagesize von 64 K.

Was Performance Optimierung hier ist ein Link aus dem Information Center:
Database performance and query optimization


Das folgende Whitepaper sollte auch unbedingt gelesen werden:
IBM DB2 for i
indexing methods and strategies

Birgitta