Post on 23-Aug-2019
transcript
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