Neues vom Clustering Factor

Richard Foote (der “Index-Guru”) hat auf seinem Blog in mittlerweile drei Artikeln Neues zur Berechnung des Clustering Factors (CF) verkündet:

  1. Erster Artikel: Ein Patch für Oracle 11.2 führt eine neue Option “TABLE_CACHED_BLOCKS” für die Berechnung mit DBMS_STATS ein. Dieser kann von 0-255 oder auf AUTO gesetzt werden und sorgt für eine Berücksichtigung von Caching-Effekten, die bislang nicht in die Berechnung des Clustering Factors eingegangen sind. Dadurch können unberechtigt zu hohe CFs deutlich reduziert werden, wenn die indizierten Rows innerhalb der nächsten n Blöcke der Zieltabelle liegen. n wird bei AUTO auf 1% der Tabellengröße in Blöcken gesetzt.
  2. Im zweiten Artikel geht Richard Foote auf Bedenken aus den Kommentaren zu Teil 1 ein, speziell die Bedenken, daß der CF nunmehr zu niedrig werden könnte. Ein ausführlicher Testfall mit einer großen Tabelle zeigt, daß hier selbst das Maximum von TABLE_CACHED_BLOCKS=255 keine gravierende Änderung zur Folge hat.
  3. Im dritten Artikel wird als Gegenbeispiel die maximale Einstellung auf eine kleine Tabelle angewendet und dargestellt, dass in solchen Fällen ein hoher Wert für TABLE_CACHED_BLOCKS, der nahe an der Anzahl an Datenblöcken der Tabelle liegt, kontraproduktiv sein kann.

Eine “Best Practice” wird sich wohl erst noch herauskristallisieren müssen. Meine persönliche Vermutung anhand der bislang diskutierten Testfälle geht dahin:

  • TABLE_CACHED_BLOCKS = AUTO als DB-weite Einstellung
  • Wo es dann immer noch Probleme mit einem zu hohen CF gibt, Objekt-spezifische Einstellung dieser Option.

Was ist der Clustering Factor?

Da es irgendwie kaum deutschsprachige Dokumente zu diesem Begriff gibt, möchte ich ihn hier kurz (vereinfacht!) umreißen:

Der Clustering Factor gibt an, wie viele I/O-Zugriffe notwendig sind, um eine indizierte Tabelle vollständig über Index-Zugriffe zu lesen.

In einem Index-Datenblock finden sich i.d.R. mehrere, aufeinander folgende Index-Einträge. Im Idealfall sind auch in den Tabellen-Datenblöcken die dazu passenden Zeilen in einem Datenblock, so dass mit nur zwei Lesezugriffen (ein Index-Block, ein Tabellen-Block) mehrere Index-Zugriffe erledigt werden können.
Im schlechtesten Fall sind die Daten in der Tabelle so verteilt, dass für jeden Index-Eintrag jeweils ein neuer Tabellen-Datenblock gelesen werden muss. Der CF reflektiert dieses Verhältnis und wird vom SQL-Optimizer zur Kostenberechnung von Index-Operationen herangezogen.

Konkurrierende, also auch parallelisierte Beladungen von Tabellen in ASSM-Tablespaces (Standard seit Oracle 10g) hatten bislang häufig sehr hohe CFs zur Folge, da aufeinander folgende Daten in verschiedene (aber meist nahe beieinander liegende) Datenblöcke eingefügt werden.

Weblinks

About these ads

2 Gedanken zu „Neues vom Clustering Factor

  1. Martin Preiss

    Hallo Uwe,

    hier vielleicht noch zwei Ergänzungen für die Link-Sammlung:
    - Kapitel 5 von Cost Based Oracle, das laut Jonathan Lewis – http://jonathanlewis.wordpress.com/2011/05/19/clustering_factor/ – frei downloadbar ist.
    - Randolf Geists Artikel http://oracle-randolf.blogspot.de/2010/01/clusteringfactor-what-if-analysis.html, der ein paar Hilfsmittel für den Fall liefert, dass die CF-Berechnung wenig taugte und man über manuelle Korrekturen nachdenkt (was mit der TABLE_CACHED_BLOCKS-Option dann wohl erledigt ist).

    Gruß

    Martin

    Gefällt mir

    Antwort

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ photo

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s