Verhalten von Index Splits

Wieder mal bin ich spät dran und exzerpiere relevante Artikel, kurz bevor sie aus dem 30-Tage-Korridor meines Blog Aggregators fallen. Und wieder mal ist es der zur Zeit ungeheuer produktive Jonathan Lewis, dessen Beiträge ich zusammenfasse. In den fraglichen Artikel beschäftigt sich der Herr Lewis mit dem Verhalten von "Index Splits", die auftreten, wenn ein neuer Index-Eintrag nicht mehr in den vorgesehenen Block der Index-Struktur passt:

• Index splits: erläutert den Unterschied zwischen dem 50:50-Split (den die Statistik "leaf node splits" erfasst) und dem 90:10-Split (erfasst unter "leaf node 90-10 splits"): letzterer tritt auf, wenn der neue Eintrag oberhalb aller bisher bekannten Werte liegt - und in diesem Fall wird nur der neue Eintrag in einen eigenen Block geschrieben (weshalb der Split eher als 100:0 zu bezeichnen wäre). Theoretisch könnte der zweite Fall (also der Sonderfall) effizienter sein als er erste - er ist es aber nicht, wie der im Artikel vorgestellte Test zeigt: die Erzeugung von undo und redo sind in beiden Fällen nahezu identisch. Die Ursache dafür ist, dass beide Fälle intern gleich behandelt werden: der alte Block wird gesichert, ein neuer Block ergänzt und dann werden beide Blocks gefüllt. Die Ursache dafür ist wahrscheinlich, dass die Entwickler bei Oracle den Code nicht komplizierter machen wollten als notwendig, obwohl hier vermutlich ein gewisses Optimierungspotential existieren würde.
• Index Splits – 2: liefert einen Test-Fall, der eine Erklärung für das im ersten Artikel beobachtete Verhalten liefert: die dabei durchgeführte Änderung am Index ändert das row directory des Blocks. Demnach ändert sich zwar nicht der Inhalt, aber die Sortierung des Blocks - und lässt das vollständige Schreiben beider Blocks sinnvoll erscheinen.
• Index Splits – 3: liefert ergänzendes Material.

Column Groups und NULL Werte

Bereits vor einigen Wochen hat Jonathan Lewis auf eine Problem hingewiesen, das sich bei Verwendung von Column Groups ergeben kann: wenn der Anteil der NULL-Werte in einer Spalte sehr groß ist, dann ist das für den Optimizer über die NUM_NULLS-Information erkennbar. Da Column Groups intern über eine virtuelle Spalte abgebildet werden, die die Informationen zu den in der Gruppe enthaltenen Spalten zusammenfasst, verliert die NUM_NULLS-Information auf dieser Ebene ihre Aussagekraft, da die Spaltenkombination insgesamt nicht mehr als NULL betrachtet werden kann. Dadurch ergeben sich im Beispiel extreme Fehleinschätzungen bei der Cardinality.

Join Cardinality und Histogramme

Jonathan Lewis hat zuletzt eine Artikelserie veröffentlicht, die sich damit beschäftigen, wie sich die Existenz unterschiedlicher Histogramm-Typen auf die Bestimmung der Join-Cardinality auswirkt. Seine Überlegungen basieren dabei auf einem umfangreicheren Artikel von Chinar Aliyev aus dem Jahr 2016. Da der Herr Lewis da natürlich sehr viele Details beleuchtet, verzichte ich weitgehend auf die Zusammenfassung und beschränke mich auf die Erfassung der Links, um die Hoffnung zu erhalten, sie bei Bedarf wiederfinden zu können:

• https://jonathanlewis.wordpress.com/2018/10/03/join-cardinality/: betrachtet das Verhalten mit frequency histograms.
• https://jonathanlewis.wordpress.com/2018/10/05/join-cardinality-2/: weitere Aussagen zu vergleichsweise übersichtlichen Fällen mit frequency histograms.
• https://jonathanlewis.wordpress.com/2018/10/09/join-cardinality-3/: betrachtet Fälle aus dem Bereich frequency/top-frequency histograms.
• https://jonathanlewis.wordpress.com/2018/10/25/join-cardinality-4/: beschäftigt sich mit der Kombination frequency/hybrid histograms.
• https://jonathanlewis.wordpress.com/2018/11/01/join-cardinality-5/: behandelt das Verhalten mit height-balanced histograms.

Wahrscheinlich wird die Artikelserie noch umfangreicher - und vielleicht erweitere ich dann auch die vorliegende Liste.

DAX Studio für Microsoft BI

Zwar sind die Zeiten, in denen ich mich mit Microsofts BI-Landschaft intensiver beschäftigt habe, schon lange vorbei, aber sollte ich jemals wieder damit anfangen, dann wäre das DAX Studio sicher ein Werkzeug, das zu berücksichtigen wäre. Vincent Rainardi verweist in seinem zugehörigen Artikel auch auf eine nützliche Liste weiterer BI Tools, die unter https://www.sqlbi.com/tools/ gepflegt wird. Ich erinnere mich noch gut daran, wie ich nach der Abwanderung von Mosha Pasumansky auf eine Weiterentwicklung des ungeheuer nützlichen MDX Studios hoffte, aber leider ist daraus offenbar nie etwas geworden.