Jonathan Lewis und vor ihm bereits Franck Pachot haben zuletzt darauf hingewiesen, dass in 11.2.0.4 eine Änderung der Berechnung der endpoint values für Histogramme von char und nchar (nicht aber varchar2 und nvarchar2) Spalten eingeführt wurde, die eine Neuerzeugung entsprechender Histogramme nach einem Upgrade von einer früheren Version erforderlich macht, da sich sonst recht bizarre costing-Effekte ergeben.
In Francks Test existiert eine Spalte mit den beiden Werten 'Y' und 'N', die massive ungleichmäßig verteilt sind (100K zu 1K). Zu erwarten wäre, dass diese Verteilung durch ein Frequency-Histogramm exakt abgebildet wird, was in 11.2.0.3 auch der Fall ist. Nach dem Upgrade auf 11.2.0.4 (ohne Neuerzugung des Histogramms) wird die Cardinality für beide Werte aber mit der Formel für nicht im frequency Histogramm vorliegende Werte berechnet: also "Häufigkeit des seltensten Werts im Histogramm" geteilt durch zwei (im Beispiel also 500). Demnach scheinen nach dem Upgrade also alle Werte unbekannt zu sein. Verantwortlich dafür ist die interne Ablage der endpoint values im Histogramm: bis 11.2.0.3 erfolgte das Padding der Werte mit spaces (ASCII 0x20), in 11.2.0.4 erfolgt es mit Nullen (ASCII 0x00) - was dem Verhalten entspricht das scon ihn älteren Releases für varchar2 verwendet wurde. Insofern ist die Neuerzeugung der Histogramme unvermeidbar.
Jonathan Lewis erwähnt in seinem Artikel auch noch mal die wichtige Tatsache, dass die Erzeugung vieler Histogrammtypen in 12c mit einem "approximate NDV" Verfahren erfolgt: die 5500 row samples, die in der Vergangenheit häufig zu Problemen geführt hatten, sind demnach in vielen Fällen nicht mehr im Spiel.
Keine Kommentare:
Kommentar veröffentlichen