Richard Foote über IOTs

Nachdem Martin Widlake im vergangenen Jahr eine interessante Serie über Index Organized Tables veröffentlichte, hat jetzt auch Richard Foote begonnen, das Thema genauer zu erläutern. Hier eine Liste der bisher veröffentlichten Artikel:

• Index Organized Tables – An Introduction Of Sorts (Pyramid Song): zeigt - unter anderem anhand von Index Block Dumps - inwiefern eine IOT einem entsprechenden Index überlegen ist (soll heißen: kompakter ist), der alle für eine Query relevanten Spalten enthält (also einem "fat" oder "covering" index): der zentrale Unterschied liegt darin, dass in der IOT keine rowid gespeichert werden muss, da der Verweis auf das zugehörige Tabellensegment entfallen kann (da es kein solches Segment gibt).
• Index Organized Tables – Overflow Segment (Shadow Man): erklärt den Sinn des Overflow-Segments, in das Spalten abgeschoben werden können, auf die eher selten zugegriffen wird. Solche Spalten würden die Index-Struktur unnötig aufblähen. Stattdessen kann man sie ins Overflow-Segment auslagern, das mehr oder minder einer Heap-Tabelle entspricht, aber nicht alle Spalten enthält (sondern nur die nutzlosen). Der erforderliche Pointer in der Index-Struktur nennt sich im Dump "consisting of a 6 byte relative block address and row directory number". Während der Zugriff auf die Spalten im Index-Segment dadurch beschleunigt wird, erhöhen sich (natürlich) die Kosten für den Zugriff auf die ausgelagerten Spalten gegenüber einer entsprechenden IOT ohne Overflow-Segment.
• Index Organized Tables – Overflow Segment Part II (The Loneliest Guy): hier erklärt Herr Foote, dass er  (wie vermutlich die meisten Leute) PK-Spalten gerne an den Anfang der Spaltenliste einer Heap-Tabelle stellt, obwohl es durchaus auch Gründe dafür gäbe, sie nicht dort zu positionieren (da man ohnehin häufig über den PK zugreift und dann erst einmal über die bereits bekannten PK-Infos drüberlesen muss). Für IOTs ist die Platzierung der PK-Spalten an führende Stelle entscheidend. Tatsächlich ignoriert Oracle jede abweichende Definition und ordnet die PK-Spalten intern an den Anfang der Tabelle (was in der SEGMENT_COLUMN_ID in DBA_TAB_COLS abzulesen ist). Eine solche Umordnung kann dann unerfreuliche Wirkungen darauf haben, welche Spalten im Overflow-Segment landen, was man vor kurzem auch schon mal bei Jonathan Lewis lesen konnte.
• Index Organized Tables – PCTTHRESHOLD (The Wedding Song): liefert (wie der Titel bereits andeutet) eine nähere Erläuterung zur PCTTHRESHOLD-Angabe, mit deren Hilfe sich exakter steuern lässt, welche Attribute im IOT-Segment und welche im Overflow-Segment landen: "with a PCTTHRESHOLD of (say) 5, the non-PK columns up to the INCLUDING clause will be included within the IOT but only if the resultant row size is less than 5% of the blocksize."
• Indexed Organized Tables – An Introduction to IOT Secondary Indexes (A Second Face): erläutert die Definition von sekundären Indizes zu einer IOT: da ein solcher Index nicht die rowid des Tabellensatzes enthalten kann (da die Sätze in der IOT ja ihren physikalischen Speicherort ändern können), besteht er aus den indizierten Spaltenwerten, dem PK der IOT und einer Angabe des initialen physikalischen Speicherortes des Satzes in der IOT: falls der Satz noch dort steht, wo er ursprünglich angelegt wurde, hat man Glück. Wenn nicht, dann wird ein zusätzlicher Scan des PK-Index erforderlich. Relevant ist jedenfalls, dass der sekundäre Index nicht aktualisiert wird, wenn sich die Position von Sätzen in der IOT verändert (was allerdings auch ein ziemlich teures Verfahren wäre).
• IOT Secondary Indexes: Primary Key Considerations (Beauty And The Beast): zeigt, dass die sekundären Indizes einer IOT größer sind als Indizes von Heap-Tabellen, da sie den PK der IOT enthalten müssen (und somit auch redundante Speicherung hervorrufen, die die IOT ja eigentlich vermeiden will). Für Fälle, in denen ein sekundärer Index eine Teilmenge der Spalten des PK enthält, kann der Overhead entfallen (was die Spalte iot_redundant_pkey_elim in dba_indexes anzeigt).
• IOT Secondary Indexes – The Logical ROWID Guess Component Part I (Lucky): erläutert die Rolle des rowid "guesses" mit dem ein sekundärer Index auf die ursprüngliche rowid des zugehörigen IOT-Satzes verweist: ursprünglich treffen dieses Vermutungen alle zu, aber wenn neue Sätze in die Tabelle eingefügt werden, ergeben sich Block-Splits und die Angaben werden unzutreffend. In diesem Fall ist ein Neuaufbau des sekundären Index mit der Option "UPDATE BLOCK REFERENCES" nützlich.
• IOT Secondary Indexes – The Logical ROWID Guess Component Part II (Move On): weist darauf hin, dass die Invalidierung der "rowid guesses" nur bei 50:50-Block-Spilts erfolgt. Im Fall eines Hinzufügens von Einträgen am Endes des Index, also z.B. über einen monoton steigenden PK-Wert, und 90:10-Splits (die ja eigentlich 100:0-Splits sind, da ein neuer (nahezu) leerer Block in die Index-Struktur eigefügt wird) ergibt sich keine physikalische Verschiebung in der IOT. Außerdem erklärt der Herr Foote, dass ein MOVE für eine IOT als ONLINE-Operation erfolgen kann und sekundäre Indizes dabei VALID bleiben - allerdings leidet ihre Effizienz, da alle  "rowid guesses" jetzt falsch sind.

Da es kaum jemanden gibt, der komplexe Sachverhalte in Oracle so klar darstellt wie der Herr Foote - und wahrscheinlich so gut wie niemanden, der sich mit Indizes besser auskennt -, lohnt es sich auf jeden Fall, die Artikel im Original zu lesen.

Christian Antognini vertritt in seinem Performance Tuning Buch übrigens die Ansicht, dass die Verwendung von Overflow-Segmenten in IOTs weitgehend sinnfrei ist, da man damit die Vorzüge des Tabellentyps (zumindest zum Teil) wieder verliere. Ich vermute, das ist mal wieder ein Fall von "It depends".

Aus Gründen der Vollständigkeit auch noch der Link auf Julian Dykes ausführliche Präsentation zum gleichen Thema.