Performanceaspekte im Oracle DWH

2014 © Trivadis

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

Dani SchniderPrincipal ConsultantBusiness Intelligence

6. Oracle DWH KonferenzMainz, 30. März 2011

30. März 2011Performanceaspekte im Oracle DWH

1

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 undnachhaltig profitabel

Erfahrung aus mehr als 1'900 Projekten pro Jahr bei über 800 Kunden

Stand 12/2012

Hamburg

Düsseldorf

Frankfurt

FreiburgMünchen

Wien

Basel

ZürichBernLausanne

2

Stuttgart

Mit über 600 IT- und Fachexperten bei Ihnen vor Ort


2

2014 © Trivadis

Trivadis ist führend bei der IT-Beratung, der Systemintegration, dem solution based Software- und Product-Engineering und der Erbringungvon 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.

Kurzvorstellung Trivadis


3

2014 © Trivadis

DOAG - Brücken bauen im dimensionalen Modell4

Dani Schnider

Principal Consultant und DWH/BI Lead Architectbei 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»

22. November 2012

2014 © Trivadis

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


5

2014 © Trivadis

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 */


6

2014 © Trivadis

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


7

2014 © Trivadis

DWH Architektur


8

2014 © Trivadis

1. Jedes Data Warehouse besitzt ein Core

Data Marts nie direkt aus Quellsystemen laden

Einzige Datenquelle für Data Marts ist Core


9

2014 © Trivadis

2. Benutzer greifen nie direkt aufs Core zu

Core ist Integrations- und Historisierungsdatenbank

Core ist nicht für Benutzerabfragen optimiert


10

2014 © Trivadis

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


11

2014 © Trivadis

Projekt-Performance – Problemstellung


12

«Slowly ChangingRequirements»

2014 © Trivadis

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


13

Projekt-Performance

2014 © Trivadis

Benutzeranforderungen klar formulieren


14

2014 © Trivadis

Datenmodellierung: Bottom-up oder Top-down


15

2014 © Trivadis

Releaseplanung: Projektziele etappieren


16

2014 © Trivadis

ETL-Performance – Problemstellung


17

«Die Nacht ist zu kurz»

2014 © Trivadis

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


18

2014 © Trivadis

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


19

2014 © Trivadis


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


20

2014 © Trivadis


4. EXCHANGE PARTITION

Austausch der Hilfstabelle mit der neuen 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


21

2014 © Trivadis

Abfrageperformance: Dimensionales Modell

Anzahl Dimensionen beschränken

Skalierung des Data Marts

Aktualisierungshäufigkeit

Granularität

Historyfenster


24

2014 © Trivadis

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


25

2014 © Trivadis

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


27

2014 © Trivadis

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


28

http://www.trivadis.com/uploads/tx_cabagdownloadarea/DWH_schnell_gemacht.pdf

http://www.trivadis.com/o-dwh

http://www.hanser.de/978-3-446-42562-0

2014 © Trivadis

BASEL BERN BRUGG LAUSANNE ZÜRICH DÜSSELDORF FRANKFURT A.M. FREIBURG I.BR. HAMBURG MÜNCHEN STUTTGART WIEN

2014 © Trivadis

Vielen Dank.

Dani SchniderPrincipal ConsultantBusiness Intelligence


29

Performanceaspekte im Oracle DWH

Presentations & Public Speaking

Transcript of Performanceaspekte im Oracle DWH