EPM 11.1.2.4 – Neue Funktionen Essbase

So, da ist sie nun, die neue Version Oracle EPM 11.1.2.4. Ohne viel Tam-Tam war sie auf einmal auf der Download-Seite verfügbar. Sieht man sich die Liste der zur Verfügung stehenden Produkte an, stellt sich zwangsläufig die Frage: Welches Produkt thematisiere ich jetzt im ersten Beitrag „Neue Version – Was ist neu in 11.1.2.4“?

Die Antwort ist einfach: Ohne ESSBASE ist alles nichts!

Fangen wir also direkt an:

HALT! STOP! Version 11.1.2.4 sollte installiert sein!
Über die Wartungs-Installation (Maintenance-Release) habe ich die Beiträge EPM 11.1.2.4 – Wartungs-Installation (Maintenance Release) und EPM 11.1.2.4 – Wartungs-Installation – Ergänzung gemacht.

Hat alles geklappt? Na dann, los geht’s:

Erweiterung Hybride Aggregation in BSO

Neue Versionen sind die eine Sache, neue Funktionen in Patches die andere. So sind in Version 11.1.2.4 Einschränkungen einer Funktion beseitigt worden, die mit Patch 11.1.2.3.500 veröffentlicht wurde.
Ich spreche hier von Funktion Hybrid Aggregation Mode in Block Storage Databases, da steckt Musik drin, aber so richtig! Das stellt lange Jahre gepflegte Meinungen und Vorurteile auf den Kopf!

Damit das nicht so einfach untergeht, verweise ich ausdrücklich auf Philip Hulsebosch’s Beitrag Der 11.1.2.3.500 Patch. Er hat dort auch auf einige Einschränkungen hingewiesen. Mit Erscheinen der 11.1.2.4er-Version wird deutlich, dass Oracle das Thema sehr ernst nimmt, bestehende Einschränkungen beseitigt und Funktionalität stetig weiter entwickelt.

Konkret geht es darum, dass die hybride Aggregation nun auf TB- (Time-Balance) und DTS (Dynamic-Time-Series)-Elementen durchgeführt werden kann.

Was steckt dahinter?

Im Kern ist die hybride Aggregation keine dritte Speicherform wie ASO oder BSO, sondern es wird für BSO-Modelle der ASO-Kalkulationsprozessor verwendet. Dieser funktioniert jedoch nur auf Sparse-Dimensionen, wenn ALLE Hierarchie-Ebenen (ausser Level 0 natürlich) auf Dynamic Calc gesetzt werden.
Dimensionen mit TB– und DTS-Elementen können jetzt ebenfalls von der hybriden Aggregation profitieren, das ist die Neuerung.

Ich möchte nicht verschweigen, dass es weiterhin Limitationen gibt, die (noch) nicht beseitigt wurden, so ist die Hybride Aggregation nicht möglich, wenn Attributs-Dimensionen oder Cross-Dimensionale-Formeln abgefragt werden.
Es geht eben nicht alles auf einmal, aber die Richtung scheint klar: Oracle investiert in diese Technologie!

Folgerichtig können deutlich mehr Kalkulations-Funktionen die hybride Aggregation nutzen, die vollständige Liste finden Sie im Kapitel Functions Supported in Hybrid Aggregation Mode in der Oracle Essbase Technical Reference.
Beachten Sie auch Kapitel ASODYNAMICAGGINBSO-Konfiguration im gleichen Dokument.

Optimierungen für Oracle-Exalytics In-Memory-Technologie

Läuft der Essbase-Server auf eine Oracle-Exalytics-Maschine mit In-Memory-Technologie (SPARC T5/Solaris), kann der virtuelle Speicher für optimale Performance so eingestellt werden, dass er größer als die Summe aller Dynamic Calculator Caches aller Datenbanken auf dem System ist.

Hört sich erst einmal sehr theoretisch an, in der Praxis soll dies die Performance des Systems verbessern.

Unterstützung der SmartView-POV-Erweiterungen 11.1.2.5.400

SmartView hat in dieser Version eine neue Werkzeugleiste erhalten. Details hierzu sowie zu allen weiteren neuen Funktionen beschreibe ich in Kürze in einem ausführlich bebilderten SmartView-Beitrag.

Aus Sicht von Essbase ist aber interessant, dass Datenbank und APS (Provider-Services) die Nutzung der neuen Leiste unterstützen.
Das heißt im Klartext:
Wer auf SmartView 11.1.2.5.400 geht und neue POV-Funktionalität nutzen möchte, muss auch Essbase und Provider-Services auf Version 11.1.2.4 aktualisieren.

