Riverland Solutions GmbH
01.11.20102© RiverlandSolutions GmbH
► Hochkarätiges Team von Technologie- und Projektmanagement-Experten (50+)
► Kernteam hat mindestens 8 Jahre Siebelerfahrung
► Hoher Technologie und Integrationsfokus
► Starker Erfahrungshintergrund in nationalen wie internationalen Projekten
► Hochprofessioneller aber pragmatischer Ansatz
► Fokus auf Qualität und Wertschöpfung
► Oracle BI Projektierungen in über 10 Projekten
► Oracle Certified Partner
► Erster Oracle BI Partnerschaft in Deutschland (2008) mit dem Produkt Oracle BI Suite (EE und SE)
Technologie und Implementierung
► Oracle CRM Siebel CRM
► Oracle Business Intelligence Analytisches CRM Operatives BI in CRM
► Oracle Fusion Middleware Integration
Who Are We?
Christian Casek
Who am I?
► Senior BI Berater bei der Riverland Solutions GmbH
► Operativ tätig in BI Projekten als Architekt und Consultant
► Seit 5 Jahren BI Erfahrung mit Oracle BI EE(Siebel Analytics) und Crystal
Reports (Business Objects)
► In verschiedenen BI Projekten in diversen Rollen mitgewirkt
► Erfahrung mit der Integration des Oracle BI Publishers(print-ready Reporting) in
Oracle CRM Applikationen
01.11.20103© RiverlandSolutions GmbH
Fragestellung
Welche Fragen werden beantwortet
► Wie können kurze Antwortzeiten der Oracle BI Dashboards gewährleistet werden?
► Wie soll bei Laufzeitproblemen oder langen Laufzeiten vorgegangen werden?
► Welche Maßnahmen können ergriffen werden, um die Performance nachhaltig zu
verbessern?
► Wie kann die Laufzeit der ETL Läufe reduziert werden?
01.11.20104© RiverlandSolutions GmbH
Ist-Situation
Szenario
► Loyaltygestütztes System mit Prämien in Form von Punkten
► Bis zu 500 Mio. neuer bzw. aktualisiertet Datensätze täglich
► Fachliche Reduzierung der Datenmenge bereits durchgeführt
Problemstellung
► Lange ETL Laufzeiten sprengen die gesetzten SLA
● Ist-Situation: ETL Laufzeit 10-12 Stunden
● Soll Anforderung: ETL Laufzeit max. 8 Stunden
► Lange Antwortzeiten der Standard und Ad-hoc Berichte
● Ist-Situation: Berichtauswertungszeit > 30 Minuten
● Soll Anforderung: Berichtauswertungszeit < 10 Minuten
01.11.20105© RiverlandSolutions GmbH
Oracle BI
Systemüberblick
01.11.20106© RiverlandSolutions GmbH
Datawarehouse
Schicht
Logische BI
Schicht
BI Server
RPD
Request und Dashboard
Schicht
Datenbanken
Informatica
DAC
Request
Dashboard
Anforderungsaufnahme
Anforderungsaufnahme
01.11.20107© RiverlandSolutions GmbH
Datawarehouse
Schicht
Logische BI
Schicht
BI Server
RPD
Request und Dashboard
Schicht
Datenbanken
Informatica
DAC
Request
Dashboard
Anforderungsaufnahme
Anforderungsaufnahme
► Bereits bei der Anforderungsaufnahme ist eine Laufzeitbetrachtung durchzuführen
► Reduzierung der Kundenwünsche auf die tatsächlich benötigten Attribute und
Kennzahlen
● Die zu Ladende Datenmenge kann hier reduziert werden
► Hinterfragen des fachlichen Nutzens hinter der Anforderung
● Verständnis für das Geschäft des Kunden erlangen
● Durch das Verständnis können die Wünsche des Kunden besser umgesetzt werden
► Benötigte Aktualität des Datenbestandes festlegen
● Festlegen welche Daten täglich, wöchentlich und monatlich geladen werden können
01.11.20108© RiverlandSolutions GmbH
Datawarehouse Schicht
01.11.20109© RiverlandSolutions GmbH
Datawarehouse
Schicht
Logische BI
Schicht
BI Server
RPD
Request und Dashboard
Schicht
Datenbanken
Informatica
DAC
Request
Dashboard
Anforderungsaufnahme
ETL Laufzeit - Szenario
Datawarehouse Schicht
► Identifizierung welche ETL SDE oder SIL Tasks haben eine hohe Laufzeit haben.
01.11.201010© RiverlandSolutions GmbH
ETL Laufzeit - Lösungsansatz
Datawarehouse Schicht
► Das betreffende SQL an Hand des DB Explain Plans analysieren
01.11.201011© RiverlandSolutions GmbH
ETL Laufzeit - Lösungsansatz
Datawarehouse Schicht
► Table Access Full => Verwendung von DB Hint „parallel“
► Syntax parallel (W_PERSON_D, 8): Tabellenname, Anzahl zu verwendender
Prozesse
01.11.201012© RiverlandSolutions GmbH
ETL Laufzeit - Lösungsansatz
Datawarehouse Schicht
► Generell führt Oracle DB den optimalen Explain plan aus
► Wichtige Voraussetzung: Statistiken der Tabellen müssen aktuell sein
► Problem: starke Schwankungen der Datenmengen beim ETL
► Folge:
● Statistiken nicht korrekt
● Oracle DB führt nicht den optimalen Explain Plan aus
● Lange Laufzeiten
► Lösung: Bei Task mit stark schwankenden Datenmengen im POST SQL des SDE
Workflows eine Statistikberechnung erzwingen:
begin dbms_stats.gather_table_stats
ownname => 'OLAP',tabname =>'WC_LOY_CARD_DS',
estimate_percent => 1,
method_opt => 'for all columns size 1')\;
end\;
01.11.201015© RiverlandSolutions GmbH
ETL Laufzeit - Lösungsansatz
Datawarehouse Schicht
► Fachliche Reduzierung von Ladeintervallen bei Aggregaten (Aggregatslauf auf das
Wochenende verlagern)
► Reduktion der ETL auf das Laden der tatsächlich benötigten Spalten
► Anlegen von zusätzlichen Indexen
► Look-Ups in die SQLs der Source Qualifier einbinden
01.11.201016© RiverlandSolutions GmbH
Massenänderungen - Szenario
Datawarehouse Schicht
► Durch eine fachlichen Anforderung wird im operativem System die Berechnung
eines Kundenkartenattributs geändert.
► Eine Aktualisierung des kompletten Kundenkartenstamms (ca. 36 Mio. Datensätze)
ist notwendig.
► Ein Update über den inkrementellen ETL ist nicht möglich, da das Zeitfenster zu
gering ist, um einen solchen Massenupdate zu ermöglichen.
01.11.201017© RiverlandSolutions GmbH
Massenänderungen - Lösungsansatz
Datawarehouse Schicht
► Die DB Transaktion INSERT ist deutlich schneller als die Transaktion UPDATE
01.11.201018© RiverlandSolutions GmbH
WC_CARD_D
WC_CARD_D
_TMP
WC_MIG_ATT
INSERT
DROP Index
on
WC_CARD_D
WC_CARD_D
_BKP
WC_CARD_D
_TMP
Create Index
on
WC_CARD_D
RENAME
Logische BI Schicht
01.11.201019© RiverlandSolutions GmbH
Datawarehouse
Schicht
Logische BI
Schicht
BI Server
RPD
Request und Dashboard
Schicht
Datenbanken
Informatica
DAC
Request
Dashboard
Anforderungsaufnahme
Aggregate
Logische BI Schicht
► Im RPD des BI Servers lassen sich die Logischen Datenquellen für verschiedene
Ebenen festlegen
► Verwendung von Aggregaten auf verschiedenen Levels
01.11.201020© RiverlandSolutions GmbH
Aggregate
Logische BI Schicht
► Reportanforderungen analysieren und Zusammenhängen zwischen Kennzahlen
und Dimensionattributen erkennen
► Gruppierungen festlegen
► Aggregat so wählen, dass es idealerweise für mehrere Reports Verwendung findet
01.11.201021© RiverlandSolutions GmbH
Aggregate
Logische BI Schicht
► Das Beladen der Aggregate verlängert den ETL Prozess
► Priorisierung zwischen ETL Laufzeit und Report Antwortzeiten muss getroffen
werden
► Aggregate vergrößern den Bedarf an Speicherplatz auf der Datenbank
01.11.201022© RiverlandSolutions GmbH
Fragmentation - Szenario
Logische BI Schicht
► Lange Antwortzeiten eines Ad-hoc Reports im Themenbereich Transaktionen
► Datenmenge der Tabelle WC_LOY_TXN_F > 300 Mio. Datensätze
► Ad-hoc Report auf Detailebene, somit keine Verwendung von Aggregaten möglich
01.11.201023© RiverlandSolutions GmbH
Fragmentation - Lösungsansatz
Logische BI Schicht
► Analyse wie die Tabelle sinnvoll verkleinert werden kann
► Teilung der Tabelle in mehrere Teile anhand des am häufigsten verwendeten
Filterkritteriums (z.b. Zeit)
01.11.201024© RiverlandSolutions GmbH
WC_LOY_TXN_F
WC_LOY_TXN_F
_Q1
WC_LOY_TXN_F
_Q2
WC_LOY_TXN_F
_Q3
WC_LOY_TXN_F
_Q4
Fragmentation - Lösungsansatz
Logische BI Schicht
► Tabellen im Logischem Layer des RPD einfügen und bekanntgeben
01.11.201025© RiverlandSolutions GmbH
Fragmentation - Lösungsansatz
Logische BI Schicht
► Für jede Sourcetabelle muss das Fragment definiert werden, dass sie enthält
01.11.201026© RiverlandSolutions GmbH
Request und Dashboard Schicht
01.11.201027© RiverlandSolutions GmbH
Datawarehouse
Schicht
Logische BI
Schicht
BI Server
RPD
Request und Dashboard
Schicht
Datenbanken
Informatica
DAC
Request
Dashboard
Anforderungsaufnahme
Antwortzeiten - Szenario
Request und Dashboard Schicht
► Die Wartezeit eines Reports beträgt über 20 Minuten.
► Der Report ist in Tabellarischer Form und liefert mehrere Tausend Zeilen und ca. 30
Spalten.
► Der Report wird mehrmals täglich in leicht veränderter Form ausgeführt.
01.11.201028© RiverlandSolutions GmbH
Antwortzeiten - Lösungsansatz
Request und Dashboard Schicht
► Verwendung von I-Bots
► Über I-Bots kann der Report jeden morgen vor den Usern ausgeführt und gecached
werden.
► Die Antwortzeit bei Ausführung der User wird deutlich verbessert
01.11.201029© RiverlandSolutions GmbH
Antwortzeiten - Lösungsansatz
Request und Dashboard Schicht
► Fachliches Hinterfragen des Reports:
● Welchen Nutzen bringt ein Report mit mehreren tausend Zeilen und über 30 Spalten?
● Dient der Extrakt einem anderen Tool als Input?
● Welche Information möchten die Anwender aus diesem Report ziehen?
► Reduktion der Reports auf wenige Spalten
● Management Reports sollte primär grafische Darstellungen enthalten
● Operational Reports enthalten mehr Daten in tabellarischer Form
● Drill-down von Management Ebene auf operative Sicht ermöglichen
► Schulungen für Power-User oder Endanwender
● Durch Schulung das Verständnis des BI vermitteln
● Anleiten zur Erstellung von intelligenten Ad-hoc Reports und Dashboards
● Verwendung von Filtern zur Einschränkung der Ergebnismenge nahelegen
01.11.201030© RiverlandSolutions GmbH
Zusammenfassung
► Verständnis beim Kunden für BI aufbauen (Oracle BI ist kein Excel-Reporting Tool)
► Verständnis für das Geschäft und die fachlichen Anforderungen des Kunden
aufbauen
► Laufzeitbetrachtung muss bereits bei der Anforderungsaufnahme vorgenommen
werden
► In der Datawarehouseschicht liegt das größte technische Optimierungspotenzial
► Optimales Zusammenspiel und Ausgewogenheit aller drei BI Schichten notwendig
► Je später Laufzeitprobleme erkannt werden desto „teurer“ ist die Behebung
01.11.201031© RiverlandSolutions GmbH