Hybridmodus für schnelle Analyseverarbeitung

Mit dem Oracle Essbase-Berechnungs- und -Abfrageprozessor im Hybridmodus können Sie Echtzeitanalysen durchführen und dabei prozedurale Berechnungen sowie Lese- und Schreibmodellierung verwenden. Der Hybridmodus ist die Standard-Engine für die dynamische Abhängigkeitsanalyse für Block-Storage-Abfragen. Er ist nicht die Standardeinstellung für Berechnungsskripte (Sie können ihn aktivieren).

Wenn Sie bereits mit Essbase 11g On-Premise gearbeitet haben, sind Sie wahrscheinlich mit einem oder mehreren dieser Cube-Designmodi vertraut, die auf bestimmte Zwecke zugeschnitten sind:

Block Storage: Am besten für große Sparse-Dimensionen geeignet. Cubes in diesem Modus werden gespeichert und vorab aggregiert, um eine gute Abfrageperformance zu erzielen. Umfasst zahlreiche Berechnungsfunktionen für Analysen.
Aggregate Storage: Am besten für Cubes mit einer großen Anzahl von Dimensionen und vielen Aggregationen der oberen Ebene geeignet. Elementformeln können mit MDX angegeben werden.
Hybridmodus: Block Storage-Modus mit den zusätzlichen Vorteilen von Aggregate Storage.

Hybridmodus ist die Standardabfrage-Engine für dynamische Abhängigkeitsanalysen für Abfragen von Block Storage Cubes in Essbase 21c und Essbase 19c. Hybridmodus bietet eine zuverlässige Abhängigkeitsanalyse und schnelle Aggregation. Er kann die Komplexität des Abfragens von Elementen mit Abhängigkeiten in dynamischen Elementen hervorragend bewältigen.

Oracle empfiehlt, in analytischen Anwendungen dynamische Abhängigkeiten, einschließlich Sparse-Aggregationen, zu verwenden. Sie sind nicht darauf beschränkt, dynamische Berechnungen selektiv in Sparse-Dimensionen zu implementieren, wie es bei Essbase 11g On-Premise der Fall war. Insbesondere sind dynamische Sparse-Aggregationen gemäß den Richtlinien und Tests zur Performanceoptimierung möglich und empfehlenswert.

Obwohl der Hybridmodus der Standardabfrageprozessor für Block Storage Cubes ist, wird er nicht standardmäßig für die Ausführung von Berechnungsskripten verwendet. Wenn Ihre Berechnungsskripte viele dynamische Abhängigkeiten enthalten, empfiehlt Oracle, dass Sie den Hybridmodus auch für Berechnungsskripte aktivieren. Hierzu aktivieren Sie die Konfigurationseinstellung HYBRIDBSOINCALCSCRIPT in Ihren Anwendungskonfigurationseinstellungen (oder verwenden sie den Berechnungsbefehl SET HYBRIDBSOINCALCSCRIPT, um die Einstellung pro Berechnung zu aktivieren).

Die meisten Essbase-Berechnungsfunktionen werden im Hybridmodus ausgeführt. Eine Liste und Die Syntax für alle Hybridmodus unterstützten Berechnungsfunktionen sowie die wenigen Ausnahmen finden Sie unter Im Hybridmodus unterstützte Funktionen. Parallele Berechnungen mit FIXPARALLEL werden im Hybridmodus unterstützt, Parallele Berechnungen mit CALCPARALLEL jedoch nicht.

Eine Informationen zur Syntax zum Konfigurieren desHybridmodus über die Standardeinstellungen hinaus finden Sie unter ASODYNAMICAGGINBSO oder zum Deaktivieren.

Themen in diesem Abschnitt:

Vorteile des Hybridmodus

Mit Essbase-Cubes im Hybridmodus profitieren Sie von schneller Aggregation selbst bei Sparse-Dimensionen, kleineren Cube-Größen, optimiertem Arbeitsspeicherbedarf, flexiblen Batchberechnungen und robusten Formelabhängigkeitsanalysen.

