Zitat Zitat von Fuerchau Beitrag anzeigen
Und siehe da, ich hatte keinen QueryTimeout mehr, da die pessimistische Zeitschätzung der CQE von ca. 40.000 Sekunden durch die Zeitschätzung der SQE auf 447 Sekunden sank.[/FONT]
Da parallel zu meinem laufenden SQL (ca. 800.000 Sätze) ein 2. Client mit dem gleichen SQL zugriff, sank die reine Queryzeit auf einmal sogar auf 0,2 Sekunden !
Wenn tatsächlich von der SQE ein temporärer Index erstellt wurde, kann dieser genauso wie der Access Plan, der im SQE Plan Cache gespeichert wird, von jedem anderen Job aus verwendet werden, zumindest bis der Access Plan aus dem Plan Cache verschwindet.

Ab V6R1 soll es ja besser werden, da man dann auch berechnete Indices erstellen kann. Wenn dann ein SQL mit Where/Join/Order genau passt, wird dieser wohl auch verwendet werden.
Vorerst können Indices mit Where-Bedingungen nur mit native I/O verwendet werden. Der SQE Query Optimizer kann z.Z. diese Erweiterungen noch nicht nutzen, d.h. es wir genau wie bei SQL-Dateien mit Select/Omit-Anweisungen mit dem kompletten Zugriffsweg gearbeitet.
... aber die Nutzung durch die SQE ist geplant. Die CQE wird diese Indices nie nutzen können.

SELECT auf das PF (Optimizer wählt die LF ohne Omit): ca. 10 Sekunden
SELECT direkt auf die LF mit Omit (Optimizer akzeptiert meinen Vorschlag): < 1 Sekunde.
=> Da hat der "kleine Programmier" wohl den besseren Vorschlag gehabt.
Nein, da war dem Optimizer die DDS-Datei zu komplex bzw. das Rewriting zu aufwändig und die Datei wurde direkt verwendet. Das kommt bei der CQE ab und zu vor.

Was man allerdings bei der CQE/SQE-Geschichte berücksichten sollte. Seit V5R3 können alle Neuerungen nur von der SQE verarbeitet werden.
z.B. Except und Intersect (V5R3), OLAP-Ranking-Funktionen und Rekursive Abfragen (V5R4), RollUp, Cube und Grouping Sets (6.1)

Birgitta