Weitere ähnliche Inhalte
Ähnlich wie Performanceaspekte im Oracle DWH (20)
Performanceaspekte im Oracle DWH
- 1. Performanceaspekte im Oracle DWH
Dani Schnider
Principal Consultant
Business Intelligence
6. Oracle DWH Konferenz
Mainz, 30. März 2011
BASEL BERN BRUGG LAUSANNE ZÜRICH DÜSSELDORF FRANKFURT A.M. FREIBURG I.BR. HAMBURG MÜNCHEN STUTTGART WIEN
2014 © Trivadis
Performanceaspekte im Oracle DWH
30. März 2011
1
- 2. Mit über 600 IT- und Fachexperten bei Ihnen vor Ort
2014 © Trivadis
11 Trivadis Niederlassungen mit
über 600 Mitarbeitenden
200 Service Level Agreements
Mehr als 4'000 Trainingsteilnehmer
Forschungs- und Entwicklungs-budget:
CHF 5.0 / EUR 4 Mio.
Finanziell unabhängig und
nachhaltig profitabel
Erfahrung aus mehr als 1'900
Projekten pro Jahr bei über 800
Kunden
Stand 12/2012
Hamburg
Düsseldorf
Frankfurt
Freiburg
München
Wien
Basel
Bern Zürich
Lausanne
2
Stuttgart
Performanceaspekte im Oracle DWH
30. März 2011
2
- 3. Kurzvorstellung Trivadis
Trivadis ist führend bei der IT-Beratung, der Systemintegration, dem
solution based Software- und Product-Engineering und der Erbringung
von IT-Services mit Fokussierung auf und
Technologien im D-A-CH-Raum.
Unsere Leistungen erbringen wir aus den strategischen Geschäftsfeldern:
Durch unser Trainingsangebot stellen wir den Know-how-Transfer sicher.
2014 © Trivadis
Performanceaspekte im Oracle DWH
30. März 2011
3
- 4. Dani Schnider
Principal Consultant und
DWH/BI Lead Architect
bei Trivadis in Zürich
Kursleiter für Trivadis-Kurse
über Data Warehousing,
SQL Optimierung und Oracle
Warehouse Builder
Co-Autor des Buches «Data
Warehousing mit Oracle»
2014 © Trivadis
4
DOAG - Brücken bauen im dimensionalen Modell
22. November 2012
- 5. Was heisst Performance im DWH?
Projekt-Performance
Kurze Entwicklungszyklen eines DWH-Projekts
ETL-Performance
Kurze Laufzeiten beim Laden des Data Warehouses
Abfrageperformance
Kurze Antwortzeiten bei Abfragen auf Data Warehouse
2014 © Trivadis
Performanceaspekte im Oracle DWH
30. März 2011
5
- 6. Performance Tuning – Mythen
Phase „Performance Tuning“ am Ende des Projekts
Performance während Design und Implementierung noch unwichtig
Kurz vor Produktivsetzung wird das DWH noch „getuned“
Performance-Probleme mit Hardware erschlagen
Hardware wird immer schneller und günstiger
Mit genügend CPUs und Memory ist Performance kein Problem
Tuning-Spezialist macht Datenbank schneller
Konfigurationsparameter „fast_oracle_enable= true“
Optimizer-Hint /*+ go_faster */
2014 © Trivadis
Performanceaspekte im Oracle DWH
30. März 2011
6
- 7. Performance Tuning – Realität
Oft werden grundlegende Architekturgrundsätze missachtet
Keine Unterscheidung Core / Data Marts
Abfragen direkt auf Core
Ungeeignetes Datenmodell
ETL-Prozesse werden row-based ausgeführt
Updates auf Fakten
Unklare Anforderungen an DWH
DWH ist „Quellsystem-getrieben“
Sammeln auf Vorrat
Falsche Granularität
Keine spezifischen Data Marts
Performance Tuning beginnt bereits bei Analyse und Design
2014 © Trivadis
Performanceaspekte im Oracle DWH
30. März 2011
7
- 9. 1. Jedes Data Warehouse besitzt ein Core
Data Marts nie direkt aus Quellsystemen laden
Einzige Datenquelle für Data Marts ist Core
2014 © Trivadis
Performanceaspekte im Oracle DWH
30. März 2011
9
- 10. 2. Benutzer greifen nie direkt aufs Core zu
Core ist Integrations- und Historisierungsdatenbank
Core ist nicht für Benutzerabfragen optimiert
2014 © Trivadis
Performanceaspekte im Oracle DWH
30. März 2011
10
- 11. 3. Pro Anwendungsbereich ein Data Mart
Data Mart „ELWMS“ vermeiden
Viele Dimensionen, feine Granularität
hohe Komplexität, schlechte Performance
Pro Benutzergruppe / Fachbereich spezifische Data Marts
Data Marts sind für Benutzergruppe zugeschnitten
Für Benutzer einfacher verständlich
Problem: Formulierung der Anforderungen
Fachbereich muss genaue Anforderungen kennen
…und auch formulieren können
2014 © Trivadis
Performanceaspekte im Oracle DWH
30. März 2011
11
- 13. Benutzeranforderungen klar definieren
Requirement-Analyse zu Beginn des Projekts
Enge Zusammenarbeit zwischen Business und IT
Umsetzen, was notwendig ist
Nicht machen, was der Kunde will – sondern was er braucht
Anforderungsgetriebene Datenmodellierung („Top-down“)
Saubere DWH-Architektur
Integration in Core, nicht in Data Marts
Pro Anwendungsbereich ein Data Mart
Projektziele etappieren
Überschaubare und planbare Releases
2014 © Trivadis
Performanceaspekte im Oracle DWH
30. März 2011
13
Projekt-Performance
- 18. ETL-Performance
Überschaubare Transformationsschritte
ETL in Teilschritte aufteilen (Layer-Konzept)
Vermeidung von komplexen ETL-Mappings
Überschaubare Datenmengen
Delta Extraction und Incremental Loads
Partitionenweises Laden (Partition Exchange)
Fast Refreshes von Materialized Views
Mengenbasierte Verarbeitung
„Set-based“ statt „Row-based“
Vermeidung von prozeduraler Logik
2014 © Trivadis
Performanceaspekte im Oracle DWH
30. März 2011
18
- 19. Exchange Partition – Vorgehensweise
1. Daten werden in Hilfstabelle geladen
Tabelle hat gleiche Attribute wie
partitionierte Zieltabelle
INSERT INTO … SELECT oder CREATE
TABLE … AS SELECT…
2. Auf bestehenden Daten Indizes erstellen
Gleiche Indizes wie auf partitionierter
Zieltabelle
Nachträgliche Indexerstellung ist effizienter
als INSERT in indexierte Tabelle
2014 © Trivadis
Performanceaspekte im Oracle DWH
30. März 2011
19
- 20. Exchange Partition – Vorgehensweise
3. Auf Zieltabelle neue Partition anfügen
ALTER TABLE ... ADD PARTITION ...
Partition mit minimaler Grösse, wird nie
für Daten gebraucht
Tablespace, in dem die Partition liegt, ist
egal, da die Partition am Ende wieder
gelöscht wird
2014 © Trivadis
Performanceaspekte im Oracle DWH
30. März 2011
20
- 21. Exchange Partition – Vorgehensweise
4. EXCHANGE PARTITION
Austausch der Hilfstabelle mit der neuen
2014 © Trivadis
Partition
Nur Änderung im Data Dictionary sehr
schnell
Geladene Daten gehören nachher zur
neuen Partition der Zieltabelle
5. Hilfstabelle ist nachher leer und kann
gelöscht werden
Performanceaspekte im Oracle DWH
30. März 2011
21
- 22. ETL: Set-based vs. Row-based Verarbeitung
Set-based ETL
2014 © Trivadis
Row-based ETL
Performanceaspekte im Oracle DWH
30. März 2011
22
- 24. Abfrageperformance: Dimensionales Modell
Anzahl Dimensionen beschränken
Skalierung des Data Marts
Aktualisierungshäufigkeit
2014 © Trivadis
Granularität
Historyfenster
Performanceaspekte im Oracle DWH
30. März 2011
24
- 25. Abfrageperformance: Physisches DB-Design
Dimensionstabellen:
Pro Dimension eine Tabelle (Star Schema)
Primary Key Index auf jeder Dimensionstabelle
Fakttabellen:
Fakttabellen nach Datum partitionieren
Foreign Key auf Dimensionstabellen
Bitmap Index pro Foreign Key
ev. zusätzliche Bitmap Join Indexes
Aggregationstabellen:
Materialized Views für Hierarchiestufen
ev. Bitmap Indexes auf Materialized Views
2014 © Trivadis
Performanceaspekte im Oracle DWH
30. März 2011
25
- 27. Performanceaspekte im Oracle DWH: Kernaussagen
Performanceaspekte immer beachten, nicht erst am Ende des Projekts
Saubere DWH-Architektur ist Grundlage für gute Performance
Zahlreiche Oracle-Features für Performanceoptimierung – wenn man sie
richtig einsetzt
2014 © Trivadis
Performanceaspekte im Oracle DWH
30. März 2011
27
- 28. Weiterführende Informationen
Artikel „Data Warehouse – schnell gemacht“
Trivadis Download Area
http://www.trivadis.com/uploads/tx_cabagdownloadarea/DWH_schnell_gemacht.pdf
Trivadis-Kurs „Data Warehousing mit Oracle“ (O-DWH)
http://www.trivadis.com/o-dwh
Buch „Data Warehousing mit Oracle – Business Intelligence in der
Praxis“
http://www.hanser.de/978-3-446-42562-0
2014 © Trivadis
Performanceaspekte im Oracle DWH
30. März 2011
28
- 29. Vielen Dank.
Dani Schnider
Principal Consultant
Business Intelligence
BASEL BERN BRUGG LAUSANNE ZÜRICH DÜSSELDORF FRANKFURT A.M. FREIBURG I.BR. HAMBURG MÜNCHEN STUTTGART WIEN
2014 © Trivadis
Performanceaspekte im Oracle DWH
30. März 2011
29