DATA WAREHOUSE Oracle Data Warehouse – ETL in der Datenbank / Zusammenspiel mit Nicht-Oracle – ETL - Tools Alfred Schlaucher DATA WAREHOUSE

Themen Ziele Oracle DWH Architektur zur Einordnung Anforderungen an den ETL Prozess Hilfsmittel in der Datenbank (Übersicht) Vorgehensweise im ETL-Prozess Hardware und Umgebungsarchitektur

Themen Ziele Oracle DWH Architektur zur Einordnung Anforderungen an den ETL Prozess Hilfsmittel in der Datenbank (Übersicht) Vorgehensweise im ETL-Prozess Hardware und Umgebungsarchitektur

Ziele Optimierung des Datenbank-Einsatzes in einem Oracle-DB basierten Data Warehouse Blick für eine „Best Practise Oracle Architektur“ öffen Aufhellen der Black Box „Datenbank“ Bessere Lastverteilung zwischen Komponenten (ETL-Server / DB-Server) Auflösen von Engpässen Aufzeigen von optimalen Wegen

Black Box DWH-DB transparent machen Data Warehouse

Themen Ziele Oracle DWH Architektur zur Einordnung Anforderungen an den ETL Prozess Hilfsmittel in der Datenbank (Übersicht) Vorgehensweise im ETL-Prozess Hardware und Umgebungsarchitektur

Was macht das DWH-Konzept so erfolgreich (auch nach 15 Jahren) ? 2 Daten sollten zentral und leicht für alle Benutzergruppen gleichermaßen zugänglich sein Zentrale Bereit- stellung Daten sollten leicht verstehbar sein Informationen statt Daten Semantische Zusammen- hänge Business- Daten Semantik Entkop- plung von op. System Historisch (-> Trends) 3 4 Trendfähige Informationen durch Aufbewahrung und Aufbereitung historischer Daten Flexibel und unabhängig von operativen Anwendungen analysieren können 7 A

Evolution des Data Warehouse ¾ unserer Kunden nutzen ihr DWH auch zu operativen Zwecken Überschaubar / aggregiert Hochvolumig / granular Operativ überschaubar Taktisch DWH Strategisch Jahr/Quartal/Monat Woche/Tag Stunde/Minute/Sekunde/Realtime Komplexe Informations- Ausarbeitung und Analysen Periodische Berichte oft und schnell wiederholbare Einzel- informationen 8

Die 3-Schichten-Architektur Das Ziel der 3-Schichten-Architektur ist der Entwurf einer möglichst umfassenden, mehrere Unternehmens- und Themenbereiche abdeckenden stabilen Informationsablage, die in kurzer Zeit konsolidierte Berichte und Analysen für alle (!) Zielgruppen des Unternehmens bereitstellt. Schlagwörter: Stabilität Kurze Lieferzeit Konsolidiert Alle Zielgruppen 9

Prinzip Normalisieren / Denormalisieren Granularisierung als Lösung Operative Daten Normalisierte Daten (DWH) Neu sortierte Daten Produktsparten Spartenname Spartennr PRODUKTDATEN PD4711 AMKLB 9987865234 7769 0000000 KLABAUTER IIO ??? EERWEERW 883466 888750000 888000 EU-Wert 735328567353654 i8886345 7746 Produktdaten Produktname Produktenr Einzelpreis Produktgruppen Gruppenname Gruppennr Gruppenname Gruppennr Produkte Produktname Produktenr Einzelpreis Spartenname Spartennr Müll, Altlast, unverständliche Daten Verständliche Information (denormalisiert) Granulare Daten Im DWH 10

Das Neutralitätsprinzip des DWH Redundanzen Any Source/Target System Enterprise Information Layer (Kern DWH) Data Integration User View Layer (Data Marts) Data Integration Layer (Stage) Process neutral / 3 NF Any User Group Prüfen Integrieren Harmonisieren Standardisieren Erweitern Verbinden In Beziehung setzen Anwenden Aufbereiten Aggregieren Rohdaten Angebot Bedarf Anwendungs- neutral, granular, Zeit-neutral Neutral gegenüber Vorsystemen, Sprachen, OS Neutral gegenüber Endbenutzern: Alle User! Alle Tools! 11

Oracle Data Warehouse Architektur für unternehmensweites Datenmanagement Data Integration Real Time & Batch Any Source BI Server Reporting & Publishing Ad-hoc Analysis Office Integration Mobile Scorecards Interactive Dashboards Oracle Database Management System Operational Data Layer Information Layer Architecture Concept Enterprise Information Layer User View Layer Data Integration Layer InDatabase ROLAP MOLAP Data Mining R Controlling Financial Marketing Sales HR BI Apps Reference Data Models Data Management Concept Dynamic Data Marts Data Quality Rules Checks&Monitoring DWH Logistic Utilities Business Catalogue Technical Auditing Metadata Utilities Lifecycle Management Concept DWH System Monitoring Utilities DWH Security Utilities DWH Backup / Recovery Concept Concept Framework noSQL Hadoop Big Data Solution Big Data Appliance Exadata Exalytics To explain it a little bit more Lets have look to this map What you see here is a collection of all components you can use in a Data Warehouse and Business Intelligence environement. Optimiertes Netzwerk Server Cluster Operating System Optimized Network Storage Hierarchy Exadata / Database Machine / Exalytics

Regeln einer effizienten DWH-Architektur Orientierung an den Informationsbedürfnissen der Benutzer Granularisierte 3NF-DWH Schicht schafft Neutralität gegenüber Vorsystemen Flexibilität bei der Bereitstellung neuer Abfragemodelle Über Data Mart-Grenzen hinweg gemeinsam genutzte Berechnungen Aggregationen usw. so früh wie möglich umsetzen Zusammenhängende Data Mart-Schicht Mehrfachnutzung von Dimensionen Geschickter Umgang mit sehr großen Faktentabellen Eher granulare Informationen auch in den Fakten-Tabellen Alle Schichten in einem DB-Raum Ein zusammenhängender DB-Server-Cluster zum Verhindern unnötiger Wege In-Database-Aktiviäten (Prüfen/Laden) 1:1 Kopien verhindern Bereits beim Lesen in die Vorsysteme einfache Prüf- und Filteraktivitäten Updates und einzelne Deletes vermeiden ETL wiederholbar aufbauen

Multidimensionales Modell (Star Schema) Status Einstiegspunkte für Anwender-Abfragen V1 V2 V3 V4 Maier P Müller F Schmid P Kunde Engel F 1 : n Verkäufe Artikel Zeit Farbe A1 A2 A3 A4 Art1 Blau A1 A2 A3 A4 R1 R2 R3 R4 Z1 Z2 Z3 Z4 V1 V2 V3 V4 4 Z1 Z2 Z3 Z4 6.7.09 Q3 1 : n n : 1 Art2 Gelb 4 7.7.09 Art3 Rot 9 8.7.09 Art4 Lila 8 9.7.09 n : 1 Star Schema Flexibel Graphisch auch für Business-User verständlich Star Schema: neben der reinen Implementierung sind auch Dinge wichtig, die die Laufzeit optimieren – Techniken wie Partitionierung, MVs, evtl. Komprimierung, Inidizes, Table Clustering etc. R1 R2 R3 R4 Nord Schwach Sued Mittel West Hoch Regionen Ost Schwach Wohndichte 14

Dimensionen Dim_Artikel Parent Parent Fakten Artikelsparte_Langname Levelschlüssel Artikelsparte Sparte Parent Aggregation Artikelgruppe_Langtext Levelschlüssel Artikelgruppe Parent Aggregation Artikel_Langtext Levelschlüssel/ Objektname Artikel Business Key Artikel_Schlüssel Künstlicher Dimension Key Dim_Schlüssel Fakten 15

Star vs. Snowflake Schema 16

Das Schichten-Modell als Hilfestellung Any Source/Target System Enterprise Information Layer Data Integration User View Layer Data Integration Layer Process neutral / 3 NF Any User Group Operational Data Layer Das Schichten-Modell als Hilfestellung bei der Planung des ETL-Prozesses Oracle Data Warehouse 17

Lade-Aktivitäten an Schichtübergängen Integration Enterprise User View Flüchtige Daten Persistent Kopien / teilpersistent dynamisch Clearing-Verfahren, technisches, logisches, semantisches Prüfen Denormalisieren Historisieren z.T. Aggregieren Normalisieren (Granularisieren) Generische Datenstrukturen (isolierte Tabellen, teil-ausgeprägte Datentypen) Keine Constraints 3 NF Datenstrukturen (ER-Tabellen, ausgeprägte Datentypen) Aktivierte Constraints Multidimensionale Modelle (ER-Tabellen, ausgeprägte Datentypen) Kopieren Selektieren Mengenbasiertes Prüfen ohne Constraints Umschlüsselung Lookups -> Referenz-/Stammdaten Joins Aufbauen von Distinct-Strukturen (Normalisieren) Umschlüsselung Lookups -> Dimensionsdaten Joins - Denormalisieren 18

Durch führes Transformieren Synergien ermöglichen Die frühest mögliche Stelle finden User View Layer ETL: Kosten pro Kunde Data Integration Data Integration Layer Enterprise Information Layer ETL: Kosten pro Kunde ETL: Kosten pro Kunde Any Source/Target System Any User Group Process neutral / 3 NF ETL: Kosten pro Kunde Operational Data Layer ETL: Kosten pro Kunde

Verteilte Server zwingen oft zu unproduktiven 1:1 Ladevorgängen User View Layer 1:1 Vorsystem Data Integration Layer Enterprise Information Layer User View Layer 1:1 Process neutral / 3 NF 1:1 1:1 Vorsystem mit Vorrechner User View Layer 1:1

Eine Hardware (bzw. Cluster) ermöglicht flexibles Handeln durch kurze Wege Freie Wahlmöglichkeit für Ort und Art des ETL Data Integration Layer Enterprise Information Layer User View Layer Process neutral / 3 NF

Synergien ermöglichen Die frühest mögliche Stelle finden User View Layer ETL: Kosten pro Kunde Data Integration Data Integration Layer Enterprise Information Layer ETL: Kosten pro Kunde ETL: Kosten pro Kunde Any Source/Target System Any User Group Process neutral / 3 NF ETL: Kosten pro Kunde Operational Data Layer ETL: Kosten pro Kunde

Stage – Funktion Arbeitsschicht für alles, was der technischen Bearbeitung unterliegt Überprüfung von Syntaktischer Korrektheit (Typ, Länge, NULL) Vollständigkeit der Daten und Mengenverhältnisse Gültigen Wertebereichen Vorhandensein von Referenzdaten Eindeutigkeit (optional) Eliminierung von NULL-Werten Zusammenführung operativ getrennter Daten Bilden neuer Informationsobjekte mit dem Ziel der einfacheren Weiterverarbeitung (optional) Waisen-Management (optional) Bildung von Daten-Deltas (optional) 23

Stage – Verarbeitung Keine 1:1-Kopien Keine besonderen Datenmodell-Strukturen Wenn möglich, bereits beim Extrahieren Prüfungen und Wandlungen von Daten vornehmen Keine Indizes verwenden  Stage ist leer, wenn nicht geladen wird 24

Die Schichten im Detail Die (Kern-) Data Warehouse - Schicht Any Source/Target System Enterprise Information Layer Data Integration User View Layer Data Integration Layer Process neutral / 3 NF Any User Group Operational Data Layer Die Schichten im Detail Die (Kern-) Data Warehouse - Schicht Oracle Data Warehouse 25

DWH-Kerndatenschicht Aufgaben und Ziele Eindeutigkeit aller Objekte und Namen Redundanzfreiheit aller Informationen Langlebigkeit der Daten (Historisierung)  Granulare Informationen als Bausteine für neue Informationszusammenhänge 26

DWH-Kerndatenschicht 3 Normalform (3 NF) Subjekt-bezogen In Teilbereiche (Subject Areas) gegliedert Anwendungs- und Geschäftsprozess-neutral Objekte werden in mehreren Geschäftsprozesse benötigt Daten müssen tauglich genug sein, um sie in allen Anwendungen zu verwenden Datenarten Stammdaten (historisiert) Referenzdaten – externe / interne, allgemeine Sammlungen Bewegungsdaten (angesammelt) 27

Themen Ziele Oracle DWH Architektur zur Einordnung Anforderungen an den ETL Prozess Hilfsmittel in der Datenbank (Übersicht) Vorgehensweise im ETL-Prozess Hardware und Umgebungsarchitektur

ETL-Lösung Backbone des DWH Transfer-Medium über alle Schichten hinweg Vermittlungsfunktion Übernimmt oft Dokumentationsaufgabe Bewegen großer Datenvolumina bei gleichzeitiger komplexer Transformation Standard-Lösung wird benötigt Nicht zu komplex (Entwickler-Spielzeug) Verständlich auch für Business User Leichte Erklärbarkeit für Dritte 29

Ziel / Aufgabe eines DWH-Ladeverfahrens Bereitstellen von Daten in adäquater Weise Zeitlich passend Richtige Form Passende Inhalte Daten so ablegen, dass man sie wiederfindet Dokumentation Daten Ressourcen-ökonomisch speichern Berücksichtigung von Plattenplatz 30

Was wird geladen? Es sollte nur das geladen werden, was wirklich gebraucht wird Gibt es einen Auftrag für das Laden bestimmter Daten? Wer braucht die Daten? Welche Daten werden gebraucht? Sind die zu ladenden Daten in einem brauchbaren Zustand? Welche Anforderungen sind an Quelldaten zu stellen? Wer definiert die Anforderungen? 31

