Fehlerbehebung und Optimieren der Datenbankleistung

Anstatt der Tabelle EMPLOYEE, die sich nur in einer Datenbankpartition befindet,
verwendet der Datenbankmanager R_EMPLOYEE, d. h. die MQT, die in jede der
Datenbankpartitionen repliziert wird, in der die Tabelle SALES gespeichert ist. Der
Leistungsvorteil ergibt sich daraus, dass die Mitarbeiterinformationen zur Ausführung
des Joins nicht an jede Datenbankpartition über das Netz gesendet werden
müssen.
Replizierte MQTs in zusammengefassten Joins
Replizierte MQTs können auch bei der Zusammenfassung (Kollokation) von Joins
helfen. Wenn beispielsweise ein Sternschema eine große Fakttabelle enthält, die
sich über zwanzig Datenbankpartitionen erstreckt, sind die Joins zwischen der
Fakttabelle und den Dimensionstabellen am effizientesten, wenn diese Tabellen
durch Kollokation zusammenfasst werden. Wenn sich alle Tabellen in derselben
Datenbankpartitionsgruppe befinden, ist höchstens eine Dimensionstabelle korrekt
für einen zusammengefassten Join (d. h. Join von durch Kollokation zusammengefassten
Tabellen) partitioniert. Die anderen Dimensionstabellen können nicht in einem
zusammengefassten Join verwendet werden, weil die Joinspalten der Fakttabelle
nicht dem Verteilungsschlüssel der Fakttabelle entsprechen.
Betrachten Sie zum Beispiel eine Tabelle mit dem Namen FACT (C1, C2, C3, ...),
die über Spalte C1 unterteilt ist, eine Tabelle mit dem Namen DIM1 (C1, dim1a,
dim1b, ...), die über C1 unterteilt ist, eine Tabelle mit dem Namen DIM2 (C2,
dim2a, dim2b, ...), die über C2 unterteilt ist, usw. In diesem Fall ist der Join zwischen
FACT und DIM1 perfekt, da das Vergleichselement dim1.c1 = fact.c1 von
den durch Kollokation zusammengefasst Daten profitiert. Beide Tabellen sind über
die Spalte C1 unterteilt.
Der Join mit der Tabelle DIM2 und dem Vergleichselement dim2.c2 = fact.c2
kann jedoch nicht mit durch Kollokation zusammengefassten Daten realisiert werden,
da FACT über die Spalte C1 unterteilt ist und nicht über die Spalte C2. In diesem
Fall könnten Sie die Tabelle DIM2 in der Datenbankpartitionsgruppe der Fakttabelle
replizieren, sodass der Join lokal in jeder Datenbankpartition erfolgen kann.
Wenn Sie eine replizierte MQT erstellen, kann die Quellentabelle eine Einzelpartitionstabelle
oder eine Mehrpartitionstabelle in einer Datenbankpartitionsgruppe sein.
In den meisten Fällen ist die replizierte Tabelle klein und kann in einer Datenbankpartitionsgruppe
mit einer Einzelpartition untergebracht werden. Sie können die zu
replizierende Datenmenge einschränken, indem Sie nur einen Teil der Spalten der
Tabelle angeben oder indem Sie die Anzahl der qualifizierten Zeilen durch Vergleichselemente
begrenzen.
Eine replizierte MQT kann auch in einer Datenbankpartitionsgruppe mit mehreren
Datenbankpartitionen erstellt werden, sodass Kopien der Quellentabelle in allen
Datenbankpartitionen erstellt werden. Joins zwischen einer großen Fakttabelle und
den Dimensionstabellen finden in dieser Art von Umgebung mit größerer Wahrscheinlichkeit
lokal statt, als wenn die Quellentabelle an alle Datenbankpartitionen
per Broadcast übertragen werden muss.
Indizes für replizierte Tabellen werden nicht automatisch erstellt. Sie können Indizes
erstellen, die sich von denen für die Quellentabelle unterscheiden. Zur Vermeidung
von Verletzungen von Integritätsbedingungen, die in der Quellentabelle nicht
vorhanden sind, können Sie jedoch keine eindeutigen Indizes erstellen oder Integritätsbedingungen
für replizierte Tabellen definieren, selbst wenn diese Integritätsbedingungen
für die Quellentabelle gelten.
298 Fehlerbehebung und Optimieren der Datenbankleistung