Der Hybridmodus ist eine Kombination aus der prozeduralen Berechnungs- und Writeback-Funktionalität von Block Storage (BSO) und der Aggregationsperformance von Aggregate Storage (ASO). Der Hybridmodus bietet den Vorteil einer schnellen Performance, ohne dass Sparse-Aggregationen gespeichert werden müssen. Dadurch werden wiederum die Datenbankgröße und der Speicher-Footprint reduziert, während die Batchberechnungszeiten beschleunigt werden. Die Überlegungen beim Deployment werden vereinfacht, weil Sie nicht mehr überlegen müssen, ob Sie bei einem vermehrten Einsatz von Berechnungen auf Ebene 0 Block Storage und bei Verwendung vieler Aggregationen der oberen Ebene Aggregate Storage verwenden sollen. Außerdem müssen Sie nicht abwägen, ob Sie partitionierte Modelle entwerfen sollen, bei denen der Cube entlang der dimensionalen Linien geteilt wird, um eine bessere Berechnungsperformance zu erreichen.

Nachfolgend finden Sie einige Szenarios, bei denen mit dem Hybridmodus die Berechnungsperformance wahrscheinlich verbessert wird:

Eine Block Storage-Datenbank enthält Sparse-Elemente, die nicht zur Ebene 0 gehören und entsprechend der Hierarchie (statt mit Berechnungsskripten) berechnet werden.
Ein übergeordnetes Sparse-Element für die dynamische Berechnung enthält mehr als 100 untergeordnete Elemente.
Sie verwenden eine transparente Partition zwischen einem leeren Aggregate-Storage-Ziel und einer Block Storage-Quelle. Wenn die Formeln für das Aggregate-Storage-Ziel einfach und in Block Storage-Formelsprache übersetzbar sind, können Sie mit dem Hybridmodus schnelle Ergebnisse für Block Storage erzielen.
Sie verwenden eine transparente Partition zwischen zwei Block Storage-Datenbanken, und die Berechnungsperformance ist ein wichtiger Aspekt.

Ein weiterer Vorteil des Hybridmodus ist, dass keine Abhängigkeit von der Reihenfolge der Modellstruktur besteht. Sie können die Lösungsreihenfolge ganz einfach anpassen, anstatt die Dimensionsreihenfolge neu anzuordnen.

Im Hybridmodus können Sie auch das Szenariomanagement verwenden, um hypothetische Daten mit einem Workflowformat zu testen und zu modellieren, ohne Speicheranforderungen hinzuzufügen.

Hybridmodus, Block Storage und Aggregate Storage - Vergleich

Ohne Hybridmodus unterliegt der Block-Storage-Algorithmus für dynamische Berechnungselemente Einschränkungen, wenn er mit großen Sparse-Dimensionen verwendet wird. Der Hybridmodus (und Aggregate Storage) sind eher für dynamische Abhängigkeitsanalysen optimiert. Nachfolgend finden Sie Informationen zu den Hauptunterschieden, die Ihnen bei der Wahl des besten Abfrageprozessortyps für eine Essbase -Anwendung helfen können.

Ohne den Hybridmodus müssen große Sparse-Dimensionen in Block Storage-Datenbanken gespeichert werden. Wenn sie als dynamisch markiert werden, entsteht zur Abfrage- oder Berechnungszeit zu viel Block-I/O, und die Performance wird dadurch beeinträchtigt. Sehr große gespeicherte Sparse-Dimensionen können zu langwierigen Batchaggregationszeiten sowie großen Datenbanken führen, deren Größe proportional zu Anzahl und Größe der Sparse-Dimensionen zunimmt. Trotz dieser Nachteile wird Block Storage aufgrund seiner leistungsstarken Funktionen häufig eingesetzt.

