Patch 11.1.2.3.500 – Teil Essbase

Oracle hat bereits die Version 11.1.2.4. auf dem Markt gebracht und ich habe noch nicht die Neuerungen aus dem Patch 500 beschrieben. Nun, einer ist so fundamental in seine Art, dass dieser sich noch weiterentwickeln wird in die nächsten Versionen: Hybrid Aggregation Mode in Block Storage Databases oder wie es in Fachkreisen heißt: Hybrid Essbase.

In diesem Beitrag werde ich nur relativ kurz auf das Hybrid Essbase eingehen, denn das Thema ist verschiedene Beiträge wert. Ja, ich werde mich echt zurückhalten müssen, ansonsten wird es nichts mehr mit den anderen interessanten Neuerungen im Patch 500. Denn hier haben wir das FIXPARALLEL und CALCPARALLEL mit @XREF und @WRITE.

 

Hybrid Essbase

Seit der Geburt von Essbase haben wir den Speichertyp Block Storage. Ich glaube, es war in Version 5, als es mit dem Integration Server ein Hybrid Essbase gab. Es bot die Möglichkeit, um ab einer bestimmten Generation die Daten in einer relationalen Datenquelle zu lassen und die Ergebnisse in das Essbase zu laden. Dann war ein Drilldown in die relationale Welt möglich…

Diese Funktionalität wurde aber zu einem großen Teil obsolet in Version 6 mit Aggregate Storage. Jetzt konnten wir echt große Dimensionen erstellen und noch mehr Daten laden. Keine Datenexplosion und stundenlanges Aggregieren mehr. Eine neue Welt öffnete sich… ein neues Level im Spiel war erreicht… es wurde probiert, es wurde diskutiert, aber es kamen auch einige Enttäuschungen. Es war doch nicht alles so einfach und der Realitätssinn kam zurück.

Doch die Essbase Entwickler bringen uns nun wieder in eine neue Welt, wir werden denselben Prozess wieder durchmachen … denn es gibt Hybrid Essbase:

Kurz gesagt innerhalb einer Block Storage Datenbank können Dimensionen markiert werden, welche dann eine ASO-artige Aggregationsfunktion haben.

Also kein CALC DIM oder AGG auf große flache Dimensionen wie Produkte und Kunden mehr, aber doch die Funktionen eines Calc Skripts.

Dieses wird wiederum die Designmöglichkeiten vergrößern und Essbase noch breiter einsatzfähig machen. Vor allem, weil die Produktmanager deutlich gemacht haben, dass dieses erst der Beginn dieser Entwicklung ist. Wir haben die rasanten Weiterentwicklungen ja auch schon beim ASO gesehen. Ich kann es nicht erwarten!

 

Im Juni, während der amerikanischen Benutzerkonferenz KSCOPE15 wird es dann auch wieder das Thema Nummer 1.

Im letzten Jahr wurden die Hybrid Essbase Präsentationen schnell in größere Räume verlegt, um allen Teilnehmern einen Sitzplatz zu bieten. Es zeigt deutlich, welchen Stellenwert diese Entwicklung haben wird.

 

Was ist es nun?

Outline:                Im BSO-Format mit Outline Formeln und Dense / Sparse Konfiguration.

Blocks:                  ja, aber werden in ASO Format geladen wenn die Applikation startet.

Rechenkern:      ASO. Angeblich wird das BSO in ein internes MDX umgewandelt.

Calc Skript:          ja, BSO Format. Wenn es ausgeführt wird, dann sieht man im Log, dass es ASO Format hat, außer    wenn es komplex wird, dann wird es BSO.

Dateneingabe: nur Level 0 (was machen wir denn sonst?!)

Aggregate Views: nein.

Attribut Dimension: ja, auf den Sparse Dimensionen.

Für den richtigen Einsatz von Hybrid Essbase sollte man Erfahrung mit ASO und BSO haben, denn die Technik ist divers (komplex? schwierig?). Ab und zu könnte man denken, dass auch noch ein Stückchen Hyperroll-Software eingefügt wurde. Diesen Spezialisten hatte Oracle ja schon 2009 gekauft.

Neben den Vorteilen der neuen Funktionalität sollten in dieser ersten Version die Beschränkungen jedoch nicht aus den Augen verloren werden.

Was geht (noch) nicht?

  • Time Balance
  • Two-Pass Calculation in einigen Fällen
  • Attributes
  • Cross-Dimensional
  • Essbase Reports und DATAEXPORT commando
  • Hybrid als Quelle in Partitionen
  • Sehr viele Calc Funktionen.

 

Einschalten von Hybrid Storage.

Hybrid Storage wird in der Essbase Konfigurationsdatei essbase.cfg mit diesem Eintrag gemacht:

ASODYNAMICAGGINBSO [appname [dbname]] NONE | PARTIAL | FULL

