Replizierte Partitionen

Beispiel: In den Beispielanwendungen Samppart und Sampeast hat der DBA bei The Beverage Company (TBC) eine replizierte Partition zwischen der East-Datenbank und der Unternehmensdatenbank erstellt, die Ist-, Budget-, Abweichungs- und Abweichungs-% enthält. Benutzer in der östlichen Region speichern jetzt ihre Budgetdaten lokal. Da sie diese Daten nicht live aus der Unternehmenszentrale abrufen müssen, sind die Reaktionszeiten schneller, und sie haben mehr Kontrolle über die Ausfallzeiten und die Verwaltung lokaler Daten.

Änderungen an Daten in einer replizierten Partition werden von der Quelle auf das Ziel-Cube übertragen. Änderungen, die an replizierten Daten im Datenziel vorgenommen wurden, fließen nicht zurück zur Datenquelle. Wenn Benutzer die Daten im Datenziel ändern, überschreibt Essbase ihre Änderungen, wenn der DBA die replizierte Partition aktualisiert.

Wenn eine replizierte Partition definiert ist, kann der DBA eine Einstellung auswählen, um zu verhindern, dass die Daten im replizierten Teil des Ziel-Cubes aktualisiert werden. Die Aktualisierungseinstellung (die Aktualisierungen zulässt oder nicht zulässt) hat Vorrang vor dem Zugriff, der durch Sicherheitsfilter bereitgestellt wird, und wird auch von Batchvorgängen wie Dataload und Berechnung berücksichtigt.

Verwenden Sie eine replizierte Partition, um eines der folgenden Ziele zu erreichen:

Netzwerkaktivität verringern
Verkürzung der Abfrageantwortzeiten
Verkürzung der Berechnungszeiten
Besseres Recovery bei Systemausfällen

Regeln für replizierte Partitionen

Sie müssen in der Lage sein, die gemeinsamen replizierten Bereiche der Quell- und Ziel-Outlines zuzuordnen, obwohl die gemeinsamen Bereiche nicht identisch sein müssen. Sie müssen Essbase mitteilen, wie jede Dimension und jedes Element in der Quelle jeder Dimension und jedem Element im Ziel zugeordnet ist.

Die Quell- und Ziel-Outlines für die nicht gemeinsam verwendeten Bereiche müssen nicht zugeordnet werden können.

Da keiner der Bereiche, die Sie als repliziertes Partitionsziel verwenden, von einer transparenten Partitionsquelle stammen kann, können Sie keine replizierte Partition auf einer transparenten Partition erstellen, wie in der Abbildung dargestellt:

Abbildung 9-4: Ungültige replizierte Partition

Diese Abbildung zeigt, wie ein repliziertes Partitionsziel keine Daten aus einer transparenten Partitionsquelle enthalten kann.

Die Zellen im Ziel einer replizierten Partition können nicht aus zwei Quellen stammen. Die Zellen in einer Partition müssen aus einem Cube stammen. Um Zellen aus mehreren Cubes zu replizieren, erstellen Sie für jede Datenquelle eine andere Partition.

Die Zellen in einem Ziel-Cube können die Quelle für eine andere replizierte Partition sein. Beispiel: Wenn die Samppart.Company-Datenbank eine replizierte Partition aus der Sampeast.East-Datenbank enthält, können Sie die Zellen in Sampeast.East in eine dritte Datenbank wie Sampwest.West replizieren.

Sie können keine Attributelemente verwenden, um eine replizierte Partition zu definieren. Beispiel: Die Attributelemente "Markttyp" sind Urban, Suburban und Rural, die der Market-Dimension zugeordnet sind. Sie können keine Partition für Urban, Suburban oder Rural definieren, da eine replizierte Partition dynamische Daten und keine gespeicherten Daten enthält. Daher führt ein Versuch, Attribute in replizierten Partitionen zuzuordnen, zu einer Fehlermeldung. Mit dem Befehl WITHATTR können Sie jedoch Attributdaten replizieren.

Vorteile replizierter Partitionen

Da Daten näher an Endbenutzern gespeichert werden, können replizierte Partitionen die Netzwerkaktivität im Ziel-Cube verringern, was zu verbesserten Abrufzeiten führt.

Die Daten sind für alle Nutzer leichter zugänglich. Einige Benutzer greifen auf die Daten im Quell-Cube zu, andere im Ziel-Cube.

Fehlschläge sind nicht so katastrophal. Da sich die Daten an mehreren Stellen befinden, können bei einem Ausfall einer Datenbank nur die Benutzer, die bei dieser Datenbank angemeldet sind, nicht auf die Informationen zugreifen. Daten sind weiterhin verfügbar und können von den anderen Websites abgerufen werden.

Lokale Administratoren steuern die Ausfallzeit. Beispiel: Da Benutzer in der östlichen Region auf ihre eigenen replizierten Daten anstatt auf die Unternehmensdatenbank zugreifen, kann ein Administrator die Unternehmensdatenbank herunterfahren, ohne Benutzer in der östlichen Region zu beeinträchtigen.

Da an jedem Standort nur die relevanten Daten gespeichert werden, können Datenbanken kleiner sein. Beispiel: Benutzer in der östlichen Region können nur die östlichen Budgetinformationen replizieren, anstatt auf eine größere Unternehmensdatenbank zuzugreifen, die Budgetinformationen für alle Regionen enthält.

Nachteile replizierter Partitionen

Sie benötigen mehr Festplattenspeicher, da Daten an mehreren Stellen gespeichert werden.

Da der Partitionsadministrator Daten regelmäßig manuell aktualisieren muss, wird den Benutzern möglicherweise nicht die neueste Version der Daten angezeigt.

Überlegungen zur Performance für replizierte Partitionen

Um die Performance replizierter Partitionen zu verbessern, befolgen Sie die folgenden Richtlinien:

Replizieren Sie keine Elemente, die dynamisch im Quell-Cube berechnet werden, da Essbase die Modellstruktur prüfen muss, um dynamisch berechnete Elemente und deren untergeordnete Elemente zu ermitteln und zu bestimmen, wie die Berechnung ausgeführt werden soll.

Abgeleitete Daten aus dem Quell-Cube nicht replizieren. Replizieren Sie stattdessen die niedrigste praktische Ebene jeder Dimension, und führen Sie die Berechnungen für den Ziel-Cube aus, nachdem Sie die Replikation abgeschlossen haben.

Beispiel: So replizieren Sie die Datenbank entlang der Market-Dimension:

Definieren Sie den gemeinsamen Bereich als die Elemente der untersten Ebene der Market-Dimension, die Sie interessieren, z.B. Ost, West, Süd und Zentral und die Elemente der Ebene 0 der anderen Dimensionen.
Nachdem Sie die Replikation abgeschlossen haben, berechnen Sie die Werte für Market und die Werte der oberen Ebene in den anderen Dimensionen am Ziel.

Manchmal können abgeleitete Daten nicht im Ziel-Cube berechnet werden. In diesem Fall replizieren Sie ihn aus dem Quell-Cube. Sie können abgeleitete Daten an der Quelle nicht berechnen, wenn die Daten eines der folgenden Kriterien erfüllen:
- Erfordert die Berechnung von Daten außerhalb des replizierten Bereichs.
- Erfordert Berechnungsskripte, aus denen Sie nicht nur den Teil extrahieren können, der auf dem Ziel berechnet werden soll.
- Wird auf einem Computer mit wenig Rechenleistung repliziert, z. B. einem Laptop.

Um die Replikation eines Aggregate Storage-(ASO-)Cubes zu optimieren, der das replizierte Ziel ist, während eine Block Storage-Datenbank der Quell-Cube ist und die beiden Outlines identisch sind, verwenden Sie die Methode "Replikation nimmt identische Outlines an" auf eine der folgenden Arten.

Aktivieren Sie die Konfigurationseinstellung REPLICATIONASSUMEIDENTICALOUTLINE. Die Syntax lautet wie folgt:
```
REPLICATIONASSUMEIDENTICALOUTLINE [appname [dbname]] TRUE | FALSE
```
Setzen Sie die alter database MaxL-Anweisung mit der Grammatik replication_assume_identical_outline ab. Die Anweisung kann nur an einen ASO-Cube abgesetzt werden und gilt nicht für die Blockspeicherreplikation. Die Syntax lautet wie folgt:
```
alter database appname.dbname enable | disable replication_assume_identical_outline;
```

Die Partitionierung entlang einer dicht besetzten Dimension dauert länger als die Partitionierung entlang einer dünn besetzten Dimension. Wenn Essbase Daten repliziert, die entlang einer dicht besetzten Dimension partitioniert sind, muss es auf jeden Block in der Datenquelle zugreifen und dann während des Replikationsvorgangs jeden Block im Datenziel erstellen.

Sie können keine Daten in ein Element replizieren, das dynamisch im Ziel-Cube berechnet wird. Essbase lädt oder repliziert nicht in Dynamische Berechnung-Elemente, da diese Elemente erst Daten enthalten, wenn ein Benutzer sie zur Laufzeit anfordert. Essbase vermeidet das Senden replizierter Daten für dynamische dicht besetzte und dynamische dünn besetzte Elemente im Replikationsziel, da diese Daten nicht auf dem Ziel gespeichert werden.

Informationen zum Replizieren nur der Datenwerte, die statt der gesamten Partition geändert wurden, finden Sie unter Replizierte Partitionen auffüllen oder aktualisieren.

Replizierte Partitionen und Portnutzung

Bei replizierten Partitionen melden sich Benutzer nur beim Ziel-Cube an. Wenn Daten auf dem Ziel aktualisiert werden, verwendet der Prozess zum Replizieren von Daten aus dem Quell-Cube in den Ziel-Cube einen Port. Diese Verbindung basiert auf dem in der Partitionsdefinition deklarierten Benutzernamen (Partitionsbenutzer).

Hinweis:

Aufgrund der kurzfristigen Art der Replikation sind replizierte Partitionen und Ports selten ein Problem.