Aggregate Storage wurde speziell für große Datenbanken mit mehr und größeren Dimensionen entwickelt. Im Gegensatz zu Block Storage müssen große Sparse-Dimensionen nicht vorab aggregiert werden, um eine gute Abfrageperformance zu erzielen. Der Grund hierfür ist der Aggregate-Storage-Datenbankkernel, der eine schnelle dynamische Aggregation bei großer Dimensionalität ermöglicht.

Trotz aller Vorzüge, die Aggregate Storage bietet, gibt es viele Anwendungen, für die Block Storage besser geeignet ist. Dazu zählen die Fähigkeit, Daten mit beliebiger Granularität zu laden, die häufige Ausführung komplexer Batchzuordnungen oder die Implementierung von Währungsumrechnungen für globale Finanzanwendungen. In solchen und vielen weiteren Fällen kann der Hybridmodus eine gute Lösung sein. Der Hybridmodus ist eine Kombination aus den besten Features von Block Storage und Aggregate Storage. Im Hybridmodus bietet Essbase folgende Vorteile:

Vollständige prozedurale Berechnungsflexibilität, auch wenn für die Berechnungen dynamische Sparse-Aggregationen erforderlich sind.
Für Abfragen, die auf dynamische Sparse-Elemente zugreifen, wird die Hybrid-Engine verwendet. Für den kleinen Prozentsatz von Abfragen, die nicht auf diese Weise verarbeitet werden können, verwendet Essbase den Block Storage-Berechnungsablauf zur Erfüllung der Anforderung.
Wenn Sie Sparse-Elemente als dynamisch markieren:
- müssen diese Elemente nicht vorab aggregiert werden
- wird die Performance bei Neustrukturierung verbessert
- wird die Backupperformance verbessert
- werden die Speicherplatzanforderungen gesenkt
Da der Hybridmodus dynamische Berechnungen erfordert, können Sie die Sequenz der Berechnungen mithilfe der Reihenfolge festlegen.

Hinweis:

Hybride Berechnungen werden, unabhängig davon, ob sie auf Abfragen oder Berechnungsskripten basieren, im temporären Speicher ausgeführt. Dabei werden ein Formelcache und der Aggregate-Storage-Cache verwendet.

Hauptunterschiede

Die folgenden Hauptunterschiede können Ihnen bei der Wahl des besten Abfrageprozessortyps für Ihre Anwendung helfen.

Anforderung	Aggregate Storage (ASO)	Block Storage (BSO)	Hybridmodus
Für schnelle Aggregation in vielen Sparse-Dimensionen optimiert	Ja	Nr.	Ja
Für minimale Nutzung des Datenträgerspeicherplatzes und geringere Backupzeit optimiert	Ja	Nr.	Ja
Für Finanzanwendungen optimiert	Nr.	Ja	Ja
Möglichkeit, Zuordnungen vorzunehmen	Ja	Ja	Ja
Möglichkeit, Batchberechnungen auszuführen	Nr.	Ja	Ja
Elementformeln werden unterstützt	Ja, ausgedrückt als MDX	Ja, ausgedrückt als Essbase-Berechnungsfunktionen	Ja, ausgedrückt als Essbase-Berechnungsfunktionen
Für Vorwärtsreferenzen in Elementformeln optimiert	Nr.	Nr.	Ja
Möglichkeit, Lösungsreihenfolge von Berechnungen/Aggregationen anzupassen	Ja	Nr.	Ja Lösungsreihenfolge im Hybridmodus
Möglichkeit, Bottom-up-Abfrageausführung für schnellere Abhängigkeitsanalysen kleinerer Eingabe-Datasets anzugeben	Nr.	Nr.	Ja Konfigurationseinstellung QUERYBOTTOMUP Berechnungsfunktion @QUERYBOTTOMUP
Möglichkeit, Abfrageausführung zu verfolgen und zu debuggen	Ja QUERYTRACE	Nr.	Ja QUERYTRACE
Möglichkeit, die für eine Abfrage zulässige Speichernutzung zu beschränken	Ja MAXFORMULACACHESIZE	Nr.	Ja MAXFORMULACACHESIZE
Unterstützung für zweistufige Berechnung	Nr.	Ja	Nr.
Möglichkeit, Daten auf allen Ebenen zu laden	Nein. Es können nur Zellen der Ebene 0 ohne Formelabhängigkeiten geladen werden	Ja	Für gespeicherte Ebenen: Ja Nicht für dynamische Ebenen
Möglichkeit, Daten inkrementell mit Puffern zu laden	Ja	Nr.	Nr.
Auswertung von Formeln in Sparse-Dimensionen kann unterschiedliche Ergebnisse ergeben als die Auswertung derselben Formeln in Dense-Dimensionen	N/V	Ja. In Block Storage ohne Hybridmodus können Essbase-Berechnungsskripte iterativ geschrieben werden, um Abhängigkeiten zu Sparse-Blöcken aufzulösen. Wenn Sie den Dimensionstyp von "Sparse" in "Dense" oder umgekehrt ändern, können Sie unterschiedliche Ergebnisse für dieselben Formeln erhalten.	Nein. Formelabhängigkeiten werden auf dieselbe Art berechnet, ohne Berücksichtigung, wie dicht oder dünn die Dimensionen besetzt sind. Im Hybridmodus verwendet Essbase einen Algorithmus zum Auflösen dynamischer Abhängigkeiten. In einigen Fällen können sich die von einem Berechnungsskript abgeleiteten Daten im Hybridmodus von den Block-Storage-Daten ohne Hybridmodus unterscheiden.

