So, ich sach ja, der Optimizer ist einfach blöd !

Ich habe nun in der QUSRSYS eine QAQQINI angelegt und einzig folgende Option eingestellt:

update qusrsys/qaqqini
set qqval='*YES'
where qqparm= 'IGNORE_DERIVED_INDEX'

Sämtliche anderen Parameter stehen auf ihrem Initialwert *DEFAULT, von denen ich nun mal annehme, dass der Optimizer diese auch annimmt, wenn die QAQQINI fehlt.

Die geschätzte Abfragezeit sank von 40.237 auf nun noch 447 Sekunden. Da mein Timeout auf 32.000 steht, ist das genug.

Die tatsächliche Abfragezeit (die rechne ich selber vom Start des Executes bis zum 1. Satz) sank von 110 Sekunden auf 13 Sekunden.

Dies ist die Beschreibung von IBM:

IGNORE_DERIVED_INDEX
*DEFAULTThe default value is the same as *NO.*YESAllow the SQE optimizer to ignore the derived index and process the query. The resulting query plan will be created without any regard to the existence of the derived index(s). The index types that are ignored include:
  • Keyed logical files defined with select or omit criteria and with the DYNSLT keyword omitted
  • Keyed logical files built over multiple physical file members (V5R2 restriction, not a restriction for V5R3)
  • Keyed logical files where one or more keys reference an intermediate derivation in the DDS. Exceptions to this are: 1. when the intermediate definition is defining the field in the DDS so that shows up in the logical's format and 2. RENAME of a field (these two exceptions do not make the key derived)
  • Keyed logical files with K *NONE specified.
  • Keyed logical files with Alternate Collating Sequence (ACS) specified
  • SQL indexes created when the sort sequence active at the time of creation requires a weighting (translation) of the key to occur. This is true when any of several non-US language IDs are specified. It also occurs if language ID shared weight is specified, even for language US.
*NODo not ignore the derived index. If a derived index exists, have CQE process the query.

Keine der obigen Bedingungen scheint zuzutreffen, trotzdem arbeitet der Optimizer nun irgendwie anders.

Die Diagnosenachrichten im Joblog sind die gleichen wie vorher (Index/LF wegen Kosten nicht genutzt), empfohlene Zugriffswege, die dann auch nicht genutzt werden (habe ich probiert, Index erstellt, nun folgte die Nachricht, dass der Index auf Grund der Sortierfolge nicht genutzt wird, also Index wieder gelöscht).
Die Antwortzeiten sind nun wieder wie bei V5R3.

Vielleicht kann mir Birgitta (gerne auch andere) ja noch Erklärungen liefern.

Ach ja, das ganze läuft auf einer 525 mit 16GB Hauptspeicher, 917 G Platte (16 Disks, 47% belegt), ca. 1500 aktive Jobs bei einer CPU-Auslastung von ca. 15% (WRKSYSSTS).