Ausarbeitung Datenbanken II

Christian Gasch 05IN Ausarbeitung Datenbanken II Thema: Physische Datenbankdefinition in Oracle

Inhaltsverzeichnis: 1. Cluster 2. Index-organisierte Tabellen 3. Partitionierung 3.1 Range-Partitionierung 3.2 Hash-Partitionierung 3.3 Composite-Partitionierung 3.4 List-Partitionierung 3.5 Partitionierte Indizes 3.6 Existierende Tabellen partitionieren 4. Die Storage-Klausel 5. Unterstützte Indexstrukturen 5.1 B*Indizes 5.2 Bitmap-Indizes 5.3 Bitmap-Join-Indizes 5.4 Reverse-Key-Indizes 5.5 Funktionale Indizes

1. Cluster: Cluster sind Gruppen von einer, oder mehrerer Tabellen, die physisch zusammen gespeichert werden, weil sie gemeinsame Spalten teilen und oft zusammen benutzt werden. Das verbessert die Platten-Zugriffszeiten. Die verbundenen Spalten der Tabellen in einem Cluster werden Cluster-Schlüssel genannt. Der Cluster-Schlüssel ist indiziert, so, dass die Zeilen des Clusters mit einem minimalen I/O-Aufwand abgefragt werden können. Es spielt keine Rolle, wie viele Tabellen im Cluster den Cluster-Schlüsselwert enthalten. Er wird immer nur einmalig pro Cluster und Cluster-Index gespeichert. Deshalb wird weniger Speicherplatz benötigt. Ungeclusterte Tabellenzeilen: Geclusterte Tabellenzeilen: Die Grafiken sind eine Abwandlung der Beispielgrafiken von http://www.dba-oracle.com/oracle_tip_hash_index_cluster_table.htm

Es gibt zwei verschiedene Arten von Clustern: Hash-Cluster Index-Cluster In Hash-Clustern werden die Daten in einem einzelnen Block basierend auf Hash-Key und Hash- Funktion zusammen gespeichert. In Index-Clustern wiederum werden die Daten in einem Block basierend auf einem gemeinsamen Spalten-Index gespeichert. SQL-Beispiel für das Erstellen eines Hash-Clusters: CREATE CLUSTER scott.off_clu (country VARCHAR2(2),postcode VARCHAR2(8)) SIZE 500 HASHKEYS 1000 TABLESPACE DATA01 STORAGE(INITIAL 5M NEXT 5M PCTINCREASE 0); HASHKEYS 1000 = wie viele Hash-Gruppen sollen erstellt werden CREATE TABLE scott.office ( office_cd NUMBER(3), cost_ctr NUMBER(3), country VARCHAR2(2), postcode VARCHAR2(8) ) CLUSTER scott.off_clu(country,postcode); SQL-Beispiel für das Erstellen eines Index-Clusters: CREATE CLUSTER scott.ord_clu (ord_no NUMBER(3)) INDEX SIZE 200 TABLESPACE DATA01 STORAGE(INITIAL 5M NEXT 5M PCTINCREASE 0); CREATE INDEX scott.ord_clu_idx ON CLUSTER scott.ord_clu TABLESPACE INDX01 STORAGE(INITIAL 1M NEXT 1M PCTINCREASE 0); CREATE TABLE scott.ord (ord_no NUMBER(3) CONSTRAINT ord_pk PRIMARY KEY, ord_dt DATE, cust_cd VARCHAR2(3)) CLUSTER scott.ord_clu(ord_no); CREATE TABLE scott.item (ord_no NUMBER(3) CONSTRAINT item_ord_fk REFERENCES scott.ord, prod VARCHAR2(5), qty NUMBER(3), CONSTRAINT item_pk PRIMARY KEY(ord_no,prod)) CLUSTER scott.ord_clu(ord_no);