Lade-Aufwand minimieren Ladeläufe orientieren sich an den Daten, die man braucht  Erst die Datenstrukturen sortieren, bevor man Ladeläufe plant Zur Orientierung hilft das 3-Schichten-Modell: Staging Area DWH (3 NF) Data Marts 32

Die vier Funktionsbereiche des ETL Integrieren Informations-Mehrwerte Kopieren Sammeln 33

1. Integrieren 2. Informations-Mehrwerte 3. Kopieren 4. Sammeln 1. Integrieren Identifizieren von identischen oder zusammenhängenden Informationen Synonymen-/Homonymen-Thematik Aggregationslevel angleichen Identifizieren und Angleichen Formate, Zustände, Sichtweisen etc... Betrag / Summe Artikel / Produkt Artikel / Artikelgruppe Meter / Kilometer Lose Stücke / Gebinde 34

2. Informations-Mehrwerte 1. Integrieren 2. Informations-Mehrwerte 3. Kopieren 4. Sammeln 2. Informations-Mehrwerte Qualitativ gute Informationen schaffen Datenqualitäts-Checks Vollständigkeit Datentypen Referentielle Integrität Eindeutigkeit Korrekte Werte Fachliche Regeln überprüfen Berechnungen / Aggregationen / Zusammenfassungen Anreichern und Vermengen mit Referenzdaten Lookups Marktdaten Vergleichszahlen 35

3. Kopieren 1:1-Datenbewegung Mengen-Operationen 1. Integrieren 2. Informations-Mehrwerte 3. Kopieren 4. Sammeln 3. Kopieren 1:1-Datenbewegung Einfachste Aufgabe Mengen-Operationen Ohne zusätzliche Logik Überwindung von Systemgrenzen Vorschriften zum Mapping Schnittstellen-Konventionen Aspekt der Performance 36

4. Sammeln Einlagern von Daten Versionieren von Daten 1. Integrieren 2. Informations-Mehrwerte 3. Kopieren 4. Sammeln 4. Sammeln Einlagern von Daten Zeitliche Rahmenvorgaben Historisierung Versionieren von Daten Kategorisieren / Inventarisieren von Daten Dokumentieren der eingelagerten Informationen Referenzen aufbauen Alterungs-Eigenschaften berücksichtigen Dokumentieren Mehr als nur eine Momentaufnahme 37

Daten-nahe Transformation im DWH Den richtigen Platz finden Quellsystem DWH-System n-tier n-tier Application Server ETL? Application Server ETL? 38

Aktivitäten in einem ETL-Prozess Standardfunktionen Insert, Update, Delete, Merge (Insert / Update) 1:1-Transformationen (reines Kopieren, auch mit minimalen Änderungen) Selektionen (z.B. Where-Klauseln, Bedingungen) Gruppierende Transformationen (Aggregationen, Sortieren, Segmentieren) Pivotierende Transformationen (Verändern der Kardinalität von Zeilen und Spalten) Berechnungen (einfache oder komplexe, Funktionen oder Programme) Formatieren von Daten Zusammenführende und spaltende Transformationen (Join / Split) Anreichernde Transformationen (Referenzen auslesen, Lookups, Konstanten, Fallunterscheidungen) Aussortieren / Trennen von Datenbereichen Prüflogik (logisch / fachliche und physisch / technische) Protokollierende Maßnahmen (Log Files, Statistiken) Steuerungen (Rules-Systeme) Kommunizieren mit anderen Systemen (Messages senden / empfangen / quittieren) 39

Generieren statt Programmieren Vorteile einer Tool-Unterstützung Vermindern von Fehlern durch Handprogrammierung Tabellen- und Spaltennamen müssen nicht mehr mühsam geschrieben werden Steuerung vieler Entwicklungsschritte durch Wizards Automatische Steuerung von Ziel- und Quellschemata Automatische Validierung (z.B. Typverträglichkeiten) Debugging der Laderoutinen Laufzeitumgebung steht bereit Wichtigster Grund: Dokumentation In der ETL – Tool – Diskussion ist immer darüber gestritten worden, ob es günstiger ist Laderoutinen von Hand zu programmieren oder Tools einzusetzen. Die Entscheidung ist längst gefallen, Tools haben sich durchgesetzt. 40 40

Balance zwischen den beteiligten Komponenten finden DWH-Datenbank ETL-Engine ETL-Server DWH-Server

Balance zwischen den beteiligten Komponenten finden DWH-Datenbank ETL-Engine ETL-Server DWH-Server

Balance zwischen den beteiligten Komponenten finden Dokumentation Steuerung Benutzerfühung Rechen-Power Ausnutzen von bestehenden Ressource DWH-Datenbank ETL-Engine ETL-Server DWH-Server

Themen Ziele Oracle DWH Architektur zur Einordnung Anforderungen an den ETL Prozess Hilfsmittel in der Datenbank Vorgehensweise im ETL-Prozess Hardware und Umgebungsarchitektur

Hilfsmittel in der Datenbank (Auflistung) Parallelisierung Partitioning / Partition Exchange Load (PEL) Direct Path Load Set-Based SQL Pipelined Table Functions Materialized Views Kopiertechniken External Tables / Loader Transportable Tablespace Data Pump Database Link Direkt FTP-Load

Parallelisierung Oracle Data Warehouse 46 46

Parallelisierung und Skalierung Abfragen SELECT JOIN-Operationen SORT-Operationen GROUP BY DDL CREATE TABLE / MV CREATE INDEX Online Index Rebuild DML INSERT UPDATE / DELETE MOVE / SPLIT PARTITION CPU SQL seriell 100% 50% I/O 100% 50% parallel SQL CPU I/O Notes: (serial: difficult to monitor a CPU bottle neck) Ein SQL Statement wird vom Optimizer in kleinere Arbeitsschritte aufgeteilt und läuft skalierbar ab. 47

Monitoring der Parallelität Abgeschlossene SQL-Jobs Laufender SQL-Job mit Parallelität 8 SQL-Job in Warteposition

Parallelisierung eines Statements Potentiell höherer Bedarf Automatisches Downgrade Statement in Warteposition (Queue)

Master-/ Slave-Prozesse (Parallelisierung)

Ausführungsplan einer parallelisierten Abfrage

Voraussetzungen für Parallelisierung Hardware-Architektur Symmetric Multiprocessors (SMP) Clusters (RAC, Grid Computing) Massively Parallel Processing (MPP) Ausreichend I/O-Bandbreite Geringe oder mittlere CPU-Auslastung Systeme mit CPU-Auslastungen von weniger als 30% Genügend Hauptspeicher für speicherintensive Prozesse Sortierung Hashing I/O-Puffer 52

Degree of Parallelism (DOP) Automatic Degree of Parallelism PARALLEL_DEGREE_POLICY = AUTO Degree of Parallelism manuell festlegen ALTER TABLE sales PARALLEL 8; ALTER TABLE customers PARALLEL 4; Default Parallelism ALTER TABLE sales PARALLEL; Parallelisieren von Abfragen SELECT /*+ PARALLEL(b)n PARALLEL(a)n */ a,b,c FROM bestellung b, artikel a; SI : DOP = PARALLEL_THREADS_PER_CPU x CPU_COUNT RAC: DOP = PARALLEL_THREADS_PER_CPU x CPU_COUNT x INSTANCE_COUNT 53

Kontrolle über Parallelisierung behalten Parameter PARALLEL_DEGREE_POLICY Manual Verhalten wie vor 11gR2, der DBA konfiguriert alles manuell Kein Automated DOP Kein Statement Queuing Keine In-Memory Parallel Execution Limited Eingeschränkter Automated DOP für Abfragen auf Tabellen mit Default Parallelisierung Auto Alle in Frage kommenden Statements werden parallel ausgeführt Statement Queuing In-Memory Parallel Execution Prior to 11gR2 customers had to manual determine what DOP a statement should run with. With no clear guide on how to determine the ideal DOP, customers would generally decide on a DOP for an object (table, index) and all statements accessing that object would use the same DOP. But one DOP may not be suitable for all statements. The only other alternative was to use a different PARALLEL hint for each statement, but a lot of third-party applications do not allow hints to be used and even if you could put a hint for every statement it would mean a time consuming tuning exercise every time a new statement got added to the system. In 11gR2 Oracle automatically decides if a statement should execute in parallel or not and what DOP it should use. Oracle will also decide if the statement can execute immediately or if it should be queued until more system resources are available. Finally Oracle will decide if the statement can take advantage of the aggregated cluster memory or not (IN-Memory PQ) 54

Funktionsweise von Automated DOP Statement wird geparsed Optimizer ermittelt Execution Plan SQL Statement Geschätzte Ausführung ist größer als Schwellwert Optimizer bestimmt idealen DOP Tatsächlicher DOP = MIN(Default DOP, idealer DOP) Geschätzte Ausführung ist kleiner als Schwellwert PARALLEL_MIN_TIME_THRESHOLD Statement wird parallel ausgeführt Statement wird seriell ausgeführt 55

Parameter für Parallel Query Oracle 11.2.0.1 Neue Parameter parallel_degree_limit = 'CPU' (CPU|IO|integer) parallel_degree_policy = MANUAL (MANUAL|LIMITED|AUTO) parallel_force_local = FALSE (FALSE|TRUE) parallel_min_time_threshold = AUTO (AUTO|integer) parallel_servers_target = 8 (0 - max_servers) Parameter parallel_adaptive_multi_user = TRUE (TRUE|FALSE) parallel_execution_message_size = 16384 (2148 – 32768) parallel_instance_group = '' () parallel_max_servers = 20 (0 - 3600) pro Instanz parallel_min_percent = 0 (1 - 100) % parallel_min_servers = 0 (0 - max_servers) parallel_threads_per_cpu = 2 (1 - 4|8) pro core Veraltete Parameter parallel_automatic_tuning = FALSE (FALSE|TRUE) parallel_io_cap_enabled = FALSE (FALSE|TRUE) 56

Partition Exchange Load Partitioning / Partition Exchange Load Oracle Data Warehouse 57

Partitioning unterstützt viele Aufgaben Query Performance Partition Pruning Ladeprozess Partitioning Unterstützung ILM (Information Lifecycle Management) Leichterer Umgang mit Indizierung Unterstützung im Backup-Prozess Unterstützung bei der Komprimierung Partitionierungs- Kriterium fachlich anwendbar oder nicht? Unterstützung bei der Aktualisierung von Materialized Views (Partition Change Tracking) Hochverfügbarkeit auch während des Ladens und Maintenance Partitioning Typ: - Range - List - Hash 58

Partitioning – Die Grundfunktionalität Kollektive Sicht Partition-bezogene Sicht Performance Manageability Separate Compression Read Only TS versch. Platten Basis für ILM Hilfsmittel im ETL PEL Local Indexing Availability Backup / Recovery Scheduled Downtime Archiving Local Index SELECT.... FROM.... Global Partitioned Index Global Index ADD, DROP, SPLIT, MOVE, MERGE, TRUNCATE, COMPRESS 59

Verschiedene Varianten Partitioning-Typen Range List Hash Reference Interval System Virtual Column Subpartitioning-Typen Range - Hash Range - List Range - Range List - Range List - Hash List - List 60

Partition Exchange Loading (PEL) -- Leere Partition an Zieltabelle hinzufügen ALTER TABLE Bestellung ADD PARTITION "Nov08" VALUES LESS THAN (to_date('30-Nov-2008','dd-mon-yyyy')); -- Neue leere temporäre Tabelle erstellen CREATE TABLE Bestellung_temp AS SELECT * FROM Bestellung WHERE ROWNUM < 1; -- Inhalte laden INSERT INTO "PART"."BESTELLUNG_TEMP" (BESTELLNR, KUNDENCODE, BESTELLDATUM, LIEFERDATUM, BESTELL_TOTAL, AUFTRAGSART, VERTRIEBSKANAL) VALUES ('2', '3', TO_DATE('23.Nov.2008', 'DD-MON-RR'), to_date('23.Nov.2008', 'DD-MON-RR'), '44', 'Service', '6'); Commit; -- Erstellen Index auf temporäre Tabelle CREATE INDEX Ind_Best_Dat_Nov ON Bestellung_temp ("BESTELLNR") NOLOGGING PARALLEL; -- Temporäre Tabelle an die Zieltabelle anhängen ALTER TABLE Bestellung EXCHANGE PARTITION "Nov08" WITH TABLE Bestellung_temp INCLUDING INDEXES WITHOUT VALIDATION; 1 2 3 4 5 61

Partition Exchange Loading (PEL) Temporäre Tabelle Financial Production Neuer Monat Human Res. P1 P2 P3 P4 4 8 9 Z1 Z2 Z3 Z4 Zeit Store Supplier Monat 13 Marketing Parallel Direct Path INSERT (Set Based) CREATE TABLE AS SELECT (CTAS) CREATE Indizes / Statistiken anlegen EXCHANGE Tabelle Monat 12 Service Monat 11 Monat 10 Region DROP PARTITION Unvergleichbar schnell! Faktentabelle 62

Wie wird partitioniert Partition Key Eine oder mehrere Spalten in der Tabelle bestimmen den tatsächlichen Speicherort eines Datensatzes Separate Tablespaces Pro Partition einen eigenen Tablespace  Vereinfachte Wartung Tablespace Segment Extent Blocks 63

Direct / Convential Path Load Oracle Data Warehouse 64

