Query mit Eingangsfolge

[BenderD]

Hallo Birgitta,
ich bin wie meist mit vielem einverstanden, was du da schreibst und empfiehlst; in diesem Punkt würde ich widersprechen wollen.
Auf die Angabe von Sortierungen kann man nur verzichten, wenn einem die Reihenfolge wirklich egal ist (was fast nie der Fall ist) und wenn es einen passenden Index gibt, wird da in der Regel nix sortiert und es wird meist sogar eher schneller als langsamer, da der Query Pessimizer von unsinnigen Entscheidungen fern gehalten wird (was bei der famosen neuen Query Engine oft die letzte Rettung ist).

ansonsten beste Grüße von D*B an F*Z

Dieter Bender

... die benötigten Datensätze selektiert und in ein temporäres Objekt ausgegeben werden. In einem weiteren Schritt werden dann die in dem temporären Objekt gespeicherten Daten in der gewünschten Reihenfolge sortiert.
(Deshalb sollte man auch den Order By nicht angeben, wenn er nicht unbedingt erforderlich ist.)

Birgitta

[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

[BenderD]

Hallo Birgitta,

da gehen mir doch ein paar Dinge an der Praxis vorbei:
eine unter Verwendung von SQL geschriebene Anwendung hat hunderte von SQL Statements, wenn nicht tausende, da helfen mir Werkzeuge wie Ooops Nerv überhaupt nichts und eine Optimierung Statement für Statement ist völlig inakzeptabel. Die gängige Vorgehensweise ist dabei:
- sauberes Design der Datenbank mit primary Keys für jede Table und referential Constraints für alle Key Beziehungen der Normalisierung, damit sind die wichtigsten Keys angelegt.
- klare Schichtentrennung in der Anwendung mit einer klar definierten Datenbank Zugriffs Schicht, damit ist alles für Optimierungen zentralisiert.
- first do it right, then make it fast also schreiben der Datenbankzugriffe orientiert am Anwender, nicht an der Datenbank (und kein Anwender versteht, wenn ihm die Datenbank Engine nach jedem PTF eine andere Reihenfolge präsentiert!!!)
- Messung mit Database Monitor und Optimierung des Index Designs
- jetzt bleiben maximal 1 % der Zugriffe über, die man in der Anwendung noch optimiert und das wars.

Zu deinen Messungen noch: die Laufzeiten sind allesamt völlig inakzeptabel (sowohl 56, wie auch 200 sec sind für jede Anwendung zuviel!) und man sollte zuerst der Sache auf den Grund gehen, warum da full Table Scans gemacht werden!!!

Zu den EVIs: ich habe noch keine Konstellation gefunden, in der ein EVI jemals verwendet wurde, geschweige denn was gebracht hätte und die Empfehlung in den Handbüchern diese Dinger vor Updates zu löschen und danach wieder aufzubauen (hat bei 500 Millionen Sätzen und 2 Ausprägungen eines 3 stelligen Mandanten Keys ca. 90 Minuten gedauert!!! und anschließend hat die famose neue Query Engine einen full tablescan gemacht???), kann ja nur ein Scherz sein.

mfg

Dieter