Erste Schritte mit dem Hybridmodus

Um mit der Ausführung Ihrer Essbase-Anwendungen im Hybridmodus zu beginnen, beginnen Sie in einer Testumgebung, machen große, dünn besetzte Dimensionen dynamisch, und studieren Sie das Anwendungslog.

Um die ersten Schritte mit dem Hybridmodus auszuführen, beachten Sie die folgenden Richtlinien:

Richten Sie eine Entwicklungsumgebung ein, und migrieren Sie vorhandene Block Storage-Anwendungen in diese Umgebung. Hybridmodus ist für Block Storage Cubes standardmäßig aktiviert.
Markieren Sie größere Sparse-Dimensionen nach Möglichkeit als dynamisch.
Führen Sie Testabfragen aus, und prüfen Sie das Anwendungslog, bevor und nachdem Sie Hybridmodus aktivieren. So kann festgestellt werden, in welchem Umfang der Aggregate-Storage-Abfrageprozessor verwendet wurde und welche Vorteile durch den Hybridmodus entstanden sind. Für jede Abfrage gibt das Anwendungslog Hybrid aggregation mode enabled oder Hybrid aggregation mode disabled. an.
Wenn zu viele Abfragen mit deaktiviertem Hybridmodus protokolliert werden, wenden Sie sich an Oracle Support.

Cube für Hybridmodus optimieren

So setzen Sie den Hybridmodus am effektivsten ein:

Vermeiden Sie die Verwendung der zweistufigen Berechnung im Hybridmodus. Verwenden Sie stattdessen Bestellung auflösen.
Konvertieren Sie nach Möglichkeit gespeicherte Elemente, die nicht zur Ebene 0 gehören, in dynamische Berechnungselemente.
Wenn die Konvertierung in dynamische Berechnungselemente die Lösungsreihenfolge für abhängige Formeln beeinflusst, müssen Sie möglicherweise die Reihenfolge der Dimensionen in der Modellstruktur anpassen, damit die Lösungsreihenfolge mit der vorherigen Batchberechnungsreihenfolge und den Einstellungen der zweistufigen Berechnung übereinstimmt.