Was können wir nun unter der POV-Unterstützung verstehen?
Mehrere Elemente können gleichzeitig aus der Tabelle in die POV-Leiste oder umgekehrt, aus der POV-Leiste in die Tabelle „gezogen“ werden.
Es lassen sich NICHT einzelne Member markieren, es werden ALLE Member des Grid in den POV geschoben. Im Unterschied zu vorher bleiben aber nun alle vorher im Grid enthaltenen Member im POV zur Auswahl bestehen, bisher stand danach nur noch das erste Element dieser Dimension im POV.

4 Elemente der Zeitdimension sind in der Tabelle vorhanden

Ein beliebiges Element dieser Dimension wird per Drag&Drop in den POV gezogen…

….alle Zeit-Elemente aus dem Grid stehen weiterhin auch im POV zur Verfügung

In der POV-Leiste kann eine einzelne Dimension behalten werden.
Hier liegt die Betonung auf „einzelne Dimension“, denn bisher mussten mindestens 2 Dimensionen in der POV-Leiste verbleiben.
Das überrascht mich! Sie auch?
Mein Gefühl sagt mir, dass es doch bisher schon möglich war, nur 1 Dimension im POV zu belassen. Ob und wie sich hier etwas geändert hat, werde ich im kommenden SmartView-Beitrag klären.

Neue Kalkulations-Funktionen

@RELXRANGE kombiniert verschiedene Funktionen (RELative, XRANGE) und eignet sich damit hervorragend für Rollierende Forecasts
XRANGE steht für eine Kreuz-Dimensionale Liste, die ausgehend von der relativen Position des aktuell prozessierten Elementes, Funktionen mit einer „die nächsten / letzten x Monate“-Logik in Modellen mit mehr als einer Zeit-Dimension erleichtert (Stichwort time continuum navigation).
Puuhhh, was für ein Satz! Gehen wir schnell zur Praxis über und sehen uns an, wie diese Berechnung in der Technical Reference dokumentiert ist:

Syntax:
@RELXRANGE (startOffset, endOffset, XrangeList)

