http://www.opitz-consulting.com/go/3-2-866 Die Oracle BI Suite 11g bietet viele neue und verbesserte Features. Im analytischen Bereich bieten hier vor allem die verbesserten Fähigkeiten im OLAP-Bereich zahlreiche neue Möglichkeiten. Drill-down- & Roll-up-Analysen entlang der Hierarchien multidimensionaler Daten sind mit wenigen Mausklicks erstellt. Was liegt näher, als auch eine echte multidimensional Datenquelle wie zum Beispiel Oracle Essbase zu nutzen? Die Integration von EssbaseDatenbanken in die Oracle BI Suite ist ebenso einfach getan, wie man es von den relationalen Datenbanken kennt. Aber wie sieht es mit der optimalen Performance im Zusammenspiel von OBI und Essbase aus? Der Vortrag gibt einen Überblick über den Weg zum optimalen Datenmodell-Design und die Ermittlung der richtigen Essbase Server- und Datenbank-Konfiguration, um beim Einsatz dieser beiden mächtigen Komponenten im Bereich der OLAP-Analyse die beste Leistung zu erzielen.

2. Oracle Essbase & OBI 11g Best Practices in Design und Tuning Frank TenzerProject Manager Denis GenseConsultant OPITZ CONSULTING Hamburg GmbH München, 26.05.2011

4. Agenda Oracle Essbase & OBI 11g – Motivation MOLAP – Neue Features der OBI 11g Oracle Essbase: Storage, Block Creation u. Statistics Server Configuration– Essbase und OBI 11g Essbase: Outline Design „Do´s & Dont‘s“ Essbase: Data Load u. Calculation Farben und Linienals Kopiervorlage A A A A A A A

6. Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.

8. Darstellung und Handling von Hierarchien

9. Pivot-Spalten aus Dimensionen

10. Verbesserte Generierung von MDX-Statements

11. Speziell: Optimierung der Essbase Anbindung (C-API)

12. Im Ergebnis:

13. Effiziente OLAP-Analysen

14. Optimierte Visualisierung und „Look & Feel“

16. Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.

18. Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.

20. Common Security, Access Control, Authorization, Auditing

21. Common Request Generation and Optimized Data Access Services

22. Common Clustering, Workload Management, & Deployment

23. Common Systems & Operational Lifecycle ManagementOBI 11 g (11.1.1.5.0) OLAP Sources Unstructured & Semi-Structured OLTP & ODS Systems Data Warehouse Data Mart Packaged Applications (Oracle, SAP, Others) Excel XML/Office Business Process Exadata Essbase(11.1.2.1)

25. „Rapid Application Development“ in Essbase: Iterativer Prozess in enger Kopplung mit den Fachanwendern

27. Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.

29. Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.

31. Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.

33. Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.

34. Die Standardfarben sind:11g 10g

36. Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.

38. Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.

40. Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.

42. Storage-Grundlagen der Essbase BSO* 100 Data Value 100-20Texas 2011 Jan 2011 Feb 2011 Mar 2011 Apr Sunroof Texas Sparse 2011 Feb  Units  Actual Dense 100 Units Ess00001.pag Ess00001.ind Actual * Block Storage Option

43. Die Berechnung der Dense-Dimensions … … wirkt sich nur auf Zellen innerhalb bestehender Blöcke aus Berechnung von Sparse-Dimensions … … erzeugt neue Blöcke ( n x m x ….) Block-Creationdurch Sparse-Dimension-Calculation Market Multidimensionale Vorfahren 20011 Jan > Units South Produkt- Vorfahren Texas Product Sunroof Carbody

46. „Gestalte den kleinstmöglichen Block mit der höchstmöglichen Dichte“

47. Bei geringer Dichte …

48. … lässt sich hohe Kompression erreichen (… weil sich unbenutzter Platz gut komprimieren lässt),

49. … aber nur auf der Platte!

50. … im RAM: Anzahl Zellen x 8 Byte!

51. Beispiel:

52. Block size: 22 KB, Density: 5%,

53. 10.000 Blöcke lesen  214 MB lesen …,

54. … davon sind 204 MB (95%) ohne Informationsgehalt!Calculation Script

55. 4 Server Configuration – Essbase & OBI 11g

56. Caching – Essbase vs. OBI 11g Caching Caching

57. Caching – Essbase vs. OBI 11g OBI 11g: File-basierter Ergebnis-Cache speichert Abfrage-Ergebnisse bis zu einer bestimmten Speichermenge, kann bereits abgefragte Ergebnisse bei exakt gleichen Abfragen sehr schnell liefern (gute Unterstützung von Standard-Dashboards und -Reports), bietet keine geeignete Unterstützung von OLAP, da diese Analysetätigkeit ständig wechselnde Abfragen bedingt (slice, dice, drill-down, roll-up). vs. Essbase: Hauptspeicher-basierter Data und Index Cache Index Cache: Hält Index-File (oder Seiten daraus) im RAM Data Cache: Hält Blöcke im RAM Data File Cache: Hält ganze(s) Data-File(s) im RAM (nur bei „direct I/O“ ! ) Caching-Parameter je Datenbank konfigurierbar OBI-Caching im Physical Layer deaktivieren

