Hallo Rince,

der Schlüssel zum Verständnis liegt immer in der Original Frage:

Nun sagt er mir aber leider nicht einen Schlüssel zur Optimierung (wie er es sonst so gerne macht) sondern gibt mir nur ein
*MAP ASCEND
als Schlüsselwort für die temporäre Datei an.

sobald der Query Optimizer sich entscheidet eine temporäre Zwischendatei anzulegen, sind mit zusätzlichen Indexen an dieser Stelle alle Spatzen gefangen.

Du hast in Deinem Query auf oberster Ebene einen Union, den Du dann per ORDER BY nach Feldern aus den beiden Dateien sortieren willst, dass die was miteinander zu tun haben merkt der Query Optimizer nicht und damit kann er auch nichts anfangen.

Alle Tricks die temporäre Tabelle zu verhindern helfen nix, da die View wg. der Gruppierung read only ist, alle Tricks einen bestimmten Zugriffspfad durch eine erweiterte ORDER BY Klausel zu favorisieren, scheitern letztlich daran, dass Zugriffs relevante Felder nicht im ResultSet sind.

Ich würde von der Analyse her im ersten Schritt den Union rausnehmen und die beiden resultierenden Queries unter debug ansehen, was der Optimizer macht - respektive empfiehlt. (das muss natürlich im Produktions Umfeld erfolgen: Datenmenge Batch oder interaktiv). Wenn hier keine Indexe mehr fehlen, dann den Union untersuchen - meine Erfahrung sagt mir aber, dass DB2/400 keinen Union kann; bis V5R1 nicht und das Marketing Getöse von der neuen 5.2er Query Engine sollte man mit Vorsicht genießen, die ist vielleicht mit V6 halbwegs fertig.

mfg

Dieter Bender