Exadata Storage Indizes

Da ich noch nicht mit Exadata gearbeitet habe - und nicht damit experimentieren kann - fällt es mir schwer, mich ohne Praxisbezug mit dem Thema zu beschäftigen. Trotzdem hier ein paar Links auf Richard Footes Erklärung der Exadata Storage Indizes:

• Exadata Storage Indexes – Part I (Beginning To See The Light): "A Storage Index basically maintains summary information about database table data down on the Exadata storage servers. The information consists of the minimum value, the maximum value and a flag to denote whether any Nulls exist for up to 8 different columns within each 1M storage region of disk." (Was mich an die Rolle von DataIds im SSAS erinnert). Storage Indizes sind keine persistierten Objekte, sondern werden komplett im Memory gehalten. Sie dienen der Vor-Filterung von Daten auf Storage-Ebene: nur potentiell relevante Daten werden an die Datenbank geliefert.
• Exadata Storage Indexes Part II – Differences With Database Indexes (Space Dementia): mit einer umfangreichen Liste der Unterschiede zwischen Storage Indizes und "normalen" Indizes.
• Exadata Storage Indexes Part III – Similarities With Database Indexes (Same Old Scene): auch hier sagt der Titel schon ziemlich genau, was drin ist: eine Untersuchung der Gemeinsamkeiten von Storage Indizes und "normalen" Indizes.
• Exadata Storage Indexes Part IV – Fast Full Table Scans (Speed of Life): mit einem praktischen Beispiel.
• Exadata Storage Indexes Part V: Warming Up (Here Come The Warm Jets): erklärt, dass storage indexes ähnlich wie database indexes eine "warm up" Phase durchlaufen, bis ihre Cache-Effekte optimal wirksam werden.

Und noch eine Serie mit dem Vergleich von herkömmlichen und Storage-Indizes, deren Grundgedanke ist, dass Storage-Indizes nicht alles leisten können, was die traditionellen Indizes leisten:

• Storage Indexes vs Database Indexes Part I MIN/MAX (Maxwell’s Silver Hammer): die Abkürzung des INDEX FULL SCAN (MIN/MAX) steht mit Storage-Indizes nicht zur Verfügung.
• Storage Indexes vs Database Indexes Part II: Clustering Factor (Fast Track): zeigt, dass die Clusterung der Tabellen-Daten für Storage-Indizes sogar noch wichtiger ist als für traditionelle Indizes: ein Index mit schlechtem CF funktioniert bei entsprechender Selektivität immer noch sehr gut - für Storage-Indizes gilt das nicht unbedingt.