Database Reference
In-Depth Information
P.: „
Was war so schlecht an den Height-Balanced-Histogrammen, dass Oracle diese Hyb-
rid-Histogramme eingeführt hat?
“
L.: „
Wie Du Dich sicherlich erinnerst, enthält jeder Bucket bei den Height-Balanced-His-
togrammen ungefähr dieselbe Anzahl der Einträge. Es kann passieren, dass ein Spaltenwert
fast 2 Buckets belegt, aber wegen der ungünstigen Datenverteilung in den Buckets nur ein-
mal als Endpunkt eines Bucket sichtbar ist. Dies führt zu einer Ungenauigkeit bei der Kar-
dinalitätsschätzung. Um solche Situationen zu vermeiden, wurden die Hybrid-Histogramme
eingeführt, bei denen Oracle die Daten günstiger für die Kardinalitätsschätzung zwischen
den Buckets verteilt (selbstverständlich findet dabei keine physikalische Datenverteilung statt,
sondern die Buckets werden anders ausgelegt). Für die Endpunkte der Buckets wird die An-
zahl der Datensätze im jeweiligen Bucket gespeichert. Auch diese Art der Histogramme kön-
nen berechnet werden, wenn das Argument ESTIMATE_PERCENT den Wert AUTO_SAM-
PLE_SIZE annimmt
.“
P.: „
Heißt das, dass die Height-Balanced-Histogramme nur erzeugt werden können, wenn
der Wert von ESTIMATE_PERCENT ungleich AUTO_SAMPLE_SIZE ist?
“
L.: „
Ja, das ist so. Bei dem Wert AUTO_SAMPLE_SIZE des Arguments ESTIMATE_PER-
CENT können die folgenden 3 Arten der Histogramme erzeugt werden
:
•
Frequency,
•
Top-Frequency,
•
Hybrid
.
Anderenfalls lediglich die folgenden 2
:
•
Frequency,
•
Height Balanced
.“
P.: „
Ich habe noch eine Frage. Bei den Height-Balanced-Histogrammen können die Endpunk-
te der Buckets nicht repräsentativ sein. Ein Bucket kann beispielsweise 999 gleiche Spalten-
werte enthalten, sein Endpunkt kann aber ein anderer Spaltenwert sein, der lediglich einmal
in der Tabelle vorkommt. Werden die Daten bei den Hybrid-Histogrammen auch in diesem
Fall umverteilt?
“
L.: „
Nein, Peter, so ein Bucket bleibt unverändert. Bei Oracle 12c ist es möglich, die ses-
sion-spezifischen Optimizer-Statistiken für die globalen temporären Tabellen zu erzeugen.
Optimizer-Statistiken für temporäre Tabellen haben wir kurz im Abschn. 15.2 angesprochen.
Vor Oracle 12c war es nicht möglich, die Optimizer-Statistiken für die globalen temporären
Tabellen mit der Klausel „ON COMMIT DELETE ROWS“ zu erstellen, weil die Prozedur
DBMS_STATS.GATHER_TABLE_STATS das Kommando COMMIT ausfuhr. In 12c ist das
möglich
.“
P.: „
Das ist interessant. Wie macht man das?
“
L.: „
Dafür gibt es die Präferenz GLOBAL_TEMP_TABLE_STATS, die 2 Werte annehmen
kann: SHARED und SESSION. Bei dem Wert SESSION gelten die Optimizer-Statistiken nur