58. Server Configuration Essbase Cache Sizing Index Cache: Hält im Idealfall das gesamte Index Fileim RAM Data Cache: Faustregel: 3 x Index Cache (oder mehr, bei aufwendigen Calculations oder vielen parallelen Usern  Viele Blöcke „in Gebrauch“) Data File Cache: Hält ganze Data Files im RAM (nur bei „direct I/O“ ! ); im Idealfall Summe der Größen aller pag.-Files Im Ergebnis: Hit Ratios Für Index: möglichst dicht an „1“ Für Data: möglichst groß

59. Server Configuration ESSBASE Block-Commit: Schreibzugriffe minimieren Default: 3.000; bedeutet: Bei Berechnungen werden diese nach je 3.000 Blöcken auf die Platte geschrieben Unnötig viele Schreibzugriffe, wenn der Data cache ein vielfaches davon fassen kann Beispiel: Eine Outline enthält 180 Mio. Blöcke bei einer Blocksize von 22 KB Ein Calculation Script bearbeitet nur 5% hiervon  9 Mio Blöcke. Commit alle 3.000 Blöcke  3.000 Schreibzugriffe Bei einem Data cache von 1 GB kann dieser aber rund 45.000 Blöcke aufnehmen … also würden 200 Schreibzugriffe genügen! Faustregel: Block commit 50.000 – 150.000

60. 5 Essbase: Outline Design „Do´s & Dont´s“

61. Outline Design – Fachliche Anforderungsanalyse Festlegung der Granularität in der Outline Auswahl der erforderlichen Dimensionen Bestimmung der Density/Sparsity Spezifizierung der Kennzahlen

62. Nachteile Langsame Abfrageperformancedurch Ad-hoc-Berechnung Hoher Hauptspeicherbedarf (Cache), um vom Dynamic Calc zu profitieren Dynamic Calc bei Sparse Member  Ad-hoc-Berechnung eines gesamten Blocks erforderlich Vorteile Optimiert die reguläre Zeit für Berechnungen Weniger DB-Zugriffe Verminderter Speicherplatzverbrauch Reduktion der Restrukturierungszeit im Falle einer Outlineanpassung Schnellere Datensicherung Geringerer Anteil an Daten im Cache und bessere Abfrage-performance – bei geringer Verwendung von Dynamic Calc Member Outline Design - Dynamic Calc

64. Minimale Fragmentierung5. Two-Pass Calculations

65. Abweichende Anordnung der Sparse-Dimensions 1. Dimensionen vom Typ „Accounts“ ( Kennzahlen)2. Dimensionen vom Typ „Zeit“ Von derGrößten zur Kleinsten 3. Dimensionen vom vom Typ „Dense“ (lt. Reihenfolge Outline) Häufigste Nutzung in Abfragen 4. Sparse-Dimensions Design unterstützt optimale Abfrageperformance durch entsprechende Anordnung im Index-File 5. Two-Pass Calculations

66. 6 Essbase: Data load & Calculation

68. Vorgehen:

69. Index erzeugen

70. Block erzeugen

71. Block füllen

73. Mit FIX die Berechnung auf das notwendige Fokussieren FIX schränkt die zu lesenden und zu schreibenden Blöcke ein FIX („Budget“, @ICHILDREN(„East“)) „Gross Sales“ = „Units“ * „List Price“ END FIX *.pag vor Calculation Blöcke im RAM *.pag nach Calculation

74. Optimaler FIX FIX auf Sparse-Dimensionen: Index-bezogene Auswahl der Blöcke Effektive Reduktion von Schreib-/Lese-Zugriffen FIX auf Dense-Dimensionen: Keine Einschränkung auf Blöcke (ALLE Member von Dense-Dimensionen existieren in jedem Block!) Einschränkung innerhalb der Blöcke (fachlich vielleicht benötigt, aber kein massiver Performance-Faktor) Jedes FIX ist ein separater Calculation-Pass! Positiv bei der Berechnung von Anteilen (rates): Für den Umsatzanteil der Produktgruppe 100 muss man zunächst den Gesamt-Produkt-Umsatz kennen (Zwei Passes) Negativ, wenn unbedacht verwendet: Zwei FIX … ENDFIX auf zwei verschiedene Dense-Dimensionen bearbeiten beispielsweise 100% der Blöcke doppelt!

75. Optimaler FIX FIX bei fehlendem dimensionalen Zusammenhang: Beispiel: Die Wareneinsatz-Kosten („COGS“) für das Produkt „Sunroof“ stehen in keiner Beziehung zu dem Markt, in dem das Produkt später verkauft wird. Essbase erfordert aber, dass Daten über alle in der Outline existierenden Dimensionen referenziert werden: „COGS“ werden für jedes Member von „Market“ einmal mit dem gleichen Wert gespeichert. Abhilfe: Ein spezieller Member in der Dimension „Market“: „No Market“ liefert eine Basis für Daten, die fachlich keinen Bezug zur Dimension „Market“ haben. Da Market Sparse ist, werden hier effektiv weniger Blöcke erzeugt und berechnet. FIX („Actual“, „No Market“) „COGS“ = „Wareneinsatz“ + „Montage“ END FIX

77. Ebenso sind die Schriftarten als „OC 2009“ hinterlegt.

78. Die Standardfarben sind:OPITZ CONSULTING Hamburg GmbHdenis.gense@opitz-consulting.comTel. +49 40 741122 1350 Denis Gense, Consultant