Seite 113. Dezember 2004

13. Dezember 2004

Vier Jahre Erfahrung mitTerrabyte Data Warehousing

Daniel GüntherProfessional Consultant

Seite 213. Dezember 2004

Die VIVEON AG

Gründung 19. April 2000

Gründer 7 ehemalige CSC Ploenzke Mitarbeiter

Grundkapital 500.000 EURO VIVEON AG200.000 CHF VIVEON CH AG

Aktien- 100 % vinkuliert Stämme davonverteilung 15 % Plönzke Holding AG

10% (SOP) Mitarbeiter

Standorte München – Wiesbaden - Zürich

Anzahl MA 60+

Umsatz 2003 D: 4,6 Mio. EUR CH: 2,1 Mio. EUR (Ist) Umsatz 2004 D: 5,5 Mio. EUR CH: 2,4 Mio. EUR (Plan)

Aufsichtsrat Dr. Harald Föst (Vorsitzender)Klaus Christian PlönzkeKlaus Knoff

Verwaltungsrat CH Stefan Gilmozzi (Vorsitzender)Heinz Bossert (ehem. Verwaltungsratspräsident CSC CH)Jacques Egli (ehem. Marketing Manager Emmi)

Seite 313. Dezember 2004

VIVEON Consulting & VIVEON Interactive – "Closing the Loop"

, MMS

DWH/CRM Consulting & IntegrationCustomer & Service AnalysisBusiness IntelligenceData Mining & Reporting

Campaign ManagementCommunity ManagementMobile ServicesMultichannelIntegrationSoftware SolutionsNetworks Connectivity

, …

VIVEON Consulting VIVEON Interactive

Seite 413. Dezember 2004

ReferenzenADIDAS Salomon

ADIG Investment

Bayerischer Rundfunk

Bosch Siemens Hausgeräte

Credit Suisse PF Deutschland

DAB Bank

Danone

Deutsche Bahn

E.ON

e-plus

EWO (Elektrizitätswerk Obwalden)

Karstadt

Infineon

Loyalty Partner

Orange

O2

QUAM

RTL New Media

Sparda Banken

Sparkassen- Versicherung

UBS Card Center

Weltbild VerlagFIDUCIA

Swisscom Mobile

Seite 513. Dezember 2004

Agenda

Das Data Warehouse – eine Übersicht

Erfahrungen, Tipps, Tricks

DBA Sicht

Entwicklersicht

Organisatorisches

Fragen & Antworten

Seite 613. Dezember 2004

Data Warehouse in der Mobilfunk Branche

3 Oracle 9i InstanzenStammdaten-Instanz

Usage-Instanz

kleine Repository Instanz

Hardware: Sun E15k + Enterprise SAN

Software: Oracle9iR2, Powermart, Scripts (SQL, PL/SQL, Perl, Python),Microstrategy, Clementine

Sonstiges:30% Indexes

Seite 713. Dezember 2004

Key Features

Versionierung der Tabellen, dadurch auch logische Trennung von Ladevorgängen und Abfragen

Scheduler Tool, das Modellieren von Abhängigkeiten, Load Balancing und einfaches Restarten von Jobs im Fehlerfall ermöglicht, Job Failures werden per SMS gemeldet.

Partitionierte parallelisierte Ladeläufe, keine Monolithen, einzelne Jobs < 2h (d.h. schneller Restart einzelner Teile möglich)

Seite 813. Dezember 2004

aus DBA-Sicht

Seite 913. Dezember 2004

Problem: Temp-Space

Früher: kartesische Produkte legen Temp Space lahm und bringen Ladeläufe zum Absturz

Lösung: Temp-Space von Ladeläufen und Ad-Hoc Analysen trennen.

Temp Tablespace getrennt inLaden

Produktive Analysen

Ad-Hoc Analysen

Seite 1013. Dezember 2004

Problem: Resourcensteuerung

3 Resource NutzungsgruppenCRITICAL_GROUP kritische Ladeprozesse

LOAD_GROUP normale Ladeprozesse

USER_GROUP Rest