Die Standardlösungsreihenfolge für Hybridmodus-Cubes ähnelt der Berechnungsreihenfolge von Block Storage Cubes, mit einigen Verbesserungen. Wenn Sie nicht die Standardlösungsreihenfolge verwenden möchten, können Sie eine benutzerdefinierte Lösungsreihenfolge für Dimensionen und Elemente festlegen.
Eine dynamisch berechnete Formel, die in der falschen Lösungsreihenfolge verarbeitet wird, kann dazu führen, dass zu viele Formeln von einer Abfrage ausgeführt werden, sodass die Performance leidet. Eine dynamisch berechnete Sparse-Formel sollte nach Möglichkeit einen höheren Lösungsrang als hierarchisch aggregierte Sparse-Dimensionen haben.

In einigen Anwendungen ist das nicht möglich, da eine andere Lösungsreihenfolge erforderlich ist, um die richtigen Formelergebnisse abzurufen. Beispiel: Bei einer Anwendung mit Einheiten und Preisen muss ein Verkaufswert vor den Sparse-Aggregationen ausgeführt werden, um die richtigen Verkaufswerte auf oberen Ebenen abzurufen.
Unter Umständen müssen Sie die Dense- und Sparse-Konfigurationen der Dimensionen anpassen (gilt nur bei Verwendung der Block Storage Engine in Fällen, in denen die Hybrid-Engine nicht verwendet werden kann).
Minimieren Sie die Größe der Blöcke, falls möglich.

Essbase-Administratoren können die Abfrageperformance im Hybridmodus mit den folgenden Tools überwachen und optimieren:

Mit den Konfigurationseinstellungen MAXFORMULACACHESIZE können Sie begrenzen, wie viel Arbeitsspeicher von einer einzelnen Abfrage belegt werden kann.
Wenn der Cube komplexe Elementformeln mit dimensionsübergreifenden Operatoren und mehreren IF/ELSE-Anweisungen umfasst, können Performanceprobleme mit der Formelausführung in Zusammenhang stehen. Wenn Sie denken, dass dies der Fall ist, können Sie die Bottom-up-Abfrageverarbeitung für die Berechnung der Formel aktivieren. Dadurch werden die Abfragezeiten optimiert, indem die erforderlichen Schnittmengen für die Berechnung identifiziert werden. So wird die Abfragezeit proportional zur Größe der Eingabedaten.

Um diese Abfrageoptimierungen für Release 21C vorzunehmen, verwenden Sie die Konfigurationseinstellung QUERYBOTTOMUP und die Berechnungsfunktion @QUERYBOTTOMUP. Für Release 19C verwenden Sie die Konfigurationseinstellung IGNORECONSTANTS mit BOTTOMUP-Syntax und die Berechnungsfunktion @NONEMPTYTUPLE.
Verwenden Sie das Abfragetracing, um die Abfrageperformance zu überwachen und zu debuggen. Je nach Anwendungsfall stehen mehrere Konfigurationseinstellungen auf Anwendungsebene zur Verfügung. Verwenden Sie QUERYTRACE für kurzfristiges Debugging einer einzelnen Abfrage, die Ihnen problematisch erscheint. Verwenden Sie TRACE_REPORT, um Statistiken zu nebenläufig ausgeführten Abfragen (ideal für das Debugging in einer Entwicklungsumgebung) zu erfassen. Verwenden Sie LONGQUERYTIMETHRESHOLD in Produktionsumgebungen, um Statistiken über Abfragen, die länger als eine festgelegte Zeit ausgeführt werden, in die Anwendungslogdatei auszugeben.

Einschränkungen und Ausnahmen für den Hybridmodus

In manchen Fällen kann eine Abfrage im Hybridmodus möglicherweise nicht optimal ausgeführt werden. Essbase erkennt das Vorliegen dieser Bedingungen und aggregiert sie im Block Storage-Modus. Wenn in einer Abfrage sowohl im Hybridmodus unterstützte als auch nicht unterstützte Berechnungstypen vorhanden sind, wird in Essbase standardmäßig die Block Storage-Berechnung ausgeführt.

Wenn der Hybridmodus aktiviert ist, gilt er für Elementformeln mit unterstützten Funktionen. Eine Liste der unterstützten und nicht unterstützten Funktionen finden Sie unter Im Hybridmodus unterstützte Funktionen.