Die Anwendung schauen wir uns in einem Beispiel an (Datenbank Sample.Basic, Dimension Scenario enthält vereinfachend nur die Elemente Actual, Budget:
mbrCount=@COUNT(SKIPNONE,@RELXRANGE(-1,3,@XRANGE(Jan->Actual,May->Actual))->Sales);

Element mbrCount in Sample.Basic, Dimension Kennzahlen mit dieser Formel angelegt (dynamisch kalkuliert), SmartView-Verbindung aufgebaut, „Ad-hoc-Analyse“ gestartet….
das Ergebnis dieser Berechnung ist 0.
Ungläubig noch einmal Aktualisieren gedrückt, bleibt immer noch 0 !

Ich habe dafür keine Erklärung und kann im Moment nur feststellen, dass die Beispiel-Funktion auf der Sample.Basic nicht funktioniert. Das Thema werden wir an die richtige Adresse zur Klärung weiterleiten und natürlich über die weitere Entwicklung berichten.

Das Beispiel aus der TechRef scheint mir eh etwas konstruiert und möchte deshalb eine praxisnähere Verwendungsmöglichkeit aufzeigen. Wir machen eine Planung über das Jahr hinaus und bestimmen mit dieser Formel den Planungs-Zeitraum immer relativ zum Startzeitpunkt.
Auf Basis der Sample.Basic erstelle ich eine neue Datenbank mit einer zusätzlichen Dimension „Jahre“, denn gerade die Modellierung mit 2 Zeit-Dimensionen (Monate, Jahre) ist ein typischer Anwendungsfall für @X-Formeln.
mbrRELXRANGE =@COUNT(SKIPNONE, @RELXRANGE(2,6,@XRANGE(„Y2014“->Aug, „Y2015“->Apr)));

Es werden die Formeln @COUNT , @RELXRANGE und @XRANGE verwendet. Die Formel soll für den Zeitraum Aug‘ 2014 bis Apr‘ 2015 die Anzahl Monate als relativen Ausschnitt aus der XRANGE ermitteln.
„mbrRELXRANGE“ und „Sales“ sind beides Elemente der Dimension „Kennzahlen“, dies ist die Anker-Dimension. Anker-Dimension ist die Dimension, für dessen Element ein Wert berechnet wird, in diesem Fall mbrRELXRANGE .

Arbeiten wir uns nun von innen nach außen vor:
@XRANGE(„Y2014“->Aug, „Y2015“->Apr)
Die XrangeList enthält den Geltungsbereich Y2014->Aug bis Y2015->Apr und gibt folgende Element-Kombinationen zurück:
Y2014->Aug
Y2014->Sep
Y2014->Oct
Y2014->Nov
Y2014->Dec
Y2015->Jan
Y2015->Feb
Y2015->Mar
Y2015->Apr

@RELXRANGE(2,6,@XRANGE(„Y2014“->Aug, „Y2015“->Apr))->Sales
Funktion @RELXRANGE verwendet diese Element-Kombination über beide Dimension und gibt daraus eine Liste mit dem definierten Offset von 2 bis 6 zurück.
Ergebnis:
Wird gerade Element-Kombination Y2014->Aug berechnet, gibt Funktion @RELXRANGE(2,6,….) den Wert „5“ zurück.
Warum? August->Y2014 ist außerhalb des startOffset von 2 und übernimmt deshalb den Wert von startOffset 2, entsprechend wird 5 zurückgegeben, zu verstehen als „Anzahl Monate von StartOffset bis EndOffset“.

Y2014->Aug (offset 0)
Y2014->Sep (offset 1)
Y2014->Oct (offset 2)
Y2014->Nov (offset 3)
Y2014->Dec (offset 4)
Y2015->Jan (offset 5)
Y2015->Feb (offset 6)
Y2015->Mar (offset 7)
Y2015->Apr (offset 8)

Wird gerade Element-Kombination Y2014->Nov berechnet, gibt Funktion @RELXRANGE(2,6,….) den Wert 4 zurück, denn von Nov. an sind es noch 4 Monate bis zum EndOffset.

Y2014->Aug (offset 0)
Y2014->Sep (offset 1)
Y2014->Oct (offset 2)
Y2014->Nov (offset 3)
Y2014->Dec (offset 4)
Y2015->Jan (offset 5)
Y2015->Feb (offset 6)
Y2015->Mar (offset 7)
Y2015->Apr (offset 8)

Wird gerade Element-Kombination Y2015->Apr berechnet, gibt Funktion @RELXRANGE(2,6,….) den Wert 0 zurück, denn Y2015->Apr ist wiederum ausserhalb des OffSet und übernimmt deshalb den Wert von EndOffset 0.
Apr->Actual (offset -1)
Apr->Budget (offset 0)
May->Actual (offset 1)

Interessant ist ein Vergleich der bisherigen Funktion @XRANGE mit der neuen Funktion @RELXRANGE.
mbrXRANGE = @COUNT(SKIPNONE, @XRANGE(„Y2014″->“Aug“, „Y2015″->“Apr“));
bringt folgendes Ergebnis:

Wie wir oben sehen, verändert sich die Berechnung auf dieser Zeitreihe nicht dynamisch mit, genau hier setzt die @RELXRANGE-Funktion an. Sie erleichtert die Berechnung von Kennzahlen mit einer „die nächsten / letzten x Monate“-Logik in Modellen mit mehr als einer Zeit-Dimension.

Formel mbrRELXRANGE = @COUNT(SKIPNONE, @RELXRANGE(2,6, @XRANGE(„Y2014“->Aug, „Y2015″->Apr))->“Sales“); bringt folgende Werte zurück.

Die Relevanz von Element Sales erkenne ich nicht, es ist gleichgültig, welche Kennzahl statt Sales angegeben wird, ja, es ist sogar gleichgültig, ob überhaupt eine Kennzahl angegeben wird. Wahrscheinlich wird mir das erst im Praxiseinsatz dieser Formel klar.
Haben Sie eine Idee? Berichten Sie hier gerne über Ihre Erfahrungen!

Änderungen bekannter Kalkulations-Funktionen

Die gerade beschriebene @RELXRANGE-Funktion kann in vielen weiteren Kalkulations-Funktionen verwendet werden.

Dies sind in alphabetischer Reihenfolge:
@COMPOUND, @COMPOUNDGROWTH, @CORRELATION, @COUNT, @DECLINE, @DISCOUNT, @GROWTH, @INTEREST, @IRR, @IRREX, @MEDIAN, @MODE, @NEXT, @NEXTS, @NPV, @PRIOR, @PRIORS, @PTD, @RANK, @RELXRANGE (new function), @SHIFT, @SHIFTMINUS, @SHIFTPLUS, @SLN, @SYD, @VARIANCE, @VARIANCEP

Outline-Export in XML

Es scheint wie ein Traum: Wir sollen jetzt eine Outline exportieren, in einem Editor bearbeiten und wieder importieren können? Den XML-Export kennen wir ja schon, nun ist also das Gegenstück verfügbar, der XML-Import.
Ist das der Durchbruch bei der Bearbeitung / Import / Export von Outlines?
Nun ja, aufwachen, es ist nur ein Traum, denn es gibt einige Einschränkungen bzw. ein (str)eng definiertes Vorgehen zu beachten:
Die Outline muss im .xsd-Format vorliegen, daraus wird eine Datei im .xml-Format erzeugt, die dann über die API-Funktion EssBuildDimXML wieder importiert werden kann.
Richtig gelesen, nur mittels Essbase-C- oder Java-API kann diese Datei als Outline eingelesen werden.
Detailliertere Informationen gibt es unter EssBuildDimXML in der Oracle Essbase API Reference.

Bei ASO-Modellen ist darüberhinaus zu beachten, dass diese zuvor in Version 11.1.2.4 migriert werden müssen, bevor das beschriebene Verfahren auch für ASO-Modelle funktioniert.

Wir müssen also weiter davon träumen, Outlines zu epxortieren, in einem Editor zu bearbeiten und wieder zu importieren, und das alles mit MaxL!

Bis dahin gibt es ja noch die neue Version des Outline-Extractor’s von OLAPUnderground, Philip Hulsebosch stellt die neueste Version des Tools in Kürze in einem eigenen Beitrag vor. Eines möchte ich schon vorwegnehmen: Was dort an Funktionalität enthalten ist, stellt die hier vorgestellte Funktion Outline-Export in XML locker in den Schatten, lassen Sie sich überraschen.

…. und wen Coding und die Nutzung der API nicht abschreckt, ja, dafür empfehle ich Groovy im Zusammenspiel mit der Java-API, ich werde diese Kombination in eigenen Beiträgen vorstellen.

Prozess-Pool für parallele Verarbeitung

Diese Neuerung ist technischer Natur, d.h. sie hat keine direkte Auswirkung auf den Benutzer von Essbase. Essbase-Entwickler sollten das Thema jedoch kennen, da es ein Mittel zur Performance-Steigerung ist. Und die bemerkt dann doch auch wieder der Essbase-Anwender, so schließt sich der Kreis.

Die Behandlung parallel laufender Prozesse (Kalkualation, Daten laden, Outline-Restrukturierung), ändert sich. Bisher wurden dynamisch die benötigten Prozesse erzeugt, sobald ein Befehl dies erforderte.

Das hieß zum Beispiel für einen Kalkulationsbefehl mit „Calc Parallel 2;“, dass Essbase den 2. parallelen Prozess erzeugte , sobald erkannt wurde, dass in einem Element-Bereich parallele Verarbeitung möglich war.
Prozesse wurden also automatisch erzeugt und wieder beendet und wieder erzeugt und wieder beendet und wieder ……

Nun gibt es einen festen Prozess-Pool, der bei Bearbeitung folgender Prozesse angelegt wird:

• Parallele Kalkulation (CALCPARALLEL, FIXPARALLEL)
• Paralleles Daten laden (ASO + BSO)
• Paralleler Export (nur BSO)
• Parallele Restrukturierung

Gibt es denn auch Möglichkeiten, die Größe des Prozess-Pools zu beeinflussen?
Doch, sogar sehr umfangreich in der Essbase.cfg mit dem Parameter WORKERTHREADS.

Dieser Befehl ist im Zusammenspiel mit einigen weiteren Parametern zu sehen, detaillierte Informationen sind in der Technical Reference in Kapitel Config Settings List (Essbase.cfg), Stichwort Workerthreads zu finden.

Ein Beispiel für folgenden Fall:
In Applikation Sample sollen Prozesse auf max. 32 Threads parallel verteilt werden
WORKERTHREADS Sample 32

Die Angabe der Applikation ist optional, Maximalwert für WORKERTHREADS ist 2048. Ist kein Wert angegeben, wird als Maximalwert der hälftige Wert von Parameter SERVERTHREADS verwendet.

Parallele Kalkulationen können auf bis zu 8 Rechenkernen gleichzeitig erfolgen, im Falle von EXALYTICS-Maschinen auf bis zu 32 Rechenkernen! Wir sehen grundsätzlich den Trend hin zu einer größeren Parallelisierung, erheblich getrieben von den Möglichkeiten der Exalytics.

Eine von Oracle empfohlene Konfiguration für übliche Hardware-Ausstattung:
WORKERTHREADS 50
SERVERTHREADS 100
AGENTTHREADS 30
DLTHREADSPREAPRE 2
DLTHREADSWRITE 2
EXPORTTHREADS 8
RESTRUCTURETHREADS 8

Neue Parameter für Essbase.cfg

• WORKERTHREADS
  Definiert die maximale Größe des „Thread Pools für parallele Prozesse“, der Einsatz ist hier weiter beschrieben
• CRASHDUMPLOCATION
  Bei unerwarteter Beendigung des Servers (Absturz) wird ein „core dump file“ geschrieben. Dieser Parameter definiert, in welches Verzeichnis dieses geschrieben wird.
  Der Parameter ist nur bei gleichzeitiger Verwendung von Parameter CRASHDUMP TRUE nutzbar.
  Agent-Core-Dateien werden im angegebenen Pfad,
  Applikations-Core-Dateien unter /app/appname im angegebenen Pfad gespeichert.Beispiel
  CRASHDUMP /EssbaseServer/crash
• CONNECTIONTIMEOUT
  Der Parameter gilt nur für SQL-Verbindungen auf XOLAP-Modelle!
  Definiert die Wartezeit in Sekunden, bevor Essbase die SQL-Verbindung mit Time-Out beendet. Der Standard-Wert ist 15 Sekunden.
  Beispiel: Time-Out nach 10 Sekunden
  CONNECTIONTIMEOUT 10
• QUERYTIMEOUT
  Der Parameter gilt nur für SQL-Abfragen auf XOLAP-Modelle!
  Definiert die Wartezeit in Milisekunden, bevor Essbase die Verbindung für eine SQL-Abfrage mit Time-Out beendet.
  Beispiel: Time-Out nach 10 Sekunden
  QUERYTIMEOUT 10000

Anonyme Daten mit MaxL-Befehl export data

Neulich wurde ich bei einem Kunden gefragt, ob es nicht möglich sei, verfälschte Daten (Kennzahlen) zu erzeugen. Hintergrund war die Notwendigkeit, Testdaten aus Produktion auf einem Test-System bereit zu stellen. Für den Test vorgesehene Mitarbeiter sollten jedoch mit produktionsnahen, aber keinesfalls mit produktiven Daten arbeiten.
Ich musste verneinen (den Gedanken, die Daten per Kalkulations-Skript zu manipulieren und exportieren habe ich schnell wieder verworfen).
Jetzt bietet uns Essbase eine komfortable Möglichkeit, anonyme Daten zu erzeugen.
Einfach den Befehl export data mit dem Parameter anonymous ergänzen, schon stimmt keine Kennzahl im Export mit der Essbase-Kennzahl überein.
Diese Daten können dann ohne Risiko an andere System oder auch externe Empfänger (Oracle-Support) übergeben wurden.

Bisheriger Export mit Befehl
export database ‚Sample‘.’Basic_‘ all data to data_file ‚Export.txt‘;

Neuer Export mit Befehl
export database ‚Sample‘.’Basic_‘ all data anonymous to data_file ‚Export_anonym.txt‘;

Beginnend mit „0“ wird jeder Wert ganzzahlig um 1 erhöht.

Das Ganze funktioniert auch als Export im column format. Da wird sich mein Kunde freuen, DANKE, Oracle

API-Erweiterungen

Details zu den neuen oder geänderten API-Funktionen finden Sie in

Funktionen, die wir bald nicht mehr sehen werden

Einige liebgewonnene Begriffe können wir so langsam aus unserem Vokabular streichen, da sie offiziell außer Dienst gestellt werden.
Das heißt nicht, dass sie schon heute nicht mehr funktionieren, Support und Weiter-Entwicklung sind jedoch ab sofort eingestellt. Anwender, die diese Funktionen verwenden und in absehbarer Zeit auf EPM 11.1.2.4 ff. gehen, sollten sich auf „die Zeit danach“ vorbereiten, d.h. eine Migration planen:

• Direct I/O
• Gruppen- und Benutzerverwaltung durch MaxL
• Kompressions-Typen „No compression“ und „ZLIB compression“ in BSO
• Währungs-Umrechnungs-Applikationen
• Verknüpfte Partitionen (Linked Partitions)