Ferne SQL Analyse / Performance

[pwrdwnsys]

Hi Forum,

mich plagt ein ähnliches Problem... nur...
ich habe hier einige Views, die wollen unter keinen Umständen die Indices benutzen die bereits da sind. Visual Explain schlägt mir immer wieder diese Indices vor, obwohl diese längst vorhanden sind. Es handelt sich dabei sogar um völlig einfache wie z.B. Index auf dem Primary Key.

Ich habe auch schon versucht, diese komplett zu löschen und neu anzulegen, aber auch das blieb ohne Erfolg.

Ich weiss zwar, dass der Query Optimizer nicht unbedingt diese Indices benutzen muss, aber die Views sind sowas von Prozessorbelastend dass ich mich langsam frage, ob nicht irgendwas an unserer DB fehlerhaft ist. (Die Tabellen dahinter haben verhältnismässig wenige Einträge im 10.000 Bereich)

Leider gehen mir inzwischen die Ideen aus, so dass ich fast dazu übergehen möchte jemanden zu beauftragen der hier bei uns etwas optimiert, aber das ist wohl der letzte Schritt der mir so einfallen würde.

Oder gibt es noch andere Methoden Abfragen zu verbessern (JOIN-Reihenfolge, Indexzwang o.ä) ?

In der Regel liegt das an zu vielen Indexdateien. Der Optimizer der iSeries hat nur eine gewisse Zeitspanne zur Verfügung, um alle Indexdateien zu analysieren. Nach Ablauf dieser Zeit wird der bis dahin gefundene optimalste Zugriffspfad herangezogen oder ein temporärer erstellt, was dann perfomancemäßig ordentlich Zeit kostet.
So ähnlich stellte sich mein obiges Problem heute auch dar. Leider habe ich auf diese Maschine (300km weit weg) nur einen Telnet-Zugriff, der grafische Schnickschnack fällt also weg. Habe trotzdem heute ordentlich Performance gewonnen (einige Indexe gelöscht, neue erstellt). Das nächste Problem steht aber schon an (JDBC Zugriff zu langsam....)

[NEich]

@BHauser Danke für die Tips und die Links, ich hoffe die bringen mich weiter. Es handelt sich übrigens hierbei um reine SQL Tabellen/Indices mit Contraints und tadeldü, die Abfragen laufen über JDBC (welches ansonsten auch keine Schwierigkeiten macht), für fast alle Abfragen sind Views vorhanden, die so zwischen 10 und 30 Tabellen verknüpfen (nicht schimpfen, das ist nicht von mir)

@pwrdwnsys hatte icha uch schon in Betracht gezogen, jedoch sagt mir Visual Explain dass keinerlei QO Zeitüberschreitung stattgefunden hat.

[pwrdwnsys]

@BHauser Danke für die Tips und die Links, ich hoffe die bringen mich weiter. Es handelt sich übrigens hierbei um reine SQL Tabellen/Indices mit Contraints und tadeldü, die Abfragen laufen über JDBC (welches ansonsten auch keine Schwierigkeiten macht), für fast alle Abfragen sind Views vorhanden, die so zwischen 10 und 30 Tabellen verknüpfen (nicht schimpfen, das ist nicht von mir)

@pwrdwnsys hatte icha uch schon in Betracht gezogen, jedoch sagt mir Visual Explain dass keinerlei QO Zeitüberschreitung stattgefunden hat.

@NEich, das Problem das ein Zugriffspfad nicht verwendet wird hatte ich heute zufällig auch und davon gleich mehrere. Das einzige was mir dabei aufgefallen ist: alle diese nicht verwendeten Zugriffspfade verwenden Felder, deren Feldnamen länger als 10 Stellen sind. Normalerweise arbeitet die AS400 ja nur mit den 10 stelligen Feldnamen, die langen Feldnamen werden als ALIAS-Namen angelegt. Erfolgt der Zuriff nun aber über die "langen" Namen, dann kann der QO das vielleicht nicht erkennen und "vermutet" einen artfremden Zugriffspfad. Ist die einzige Erklärung die ich dafür habe. Werde das mal weiter analysieren.

Wer einen Tipp hat, wie ich das umgehen oder abstellen kann, immer her damit.

[NEich]

[...] alle diese nicht verwendeten Zugriffspfade verwenden Felder, deren Feldnamen länger als 10 Stellen sind[...]

Klingt nach nem guten Ansatz, würde einiges bei mir erklären können, denn genau diese (unverhältnismässig) performancelastigen Tabellen haben Prosatexte als Feldnamen.
Würde mich aber wundern, wenn der Optimizier das ignorieren würde :/