2. Index-organisierte Tabellen: Index-organisierte Tabellen haben ihre eigene Struktur- und Indexmodelle die sich von denen konventioneller Tabellen unterscheiden. In einer konventionellen Tabelle ist die physische Adresse, oder ROWID stabil und ändert sich nicht, solange die ROW existiert Index-organisierte Tabellen sind nicht an einen physischen Ort gebunden. Sie speichern ihre Daten sortiert nach dem Primärschlüssel in Form eines B*-Indexbaumes. Im Gegensatz zu normalen B*- Indexbäumen enthalten die B*-Bäume von Index-organisieren Tabellen jedoch auch Spalten, die nicht zu dem Tabellenschlüssel gehören. Ausserdem ist es bei Index-organisierten Tabellen möglich, bestimmte Spalten, in einem separaten Segment zu speichern. Mit Hilfe dieser Überlaufbereiche können die Datensätze in dem Blättern des Baumes kurz gehalten und dadurch der Baum kompakter aufgebaut werden. Darüber hinaus kann man zusätzliche Sekundärindizes für Index-organisierten Tabellen definieren. Damit werden Zugriffe, die nicht über die Primärschlüsselspalten erfolgen, optimiert. Diese Sekundärindizes enthalten logische Satzadressen für den Zugriff auf den Index- Baum. In einer Index-organisierten Tabelle können sich die Row hin und her bewegen, um die sortierte Reihenfolge zu erhalten. An einen anderen Platz, oder sogar in einen anderen Block. Da Einträge in Index-Bäumen durch INSERT- und UPDATE-Operationen und damit verbundenen Splitoperationen auf den Index-Blättern möglicherweise verschoben werden, können Zugriffe über logische Satzadressen fehlschlagen. In diesen Fällen wird eine zusätzliche Scan-Operation über den Primärschlüssel notwendig, um den betreffenden Datensatz zu lesen. Wie normale Indizes, so lassen sich auch Index-organisierte Tabellen zusätzlich komprimieren. Bei der Komprimierung werden die Spalten des Primärschlüssels in Präfix- und Sufixbereiche aufgeteilt und die wiederholt auftretenden Werte der Präfixe innerhalb eines Blockes unterdrückt. Index-organisierte Tabellen sind sehr gut geeignet für die Umsetzung aller Entitäten, die einen großen Teil ihres Imformationsgehaltes aus den Schlüsselspalten beziehen. Dabei gibt es eine große Ersparnis an Speicherplatz, da keine seperaten Segemente für Tabellen und Indizes angelegt werden müssen. Beispiel für die Implementierung einer Tabelle, bei der die Spalten Rabatt und kommentar und rabattliste, sofern der Schwellwert von 10% pro Block und Datensatz überschritten wird, in einen Überlaufbereich im Tablespace ts_over ausgelagert werden. CREATE TABLE artikelpreis (artnr VARCHAR(20), von_datum DATE, bis_datum DATE, preis_euro number(6,2), kommentar VARCHAR2(2000), rabattliste mumber(4), CONSTRAINT pk_artikelpreis PRIMARY KEY(artnr, von_datum, bis_datum) ) ORGANIZATION INDEX TABLESPACE ts_data PCTTHRESHOLD 10 INCLUDE preis_euro OVERFLOW TABLESPACE ts_over;

Im folgenden Beispiel wird die Tabelle aus dem letzen Beispiel mit einer Komprimierung auf der ersten Schlüsselspalte angelegt. Dementsprechend werden redundante Artikelnummern innerhalb eines Index-Blattes unterdrückt. CREATE TABLE artikelpreis (artnr VARCHAR(20), von_datum DATE, bis_datum DATE, preis_euro number(6,2), kommentar VARCHAR2(2000), rabattliste mumber(4), CONSTRAINT pk_artikelpreis PRIMARY KEY(artnr, von_datum, bis_datum) ) ORGANIZATION INDEX COMPRESS 1 TABLESPACE ts_data PCTTHRESHOLD 10 INCLUDE preis_euro OVERFLOW TABLESPACE ts_over; * Die beiden Beispiele sind dem Buch Oracle9i für den DBA von Uwe Herrmann entnommen. 3. Partitionierung 3.1 Range-Partitionierung Bei der Range-Partitionierung werden die Daten durch einen bestimmten Wertebereich in einer, oder mehreren Spalten partitioniert. Dabei werden die entsprechenden Grenzwerte über Value- Klauseln vorgegeben. Dadurch ist immer ersichtlich, in welcher Partitionierung welche Daten gespeichert sind. Des Weiteren kann diese Partitionierung benutzt werden, wenn zum Beispiel nach Monaten, oder Jahren partitioniert wird und ein bestimmter Monat gelöscht werden soll, kann einfach die Partition gelöscht werden. Das selbe gilt für andere Zugriffe, die speziell eine bestimmte Partition betreffen. SQL-Beispiel für das Anlegen einer Range-Partitionierung: CREATE TABLE person (pid NUMBER NOT NULL, birth_date DATE NOT NULL, name VARCHAR2(100)) PARTITION BY RANGE (birth_date) (PARTITION person_q1 VALUES LESS THAN (TO_DATE('01/01/1986', 'DD/MM/YYYY')) TABLESPACE people, PARTITION person_q2 VALUES LESS THAN (TO_DATE('01/01/1987', 'DD/MM/YYYY')) TABLESPACE people, PARTITION person_q3 VALUES LESS THAN (TO_DATE('01/01/1988', 'DD/MM/YYYY')) TABLESPACE people, PARTITION person_q4 VALUES LESS THAN (TO_DATE('01/01/1989', 'DD/MM/YYYY')) TABLESPACE people); Hierbei wird die Tabelle person nach dem Geburtsdatum partitioniert werden. In vier Partitionen.

