Zweites CBO Webinar von Randolf Geist

Vor einigen Tagen hat Randolf Geist wieder ein Webinar bei AllThingsOracle gehalten, diesmal zum Thema Oracle Cost-Based Optimizer Advanced. Hier eine stichpunktartige Zusammenfassung diverser interessanter Punkte (ohne Anspruch auf Vollständigkeit und mit unterschiedlich intensiver Beschreibung und Kommentierung).

• Entscheidende Faktoren für die Effizienz von Zugriffsverfahren (wurden bereits im ersten Webinar erläutert):
• Datenmengen
• Clustering der Daten
• Caching der Daten
• Clustering Factor
• Störfaktoren, die die Aussagekraft des Clustering Factor beeinträchtigen
• bei MSSM: multiple freelists, freelist groups; ASSM (der default in aktuellen Releases): diese Optionen dienen zur Vermeidung von contention (da gleichzeitig mehrere Blocks für INSERTs angesteuert werden), aber ihre Verwendung führt auch dazu, dass der CF die tatsächliche Clusterung der Daten nicht mehr adäquat abbildet: auch für stark geclusterte Daten kann der CF sehr hoch werden, da seine Bestimmung nur den Wechsel von Blockzuordnungen berücksichtigt (eine Funktion, die das Verfahren nachbildet, findet man in Christian Antogninis Troubleshooting Oracle Performance, S. 135)
• Partitioning (sollte allerdings kein Problem sein bei lokalen Indizes)
• Shrink-Operationen
• Scripts zur Beantwortung der Frage, ob der CF die tatsächliche Clusterung der Daten sinnvoll repräsentiert, findet man in Randolf Geists Artikel CLUSTERING_FACTOR What-If Analysis.
• Statistiken, Histogramme
• die method_opt FOR ALL INDEX COLUMNS SIZE ... ist in aller Regel Unfug, da sie bewirkt, dass nur für die indizierten Spalten basic column statistics (und histograms) angelegt werden; für alle übrigen Spalten verwendet der CBO dann default-Werte.
• Die Anlage von Histogrammen (=> size > 1) erfordert ein zusätzliches Lesen der Tabelle für jede betroffene Spalte (weshalb Oracle in diesem Fall ein extremes Sampling verwendet - 5500 rows, was Randolf Geist unter anderem auch hier erläutert hat -; und das hat dann natürlich Auswirkungen auf die Qualität der Histogramme; unter Umständen ergibt sich ein nicht deterministisches Verhalten, wenn das Sample bei wiederholtem Aufruf seltene Extremfälle erfasst oder übersieht)
• height balanced histograms basieren immer auf sampling (und können folglich relevante Informationen verpassen)
• die method_opt size auto sorgt dafür, dass frequency histograms  für alle Spalten mit weniger als 255 distinkten Werten angelegt werden, die in WHERE-Bedingungen erscheinen (was nicht unbedingt gewünscht ist)
• gefährlich ist die (für aktuelle Releases als Standard fungierende) Annahme des cbo, dass ein nicht im frequency histogram vorliegender Wert die halbe Wahrscheinlichkeit des seltensten im histogram vorliegenden Werts besitzt: wenn im histogram ausschließlich extrem populäre Werte vorliegen, kann dieser halbierte Wert sehr hoch sein. Einen Test zu diesem Problem hatte ich gelegentlich hier durchgeführt. Eine mögliche Lösung für solche Fälle stellt dynamic sampling dar. Über fix_control kann man auch das in diesem Fall sinnvollere ältere Verhalten des cbo wieder aktivieren, das für nicht im frequency histogram erscheinende Werte eine sehr niedrige Wahrscheinlichkeit annahm.
• sehr große Attribut-Werte stellen die Histogramme vor Probleme, weil in ihnen nur eine beschränkte Genauigkeit zur Verfügung steht. Weitere Erläuterungen zu diesem Thema findet man (natürlich) in Jonathan Lewis' cbo-Buch und in Randolf Geists Blog.
• height balanced histograms können ebenfalls zu Instabilität führen, da die Bestimmung eines Werts als popular (=> umfasst mehr als einen Bucket) bei wiederholter Statistikerfassung oder geringfügigen Datenänderungen unterschiedliche Ergebnisse bringen kann.
• nützlich sind height balanced histograms zur Erkennung großer Lücken in ranges (und damit auch zur Bestimmung der cardinality von range-Bedingungen).
• Datentypen
• int statt date nimmt dem CBO die Möglichkeit, die spezielle Semantik von Datumswerten zu berücksichtigen
• implizite Typkonvertierungen können Probleme hervorrufen