Oracle 12c - Das umfassende Handbuch

26.2

Indexe

613

26.2 Indexe

Mit der Verwendung von partitionierten Tabellen stellt sich die Frage nach partiti-

onierten Indexen. In Oracle 12c gibt es zwei Arten:

쐽 Local Partitioned Index

쐽 Global Partitioned Index

Ein Local Partitioned Index besteht aus Schlüsseln, die ausschließlich auf Daten-

sätze der zugehörigen Partition verweisen. Oracle erstellt für jede Partition der

Tabelle einen Local Partitioned Index. Wird eine Partition der Tabelle gelöscht,

geteilt, zusammengefasst oder hinzugefügt, dann werden die zugehörigen Index-

partitionen automatisch gepflegt und der neuen Partitionierungsstruktur ange-

passt. Ein Local Partitioned Index bietet folgende Vorteile:

쐽 Wird bei Wartungsarbeiten die Struktur der Partitionierung verändert (SPLIT,

ADD, MERGE), dann müssen nur die lokalen Indexe neu gebildet werden, die

zu den geänderten Tabellenpartitionen gehören.

쐽 Die Zeit für Wartungsarbeiten wird deutlich reduziert, da nicht der gesamte In-

dex neu erstellt oder aktualisiert werden muss.

쐽 Durch die eindeutige Zuordnung zu einer Tabellenpartition kann der Optimi-

zer einen effizienteren EXPLAIN-Plan erstellen.

쐽 Recovery-Zeiten für Partitionen werden wesentlich verkürzt.

SQL> CREATE TABLE account_facts_3 (

2 customer_key NUMBER,

3 time_key NUMBER,

4 status_key NUMBER,

5 product_key NUMBER,

6 branch_key NUMBER,

7 balance NUMBER(8,2),

8 transactions NUMBER(5),

9 account_number NUMBER(10))

10 PARTITION BY RANGE (time_key)

11 SUBPARTITION BY LIST(product_key)

12 (PARTITION p_2002 VALUES LESS THAN (9)

13 (SUBPARTITION p_prod11 VALUES (1,4),

14 SUBPARTITION p_prod12 VALUES (2,3,5)),

15 PARTITION p_2003 VALUES LESS THAN (13)

16 (SUBPARTITION p_prod21 VALUES (1,4),

17 SUBPARTITION p_prod22 VALUES (2,3,5))

18 );

Tabelle wurde angelegt.

Listing 26.11: Eine Tabelle mit Composite Partitioning anlegen

Kapitel 26

Administration von Data Warehouse-Datenbanken

614

In Listing 26.12 finden Sie die Syntax für das Erstellen lokaler Indexe an der Fact

Table account_facts. Durch Angabe des Schlüsselworts PARALLEL wird die Inde-

xerstellung parallelisiert. Das führt zu einer Beschleunigung des Erstellungspro-

zesses.

Ein Global Partitioned Index ist schwerer zu verwalten, da er über die gesamte

Tabelle gebildet wird. Kommt es zu Veränderungen in der Struktur der Tabellen-

partitionen (MOVE, SPLIT, DROP, ADD), dann muss der gesamte Index neu

erstellt bzw. aktualisiert werden. Dieser Indextyp ist für große partitionierte Tabel-

len nicht zu empfehlen.

Bitmap-Indexe kommen in Data Warehouse-Datenbanken recht häufig zum Ein-

satz. Bitmap-Indexe sind besser als B-Tree-Indexe, wenn die folgenden Vorausset-

zungen erfüllt sind:

쐽 Die Anzahl der unterschiedlichen Werte im Index ist gering gegenüber der An-

zahl der Indexeinträge.

쐽 Der Index muss nicht permanent aktualisiert werden, er wird überwiegend von

Abfragen benutzt, nicht im Zusammenhang mit DML-Anweisungen.

Beide Voraussetzungen sind im Data Warehouse häufig erfüllt. So wird der Index

in der Regel nur beim Ladevorgang erstellt oder aktualisiert und für den Rest der

Zeit von DSS-Abfragen verwendet. Gerade in einem Star-Schema weisen viele

Indexeinträge nur eine geringe Anzahl von unterschiedlichen Werten auf. Das

SQL> CREATE INDEX i_customer_key

2 ON account_facts(customer_key)

3 TABLESPACE dwhind

4 PARALLEL (DEGREE DEFAULT)

5 LOCAL

6 (PARTITION "P_2002" ,

7 PARTITION "P_2003" ,

8 PARTITION "P_2004" ,

9 PARTITION "P_OTHER" );

Index wurde angelegt.

Listing 26.12: Einen Local Partitioned Index erstellen

Tipp

Ein weiterer Vorteil eines Local Partitioned Index ist die Möglichkeit, die einzel-

nen Partitionen in unterschiedlichen Tablespaces unterzubringen und damit

eine bessere Verteilung auf unterschiedliche Festplatten oder Disk-Gruppen zu

erreichen. Werden zusätzlich die Prozesse noch parallelisiert, dann kann z.B. bei

einem Index Scan eine sehr gute Performance auch über sehr große Tabellen

erreicht werden.

26.2

Indexe

615

trifft auf Indexschlüssel zu, die durch die Fremdschlüssel in den Fact Tables gebil-

det werden. Ein klassisches Beispiel ist ein Index über die Spalte »Geschlecht«, die

nur zwei Werte aufweist. Oracle speichert pro Indexeintrag ein Bitmap, so wie im

folgenden Beispiel:

Jedes Bitmap besitzt eine Verbindung zur ROWID. Wie beim B-Tree-Index werden

die Daten über die ROWID gelesen.

In unserem Beispiel-Data Warehouse ist der status_key ein sehr guter Kandidat für

einen Bitmap-Index. Er kann nur sechs unterschiedliche Werte aufweisen. Die

Anweisung in Listing 26.13 erstellt einen Bitmap-Index.

Die folgenden Punkte fassen die Vorteile von Bitmap-Indexen zusammen:

쐽 Die Laufzeiten für SQL-Abfragen werden reduziert.

쐽 Ein Bitmap-Index benötigt weniger Speicher auf der Festplatte und im Haupt-

speicher.

쐽 Die Erstellung eines Bitmap-Index ist schneller und verbraucht weniger Res-

sourcen. Damit wird der Ladeprozess deutlich entlastet.

Sei Oracle9i können sogenannte Bitmap Join-Indexe erstellt werden. Dabei handelt

es sich um einen Bitmap-Index für mehr als eine Tabelle. Die ROWIDs für alle

beteiligten Tabellen werden im Index gespeichert. Bitmap Join-Indexe sind in Data

männlich 0 1 1 0 1 0 1 1 1 1 0 0 0 1

weiblich 1 0 0 1 0 1 0 0 0 0 1 1 1 0

SQL> CREATE BITMAP INDEX i_status_key

2 ON account_facts (status_key)

3 TABLESPACE dwhind

4 PARALLEL (DEGREE DEFAULT)

5 LOCAL

6 (PARTITION "P_2002",

7 PARTITION "P_2003",

8 PARTITION "P_2004",

9 PARTITION "P_OTHER");

Index wurde angelegt.

Listing 26.13: Einen Bitmap-Index erstellen

Hinweis

Ein Bitmap-Index ist immer lokal. Sie können keinen globalen Bitmap-Index für

eine partitionierte Tabelle erstellen. Der Erstellungsprozess für einen Bitmap-

Index ist naturgemäß wesentlich kürzer als für einen B-Tree-Index, da keine auf-

wendigen Sortiervorgänge erforderlich sind.