Forum

Hallo Uli,

danke für deinen Hinweis, dass DB2 auf den definierten DPSIs offensichtlich kein partiton pruning durchführen wollte / konnte.

Das hat mich zur Ãœberlegung gebracht, wie den mein PARTITION BY RANGE Parameter aussieht. Und siehe da: ich hatte die von IBM propagierte Methode der Umstellung auf Table-Controlled Partitioning durchgeführt, indem ich die Befehle ALTER INDEX NOT CLUSTER / CLUSTER auf den Partitioning Index abgesetzt hatte. Dabei hat DB2 nicht nur die Limitkeys vom Index auf die Table übertragen, sondern – wie mir jetzt auch bewußt wurde – auch alle Keycolumns des Index als PARTITION BY RANGE-Columns aufgenommen, obgleich im Index nur bei der ersten von den 11 Columns ein Limitkey definiert war.

Nachdem ich den PARTITION BY RANGE Parameter jetzt angepasst habe, besteht er jetzt nur noch aus der Spalte, auf der die Limitkey-Values definiert sind. Und siehe da: Jetzt nimmt DB2 auch den richtigen zum ORDER BY passenden DPSI und verzichtet auf einen add. sort!

Eine wichtige Erkenntnis, dass man mit dieser Methode (Umstellung ohne Unload / Reload) vorsichtig sein muss, da DB2 dann wesentlich mehr Schwierigkeiten hat sich für partition pruning zu enstscheiden!

Viele Grüße, frohe Weihnachten und ein gesegnetes neues Jahr!
Peter