Resource PlanDefault SYS_GROUP (Ebene 1, 80% CPU)

CRITICAL_GROUP (Ebene 2, 80% CPU)

LOAD_GROUP (Ebene 3, 50% Laden, 30% Ad-Hoc)

USER_GROUP (Ebene 4)

Beschränken der Parallel Server Prozesse für interaktive Queries

früher konnten Ad-Hoc User alle Parallel Server „wegschnappen“, so dass kritische Ladeläufe serialisiert wurden

Seite 1113. Dezember 2004

DWH Problem: Backup

Backups ziehen viel Last und die Kosten der Aufbewahrung steigen.

Facts: Bis zu 1 TB pro Tag Archiv Logs

Full Backups am Wochenende

Backups werden über einen Monat vorgehalten

RMAN Backup mit Veritas NetBackup

geplant: HDS Shadow Image der DB und Backup vom Spiegel

zusätzlich: täglicher Export kleiner Tabellen

zusätzlich: täglicher Export der Repositories

Seite 1213. Dezember 2004

DWH Backup: HDS Shadow Image

Primärinstanz gemounted

Sekundärinstanzgemounted

Storage System

Prim

är D

isks

Spie

gel

Syn

c

LadeläufeSchutz vor logischen Fehlern

BackupAktuelle Analysen

Analysen, die nicht aktuelle

Aggregate benötigen

Seite 1313. Dezember 2004

DWH Backup: weitere Maßnahmen

Um Generierung von Archive Logs zu minimieren:

konsequent NO_LOGGING einsetzen (natürlich nur für temporäre oder einfach wiederherzustellende Tabellen)

Full Backups zum Lastausgleich nur am Wochenende

Tablespaces für wichtige Tabellen < 150GB, sodass einzelne Tabellen nach versehentlichem „DROP TABLE“ über RMAN cross restore wiederhergestellt werden können, ohne dass die komplette Instanz zurückgesetzt werden muss (würde wohl etliche Tage Downtime bedeuten)

Seite 1413. Dezember 2004

DWH Backup: Recovery Fähigkeit:

Problem versehentliches „DROP TABLE“

Trennung produktive und temp/work TabellenProduktive Tabellen in Tablespaces < 150 GB für schnelleres Restoreper RMAN cross recovery

Backup kann auf produktive Tabellen beschränkt werden

(Metadaten, welche Table in welchem Tablespace, werden in der Repository Instanz gepflegt)

Seite 1513. Dezember 2004

Problem: Einsparung Speicherplatz -> Compression

Table Data Compression spart Platz und IO

Vorteile:50% Speicherplatzersparnis (bei unseren Daten)

Full Table Scans sind schneller da weniger IO (zumindest in unserem IO begrenzten System)

Nachteile:funktioniert nur bei a) INSERT /*+ APPEND */, b) sqlldr direct oder c) ALTER TABLE MOVE COMPRESS -> d.h. In unserem Fall müssen wir Partitions nachträglich komprimieren („Downtime wegen unusable indexes“)

Bug bis Oracle 10.x: An Compressed Tables können keine neue Spalten hinzugefügt werden (auch nicht nach Uncompress) (macht Spaß eine 500GB Tabelle neu aufzubauen ;-) ), Bug No. 2421054

Kostet CPU

Seite 1613. Dezember 2004

Problem: Einsparung Speicherplatz -> Indices

Ziel: möglichst wenige Indices

Vorteile:Speicherplatzersparnis (bei uns mit 30% der Daten im Vergleich zu anderen DWH relativ wenig)

Weniger Index Maintenance bei DML (speziell globale Indices sind zu vermeiden)

Nachteile:Manche Queries inperformant

Aber: primary keys sind unverzichtbar!

Seite 1713. Dezember 2004

Showstopper im täglichen Betrieb

Tablespace voll

vergessene unusable Indices

Locks durch offen gelassene PC-Tools (z.B. TOAD) (Explain Plan ansehen ist z.B. eine schreibende Transaktion)

vor 8i/9i: max-extents exceed (vor den LMTS Zeiten)

vor 9i: full Rollback Segments (offene Transaktionen)