Die folgenden Abfragetypen werden im Hybridmodus nicht ausgeführt:

Dynamische Berechnungselemente mit Formeln, die ein Ziel transparenter Partitionen sind
Abfragen, bei denen das gemeinsame Element außerhalb der Zielpartitionsdefinition liegt und das zugehörige Prototypelement innerhalb der Zielpartitionsdefinition liegt, oder umgekehrt
XOLAP
Textkennzahlen/Textlisten

Attributberechnungen werden nur für Summen im Hybridmodus ausgeführt.

Wenn abhängige Elemente eine höhere Auflösungsreihenfolge als das Formelelement aufweisen, wird folgende Warnung angezeigt:

Solve order conflict - dependent member member_name with higher solve order will not contribute value for formula of member_name

Lösungsreihenfolge im Hybridmodus

Die Lösungsreihenfolge in Essbase bestimmt die Reihenfolge, in der die dynamische Berechnung im Hybridmodus ausgeführt wird. Sie können die Lösungsreihenfolge anpassen oder die Standardeinstellung akzeptieren, die für hohe Performance und Abhängigkeitsanalysen optimiert ist.

Das Konzept der Lösungsreihenfolge wird bei der Ausführung dynamischer Berechnungen angewendet, unabhängig davon, ob sie durch eine dynamische Elementformel oder eine dynamische Abhängigkeit in einem Berechnungsskript initiiert wurden. Wenn eine Zelle in einer mehrdimensionalen Abfrage ausgewertet wird, ist die Reihenfolge, in der die Berechnungen aufgelöst werden sollen, möglicherweise nicht eindeutig, es sei denn, die erforderliche Berechnungspriorität ist über eine Lösungsreihenfolge angegeben.

Sie können die Lösungsreihenfolge für Dimensionen oder Elemente festlegen oder die Essbase-Standardlösungsreihenfolge verwenden. Sie können für die Lösungsreihenfolge ein Minimum von 0 und ein Maximum von 127 festlegen. Eine höhere Lösungsreihenfolge bedeutet, dass das Element später berechnet wird. Beispiel: Ein Element mit der Lösungsreihenfolge 1 wird vor einem Element mit der Lösungsreihenfolge 2 berechnet.

Wenn der Hybridmodus aktiviert ist, entspricht die Standardlösungsreihenfolge (auch als Berechnungsreihenfolge bezeichnet) am ehesten der von Block Storage-Datenbanken:

Dimensions-/Elementtyp	Standard-Lösungsreihenfolgenwert
Gespeicherte Elemente	0
Sparse-Dimensionselemente	10
Dense Account-Dimensionselemente	30
Dense Time-Dimensionselemente	40
Dense Regular-Dimensionselemente	50
Attribute-Dimensionselemente	90
Zweistufige dynamische Elemente	100
Berechnete MDX-Elemente oder benannte Sets (in MDX mit definiert)	120

Zusammenfassend schreibt die Standardlösungsreihenfolge im Hybridmodus vor, dass gespeicherte Elemente vor dynamischen Berechnungselementen und Sparse-Dimensionen vor Dense-Dimensionen berechnet werden, und zwar in der Reihenfolge, in der sie in der Modellstruktur aufgeführt sind (von oben nach unten).

Dynamische Elemente (mit oder ohne Formeln), für die keine Lösungsreihenfolge angegeben ist, erben die Lösungsreihenfolge der zugehörigen Dimension, sofern sie nicht als zweistufig getaggt sind.

Zweistufige Berechnung ist eine Einstellung, die Sie im Block Storage-Modus auf Elemente mit Formeln anwenden können, die zweimal berechnet werden müssen, damit sie den korrekten Wert ergeben.

Hinweis:

Verwenden Sie keine zweistufige Berechnung mit Hybridmodus-Cubes. Verwenden Sie nur Bestellung auflösen.

