Anonym.
Hallo,
ich habe ein merkwürdiges Phänomen:
Auf einer partitioned Table sind drei DPSIs definiert. Alle drei DPSIs beinhalten die gleichen Columns nur in anderer Reihenfolge.
Nach einem Runstats sieht die FUllkeycardinality bei allen dreien wie folgt aus:
DPSI1: 11595634
DPSI2: 11595634
DPSI3: 10223616
Alle drei haben Clusterratio 99%. Die Cardinality der Table ist 11595634.
Der Effekt ist, das eine Query mit einer ORDER BY Clause, die genau DPSI2 entspricht nun DPSI3 nimmt und einen Additional sort macht, was zu Performance Problemen führt.
Kann mir jemand weiterhelfen oder hat jemand Erfahrungen mit DPSIs?
Gruß Peter
hm, ein paar Fragen zum eingrenzen des Phänomens:
ist wirklich RUNSTATS auf alle drei Indices gelaufen ? ( im Systemkatalog nachschauen, nicht im Job )
Sind die Indices UNIQUE definiert ?
Ist einer der Indices explizit der CLUSTER-Index ?
Beinhalten alle drei Indices auch wirklich die selben Spalten ?
Gehen die Indices auch wirklich auf die selbe Tabelle ? ( Nicht lachen, wir haben uns schon mal zu tode gesucht weil der Index auf der falschen Tabelle angelegt war … ! )
Hat die Query nur ein ORDER BY oder auch WHERE-Bedingungen, wenn ja sind alle Bedingungen stage-I ? ( Matching columns beim Explain )
Hallo H. Mayer,
ich erhalte beim Anworten auf Ihren Beitrag immer einen internen Fehler 403 :'(.
Was mache ich falsch?
Gruß Peter
keine Ahnung.
Vielleicht versucht  "SELECT" zu schreiben ? Auf dieses Schlüsselwort bringt die Software manchmal einen Fehler. Da muss man dann immer irgendwo ein blanc ins Wort reinbasteln.  Â
Kann ich Ihnen die Infos aus den Sysibm.Tabellen etc.. irgendwie zukommen lassen?
Gruß Peter
Ps. Ãœbrigens, habe die DPSIs auf NPI umgestellt, dann klappt der zugriff. Db2 nimmt den zum ORDER BY passenden Index in macht keinen add. sort.
klar, Du kannst mir an die Adresse rub*mayeruli.de mailen ( statt * ein @ verwenden ).
Antwort ist unterwegs …
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
You must be logged in to reply to this topic.
