SQL Optimizer - Logische mit Select/Omit

[schatte]

Hallo,

also CQE wird auf jeden Fall schonmal benutzt, da dort eigentlich alle Dateien irgendwo eine Logische mit Omit haben. Ist aber erstmal nicht schlimm.

Schlimm ist aber, dass der Optimizer niemals die Logische mit dem Omit nehmen will, obwohl diese genau zur SQL-Abfrage passt.

Ich habe sogar extra mal eine kleinen Testfall gemacht. Ein PF mit 2 x LF. Eines mit nur Key und eines mit Key und Omit.
SQL drauf mit Abfrage auf den Key und das Omit-Feld. Und er nimmt immer die Logische ohne Omit. Obwohl man (aufgrund der großen Satzanzahl) eindeutig sehen kann, dass der Zugriff über die Omit-LF wesentlich schneller wäre.

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.

Wie kann das sein?

Gruß
Matthias

[BenderD]

... das ist öfter so, z.B. wenn der Mensch vor dem Bildschirm mehr Information über den Verlauf des Programmes hat als die Maschine; in diesem Fall könnte es sein, dass die Query Engine mit einbezieht, dass bei späteren Zugriffen eine geänderte where Klausel genau die Verwendung dieses Omit paths verhindern würde.

D*B

=> Da hat der "kleine Programmier" wohl den besseren Vorschlag gehabt.

Wie kann das sein?

Gruß
Matthias

[Fuerchau]

Deswegen sollte man ja an Stelle der LF mit Select/Omit eine View erstellen und den Select darauf loslassen.

Bei meinen Tests (siehe anderer Beitrag) konnte ich nun die SQE dazu bewegen sich einzuschalten.
Ich habe einfach eine QAQQINI in QUSRSYS erstellt und den SQL
update qusrsys/qaqqini
set qqval='*YES'
where qqparm= 'IGNORE_DERIVED_INDEX'
ausgeführt. 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.

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 !

Hierzu passt auch die Aussage:
If a derived index exists, have CQE process the query.

Und gerade wegen der CQE steht unser Systemwert QQRYTIMLMT auf *NOMAX, da sonst die meisten AS/400-Queries sonst auf Timeout laufen würden.

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.

Klar bin ich mit Kenntnis der Anwendung, Ausnutzung der DDS-Möglichkeiten in vielen Fällen mit Native-Access (SETLL/READE/...) schneller, aber SQL-Anwendungen erfordern eh ein anderes Denken und Design.

[B.Hauser]

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