Direct Path / Convential Path SQL Loader External Table Insert Append CTAS Benutzer SQL Command Processing Space Management Get new extents Adjust High Water Mark Find partial blocks Fill partial blocks Buffer Cache Buffer Cache Management Manage queues - Manage contention Read Database Blocks Write Database Direct Path Database Oracle Server Convential Path Reuse Free Space in Blöcken Constraint Checks Undo Data / Logging Daten zunächst immer in SGA Buffer Direct Path Schreiben oberhalb der High Water Marks Keine Constraint Checks Kein Logging Daten nicht in SGA Buffer

Set Based SQL Oracle Data Warehouse 66

Varianten von Prüfungen Attribut-bezogen Not Null / Pflichtfelder Formatangaben Check Constraint Wertbereiche Ober-/Untergrenzen / Wertelisten Satz-bezogen (Tupel) Abhängigkeiten von Werten in anderen Attributen desselben Satzes Satz-übergreifend (Relationen) Primary Key / Eindeutigkeit Aggregat – Bedingungen Ober- Untergrenzen von Summen Anzahl Sätze pro Intervall usw. Rekursive Zusammenhänge Verweise auf andere Sätze derselben Tabelle (Relation) Tabellen-übergreifend (interrelational) Foreign Key Aggregat – Bedingungen Ober- Untergrenzen von Summen Anzahl Sätze pro Intervall usw. Rekursive Zusammenhänge Verweise auf Sätze einer anderen Tabelle (Relation) Zeit-bezogen (Tupel) Zeitinvariante Inhalte Anz. Bundesländer Zeitabhängige Veränderungen Über die Zeit mit anderen Daten korrelierende Feldinhalte Verteilungs-bezogen Arithmetische Mittel Varianz / Standardabweichungen Qualitätsmerkmale und Mengen 67

Prüfkonzepte Einfach implementierbar Fachliche Prüfungen kaum möglich Bessere Performance Nur bei aktivierten Constraints Fachliche Prüfungen kaum möglich Eventuell zusätzliche Prüfungen nötig Stage-Tabelle + Geprüfte Daten Statistik Routine Statistiken Date Number Varchar2() Kopieren Check Constraints Bad File Fehlerhafte Sätze DML Error Log 68

Error Logging Constraints Unique Key / Primary Key Foreign Key NOT NULL Check Constraint Kunde KUNDENNR VORNAME NACHNAME ORTNR STRASSE TELEFON INSERT INTO Kunde VALUES (......) LOG ERRORS INTO kunde_err('load_20040802') Kunde_err KUNDENNR VORNAME NACHNAME ORTNR STRASSE TELEFON ORA_ERR_NUMBER$ ORA_ERR_MESG$ ORA_ERR_ROWID$ ORA_ERR_OPTYP$ ORA_ERR_TAG$ 69

Error Logging: Beispiel 70

Check Constraint mit Regular Expressions CREATE TABLE Check_KUNDE ( KUNDENNR NUMBER, GESCHLECHT NUMBER, VORNAME VARCHAR2(50), NACHNAME VARCHAR2(50), ANREDE VARCHAR2(10), GEBDAT DATE, ORTNR NUMBER, STRASSE VARCHAR2(50), TELEFON VARCHAR2(30) ); Regel: Im Kundennamen müssen Buchstaben vorkommen und keine reine Zahlenkolonne ALTER TABLE check_kunde ADD CONSTRAINT Ch_KD_Name CHECK(REGEXP_LIKE(NACHNAME, '[^[:digit:]]')); INSERT INTO check_kunde (Kundennr, Geschlecht, Vorname, Nachname, Anrede, Gebdat, Ortnr, Strasse, Telefon) VALUES (9,1,'Klaus','123','Herr','01.01.60',2,'Haupstr.',08923456); FEHLER in Zeile 1: ORA-02290: CHECK-Constraint (DWH.CH_KD_NAME) verletzt 71

Beispiele Modus Zeichenklassen * Match 0 or more times ? Match 0 or 1 time + Match 1 or more times {m} Match exactly m times {m,} Match at least m times {m, n} Match at least m times but no more than n times \n Cause the previous expression to be repeated n times Modus [:alnum:] Alphanumeric characters [:alpha:] Alphabetic characters [:blank:] Blank Space Characters [:cntrl:] Control characters (nonprinting) [:digit:] Numeric digits [:graph:] Any [:punct:], [:upper:], [:lower:], and [:digit:] chars [:lower:] Lowercase alphabetic characters [:print:] Printable characters [:punct:] Punctuation characters [:space:] Space characters (nonprinting), such as carriage return, newline, vertical tab, and form feed [:upper:] Uppercase alphabetic characters [:xdigit:] Hexidecimal characters Zeichenklassen 72

Performance Regular Expressions sind schnelle Operartionen in der Datenbank Verwendung von Regular Expressions steigert die Performance bei Prüfungen von Formaten Daten müssen nicht mehrfach gelesen werden 73

Arbeiten ohne Constraints Constraints stören bei Massenaktionen im DWH  Ausschalten der Constraints Übernahme der Aufgaben von Constraints durch ETL-Prozess Mengen-basierte Vorgehensweise spool test.sql select 'alter table '||table_name||' disable constraint '||constraint_name||';' from user_constraints where table_name=('TABELLENNAME'); spool off 74

Was kann mit SQL geprüft werden Formatprüfungen Feldtypen Stringformate, Ausdrücke NOT NULL Eindeutigkeit Wertebereiche Spaltenübergreifende Table_Checks Inhaltliche Regeln 75

Wichtiges Hilfsmittel: CASE-Anweisung SELECT CASE WHEN isnumeric('999') = 1 THEN 'numerisch' ‚ ELSE 'nicht numerisch'‚ END Ergebnis FROM dual; CREATE OR REPLACE FUNCTION isnumeric ( p_string in varchar2) return boolean AS l_number number; BEGIN l_number := p_string; RETURN 1; EXCEPTION WHEN others THEN RETURN 0; END; 76

Abarbeitungslogik mit CASE OLTP_Kunden_tmp Bestellnr Menge Summe Name Ort BestDatum OLTP_Kunden Bestellnr Menge Summe Name Ort BestDatum INSERT INTO OLTP_Kunden_tmp SELECT Bestellnr,Menge,Summe,Name,Ort,BestDatum, CASE WHEN (Bestellnr is NULL) then 1 ELSE 0 END Bestellnr_isNull, CASE WHEN (isNumeric(Menge) = 1) END Menge_isNumeric, CASE WHEN (isNumeric(Summe) = 1) END Summe_isNumeric, CASE WHEN (Summe is NULL) END Summe_isNull, CASE WHEN (isDate(BestDatum) = 1) END BestDatum_isDate FROM OLTP_Kunden; Bestellnr_isNull Menge_isNumeric Summe_isNumeric Summe_isNull BestDatum_isDate ...

Hilfsfunktion: Is Number create or replace function isNumeric(i_value_to_check varchar2) return number is v_dummy number; begin v_dummy := to_number( i_value_to_check); return 1; -- it's number exception when others then return -1; -- it's invalid end isNumeric; 78

Hilfsfunktion: Date_Check BEGIN inDate:= trim(str); if dateCheck(inDate, 'mm-dd-yyyy') = 'false' AND dateCheck(inDate, 'mm-dd-yy') = 'false' AND dateCheck(inDate, 'yyyy-mm-dd') = 'false' AND dateCheck(inDate, 'yy-mm-dd') = 'false' AND dateCheck(inDate, 'yyyy-mon-dd') = 'false‚ AND dateCheck(inDate, 'yy-mon-dd') = 'false‚ AND dateCheck(inDate, 'dd-mon-yyyy') = 'false‚ AND dateCheck(inDate, 'dd-mon-yy') = 'false‚ AND dateCheck(inDate, 'mmddyy') = 'false‚ AND dateCheck(inDate, 'mmddyyyy') = 'false‚ AND dateCheck(inDate, 'yyyymmdd') = 'false' AND dateCheck(inDate, 'yymmdd') = 'false‚ AND dateCheck(inDate, 'yymmdd') = 'false' AND dateCheck(inDate, 'yymondd') = 'false‚ AND dateCheck(inDate, 'yyyymondd') = 'false‚ AND dateCheck(inDate, 'mm/dd/yyyy') = 'false' AND dateCheck(inDate, 'yyyy/mm/dd') = 'false‚ AND dateCheck(inDate, 'mm/dd/yy') = 'false' AND dateCheck(inDate, 'yy/mm/dd') = 'false‚ AND dateCheck(inDate, 'mm.dd.yyyy') = 'false' AND dateCheck(inDate, 'mm.dd.yy') = 'false' AND dateCheck(inDate, 'yyyy.mm.dd') = 'false' AND dateCheck(inDate, 'yy.mm.dd') = 'false' then return 'false'; else return 'true'; end if; --exception --when others then return 'false'; END; create or replace function IsDate (str varchar2) return varchar2 is inDate varchar2(40); FUNCTION dateCheck (inputDate varchar2, inputMask varchar2) RETURN varchar2 IS dateVar date; BEGIN dateVar:= to_date(inputDate,inputMask); return 'true'; exception when others then return 'false'; END; In Verbindung mit der CASE-Anweisung 79

Prüfung auf Eindeutigkeit SELECT F1 FROM (SELECT count(F1) n,F1 FROM s GROUP BY F1) WHERE n > 1; INSERT INTO el_kunde (kundennr,vorname,nachname,ortnr,strasse,telefon) SELECT src2.nummer, src2.name, FROM SRC2, (SELECT nummer FROM (SELECT count(nummer) n, nummer FROM src2 group by nummer) WHERE n = 1) doppelte WHERE src2.nummer = doppelte.nummer; 80

Inhaltliche Abhängigkeit von zwei Feldern Die satzübergreifende Reihenfolge von den Werten einer Spalte muss mit der Reihenfolge in einer anderen Spalte übereinstimmen ? 81

Tabellenübergreifender Summenvergleich Select * from (select bestellnumme, gesamtsumme from Bestellung) best, (select Bestellnummer , sum(Positionssumme) gesamtsumme from Bestellposition group by Bestellnummer) Pos where best.bestellnummer = pos.bestellnummer and best.gesamtsumme = pos.gesamtsumme Bestellung Bestellnummer (PK) Gesamtsumme Bestellposition = Bestellnummer (FK) Positionssumme 82

Native Support für Pivot und Unpivot SALESREP QU REVENUE ---------- -- ---------- 100 Q1 230 100 Q2 240 100 Q3 260 100 Q4 300 101 Q1 200 101 Q2 220 101 Q3 250 101 Q4 260 102 Q1 260 102 Q2 280 102 Q3 265 102 Q4 310 Sinnvoller Einsatz im Rahmen des ETL-Prozesses SALESREP Q1 Q2 Q3 Q4 ---------- ----- ----- ----- ----- 100 230 240 260 300 101 200 220 250 260 102 260 280 265 310 83

Native Support für Pivot und Unpivot SALESREP QU REVENUE ---------- -- ---------- 100 Q1 230 100 Q2 240 100 Q3 260 100 Q4 300 101 Q1 200 101 Q2 220 101 Q3 250 101 Q4 260 102 Q1 260 102 Q2 280 102 Q3 265 102 Q4 310 Sinnvoller Einsatz im Rahmen des ETL-Prozesses QUARTERLY_SALES SALESREP Q1 Q2 Q3 Q4 ---------- ----- ----- ----- ----- 100 230 240 260 300 101 200 220 250 260 102 260 280 265 310 select * from quarterly_sales unpivot include nulls (revenue for quarter in (q1,q2,q3,q4))‏ order by salesrep, quarter ; 84

Native Support für Pivot und Unpivot SALES_BY_QUARTER SALESREP QU REVENUE ---------- -- ---------- 100 Q1 230 100 Q2 240 100 Q3 160 100 Q4 90 100 Q3 100 100 Q4 140 100 Q4 70 101 Q1 200 101 Q2 220 101 Q3 250 101 Q4 260 102 Q1 260 Sinnvoller Einsatz im Rahmen des ETL-Prozesses SALESREP 'Q1' 'Q2' 'Q3' 'Q4' ---------- ----- ----- ----- ----- 100 230 240 260 300 101 200 220 250 260 102 260 280 265 310 select * from sales_by_quarter pivot (sum(revenue)‏ for quarter in ('Q1','Q2','Q3','Q4'))‏ order by salesrep ; 85

Multiple Inserts INSERT ALL WHEN STATUS = 'P'‚ THEN INTO WH_TRANS_PRIVAT (BESTELLMENGE,KUNDENCODE,BESTELL_TOTAL,STATUS) VALUES (BESTELLMENGE$1,KUNDENCODE$1,BESTELL_TOTAL$1,STATUS) WHEN STATUS = 'F'‚ THEN INTO WH_TRANS_FIRMA (BESTELLMENGE,KUNDENCODE,BESTELL_TOTAL,STATUS) VALUES (BESTELLMENGE$1,KUNDENCODE$1,BESTELL_TOTAL$1,STATUS) SELECT WH_TRANSAKTIONEN.BESTELLMENGE BESTELLMENGE$1, WH_TRANSAKTIONEN.KUNDENCODE KUNDENCODE$1, WH_TRANSAKTIONEN.BESTELL_TOTAL BESTELL_TOTAL$1, WH_TRANSAKTIONEN.STATUS STATUS FROM WH_TRANSAKTIONEN WH_TRANSAKTIONEN WHERE (WH_TRANSAKTIONEN.STATUS = 'P‚ /*SPLITTER.PRIVATKUNDEN*/) OR (WH_TRANSAKTIONEN.STATUS = 'F‚ /*SPLITTER.FIRMENKUNDEN*/); 86