Die zweistufige Berechnung kann im Hybridmodus nicht angewendet werden. Elemente, die als zweistufig getaggt sind, werden zuletzt berechnet, nach den Attributen. Im Hybridmodus müssen Sie eine benutzerdefinierte Lösungsreihenfolge statt der zweistufigen Berechnung implementieren, wenn die Standardlösungsreihenfolge nicht Ihren Anforderungen entspricht.

Die Standlösungsreihenfolge im Hybridmodus ist für die folgenden Szenarios optimiert:

Vorwärtsreferenzen, in denen eine dynamische Elementformel ein Element referenziert, das in der Reihenfolge der Modellstruktur später aufgeführt ist. Im Hybridmodus besteht keine Abhängigkeit von der Reihenfolge der Modellstruktur.
Die Aggregation von untergeordneten Werten basierend auf der Reihenfolge der Modellstruktur stimmt am ehesten mit der Aggregation mithilfe von äquivalenten Formeln überein.
Dynamische Dense-Elemente als Abhängigkeiten in Sparse-Formeln. Wenn eine Sparse-Formel im Hybridmodus ein dynamisches Dense-Element referenziert, wird die Referenz ignoriert, weil Sparse-Dimensionen zuerst berechnet werden. Um das zu ändern, weisen Sie der Sparse-Dimension einen höheren Lösungsreihenfolgenwert zu (sodass sie später berechnet wird) als der Dense-Dimension.

Lösungsreihenfolge anpassen

Wenn Sie das Verhalten der dynamischen Berechnungen im Hybridmodus anpassen müssen, können Sie dazu die Lösungsreihenfolge von Dimensionen und Elementen anpassen, ohne große Änderungen an der Modellstruktur vornehmen zu müssen.

Wenn Sie eine benutzerdefinierte Lösungsreihenfolge implementieren, wird dadurch die Standardlösungsreihenfolge außer Kraft gesetzt. Wenn Elemente oder Dimensionen die gleiche Lösungsreihenfolge aufweisen, wird der Konflikt anhand der Reihenfolge gelöst, in der sie in der Modellstruktur aufgeführt sind (von oben nach unten).

Die Lösungsreihenfolge des obersten Dimensionselements gilt für alle dynamischen Elemente in der Dimension, es sei denn, Sie passen die Lösungsreihenfolge für bestimmte Elemente an.

Um die Lösungsreihenfolge zu ändern, müssen Sie den Modellstruktureditor in der Essbase-Weboberfläche verwenden oder Smart View verwenden (siehe Solve-Reihenfolge eines ausgewählten POV ändern).

Sie können für die Lösungsreihenfolge ein Minimum von 0 und ein Maximum von 127 festlegen. Eine höhere Lösungsreihenfolge bedeutet, dass das betreffende Element später berechnet wird.

Anwendungsfälle für die Lösungsreihenfolge finden Sie in den Vorlagen für Lösungsreihenfolgen im technischen Abschnitt der Galerie der Anwendungsarbeitsmappen, die sich im Dateienkatalog in Essbase befinden.

Hinweise zur Lösungsreihenfolge in einem Nicht-Hybridmodus

In Aggregate Storage Cubes gilt Folgendes:

Die Lösungsreihenfolge ist für alle Dimensionen auf 0 gesetzt.
Die Aggregation wird in der Reihenfolge der Modellstruktur ausgeführt. Dabei gelten folgende Ausnahmen:
- Gespeicherte Hierarchieelemente werden zuerst verarbeitet.
- Dynamische Hierarchieelemente werden als Nächstes verarbeitet.

In Block Storage Cubes im Nicht-Hybridmodus lautet die Standardlösungsreihenfolge:

Sparse vor Dense
Accounts vor Time
Attribute zuletzt

Hinweis:

Wenn die Lösungsreihenfolge von Elementen der Dimension "Accounts" manuell höher als die Lösungsreihenfolge von Elementen der Dimension "Time" festgelegt wird, wird "Accounts" nach Dynamic-Time-Series-Elementen ausgewertet.