None bedeutet, Hybrid ist ausgeschaltet.

Partial bedeutet, dass die Aggregationszeichen Plus, Minus, Tilde, sowie Formeln in der Outline möglich sind.

Full bedeutet, dass alle Aggregationszeichen in der Outline möglich sind, aber nur eine reduzierte Anzahl von Calc Funktionen verwendet werden kann.

 

Datenordner für Hybrid Storage.

Wie auch im BSO werden die Daten in einer “Page Datei” und “Index Datei” abgelegt, aber zusätzlich auch in einer .dat Datei. Diese liegt in einem Verzeichnis mit der folgenden Pfadangabe $ARBORPATH/hybrid/ApplikationsName.

Hier liegen wie bei ASO-Modellen die Unterverzeichnisse default, log, metadata und temp. Das interessante ist, diese Verzeichnisse sind nur anwesend wenn die Applikation gestartet ist. Beim Herunterfahren werden diese entfernt und beim Hochfahren der Applikation werden diese wieder erstellt.

Mit der Option ASODYNAMICAGGINBSOFOLDERPATH kann dieses Verzeichnis sogar irgendwo anders abgelegt werden. Dann erscheinen und verschwinden die Ordner wie aus Geisterhand! Da werden wir einen Junior-Kollegen mal mit reinlegen können… 😉

 

Jetzt aber genug von Hybrid Essbase! Was gibt es sonst noch?

Schnelleres Summieren im MDX

Noch nicht getestet aber sicherlich willkommen sind alle Funktionen die das summieren schneller und schneller machen. Essbase Datenbanken werden immer größer und Google verwöhnt uns auch mit super schnellen Antwortzeiten. Dann darf Essbase nicht zurückbleiben.

Was passiert ist, Essbase macht eine Abhängigkeitsanalyse und schaut nach ob der Formelspeicher verwendet werden kann. Wenn dies so ist, dann kann die Abfrage dynamisch ausgeführt werden.

Also wenn Aggregate( ) oder Sum( ) verwendet wird, dann wird Essbase automatisch den Formelspeicher ansprechen, wenn diese schneller sein wird.

 

FIXPARALLEL

Wenn viele Datenblöcke berechnet werden müssen, die keine wechselseitigen Beziehungen haben, dann ist es günstig um diese parallel zu verarbeiten. In verschiedenen Situationen konnte eine Berechnung jedoch nicht auf diese Weise ausgeführt werden, z.B. wenn ein Teil der Datenbank mit DATACOPY, DATAEXPORT oder CLEARDATA bearbeitet wurde. In der Logdatei konnte man sehen, dass auf serielle Verarbeitung umgeschaltet wurde, obwohl das CALCPARALLEL n; angegeben war.

 

Mit dem neuen FIXPARALLEL können diese Bereiche jetzt doch schneller berechnet werden. Es empfiehlt sich, mit dem gebräuchlichen CALCPARALLEL zu starten. Durch eine schnelle Logdateianalyse können dann die Teile identifiziert werden, die seriell ausgeführt werden. Diese können dann vielleicht mit FIXPARALLEL weiter optimiert werden. Serielle Verarbeitung findet auch häufig statt bei der Verwendung von Variablen und voneinander abhängige Formeln.

 

Die Syntax ist einfach, die Erweiterungen und deren Anwendung aber nicht immer. Wie bei jeder Parallel-Verarbeitung wird der Berechnungsbereich in Aufgaben aufgeteilt. Diese werden dann über die Rechenkerne (Threads) verteilt, wobei die Reihenfolge der Berechnungen nicht immer gleich ist.

 

FIXPARALLEL (numThreads, mbrList)

COMMANDS;

ENDFIXPARALLEL

 

CALCPARALLEL mit @XREF und @XWRITE

Die Funktion CALCPARALLEL ist uns ja schon Jahre bekannt, aber schaltet sich jetzt auch ein wenn @XREF oder @XWRITE Funktionen verwendet werden. Hierdurch werden auch Oracle Planning Applikationen profitieren. Vor nicht allzu langer Zeit haben wir in der Praxis die @XREF Funktion nur für kleine Datenabrufe zwischen Datenbanken verwendet. Die Leistung hat sich aber stark verbessert und wir sind jetzt auf einen Punkt angekommen, wo die @XREF oder @XWRITE Funktionen auch für größere Transfers eingesetzt werden können.

 

Soweit zu dem Essbase Teil im 500-Patch.

 

Ihr Philip Hulsebosch.

 

 

Veröffentlicht unter EPM - 11.1.2.3, Essbase Getagged mit: , ,

Schreibe einen Kommentar

  • Ein Fehler ist aufgetreten – der Feed funktioniert zur Zeit nicht. Versuche es später noch einmal.