Query mit Eingangsfolge

[B.Hauser]

Hallo Dieter,

das kann ja vielleicht alles stimmen, sofern wirklich wenige aber dafür optimale Indices vorhanden sind und die Datenbank ausserdem sauber designed ist. (... was bei vielen wohl nicht der Fall sein wird.)

Wenn der Optimizer allerdings nun keinen optimalen Index finden kann, wird ein suboptimaler Index oder sogar ein Table scan verwendet und das Ergebnis im Anschluß sortiert. Bei der CQE wird u.U. ein temporärer Index gebildet. Bei der SQE wird, zumindest vor Release V5R4, darauf verzichtet. Der Grund dafür liegt darin, dass zur Erstellung eines Indices sowieso ein Table Scan erforderlich ist. Also bleibt man beim Table Scan, erstellt kein neues Objekt und sortiert anschließend. Ab Release V5R4 können quasi permanente Indices gebildet werden, d.h. Indices die im Plan-Cache gespeichert werden und von allen Jobs verwendet werden können. Diese Indices werden erst dann gelöscht, wenn der letzte Access Plan, der diesen Index verwendet aus dem Plan-Cache verschwindet, oder IPL, bei dem der Plan-Cache gecleart wird, gefahren wird.

(Binary Radix Tree) Indices, werden nur verwendet, wenn das erwartete Ergebnis weniger als 20% der Gesamtzahl der Sätze umfasst. Zwischen 20 und 70% kann der Optimizer Encoded Vector Indices verwenden. Wird allerdings eine Sortierung angegeben können EVIs nur begrenzt eingesetzt werden.

Kann nur ein suboptimaler Index verwendet werden, erfolgt die Sortierung im Nachhinein. Eine nachträgliche Sortierung ist ein zusätzlicher Aufwand, d.h. wenn eine Sortierung nicht erforderlich ist, nicht angeben! Ich muss fairerweise zugestehen, dass man u.U. durch die Angabe einer Order By-Anweisung der Optimizer dazu bringen kann einen Zugriffsweg anstatt eines Table scans zu verwenden. Allerdings sollte man das erst probieren, wenn auch ein FOR OPTIMIZE OF mit einer kleinen Anzahl an Zeilen kein Erfolg gebracht hat.

Die Order By-Anweisung ist auch das letzte, das der Optimizer bei der Suche nach dem optimalen Index in Betracht zieht. Er geht nach der folgenden Reihenfolge vor:

1. Join-Bedingungen und Where-Auswahl
2. Where-Auswahl und Join-Bedingungen
3. Where-Auswahl und Group By-Anweisungen
4. Where-Auswahl und Order By-Anweisungen

... sicher man könnte den optimalen Index anlegen und wo schon hunderte von Zugriffswegen auf den Dateien liegen, tut ein zusätzlicher Index auch nicht mehr weh

Ich weiß, Du liebst die bunten Bilder im iSeries Navigator nicht so sehr, aber mit Visual Explain kann man das Ganze schön sichtbar machen.

Ich habe es vorhin ausprobiert mit einer Standard-Abfrage bei uns.

select * 
   from LLAKOPP
   where FIRNR = 600 and AKKNDB = 'XXX' and AKLAO = 'YYY' and AKSTS = '01'
   Order By FIRNR, AKKNDB, AKLAO, AKSTS, AKKND, AKZUA, AKBNR; 

Ich ging auch davon aus, dass passende Zugriffswege vorhanden sind. Dennoch war das Ergebnis folgenes:

1. CQE ohne Sortierung: Verwendung eines Zugriffsweges nach FIRNR/AKKNDB/AKSTS/AKBNR --> Zeit: 162489 Ms
2. CQE mit Sortierung: Erstellung eines temporären Indices (mit Table scan) --> Zeit: 204752 Ms
3. SQE ohne Sortierung: Verwendung eines Zugriffsweges nach FIRNR/AKKNDB/AKSTS/AKBNR --> Zeit: 56984 Ms
4. SQE mit Sortierung: Verwendung des gleichen Zugriffsweges nach FIRNR/AKKNDB/AKSTS/AKBNR mit anschließender Sortierung --> Zeit 86506 Ms

Die gleichen Statements wurden mehrfach ausgeführt. Die Zeitverhältnisse waren immer ungefähr identisch.

... Man kann noch viel philosophieren und interpretieren. Ich habe jedoch das Gefühl, je mehr man glaubt den Optimizer zu verstehen, desto weniger versteht man ihn. Im Prinzip muss man an jedem einzelnen SQL-Statement solange herum drehen, bis es optimal läuft.

@Fuerchau:

Das mit der View geht solange gut, solange man wenige Sätze hat.
Da der Optimizer nun mal immer auf der PF aufsetzt, habe ich zwar für Query nun die Satznummer, aber bei einer Sortierung nach dieser erfolgt eben immer ein Table-Scan und zwar unabhängig von jedweder Verfügbarkeit von LF's (ich habe es mit einer 2,5Mio-Date bei V5R3 ausprobiert).

Lasse ich die Sortierung weg, klappts auch mit den LF's.
Ich denke, das liegt daran, dass die RRN eine Funktion und kein Feld ist. Bei Sortierung nach UDF's siehts genauso bescheiden aus.

Wenn ich aber weiß, dass das Zwischenergebnis nur ein paar 1000 bis 10.000 Sätze sind, ist das über einen Insert/Select bzw. Create/Select um Faktoren schneller.

Dann machst Du was falsch! Bei meinen Tests hat der Optimizer für die Selektion von ein paar Hundert Sätzen aus der großen Datei mit unterschiedlichen Abfragen jeweils einen Zugriffsweg (DDS beschriebene logische Datei!) verwendet und anschließend nach RRN sortiert. (und zwar sowohl mit der CQE als auch mit der SQE!). Ich habe allerdings auch Zugriffswege über die in den Where-Bedingungen angegebenen Felder gehabt. (Where-Bedingungen werden vom Optimizer den Order By-Anweisungen vorgezogen!)

SQL kann nur Zugriffswege, die auf Original-Feldern liegen verwenden. Du kannst auch nur Indices mit Datei-Feldern anlegen. DDS beschriebene logische Dateien, in denen z.B. Schlüssel auf neugenerierte Felder z.B. durch Verknüpfung oder Substring verwendet werden, können von SQL nicht benutzt werden.

Was man auch machen kann, wäre eine MQT (Materialized Query Table) anzuglegen und über die Spalte Relative Satz-Nr. einen Index generieren. Die MQT muss zwar immer wieder neu aufgebaut werden über das SQL-Statement REFRESH, kann aber dann den Index über die Spalte relative Satz-Nr. verwenden.

Birgitta