Materialisierte Sichten in Oracle - Seminar "Intelligente Datenbanken" Prof. Dr. Rainer Manthey
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Seminar „Intelligente Datenbanken“
AG „Intelligente Datenbanken“
Prof. Dr. Rainer Manthey
Sommersemester 2005
Materialisierte Sichten in Oracle
Kai-Lin Pang
07. Juni 2005Inhaltsverzeichnis
1 Motivation 3
2 Anpassungsmethoden 3
2.1 Memoryless Refresh-Algorithmus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Syntax zur Erstellung von materialisierte Sichten 5
3.1 Refresh-Option. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 Dimensionen 6
4.1 Syntax zur Erstellung von Dimensionen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2 Beispiel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5 Query Rewrite 9
5.1 Konzepte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2 General Rewrite-Algorithmus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
6 Heuristisch und Cost Based Rewrite 12
7 Zusammenfassung 12
A Literatur 13
-2-1 Motivation
Heutzutage besitzen viele Unternehmen ihre eigenen Datenbanken, in denen betriebliche
Informationen gespeichert werden. In vielen Fällen besitzt jede Filiale eines Unternehmens
ihre eigene Datenbank. Wie können nun die Daten aller Filialen gemeinsam effizient
ausgewertet werden? Eine Möglichkeit besteht darin Sichten in einem Data Warehouse zu
materialisieren. Ein Data Warehouse kann als eine Menge von (Materialisierten Sichten)
MVs aufgefasst werden.
Die MVs sind Resultate einer Anfrage in Form einer relationalen Tabelle gespeichert, um
komplexe Anfragen schneller zu beantworten. Aktualisierung der Basistabellen können
Inkonsistenzen zwischen einer MV und ihre Basisrelation bestehen. Die Herausforderungen
sind geeignete effiziente Methoden zur Anpassung MVs zu finden. In Kapitel 2 wird ein
effizienter Algorithmus zur Anpassung MVs vorgestellt.
Das Konzept der materialisierten Sichten wurde bis heute noch nicht im SQL-Standard
standardisiert. Die Erweiterungen von SQL um MVs sind bisher nur für einzelne DBMS-
Produkte verfügbar, z.B Oracle, IBM DB2 und MS SQL. Wobei IBM DB2 und MS SQL nicht
so eine Fülle von Möglichkeiten besitzen MVs zu definieren im Gegensatz zu Oracle, mit
dem sich Kapitel 3 auseinandersetzt.
Mit Oracle8i wurden neue Möglichkeiten im Data Warehousing-Bereich eingeführt welche
enormen Performanceverbesserungen ermöglichen. Eine Performanceverbesserung wird
mithilfe Dimensionen erreicht, welche in Kapitel 4 beschrieben wird.
Kapital 5 beschäftigt sich mit MVs, die selbst auch für Abfrageoptimierungen verfügbar sind,
bei denen Bestandteile der Abfrage, transparent für den Nutzer, durch Vorberechnete MVs
ersetzt werden (Query Rewrite).
2 Anpassungsmethoden
Eine Möglichkeit MVs zu aktualisieren ist die vollständige Rematerialisierung, jedoch ist
diese Methode sehr ineffizient und mit enormem Zeitaufwand verbunden. Für beliebig
komplexe Anfragen ist komplette Neuberechnung seitens Oracle vorgeschrieben.
Die inkrementelle Aktualisierung stellt eine andere Methode dar. Dabei werden
Datenänderungen an der Basisrelation protokolliert und diese Änderungen in die MVs
propagiert. Das Ziel dabei ist, Zugriffe auf die Basisrelation zu vermeiden. Ab Oracle8i
werden drei Klassen von inkrementell angepassten MVs unterstützt:
• „Materialized Join View“ (MJV), die eine Materialisierung einer Anfrage mit INNER
und OUTER Equi-Join darstellt
• „Materialisized Aggregate View“ (MAV), welches eine MJV mit Aggregationen ist
• „Materialisierte Subquery View“ (MSV) mit materialisierten EXISTS Unteranfragen.
-3-2.1 Memoryless Refresh-Algorithmus
Im Folgenden betrachten wir einen effektiven „memoryless“-Algorithmus für die
inkrementelle Anpassung MJVs. Die Deltas (∆) werden von zwei Quellen bezogen: Row-
DML Logs und Direct-Loader Logs.
Das Log einer MV ist ein Schemaobjekt, welches Änderungen der Daten in einer
Basisrelation aufzeichnet, sodass eine auf der Basisrelation definierende MV fortlaufend
aktualisiert werden kann.
Im Row-DML Log protokolliert Oracle, welche Zeilen in einer Tabelle mittels DML verändert
wurden. ∆X besteht aus drei Mengen: ∆X = {D} + {I} + {U}. In den Mengen {D}, {I} und {U}
werden Zeilen gespeichert, die gelöscht, eingefügt oder aktualisiert werden sollen. Zusätzlich
werden eine Kopie der geänderten Zeilen, die ROWID, der DML-Typ, und ein Zeitstempel
gespeichert. Bei ROWID handelt es sich um ein so genanntes Pseudoattribut. Das ROWID-
Attibut identifiziert eindeutig den Speicherplatz jedes Tupels einer Tabelle. Der Zeitstempel
stellt fest, ob beim Aktualisieren der MV diese Zeile hinzugefügt, aktualisiert oder gelöscht
werden muss. Oracle protokolliert im Direct-Loader Log, welche neuen Zeilen eingefügt
werden müssen.
Wir erläutern nun den Aktualisierungsalgorithmus Anhang eines Beispiels. Falls die MV M
nur mit einer Tabelle verbunden ist, können wir die Änderungen einfach an die MV M
weitergeleitet werden. Wir betrachten zwei Tabellen R und S, auf denen durch einen
natürlichen Join (z.B. M = R S) eine MV M definiert ist. Dieser Algorithmus lässt sich leicht
auf beliebig viele Tabellen verallgemeinern. Seien weiter ∆R bzw. ∆S die Änderungen, die
über DML an R bzw. S durchgeführt wurden und seien R' bzw. S' die geänderten Tabellen,
also gilt R' = R + ∆R bzw. S' = S + ∆S. Wenn ∆M die Veränderungen darstellt, die an der MV
M durchgeführt werden müssen, dann führt dies zur folgenden Gleichung:
Q1 ∆M = (R ∆S) + (∆R S) + (∆R ∆S) = (R ∆S) + (∆R S')
Da die unveränderten Tabellen (z.B. R und S) nach der Aktualisierung nur unter
bestimmten Zeitkosten zu berechnen sind, formt man die bisherige Gleichung so um, dass
sie keine der ursprünglichen Tabelle mehr enthält, damit die ursprüngliche Tabelle nicht
mehr wiederberechnet werden muss (memoryless):
Q2 ∆M = (R' ∆S) - (∆R ∆S) + (∆R S')
Die Wiederberechung der Basisrelation nach Datenänderungen wird beim „memoryless“-
Algorithmus vermieden. In vielen Situationen behandelt der Algorithmus ein Update durch
Löschung gefolgt von einer Einfügeoperation und fügt diese entsprechend in {D} und {I} ein.
-4-3 Syntax zur Erstellung materialisierter Sichten
Eine MV in Oracle wird mit dem folgenden Statement erzeugt:
CREATE MATERIALIZED VIEW
TABLESPACE { }
REFRESH
[ ENABLE | DISABLE ] QUERY REWRITE
AS (SQL STATEMENTS);
Im Gegensatz zur Definition einer virtuellen Sicht, wird bei der MV seht das Schlüsselwort
MATERIALIZED vor VIEW als Präfix. Die TABLESPACE-Option erlaubt den
Speicherbereich der Tabellen in Oracle zu definieren.
Die bestimmt, wann eine MV erzeugt wird:
• BUILD IMMEDIATE: Die MV wird sofort erzeugt.
• BUILD DEFFERED: Die MV wird zu einem späteren Zeitpunkt erstellt.
• ON PREBUILT TABLE: Die MV kann über existierende Tabelle gelegt werden.
3.1 Refresh-Option
Wir diskutieren nun die wichtigsten Optionen von REFRESH:
[ REFRESH [ FAST | COMPLETE | FORCE ]
[ ON COMMIT | DEMAND ]
[ START WITH date ] [ NEXT date ]
[ WITH { PRIMARY KEY | ROWID } ] ]
REFRESH-Methoden (Wie wird aktualisiert?):
• FAST
Bei FAST werden Zeilenveränderungen der Basisrelation an die MV inkrementell
propagiert. Dabei muss ein MV-Log für jede Basistabelle angelegt werden. Viele
weitere Anforderungen müssen erfüllt werden.
• NEVER
Bei NEVER findet keine Aktualisierung statt.
• COMPLETE
Die MV wird vollständig rematerialisiert.
• FORCE
-5-Die FAST Strategie wird bei FORCE wenn möglich verwendet, sonst die COMPLETE.
REFRESH-Modus (Wann wird aktualisiert?):
• ON COMMIT
Die Aktualisierung findet beim Abschluss einer Transaktion an einer Basistabelle
statt.
• ON DEMAND
Die Aktualisierung wird bei Bedarf durch den Benutzer wird festgelegt.
REFRESH-Timing:
• START WITH
Die MV wird zu einem bestimmten Zeitpunkt zum ersten Mal aktualisiert.
• NEXT
Hierbei bestimmt man das Refresh-Intervall.
4 Dimensionen
Eine Dimension ist ein Gebilde, die geordneten Daten kategorisiert, um schnelle Anfragen
zu ermöglichen, ein Weg um komplexe Relationsbeziehungen zu beschreiben. Eine
Dimension kann bildlich als einen gerichteten Graph dargestellt werden, bei der jede Kante
eine hierarchische Beziehung und jeder Knoten eine Aggregationsebene repräsentiert. Eine
Hierarchie ist ein Pfad durch diesen Graphen. Jeder Wert eines „Kindes“ in einer Hierarchie
ist mit exakt mit einem Wert des „Elternteils“ verbunden.
Wozu überhaupt Dimensionen?
Häufige Anfragen wie z.B. „Wie viele Produkte X haben wir in Stadt Y im Monat Z
verkauft?“ sollen in einem Unternehmen materialisiert werden. Nun wollen wir nicht die
Umsätze nur nach Monaten, sondern auch nach Quartalen und Jahren verdichten. Es ist
nicht sinnvoll für jede dieser häufigen Anfragen eine entsprechende MV zu erstellen, wegen
Redundanzen wie z.B. Woche, Quartal, Jahr, etc. Mithilfe von Dimensionen können wir dem
Oracle-Optimizer die Beziehungen zwischen Attributen (z.B. zwischen Monat und Jahr)
verständlich machen.
-6-4.1 Syntax zur Erstellung von Dimensionen in Oracle
Eine Dimension in Oracle wird mittels des CREATE DIMENSION Befehls erzeugt:
CREATE DIMENSION
LEVEL [ IS
IS … ]
HIERARCHY
( [ CHILD OF
CHILD OF … ] )
ATTRIBUTE DETERMINES
DETERMINES , … ;
Die LEVEL-Klausel definiert den Namen einer Ebene. Eine oder mehrere Hierarchien
(Relationsbeziehungen) können mittels der HIERARCHY-Klauseln definiert werden. 1:1
funktionale Abhängigkeiten werden mit den ATTRIBUTE-Klauseln Oracle bekannt
gegeben.
Die Datenorganisation eines Data Warehouses unterscheidet zwischen Dimensionen und
Fakten. Dimensionen und Fakten werden anhand des Sternschemas modelliert.
• Dimensionstabelle:
Die Dimensionstabellen enthalten die Stammdaten und sind in der Regel
denormalisiert. Jede Tabelle besitzt ihren eigenen Primärschlüssel.
• Faktentabelle:
Es gibt zentrale Faktentabelle, um die sich „sternenförming“ herum diverse
Dimensionstabellen anordnen. Sie ist in der Regel normalisiert, hat einen eigenen
Primärschlüssel, enthält Fremdschlüssel zu allen anderen Dimensionstabellen und
beinhalten die Kennzahlen.
4.2 Beispiel
Wir wollen nun die Anfrage „Wie viele Produkte X haben wir in Stadt Y im Monat Z
verkauft?“ materialisieren. Dazu werden die Basisdaten anhand des Sternschemas
modelliert (Abb. 1).
-7-Dimensionstabelle
Dimensionstabelle Zeit
Städte
Sadt_Id Datum
Region Faktentabelle Woche
Faktentabelle
Stadt Monatsname
Umsätze
Umsatz_ID Monat
Quartal
Stadt_Id
Jahr
Produkt_Id
Datum
Produkte Foreign
ForeignKeys
Keyszu
zu
Umsatz
Produkt_Id
allen
allen
Dimensionstabellen
Dimensionstabellen
Produktname
Produktgruppe
Marke
Abb. 1
In diesem Beispiel besitzt die Faktentabelle Fremdschlüsseln Stadt_Id, Produkt_Id
und Datum auf die Dimensionstabellen Städte, Produkte und Zeit. Die Datenbank
verwaltet Fakten wie Umsätze und Verkaufszahlen je Region, Produkt und Zeit.
Um „Umsatz Anfragen“ nach Quartal oder Jahr effizient beantworten zu können, teilen wir
die Beziehungen zwischen den Attributen mithilfe von Dimensionen dem Oracle-Optimizer
mit. Dazu betrachten wir in diesem Beispiel die Zeitdimension (Abb. 2), die in Jahr, Quartal,
Monat, Woche und Datum unterteilt werden kann.
⇒⇒Wochenumsätze
Wochenumsätze
Jahr können
könnenzuzuJahresumsätze
Jahresumsätze
Jahr „aufgerollt“
„aufgerollt“werden.
werden.
Quartal
Quartal
Jeder ⇒⇒Monatsumsätze
Monatmuss
JederMonat mussininexakt
exakt Monatsumsätze
einem können
könnenzuzuQuartals-
einem Quartalenthalten
Quartal enthaltensein
sein Quartals-
Monat
(hierarchische
(hierarchischeRelation).
Relation). Monat umsätzen„aufgerollt“
umsätzen „aufgerollt“
werden.
werden.
Woche
Woche
Datum
Datum
Abb. 2
Jeder Monat muss exakt in einem Quartal enthalten sein, folglich können Monatsumsätze
zu einer Summe von Quartalumsätzen aufgerollt (ROLLUP) werden. „ROLLUP“ ermöglichst
Oracle innerhalb einer Dimension auf summierte Daten zuzugreifen.
Die Zeitdimension und die Beziehungen zwischen den Attributen in diesem Beispiel, wird
Oracle mittels des CREATE DIMENSION-Befehls bekannt gegeben:
CREATE DIMENSION zeit_dim
LEVEL Datum IS Zeit.Datum
LEVEL Woche IS Zeit.Woche
LEVEL Monat IS Zeit.Monat
LEVEL Quartal IS Zeit.Quartal
LEVEL Jahr IS Zeit.Jahr
-8-HIERARCHY Kalender_rollup (
Datum CHILD OF Monat CHILD OF Quartal CHILD OF Jahr )
HIERARCHY woche_rollup (
Datum CHILD OF Woche CHILD OF Jahr )
ATTRIBUTE Monat DETERMINES Monatsname;
Zu beachten ist, dass Zeit.Datum in Oracle vom Typ DATE ist. Falls wir in der
Dimensionstabelle Zeit außerdem eine Spalte Monatsname enthält, dann kann
Monatsname von Monat funktional abhängig gemacht werden.
Da Oracle nun die Zeithierarchie bekannt ist, ist ein „intelligentes“ Query Rewrite durch den
Oracle-Optimierer möglich. Wenn wir eine MV die Umsätze nach Monat verdichtet haben,
dann können wir z.B. Umsätze nach Jahr, mittels der MV in welcher die monatsweise
verdichteten Daten abgespeichert sind, effizient beantwortet werden, anstelle auf die
Basisrelation zuzugreifen bzw. neu zu berechnen. Hierbei erlaubt es maximal 12-Tupel pro
Stadt und Marke aus den Umsätze MV zu aggregieren.
Die Implementierung vom „intelligenten“ Query Rewrite wurde seitens Oracle nicht
dokumentiert.
5 Query Rewrite
5.1 Konzepte
Der Oracle-Optimierer nutzt Informationen über verlustfreie Joins, funktionale
Abhängigkeiten, Spaltenäquivalenz und Join-Ableitbarkeit, um grosse Mengen von Anfragen
mit einer kleinen Menge von MVs zu umschreiben.
Join-Ableitbarkeit ermöglichst uns einen Join in einer Abfrage durch einen Join in einer MV
wiederzuberechnen. Mit einem LEFT OUTER Join in einer MV ist es möglich INNER Join in
einer Anfrage durch Filterung von Anti-Join-Zeilen, Semi-Join durch Eliminierung duplizierter
Zeilen und Anti-Join durch Filterung Theinner Join-Zeilen wiederzuberechnen. Mit INNER
Join in einer MV ist es möglich Semi-Join in einer Anfrage durch Eliminierung von
duplizierten Zeilen zu berechnen. Die Join-Ableitbarkeit Unterstützung vom Oracle erlaubt
Anfragen mit IN und EXISTS Subanfragen (Semi-Joins) mit MVs mit Inner oder LEFT
OUTER Joins zu umschreiben. Abfragen mit NOT IN und NOT EXISTS Subanfragen (Anti-
Joins) können mit MVs mit Left Outer Joins umschrieben werden.
-9-5.2 General Rewrite-Algorithmus
Bevor eine MV umschrieben wird, wird mittels verschiedenen Algorithmen überprüft, ob
eine MV überhaupt umschrieben werden kann. Die Abb. 3 zeigt uns welche Überprüfungen
auf verschiedene MVs durchzuführen sind.
Query Rewrite Checks MV mit Joins MV mit Joins und MV mit Aggregaten auf
Aggregaten Einzeltabellen
Full Exact Text Match X X X
Partial Text Match X X X
Join Compatibility X X -
Data Sufficiency X X X
Grouping Compatibility - X X
Aggregate Compatibility - X X
Abb. 3
Oracle führt Query Rewrite aus, indem die Join-Graphen eines Query Blocks (QB) mit
einer potentiellen MV verglichen werden. Jede MV ist ein potentieller Teilplan, um eine
Anfrage zu dienen. Die zwei Graphen sollten sich schneiden aber auch keine Überscheidung
des Subgraphen ist in einem QB, in einer MV oder beide erlaubt. Subanfrage Transformation
beinhaltet die Umwandlung von IN oder EXISTS Subabfragen in Semi-Joins und NOT IN und
NOT EXISTS Unterabfragen in Anti-Joins, welches höchst komplexe Abfragen ermöglichen.
Der Algorithmus ist in zwei Phasen aufgeteilt: Eligibility und Transformation:
Die Eligibility-Phase entscheidet ob überhaupt Rewrite möglich ist, entscheidet wie man eine
MV mit nicht überscheidende Relationen in einen QB joint und entscheidet welche
zusätzliche Join- oder Filterungsbedingungen erforderlich sind. Wenn ein QB eine
Aggregation beinhaltet, dann entscheidet der Eligibility-Algorithmus, ob die QB Aggregate
durch Aggregate in einer potentiellen MAV berechenbar sind.
Die Transformation-Phase ersetzt überschneidende Relationen von einem QB mit einer
MV und fügt falls erforderlich zusätzliche „Joins“ und „Selection“ Eigenschaften ein um den
QB durch die MV wiederzuerlangen.
Die folgenden Eligibility-Prüfungen werden ausgeführt bevor ein QB umschrieben wird:
1. Join Compatibility Check: Der Join-Graph G(M) einer MV M wird mit dem Join-
Graphen G(Q) eines QB verglichen. Der Subgraph G(I) stellt den Schnitt zwischen
G(M) und G(Q) dar, G(I)=G(M)∩G(Q). Der Delta Subgraph ∆G(Q) stellt den Bereich
- 10 -von G(Q) der nicht in G(I) ist dar, ∆G(Q)=G(Q)-G(I), und der Delta Subgraph ∆G(M)
stellt den Bereich von G(M) der nicht in G(I) ist dar, ∆G(M)=G(M)-G(I). G(Q) kann
durch G(Q)=∆G(Q) M verlustfrei berechnet werden, wenn alle Joins in ∆G(M)
verlustfrei und die Joins in G(I) zwischen der MV und QB vom selben Typ sind. Eine
Transformation ist erforderlich wenn einige Joins in G(I) nicht vom selben Typ, aber
kompatibel sind. Zum Beispiel, wenn G(M)=S←L→O („←“ bzw. „→“ bezeichnet einen
LEFT bzw. RIGHT OUTER Join) und G(G)=L O C, dann gilt ∆G(M)=S,
∆G(I)=L→O, G(Q)=C und wenn S←L verlustfrei ist, dann kann der QB umschrieben
werden als MV C mit Filterung von Anti-Join Zeilen in L→O.
2. Data Sufficiency Check: Alle erforderlichen Daten müssen in einer MV vorhanden
sein oder durch eine Join Back-Operation berechnet werden können. Zum Beispiel,
wenn der QB Referenzen auf die Spalte Produktname von der Relation Produkte
enthält, die funktional durch die Produkt_Id Spalte in einer MV bestimmt wird, so kann
Produktname berechnet werden durch MV Produkte mit Produkt_Id. Und wenn
Produkt_Id in Produkte nicht UNIQUE ist, dann wird die MV mit einer abgeleiteten
Tabelle gejoint, die eindeutig Produkt_Id mit anderen benötigen Spalten von Produkte
wählt.
3. Grouping Compatibility Check: Wenn ein QB eine GROUP BY Klausel enthält, dann
sollte jede Gruppierungsspalte von einem QB exakt übereinstimmen mit einer oder
von einer Gruppierungsspalte einer potentiellen MAV funktionell abhängig sein. Wenn
eine QB-kompatiblere, funktional abhängige Gruppierung gefunden wurde, dann
sollten die Aggregate in MAV aufgerollt werden. Zum Beispiel, wenn ein QB
SUM(Umsaetze) BY Jahr anfragt und die potentielle MAV SUM(Umsaetze) BY Monat
enthält und weiter bekannt ist, dass Monat→Jahr, dann kann der QB umschrieben
werden durch aufrollen von SUM(Umsaetze) in einer MAV von der Monatsebene auf
Jahresebene.
4. Aggregate Compatibility Check: Wenn ein QB Aggregate enthält, dann muss jedes
Aggregat von einem Aggregat oder mehreren Aggregaten in einer potentiellen MAV
berechenbar sein. Zum Beispiel ist in einem QB SUM(x) nur durch COUNT(x) und
AVG(x) in einer MAV berechenbar. Eine Anfrage mit AVG(x) kann beantwortet
werden, wenn SUM(x) und COUNT(x) in einer MAV vorhanden ist. AVG(x) kann
aufgerollt werden, nur wenn COUNT(x) auch existiert. Aggregate mit Ausdrücken
werden ebenfalls unterstützt. Zum Beispiel, SUM(a+b) in einem QB wird entweder mit
SUM(a+b) oder SUM(b+a) in einer MAV bestimmt, und SUM(a)+SUM(b) in einem QB
wird mit SUM(a) und SUM(b) in einer MAV bestimmt.
- 11 -6 Heuristic und Cost Based Rewrite
Eine MV wird auf eine Menge von Relationen definiert, es muss eine Schnittmenge von
dieser Menge mit der Menge von Relationen in einem QB existieren, damit die MV ein
Kandidat für „Umschreibung“ sein kann. Um eine Menge von potentiellen MVs für einen QB
zu erfassen wird eine Liste von MVs für jede Relation gehalten. Diese Liste enthält für die
Relation R alle MVs, die R als ihre Basistabelle referenziert.
Wenn ein QB Aggregate enthält, dann wird als erstes versucht, diese Aggregate mit einer
MAV zu umschreiben. Wenn noch Joins verbleiben, wird die Umschreibung mit MJVs oder
MAVs versucht. Rewrite wird solange wiederholt bis noch Joins in einem QB übrig bleiben
oder keine geeignete MV gefunden wird. Da die Datengröße durch Aggregation reduziert
wird, wird immer zuerst versucht Rewrite mit einer MAV durchzuführen, um diese Vorteile als
erstes zu erreichen.
Wenn es möglich ist einen QB mit mehreren geeigneten MVs zu umschreiben, wird eine
Heuristik namens „Query Reduction Factor“ verwendet um die beste geeignete MV in einer
Liste geeigneter MVs zu identifizieren.
Nachdem die gesamte Anfrage mit einer MV oder mehreren MVs umschrieben wurde, ist
die Anfrage nun optimiert und seine optimalen Kosten sind gefunden.
7 Zusammenfassung
Mithilfe von MVs in Oracle können selbst sehr komplexe Anfragen mittels Query Rewrite
effizient beantwortet werden. MVs sind transparent für den Nutzer, die können nach Bedarf
inkrementell oder mit „Scheduler“ aktualisiert werden. Die Auswahl und die Pflege der MVs
ist kein triviales Problem, deshalb wurde sie bis jetzt noch nicht im SQL-Standard
standardisiert.
Dimensionen erlauben den Oracle-Optimizer über komplexe Datenbeziehungen zu
„informieren“ um dadurch „intelligentes“ Query Rewrite zu ermöglichen.
- 12 -A Literatur
[BDDFFNSWZ98] R.G. Bello, K. Dias, A. Downing, J. Feenan, J. Finnerty, W.D.
Norcott, H. Sun, A. Witkowski, M. Ziauddin: Materialized Views
In Oracle, Proc. 24th VLDB Conf. New York, 1998, S. 659–664
[Or10g] Oracle10g Database SQL Reference
[OrDWG9i] Oracle9i Data Warehousing Guide
[OrAR9i] Oracle9i Advanced Replication
[OrBI9i] Business Intelligence with Oracle9i – An Oracle Technical
White Paper
- 13 -Sie können auch lesen
