[ORACLE] Clustering Factor

[moo_kuh]

Hallo Leute,

ich versuche gerade den "Clustering Factor" von Index zu Table zu verstehen. Bisher habe ich leider nur englische Dokumente gefunden, die mir das ganze bisher aber noch nicht "verständlich" rübergebracht haben.

Habt ihr vielleicht ein paar deutsche Dokumente zu dem Thema oder vielleicht ein paar Links dazu?

Wäre super...

Danke

die moo_kuh

[Jasper]

ich versuche gerade den "Clustering Factor" von Index zu Table zu verstehen. Bisher habe ich leider nur englische Dokumente gefunden, die mir das ganze bisher aber noch nicht "verständlich" rübergebracht haben.

Habt ihr vielleicht ein paar deutsche Dokumente zu dem Thema oder vielleicht ein paar Links dazu?

links habe ich keine. ist aber eigentlich recht einfach:

ist einfach ein mass für die zuordnung der leaf-blöcke des index zu den datenblöcken, also wie geordnet die rows in den datenblöcken in bezug zu den leaf-blöcken sind. geht clustering factor in richtung anzahl datenblöcke, nimmt die ordnung zu, geht der factor in richtung anzahl rows, nimmt die ordnung ab.

praktisch gesehen bezeichnet clustering factor die anzahl logischer I/O-operationen, die notwendig sind, die gesamte tabelle per index access zu lesen (das ist der eigentliche zweck des wertes, nämlich kosten für den CBO zu berechnen).

angenommen, eine tabelle hat 1000 rows, 10 rows pro datenblock. die tabelle hat einen PK, streng monoton steigend. um jeden zeile der tabelle per pk zu lesen, müssen exakt 100 datenblöcke logisch gelesen werden, jeder block nur einmal => clustering factor = 100. falls die jeweils nächste zeile aber in einem anderen datenblock liegt (also zeile 1 in block 1, zeile 2 in block, zeile 3 in block, ..), müssen 1000 blöcke logisch gelesen werden, pro row ein block. ingesamt sind das zwar wiederum nur 100 blöcke, aber jeder block dafür 10 mal. in dem fall ist clustering factor = 1000.

clustering factor kann damit nur zwischen anzahl blöcke der tabelle und anzahl der rows der tabelle liegen, je näher am ersten wert, desto besser.

-j

[moo_kuh]

ist einfach ein mass für die zuordnung der leaf-blöcke des index zu den datenblöcken, also wie geordnet die rows in den datenblöcken in bezug zu den leaf-blöcken sind. geht clustering factor in richtung anzahl datenblöcke, nimmt die ordnung zu, geht der factor in richtung anzahl rows, nimmt die ordnung ab.

praktisch gesehen bezeichnet clustering factor die anzahl logischer I/O-operationen, die notwendig sind, die gesamte tabelle per index access zu lesen (das ist der eigentliche zweck des wertes, nämlich kosten für den CBO zu berechnen).

angenommen, eine tabelle hat 1000 rows, 10 rows pro datenblock. die tabelle hat einen PK, streng monoton steigend. um jeden zeile der tabelle per pk zu lesen, müssen exakt 100 datenblöcke logisch gelesen werden, jeder block nur einmal => clustering factor = 100. falls die jeweils nächste zeile aber in einem anderen datenblock liegt (also zeile 1 in block 1, zeile 2 in block, zeile 3 in block, ..), müssen 1000 blöcke logisch gelesen werden, pro row ein block. ingesamt sind das zwar wiederum nur 100 blöcke, aber jeder block dafür 10 mal. in dem fall ist clustering factor = 1000.

clustering factor kann damit nur zwischen anzahl blöcke der tabelle und anzahl der rows der tabelle liegen, je näher am ersten wert, desto besser.

Super Erklärung! :uli :nett:

Mit diesem Verständnis kann man dann auch folgendes Dokument gut nachvollziehen: DBAzine.com: Oracle Index Clustering Factor

Btw. es ist immer die Rede von "Leaf-Blocks"... werden so die "Datenblöcke" von Indezes bezeichnet? oder was kann ich unter "Leaf-Blocks" verstehen?

Vielen Dank. :byby:

[Jasper]

Btw. es ist immer die Rede von "Leaf-Blocks"... werden so die "Datenblöcke" von Indezes bezeichnet? oder was kann ich unter "Leaf-Blocks" verstehen?

ein index besteht aus einem root-block (wurzel), einer oder mehreren ebene(n) von branch-blöcken (äste) und eben den erwähnten leaf-blöcken (blätter). der root-block verweist nur auf branch-blöcke, diese wiederum auf die leafs. in den leafs stehen die indexwerte mit den zugehörigen rowids der datenblöcke. insofern kann man leaf-blocks als index-datenblöcke ansehen.

-j

[moo_kuh]

in den leafs stehen die indexwerte mit den zugehörigen rowids der datenblöcke. insofern kann man leaf-blocks als index-datenblöcke ansehen.

Dachte ich es mir doch :beagolisc

Ab welchen "Verhältnis" wird denn ein Fulltablescan einen Indexzugriff vorgezogen? Gibt es dafür irgendeine Faustregel bzw. einen prozentualen Wert des Clustering Factors auf die Rows?

[Jasper]

Ab welchen "Verhältnis" wird denn ein Fulltablescan einen Indexzugriff vorgezogen? Gibt es dafür irgendeine Faustregel bzw. einen prozentualen Wert des Clustering Factors auf die Rows?

da gibt es keine faustregel. der CBO berechnet die kosten der zugriffspfade und wählt den mit den wenigsten kosten aus. clustering factor ist nur ein faktor in der gleichung, systemstatistiken soielen eine rolle, ebenso wie index-selektivität, range, etc. pp.

-j

[moo_kuh]

der CBO berechnet die kosten der zugriffspfade und wählt den mit den wenigsten kosten aus. clustering factor ist nur ein faktor in der gleichung, systemstatistiken soielen eine rolle, ebenso wie index-selektivität, range, etc. pp.

Ja das ist schon klar aber als übertriebenes Beispiel "Clustering Factor = Anzahl rows in Tabelle", dann macht es ja keinen "Sinn" den Index zu verwenden, außer man möchte nur einen Wert der Unique ist oder nur einen kleinen "Range" selektieren.

Will man verschiedene Ranges haben... dann relativiert sich das ganze natürlich

Also danke nochma für deine gute Erklärung :nett: