Transparente Partitions

Benutzer, die am Ziel-Cube arbeiten, müssen nicht wissen, wo die Daten gespeichert sind, da sie darauf zugreifen, als wären sie Teil ihres lokalen Cubes.

Abbildung 9-5 Transparente Partitionen

Diese Abbildung veranschaulicht, wie ein Benutzer im transparenten Partitionsdatenziel Daten aus drei Datenquellen sieht.

Da Daten direkt aus der Datenquelle abgerufen werden, greifen Benutzer auf die neueste Version zu. Wenn sie die Daten aktualisieren, werden ihre Aktualisierungen in die Datenquelle zurückgeschrieben. Dieser Prozess bedeutet, dass andere Benutzer der Datenquelle und des Datenziels sofortigen Zugriff auf diese Updates haben.

Mit einer transparenten Partition können Benutzer an der Datenquelle und am Datenziel eine langsamere Performance feststellen, da mehr Benutzer auf die Quelldaten zugreifen.

Beispiel: Der DBA bei TBC kann eine transparente Partition verwenden, um jedes Element der Scenario-Dimension auf einem separaten Computer zu berechnen. Dieser Prozess reduziert die Gesamtzeit für die Berechnung und bietet den Benutzern die gleiche Ansicht der Daten.

Verwenden Sie eine transparente Partition, um die folgenden Ziele zu erreichen:

Benutzern die neueste Version der Daten anzeigen
Benutzern im Datenziel erlauben, Daten zu aktualisieren
Speicherplatzbedarf minimieren

Wenn Sie eine transparente Partition erstellen, wird das Datensegment im Ziel-Cube auf #MISSING gelöscht, da die Daten voraussichtlich im Quell-Cube gespeichert werden. Sie wird auch dann gelöscht, wenn Sie die Partition löschen.

Regeln für transparente Partitionen

Transparente Partitionen müssen die folgenden Regeln erfüllen:

Die Daten werden im Quell-Cube gespeichert. Der Ziel-Cube speichert oder verwaltet keine Daten, sondern fungiert als Zugriffspunkt. Wenn der Schreibzugriff aktiviert ist, können Benutzer, die auf den Ziel-Cube zugreifen, Daten im Quell-Cube aktualisieren.
Wenn Quelle und Ziel beide Aggregate Storage-(ASO-)Cubes sind, wird die Datenzusammenführung vom Ziel-Cube zum Quell-Cube nicht unterstützt.
Die gemeinsam verwendeten transparenten Bereiche der Datenquellen- und Datenzielumrisse müssen nicht identisch sein. Sie müssen jedoch in der Lage sein, die darin enthaltenen Dimensionen zuzuordnen. Sie müssen Essbase mitteilen, wie jede Dimension und jedes Element in der Datenquelle jeder Dimension und jedem Element im Datenziel zugeordnet wird.
Die Outlines der Datenquelle und des Datenziels für die nicht gemeinsam verwendeten Bereiche müssen nicht zugeordnet werden können. Attributverknüpfungen müssen jedoch identisch sein. Andernfalls können Benutzer falsche Ergebnisse für einige Abrufe erhalten. Beispiel: Wenn das Produkt 100-10-1010 dem Attribut "Trape Flavor" auf der Quelle zugeordnet ist, das Produkt 100-10-1010 jedoch nicht dem Ziel "Trape" zugeordnet ist, ist der Gesamtumsatz für alle Traubenaromen in New York falsch.
Die Partitionsdefinition darf nur gespeicherte Elemente enthalten. Sie können Attribute-Dimensionen oder -Elemente nicht verwenden, um eine transparente Partition zu definieren. Beispiel: Die Attributdimension "Markttyp", die der Dimension "Markt" zugeordnet ist, enthält die Elemente "Urban", "Suburban" und "Rural". Sie können keine Partition für Urban, Suburban oder Rural definieren.
Wenn eine Zelle von der Datenquelle einer Aggregate Storage-Datenbank als Ziel zugeordnet wird, müssen alle abhängigen Zellen auch derselben Partitionsdefinition zugeordnet werden.
Sie können eine transparente Partition auf einer replizierten Partition erstellen. Mit anderen Worten, Sie können ein transparentes Partitionsziel mit einer replizierten Partitionsquelle erstellen, wie in dieser Abbildung dargestellt:

Abbildung 9-6: Gültige transparente Partition
Wie unten dargestellt, können Sie keine transparente Partition auf mehreren anderen Partitionen erstellen. Mit anderen Worten, Sie können kein transparentes Partitionsziel aus mehreren Quellen erstellen, da jede Zelle in einer Datenbank nur von einem Speicherort abgerufen werden muss – entweder von der lokalen Festplatte oder von einer Remote-Festplatte.

Abbildung 9-7 Ungültige transparente Partition
Berücksichtigen Sie sorgfältig alle Formeln, die Sie Elementen in der Datenquelle und im Datenziel zuweisen.

Vorteile von transparenten Partitionen

Transparente Partitionen können viele Datenbankprobleme lösen, aber transparente Partitionen sind nicht immer der ideale Partitionstyp.

Sie benötigen weniger Speicherplatz, da Sie die Daten in einer Datenbank speichern.

Die Daten, auf die über das Datenziel zugegriffen wird, sind immer die neueste Version.

Wenn der Benutzer die Daten in der Datenquelle aktualisiert, nimmt Essbase diese Änderungen am Datenziel vor.

Einzelne Datenbanken sind kleiner, so dass sie schneller berechnet werden können.

Die Verteilung der Daten ist für den Endbenutzer und die Tools des Endbenutzers unsichtbar.

Sie können die Daten entweder aus der Datenquelle oder aus dem Datenziel laden.

Nachteile von transparenten Partitionen

Wenn die folgenden Nachteile zu schwerwiegend sind, sollten Sie stattdessen replizierte oder föderierte Partitionen verwenden.

Transparente Partitionen erhöhen die Netzwerkaktivität, was zu langsameren Abrufzeiten für Benutzer führt.

Da mehr Benutzer auf die Quelldaten zugreifen, kann die Abrufzeit langsamer sein.

Wenn der Quell-Cube ausfällt, sind Benutzer sowohl an der Quelle als auch am Ziel betroffen. Daher müssen das Netzwerk und der Quell-Cube verfügbar sein, wenn Benutzer, die mit der Quelle oder dem Ziel verbunden sind, sie benötigen.

Einige administrative Vorgänge können nur für lokale Daten ausgeführt werden. Beispiel: Wenn Sie den Ziel-Cube archivieren, archiviert Essbase nur das Ziel und nicht den Quell-Cube. Die folgenden administrativen Vorgänge funktionieren nur für lokale Daten in Blockspeicherdatenbanken:

CLEARDATA-Berechnungsbefehl
DATACOPY-Berechnungsbefehl
EXPORT-Befehl
VALIDATE-Befehl
Befehle BEGINARCHIVE und ENDARCHIVE

Wenn Sie eine Berechnung für eine transparente Partition durchführen, führt Essbase die Berechnung anhand der aktuellen Werte der lokalen Daten und transparenter abhängiger Elemente aus. Essbase berechnet die transparenten abhängigen Elemente nicht neu, da die Outlines für die Quelle und das Ziel möglicherweise so unterschiedlich sind, dass eine solche Berechnung nicht korrekt ist. Um alle Partitionen zu berechnen, geben Sie einen CALC ALL-Befehl für jede einzelne Partition aus, und führen Sie dann einen CALC ALL-Befehl auf der obersten Ebene aus. Verwenden Sie dazu die neuen Werte.

Beispiel:

Die Gliederung des Zielwürfels enthält eine Market-Dimension mit East-, West-, South- und Central-Elementen
Die Gliederung des Quell-Cubes enthält eine East-Dimension mit New York- und New Jersey-Elementen

Wenn Sie versucht haben, den Ziel-Cube zu berechnen, gehen Sie davon aus, dass East ein Element der Ebene 0 war. Im Quellwürfel wird East jedoch durch Hinzufügen von New York und New Jersey abgeleitet. Alle Berechnungen am Ziel würden diese Informationen jedoch nicht kennen und die Änderungen an New York und New Jersey in der Quelle nicht widerspiegeln. Um eine genaue Berechnung durchzuführen, berechnen Sie daher "Ost" in der Quelle und berechnen dann das Ziel.

Formeln, die Elementen im Quell-Cube zugewiesen sind, können zu berechneten Ergebnissen führen, die nicht mit Formeln oder Konsolidierungen übereinstimmen, die im Ziel-Cube definiert sind, und umgekehrt.

Überlegungen zur Performance für transparente Partitionen

Um die Performance transparenter Partitionen zu verbessern, sollten Sie beim Erstellen der Partition die folgenden Richtlinien beachten:

Die Partitionierung entlang dicht besetzter Dimensionen kann die Performance erheblich verlangsamen, da mit dicht besetzten Dimensionen die Struktur und der Inhalt von Datenblöcken bestimmt werden.

Um die Performance zu verbessern, sollten Sie eine oder mehrere dünn besetzte Dimensionen in die Bereichsdefinition aufnehmen, sodass die Anzahl der erforderlichen Blöcke auf Kombinationen mit den dünn besetzten Elementen begrenzt ist.
Wenn transparente Partitionen auf den Attributwerten einer Dimension basieren, kann dies die Abrufzeit erhöhen, da Attribute mit dünn besetzten Dimensionen verknüpft sind. In solchen Fällen verbessert die Partitionierung auf einer Ebene, die höher ist als die Ebene, die mit Attributen verknüpft ist, die Abrufzeit. Beispiel: Wenn in der Produktdimension der Sample.Basic-Datenbank untergeordnete Elemente 100-10, 200-10 und 300-10 (Ebene 0) mit Attributen verknüpft sind, partitionieren Sie die übergeordneten Elemente 100, 200 und 300 (Ebene 1) für eine bessere Abrufperformance.
Das Laden von Daten aus dem Ziel-Cube in den Quell-Cube kann die Performance erheblich verlangsamen. Wenn möglich laden Sie Daten lokal in die Datenquelle.
Die Abrufzeit ist langsamer, da Benutzer über das Netzwerk auf die Daten zugreifen.
Wenn eine transparente Partition das Ziel ist, sollten Sie die folgenden Konfigurationseinstellungen verwenden:
- Bei Anforderungen, die von einem Quell-Cube an einen transparenten Partitionsziel-Cube gesendet werden, können Sie Transaktionsantwortzeiten mit der Konfigurationseinstellung ENABLE_DIAG_TRANSPARENT_PARTITION protokollieren. Das Protokollieren dieser Nachrichten ist hilfreich, wenn Sie zu langsame Antwortzeiten beheben.
- Wenn das transparente Partitionsziel ein Aggregate Storage-(ASO-)Cube ist, können Sie die maximale Größe des Anforderungsrasters und des Antwortrasters mit den Konfigurationseinstellungen MAX_REQUEST_GRID_SIZE und MAX_RESPONSE_GRID_SIZE angeben.
Die Partitionierung der Basisdimensionen kann die Performance erheblich verlangsamen.

Berechnung von transparenten Partitionen

Bei der Berechnung lokaler Daten, die von Remote-Daten abhängen, muss Essbase die Bottom-up-Berechnung verwenden. Stellen Sie sicher, dass Sie einen optimierten Rechnercache im Ziel-Cube verwenden. Lesen Sie dazu Size the Calculator Cache.

Wenn Sie eine Berechnung für eine transparente Partition durchführen, führt Essbase die Berechnung anhand der aktuellen Werte der lokalen Daten und transparenter abhängiger Elemente aus. Bei der Berechnung lokaler Daten, die von Remote-Daten abhängen, führt Essbase eine Bottom-up-Berechnung aus. Die Bottom-up-Berechnung kann nur durchgeführt werden, wenn der Rechnercache in der Zieldatenbank ordnungsgemäß verwendet wird. Siehe Bottom-Up- und Top-Down-Berechnung.

Die Erhöhung des dem Rechnercache zugewiesenen Speichers verbessert die Rechenleistung durch transparente Partitionen erheblich. Wenn eine Berechnung gestartet wird, gibt eine Meldung in der Anwendungslogdatei an, ob der Rechnercache in der Zieldatenbank aktiviert oder deaktiviert ist. Wenn Sie den Rechnercache in der Zieldatenbank verwenden, wird die Anzahl der Blöcke reduziert, die während der Berechnung von der Datenquelle angefordert werden. Die Reduzierung der angeforderten Blöcke wiederum reduziert den Netzwerkverkehr, der durch die Übertragung von Blöcken über das Netzwerk generiert wird.

Performance der transparenten Partitionsberechnung

Die Berechnung von Daten auf dem Ziel einer transparenten Partition kann die Performance verlangsamen, wenn Essbase vor der Berechnung abhängige Blöcke im gesamten Netzwerk aus der Quelle abrufen muss. Um transparente Berechnungen zu optimieren, verwenden Sie Dynamische Berechnung, verwalten den Rechnercache, vermeiden Top-Down-Formeln und vermeiden komplexe Formeln für flächendefinierende Elemente.

Die Performance mit transparenten Berechnungen kann sich auch verlangsamen, wenn Essbase eine Top-down-Berechnung für jeden Teil des Datenziels ausführen muss, der Top-down-Elementformeln enthält. Wenn das Datenziel keine Top-down-Elementformeln enthält, kann Essbase eine Bottom-up-Berechnung für das Datenziel ausführen, was viel schneller ist.

Wenn Essbase die Berechnung für den Quell-Cube ausführt, kann es immer eine Bottom-up-Berechnung ausführen.

Verwenden Sie die folgenden Berechnungsalternativen:

Wenn Sie absolut sicher sind, dass ein Berechnungsskript für die Zielpartition keinen Zugriff auf Remotedaten beinhaltet, können Sie den Berechnungsbefehl SET REMOTECALC OFF im Berechnungsskript verwenden, um den Abruf von Daten aus der Quellpartition zu stoppen.
Implementieren Sie Dynamic Calc-Elemente als übergeordnete Elemente der transparenten Daten, sodass die Daten beim Abruf sofort berechnet werden. Dieser Prozess verkürzt die Batch-Verarbeitungszeit. Essbase führt die Berechnung nur aus, wenn Benutzer sie anfordern.
Implementieren Sie eine replizierte Schicht zwischen den transparenten Daten auf niedriger Ebene und den lokalen Daten auf hoher Ebene.

Berücksichtigen Sie folgende Performance-Strategien:

Behalten Sie die Partition vollständig im Rechnercachebereich bei, was bedeutet, dass alle dünn besetzten Elemente in der Partitionsdefinition im Rechnercache enthalten sein müssen. Beispiel: Wenn im Beispiel-Basic-Cube eine Partitionsdefinition @IDESC(East) enthält, müssen sich alle Nachkommen von East im Rechnercache befinden.
Aktivieren Sie den Rechnercache, und weisen Sie ihm ausreichend Speicher zu.
Verwenden Sie keine komplexen Formeln für Elemente, die eine Partition definieren. Beispiel: Durch die Zuweisung einer komplexen Formel zu New York oder New Jersey (beide untergeordnete Elemente von East) wird Essbase gezwungen, die Top-down-Berechnungsmethode zu verwenden.

Transparente Partitionen und Elementformeln

Wenn die Outlines des Datenziels und der Datenquelle mit Ausnahme verschiedener Elementformeln identisch sind, stellen Sie sicher, dass die Partitionsdefinition die gewünschten Berechnungsergebnisse liefert.

Beispiel: Die Umrisse der Datenquelle und des Datenziels enthalten sowohl eine Market-Dimension mit Nord- und Süd-Elementen als auch untergeordnete Elemente von Nord und Süd. Auf dem Datenziel wird Market aus den Daten für die Mitglieder des Nordens und des Südens (und deren Kinder) in der Datenquelle berechnet. Wenn eines dieser Elemente in der Datenquelle Elementformeln enthält, werden diese Formeln berechnet, was sich auf den berechneten Wert von "Markt" im Datenziel auswirkt. Diese Ergebnisse können sich von der Art und Weise unterscheiden, wie das Market-Mitglied von den North- und South-Elementen auf dem Datenziel berechnet wird, wobei diese Formeln möglicherweise nicht vorhanden sind.

Stellen Sie sicher, dass alle Formeln, die Sie Elementen in der Datenquelle und im Datenziel zuweisen, die gewünschten Ergebnisse liefern.

Transparente Partitionen und Portnutzung

Ein Port wird für jede einzigartige Kombination aus Benutzer und Maschine verwendet. Wenn ein Benutzer mehrere transparente Partitionen auf einem Server mit demselben Benutzernamen definiert, wird nur ein Port belegt.

Wenn ein Benutzer (user1) in einer transparenten Partition einen Drilldown in einen Bereich im Ziel durchführt, der auf Quelldaten zugreift, verwendet user1 den in der Partitionsdefinition deklarierten Benutzernamen (Partitionsbenutzer), um auf die Daten aus der Quelldatenbank zuzugreifen. Durch diesen Zugriff wird ein zusätzlicher Port verwendet, da sich verschiedene Benutzer (user1 und partition user) bei der Anwendung anmelden.

Wenn sich ein zweiter Benutzer (user2) bei der Zieldatenbank anmeldet und einen Drilldown für den Zugriff auf Quelldaten durchführt, verwendet user2 auch den in der Partitionsdefinition deklarierten Benutzernamen (Partitionsbenutzer). Da der Partitionsbenutzer bereits bei der Quelldatenbank angemeldet ist, ist für den Partitionsbenutzer kein zusätzlicher Port erforderlich, solange user2 auf dieselbe Quelldatenbank zugreift.