-> Anti Showstopper Shell Script

Seite 1813. Dezember 2004

Entwickler-Sicht

Seite 1913. Dezember 2004

DWH Problem: Snapshot-too-old (ORA-1555)

Verursacht durch lange Selects während Tabelle mit kurzen Transaktionen geladen wird.

Problem läßt sich nicht beseitigen, sondern nur die Fehlerwahrscheinlichkeit minimieren

Gegenmaßnahmenundo_retention 1 Tag und entsprechend UNDO Space erweitern (derzeit 300GB)

Jobs parallelisieren, so dass Teile in < 2h fertig werden

Versuch, Lesen und Schreiben zu trennen z.B. Analysen auf einem Spiegel laufen zu lassen

Seite 2013. Dezember 2004

DWH Problem: Snapshot-too-old II

ETL Jobs klein halten

Rechner mit mehreren Prozessoren –> bessere ResourcenAufteilung

dadurch Zeitgewinn

Bei Neustart von großen, länger laufenden Teilen verliert man mehr Zeit

Länger laufende große Jobs haben folgende Risiken:ORA-1555 Snapshot too old

Massive Rollback Segments Usage

Downtime

Seite 2113. Dezember 2004

Problem: Lokalitäten 1

Beispiel: Cursor Loops(Annahme: Update in einer Transaktion ist nicht möglich)

cursor c is select a.rowid,b.wert from a,b where....ORDER BY a.rowid

for r in c loopupdate a set x=r.wert where a.rowid=r.rowid;

end loop;

das Update springt „hin und her“ -> db_file_sequential_reads (=single block reads) - oft nicht im Cache

Verbesserung z.B. durch Sortieren nach rowid

Seite 2213. Dezember 2004

Buffer Cache

rowid

Seite 2313. Dezember 2004

Problem: Lokalitäten 2

Beispiel: Partitionierung z.B. mit modulo cursor c is select * from a where mod(id,10)=xfor r in c loopupdate b set x=y where id=r.id;

end loop;(Annahme: einzelnes Update DML sprengt UNDO)

Problem: irgendwann kommen die Updates auf den gleichen Block (oder gleichen Index Block) -> buffer busy waits, die Loads bremsen sich gegenseitig aus.

Abhilfe: statt modulo Hash/List Partitions (Datensätze sind physikalisch getrennt) oder Sortieren und zeitversetzt starten (verringert nur die Wahrscheinlichkeit)

Seite 2413. Dezember 2004

Updates mit Unter-Selects

update a set a.col = (select b.col from b where b.id=a.id) dauern unendlich lange (wie nested loops)

besserdeclarecursor c is select a.id,b.col from a,b where a.id=b.id;

beginfor r in c loop

update a set a.col=r.col where a.id=r.id;end loop;

end;

alle 10.000 records commit

noch besser: PL/SQL Arrays, bulk collect, forall loops = array processing

Ab 9i Join Updates

Seite 2513. Dezember 2004

Organisatorische

Probleme

Seite 2613. Dezember 2004

DWH Problem: neue Mitarbeiter

Sensibilisierung von neuen Mitarbeiter um ein Gefühl für die Datenmengen zu bekommen

D.h. Einführung in die Do‘s and Don‘ts z.B.den Unterschied zwischen NESTED_LOOPS und HASH_JOINS erklären

Update und Deletes vermeiden, und wenn schon, dann nicht in einer einzelnen Transaktion, die den Undo Space zumacht

was ist ein kartesisches Produkt?

Korrekte Benutzung des driving_site hints

Seite 2713. Dezember 2004

Problem: „Vergessene Sessions“ bzw. Langläufer

Tools stürzen ab und lassen DB Sessions offen

Lösung: 3 Benutzer Profile: default (unbeschränkt) Ladeprozesse

interne Mitarbeiter (2Tag max connect time für vergessene TOADs)

externe Zugriffe (3h max connect etc.)

TOAD Killer am Abend: tagsüber im Schnitt 150 Toad Sessions

Seite 2813. Dezember 2004

Fragen & Antworten