MERGE INTO "Kunde_TGT" USING (SELECT "KUNDEN_STAMM" MERGE INTO "Kunde_TGT" USING (SELECT "KUNDEN_STAMM"."KUNDENNR" "KUNDENNR", "KUNDEN_STAMM"."VORNAME" "VORNAME", "KUNDEN_STAMM"."NACHNAME" "NACHNAME", "KUNDEN_STAMM"."STATUS" "STATUS", "KUNDEN_STAMM"."STRASSE" "STRASSE", "KUNDEN_STAMM"."TELEFON" "TELEFON", "KUNDEN_STAMM"."TELEFAX" "TELEFAX„ FROM "KUNDEN_STAMM" "KUNDEN_STAMM") MERGE_SUBQUERY ON ( "Kunde_TGT"."KUNDENNR" = "MERGE_SUBQUERY"."KUNDENNR") WHEN NOT MATCHED THEN INSERT ("Kunde_TGT"."KUNDENNR", "Kunde_TGT"."VORNAME", "Kunde_TGT"."NACHNAME", "Kunde_TGT"."STATUS", "Kunde_TGT"."STRASSE", "Kunde_TGT"."TELEFON", "Kunde_TGT"."TELEFAX") VALUES ("MERGE_SUBQUERY"."KUNDENNR", "MERGE_SUBQUERY"."VORNAME", "MERGE_SUBQUERY"."NACHNAME", "MERGE_SUBQUERY"."STATUS", "MERGE_SUBQUERY"."STRASSE", "MERGE_SUBQUERY"."TELEFON", "MERGE_SUBQUERY"."TELEFAX") WHEN MATCHED THEN UPDATE SET "VORNAME" = "MERGE_SUBQUERY"."VORNAME", "NACHNAME" = "MERGE_SUBQUERY"."NACHNAME", "STATUS" = "MERGE_SUBQUERY"."STATUS", "STRASSE" = "MERGE_SUBQUERY"."STRASSE", "TELEFON" = "MERGE_SUBQUERY"."TELEFON", "TELEFAX" = "MERGE_SUBQUERY"."TELEFAX"; MERGE-Funktion Funktion MERGE dient dem gleichzeitigen INSERT und UPDATE Basierend auf dem Matching des definierten Schlüssels (ON-Klausel) Auch DELETE-Operationen möglich Into - Zielobjekt Using – betrachtete Daten ON – Bedingung 87

Bildung künstlicher Schlüssel Anwendung 1 Verkaufsregion Einkommensgruppe Data Warehouse Wohnart Verkaufsregion Berufsgruppe Einkommensgruppe Anzahl Kinder Wohnart Alter ... Name PLZ Kunden_NR Ort Anwendung 2 Kunden_NR Tel Partnernummer PLZ Dim_Kd_NR Neuer Schlüssel Ort Strasse Partnernummer Sequence 88

Key Lookup Dimension Fakten Bewegungsdaten Künstl. Schlüssel (Primary Key) Log.Business Schlüssel (Alternate Unique) 6 KD_66 Stamm Info Stamm Info Stamm Info 5 KD_55 Stamm Info Stamm Info Stamm Info 4 KD_44 Stamm Info Stamm Info Stamm Info 3 KD_33 Stamm Info Stamm Info Stamm Info 2 KD_22 Stamm Info Stamm Info Stamm Info 1 KD_11 Stamm Info Stamm Info Stamm Info Join Lookup Log.Business Schlüssel Satz12 AA 34 dddf KD_11 1 DFG 64 dloidf Satz13 DFG 64 dloidf KD_22 2 DFG 64 dloidf ? Satz14 erf 78 ghzf KD_33 3 erf 78 ghzf Satz15 sdfg 4456 llkof KD_44 4 sdfg 4456 llkof Fakten Bewegungsdaten 89

Lookup-Verfahren mit Aktualisierung (Stammdaten) Bewegungs- sätze Join Zielsätze Anti – Join Referenzdaten Tmp Table alle Sätze ohne Referenz Insert mit Dummy – Schlüssel Protokoll 90

Dimension Bewegungsdaten Fakten Künstl. Schlüssel (Primary Key) Log.Business Schlüssel (Alternate Unique) Sequenz Dimension Next Val 7 7 Dummy KD_99 1 Stamm Info 2 3 4 5 KD_11 KD_22 KD_33 KD_44 KD_55 6 KD_66 1. Schritt Anti - Join Wenn nicht in Dimension enthalten dann INSERT INTO Dim SELECT .... FROM Bew, Dim WHERE Log Key NOT IN Dim 2. Schritt Join Lookup Log.Business Schlüssel Satz12 XX 567 ddwer KD_99 7 XX 567 ddwer Satz12 AA 34 dddf KD_11 1 DFG 64 dloidf Satz13 DFG 64 dloidf KD_22 2 DFG 64 dloidf Satz14 erf 78 ghzf KD_33 3 erf 78 ghzf Satz15 sdfg 4456 llkof KD_44 4 sdfg 4456 llkof 91 Bewegungsdaten Fakten

Table Functions Oracle Data Warehouse 92 92 92

Table Functions – Pipeline-Verfahren tf1 tf2 Quelle Ziel tf3 Stage_tabelle INSERT INTO Ziel SELECT * FROM (tf2(SELECT * FROM (tf1(SELECT * FROM Quelle)))) INSERT INTO Ziel SELECT * FROM tf( SELECT * FROM (Stage_tabelle)) 93

Begriffe im Bereich Table Functions Funktionen, die eine Gruppe von Sätzen (SET) gleichzeitig bearbeitet. Table Functions wirken wie physische Tabellen. Entsprechend werden sie auch in der FROM Klausel verwendet. Record Type Ein komplexer, aus mehreren Feldern zusammengesetzter Datentyp. Nested Table Eine Art virtuelle Tabelle (temporäre Tabelle im Speicher). Eine Table Function kann eine solche Tabelle komplett an das aufrufende Kommando zurückgeben. Ref Cursor Eine Art Pointer auf ein Result – Set einer Abfrage. Man übergibt einen Ref Cursor einer Table Function, damit diese die Sätze des Result – Sets innerhalb der Function abarbeitet. Parallel Table Functions können eingehende Sätze parallel bearbeiten, wenn diese als Ref Cursor übergeben werden. Pipelined Eine Table Function reicht bereits fertige Sätze an das aufrufende Kommando zur weiteren Verarbeitung weiter, während sie noch weitere Sätze bearbeitet. 94

Mengenbasierte Verarbeitung Trotz Programmierung INSERT INTO Table SELECT Feld1, Feld2 FROM Schnelle Verarbeitung (Pipelined) Objekttechnik Parallelisierung Mehrere Rückgabewerte und Einzelrückgaben Cursor als Input Schachtelbar Table_Function( ) Funktion Cursor Fetch Loop If a = b... Update... Case... Parallel eingesetzte Techniken Materialized Views Query Rewrite Verwendung von Dimension Tables pipe row(record Type) Variante 1 Variante 2 Return Table 95

Die Hilfstypen für Daten und Cursor drop type Bestellung_X_t; create type Bestellung_X_t as object ( BESTELLNR NUMBER(10), KUNDENCODE NUMBER(10), BESTELLDATUM DATE, LIEFERDATUM DATE, BESTELL_TOTAL NUMBER(12,2), Fehler_Datum DATE); drop type Bestellung_X_t_table; create type Bestellung_X_t_table as TABLE of Bestellung_X_t; create or replace package cursor_pkg as type Bestellung_t_rec IS RECORD ( BESTELLNR NUMBER(10), KUNDENCODE NUMBER(10), BESTELLDATUM DATE, LIEFERDATUM DATE, BESTELL_TOTAL NUMBER(12,2)); END; Definition Record-Type Definition Nested-Table auf der Basis des Rekord-Types Definition Cursor als Typ des Übergabeparameters 96

Die Table Function Übernahme von Ausgangssätzen als Cursor create or replace function f_Bestellung_X(cur cursor_pkg.refcur_t) RETURN Bestellung_X_t_table IS BESTELLNR NUMBER(10); KUNDENCODE NUMBER(10); BESTELLDATUM DATE; LIEFERDATUM DATE; BESTELL_TOTAL NUMBER(12,2); Fehler_Datum DATE; ORDER_ID NUMBER(10); objset Bestellung_X_t_table := Bestellung_X_t_table(); i number := 0; begin LOOP -- read from cursor variable FETCH cur into BESTELLNR,KUNDENCODE, BESTELLDATUM,LIEFERDATUM,BESTELL_TOTAL,ORDER_ID; -- ext when last row EXIT WHEN cur%NOTFOUND; i := i+1; if substr(to_char(LIEFERDATUM,'YYYY.MM.YY'),1,4) >2002 then Fehler_Datum := to_date('9999.12.12','YYYY.MM.DD'); else Fehler_Datum := LIEFERDATUM; End if; objset.extend; objset(i) := Bestellung_X_t(BESTELLNR,KUNDENCODE, BESTELLDATUM,LIEFERDATUM,BESTELL_TOTAL,Fehler_Datum); END LOOP; CLOSE cur; Return objset; END; Definieren einer Nested-Table-Struktur für die spätere Rückgabe. Lesen aus Cursor Erweitern Nested-Table um einen Satz und Überführen eines Satzes in die Nested-Table Rückgabe der kompletten Tabelle an das aufrufende Statement (Alternative zu PIPE). 97

Beispielaufrufe Kapseln von Table Function – Aufrufen: insert into bestellung_X select * from TABLE(f_Bestellung_X(CURSOR(SELECT * from Bestellung))) select * from TABLE(f_bestellung(CURSOR(SELECT * from Bestellung))) select count(*) from TABLE(f_bestellung(CURSOR(SELECT * from Bestellung)) Kapseln von Table Function – Aufrufen: create view VWTF (anzahl) as select count(*) from TABLE(f_bestellung_y()); 98

Materialized Views spart ETL-Aufwand Oracle Data Warehouse 99

Prinzip und Aufgabenstellung Summentabellen Basistabelle Summentabelle Complete Refresh Incremental Refresh ? Änderungen stale 100

Nachteile Summentabellen Kein automatisches Erkennen von „Staleness“ Zusätzlicher ETL-Aufwand Fehlende Inkrementelle Aktualisierung Eingriff auf die Benutzeraktivitäten Benutzer müssen Namen der Summentabelle wissen

Aufgaben der Materialized Views (MAVs) Erleichtern das Management von Summentabellen Wegfall von Erstellungsprozeduren Einfache Steuerung des Zeitpunktes zur Aktualisierung Eventuell Beschleunigung der Aktualisierung (inkrementelles Refresh) Abfrage-Performance optimieren Variable Kennzahlensysteme aufbauen Mehrstufige MAVs Abfragegruppen zusammenfassen (Kategorisierung) Geschäftsobjekt-bezogene MAVs MVS erstetzen Programmierung – WestLB Fall (Java) Einheitliche Sicht zu einem festgelegten Zeitpunkt – aktuelle Zahlen bis 15 Uhr 1 MV pro Kennzahl Anwender denken in Geschäftsobjekte (Joins von Tabellen) 102

Physische Eigenschaften von MAVs Speicherung / Plattenplatz Speicherung von MAVs Angabe einer Storageklausel möglich Können in separatem Tablespace angelegt werden Belegen Plattenplatz Nicht mehr als klassische Summentabellen Komprimierung vom MAVs möglich 103

MAV-Erstellung und erstmaliges Füllen BUILD IMMEDIATE (direkt bei der Erstellung, default) Problematisch bei großen Basistabellen und im Rahmen von Entwicklung / Test BUILD DEFERRED (Erstellung beim ersten Refresh) Sinnvoll bei erster Überführung neuer MAV-Definitionen in die Produktionsumgebung ON PREBUILD Sinnvoll, wenn es separate Erstellungroutinen gibt, die ihr Ergebnis nur in einer Tabelle ablegen können, man aber die Rewrite-Vorteile der MAVs nutzen will Kopie von normalen Views (analog zum vorigen Punkt) 104

Refresh-Funktionen COMPLETE FAST (inkrementell) Immer vollständiges Neuladen aus den Basistabellen FAST (inkrementell) Nur bei vorhandenem MAV Log auf der Basistabelle FORCE (inkrementell oder komplett, default) Je nach der zu erwartenden Refresh-Dauer NEVER Vorhalten historischer Bestände oder bei separater Prozedur ON COMMIT (oft bei OLTP) Commit einer Transaktion auf der Basistabelle ON DEMAND (sinnvoll im DWH, default) 105

Beispiel einer Materialized View CREATE MATERIALIZED VIEW MV_Standard BUILD IMMEDIATE REFRESH COMPLETE ON DEMAND ENABLE QUERY REWRITE AS SELECT z.jahr_nummer Jahr, z.monat_desc Monat, sum(u.umsatz) Summe, a.artikel_id ID, count(u.umsatz) FROM f_umsatz u, d_artikel a, d_zeit z WHERE a.artikel_id = u.artikel_id AND u.zeit_id = z.datum_id GROUP BY z.jahr_nummer, z.monat_desc, a.artikel_id; 106

Testen und Ablaufbedingungen einer MAV set autotrace on; -- Anzeige des Ausführungsplans show parameter query query_rewrite_enabled TRUE -- erlaubt das Query Rewrite query_rewrite_integrity STALE_TOLERATED -- erlaubt Query Rewrite, auch wenn -- die Daten in der Basistabelle -- nicht mehr aktuell sind query_rewrite_integrity TRUSTED -- auch deklarierte -- Basis-Informantionen gelten -- als korrekt (z. B. Views oder -- prebuild) query_rewrite_integrity ENFORCED -- Daten müssen stimmen -- Ändern der Parameter mit ALTER SESSION SET query_rewrite_enabled=TRUE; ALTER SESSION SET query_rewrite_enabled=FALSE; Accuracy of Query Rewrite Query rewrite offers three levels of rewrite integrity that are controlled by the initialization parameter QUERY_REWRITE_INTEGRITY, which can either be set in your parameter file or controlled using an ALTER SYSTEM or ALTER SESSION statement. The three values it can take are: ENFORCED This is the default mode. The optimizer will only use materialized views that it knows contain fresh data and only use those relationships that are based on ENABLED VALIDATED primary/unique/foreign key constraints. TRUSTED In TRUSTED mode, the optimizer trusts that the data in the materialized views is fresh and the relationships declared in dimensions and RELY constraints are correct. In this mode, the optimizer will also use prebuilt materialized views or materialized views based on views, and it will use relationships that are not enforced as well as those that are enforced. In this mode, the optimizer also 'trusts' declared but not ENABLED VALIDATED primary/unique key constraints and data relationships specified using dimensions. STALE_TOLERATED In STALE_TOLERATED mode, the optimizer uses materialized views that are valid but contain stale data as well as those that contain fresh data. This mode offers the maximum rewrite capability but creates the risk of generating inaccurate results. If rewrite integrity is set to the safest level, ENFORCED, the optimizer uses only enforced primary key constraints and referential integrity constraints to ensure that the results of the query are the same as the results when accessing the detail tables directly. If the rewrite integrity is set to levels other than ENFORCED, there are several situations where the output with rewrite can be different from that without it.

DBMS_MVIEW (Refresh-Funktion) Refresh-Funktionen REFRESH REFRESH_DEPENDENT REFRESH_ALL_MVIEW REFRESH_DEPENDENT REFRESH Refresh-Methoden (optional) COMPLETE (C) FAST (F) FORCE (default) (?) PARTITIONED (P) REFRESH_ALL_MVIEW COMPLETE C) -> immer komplettes Lesen der Basis-Tabelle FAST (F) -> Inkremtentelles Lesen, wenn möglich (View-Log oder PCT) FORCE (default) (?) -> beide vorgenannte Varianten, abhängig von der dafür benötigten Zeit Transaktionsverhalten (optional) ATOMIC_REFRESH REFRESH_AFTER_ERRORS NESTED EXECUTE DBMS_MVIEW.REFRESH('MV_STANDARD‘,'C'); COMPLETE C) -> immer komplettes Lesen der Basis-Tabelle FAST (F) -> Inkremtentelles Lesen, wenn möglich (View-Log oder PCT) FORCE (default) (?) -> beide vorgenannten Varianten, abhängig von der dafür benötigten Zeit

DBMS_MVIEW (Refresh-Funktion) ATOMIC_REFRESH => TRUE | FALSE Refresh vollzieht sich in einer Transaktion Im Fehlerfall wird die Transaktion zurückgerollt REFRESH_AFTER_ERRORS => TRUE | FALSE Refresh von mehreren Materialized Views läuft weiter bzw. bricht ab, wenn bei einer MAV ein Fehler aufgetreten ist NESTED Eine Materialized View und alle von ihr abhängigen MAVs werden aktualisiert EXECUTE DBMS_MVIEW.REFRESH('MV_STANDARD‘,'C'); EXECUTE DBMS_MVIEW.REFRESH('MV_STANDARD',atomic_refresh=>TRUE); EXECUTE DBMS_MVIEW.REFRESH('MV_STANDARD',atomic_refresh=>TRUE, nested => TRUE); EXECUTE DBMS_MVIEW.REFRESH('MV_STANDARD',nested=>TRUE); refresh_after_errors If this parameter is true, an updatable materialized view continues to refresh even if there are outstanding conflicts logged in the DEFERROR view for the materialized view's master table or master materialized view. If this parameter is true and atomic_refresh is false, this procedure continues to refresh other materialized views if it fails while refreshing a materialized view. Atomic_refresh If this parameter is set to true, then the list of materialized views is refreshed in a single transaction. All of the refreshed materialized views are updated to a single point in time. If the refresh fails for any of the materialized views, none of the materialized views are updated. If this parameter is set to false, then each of the materialized views is refreshed in a separate transaction. 109

Fast Refresh-Varianten Aktualisierung über MAV Logs Aktualisierung über Partition Change Tracking (PCT) MAV1 MAV2 MAV3 komplett Partition 1 MAV1 Partition 2 MAV2 Partition 3 Partition 4 inkrementell Partition 5 Partition 6 MAV Log Basistabelle Basistabelle WITH ROWID SEQUENCE INCLUDING NEW VALUES Join Dependency Expression Partition Key Partition Marker 110

Fast Refresh mit MAV Log --- MAV Log auf Tabelle D_Artikel DROP MATERIALIZED VIEW LOG ON d_artikel; CREATE MATERIALIZED VIEW LOG ON d_artikel WITH ROWID, SEQUENCE (dimension_key, nummer, artikel_name, artikel_id, gruppe_nr, gruppe_name, sparte_name, sparte_nr) INCLUDING NEW VALUES; --- MAV Log auf Tabelle D_Zeit DROP MATERIALIZED VIEW LOG ON d_zeit; CREATE MATERIALIZED VIEW LOG ON d_zeit (datum_id, datum_desc, tag_des_monats, tag_des_jahres, woche_des_jahres, monats_nummer, monat_desc, quartals_nummer, jahr_nummer) --- MAV Log auf Tabelle F_Umsatz DROP MATERIALIZED VIEW LOG ON f_umsatz; CREATE MATERIALIZED VIEW LOG ON f_umsatz (umsatz, menge, umsatz_nach_rabatt, rabatt_wert_firmenkunde, Rabatt_wert_privatkunde, bestell_datum, artikel_id, kunde_id, region_id, zeit_id) 111

Kopiertechniken beim Laden Trigger in Quelltabelle SQL*Loader Data Pump External Tables Transportable Tablespaces Database Link Oracle Data Warehouse 112 112 112

Herausforderungen beim Extrahieren Unterschiedliche Schema-Namen in Quell- und Zielsystemen Bewahrung der Konsistenz Unterschiedliche GRANTs der User Zusätzlicher Netzwerkverkehr Meist ist nur das Delta der geänderten Daten gewünscht 113

Datenbank-Trigger Werden nur im Quellsystem angelegt Beeinflusst Performance des Quellsystems Eher als Notlösung anzusehen Wenn es kein Änderungsdatum in der Quelltabelle gibt Zum Triggern Message-basierter oder Event-gesteuerter Ladeläufe CREATE OR REPLACE TRIGGER Bestellung BEFORE DELETE OR INSERT OR UPDATE ON Bestellung FOR EACH ROW WHEN (new.Bestellnr > 0) DECLARE sal_diff number; BEGIN INSERT INTO log_Bestellung (Alte_Bestell_Nr,Neue_Bstell_Nr) VALUES(old.Bestellnr,new.Bestellnr); END; / 114

SQL*Loader Loader Modes Convential Path Direct Path INSERT von Daten / UPDATE von Indizes / Auslösen von Triggern Auswertung von Constraints Direct Path Formatieren der Daten in Blöcken und direktes Einfügen in die Datafiles Keine SGA-Operationen / kein INSERT auf SQL-Level Parallel Direct Path Parallele SQL*Loader-Aufrufe Show SQL Loader in OEM Sqlldr Line Modus 115

SQL*Loader – Empfehlungen Direct Path Load nutzen Alle Integrity Constraints ausschalten NOT NULL, Unique und Primary Key Constraints Verhindern von Index-Aktualisierungen UNRECOVERABLE Option wählen Partitionen nach und nach laden Andere Partitionen bleiben für andere Benutzer im Zugriff Parallel laden, wenn es möglich ist Nutzung paralleler Schreib-Threads Alternativ parallele Jobs starten An unrecoverable load does not record loaded data in the redo log file 116

Beispiel - Control File OPTIONS (SKIP=1, BINDSIZE=50000, ERRORS=50, ROWS=200, DIRECT=TRUE, PARALLEL=TRUE, READSIZE=65536, RESUMABLE=TRUE, RESUMABLE_TIMEOUT=7200) UNRECOVERABLE LOAD DATA CHARACTERSET WE8MSWIN1252 INFILE 'C:\orte.csv' BADFILE 'orte.bad' DISCARDFILE 'orte.dis‚ INTO TABLE dwh.tb_orte WHEN ort_id != BLANKS APPEND REENABLE DISABLED_CONSTRAINTS FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY "'" (orte_nr POSITION(1) INTEGER EXTERNAL , ort CHAR , plz CHAR , bundesland CHAR , region CHAR , nummernfeld INTEGER EXTERNAL ) 117

Aufruf des SQL*Loaders sqlldr userid=DWH/DWH control=c:\orte.ctl log=C:\orte.log orte.ctl orte.csv Control File Daten TB_ORTE 118

Data Pump Architektur Werkzeug auch im Oracle Client vorhanden. Allerdings wird server-seitig der Job angestartet. Die Dump-Dateien liegen Serverseitig. D.h. Datendateien werden nicht vom Client zum Server transferiert. Detaching/Attaching des Client- vom Serverprozess möglich. Früher 1:1 Bezug zu Client- u. ServerProzess Eigenes Binary-Format der Datendateien: nicht von alten ex-im-loader lesbar. Data Pump deckt auch Teile der SQL*Loader Funktionalität ab. Allerdings im eigenen Datenformat! Deshalb ist SQL*Loader immer noch wichtig. Quelle: http://www.dbazine.com/blogs/blog-cf/chrisfoot/blogentry.2006-05-26.3042156388 119

Oracle Data Pump Höhere Performance als bei IMP / EXP oder anderen Entlade-Verfahren Daten und / oder Metainformationen von DB Objekten Größere Steuerungsmöglichkeit, d.h. mehr Parameter und Kontrolle der Datenextraktion Leichtere Einbindung der Datenflüsse über Rechnergrenzen hinweg Parallelisierung in RAC-Umgebungen Instanz-übergreifend Kompression u. Verschlüsselung nach Bedarf Legacy Mode zur Weiterverwendung von Ex-/Import Controls Wiederanlauffähig Release 2 Verwendung von Parameter-File wird empfohlen Eingeführt mit Oracle 10gR1 Original Export: “Desupport for general use” in Oracle 11g In Oracle10gR2 Unterstützung aller 10g Features außer XML Schemas und XML Schema based Tables In Oracle 11g keine Einschränkungen Benötigt Schreibzugriff auf DB-Server für master table, Export von readonly DBs via NETWORK_LINK 120

Vereinfachte Verfahrensdarstellung OLTP DWH Import mit Data Pump (impdp) Export mit Data Pump (expdp) FTP Schema OLTP Besondere GRANTs Schema DWH Delta-Load Network Mode Data Pump Export and Import both support a network mode in which the job's source is a remote Oracle instance. When you perform an import over the network, there are no dump files involved because the source is another database, not a dump file set. When you perform an export over the network, the source can be a read-only database on another system. Dump files are written out on the local system just as they are with a local (non-networked) export. 121

Export der Daten Optional Flashback zum Absichern des Entlade-Zeitpunktes nutzen Remote-Export möglich (per NETWORK_LINK) Wegfall von separatem FTP-Aufruf Einschränkung durch Query-Bedingung Damit Zugriff z. B. auf „Last Update-Sätze“ Default Export Location D:\o11\admin\o11\dpdump\EXPDAT.DMP expdp hr DIRECTORY=dpump_dir1 NETWORK_LINK=source_database_link DUMPFILE=network_export.dmp LOGFILE=network_export.log 122

Ablauf des Exports Export über Parameter-Datei Export auch mit Remote-Zugriff Einschränkung der Datenmenge durch QUERY Bei dem Import: REMAP auf das Schema expdp dwh/dwh@o11 parfile=Para_EX.txt impdp dwh2/dwh2@o11 DIRECTORY=DP_OUT DUMPFILE=EXP1.DMP LOGFILE=DP_OUT:imp_log REMAP_SCHEMA=DWH:DWH2 123

Export-Beispiele 124

Import-Beispiele 125

Interaktiver Modus von Data Pump CTRL-C zum Starten des interaktiven Modus ADD_FILE Das Hinzufügen eines neuen Dump-Files ist möglich KILL_JOB Prozess kann abgebrochen werden STOP_JOB Aktueller Job wird beendet PARALLEL Einstellung des Parallelisierungsgrads Eingabe von „continue_client“ führt zur normalen Monitor-Ausgabe zurück 126

External Tables Tabelle, die eine Datei referenziert Datei wird als normale Tabelle behandelt Nur lesend zugreifbar RMAN sichert nicht die Daten Bulk-Loading Operationen, wie insert... select Mehr Transformationsoptionen als im SQL* Loader Parallelisierbares Lesen Alternative zum SQL*Loader 127

External Tables – Beispiel 1 CREATE DIRECTORY Exttab AS 'D:\Szenario\Exttab'; DROP TABLE Gemeinde_EX; CREATE TABLE Gemeinde_EX ( Gemeinde_Nr VARCHAR2(8), Gemeinde VARCHAR2(50) ) ORGANIZATION EXTERNAL (TYPE oracle_loader DEFAULT DIRECTORY Exttab ACCESS PARAMETERS (RECORDS DELIMITED BY newline BADFILE 'Gemeinde.bad‚ DISCARDFILE 'Gemeinde.dis‚ LOGFILE 'Gemeinde.log‚ SKIP 20 FIELDS TERMINATED BY ";" OPTIONALLY ENCLOSED BY '"‚ ) LOCATION ('Gemeinde_CSV.TXT') ) GemeindeID;Gemeinde;KundenID;KreisID 01001000;Flensburg;;0;1001 01002000;Kiel;;0;1002 01003000;Luebeck;;0;1003 01004000;Neumuenster;;0;1004 01051001;Albersdorf;;0;1051 01051002;Arkebek;;0;1051 01051003;Averlak;;0;1051 01051004;Bargenstedt;;0;1051 01051005;Barkenholm;;0;1051 01051006;Barlt;;0;1051 01051008;Bergewoehrden;;0;1051 01051010;Brickeln;;0;1051 01051011;Brunsbuettel;;0;1051 ........................... External tables are defined as tables that do not reside in the database, and can be in any format for which an access driver is provided. Oracle Database provides two access drivers: ORACLE_LOADER and ORACLE_Data Pump. By providing the database with metadata describing an external table, the database is able to expose the data in the external table as if it were data residing in a regular database table. 128

Modifikationsmöglichkeiten create or replace directory LC_TEXTE_2 AS 'D:\Szenario\Testdaten'; alter table ex_orte default directory LC_Texte_2; alter table ex_orte location ('ORTE_Y.CSV'); 129

„Beschickungskonzept“ Änderungsprozedur zum Kopieren der Dateien Umbenennen von Dateinamen Ändern der Einträge in der External Table Ändern des Pfades im Directory-Objekt ABC120109 ABC130109 ABC140109 ABC150109 Sich täglich ändernde Dateinamen Datum im Dateinamen Lieferantenname im Dateinamen 130

Preprocessing für External Tables Release 2 Preprocessing für External Tables CREATE TABLE sales_transactions_ext (PROD_ID NUMBER, CUST_ID NUMBER ...) ORGANIZATION external (TYPE oracle_loader DEFAULT DIRECTORY data_file_dir ACCESS PARAMETERS (RECORDS DELIMITED BY NEWLINE CHARACTERSET US7ASCII PREPROCESSOR exec_file_dir:'gunzip' OPTIONS '-C' BADFILE log_file_dir:'sh_sales.bad_xt' LOGFILE log_file_dir:'sh_sales.log_xt' FIELDS TERMINATED BY "|" LDRTRIM ( PROD_ID, CUST_ID, TIME_ID DATE(10) "YYYY-MM-DD", CHANNEL_ID, PROMO_ID, QUANTITY_SOLD, AMOUNT_SOLD, UNIT_COST, UNIT_PRICE)) location ('sh_sales.dat.gz')) REJECT LIMIT UNLIMITED; 131

External Tables mit Data Pump Erstellen External Table in Quell-DB Verwendung von CREATE AS SELECT * FROM <source_table> Das Ausführen des CREATE startet den Data Pump-Export Kopieren der Dump-Datei auf die Zielumgebung In der Zielumgebung neue External Table-Definition erstellen und aktivieren Durch Zugriff mit SELECT auf die External Table die Daten lesen 132

External Tables mit Data Pump OLTP DWH EX_T EX_T FTP 133

External Tables mit Data Pump OLTP DWH select * from EX_Bestellung_2 134

Vorteile der Kombination Leichte Handhabung Syntax der beiden Typen sehr ähnlich Hohe Performance Data Pump-eigenes Format ist für schnellen Ex-/Import ausgelegt Parameter von Data Pump zusätzlich nutzen, um die zu extrahierende Datenmenge auf das Wesentliche zu reduzieren Verbleiben innerhalb der SQL-Sprache Durch CREATE TABLE AS SELECT lassen sich sowohl WHERE- Filter als auch Joins während des Extrahierens verarbeiten 135

Transportable Tablespaces Höchste Performance beim Austausch von Oracle zu Oracle Daten werden als komplettes File oder File Set bewegt Austausch zwischen unterschiedlichen Betriebssystemen möglich Konvertierung kann mit RMAN erfolgen, z.B. von BigEndian nach LittleEndian Nützlich beim Bewegen der Daten zwischen Quellsystem und Staging Area sowie zwischen den anderen Schichten im Warehouse 136

Vorgehensweise Anlegen des Tablespaces im Quellsystem Zuweisung der zu kopierenden Daten zum Tablespace Alle Daten sind dem Tablespace zugeordnet (Indizes etc.) Ändern des Tablespaces auf Read-Only Export der Metadaten mit Data Pump (EXPDP) Eventuell Konvertierung des Tablespace Datafiles Über die RMAN CONVERT Function Kopieren des Tablespace Datafiles und der Metadaten Import der Metadaten in der Zielumgebung Ändern des Tablespaces auf Read-Write 137

Transportable Tablespaces 1 CREATE TABLE temp_jan_umsatz NOLOGGING TABLESPACE ts_temp_umsatz AS SELECT * FROM ????????? WHERE time_id BETWEEN '31-DEC-1999' AND '01-FEB-2000'; Buchhaltung Produktion Personal P1 P2 P3 P4 4 8 9 Z1 Z2 Z3 Z4 Lager Index/Constraint free Parallel Direct Path Insert Set Based Lieferanten Marketing Service 2 ALTER TABLESPACE ts_temp_umsatz READ ONLY; 3 Kopieren des Tablespace zur Zielplattform BS-Copy Daten EXP TRANSPORT_TABLESPACE=y TABLESPACES=ts_temp_umsatz FILE=jan_umsatz.dmp Meta daten 4 138

Transportable Tablespaces 5 IMP TRANSPORT_TABLESPACE=y DATAFILES='/db/tempjan.f' TABLESPACES=ts_temp_umsatz FILE=jan_umsatz.dmp Metadaten 6 ALTER TABLESPACE ts_temp_umsatz READ WRITE; 7 Neuer Monat 012000 ALTER TABLE umsatz ADD PARTITION umsatz_00jan VALUES LESS THAN (TO_DATE('01-feb-2000','dd-mon-yyyy')); ALTER TABLE umsatz EXCHANGE PARTITION umsatz_00jan WITH TABLE temp_umsatz_jan INCLUDING INDEXES WITH VALIDATION; 121999 111999 101999 091999 Fakttable Umsatz 139

Database Links – SQL über DB-Grenzen hinweg OLTP Data Warehouse SID: ORCL_OLTP Schema: CRM Kunde Kunde tgt Insert into tgt select * from kunde@DBL_OLTP CREATE DATABASE LINK “DBL_OLTP" CONNECT TO “CRM" IDENTIFIED BY “CRM" USING 'ORCL_OLTP0' ;

Themen Ziele Oracle DWH Architektur zur Einordnung Anforderungen an den ETL Prozess Hilfsmittel in der Datenbank (Übersicht) Vorgehensweise im ETL-Prozess Hardware und Umgebungsarchitektur

Aspekte, die zu beachten sind Indizierung Constraints Komprimierung Statistiken Logging Steuern von logischen Transaktionen Aktualisierung Materialized Views Laufzeit-Statistiken 142

Typischer Ablauf eines Ladelaufs Großes Ladevolumen Initialisieren Monitoring-Funktionen (wenn vorhanden) Constraints abschalten Indizes löschen Laden über “Direct Path” Constraint-Prüfung mit SQL-Mitteln Eventuell Löschen alter Daten Oder Archivieren Aktivieren der Constraints (Sofern überhaupt gebraucht) Neu-Aufbau von Indizes Statistiken aktualisieren DBMS_STAT Materialized Views aktualisieren Laufzeit-/ Ressourcen – Statisitiken aktualisieren 143

Lade-Aktivitäten an Schichtübergängen Integration Enterprise User View Flüchtige Daten Persistent Kopien / teilpersistent dynamisch Clearing-Verfahren, technisches, logisches, semantisches Prüfen Denormalisieren Historisieren z.T. Aggregieren Normalisieren (Granularisieren) Generische Datenstrukturen (isolierte Tabellen, teil-ausgeprägte Datentypen) Keine Constraints 3 NF Datenstrukturen (ER-Tabellen, ausgeprägte Datentypen) Aktivierte Constraints Multidimensionale Modelle (ER-Tabellen, ausgeprägte Datentypen) Kopieren Selektieren Mengenbasiertes Prüfen ohne Constraints Umschlüsselung Lookups -> Referenz-/Stammdaten Joins Aufbauen von Distinct-Strukturen (Normalisieren) Umschlüsselung Lookups -> Dimensionsdaten Joins - Denormalisieren 144

ETL-Aktivitäten sind kontrollierte Vorgänge Lade-Aktivitäten Lese-Aktivitäten Data Integration Layer Enterprise Information Layer User View Layer Process neutral / 3 NF Objektbezogenes Vorgehen Objektbezogenes Steuern der Parallelisierung Gezieltes Ein-/ Ausschalten der Constraints Gezieltes Ein-/Ausschalten Logging Gezieltes Aktualisieren der Statistiken einzelner Objekte Gezieltes Aktualisieren von Materialized Views Pauschale Schema-bezogene Routinen vermeiden. Diese sind in OLTP- Systemen sinnvoll aber nicht im DWH.

Umgang mit Constraints im DWH Constraints werden im DWH seltener gebraucht (Gegensatz zu OLTP) Es finden keine Benutzer-initiierten Inserts / Updates statt Potentielle Änderungen sind alle bekannt und können gezielt behandelt werden Mengenbasierte Prüfungen schneller als Contraint-Prüfungen Sinnvolle Contraints sind: PK-Contraints / Index auf Stamm- / Referenztabellen PK-Contraints / Index auf Dimensionstabellen

Notwendige Prüfungen Dimensionen des Star Schemas Faktentabellen Parent-Child – Kardinalität zwischen Hierachie-Leveln Eindeutigkeit (PK) der Einträge auf dem untersten Level Faktentabellen Sind alle Faktensätze über Joins mit den Dimensionen erreichbar? Sind alle FK-Felder mit Werten gefüllt

Umgang mit Tabellen beim Laden Mengenbasiertes Prüfen von * Eindeutigkeit * NOT NULL * Feldtypen * FK / PK – Relationen *Sonstige Checks Keine Constraints aktiv Keine Trigger aktiv Keine Indizes (Nologging) Target Table Flashback Recovery aktiv 148

Einsatz von Compression Oracle Data Warehouse 149

Fallstricke und Empfehlungen Mindestens Standard-Kompression sollte im DWH eingesetzt werden Tabellen mit Standard-Kompression dekomprimieren sich bei vielen vielen INSERTS / UPDATES Regelmäßiges Rekomprimieren Partitionen von partitionierten Tabellen unterschiedlich behandeln

Das Datenwachstum beherrschen Komprimieren: Verwaltung und Kosten reduzieren Kompressions Typ: Einsatz für: Faktor Basic Compression Read only Tabellen und Partitionen in Data Warehouse Umgebungen oder “inaktive” Daten-Partitionen in OLTP Umgebungen. 2-4 OLTP Compression Aktive Tabellen und Partitionen in OLTP und Data Warehouse Umgebungen. SecureFiles Compression Non-relational Daten in OLTP und Data Warehouse Umgebungen. Index Compression Indizes auf Tabellen in OLTP und Data Warehouse Umgebungen. 2 Backup Compression Alle Umgebungen. Hybrid Columnar Compression – Data Warehousing Read only Tabellen und Partitionen in Data Warehouse Umgebungen. 8-12 Hybrid Columnar Compression – Archival “Inaktive” Daten Partitionen in OLTP und Data Warehousing Umgebungen. 10-40 Basic Compression Basic compression, first made available with Oracle9i Database Enterprise Edition, is used to compress read-only data that may be found in a data warehouse, or in the non-active partitions of a large partitioned table underneath OLTP applications. The data is compressed as it is loaded into the table (or moved into the partition), with typically around a 2 to 4 times compression ratio achieved. SecureFiles Compression The Advanced Compression option of Oracle Database 11g also supports compression of data stored as large objects (LOBs) in the database. This is especially important for environments that mix structured data with unstructured data underneath rich applications – for example, XML, spatial, audio, image or video information stored in Oracle Database 11g can also be compressed. Compression ratios are dependent on the type of media being compressed, however three levels of compression are provided to allow the desired level of compression to be achieved based on available CPU resources Index Compression Oracle Database 11g not only compresses row data, but also compresses the indexes associated with these rows. Indexes can be compressed independent of whether the underlying table data is compressed or not. Index compression can significantly reduce the storage associated with large indexes in large database environments. Backup Compression Oracle Database 11g can also compress backups of data stored in the rows and indexes in databases, independent of whether the data in these rows or indexes have in turn been compressed. 151

Tabellen-Komprimierung in 11g Komprimierungseinstellung durch CREATE TABLE beim Neuanlegen ALTER TABLE MOVE COMPRESS bei existierenden Daten ALTER TABLE MOVE PARTITION COMPRESS bei Partitionen Beispiel - Syntax: Im Enterprise Manager: CREATE TABLE sales_history(…) COMPRESS FOR BASIC | OLTP 152

Der Query Optimizer und Statistiken Oracle Data Warehouse 153 153

Statistiken sammeln Regelmäßig aktuelle Statistiken sind wichtig für gute Ausführungspläne Ständiges Aktualisieren belastet das System Best Practice im DWH Statistiken in Verbindung mit dem ETL-Prozesse aktualisieren. Nur diejenigen Tabellen, Partitionen und Indexe aktualisieren, die aktuell geladen bzw. verändert wurden. => Automatisiertes Aktualisieren sollte genau überlegt werden DBMS_STATS.GATHER_TABLE_STATS(Ownname=><OWNER>, Tabname=><TABLE_NAME>); DBMS_STATS.GATHER_TABLE_STATS(Ownname=><OWNER>, Tabname=><TABLE_NAME>, Partname=><PARTITION_NAME>, GRANULARITY=>'PARTITION'); 154

Sammeln von Statistiken Tabellen -> GATHER_TABLE_STATS Indexe -> GATHER_INDEX_STATS Schema -> GATHER_SCHEMA_STATS Automatisiertes Sammeln für ein Schema Automatisiertes Sampling Parameter DBMS_STATS.AUTO_SAMPLE_SIZE EXEC DBMS_STATS.GATHER_TABLE_STATS ( 'PART','BESTELLUNG_PART_RANGE', estimate_percent=>100); EXEC dbms_stats.gather_schema_stats( ownname => 'PERF', estimate_percent => 5,block_sample => TRUE) Begin dbms_stats.gather_schema_stats( ownname => 'PERF' ,options => 'GATHER AUTO' ,estimate_percent => 5 ,block_sample => TRUE); end; EXECUTE DBMS_STATS.GATHER_SCHEMA_STATS( 'OE',DBMS_STATS.AUTO_SAMPLE_SIZE);

Inkrementelles Statistiksammeln (11g) 11g: Incremental Global Statistics Synapsis Struktur in SYSAUX Tablespace Sehr schnelles Erzeugen der globalen Statistiken ohne die komplette Tabelle zu lesen Inkrementelles Aktualisieren einschalten Initiales einmaliges Sammeln Inkrementelles Sammeln geschieht automatisch über EXEC DBMS_STATS.GATHER_TABLE_STATS(‚DWH1','UMSATZ'); DBMS_STATS.SET_TABLE_PREFS(<OWNER>, <TABLE_NAME>, 'INCREMENTAL', TRUE); DBMS_STATS.GATHER_TABLE_STATS(Ownname=><OWNER>, Tabname=><TABLE_NAME>, DEGREE=><DESIRED_DEGREE>); DBMS_STATS.GATHER_TABLE_STATS(Ownname=><OWNER>, Tabname=><TABLE_NAME>, Partname=><SUBPARTITION_NAME>, GRANULARITY=>'SUBPARTITION', DEGREE=><DESIRED_DEGREE>); Oracle Database Performance Tuning Guide 11g Release 2 / Chapter 13 - Managing Optimizer Statistics http://download.oracle.com/docs/cd/E11882_01/server.112/e10821/stats.htm 156

Anwendung im DWH bei partitionierten Tabellen Partition Tag 1 Globale Statistiken regelmäßig sammeln Z. B. einmal im Monat Einschalten des ‚Incremental‘- Modus für die entsprechende Tabelle: EXEC DBMS_STATS.SET_TABLE_PREFS(‚DWH',‘UMSATZ, 'INCREMENTAL','TRUE'); Nach jedem Laden einer neuen Partition, die Statistiken aktualisieren: EXEC DBMS_STATS.GATHER_TABLE_STATS('DWH','UMSATZ'); Partition Tag 2 Partition Tag 3 Partition Tag 4 Partition Tag 5 Globale tatistiken Partition Tag 7 Partition Tag 8 Partition Tag 9 Partition Tag 10 Neu hinzugefügte Partiton verfälscht Statistiken ETL Partition Tag n 157

Schlüssel im DWH und Indizierung Oracle Data Warehouse 158

Warum künstliche Schlüssel verwenden? Gründe für den zusätzlichen Aufwand künstlicher Schlüssel sind: Integration In mehreren Vorsystemen gibt es unterschiedliche Schlüssel Stabilität Natürliche Schlüssel können sich ändern Geschäftsbereiche können sich ändern  DWH langlebiger als operative Anwendungen Künstliche Schlüssel bedeuten Performance für das Star Schema 159

Umschlüsselung Anwendung 1 Verkaufsregion Einkommensgruppe Data Warehouse Wohnart Verkaufsregion Berufsgruppe Einkommensgruppe Anzahl Kinder Wohnart Alter ... Name PLZ Kunden_NR Ort Anwendung 2 Kunden_NR Tel Partnernummer PLZ Dim_Kd_NR Neuer Schlüssel Ort Strasse Partnernummer Sequence 160

Regeln für künstliche Schlüssel In Dimensionen Schlüssel sind einfach zu benutzen und kurz, um Speicherplatz zu sparen Fehler zu vermeiden Nach Möglichkeit keine zusammengesetzten Schüssel Erfordert beim Zugriff unnötig viel Vorwissen zu den einzelnen Schlüsselbestandteilen Schlüsselbestandteile können leicht NULL-Wert annehmen, die Eindeutigkeit ist gefährdet Keine Felder wählen, die NULL werden können Spaltenwerte sollten stabil sein und sich nicht mehr ändern 161

B*Tree Index – 4 Zugriffe bis zum Wert 1 2 Clustering Factor Zugriff über die RowID 3 4 162

Bitmap – Zugriff auf Werte per Bit Stream Rowid Name Abschluss Rating AAAHfVAAJAAAKOKAAA Meier Klasse_10 5 AAAHfVAAJAAAKOKAAB Schubert Abitur 5 AAAHfVAAJAAAKOKAAC Klaus-Gustav Abitur 5 AAAHfVAAJAAAKOKAAD Schmidt Diplom 5 AAAHfVAAJAAAKOKAAE Langbein Doktor 5 AAAHfVAAJAAAKOKAAF Hund Klasse_10 5 AAAHfVAAJAAAKOKAAG Vogel Abitur 5 AAAHfVAAJAAAKOKAAH Messner Abitur 5 Abschluss= Klasse_10 Abschluss= Abitur Abschluss= Diplom Abschluss= Doktor AAAHfVAAJAAAKOKAAA 1 1 1 1 AAAHfVAAJAAAKOKAAB AAAHfVAAJAAAKOKAAC AAAHfVAAJAAAKOKAAD AAAHfVAAJAAAKOKAAE SELECT Name FROM KD_Table WHERE Abschluss=‘Diplom‘; AAAHfVAAJAAAKOKAAF AAAHfVAAJAAAKOKAAG AAAHfVAAJAAAKOKAAH 163

Physische Strukturen im Star Schema Data Mart-Schicht Dimensionsobjekt Reg Zeit Dimensionsobjekt PK Constraint Primary Key Constraint Komprimiert Partitioniert Lokale Indizes Security Verschlüsselung Foreign Key (NOT NULL) Bitmap-Index Keine Contstraints= kein PK Constraint -> star transformation Dimensionsobjekt Org. Linie Prod Dimensionsobjekt PK Constraint PK Constraint 164

Indizierung im Star D_KUNDE D_ARTIKEL D_ZEIT F_UMSATZ D_REGION KUNDEN_ID KUNDENNR GESCHLECHT VORNAME NACHNAME TITEL ANREDE GEBDAT BRANCHE WOHNART KUNDENART BILDUNG ANZ_KINDER EINKOMMENSGRUPPE ORTNR NUMBER, BERUFSGRUPPE STATUS STRASSE TELEFON TELEFAX KONTAKTPERSON FIRMENRABATT BERUFSGRUPPEN_NR BILDUNGS_NR EINKOMMENS_NR WOHNART_NR HAUSNUMMER PLZ ORT KUNDENKARTE ZAHLUNGSZIEL_TAGE TOTAL TOTAL_NR Indizierung im Star PK D_ARTIKEL ARTIKEL_NAME GRUPPE_NR GRUPPE_NAME SPARTE_NAME SPARTE_NR ARTIKEL_ID D_ZEIT DATUM_ID TAG_DES_MONATS TAG_DES_JAHRES WOCHE_DES_JAHRES MONATS_NUMMER MONAT_DESC QUARTALS_NUMMER JAHR_NUMMER ZEIT_ID PK F_UMSATZ ARTIKEL_ID KUNDEN_ID ZEIT_ID REGION_ID KANAL_ID UMSATZ MENGE UMSATZ_GESAMT FK FK PK FK FK FK D_REGION REGION_ID ORTNR ORT KREISNR KREIS LANDNR LAND REGIONNR REGION PK D_VERTRIEBSKANAL KANAL_ID VERTRIEBSKANAL KANALBESCHREIBUNG VERANTWORTLICH KLASSE PK PK: Btree Index FK: Bitmap Index 165

Indizierung im Star D_KUNDE D_ARTIKEL D_ZEIT F_UMSATZ D_REGION KUNDEN_ID KUNDENNR GESCHLECHT VORNAME NACHNAME TITEL ANREDE GEBDAT BRANCHE WOHNART KUNDENART BILDUNG ANZ_KINDER EINKOMMENSGRUPPE ORTNR NUMBER, BERUFSGRUPPE STATUS STRASSE TELEFON TELEFAX KONTAKTPERSON FIRMENRABATT BERUFSGRUPPEN_NR BILDUNGS_NR EINKOMMENS_NR WOHNART_NR HAUSNUMMER PLZ ORT KUNDENKARTE ZAHLUNGSZIEL_TAGE TOTAL TOTAL_NR Indizierung im Star PK D_ARTIKEL ARTIKEL_NAME GRUPPE_NR GRUPPE_NAME SPARTE_NAME SPARTE_NR ARTIKEL_ID D_ZEIT DATUM_ID TAG_DES_MONATS TAG_DES_JAHRES WOCHE_DES_JAHRES MONATS_NUMMER MONAT_DESC QUARTALS_NUMMER JAHR_NUMMER ZEIT_ID PK F_UMSATZ ARTIKEL_ID KUNDEN_ID ZEIT_ID REGION_ID KANAL_ID UMSATZ MENGE UMSATZ_GESAMT FK FK PK FK FK FK D_REGION REGION_ID ORTNR ORT KREISNR KREIS LANDNR LAND REGIONNR REGION PK D_VERTRIEBSKANAL KANAL_ID VERTRIEBSKANAL KANALBESCHREIBUNG VERANTWORTLICH KLASSE PK PK: Btree Index FK: Bitmap Index 166

Wo und wie wird im DWH indiziert Lade-Aktivitäten Lese-Aktivitäten Data Integration Layer Enterprise Information Layer User View Layer Process neutral / 3 NF Keine Indexe B*tree für Eindeutigkeit und als Primary Key Bitmaps Bitmaps B*tree für Primary Keys In den Dimensionen Tabellen

Transaktionssteuerung Logische / technische Transaktion Flashback Oracle Data Warehouse 168 168 168

Aufgabenstellung der Lade-Transaktion Betrachten des kompletten Ladelaufs als eine zusammenhängende Transaktion Entweder alle Sätze oder keine geladen Wie können abgebrochene Ladeläufe wieder rückgängig gemacht werden? 169

Transaktionssteuerung / -rücksetzung Markieren von Sätzen eines Ladelaufs in zusätzlichen Feldern Ladelauf-Nummer, Ladelauf-Datum, ... Zurückrollen durch langsames Einzel-DELETE Arbeiten mit Partitioning Aufbau einer neuen Partition unabhängig von der Zieltabelle Schnelles DROP PARTITION im Fehlerfall Einfachste und schnellste Variante Flashback Database / Table / Query Transaktions-genaues Zurückrollen Flashback DB benötigt zusätzlichen Plattenplatz Einsatz von Data Guard 170

Flashback Database Vorbereitungen Archive Log Mode Prüfen, ob Flashback und Archive Log Mode der Datenbank aktiviert sind SELECT flashback_on, log_mode FROM gv$database; Abfragen der Zeitdauer, mit der Objekte aufgehoben werden SELECT name, value FROM gv$parameter WHERE name LIKE '%flashback%'; Verändern der Aufbewahrungszeit (Anzahl der Minuten 60 * 24 = 1440 = 1 Tag) ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=2880; FLASHBACK_ON LOG_MODE ------------------ ------------ YES ARCHIVELOG db_flashback_retention_target 2880 171

Flashback Logs SQL> desc gv$flashback_database_log; Name Null? Typ ----------------------------------------- -------- --------------------------- INST_ID NUMBER OLDEST_FLASHBACK_SCN NUMBER OLDEST_FLASHBACK_TIME DATE RETENTION_TARGET NUMBER FLASHBACK_SIZE NUMBER ESTIMATED_FLASHBACK_SIZE NUMBER SQL> SELECT * from gv$flashback_database_log; INST_ID OLDEST_FLASHBACK_SCN OLDEST_F RETENTION_TARGET FLASHBACK_SIZE ESTIMATED_FLASHBACK_SIZE ---------- -------------------- -------- ---------------- -------------- --------------------- 1 16527241 27.12.08 2880 72892416 217939968 172

Abfragen auf die Änderungssituation SQL> select ora_rowscn from X; ORA_ROWSCN ---------- 16531366 16531970 16531366 16531444 16532989 16532989 16532989 16532989 16532989 16532989 16532989 16532989 16532989 16532989 SQL> SELECT oldest_flashback_scn, 2 oldest_flashback_time 3 FROM gv$flashback_database_log; OLDEST_FLASHBACK_SCN OLDEST_F -------------------- -------- 16527241 27.12.08 SQL> SELECT current_scn 2 FROM gv$database; CURRENT_SCN ----------- 16554677 SQL> SELECT * from gv$flashback_database_log; INST_ID OLDEST_FLASHBACK_SCN OLDEST_F RETENTION_TARGET FLASHBACK_SIZE ESTIMATED_FLASHBACK_SIZE ---------- -------------------- -------- ---------------- -------------- ----------------------- 1 16527241 27.12.08 2880 72892416 217939968 173

Beispiel Flashback Table CREATE TABLE x (Nummer number); ALTER TABLE x ENABLE ROW MOVEMENT; INSERT INTO X VALUES (1); INSERT INTO X VALUES (1); INSERT INTO X VALUES (1); COMMIT; Jetzt erst wird eine SCN erzeugt Abfrage u. Flashback der letzten Änderungs-SCN SELECT ora_rowscn FROM x; SELECT * FROM x AS OF SCN 12555060; SELECT * FROM x AS OF TIMESTAMP to_timestamp('2012-02-15 10:15:00', 'YYYY-MM-DD HH:MI:SS'); Zurücksetzen Flashback table x to scn 16552768; 174

Flashback Database Sys-Schema DWH-Schema Komplette Datenbank zurücksetzen Einzelne Tabellen Ist im DWH-Load-Prozess sinvoller Zurücksetzen Über Zeitstempel Über SCN Sys-Schema DWH-Schema startup mount exclusive; FLASHBACK TABLE dwh.X TO SCN 16552768; FLASHBACK TABLE X TO SCN 16552768; 175

Themen Ziele Oracle DWH Architektur zur Einordnung Anforderungen an den ETL Prozess Hilfsmittel in der Datenbank (Übersicht) Vorgehensweise im ETL-Prozess Hardware und Umgebungsarchitektur

Hardware-Faktoren Oracle Data Warehouse 177

Nähe von Datenbank und ETL-Server 1 Gb Leitung DB Server ETL Server 10 Gb Leitung DB Server ETL Server

Balanced Konfigurationen ~200 MB Datendurchsatz pro CPU Anzahl CPU = Max. Durchsatz in MB/s / 200 Anzahl CPU‘s Größe des Hauptspeichers Anzahl Platten Anzahl Disk Controller Größe des Speichers in GB = 2 * Anz. CPUs Trennung von Storage für OLTP und DWH-Systeme !! Schnelle Platten nutzen (15000 U/min) Eher mehr, kleine Platten nutzen, als wenige große Platten nutzen Flash-Speicher in Betracht ziehen ASM in Betracht ziehen Einfaches und DB-optimiertes Verwalten Max. Durchsatz in MB/s Anzahl Disk Controller = Controllerdurchsatz in MB 70% * Herstellerangaben in Gbit/s Controllerdurchsatz in MB = 8 179

Die Hardware Umgebung – Storage Trennung von Storage für OLTP und DWH-Systeme Schnelle Platten nutzen (15000 U/min) Eher mehr, kleine Platten nutzen, als wenige große Platten nutzen Flash-Speicher in Betracht ziehen ASM in Betracht ziehen Einfaches und DB-optimiertes Verwalten 180

Messung von IO-Durchsatz Einfache Schätzmethode Calibrate_IO Read-only Test Wenige Test-Optionen -> leicht anwendbar > 11g Orion (ORacle IO Numbers) Read / Write – Tests (Achtung schreibt auf Platten) Viele Test-Optionen OLTP + DWH Workload Ab 11.2 im BIN-Verzeichnis der DB www.oracle.com/technology/software/tech/orion/index.html 181

Einfache Schätzmethode zur Lesegeschwindigkeit Blockgröße feststellen select tablespace_name, block_size from dba_tablespaces; TABLESPACE_NAME BLOCK_SIZE ------------------------------ ---------- MON_G 8192 MON 8192 MON_D 8192 MON_E 8192 MON_F 8192 Anzahl Blöcke/ Anzahl Bytes SELECT table_name, num_rows, blocks, blocks*8 KB,blocks*8/1000 MB,blocks*8/1000000 GB FROM user_tables; TABLE_NAME NUM_ROWS BLOCKS KB MB GB ------------------------------ ---------- ---------- ---------- ---------- ---------- BESTELLUNG_PART_RANGE 163840000 962355 7698840 7698,84 7,69884 BESTELLUNG_PART_RANGE_4 163840000 962355 7698840 7698,84 7,69884 Messen der Lese- geschwindigkeit select count(*) from bestellung_part_Range_4; -- liest komplette Tabelle   COUNT(*) ---------- 163840000 Abgelaufen: 00:00:31.32 Berechnung des Durchsatzes select 7.7/31 from dual;  Ergibt ~0,25 GB pro Sekunde Lesegeschwindigkeit (Achtung Blöcke eventuell nicht voll, daher geringer ) SQL> 7.7/31 ---------- ,248387097 182

ASM Verwalten ganzer Gruppen von Platten Keine Einzelaktionen DBA übernimmt die Storage-Verwaltung Gewohnte Kommandos… SQL Create… SAME in der DB Verlagern des Striping and Mirroring Everything in die Verantwortung der Datenbank Automatische Verteilung der Daten über alle Platten Verhindert von Hotspots Messung von IO-Zugriffen über DB-Statistiken (ist klassischen RAID- Verfahren überlegen) Bequemes Hinzufügen /Wegnehmen von Platten Verhindert Fragmentierung der Platten Einführung von ASM kann bis 25% verbessertes IO-Verhalten liefern Performance kommt an Raw Devices heran 183

ASM Architektur ASM Disks ASM Disk Groups ASM Failure Groups Partitionen oder LUNs, die über das Betriebssystem bereitgestellt werden Ab 11 sind einfache Partitionen, RAW Devices oder auch NFS-Dateien möglich ASM Disk Groups Eine oder mehrere ASM Disks Logical Volumes – logische Einheit von Speicherplatz Eine DB kann mehrere Disk Groups haben ASM Failure Groups Ensemble von ASM Disk Groups, die als 2 oder 3-Wege-Spiegel arbeiten ASM instance Ähnlich einer DB-Instanz aber ohne datafiles Muss hochgefahren und auch über eine SID ansprechbar sein ASM Files Files, die in den Disk Groups abgelegt sind, ohne dass man deren physischen Ort bestimmt Die ASM-Files entsprechen den sonst üblichen Datenbank-Files (1:1 Mapping) ASM verteilt diese Files über mehrere physische Bereiche (Platten) Die logischen Konzepte wie Extents, Segmente oder Tablespaces bleiben erhalten ASM Disk 184

ASM Architektur 185

Der physische Aufbau einer RAC-Umgebung Options: RAC Der physische Aufbau einer RAC-Umgebung Öffentliches Netzwerk Privates Netzwerk (Interconnect) CPU CPU Knoten 1 Knoten 2 Instanz 1 Instanz 2 Speichernetzwerk Daten 186

Ausfallsicherheit durch den Cluster 1 Gigabit ethernet 4 nodes, each with 4 x 2 Ghz CPUs 5 PCI slots 16-port switch 16-port switch 16 Storage arrays, each with 10-20 disks 187

Architektonische Vorteile RAC und ETL Voraussetzung ETL in der Datenbank Nur dieses bringt Last auf die RAC-Knoten Verteilung der Datenbank-basierten ETL-Jobs auf unterschiedliche Knoten Laufen keine ETL-Jobs Knoten frei für andere Datenbank-Aufgaben Geringere Hardware-Anschaffungskosten Wegfall Backup-Rechner Wegfall Netzlast Direkter ETL-Zugriff auf Daten der eigenen Datenbank und über schnelle Leitungen 188

Allgemeine Aufbauempfehlungen RAC aus ETL-Sicht Die Knoten nicht zu klein wählen Sollten so stark sein, dass sie zusammenhängende ETL-Jobs auch alleine bewältigen können. (Z. B. 4 CPUs pro Knoten) RAC und ETL Das System sollte nicht darauf angewiesen sein, über die Knoten hinweg parallelisieren zu müssen, um zu skalieren. Skalierung gelingt über die gezielte Steuerung zusammenhängender Lade-Jobs auf die unterschiedlichen Knoten. Durchsatz für Interconnect 1-2 Gbit / Sec Hauptspeicher 4 GB pro CPU Durchsatz für das Speichernetzwerk: pro CPU mindestens 100 MB/Sec 189

Performance und Systemzustand überwachen (Hilfsmittel) Oracle Data Warehouse 190

Automatic Database Diagnostic Monitor (ADDM) und AWR DBMS_ADVISOR Package Addmrpt.sql OEM Statistics_level TYPICAL -> ON BASIC -> OFF 1 1……nn% 2……nn% 3……nn% ……. AWR-Report ADDM Findings use AWR 2 stündlich MMON- Process Recommendations - Hardware - Init-Parameter - Space Konfig. - Performance Advisor User 1 3 Action sysaux User 2 8 Tage lang 4 SQL Tuning Advisor Rationale Undo Advisor Segement Advisor 191

AWR (Analytic Workload Repository) Regelmäßiges Sammeln von einer Vielzahl von System-generierten Statistiken Mit Hintergrundprozessen (MMON) Gespeicherte Statistiken des MMON in SYSAUX Tablespace Vorkonfiguriert generiert AWR alle 60 Minuten Snapshots Parameter STATISTICS_LEVEL (Basic/Typical/All) Basic schaltet das Sammeln aus Retention-Time (Default 8 Tage) DBA_HIST_* - Views zur Auswertung Manuell starten execute dbms_workload_repository.create_snapshot(‘ALL‘); Auswerten Awrrpt.sql OEM 192

Trace einer Session Identifizierung einer zu prüfenden Session   select sid,serial#,terminal,program,module from v$session; 135 177 ASCHLAUC sqlplus.exe sqlplus.exe Aktivieren des SQL-Trace execute dbms_monitor.session_trace_enable(135,177,true); -- TRUE / FALS mit bzw. Ohne waits und zusätzliche Analysen Deaktivieren execute dbms_monitor.session_trace_disable(135,181); *** 2011-09-05 08:08:53.468 ===================== PARSING IN CURSOR #1 len=62 dep=0 uid=0 oct=47 lid=0 tim=33718840968 hv=3081195784 ad='34ab52dc' sqlid='2bqy8r6vufn88' BEGIN dbms_monitor.session_trace_enable(135,181,false); END; END OF STMT EXEC #1:c=0,e=1082,p=0,cr=0,cu=0,mis=1,r=1,dep=0,og=1,plh=0,tim=33718840965   *** 2011-09-05 08:09:02.890 CLOSE #1:c=0,e=45,dep=0,type=0,tim=33728275300 PARSING IN CURSOR #3 len=41 dep=0 uid=0 oct=3 lid=0 tim=33728275601 hv=1078826809 ad='34ab4260' sqlid='2b69gpx04v5tt' select count(*) from dwh.wh_transaktionen PARSE #3:c=0,e=63,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=3695442063,tim=33728275598 EXEC #3:c=0,e=43,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=3695442063,tim=33728275918 FETCH #3:c=0,e=792,p=0,cr=49,cu=0,mis=0,r=1,dep=0,og=1,plh=3695442063,tim=33728276801 STAT #3 id=1 cnt=1 pid=0 pos=1 obj=0 op='SORT AGGREGATE (cr=49 pr=0 pw=0 time=0 us)' STAT #3 id=2 cnt=4216 pid=1 pos=1 obj=86150 op='TABLE ACCESS FULL WH_TRANSAKTIONEN (cr=49 pr=0 pw=0 time=8940 us cost=16 size=0 card=4216)' FETCH #3:c=0,e=3,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,plh=3695442063,tim=33728277502 *** 2011-09-05 08:09:15.453 CLOSE #3:c=0,e=28,dep=0,type=0,tim=33740829401 PARSING IN CURSOR #2 len=57 dep=0 uid=0 oct=47 lid=0 tim=33740830066 hv=208267310 ad='34bc4a1c' sqlid='faaagm066mu1f' BEGIN dbms_monitor.session_trace_disable(135,181); END; 193

Auswertung Trace-Dateien TKPROF tkprof orcl_ora_4488.trc c:\abc.txt explain=sys/sys sort=fchqry Trace Analyzer (TRCA) Download über Doc 224270.1 194

Spokesperson will be Jay Schaudies, Vice President, Global eCommerce. Bring up on stage two customers to tell the audience about their experiences. Manpower Associates is a $14.9B global company with 27,000 employees in the temporary staffing business. Manpower runs a combined PeopleSoft Enterprise and JD Edwards EnterpriseOne shop. These experts in human resources use Enterprise HCM for their own staffing and EnterpriseOne Payroll and Service Billing for handling the large volumes of US-based temporary staff. Manpower is very happy with Oracle’s support since purchasing PeopleSoft and is looking forward to a long relationship with Oracle. Spokesperson will be Jay Schaudies, Vice President, Global eCommerce. Welch Foods is the food processing and marketing arm of National Grape Cooperative Association. Organized in 1945, National Grape is a grower-owned agricultural cooperative with 1,461 members. The company, headquartered in Concord, Massachusetts, operates six plants located in Michigan, New York, Pennsylvania and Washington. The company was running a mix of legacy, home grown, and manual systems that failed to provide senior management with accurate and timely cost and production information. Welch’s required a centralized manufacturing and financial information system to improve management decision making. The solution had to be hot-pluggable with existing technologies, for example, Welch’s Plumtree portal. Welch Foods chose Oracle over SAP for this business-critical application. The key to the customer’s business problem was their ability to manage costs. The company’s costs are driven by fruit solid content in each of their products, and they use a specialized technique called BRIX for measuring and calculating the cost of materials. Welch’s compared SAP and Oracle SAP’s software was too rigid and, therefore, unable to include the BRIX calculation in their manufacturing solution. Only Oracle’s OPM could bind this custom cost method into the Quality Management Process. Technology customer yet to be determined. Current possibilities include eBay and FTD Florists. 195 195