Performanceaspekte im Oracle DWH

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
30. März 2011
1

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
30. März 2011
2

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
30. März 2011
3

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

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
30. März 2011
5

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
30. März 2011
6

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
30. März 2011
7

DWH Architektur
2014 © Trivadis
30. März 2011
8

1. Jedes Data Warehouse besitzt ein Core
 Data Marts nie direkt aus Quellsystemen laden
 Einzige Datenquelle für Data Marts ist Core
2014 © Trivadis
30. März 2011
9

2. Benutzer greifen nie direkt aufs Core zu
 Core ist Integrations- und Historisierungsdatenbank
 Core ist nicht für Benutzerabfragen optimiert
2014 © Trivadis
30. März 2011
10

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
30. März 2011
11

Projekt-Performance – Problemstellung
2014 © Trivadis
30. März 2011
12

 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
30. März 2011
13
Projekt-Performance

Benutzeranforderungen klar formulieren
2014 © Trivadis
30. März 2011
14

Datenmodellierung: Bottom-up oder Top-down
2014 © Trivadis
30. März 2011
15

Releaseplanung: Projektziele etappieren
2014 © Trivadis
30. März 2011
16

ETL-Performance – Problemstellung
2014 © Trivadis
30. März 2011
17

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
30. März 2011
18

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
30. März 2011
19

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
30. März 2011
20

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
30. März 2011
21

Abfrageperformance: Dimensionales Modell
Anzahl Dimensionen beschränken
Skalierung des Data Marts
 Aktualisierungshäufigkeit
2014 © Trivadis
 Granularität
 Historyfenster
30. März 2011
24

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
30. März 2011
25

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
30. März 2011
27

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
30. März 2011
28

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
30. März 2011
29

Performanceaspekte im Oracle DWH

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (16)

Ähnlich wie Performanceaspekte im Oracle DWH

Ähnlich wie Performanceaspekte im Oracle DWH (20)

Mehr von Trivadis

Mehr von Trivadis (20)

Performanceaspekte im Oracle DWH