3.2 Hash-Partitionierung Bei einer Hash-Partitionierung übernimmt eine interne Hash-Funktion die Zuordnung einer Tabellenzeile zu einer Partition anhand einer, oder mehrerer Spalten. Auf Grund der internen Hash- Funktion kann nicht vorher gesagt werden, in welche Partition eine Zeile gespeichert wird. Dadurch ist es bei einer Hash-Partitionierung nur möglich eine gewünschte Anzahl an Partitionierungen anzugeben. Bei einer Partitionierung über einem natürlichen Wert, wie Monate, oder Jahre bringt die Hash- Partitionierung keine Vorteile. Die Vorteile der Hash-Partitionierung liegen in der Anwendung auf Daten ohne natürliches Partitionierungskriterium, oder bei denen die Daten ungleich verteilt sind. SQL-Beispiel für das Anlegen einer Hash-Partitionierung: CREATE TABLE person (pid NUMBER NOT NULL, bierth_date DATE NOT NULL, name VARCHAR2(100)) PARTITION BY HASH (pid) PARTITIONS 4 STORE IN (people, people, people, people); Hierbei wird über die STORE IN-Klausel der Tablespace definiert werden in dem die Partitionen gespeichert werden. Alternativ dazu kann der Tablespace direkt angegeben werden: CREATE TABLE person (pid NUMBER NOT NULL, birth_date DATE NOT NULL, name VARCHAR2(100)) PARTITION BY HASH (pid) (PARTITION person_q1 TABLESPACE people, PARTITION person_q2 TABLESPACE people, PARTITION person_q3 TABLESPACE people, PARTITION person_q4 TABLESPACE people); 3.3 Composite-Partitionierung Bei der Composite-Partitionierung handelt es sich um eine Kombination aus Range- und Hash- Partitionierung. Dabei wird zuerst eine Range-Partitionierung durchgeführt und dann die einzelnen Partitionierungen mit einer Hash-Partitionierung partitioniert. SQL-Beispiel für fas Anlegen einer Composite-Partinionierung: CREATE TABLE person (pid NUMBER NOT NULL, birth_date DATE NOT NULL, name VARCHAR2(100)) PARTITION BY RANGE (birth_date) SUBPARTITION BY HASH (pid) SUBPARTITIONS 8 (PARTITION person_q1 VALUES LESS THAN (TO_DATE('01/01/1986', 'DD/MM/YYYY')), PARTITION person_q2 VALUES LESS THAN (TO_DATE('01/01/1987', 'DD/MM/YYYY')), PARTITION person_q3 VALUES LESS THAN (TO_DATE('01/01/1988', 'DD/MM/YYYY')), PARTITION person_q4 VALUES LESS THAN (TO_DATE('01/01/1989', 'DD/MM/YYYY'));

3.4 List-Partitionierung Bei einer List-Partitionierung werden keine festen Wertebereiche fest gelegt. Sondern möglicherweise nicht fortlaufende, explizite Werte als Partitionierungskriterium festgelegt. Dies findet vor allem dort Anwendung, wo keine natürlichen Wertebereiche vorliegen, trotzdem aber eine Kontrolle darüber erwünscht ist, was in welcher Partitionierung gespeichert wurde, um zum Beispiel das Löschen zu erleichtern. Die Partitionierung geschieht hier, wie bei der Range-Partitionierung über eine Value-Klausel. Dabei ist es bei der List-Partitionierung jedoch nur möglich eine Spalte als Kriterium anzugeben. SQL-Beispiel für das Anlegen einer List-Partitionierung: CREATE TABLE state_sales( acct_no NUMBER(5), acct_name VARCHAR2(30), amount_of_sale NUMBER(6), state_cd VARCHAR2(2), sale_details VARCHAR2(1000), PRIMARY KEY (acct_no, acct_name, state_cd) ) ORGANIZATION INDEX INCLUDING state_cd OVERFLOW TABLESPACE users PARTITION BY LIST (state_cd) ( PARTITION reg_east VALUES ('MA','NY','CT','NH'), PARTITION reg_west VALUES ('CA', 'AZ', 'NM','OR'), PARTITION reg_south VALUES ('TX','KY','TN','GA'), PARTITION reg_central VALUES ('OH','ND','SD','IA'), PARTITION reg_null VALUES (NULL), PARTITION reg_unknown VALUES (DEFAULT) Dieses Beispiel ist der Oracle-Tutorialseite http://www.remote-dba.cc/10g_52.htm entnommen. 3.5 Partitionierte Indizes Ebenso wie Tabellen können auch Indizes partitioniert. Partitionierte Indizes können sowohl für partitionierte als auch für nicht partitionierte Tabellen angelegt werden. Ebenso kann man partitionierte Tabellen mit nicht partitionierten Indizes versehen werden. Indextypen: Lokale Indizes: Partitionierte Indizes sind dann lokal wenn ihnen die selben Partitionierungskriterien wie die Tabellen zu denen sie gehören zu Grunde liegen. Dadurch können Operationen auf den partitionierten Tabellen eins zu eins auf die Indizes übertragen werden. Globale Indizes: Bei globalen partitionierten Indizes haben ein von der partitionierten Tabelle unabhängiges Partitionierungskriterium. Dies Kriterien werden stets auf Basis der Range- Partitionierung definiert. Prefixed: Indizes sind prefixed, wenn die als Partitionierungskriterium verwendeten Spalten selber auch indiziert sind.

Nonprefixed: Indizes sind nonprefixed, wenn wenn die für die Partitionierung verantwortlichen Spalten selbst nicht indiziert werden. Es sind drei Kombinationen dieser Eigenschaftspaare möglich: Lokal Prefixed-Index: CREATE INDEX invoices_idx ON invoices (invoice_date) LOCAL; CREATE INDEX invoices_idx ON invoices (invoice_date) LOCAL (PARTITION invoices_q1 TABLESPACE users, PARTITION invoices_q2 TABLESPACE users, PARTITION invoices_q3 TABLESPACE users, PARTITION invoices_q4 TABLESPACE users); Lokal Nonprefixed-Index: CREATE INDEX invoices_idx ON invoices (invoice_date) LOCAL; CREATE INDEX invoices_idx ON invoices (invoice_date) LOCAL (PARTITION invoices_q1 TABLESPACE users, PARTITION invoices_q2 TABLESPACE users, PARTITION invoices_q3 TABLESPACE users, PARTITION invoices_q4 TABLESPACE users); Global Prefixed-Index: CREATE INDEX invoices_idx ON invoices (invoice_date) LOCAL; CREATE INDEX invoices_idx ON invoices (invoice_date) LOCAL (PARTITION invoices_q1 TABLESPACE users, PARTITION invoices_q2 TABLESPACE users, PARTITION invoices_q3 TABLESPACE users, PARTITION invoices_q4 TABLESPACE users); 3.6 Existierende Tabellen partitionieren Eine nachträgliche Partitionierung einer Tabelle ist nur auf einem Umweg möglich. Dabei wird die Partitionierung einer anderen Tabelle mit der zu partitionierenden Tabelle vertauscht. Dabei können ALTER TABLE und EXCAHNGE PARTITION verwendet werden, um schon bestehende Tabellen zu partitionieren. Als erstes wird eine Tabelle erstellt: CREATE TABLE my_table ( id NUMBER, description VARCHAR2(50) ); INSERT INTO my_table (id, description) VALUES (1, 'One'); INSERT INTO my_table (id, description) VALUES (2, 'Two'); INSERT INTO my_table (id, description) VALUES (3, 'Three'); INSERT INTO my_table (id, description) VALUES (4, 'Four'); COMMIT;

Als nächstes wird eine neue, partitionierte Tabelle mit einer Partition erstellt, die als Zieltabelle dienen wird. CREATE TABLE my_table_2 ( id NUMBER, description VARCHAR2(50) ) PARTITION BY RANGE (id) (PARTITION my_table_part VALUES LESS THAN (MAXVALUE)); Als nächstes wird das original Tabllensegment mit dem partitionierten vertausch. ALTER TABLE my_table_2 EXCHANGE PARTITION my_table_part WITH TABLE my_table WITHOUT VALIDATION; Jetzt muss bloß noch die alte Tabelle gelöscht und die neue in den Namen der alten umbenannt werden, und die Partitionierung ist vollständig. *Das Beispiel ist der Oracle Tutorialseite: http://www.oraclebase.com/articles/8i/partitionedtablesandindexes.php#partitioningexistingtables entnommen. 4. Die STORAGE-Klausel Die Storage-Klausel spezifiziert wie ein Objekt den Platz benutzt, in dem es angelegt ist. Einige Objekte, einschließlich Pakete, Prozeduren, Typen, Sichten,Bibliotheken, Ordner und Index-Typen benutzen die Storage-Klausel nicht. Eine create tablespace-statement kann eine default -Storage-Klausel haben, die die Storage- Vorgabe für im Tablespace angelegte Objekte festlegt. SQL-Beispiel für der Verwendung der Storage Klausel: storage ( initial 65536 next 1048576 minextents 1 maxextents 2147483645 pctincrease 0 freelists 1 freelist groups 1 optimal 7k buffer_pool default )

initial Spezifiziert die Größe (in Bytes) des ersten Extents. next Spezifiziert die Größe (in Bytes) des zweiten Extents. pctincrease Spezifiziert die Größe des n-ten Extents. Die größe des n-ten Extents = pctincrease * der Größe des (n-1)-ten Extents. Pctincrease sollte auf 0 gesetzt sein, um die Fragmentierung des Tablespace zu reduzieren. minextents Spezifiziert die anfängliche Anzahl der Extents. Dadruch lässt sich bereits einen große Menge Speicher allokieren wenn man ein Objekt erstellt, selbst, wenn der Speicher nicht fortlaufend ist. Der Default- und Minimumwert ist 1, womit nur das anfängliche Extent allokiert wird. Für Rollback-Segmente ist das Minimum 2. Die Maximal-Größe hängt vom verwendeten Betriebssystem ab. maxextents Spezifiziert die maximale Anzahl von Extents, die ein Objekt haben kann. Der Minimum-Wert für diese Spezifikation ist 1, außer für Rollback-Segmente, da liegt der Minimum-Wert, genau wie bei maxextents bei 2. Der Default-Wert hängt von der Größe der Datenblöcke ab. Des Weiteren kann hier auch der Wert unlimited angegeben werde, wenn gewünscht ist, dass bei Bedarf automatisch neue Extents allokiert werden. Dies sollte nicht für Rollback-Segmente verwendet werden, das dies ermöglicht, dass lang läufige DML-Transaktionen mit dem Erstellen neuer Extents fort fahren, bis die Platte voll ist. freelists Spezifiziert für andere Objekte als Tablespaces und Rollback-Segmente,die Anzahl der freien Listen für jede der Gruppen freier Listen eine Tablle, eine Partition, ein Cluster, oder einen Index. Default- und Minimum-Parameter sind 1, so, dass jede Gruppe freier Listen eine frei Tabelle beinhaltet. Der Maximalwert hängt von der Größe der Datenblöcke ab. Wenn ein zu großer Wert für freelists angegeben wird, gibt Oracle eine Fehlermeldung mit dem Maximalwert zurück. freelist groups Spezifiziert die Anzahl der Gruppen freier Listen für das Datenbankobjekt, dass man erstellt. Der Default- und Minimumwert dieses Parameters liegt bei 1. Jede Gruppe benutzt einen Datenbankblock. Es gilt: Wenn für initial ein zu geringer Wert angeben wird, wird Oracle automatisch den Wert auf den nötigen Betrag erhöhen Wenn man ein Objekt in einem uniformen Lokal gemanageten Tablespace erstellt, und die Extent-Größe ist nicht groß genug, um die Anzahl an Gruppen zu aufzunehmen, wird create- Operation fehlschlagen..

buffer_pool Der Wert von buffer_pool folgende Werte annehmen: keep recycle default KEEP spezifiziert, dass Blöcke aus dem Segment in den KEEP Bufferpool getan werden. RECYCLE spezifiziert, dass Blöck aus dem Segment in den RECYCLE-Pool getan werden. DEFAULT zeigt den default-bufferpool an. Dieser Parameter kann nur für create table, create index, create cluster, alter table, alter index und alter cluster spezifiziert werden. optimal Das Optimum kann nur für rollback-segemente spezifiziert werden. Es spezifiziert die optimale Größe (in Bytes) für ein Rollback-Segment. Oracle versucht die Größe des Rollback-Segments durch das automatische Freigeben von Extents, wenn ihr Inhalt nicht mehr für aktive Transaktionen benötigt wird, beizubehalten. Des Weiteren werden so viele Extents wie möglich frei gegeben, ohne die komplette Größe des Segments unter den bei OPTIMAL spezifizierten Wert fällt. Der Wert von OPTIMAL kann nicht niedriger als der zuvor von den Anderen Parametern allokierte Speicher. Der Maximalwert hängt vom Betriebssystem ab. Oracle rundet Werte auf das nächste Vielfache der Blockgröße auf. Es kann auch der Wert NULL angegeben werden. Das heißt es gibt keine optimale Größe. Demnach wird Oracle nie Extents frei geben. Dieses ist das Default-Verhalten. 5. Unterstützte Indexstrukturen: 5.1 B*Indizes: B*Indizes sind die klassischen Indizes in Oracle-Datenbanken und basieren auf einem B*-Baum. Sie zeigen ein gutes Sperrverhalten, da immer nur der momentan von einer Transaktion bearbeitete Eintrag gesperrt wird. Dadurch werden keine unnötigen Wartezeiten bei gleichzeitig operierenden Transaktionen ausgelöst. Dadurch ist allerdings höher als, der Bitmap-Indizes mit ihrem ungünstigen Sperrverhalten. Dadurch entstehen mehr Kosten, da beim Zugriff mehr Indexblöcke gelesen werden müssen. Das führt außerdem dazu, dass Mischoperationen mit B*-Indizes wesentlich aufwendiger sind als bei Bitmap-Indizes. Um unnötige Mischoperationen zu vermeiden kann deshalb einen zusammengesetzter Index angelegt werden.

5.2 Bitmap-Indizes: Bei einem Bitmap-Index wird eine Bitmaske gespeichert, die bestimmte Werte repräsentiert, die nur ein Zustände annehmen können. Dieses findet zum Beispiel bei der Charakterisierung von Personen Anwendung, wo bestimmte Zustände wie ledig, oder verheiratet, männlich, oder weiblich gespeichert werden. In der Bitmapstruktur wird ein zweidimensionales Feld erstellt, mit einer Spalte für jede Zeile der zu indizierenden Tabelle. Jede Spalte repräsentiert einen bestimmten Wert im Bitmap-Index. Dieses zweidimensionale Feld repräsentiert jeden Wert im Index, vervielfacht um die Anzahl der Zeilen in der Tabelle. Bei der Zeilenabfrage dekomprimiert die Bitmap in den RAM-Datenpuffer, so das es sie schnell auf Treffer gescant werden kann. Diese Treffer werden Oracle in Form einer Row-ID-Liste zurück geliefert. Der echte Vorteil von Bitmap-Indizierung tritt zu Tage, wenn eine Tabelle mehrere Bitmap-indexe beinhaltet. Das erstellen von multiplen Bitmap-Indizes liefert eine gute Methode, um schnell komplizierte SQL-Anfragen zu beantworten. Da sich maximal nur zwei physische Bitmaps einen Block teilen, können abhängig von der Blockgröße und Komprimierung Tausende von Datensätzen in einer Bitmap referenziert werden. Dieser Vorteil kann auch als Nachteil wirken. Werden Spalten geändert, die durch einen Bitmapindex indiziert wurden, wird das ganze physische Bitmap gesperrt. Das heißt von der Sperrung können wiederum tausende von Datensätzen betroffen sein. Bitmaps können optimal eingesetzt werden, wenn die betreffende Spalte äußerstem selten geändert wird, die Kardinalität der Spalten niedrig ist, oder die Tabellen viele Datensätzen enthalten. Wegen ihres Sperrverhaltens dürfen Bitmap-Indizes keines Falls für Spalten angelegt werden, die gleichzeitig von mehreren Transaktionen verändert werden. Beispiel für einen Bitmap-Index: pid F K 1 1 0 2 0 0 3 1 1 Pid: Personen-ID F: Familienstand (0=Ledig, 1=Verheiratet) K: Kinder (0=keine Kinder, 1=Kinder) pid F K 1 1 0 2 0 0 3 1 1 Die grün markierte ROW wird durch eine Transaktionen verändert. Alle anderen daten der Bitmaske werden auch gesperrt. Die Transaktion in der gelb markierten ROW kann nicht zugreifen.

5.3 Bitmap-Join-Indizes Bei Bitmap-Join-Indizes werden Tabellen anhand von Spaltenwerten anderer Tabellen die über Fremdschlüssel mit der Tabelle verbunden sind indiziert. Dadurch können Join-Operationen im Index vorbereitet werden. Dadurch sind für einen Join keine Zugriffe auf Fremdschlüssel-Tabellen mehr nötig. Die Where-Klauseln können über den Bitmap-Join-Index aufgelöst werden. Dadurch kann die Performance der Datenbank erhöht werden. Ein Beispiel für die Verwendung von Bitmap-Join-Indizes: Eine Tabelle mit Wettkampfteilnehmern setzt sich sich aus bestimmten Werten zusammen. Darunter auch Fremdschlüssel auf einen Trainer und ein Herkunftsland. Trainer Tid Name Alter Herkunft Land Cid Name Einwohnerzahl Kontinent Spieler... Tid Cid Name Erstellen eines Bitmap-Join-Indexes: create bitmap index trainer_land_spieler on spieler(trainer.herkunft,land.kontinent) from spieler s, trainer t, land l where s.tid=t.tid and s.cid=l.cid; Um die Funktionsweise zu verdeutlichen sollen nun alle Trainer ausgewählt werden, deren Spieler und sie selbst aus Asien stammen. Verwendung Select name from trainer natural join spieler natural join land where herkunft = 'Asien' and kontinent = 'Asien'

Normalereise würde diese Anfrage mit einem nested-loop- Join oder hash-join für alle drei Tabellen bedient werden. Mit einem Bitmap-Join-Index sind die die Tabellen schon vorgejoint und die Query kann schnell eine Row-ID passender Rows in allen drei Tabellen erhalten. Oracle-Benchmarks zeigen, dass ein Bitmap-Join-Index eine Anfrage bis zu acht mal schneller bearbeiten können, als herkömmliche Indizierungsmethoden. 5.4 Reverse Key-Indizes Reverse Key-Indizes sind eine Variante der B*Indizes. Dabei werden die Schlüsselwerte in den Index-Blättern in umgekehrter Zeichenreihenfolge abgespeichert. Aus 'Jim' wird 'mij', aus 'Bob' wird 'bob'. Der Nutzen besteht vor allen darin, dass Schlüssel, die normaler Weise auf einem Blatt zusammen stünden, auf verschiedene Blätter verteilt. Das gleiche gilt für Operationen die diese Schlüsselwerte verändern. Dadurch können I/O-Operationen besser auf verschiedene Index-Blätter verteilt werden 5.5 Funktionale Indizes Funktionale Indizes werden im Kontext mit Funktionen oder Ausdrücken angelegt, die sich auf Spalten der betreffenden Tabelle beziehen. Dabei werden die von den Funktionen zurückgegebenen Werte indiziert. Dabei können sowohl vordefinierte SQL-Funktionen verwendentet werden, als auch jegliche vom Benutzer definierte Funktion. Da der Rückgabewert einer Funktion beliebig ist können Funktionale Indizes als B*Baum- oder Bitmap-Index angelegt werden.

Quellen: Oracle9i für den DBA Uwe Herrmann Oracle9i Index-Organized Tables Technical Whitepaper http://www.dba-oracle.com/oracle_tips_bitmapped_indexes.htm http://www.dba-oracle.com/art_builder_bitmap_join_idx.htm http://www.dba-oracle.com/t_ault_18_clause_minextents_maxextent.htm http://www.dba-oracle.com/oracle_tip_hash_index_cluster_table.htm http://www.ss64.com/orasyntax/4clusters.html http://www.ss64.com/ora/index_c.html http://dbs.uni-leipzig.de/html/seminararbeiten/semss98/arbeit5/dwdm-vortrag5-22.html http://www.oracle-base.com/articles/8i/partitionedtablesandindexes.php#range http://www.remote-dba.cc/10g_52.htm http://www.adp-gmbh.ch/ora/sql/clauses/storage.html http://youngcow.net/doc/oracle10g/server.102/b14200/clauses009.htm http://www.psoug.org/reference/clusters.html www.rrzn.uni-hannover.de/fileadmin/kurse/material/oracle/o9i_pt13.pdf