Oracle Data Warehouse Technik im Fokus

Transkript

1 Oracle Data Warehouse Technik im Fokus Praxis-Seminar, Mai 2015

2 Die Themen Data Warehouse Architekturen für effiziente Informationsverarbeitung Partitionierung Schlüssel und Indizierung im Data Warehouse Partitionierung und Indizierung im Data Warehouse Star Query Transformation Komprimierung im Data Warehouse Query-Optimizer und System-Statistiken im Data Warehouse Speicher-Hierarchie Beispiel Flash Automatische Verwaltung von Daten im Data Warehouse (Heat Map) Information Lifecycle Management Parallelisierung Query Result Cache Materialized Views und Kennzahlenkonzepte Automatische Aktualisierung von Materialized Views Konzepte rund um Materialized Views Automatisches Query Rewrite Materialized Views und Hierarchisierung von Dimensionen Hilfsmittel bei der Verwaltung von Materialized Views Analytische SQL-Funktionen In-Memory Database im Data Warehouse Wo und wie macht In-Memory im Data Warehouse Sinn und was ändert sich? Laden und Updaten im Data Warehouse mit Bordmitteln der Datenbank ETL-Performance-Techniken in der Datenbank Set-Based ETL-Prüf- und Transformations Techniken in der Datenbank Umgang mit Schlüssel im Verlauf des Ladens Lade-Transaktionssteuerung innerhalb der Datenbank Lade-Tools ausserhalb der Datenbank Security und Mandantensteuerung im Data Warehouse Multi-strukturierte Daten mit JSON Big Data Analysen im Data Warehouse mit Big Data SQL R als universelles Analyse-Mittel Notwendige Dinge, die niemand macht: Metadatenverwaltung im Data Warehouse Die optimale Hardware für das Data Warehouse Cluster-Einsatz Monitoring Data Warehouse Zusammenfassung 2

3 Data Warehouse Architekturen für effiziente Informationsverarbeitung

4 Immer wieder auf den Punkt bringen! Ein unternehmensweites DWH muss mehr leisten: 1 Zentral und Unternehmensweit 2 Erklärende Mehrwerte Zusammenführen von Daten aus allen Geschäftsprozessen Ermöglichen einer integrierten Sicht auf das ganze Unternehmen und nicht nur einzelner Abteilungen Integration bedeutet die Harmonisierung verschiedner Sichten 3 Historisierung Aufgrund der Vergangenheit Trends der Zukunft erkennen Nur wer die Geschichte kennt, kann die Zukunft verstehen Nicht nur aktuelle Realtime- sondern vor allem historische Daten sind dafür nötig Für alle, auch sachfremde Mitarbeiter verständliche Daten Zusätzliche Referenzdaten von außerhalb des Unternehmens Erklärungen statt Codes 4 Entkopplung von op. Systemen Nur in separierten Systemen simulieren Neue Daten-Kombinationen schaffen Realtime-freie zeitbezogene Messpunkte schaffen

5 Evolution des Data Warehouse DWH-Systeme werden zunehmend auch in einem operativen Sinn genutzt Überschaubar / aggregiert Hochvolumig / granular Operativ überschaubar Taktisch DWH Strategisch Jahr/Quartal/Monat Komplexe Informations- Ausarbeitung und Analysen Woche/Tag Periodische Berichte Stunde/Minute/Sekunde/Realtime oft und schnell wiederholbare Einzel-informationen 5

6 Was geschieht in einem Data Warehouse wirklich Service Logistik Controlling Einkauf Vertrieb Marketing Servicekunde Logistikaufwand Profitabilität Produkte&Trends Kundenhistorie Marketingsicht Integration Layer Enterprise Layer Core - DWH / Info Pool Referenzdaten (extern) (10%) Stammdaten (10%) Bewegungsdaten / Transaktionen (80%) Marketingsicht Sozialsituation Kundenhistorie Profitabilität Kunde Logistikaufwand für einen Kunden Produkte&Trends Servicekunde User View Layer Geschäfts- Objekte Kennzahlen Multidimensionale Sichten Themenbezogene Sichten Top 100 unternehmensweite Kennzahlen Es geht um Gesamtsichten Top 5 Geschäftsfelder Profitabilität eines Kunden Profitabilität eines Produktes über den gesamten Lebenszyklus Bedarfsprognose von sozialen Gruppen Aktualität und Entwicklung des eigenen Portfolios Eigene Marktstärke im Vergleich zu den Wettbewerbern

7 Informationsbeschaffung organisieren Integration Layer (Stage) Zusammenführen von Daten aus unterschiedlichen Vorsystemen Prüfen, harmonisieren, brauchbar machen Enterprise Layer (DWH-Kernschicht) Zentrale Ablage aller Informationen des Data Warehouse Prozess- /Referenz, Stammdaten Langlebig, strategisch User View Layer (Data Marts) Nach Sachgebieten sortierte analysefähiger Ausschnitt von Daten der Kernschicht Endbenutzerverständlich Analysezeitraum- und Projekt-bezogen, taktisch

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 Normalisieren / Denormalisieren Grundprinzip der Warehouse-Modellierung / Granularisierung als Lösung Operative Daten PRODUKTDATEN PD4711 AMKLB KLABAUTER IIO??? EERWEERW EU-Wert i Müll, Altlast, unverständliche Daten Normalisierte Daten (DWH) Produktsparten Spartenname Spartennr Produktgruppen Gruppenname Gruppennr Produkte Produktname Produktenr Einzelpreis Granulare Daten Im DWH Neu sortierte Daten Produktdaten Produktname Produktenr Einzelpreis Gruppenname Gruppennr Spartenname Spartennr Verständliche Information (denormalisiert) 9

10 Ein vollständiges Bild über relevante Geschäftsobjekte Service Servicekunde Logistik Logistikaufwand Controlling Profitabilität Einkauf Produkte&Trends Vertrieb Kundenhistorie Marketing Marketingsicht Log Files Web-Clicks Mails Call-Center Verträge Berichte Integration Layer HDFS / NoSQL Enterprise Layer Core - DWH / Info Pool Referenzdaten (extern) (10%) Stammdaten (10%) Bewegungsdaten / Transaktionen (80%) Marketingsicht Sozialsituation Kundenhistorie Profitabilität Kunde Logistikaufwand für einen Kunden Produkte&Trends Servicekunde Multi-strukturierte Daten User View Layer Geschäfts- Objekte Kennzahlen Multidimensionale Sichten Themenbezogene Sichten Top 100 unternehmensweite Kennzahlen Es geht um Gesamtsichten Top 5 Geschäftsfelder Profitabilität eines Kunden Profitabilität eines Produktes über den gesamten Lebenszyklus Bedarfsprognose von sozialen Gruppen Aktualität und Entwicklung des eigenen Portfolios Eigene Marktstärke im Vergleich zu den Wettbewerbern

11 Flexibilität und schnelles Bereitstellen Service Servicekunde Logistik Logistikaufwand Controlling Profitabilität Einkauf Produkte&Trends Vertrieb Kundenhistorie Marketing Marketingsicht Log Files Web-Clicks Mails Call-Center Verträge Berichte Integration Layer T T T B B HDFS / NoSQL Enterprise Layer Core - DWH / Info Pool R R S S S B B Marketingsicht Sozialsituation Kundenhistorie Profitabilität Kunde Logistikaufwand für einen Kunden Produkte&Trends Servicekunde Multi-strukturierte Daten B B User View Layer D D D F D F F D Geschäfts- Objekte D D D Kennzahlen Zusammenhängender Abfragebereich Es geht um Gesamtsichten Breite der Datenmodelle

12 Flexibilität und schnelles Bereitstellen Service Servicekunde Logistik Logistikaufwand Controlling Profitabilität Einkauf Produkte&Trends Vertrieb Kundenhistorie Marketing Marketingsicht Log Files Web-Clicks Mails Call-Center Verträge Berichte Integration Layer T T T B B HDFS / NoSQL Enterprise Layer Core - DWH / Info Pool R R S S S B B Multi-strukturierte Daten B Strategische Daten B User View Layer D D D F D F F D D D D Taktische Daten Rolle der zentralen Schicht Sich aus Informationsvorat bedienen Schneller reagieren können Synchronisierung von User Views Vermeiden von Redundanzen Historische Sicht

13 Die Rolle multidimensionaler Sichten Buchhaltung: Es fehlen Daten Warum sind die Spediteursrechnungen so hoch? Sind alle Bestellungen korrekt bezahlt worden? Wie hoch sind die Versandkosten pro Lieferung? Was wurde storniert? Marketing: Absatzzahlen sind nicht aussagefähig Wie viele Kunden gibt es? Lohnt die Kundenkarte? Welche Segmentierung gibt es? Vertrieb: wünscht leichtere Auswertungen Was sind wichtige Produkte? Was sind rentable Sparten? Hat sich der Servicebereich gelohnt? Vertrieb SERVICE GmbH Management Marketing Buchhaltung Controlling Controlling: Vergleichbarkeit fehlt Was sind rentable Sparten? Wie rentabel sind einzelne Produkte? Was kosten Produkte im Einkauf? Wie teuer wurden Produkte verkauft? Management: Kennzahlen fehlen Wie hoch sind die liquiden Mittel? Wie hoch sind die Außenstände? 13

14 Die Rolle multidimensionaler Sichten Kunden Kundenkarte Segmentierung Produkte Sparten Vertrieb: wünscht leichtere Auswertungen Was sind wichtige Produkte? Was sind rentable Sparten? Hat sich der Servicebereich gelohnt? Unternehmensbereiche Marketing: Absatzzahlen sind nicht aussagefähig Wie viele Kunden gibt es? Lohnt die Kundenkarte? Welche Segmentierung gibt es? Vertrieb Buchhaltung: Es fehlen Daten Lieferung Warum sind die Spediteursrechnungen so hoch? Bestellung Sind alle Bestellungen korrekt bezahlt worden? Wie hoch sind die Versandkosten pro Lieferung? Was wurde storniert? Umsatz / Nicht-Umsatz SERVICE GmbH Management Marketing Buchhaltung Controlling Controlling: Vergleichbarkeit fehlt Was sind rentable Sparten? Wie rentabel sind einzelne Produkte? Was kosten Produkte im Einkauf? Wie teuer wurden Produkte verkauft? Management: Kennzahlen fehlen Wie hoch sind die liquiden Mittel? Wie hoch sind die Außenstände? Sparten Produkte Einkauf/ Verkauf Geldflüsse Gebundene Werte 14

15 Referenzdaten Stammdaten Wohnkategorien Wohnart_ID Wohnart Bildung und Berufe Bildungs_GRP Lieferanten Lieferanten_Art Lieferant Lieferant_ID Vertriebskanäle Kanal Kanal_ID Internet, Baumarkt, Partner, Kette... Berufs_GRP_ID Berufs_GRP Einkommenskategorien Eink_GRP_ID Einkomm_GRP Regionen Land Kreis Ort Kundenstamm Kunderart KD_Karten_ID PrivatKD_Art Skonto_Proz Gr_Haushalt Fam_Stand Geb_Dat Name Kunden_ID Dienstleistungen Vermittl_Art_ID Vermittl_Art Produktgruppen Produktgrp_ID Produktgruppe Finanzleistung Handwerksleistung Computer, Haushaltsware, KFT... Produktarten Produktart_ID Produktart Geschäftssegmente Segement_ID Segment Produkte Pref_Liefer_ID VK_Preis Produkt Produkt_ID Vermittlung, Handelsware IT-Ware, Baumarktware 15

16 D_Kunden Alle_Kunden Land Kreis Ort Kunderart Wohnart_ID Wohnart KD_Karten_ID PrivatKD_Art Skonto_Proz Bildungs_GRP Berufs_GRP_ID Berufs_GRP Gr_Haushalt Fam_Stand Geb_Dat Eink_GRP_ID Einkomm_GRP Name Kunden_ID Segment Beruf& Bildung Merkmal Familie D_Zeit Alle_Zeiten Jahr Quartal Monat Monats_i_Jahr Tag_i_Jahr Tages_ID Segmentierung nach Einkommen F_Einkaeufe Mitarbeiter_ID Produkt_ID Lieferanten_ID EK_Preis Menge Lieferzeit_ID Zeit_ID Y F_Verkaeufe Zeiit_Id Kauf_ID Produkt_ID Positions_ID Menge VK_Wert Discout_Proz Kunden_ID Filial_ID D_Lieferanten Alle_Lieferant Land Kreis Ort Lieferanten_Art Lieferant Lieferant_ID Sicht auf - Geschäftsobjekte - Sicht auf Kennzahlen - Drillpfade - Synchronisierungselemente D_Produkt Alle_Produkte Kanal Kanal_ID Produktart_ID Produktart Segement_ID Segment Vermittl_Art_ID Vermittl_Art Produktgrp_ID Produktgruppe Pref_Liefer_ID VK_Preis Produkt Produkt_ID Internet, Baumarkt, Partner, Kette... Vermittlung, Handelsware IT-Ware, Baumarktware Finanzleistung Handwerksleistung Computer, Haushaltsware, KFT... 16

17 Multidimensionales Modell (Star Schema) Einstiegspunkte für Anwender-Abfragen Artikel A1 A2 A3 A4 Art1 Art2 Art3 Art4 Star Schema Flexibel Graphisch auch für Business-User verständlich Farbe Blau Gelb Rot Lila 1 : n V1 V2 V3 V4 Verkäufe R1 R2 R3 R4 A1 A2 A3 A4 Maier Müller Schmid Engel R1 R2 R3 R4 Nord Sued West Ost Z1 Z2 Z3 Z4 Status P F P F 1 : n V1 V2 V3 V4 n : Schwach Mittel Hoch Schwach Wohndichte Kunde n : 1 Regionen Zeit Z1 Z2 Z3 Z Q3 Q3 Q3 Q3 17

18 Multidimensionales Modell (Star Schema) Einstiegspunkte für Anwender-Abfragen Artikel A1 A2 A3 A4 Art1 Art2 Art3 Art4 Farbe Blau Gelb Rot Lila Dimensionen (Kontext) Star Schema Flexibel Graphisch auch für Business-User verständlich 1 : n V1 V2 V3 V4 Verkäufe A1 A2 A3 A4 R1 R2 R3 R4 Maier Müller Schmid Engel R1 R2 R3 R4 Nord Sued West Ost Z1 Z2 Z3 Z4 Status P F P F Dimensionen (Kontext) 1 : n Kennzahlen V1 V2 V3 V4 n : (Numerische Messungen) Schwach Mittel Hoch Schwach Dimensionen (Kontext) Wohndichte Kunde n : 1 Regionen Zeit Z1 Z2 Z3 Z Q3 Q3 Q3 Q3 Dimensionen (Kontext) 18

19 H i e r a r c h i e Dimensionen Levelschlüssel Dim_Artikel Artikelsparte_Langname Artikelsparte Artikelgruppe_Langtext Sparte Parent Aggregation Levelschlüssel Levelschlüssel/ Objektname Business Key Künstlicher Dimension Key Artikelgruppe Artikel_Langtext Artikel Artikel_Schlüssel Dim_Schlüssel Fakten (Umsatz) Parent Aggregation Konsolidierungslevel Betrachtungslevel 19

20 Unbalanced Hierarchy Star Schema-Design - Modellierungstechniken Teile Parent Teil von Fakt Gelieferte Teile Bestellkosten Lieferant Factless Fact Benutzte Teile Count Region Ort Kreis Land Region Produkte Sparte Gruppe Produkt Verkauf Fakten Zeit Produkt Lieferanten Zeit Conformed Dimension Verkäufer Verkaufsanteil Kunde Segment Alter Bildung Conformed Dimension Intersection- Table (Degenerated Fact) 1:1 Lieferant Verkäufer KD_CRM Anschrift Kontakt Ja-Umsatz Ausgelagerte Dimension Fakt Umsatz pro Verkäufer Bonusgruppe Bonusprogramm Degenerated Dimension 20

21 Varianten von Analyseprozessen 1. Kennzahlen-gesteuertes Event-Processing 2. Klassisches Standard-Berichtswesen x Operativer Prozess DWH 3. Interaktives Ad-Hoc-Analysen 4. Analyse-Cycle Problem Definition Data Preparation Model Building Deployment

22 Anforderungen aus den Analyseprozessen Modell form Nähe zu Operativen Prozessen Dauer der Analyse- Phase 1. Kennzahlen-gesteuertes Event-Processing Keine Vorgaben eng Sekunden 2. Klassisches Standard-Berichtswesen Keine Vorgaben weit Bis zu 24 Std. 3. Interaktives Ad-Hoc-Analysen multidimensional weit Bis zu 24 Std. 4. Analyse-Cycle Flach, maschinen-lesbar Sehr weit Wochen bis zu mehreren Jahren 22

23 Anforderungen aus den Analyseprozessen + Technologie Modell form Nähe zu Operativen Prozessen Dauer der Analyse- Phase Technologie 1. Kennzahlen-gesteuertes Event-Processing Keine Vorgaben eng Sekunden Materialized Views als vorbereitete Profile (event. nosql) 2. Klassisches Standard-Berichtswesen Keine Vorgaben weit Bis zu 24 Std. Materialized Views in Verbindung mit ETL 3. Interaktives Ad-Hoc-Analysen 4. Analyse-Cycle Multidimensional Flach, maschinenlesbar weit Sehr weit Bis zu 24 Std. Wochen bis zu mehreren Jahren Star Schema -> In-Memory / event. Views Flexibilität für interaktive Analysen, Alle ausgewählten Felder sind schnell analog OLAP - Würfel Mining Tabellen -> In-Memory Die Mining-tabellen werden für den jeweiligen Analyse-Prozess einzeln und gezielt In-Memory geladen 23

24 Allgemeine Regeln für das Star Schema Star Schema einfach halten Für Endbenutzer überschaubarer Nicht mit zu vielen Dimensionsattributen überfrachten Code-Attribute vermeiden Attribute mit beschreibenden Inhalten verwenden Sprechende Columnnamen verwenden Level-bezogene Präfixe verwenden Operativ genutzte Daten in separate Tabellen auslagern 1:1-Beziehung zu Dimensionen Star Schema = Virtualisierungs- Kandidat bei In-Memory Überfrachtete Dimensionen aufspalten Bei zu vielen Attributen Bei sehr oft genutzten Selektionskriterien Dimensionen mit nur einem Attribut in die Faktentabelle verlagern Keine Snowflakes nutzen 24

25 User View Layer (Faktentabellen) So granular wie möglich aufbauen Performance-Thematik separat lösen Keine eigene Faktentabelle bilden, nur um eine höhere Aggregations-Ebene zu erhalten Keine separate Faktentabelle aus Performance-Gründen Verwandte Faktentabellen schaffen Über gemeinsam genutzte Dimensionen (Conformed Dimensions) Die Faktentabelle besitzt keinen eigenen PK Zugriff nur über die Foreign Key-Felder Sätze müssen nicht eindeutig sein

26 Integration Layer 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ültige Wertebereichen Vorhandensein von Referenzdaten Eindeutigkeit (optional) Eliminierung von NULL-Werten...

27 Integration Layer Zusammenführung operativ getrennter Daten Bilden neuer Informationsobjekte mit dem Ziel der einfacheren Weiterverarbeitung (optional) Waisen-Management (optional) Bildung von Daten-Deltas (optional) 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

28 Enterprise Layer (DWH Kerndatenschicht) In Richtung 3. Normalform (3 NF) tendierend In Teilbereiche (Subject Areas) gegliedert aber sachgebietsübergreifend zusammenhängend Anwendungs- und Geschäftsprozess-neutral Dieselben Objekte werden in mehreren Geschäftsprozesse benötigt Daten müssen tauglich genug sein, um sie in allen Anwendungen zu verwenden Eindeutigkeit aller Objekte und Namen Redundanzfreiheit aller Informationen Langlebigkeit der Daten (Historisierung) Datenarten Stammdaten (historisiert) Referenzdaten externe / interne, allgemeine Sammlungen Bewegungsdaten / Transaktionslevel (angesammelt)

29 Regeln einer effizienten Data Warehouse Architektur Permanente Orientierung an den Informationsbedürfnissen der Benutzer Technisches und fachliches Monitoring von Inhalten und System Kompaktes Schichtenmodell schaffen Wege verkürzen Redundanzen in unterschiedlichen Schichten vermeiden Berechnungen / Aggregate so früh wie möglich durchführen Zusammenhängende Data Mart-Schicht Mehrfachnutzung von Dimensionen / Conformed Dimensions Geschickter Umgang mit sehr großen Faktentabellen / Vermeiden unnötiger Kopien Eher granulare Informationen auch in den Fakten-Tabellen Data Marts eventuell virtualisieren 29

30 Regeln einer effizienten Data Warehouse Architektur 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 Alle Schichten in einem DB-Raum Ein zusammenhängender DB-Server-Cluster zum Verhindern unnötiger Wege In-Database-Aktivitäten (Prüfen/Laden) Ein zusammenhängender DB-Server-Cluster zum Verhindern unnötiger Wege 1:1 Kopien verhindern Bereits beim Lesen in die Vorsysteme einfache Prüf- und Filteraktivitäten Updates und einzelne Deletes vermeiden ETL wiederholbar aufbauen 30

31 E x t e r n e I n t e r n e D a t e n Szenario DWH - Gesamtsicht OLTP Systeme Disk-Daten In Memory Integration Layer Temporäre Daten T T Referenzdaten Stammdaten Enterprise Layer Core - DWH / Info Pool R Partitionierte Transaktionsdaten nur wenn sie abgefragt werden R S S S Embedded Meta-Layer R Operational Data (virtuell) User View Layer (teils virtuell) Vorberechnete Kennzahlen C A MJ Q L JSON Unstructured JSON Data A Dimensionen als Views Fakten als In-Memory-Variante von Core-Transaktionen Kennzahlen-MAVs physikalisch R-Objekte physikalisch JSON-Objekte physikalisch JSON JSON Data Mining Statistikdaten HDFS / NoSQL Unstructured Data Oracle R

32 Grenzfälle: Wo Wünsche nach Verbesserungen entstehen Schichtenmodell ist Blaupause für Verantwortlichkeiten Integration Layer Enterprise Layer Core - DWH / Info Pool DWH- Admin User View Layer Fehlendes ganzheitliches Informationsmanagement Redundanzen, wenig Wiederverwendung, fehlende Synchronisation bei zusammenhängenden Themen Fehlende sachgebietsübergreifende Breite beim Informationsangebot Zu hohe Latenz-Zeiten Integration Layer Enterprise Layer Core - DWH / Info Pool DWH- Admin Zu geringe Flexibilität und Schnelligkeit in den Projekten bei der Umsetzung neuer Informations-Bedarfe User View Layer User View Layer User View Layer 32

33 Die Rolle der zentralen Schicht End-Anwender benötigen diese Schicht nicht! Integration Layer Aber: Sie hat eine strategische und taktische Bedeutung Enterprise Layer Core - DWH / Info Pool????????? Historisches Wissen (strategisch) Sachgebiets-übergreifende Zusammenhänge (Enterprise-View, strategisch) Projekt-taktische und Maintenance Aspekte: schnelles Erzeugen neuer Strukturen Integriertes Datenmodell verhindert Redundanzen Leichtere Organisation des Gesamt-ETL-Ablaufs: Einfacheres Normalisierung / Denormalisierungs-Schema User View Layer 33

34 Zugriff von Endbenutzern auf die zentrale Schicht Nicht akzeptiert werden Gründe wie Security-Gründe Hoheits-Denken des DB-Administrators Performance-Gründe Überkommene und unreflektierte Standard-Architekturen So haben wir das immer schon gemacht, Das steht in unserem Architektur-Blueprint Integration Layer Enterprise Layer Core - DWH / Info Pool????????? User View Layer 34

35 Partitionierung

36 Partitioning unterstützt viele Aufgaben Große Tabellen Tablespace Query Performance Partition Pruning Beschleunigung des Ladeprozesses Tablespace Tablespace Tablespace Tablespace Unterstützung ILM (Information Lifecycle Management) Leichterer Umgang mit Indizierung Feld für Partitionierungs- Kriterium nach fachlichen oder organisatorischen Gesichtspunkten ausgewählt Tablespace Range List Hash Unterstützung im Backup-Prozess Unterstützung bei der Aktualisierung von Materialized Views (Partition Change Tracking) Steuerung der Komprimierung Hochverfügbarkeit auch während des Ladens und Maintenance 36

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

38 Partitioning ist transparent Gesamte Tabelle selektieren SELECT * FROM orders; Abfrage nur auf eine Partition Alle Partitionen werden selektiert SELECT * FROM orders WHERE order_dat Partition Pruning: between to_date Automatische (' ') Beschränkung AND SQL-Abfrage to_date ist von (' '); Partitionierung unabhängig auf betroffene Partition Jan 2007 Feb 2007 Mär 2007 Apr 2007 Mai 2007 Jun

39 Range Partitioning - Partitionierung nach Wertebereichen Partitionierung nach Wertebereichen Für sortierte Wertebereiche LESS THAN: Angabe eines maximalen Wertes pro Partition CREATE TABLE F_Umsatz ( Artikel_ID number, Kunden_ID number, Zeit_ID DATE, Region_ID number, Umsatz number, Menge number ) PARTITION BY RANGE (Zeit_ID) ( PARTITION M1 VALUES LESS THAN (to_date(' ','yyyy-dd-mm')), PARTITION M2 VALUES LESS THAN (to_date(' ','yyyy-dd-mm')),... Jan 2007 Feb 2007 Mär 2007 Apr 2007 Mai 2007 Jun

40 Interval Partitioning Erweiterung der Range-Partitionierung Automatisierung für gleichgroße Range-Partitionen Mai Maidaten? Partitionierung wird als Metadaten-Information abgelegt Start-Partition ist dabei persistent Sobald neue Daten hinzukommen werden Segmente allokiert April März Februar Januar Aprildaten Märzdaten Februardaten Januardaten April März Februar Januar Produkte Lokale Indizes werden automatisch mitgepflegt Kunden Partition Key muss NUMBER oder DATE sein Partition-Typ muss RANGE sein 41

41 Interval Partitioning Syntax CREATE TABLE "BESTELLUNG" ( "BESTELLNR" NUMBER(10) NOT NULL, "KUNDENCODE" NUMBER(10), "BESTELLDATUM" DATE, "AUFTRAGSART" VARCHAR2(30)) PARTITION BY RANGE ("BESTELLDATUM") INTERVAL(NUMTOYMINTERVAL(1,'MONTH')) ( PARTITION "Jan07" VALUES LESS THAN (TO_DATE(' :00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN')) TABLESPACE "TS_PAR,...) ; CREATE TABLE POSITION" ( "POSITIONSNR" NUMBER(10) NOT NULL, "BESTELLNR" NUMBER(10) "ARTIKELNUMMER" NUMBER) contraint FK_BEST FOREIGN KEY (BESTELLNR) REFERENCES BESTELLUNG PARTITION BY REFERENCE (FK_BEST); 42

42 Interval Partitioning Nachträgliches Ändern der Zyklen Range-partitionierte Tabellen können umgestellt werden Einfaches Metadaten Kommando Investitionsschutz Table F_Umsatz_Interval Q Q Oct 2006 Bisherige Range Partition Table Neue monatliche Interval Partitions ALTER TABLE F_Umsatz_Interval SET INTERVAL(NUMTOYMINTERVAL(1,'month');

43 List Partitioning Für diskrete, unsortierte Werte Angabe einer Werteliste pro Partition VALUES (DEFAULT) für alles andere Verhalten wie MAXVALUE in der Range-Partitionierung AMER EMEA APAC CREATE TABLE bestellung ( bestellnr number, auftragsart varchar2(40), land varchar2(2) ) PARTITION BY LIST (land) ( PARTITION EMEA VALUES ('DE','FR',[..]), PARTITION AMER VALUES ('US','CA',[..]), PARTITION APAC VALUES ('JP','CN',[..]), PARTITION OTHERS VALUES (DEFAULT) ) 44

44 Hash Partitioning - Gleichverteilung der Daten Partitionierung nach Hash-Wert des Partition Key Schlüsseltypen: Alle built-in Datentypen außer ROWID, LONG, LOB Ziel: Gleichverteilung der Daten Anzahl Partitionen: als Potenz von 2 empfohlen CREATE TABLE F_Umsatz_HASH ( Artikel_ID number, Kunden_ID number, Zeit_ID DATE, Region_ID number, Umsatz number, Menge number ) PARTITION BY HASH (Zeit_ID) PARTITIONS 4 45

45 Reference Partitioning Anwendung im DWH eher selten PK Beispiel abhängige Faktentabellen BestellNr KundenNr BestellDatum Bondaten (Kopf- / Positionsdaten) FK PK April BestellNr ArtikelNr Menge PosNr März Februar Januar Bestellungen April März Februar Januar BestellNr FK LieferNr April März Februar PosNr Bestell_Positionen Januar Auslieferungen 46

46 Zuweisen unterschiedlicher Tablespaces ALTER TABLE Bestellung ADD PARTITION "DEZ08" VALUES LESS THAN (to_date(' :00:00','SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN')) TABLESPACE "TS_PAR" DEPENDENT TABLES (Best_Position(PARTITION DEZ08_Child TABLESPACE TS_DEZ08_Child)); 48

47 Virtual Column Partitioning Produktnummer Menge Preis Abnehmer Anwendung im DWH eher selten IM ETL-Prozess würde man stattdessen eine zusätzliche Spalte erstellen Partitionierung einer Bestelltabelle nach den Produktgruppen. Die Nummer der Produktgruppen ist allerdings Bestandteil der Produktnummer ( Stelle). 4711GBEMP , GBEMP , GBEMP , LEERM , LEERM , LEERM , UAGBM , UAGBM , UAGBM ,70... substr(produktnummer,4,5) P1 P2 P3 Für alle Partitioning-/Subpartitioning-Varianten einsetzbar 49

48 Composite Partitioning Range... Range Range Range Hash Range - List Produkt JAN 07 FEB 07 MAR 07 List... List - Range List - Hash List - List Service Storno 50

49 ARTIKEL_ID FK KUNDEN_ID FK ZEIT_ID REGION_ID FK KANAL_ID FK UMSATZ FK MENGE UMSATZ_GESAMT Partitionierung im Star D_ZEIT DATUM_ID TAG_DES_MONATS TAG_DES_JAHRES WOCHE_DES_JAHRES MONATS_NUMMER MONAT_DESC QUARTALS_NUMMER JAHR_NUMMER ZEIT_ID PK Range-Partitioning nach Zeit Mehr als 80 % aller Partitionierungen sind so aufgebaut. D_VERTRIEBSKANAL KANAL_ID PK VERTRIEBSKANAL KANALBESCHREIBUNG VERANTWORTLICH KLASSE F_UMSATZ PK: Btree Index FK: Bitmap Index 51

50 ARTIKEL_ID FK KUNDEN_ID FK ZEIT_ID REGION_ID FK KANAL_ID FK UMSATZ FK MENGE UMSATZ_GESAMT Partitionierung im Star D_ZEIT DATUM_ID TAG_DES_MONATS TAG_DES_JAHRES WOCHE_DES_JAHRES MONATS_NUMMER MONAT_DESC QUARTALS_NUMMER JAHR_NUMMER ZEIT_ID PK Range-Partitioning nach Zeit List-Partitioning nach Vertriebskanal Mehr als 80 % aller Partitionierungen sind so aufgebaut. D_VERTRIEBSKANAL KANAL_ID PK VERTRIEBSKANAL KANALBESCHREIBUNG VERANTWORTLICH KLASSE F_UMSATZ PK: Btree Index FK: Bitmap Index 52

51 Beispiel Range-List CREATE TABLE f_umsatz_range_list (ARTIKEL_ID NUMBER(10), KUNDEN_ID NUMBER(10), ZEIT_ID DATE, REGION_ID NUMBER(10), KANAL_ID NUMBER(10), UMSATZ NUMBER(10), MENGE NUMBER(10), UMSATZ_GESAMT NUMBER(10) ) PARTITION BY RANGE (ZEIT_ID) SUBPARTITION BY LIST (KANAL_ID) SUBPARTITION TEMPLATE ( SUBPARTITION kanal1 VALUES (1), SUBPARTITION kanal2 VALUES (2), SUBPARTITION kanal3 VALUES (3), SUBPARTITION kanal4 VALUES (4), SUBPARTITION kanal5 VALUES (5), SUBPARTITION kanal6 VALUES (6), SUBPARTITION kanal7 VALUES (7) ) ( PARTITION jan10 VALUES LESS THAN (TO_DATE(' ','SYYYY-MM-DD')), PARTITION feb10 VALUES LESS THAN (TO_DATE(' ','SYYYY-MM-DD')), PARTITION nov11 VALUES LESS THAN (TO_DATE(' ','SYYYY-MM-DD')), PARTITION dec11 VALUES LESS THAN (TO_DATE(' ','SYYYY-MM-DD')), PARTITION next_month VALUES LESS THAN (MAXVALUE));

52 54 Beispiel List-List Beispiel für die nachfolgende Systemabfrage CREATE TABLE "BESTELLUNG" ( "BESTELLNR" NUMBER(10) NOT NULL, "KUNDENCODE" NUMBER(10), "BESTELLDATUM" DATE, "LIEFERDATUM" DATE, "BESTELL_TOTAL" NUMBER(12, 2), "AUFTRAGSART" VARCHAR2(30), "VERTRIEBSKANAL" NUMBER ) PARTITION BY LIST ("VERTRIEBSKANAL") SUBPARTITION BY LIST ("AUFTRAGSART") SUBPARTITION TEMPLATE ( SUBPARTITION Produkt VALUES ('ARTIKEL','TAUSCHWARE'), SUBPARTITION Service VALUES ('SERVICE','REISE'), SUBPARTITION Storno VALUES ('RETOURE','KOMMISSION'), SUBPARTITION Andere VALUES (default) ) ( PARTITION Telefon VALUES (1,2,3), PARTITION Aussendienst VALUES (4,5), PARTITION Web VALUES (6,7), PARTITION PARTNER VALUES (8,9,10) );

53 Systemabfragen col subpartition_name format a15 col partition_name format a15 col SUBPARTITION_POSITION format SELECT table_name, partition_name, subpartition_name, subpartition_position FROM user_tab_subpartitions; TABLE_NAME PARTITION_NAME SUBPARTITION_NA SUBPARTITION_POSITION BESTELLUNG Jan08 Jan08_ANDERE 4 BESTELLUNG Jan08 Jan08_STORNO 3 BESTELLUNG Jan08 Jan08_SERVICE 2 BESTELLUNG Jan08 Jan08_PRODUKT 1 BESTELLUNG Feb08 Feb08_ANDERE 4 BESTELLUNG Feb08 Feb08_STORNO 3 BESTELLUNG Feb08 Feb08_SERVICE 2 BESTELLUNG Feb08 Feb08_PRODUKT 1 BESTELLUNG Mar08 Mar08_ANDERE 4 BESTELLUNG Mar08 Mar08_STORNO 3 BESTELLUNG Mar08 Mar08_SERVICE 2 55

54 Partitionwise Join im DWH Das Partitionieren von Dimensionen ergibt heute oft nur eingeschränkt einen Sinn Oft zu klein im Vergleich zu einer Faktentabelle Fachlich ist meist kein gleiches Partitionierungskriterium zu finden Ausnahmen Abfragen über 2 große Tabellen z. B. große Faktentabellen Zahlungen Leistungen Bonköpfe 1 : n Bonpositionen 56

55 Verwaltung von Partitionen ADD PARTITION DROP PARTITION TRUNCATE PARTITION MOVE PARTITION SPLIT PARTITION MERGE PARTITION EXCHANGE PARTITION Verändern der Default-/ realen Attribute Partition Exchange Loading 57

56 Add / Rename / Truncate Partition Add Partition (Globale und lokale Indizes bleiben USABLE ) ALTER TABLE BESTELLUNG ADD PARTITION "NOV08" VALUES LESS THAN (to_date(' :00:00','SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN')) TABLESPACE "TS_PAR" Umbenennen einer Partition ALTER TABLE Bestellung RENAME PARTITION Andere TO Bestellung_Rest; Truncate einer Partition ALTER TABLE Bestellung TRUNCATE PARTITION Service DROP STORAGE; Ändern des Tablespace einer Partition (Wirkt sich nur auf künftige Partitionen aus) ALTER TABLE BESTELLUNG MODIFY DEFAULT ATTRIBUTES FOR PARTITION "Jan08" TABLESPACE TS_PAR_JAN ; 58

57 Moving Partition Fragmentierung beheben Umziehen in einen anderen Tablespace Komprimierung der Daten einer Partition CREATE TABLESPACE TS_PAR_Archiv DATAFILE D:\o11\oradata\o11\TS_PAR_Archiv.f' SIZE 10m REUSE; ALTER TABLE BESTELLUNG MOVE PARTITION "Jan08" TABLESPACE TS_PAR_Archiv; CREATE TABLESPACE TS_PAR_Archiv_Jan DATAFILE 'D:\o11\oradata\o11\TS_PAR_Archiv_Jan.f' SIZE 10m REUSE; TS_Gesamt P1 sub sub sub TS_Einzel_1 sub ALTER TABLE BESTELLUNG MOVE SUBPARTITION "Jan08_STORNO" TABLESPACE TS_PAR_Archiv_Jan; P2 P3 P4 P5 sub sub sub sub sub sub sub sub sub sub sub sub TS_Einzel_2 sub TS_Archiv Transparente MOVE PARTITION ONLINE Operation Gleichzeitig DML und Abfragen möglich Index Pflege für lokale und globale Indizes P6 sub sub sub sub sub sub P7 sub sub sub 59

58 Split und Merge von Partition ALTER TABLE Bestellung SPLIT PARTITION "Jan08" AT (to_date('15-jan-2008','dd-mon-yyyy')) INTO (PARTITION Jan08_1, PARTITION Jan08_2) UPDATE GLOBAL INDEXES; ALTER TABLE BESTELLUNG MERGE SUBPARTITIONS TELEFON_STORNO, TELEFON_ANDERE INTO SUBPARTITION TELEFON_OBJEKTE TABLESPACE TS_PAR; SELECT table_name, partition_name, high_value FROM user_tab_partitions WHERE table_name = 'BESTELLUNG '; sub1 subx ParX Par1 Par2 Nicht für Reference / Hash Partitioned Tables anwendbar Indizes werden UNUSABLE gesetzt sub2 Verschmolzen wird immer eine Liste von Partitionen / Subpartitionen Die neue Partition darf noch nicht existieren Funktioniert auch für Reference Partitioning, d.h. MERGE-Operation auf Parent Table wirkt sich auch auf die abhängige Tabelle aus 60

59 Erweiterte Partitionspflege Operationen Ein Operation bezieht sich auf mehrere Partitionen Parallelisiert Transparente Pflege lokaler und globaler Inidizes ALTER TABLE orders MERGE PARTITIONS Jan2009, Feb2009, Mar2009 INTO PARTITION Quarter1_2009 COMPRESS FOR ARCHIVE HIGH;

60 Ändern von Werten bei List Partitioning SQL> ALTER TABLE Bestellung 2 MODIFY PARTITION Produkt 3 ADD VALUES ('WARE'); Tabelle wurde geändert. SQL> ALTER TABLE Bestellung 2 MODIFY PARTITION Storno 3 DROP VALUES ('KOMMISSION'); Tabelle wurde geändert. SQL> SELECT partition_name, tablespace_name, high_value 2 FROM user_tab_partitions 3 WHERE table_name = 'BESTELLUNG'; PARTITION_NAME TABLESPACE_NAME HIGH_VALUE PRODUKT USERS 'ARTIKEL', 'TAUSCHWARE', 'PRODUKT', 'WARE' SERVICE USERS 'SERVICE', 'REISE' STORNO USERS 'RETOURE' ANDERE USERS default 62

61 Erstellen einer Tabelle aus einer Partition EXCHANGE SQL> CREATE TABLE Bestellung_Produkte AS 2 SELECT * FROM bestellung WHERE 1=2 SQL> / Tabelle wurde erstellt. TS_Gesamt SQL> ALTER TABLE Bestellung 2 EXCHANGE PARTITION Produkt 3 WITH TABLE Bestellung_Produkte; P1 sub sub sub P2 sub sub sub Die Zieltabelle muss existieren P3 sub sub sub P4 sub sub sub Tabelle X Allgemeine Syntax: P5 P6 P7 sub sub sub sub sub sub sub sub sub ALTER TABLE <Tabellen-Name> EXCHANGE PARTITION <Partition-Name> WITH TABLE <neue Tabelle> <including excluding> INDEXES <with without> VALIDATION EXCEPTIONS INTO <Schema.Tabellen-Name>; 63

62 Data Dictionary DBA_PART_TABLES Table-Level DBA_TAB_PARTITIONS DBA_TAB_SUBPARTITIONS DBA_PART_KEY_COLUMNS DBA_SUBPART_KEY_COLUMNS DBA_PART_COL_STATISTICS DBA_SUBPART_COL_STATISTICS Partition-/Subpartition-Level Partition-/Subpartition- Key- Informationen Statistiken und Histogramme per Partition / Subpartition 64

63 Wo und wie wird im DWH partitioniert Partitioning und Ladesteuerung laufen oft synchron Parallelisierung L a d e - A k t i v i t ä t e n Data Integration Layer T T T 20% PEL 80% Enterprise Information Layer R R S S S B B L e s e - A k t i v i t ä t e n Partition Pruning Parallelisierung User View Layer D F D D D R: Referenztabellen T: Transfertabellen S: Stammdaten B: Bewgungsdaten D: Dimensionen F: Fakten ILM Backup Vorbereitung Temporäre Tabellen (Prüfungen etc) Bewegungsdaten sind Partitioniert (80/20 Prinzip) Faktentabellen und Würfel können partitioniert sein 65

64 Wo wird Partitioning wieder vorkommen Indizierung Materialized Views Partition Exchange and Load Parallelisierung Life Cycle Management / Storage Management Bessere Verwaltung großer Tabellen Verbesserung der Verfügbarkeit und Performance Ressourcen werden geschont und geben Rechenkapazitäten frei Transparente Anwendung, d.h. Nutzung ohne Änderung an der Applikation Ermöglicht Information Lifecycle Management: Nutzung unterschiedlicher Storage-Klassen, je nach Zugriffshäufigkeit -> Einsparung von Storagekosten 66

65 Schlüssel und Indizierung im Data Warehouse

66 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 68

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

68 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 70

69 B*Tree Index 4 Zugriffe bis zum Wert 1 Clustering Factor Zugriff über die RowID

70 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 AAAHfVAAJAAAKOKAAA Abschluss= Klasse_10 1 Abschluss= Abitur 0 Abschluss= Diplom 0 Abschluss= Doktor 0 AAAHfVAAJAAAKOKAAB AAAHfVAAJAAAKOKAAC AAAHfVAAJAAAKOKAAD SELECT Name FROM KD_Table WHERE Abschluss= Diplom ; AAAHfVAAJAAAKOKAAE AAAHfVAAJAAAKOKAAF AAAHfVAAJAAAKOKAAG AAAHfVAAJAAAKOKAAH

71 Platzverbrauch im Vergleich CREATE TABLE I_Kunde (KD_NR Name Geb_Dat Bildungsgruppe KR_Rating_1_bis_Variabel number, varchar2(30), date, varchar2(30), number); Tests mit unterschiedlicher Kardinalität SELECT index_name,index_type blevel, leaf_blocks, distinct_keys FROM user_indexes; Anzahl Sätze Distinct Werte Prozent Leaf_ Blocks BTree Leaf_ Blocks bitmap Bildungsgruppe Bildungsgruppe Geb_Dat KR_Rating_1_bis_Varia KD_NR

72 Aktualisieren von Indexen OLTP-Option: Rebuild Index Operation ALTER INDEX index_name REBUILD [ NOLOGGING ]; Schneller als DROP / CREATE NOLOGGING-Klausel Fragmentierung wird beseitigt Wenig hilfreich im DWH Änderungen aber oft als Batch-Lauf durchgeführt Zunächst DROP INDEX (beschleunigt den Batch-Lauf) Dann Neuerstellen des Index Oder 1. INDEX auf Unusable setzen [Alter index index_name usable] 2. ETL-Massen-Load 3. INDEX Rebuild [Alter index index_name rebuild] 74

73 Indexed-organized Tabellen Index organized Tables (IOT) Blöcke sind entsprechend einer Btree-artigen Organisation abgelegt Jeder Leaf-Block speichert sowohl Werte eines Schlüssel und von nicht-schlüssel-feldern -Schneller Random Zugriff (Einzelsatzlesen) - Schneller Range-Scan weil die Daten bereits geclustert sind - Spart Platz, weil kein Platz für separaten Index benötigt wird Heap Tables Blöcke sind nach einem Heap-Mechanisums abgelegt (Zufallsverfahren) Schlüsselwerte sind zusätzlich in einer Btree-Indey-Struktur abgelegt Alle Zugriffe in der Regel über einen separaten Index Relevanz für das DWH gering Zwingt zur Eindeutigkeit der Sätze Erfordert bei Massen Import eine Orientierung an der Index-Struktur und Constraintprüfung -> bremst aus Ausnahmen: sehr große Dimensionstabellen

74 Partitionierung und Indizierung im Data Warehouse

75 Partitioning und Indizes Lokale Indizes Nicht-partitionierte oder partitionierte globale Indizes USABLE oder UNUSABLE Index Segmente Nicht-persistenter Index Status Losgelöst von der Tabelle Partielle lokale und globale Indizes Erwirkt spezielle Metadaten auf [Sub]Partitionsebene Interagiert mit dem USABLE/UNUSABLE Status für lokale Indizes Indizierung jederzeit anpassbar

76 Bestelldatum Kundennummer Auftragsart Partition Key Bestelldatum Prefixed / Non Prefixed Indexes Partitionierte Tabelle Bestellung Local Index Indiziert nach Bestelldatum Prefixed local Index Indiziert nach Bestelldatum, Kundennummer Non-Prefixed Indiziert nach Auftragsart Im DWH relevante Variante Einfacher Index Gut für Management der Partitionen Gut für nicht Part-Key gesteuerte Abfragen 78

77 Globale Indexe CREATE TABLE f_umsatz_range (ARTIKEL_ID NUMBER(10), KUNDEN_ID NUMBER(10), ZEIT_ID DATE, REGION_ID NUMBER(10), KANAL_ID NUMBER(10), UMSATZ NUMBER(10), MENGE NUMBER(10), UMSATZ_GESAMT NUMBER(10) ) PARTITION BY RANGE (ZEIT_ID) ( PARTITION jan10 VALUES LESS THAN (TO_DATE(' ','SYYYY-MM-DD')), PARTITION feb10 VALUES LESS THAN (TO_DATE(' ','SYYYY-MM-DD')), PARTITION mar10 VALUES LESS THAN (TO_DATE(' ','SYYYY-MM-DD')), PARTITION dec11 VALUES LESS THAN (TO_DATE(' ','SYYYY-MM-DD')), PARTITION next_month VALUES LESS THAN (MAXVALUE)); CREATE INDEX idx_umsatz_range on f_umsatz_range (Kunden_id) GLOBAL PARTITION BY RANGE (Kunden_id) ( PARTITION index100 VALUES LESS THAN (100), PARTITION index500 VALUES LESS THAN (500), PARTITION index1000 VALUES LESS THAN (1000), PARTITION index_max VALUES LESS THAN (MAXVALUE) );

78 Lokale Indizes CREATE TABLE f_umsatz_range (ARTIKEL_ID NUMBER(10), KUNDEN_ID NUMBER(10), ZEIT_ID DATE, REGION_ID NUMBER(10), KANAL_ID NUMBER(10), UMSATZ NUMBER(10), MENGE NUMBER(10), UMSATZ_GESAMT NUMBER(10) ) PARTITION BY RANGE (ZEIT_ID) ( PARTITION jan10 VALUES LESS THAN (TO_DATE(' ','SYYYY-MM-DD')), PARTITION feb10 VALUES LESS THAN (TO_DATE(' ','SYYYY-MM-DD')), PARTITION mar10 VALUES LESS THAN (TO_DATE(' ','SYYYY-MM-DD')), PARTITION dec11 VALUES LESS THAN (TO_DATE(' ','SYYYY-MM-DD')), PARTITION next_month VALUES LESS THAN (MAXVALUE)); CREATE INDEX idx_artikel_id ON F_Umsatz_range (Artikel_id) LOCAL; CREATE INDEX idx_region_id ON F_Umsatz_range (region_id) LOCAL; 80

79 Indizes anzeigen lassen Welche Indexe gibt es für eine Tabelle SELECT index_name, partitioned FROM user_indexes WHERE table_name = 'BESTELLUNG_RANGE'; INDEX_NAME PAR PK_DATE_BESTELL YES Auflistung von Index-Partitionen SELECT ip.index_name, ip.composite, ip.partition_name, ip.high_value FROM user_ind_partitions ip, user_indexes ui WHERE ip.index_name = ui.index_name AND ui.table_name = 'BESTELLUNG'; INDEX_NAME COM PARTITION_NAME HIGH_VALUE BEST_DAT NO Feb07 TO_DATE(' BEST_DAT NO Jan07 TO_DATE(' BEST_DAT NO Mar07 TO_DATE(' BEST_DAT NO Apr07 TO_DATE('

80 Partielle lokale und globale Indizes

81 Operationen auf lokale Indizes Änderungs-Operationen wie ADD, DROP, SPLIT, MERGE werden von der Tabelle auf den Index übertragen Rebuild Partiton Index Rebuild Subpartiton Index Verschieben auf einen anderen Table ALTER TABLE <table_name> MODIFY PARTITION <partition_name> REBUILD UNUSABLE LOCAL INDEXES; ALTER TABLE <table_name> MODIFY SUBPARTITION <subpartition_name> REBUILD UNUSABLE LOCAL INDEXES; ALTER INDEX <index_name> REBUILD PARTITION <partition_name> TABLESPACE <new_tablespace_name>; 83

82 Asynchrone Global Index Pflege Nach DROP oder TRUNCATE PARTITION bleibt der globale Index auch ohne Index Pfege valide Betroffene Partitionen sind intern bekannt und werden während des Zugriffs herausgefiltert Verzögerte Global Index Pflege Anstoß durch ALTER INDEX REBUILD COALESCE Automatisierbar in einem Datenbank-Job

83 Star Query Transformation

84 86 Beispiel Star Schema D_ZEIT DATUM_ID TAG_DES_MONATS TAG_DES_JAHRES WOCHE_DES_JAHRES MONATS_NUMMER MONAT_DESC QUARTALS_NUMMER JAHR_NUMMER ZEIT_ID PK D_REGION REGION_ID ORTNR ORT KREISNR KREIS LANDNR LAND REGIONNR REGION PK D_VERTRIEBSKANAL KANAL_ID PK VERTRIEBSKANAL KANALBESCHREIBUNG VERANTWORTLICH KLASSE F_UMSATZ D_ARTIKEL ARTIKEL_NAME GRUPPE_NR GRUPPE_NAME SPARTE_NAME SPARTE_NR ARTIKEL_ID ARTIKEL_ID FK KUNDEN_ID FK ZEIT_ID FK REGION_ID FK KANAL_ID FK UMSATZ MENGE UMSATZ_GESAMT PK PK: Btree Index FK: Bitmap Index D_KUNDE KUNDEN_ID PK 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

85 Star Query Transformation Optimierung für Joins mit großen Faktentabellen SELECT sum(summe) FROM F_Umsatz U, D_Artikel A, D_Region R, D_Zeit Z, D_Kunde K WHERE U.FK_Kunden_ID AND U.FK_Datum_ID AND U.FK_Ort_ID AND U.FK_Artikel_Nummer = K.Kunden_ID = Z.Datum_ID = R.Ort_ID = A.Nummer AND Z.JAHR_NUMMER = 2008 AND A.GRUPPE_NR = 3 AND K.KUNDENART = 8 AND R.REGION_Name IN ('MITTE','SUED','NORD'); 87

86 STAR_TRANSFORMATION_ENABLED=FALSE; Abgelaufen: 00:00: Id Operation Name Rows Bytes Cost (%CPU) Time SELECT STATEMENT (2) 00:00:13 1 SORT AGGREGATE NESTED LOOPS 3 NESTED LOOPS (2) 00:00:13 * 4 HASH JOIN (2) 00:00:13 * 5 HASH JOIN (2) 00:00:13 * 6 TABLE ACCESS FULL D_ZEIT (0) 00:00:01 * 7 HASH JOIN (2) 00:00:13 * 8 TABLE ACCESS FULL D_KUNDE (0) 00:00:01 9 TABLE ACCESS FULL F_UMSATZ 1010K 18M 1001 (2) 00:00:13 * 10 TABLE ACCESS FULL D_ARTIKEL (0) 00:00:01 * 11 INDEX UNIQUE SCAN PK_REGION 1 0 (0) 00:00:01 * 12 TABLE ACCESS BY INDEX ROWID D_REGION (0) 00:00:

87 STAR_TRANSFORMATION_ENABLED=TRUE; Abgelaufen: 00:00: Id Operation Name Rows Bytes Cost (%CPU) Time SELECT STATEMENT (2) 00:00:03 1 SORT AGGREGATE TABLE ACCESS BY INDEX ROWID F_UMSATZ (2) 00:00:03 3 BITMAP CONVERSION TO ROWIDS 4 BITMAP AND 5 BITMAP MERGE 6 BITMAP KEY ITERATION * 7 TABLE ACCESS FULL D_KUNDE (0) 00:00:01 * 8 BITMAP INDEX RANGE SCAN IDX_FK_KUNDEN_ID_BM 9 BITMAP MERGE 10 BITMAP KEY ITERATION * 11 TABLE ACCESS FULL D_ARTIKEL (0) 00:00:01 * 12 BITMAP INDEX RANGE SCAN IDX_FK_ARTIKEL_NUMMER_BM 13 BITMAP MERGE 14 BITMAP KEY ITERATION * 15 TABLE ACCESS FULL D_ZEIT (0) 00:00:01 * 16 BITMAP INDEX RANGE SCAN IDX_FK_DATUM_ID_BM 17 BITMAP MERGE 18 BITMAP KEY ITERATION * 19 TABLE ACCESS FULL D_REGION (0) 00:00:01 * 20 BITMAP INDEX RANGE SCAN IDX_FK_ORT_ID_BM

88 Star Query Transformation 1. Zugriff auf die Faktentabelle und Lookup mit den Filterkriterien auf Dimension 1 zur Erzeugung eines Bitmap entsprechend der Primary Keys 2. Wiederholen für alle Dimensionen 3. AND-Verknüpfung der Bitmaps und Suchen nach den Faktentabellen- Row IDs 4. Zugriff mit gefundenen Row IDs auf die Faktentabelle 5. Evtl. Join-back auf die Dimensionen für die restlichen Spalten, die benötigt werden. Es findet zu keinem Zeitpunkt ein Full Table Scan auf der Faktentabelle statt 90

89 Bedingungen für die Star-Transformation STAR_TRANSFORMATION_ENABLED=TRUE Keine Bind Variable im SELECT Statement, kein CONNECT BY und kein START WITH verwenden Die Faktentabelle Muss mehr als Sätze haben (Stand 10g) Kann keine View sein Kann keine Remote-Tabelle sein Muss mehr als 2 Bitmap Indizes haben Die Foreign Key Felder müssen als Bitmap Index definiert sein (Faktentabelle) Ein Foreign Key Constraint als solches muss nicht definiert sein 91

90 Indizierung im Star D_ZEIT DATUM_ID TAG_DES_MONATS TAG_DES_JAHRES WOCHE_DES_JAHRES MONATS_NUMMER MONAT_DESC QUARTALS_NUMMER JAHR_NUMMER ZEIT_ID PK D_REGION REGION_ID ORTNR ORT KREISNR KREIS LANDNR LAND REGIONNR REGION PK D_VERTRIEBSKANAL KANAL_ID PK VERTRIEBSKANAL KANALBESCHREIBUNG VERANTWORTLICH KLASSE F_UMSATZ D_ARTIKEL ARTIKEL_NAME GRUPPE_NR GRUPPE_NAME SPARTE_NAME SPARTE_NR ARTIKEL_ID ARTIKEL_ID FK KUNDEN_ID FK ZEIT_ID FK REGION_ID FK KANAL_ID FK UMSATZ MENGE UMSATZ_GESAMT PK PK: Btree Index FK: Bitmap Index D_KUNDE KUNDEN_ID PK 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 92

91 Werden Index immer gebraucht? Im DWH gibt es eine grundsätzlich andere Verwendung von Indexen OLTP Einzelne Selects Einzelne Inserts Oft Verwaltung über Contraints (z. B. Unique Key) DWH Selects über Datenbereiche Massen-Inserts Möglichkeiten im Verlauf des ETL- Prozesses alter index PK_BESTELLNR_PART_RANGE_HASH monitoring usage SELECT INDEX_NAME, TABLE_NAME, MONITORING, USED FROM SYS.V$OBJECT_USAGE => Im DWH eher Bitmap-Indexe als Btree Usage-Monitor zeigt, ob ein Index wirklich genutzt wurde

92 Wo und wie wird im DWH indiziert L a d e - A k t i v i t ä t e n L e s e - A k t i v i t ä t e n 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

93 Komprimierung im Data Warehouse

94 Bedingungen im Data Warehouse Kompressionskonzept Komprimierung besonders wichtig, da große Datenmengen Besonders krasser Unterschied zwischen Daten, die häufig gelesen werden Sehr wenige Daten, die selten bis kaum gelesen werden Sehr viele Lese- und Schreib-Operationen sind bestimmbar Massen-Schreibaktionen können explizit auch zum Komprimieren genutzt werden Updates kommen seltener vor 96

95 Das Datenwachstum beherrschen Komprimieren: Verwaltung und Kosten reduzieren Kompressions Typ: Einsatz für: Faktor Basic Compression OLTP Compression SecureFiles Compression Index Compression Backup Compression Hybrid Columnar Compression Data Warehousing Hybrid Columnar Compression Archival Read only Tabellen und Partitionen in Data Warehouse 2-4 Umgebungen oder inaktive Daten-Partitionen in OLTP Umgebungen. Aktive Tabellen und Partitionen in OLTP und Data Warehouse 2-4 Umgebungen. Non-relational Daten in OLTP und Data Warehouse Umgebungen. 2-4 Indizes auf Tabellen in OLTP und Data Warehouse Umgebungen. 2 Alle Umgebungen. 2 Read only Tabellen und Partitionen in Data Warehouse Umgebungen. Inaktive Daten Partitionen in OLTP und Data Warehousing Umgebungen

96 Anwendung für Komprimierung In der DB EE für Indizes Strukturierte Daten in Tabellen (bzw. Partitionen) mit DIRECT Load Mit der Option Advanced Compression auch für Unstrukturierte Datentypen (SecureFiles) Konventionelles DML (OLTP Compression) DataPump Daten und RMAN Redo Traffic mit Data Guard SQLNET Redo Logs Standby Backups 98

97 OLTP Tabellen Kompression Block-Level Batch Komprimierung leerer Block initial unkomprimierter Block komprimierter Block teilweise komprimierter Block komprimierter Block Legende Header Daten Freier Platz unkomprimierte Daten komprimierte Daten 99

98 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 CREATE TABLE sales_history( ) COMPRESS FOR BASIC OLTP Im Enterprise Manager 100

99 Hybrid Columnar Compression (HCC) Neue Kombination der Anordnung nach Spalten und Zeilen höhere Compression Ratio möglich Verschiedene Level der Verdichtung möglich Designed für Daten, die nicht häufig verändert werden Komprimierung nur während Bulk Loads! Verfügbar für Storage wie Exadata, ZFS oder Pillar Logical Compression Unit (CU) BLOCK HEADER CU HEADER BLOCK HEADER BLOCK HEADER BLOCK HEADER C1 C2 C3 C4 C5 C5 C6 C7 C8

100 Compression Advisor Welchen Komprimierungsfaktor kann ich erwarten? Einsatz des Package DBMS_COMPRESSION ab 11gR2 Ohne zusätzliche Installation Unterstützt partitionierte/nicht partitionierte Tabellen Funktionen: Erstellt temporäre Objekte um Komprimierungsratio zu berechnen Analysiert Zeilen auf Komprimierungstyp Einsatz auch für HCC Komprimierung

101 Syntaxänderung in 12c Änderungen für Basic, OLTP und HCC Compression BASIC CREATE TABLE sales_history( ) ROW STORE COMPRESS BASIC; OLTP CREATE TABLE sales_history( ) ROW STORE COMPRESS ADVANCED; Beispiel für HCC CREATE TABLE sales_history( ) COLUMN STORE COMPRESS FOR QUERY HIGH;

102 Erweiterungen in 12c Aufhebung des 255 Spalten Limits DBMS_COMPRESSION Advisor jetzt auch für Securefile LOBs begin DBMS_COMPRESSION.GET_COMPRESSION_RATIO ( SCRATCHTBSNAME => 'USERS', TABOWNER => 'SH', TABNAME => 'BASIC_LOB', LOBNAME => 'TEXT', PARTNAME => '', COMPTYPE => 128,

103 Online Operationen in 12c Online Operationen für MOVE PARTITION Weniger Sperren Grundlage für ILM Operationen Beispiele SQL> ALTER TABLE sales_big MOVE PARTITION sales_q4_2001 ROW STORE COMPRESS ADVANCED ONLINE; SQL> ALTER TABLE sales_big MOVE PARTITION sales_q4_2001 TABLESPACE example ONLINE;

104 Zusammenfassung Anwendung der Komprimierung Bei Tabellen mit grösstem Speicherplatzverbrauch Speicherplatzeinsparung immer abhängig von den Daten und dem Ladevorgang Komprimierungsratio (Quotient aus unkomprimierten und komprimierten Daten) variiert Bessere Ratio durch: Verwendung von größeren DB Blöcken Erhöhung der Daten-Redundanz z.b. durch Laden von sortierten Daten Daten werden erst in der SGA beim Zugriff entpackt -> Bessere Ausnutzung von I/O

105 Query-Optimizer und System-Statistiken im Data Warehouse

106 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'); DBMS_STATS.GATHER_INDEX_STATS(Ownname=><OWNER>,Indexname=><TABLE_NAME>); 108

107 Sammeln von Statistiken Tabellen -> GATHER_TABLE_STATS EXEC DBMS_STATS.GATHER_TABLE_STATS ( 'PART','BESTELLUNG_PART_RANGE', estimate_percent=>100); Indexe -> GATHER_INDEX_STATS Schema -> GATHER_SCHEMA_STATS Automatisiertes Sammeln für ein Schema 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);

108 Sammeln von Column-bezogenen Statistiken (Histogramme) Sinnvoll bei komplexen where-bedingungen und starker Ungleich- Verteilung der Werte innerhalb einer Spalte begin DBMS_STATS.GATHER_TABLE_STATS(Ownname=>'DWH', Tabname=>'F_UMSATZ', METHOD_OPT => 'FOR COLUMNS SIZE AUTO KUNDEN_ID,ARTIKEL_ID,ZEIT_ID, REGION_ID, KANAL_ID ); end; begin DBMS_STATS.GATHER_TABLE_STATS(Ownname=>'DWH', Tabname=>'F_UMSATZ', METHOD_OPT => 'FOR COLUMNS SIZE 20 KUNDEN_ID,ARTIKEL_ID,ZEIT_ID, REGION_ID ); end;

109 Abfrage der Art Histogramme HEIGHT BALANCED: Aufteilung aller Werte in n-gruppen Hier kann der Grenzwert der jeweiligen Gruppen abgefragt werden FREQUENCY: Auflistung der Menge pro vorkommenden Wert SELECT column_name, num_distinct, num_buckets, histogram FROM user_tab_col_statistics WHERE table_name = 'F_UMSATZ'; COLUMN_NAME NUM_DISTINCT NUM_BUCKETS HISTOGRAM ARTIKEL_ID HEIGHT BALANCED KUNDEN_ID HEIGHT BALANCED ZEIT_ID HEIGHT BALANCED REGION_ID HEIGHT BALANCED KANAL_ID 7 7 FREQUENCY

110 Warum Histogramme? Histogramme sinnvoll Wenn Spalten ungleichmäßig verteilte Werte haben und in der WHERE-Klausel von Abfragen vorkommen Spalten die seltener abgefragt werden, und daher keine Indexe haben Histogramme nicht anlegen bei Gleich verteilten Spaltenwerten Nicht für alle Spalten einer Tabelle zu viel Overhead PKs oder indizierten Spalten Spalten, die nicht abgefragt werden

111 Dynamic Sampling Zusätzliche Hilfen für den Optimizer Werte von 1 10 (Default 2) Setting alter system set optimizer_dynamic_sampling=4; Manuelles Setzen ist sinnvoll wenn SQL seriell System wählt automatisch den Einstellwert bei Parallelisierung Testen Sinnvoll bei komplexen WHERE-Klauseln

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

113 Anwendung im DWH bei partitionierten Tabellen Partition Tag 1 Globale Statistiken regelmäßig sammeln Partition Tag 2 Z.B. einmal im Monat ETL Partition Tag 3 Partition Tag 4 Partition Tag 5 Partition Tag 7 Partition Tag 8 Partition Tag 9 Partition Tag 10 Partition Tag n Globale tatistiken Neu hinzugefügte Partiton verfälscht Statistiken 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 '); 115

114 Empfehlungen Dynamic Sampling auf einen höheren Wert setzen (z. B. 4) Bei großen partitionierten Tabellen mit Inkrementellem Statistik-Sammeln arbeiten. Histogramme gezielt für Spalten mit ungleich verteilten Werten verwenden, wenn sie oft abgefragt werden. Große Tabellen in dem Kontext des ETL-Prozesses aktualisieren -> ETL-Gesamt-Konzept

115 Speicher-Hierarchie Beispiel Flash

116 Datennutzung und Speicherhierarchieen Memory 60% aller Abfragen Flash Technology 35% aller Abfragen SAS drives < 10% aller Daten SATA drives < 50% aller Daten mal schneller mal schneller 5% aller Abfragen Off-line Data Archives 100% aller Daten

117 Flash Cache Transparente Erweiterung des Buffer Caches Hot Data 16 GB SGA Memory 120 GB Flash Cache Warm Data Extended Buffer Cache Install Flash Drive in the Host Server Set two init.ora parameters: db_flash_cache_file = <filename> Specifies the path to the flash disk db_flash_cache_size=<size> Specifies the amount of flash disk to use Cold Data 360 GB Magnetic Disks Flash Disks oder Cards in den Server-Maschinen SSD wirken als Level 2 Cache (SGA ist Level 1) 119

118 Hausgemachte Engpässe und Lösungen Hauptspeicher / RAM Internal Bus Internal Bus CPUs Sinnvolle Positionierung von Flash-Speicher Direkt adressierbar durch Server-CPUs Für die Datenbank sichtbar Dynamischer Flash-Index Flash-Speicher Public-SAN Controller Controller Controller Controller Physikalische Grenzen Drehgeschwindigkeit von Platten Anzahl Platten pro Controller Distanz und Remote-Netz-Topologie SSD SSD SSD Disk-Arrays SSD 120

119 Automatische Verwaltung von Daten im Data Warehouse (Heat Map)

120 Heat Map Datenzugriff tracken Active Frequent Access Occasional Access Dormant HOT Actively updated Infrequently updated, Frequently Queried Infrequent access for query and updates Long term analytics & compliance COLD Ebenen Auf Segment Ebene Welche Tabellen und Partitionen werden verwendet? Auf Block Ebene Welche Veränderung auf Block Ebene liegen vor? Umfassend Verfolgung von Lese- und Schreib - Operationen Unterscheidet zwischen Lookups und Full Table Scans Schließt Operationen wie Statistiksammeln, DDLs oder Tabellen Redefinition aus Performant 122

121 Heat Map Enterprise Manager 124

122 Heat Map für Tabellen und Partitionen Segment Level Tracking ORDER S Welche Tabellen und Partitionen werden wie verwendet? Aktueller Ausschnitt aus DBA_HEAT_MAP_SEG_HISTOGRAM OWNER OBJECT_NAME TRACK_TIME WRI FUL LOO SH CUSTOMERS_PK :48 NO NO YES SCOTT DEPT :48 NO YES NO SCOTT EMP :30 YES YES NO SCOTT EMP :48 NO YES NO SCOTT EMP :47 NO YES NO SCOTT PK_EMP :30 NO NO YES SCOTT PK_EMP :48 NO NO YES 126

123 Heat Map für Blöcke Row Level Tracking ORDER S Letzte Änderung auf Block Ebene Beispiel: Letzte Änderung an Tabelle CUSTOMERS mit DBMS_HEAT_MAP TABLESPACE FNO BLOCK_ID WRITETIME USERS :45 USERS :45 USERS :45 USERS :45 USERS :45 127

124 Heat Map Einschalten über Initialisierungsparameter HEAT_MAP SQL> ALTER SYSTEM SET heat_map = 'ON' 'OFF'; SQL> ALTER SESSION SET heat_map = 'ON' 'OFF'; Voraussetzung für Automatische Daten Optimierung Administration und Monitoring über V$Views Data Dictionary Views Packages Graphische Implementierung im Enterprise Manager 128

125 Heat Map für Daten Komprimierung Weniger Speicherplatz und Vorteile durch Komprimierung Hot Data X Advanced Row Compression Warm Data X Columnar Query Compression Archive Data X Columnar Archive Compression 129

126 Zeilenkomprimierung auf Basis der Nutzung Background Row Compression ORDER S ALTER TABLE EMPLOYEE ILM ADD POLICY ROW STORE COMPRESS ADVANCED ROW AFTER 1 DAY OF NO MODIFICATION 131

127 Automatic Data Optimization Storage-Tiering how it works SQL> ALTER TABLE employee ILM ADD POLICY TIER TO LOW_COST_TABLESPACE 1. Tables grow in size ILM policies compress data 2. Tablespace containing partitions reaches ILM tiering threshold 3. Partitions are moved to different tablespace on lower spec disk group 134

128 Automatische Daten Optimierung OLTP Reporting Compliance & Reporting 10x komprimiert 15x komprimiert Automatische ONLINE Konvertierung Im Quartal Im Jahr Jahre zuvor Advanced Row Compression für OLTP Columnar Query Compression für schnelle Analysen Columnar Archive Compression für max. Kompression 135

129 Backup & Recovery OLTP Reporting Compliance & Reporting 10x compressed 15x compressed Online Move zu READ ONLY Tablespace => Einmaliges Backup erforderlich Read / Write Tablespace Read-mostly Daten verlagert zu READONLY Tablespace READONLY TBS 136

130 Parallelisierung 138

131 Parallele Ausführung Ressourcen Parallel Execution Query Coordinator (QC) Parallel Execution Server Pool (PS) Messages Einteilung der Arbeitsmenge in kleinere Einheiten (Granules) Partitionen von Tabellen oder Indizes können diese Granules bilden Erfahrungswerte: Datenobjekte < 200 MB sollten keine Parallelisierung nutzen Objekte < 200 MB > 5 GB = Parallelisierungsgrad (DOP) 4 Objekte > 5 GB = DOP 32 Angaben variieren nach Systemauslastung und Hardware Konfiguration 139

132 SQL Parallel Execution Plan SELECT c.cust_name, s.purchase_date, s.amount FROM sales s, customers c WHERE s.cust_id = c.cust_id; Query Coordinator ID Operation Name TQ IN-OUT PQ Distribution 0 SELECT STATEMENT 1 PX COORDINATOR 2 PX SEND QC {RANDOM} Q1,01 P->S 3 HASH JOIN Q1,01 PCWP 4 PX RECEIVE Q1,01 PCWP 5 PX SEND BROADCAST Q1,01 P->P BROADCAST 6 PX BLOCK ITERATOR Q1,01 PCWP 7 TABLE ACCESS FULL CUSTOMERS Q1,01 PCWP 8 PX BLOCK ITERATOR Q1,01 PCWP 9 TABLE ACCESS FULL SALES Q1,01 PCWP Parallel Server leisten die Hauptarbeit 140

133 Execution Plan Partition Hash All über dem Join & Einfaches PQ Set bezeichnet Partition-wise Join ID Operation Name Pstart Pstop TQ PQ Distrib 0 SELECT STATEMENT 1 PX COORDINATOR 2 PX SEND QC (RANDOM) :TQ10001 Q1,01 QC (RAND) 3 SORT GROUP BY Q1,01 4 PX RECEIVE Q1,01 5 PX SEND HASH :TQ10000 Q1,00 HASH 6 SORT GROUP BY Q1,00 7 PX PARTITION HASH ALL Q1,00 8 HASH JOIN Q1,00 9 TABLE ACCESS FULL Customers Q1,00 10 TABLE ACCESS FULL Sales Q1,00 141

134 Parallelisierung und Skalierung Parallelisierbare Operationen Abfragen SELECT Join Operationen Sort Operationen GROUP BY DDL CREATE TABLE/MV CREATE INDEX Online Index Rebuild DML INSERT UPDATE / DELETE MOVE / SPLIT PARTITION serial 100% parallel SQL SQL 50% 100% 50% CPU CPU I/O I/O Ein SQL Statement wird vom Optimizer in kleinere Arbeitsschritte aufgeteilt und läuft skalierbar ab 142

135 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 143

136 Funktionen für Parallelisierung Automated Degree of Parallelism (DOP) Anpassung über Schwellwert und Systemressourcen Parallel Statement Queuing Zwingend parallel auszuführende Statements werden geparkt Bei genügend freien Ressourcen wird das Statement automatisch aufgeweckt und parallel ausgeführt In-Memory Parallel Execution = weniger Disk I/O Im RAC werden Daten aus den Buffer Caches genutzt Optimale Systemauslastung Mehr Parallelisierung, weniger Aufwand = Performance 144

137 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; SI : DOP = RAC: DOP = PARALLEL_THREADS_PER_CPU x CPU_COUNT PARALLEL_THREADS_PER_CPU x CPU_COUNT x INSTANCE_COUNT 145

138 Parallel Degree Policy Ausführungsplan Plan hash value: Id Operation Name Rows Bytes Cost (%CPU) Time SELECT STATEMENT (9) 00:00:03 1 VIEW (9) 00:00:03 2 WINDOW SORT (9) 00:00:03 3 HASH GROUP BY (9) 00:00:03 * 4 HASH JOIN 51M 1367M (2) 00:00:03 5 TABLE ACCESS FULL D_ARTIKEL (0) 00:00:01 6 TABLE ACCESS FULL F_UMSATZ 51M 341M (2) 00:00: Predicate Information (identified by operation id): access("u"."artikel_id"="a"."artikel_id") Note automatic DOP: Computed Degree of Parallelism is 1 Note automatic DOP: skipped because of IO calibrate statistics are missing 146

139 Automatischer Parallelisierungsgrad Bisher erfolgt das Tunen der Parallelisierung manuell Nur einen DOP zu haben ist nicht für alle Queries geeignet Zuviel Parallelisierung kann das System überlasten Automated Degree of Parallelism entscheidet automatisch, Ob ein Statement parallel ausgeführt wird oder nicht Welchen DOP das Statement nutzt Der Optimizer leitet den passenden DOP von den nötigen Ressourcen des Statements ab Kosten aller Scan-Operationen Maximales Limit der Parallelisierung wird berücksichtigt 147

140 Automatischer Parallelisierungsgrad Wie funktioniert das? SQL Statement Statement wird geparsed Optimizer ermittelt den Execution Plan Geschätzte Ausführung dauert länger als Schwellwert Optimizer bestimmt den idealen DOP PARALLEL_MIN_TIME_THRESHOLD (default =10s) Geschätzte Ausführung dauert nicht länger als Schwellwert Statement wird seriell ausgeführt Tatsächlicher DOP = MIN(PARALLEL_DEGREE_LIMIT, idealer DOP) PARALLEL_DEGREE_LIMIT (default =CPU) Statement wird parallel ausgeführt 148

141 Parallel Statement Queuing Mit Automatic Degree of Parallelism können mehr Statements parallel arbeiten ABER: Potentielle Systemüberlastung Parallel Statement Queuing entscheidet automatisch, ob ein Statement sofort ausgeführt werden kann oder nicht Sobald ein paralleles Statement startet wird geprfüt, ob genügend Parallel Server (Parallel Query Slaves) vorhanden sind Wenn nicht, wird das Statement in die Queue geschoben Sobald genügend Parallel Server verfügbar sind, wird das Statement aus der Queue geholt und ausgeführt 149

142 Parallel Statement Queuing Wie funktioniert das? SQL Statements Statement wird geparsed Oracle ermittelt automatisch den DOP Wenn zu wenig Parallel Server vorhanden sind, landet das Wenn genügend Parallel Server vorhanden sind, wird das Statement sofort ausgeführt FIFO Queue Wenn wieder genügend Parallel Server vorhanden sind, wird erste Statement aus der Queue geholt und ausgeführt

143 In-Memory Parallel Execution Data Warehouse-Umgebungen haben große Hauptspeicher, die nicht immer genutzt werden Ein Algorithmus plaziert Objektfragmente (Partitionen) in den Hauptspeicher der verschiedenen Knoten Mehr Daten im Hauptspeicher bei Einsatz von Kompression Parallel Servers (PQ Slaves) arbeiten auf den jeweiligen Knoten Automatic Degree of Parallelism erforderlich 151

144 In-Memory Parallel Execution SQL Statement Die Größe der angeforderten Tabelle wird bestimmt Die Tabelle eignet sich für In- Memory Parallel Execution Fragmente der Tabelle werden in den Buffer Cache jedes einzelnen Knotens gelesen Tabelle ist sehr klein Tabelle ist sehr groß In den Buffer Cache irgendeines Knotens lesen Immer direkt von Disk lesen Nur Parallel Server auf demselben RAC-Knoten werden auf die einzelnen Fragemente zugreifen 152

145 Parameter für Parallel Query Oracle DB 11.2 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 = 2148 ( ) 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) 153

146 Parameter für Parallel Query Oracle DB 11.2 Parameter parallel_degree_limit = 'CPU' (CPU IO integer) parallel_degree_policy = MANUAL (MANUAL LIMITED AUTO ADAPTIVE) parallel_force_local = FALSE (FALSE TRUE) parallel_min_time_threshold = AUTO (AUTO integer) parallel_servers_target = 8 (0 - max_servers) parallel_adaptive_multi_user = TRUE (TRUE FALSE) parallel_execution_message_size = 2148 ( ) 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) 154

147 Query Result Cache 155

148 Konzept und Einsatz des Result Cache Eigener Cache im Shared Pool Keine Installation notwendig Automatischer Refresh bei Datenänderungen Einfaches Setup und Monitoring der Cache-Nutzung Der Query Result Cache ist anwendbar für SQL-Abfragen PL/SQL-Funktionen 156

149 Implementierung und Nutzung Anwendung steuerbar über Initialisierungsparameter RESULT_CACHE_MODE Falls RESULT_CACHE_MODE=MANUAL gesetzt ist, dann einen Hint im Statement einfügen wie z.b. SELECT /*+ result_cache */ count(*) FROM sales Falls RESULT_CACHE_MODE=FORCE gesetzt ist, dann erfolgt ein automatisches Einfügen des Hints im Root-SELECT SELECT count(*) FROM sales

150 Parameter zum Result Cache RESULT_CACHE_MAX_RESULT 5 (%) RESULT_CACHE_MAX_SIZE RESULT_CACHE_MODE RESULT_CACHE_REMOTE_EXPIRATION abhängig vom OS MANUAL/FORCE 0 (min) RESULT_CACHE_MAX_SIZE: Gesamtgröße des reservierten Bereichs für den Result Cache im Shared Pool RESULT_CACHE_MAX_RESULT: Prozentualer Anteil am gesamten Result Cache für die einzelnen Ergebnisse RESULT_CACHE_REMOTE_EXPIRATION: Zeitdauer bei Remote Objekt-Nutzung, wie lange das Resultat in Minuten im Cache verbleibt 158

151 Beispiel mit Hints SQL> SELECT /*+ result_cache */ COUNT(*), SUM(salary) FROM hr.bigemp group by department_id ORDER BY department_id; Id Operation Name Rows Bytes Cost (%CPU) Time SELECT STATEMENT (2) 00:00:34 1 RESULT CACHE 91myw5c1bud0mcn64g3d0ykdhm 2 SORT GROUP BY (2) 00:00:34 3 TABLE ACCESS FULL BIGEMP 876K 4280K 2201 (1) 00:00:34 Statistics recursive calls 0 db block gets 0 consistent gets 0 physical reads 0 redo size 696 bytes sent via SQL*Net to client 419 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 12 rows processed 159

152 V$RESULT_CACHE_OBJECTS SQL> SELECT name, type, row_count, invalidations, scan_count FROM v$result_cache_objects; NAME TYPE ROW_COUNT INVALIDATIONS SCAN_COUNT HR.GET_DATUM Dependency SCOTT.EMP Dependency HR.BIGEMP Dependency "HR"."GET_DATUM"::8. Result "GET_DATUM"#27dda668 fe0cf492 #1 SELECT /*+ result_ca Result che */ COUNT(*), SUM(salary) FROM hr.bigemp group by department_id OR DER BY department 160

153 Materialized Views und Kennzahlenkonzepte 161

154 Prinzip und Aufgabenstellung - Summentabellen Basistabelle Summentabelle Complete Refresh Incremental Refresh? Änderungen stale 162

155 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 163

156 MAV-Erstellung und erstmaliges Füllen Parameter des create Befehles I/II: 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) 164

157 Refresh-Funktionen Parameter des create Befehles II/II: Refresh wie: COMPLETE 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 Refresh wann : ON COMMIT (oft bei OLTP) Commit einer Transaktion auf der Basistabelle ON DEMAND (sinnvoll im DWH, default) 165

158 Star Schema zum Testen D_ZEIT DATUM_DESC TAG_DES_MONATS WOCHE_DES_JAHRES JAHR_NUMMER QUARTALS_NUMMER MONATS_NUMMER MONAT_DESC DATUM_ID D_REGION REGION_ID ORT_ID ORT_NAME KREIS_ID KREIS_NUMMER KREIS_NAME LAND_NAME LAND_ID LAND_NUMMER REGION_NAME REGION_NUMMER F_UMSATZ ARTIKEL_ID ZEIT_ID KUNDE_ID REGION_ID UMSATZ MENGE BESTELL_DATUM STATUS D_ARTIKEL SPARTE_NAME SPARTE_NR GRUPPE_NAME GRUPPE_NR ARTIKEL_NAME ARTIKEL_ID D_KUNDE KUNDEN_ID VORNAME NACHNAME GEBDAT BRANCHE WOHNART KUNDENART BILDUNG EINKOMMENSGRUPPE ORTNR BERUFSGRUPPE BERUFSGRUPPEN_NR BILDUNGS_NR EINKOMMENS_NR WOHNART_NR PLZ ORT 166

159 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; 167

160 Data Dictionary Views für MAVs Weitreichende Informationen über Zustand der MAVs und ihrer dazugehörigen Basistabellen ALL_MVIEWS DBA_MVIEWS USER_MVIEWS USER_MVIEW_DETAIL_RELATIONS USER_MVIEW_DETAIL_SUBPARTITION Mit 11g wurde der Detailgrad in diesen Views erhöht, vor allem bei partitionierten Tabellen (Staleness etc.) 168

161 Testen und Ablaufbedingungen für 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;

162 Automatische Aktualisierung von Materialized Views 170

163 Basis- Tabellen Aufeinander Aufbauende M-Views DBMS_MVIEW (Refresh-Funktion) Umsatz Prod. Gr und Jahr SUM/Jahr U Prod.A U Prod B SUM/Monat JOIN D_Zeit FAKT D_PROD Refresh-Funktionen DBMS_MVIEW.REFRESH() DBMS_MVIEW.REFRESH_DEPENDENT() DBMS_MVIEW.REFRESH_ALL_MVIEW() Refresh-Methoden (optional) COMPLETE (C) FAST (F) FORCE (default) (?) PARTITIONED (P) Transaktionsverhalten (optional) ATOMIC_REFRESH REFRESH_AFTER_ERRORS NESTED Bsp.: EXECUTE DBMS_MVIEW.REFRESH('MV_STANDARD,'C');

164 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); 172

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

166 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 WITH ROWID, SEQUENCE (datum_id, datum_desc, tag_des_monats, tag_des_jahres, woche_des_jahres, monats_nummer, monat_desc, quartals_nummer, jahr_nummer) INCLUDING NEW VALUES; --- MAV Log auf Tabelle F_Umsatz DROP MATERIALIZED VIEW LOG ON f_umsatz; CREATE MATERIALIZED VIEW LOG ON f_umsatz WITH ROWID, SEQUENCE (umsatz, menge, umsatz_nach_rabatt, rabatt_wert_firmenkunde, Rabatt_wert_privatkunde, bestell_datum, artikel_id, kunde_id, region_id, zeit_id) INCLUDING NEW VALUES; 174

167 Fast Refresh mit MAV Log CREATE MATERIALIZED VIEW MV_Standard_Fast_Refresh BUILD IMMEDIATE REFRESH FAST 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; SQL> SELECT mview_name, update_log, stale_since, staleness 2 FROM user_mviews where mview_name = 'MV_STANDARD_FAST_REFRESH'; MVIEW_NAME UPDATE_LOG STALE_SI STALENESS MV_STANDARD_FAST_REFRESH FRESH 175

168 PCT Refresh mit Partition Key Der Partitioning Key der Basistabelle ist in dem SELECT- und eventuell in dem GROUP BY-Teil, aber nicht in der WHERE-Klausel der MAV enthalten Führt zur Aggregierung auf der Ebene des Partitioning Keys Höhere Datenmenge als ohne PCT SQL> SELECT count(*) 2 FROM MV_Standard_PCT_Richtig; COUNT(*) CREATE MATERIALIZED VIEW MV_Standard_PCT_Richtig AS SELECT u.bestell_datum, z.jahr_nummer Jahr, z.monat_desc Monat, sum(u.umsatz) Summe, a.artikel_id ID, count(u.umsatz) FROM f_umsatz_par u, d_artikel a, d_zeit z WHERE a.artikel_id = u.artikel_id AND u.zeit_id = z.datum_id GROUP BY u.bestell_datum, z.jahr_nummer, z.monat_desc, a.artikel_id; 176

169 PCT Refresh Join Dependency Expression Partitioning Key kommt in der Join Condition vor und eine Spalte der Basistabelle im SELECT-Teil der MAV CREATE MATERIALIZED VIEW MV_Standard_PCT_Falsch AS SELECT z.jahr_nummer Jahr, z.monat_desc Monat, sum(u.umsatz) Summe, a.artikel_id ID, count(u.umsatz) FROM f_umsatz_par 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; CREATE MATERIALIZED VIEW MV_Standard_PCT_Richtig AS SELECT z.jahr_nummer Jahr, z.monat_desc Monat, sum(u.umsatz) Summe, a.artikel_id ID, count(u.umsatz) FROM f_umsatz_par u, d_artikel a, d_zeit z WHERE a.artikel_id = u.artikel_id and u.bestell_datum = z.datum_desc GROUP BY z.jahr_nummer, z.monat_desc, a.artikel_id; 177

170 PCT Refresh mit Partition Marker Die Partitionmarker-Funktion liefert pro Partition einen Wert, der beliebige Level für die Aggregationen in der MAV erlaubt SQL> SELECT count(*) FROM MV_Standard_PCT_Par_MARKER; COUNT(*) CREATE MATERIALIZED VIEW MV_Standard_PCT_Par_MARKER AS SELECT dbms_mview.pmarker(u.rowid) AS pmark, z.jahr_nummer Jahr, z.monat_desc Monat, sum(u.umsatz) Summe, a.artikel_id ID, count(u.umsatz) FROM f_umsatz_par u, d_artikel a, d_zeit z WHERE a.artikel_id = u.artikel_id and u.bestell_datum = z.datum_desc GROUP BY z.jahr_nummer,z.monat_desc,a.artikel_id, dbms_mview.pmarker(u.rowid) ; 178

171 PCT Refresh und MAV Log Refresh Fast Refresh über MAV Logs funktioniert nicht, wenn Partitionen hinzukommen oder gelöscht werden Für bestimmte MAVs funktioniert das Log-Verfahren nicht, z.b. Verwendung der RANK-Funktion PCT Refresh ist schneller, wenn viele Änderungen pro Partition gemacht wurden PCT Refresh lässt sich parallelisieren MAVs können bei PCT trotz Staleness mancher Partitionen für Query Rewrite genutzt werden 179

172 Refresh Performance Tipps Optimizer-Statistiken immer aktuell halten Nach jedem Laden aktualisieren DBMS_STATS auch über MAVs laufen lassen ATOMIC_REFRESH auf FALSE setzen PCT nutzen, wo es geht Auch die MAV kann partitioniert werden (bringt zusätzliche Performance beim Refresh) Parallele Ausführung verwenden Mit REFRESH_ALL arbeiten DB organisiert sich die Abarbeitung selbst und parallelisiert automatisch bei Bedarf Berücksichtigt auch Abhängigkeiten zwischen einzelnen MAVs 180

173 Nutzenpotenziale durch MAV heben Wartbarkeit und Wiederverwendbarkeit Konzept erstellen als Grundlage für MAVs Komplexität reduzierne der einzelnen SQL Keine MAV für einzelne Abfrage Einfache Pflege Aufeinander aufbauende MAV Einsatz der Automatismen prüfen (refresh) Verwendung der MAV mit System Views prüfen Performance im ETL Trennung von unterschiedlichen Aufgaben (Join, Aggregation) Abhängige Elemente nutzen Effiziente Nutzung Unterstützende Elemente nutzen (Dimensionen) Partitionierung prüfen 181

174 Konzepte rund um Materialized Views 182

175 Prinzip: Nested Materialized Views Umsatz aggregiert auf Jahreslevel Umsatz aggregiert auf Monatslevel sum / count D_ZEIT DATUM_DESC TAG_DES_MONATS WOCHE_DES_JAHRES JAHR_NUMMER QUARTALS_NUMMER MONATS_NUMMER MONAT_DESC DATUM_ID F_UMSATZ ARTIKEL_ID ZEIT_ID KUNDE_ID REGION_ID UMSATZ MENGE BESTELL_DATUM D_ARTIKEL SPARTE_NAME SPARTE_NR GRUPPE_NAME GRUPPE_NR ARTIKEL_NAME ARTIKEL_ID 183

176 Prinzip: Nested Materialized Views CREATE MATERIALIZED VIEW MV_Umsatz_Monat 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; CREATE MATERIALIZED VIEW MV_Umsatz_Jahr ENABLE QUERY REWRITE AS SELECT Jahr, sum(summe) Summe, ID artikel_id, count(summe) FROM MV_Umsatz_Monat GROUP BY jahr,id; 184

177 Vorteil: Minimierung von Komplexität Liefere die Artikel mit dem größten Umsatz im November 2006 CREATE MATERIALIZED VIEW MV_Umsatz_Komplex ENABLE QUERY REWRITE AS SELECT a.artikel_name, sum(u.umsatz) FROM f_umsatz u, d_artikel a WHERE a.artikel_id = u.artikel_id GROUP BY a.artikel_name HAVING sum(u.umsatz) --> kein Fast Refresh möglich IN (SELECT max(u.umsatz) FROM f_umsatz u, d_zeit z WHERE u.zeit_id = z.datum_id AND z.monat_desc = 'November' AND z.jahr_nummer = '2006' GROUP BY u.artikel_id); 185

178 Vorteil: Minimierung von Komplexität Minimierung von Komplexität Liefere die Artikel mit dem größten Umsatz im November 2006 CREATE MATERIALIZED VIEW MV_Umsatz_KOMBINATION REFRESH COMPLETE ENABLE QUERY REWRITE AS SELECT artikel, umsatz_summe FROM MV_Umsatz_Komplex_SUB1 WHERE umsatz_summe IN (SELECT umsatz_max FROM MV_Umsatz_Komplex_SUB2); CREATE MATERIALIZED VIEW MV_Umsatz_Komplex_SUB1 ENABLE QUERY REWRITE AS SELECT a.artikel_name Artikel, sum(u.umsatz)umsatz_summe, count(u.umsatz), count(*) FROM f_umsatz u, d_artikel a WHERE a.artikel_id = u.artikel_id GROUP BY a.artikel_name; CREATE MATERIALIZED VIEW MV_Umsatz_Komplex_SUB2 ENABLE QUERY REWRITE AS SELECT u.artikel_id, max(u.umsatz) umsatz_max FROM f_umsatz u, d_zeit z WHERE u.zeit_id = z.datum_id AND z.monat_desc = 'November' AND z.jahr_nummer = '2006' GROUP BY u.artikel_id; 186

179 Kennzahlen standardisieren Umsatz Prod. Gr B relativ zum Gesamtjahresumsatz Materialized View Level 4 Summierung/Jahr Materialized View Level 3 Umsatz Prod.Gr A Umsatz Prod.Gr B Summierung/Monat Materialized View Level 2 Aufwändige Join-Operation Materialized View Level 1 DIM_Zeit FAKT_Umsatz DIM_Produkte Basistabellen 187

180 Kennzahlen standardisieren Kennzahlen nur als Materialized Views Automatisches Refresh anstatt ETL Standardisierte und stimmige Kennzahlen Wiederverwenden von bereits aggregierten Daten User View Layer L1 L2 L3 L4

181 Beispiel Level 4 Mv_EA_Finanz_Kum_Gruppe_Monat Produktgruppen-Sicht Finanz-Sicht / Berechnungen Jahres-Sicht Level 3 Mv_EA_Finanz_Kum_Monat LFD_Bestands_Wert / Produkt / Monat LFD_Saldo / Produkt / Monat Kumulierter EK / Produkt Kumulierter VK / Produkt Kumuliertes Saldo Mav_Einkauf_Verkauf_Diff_Jahr Level 2 Mv_EA_Menge_Kum_Monat Bestands-/Lager-Sicht / Berechnungen LFD_Bestands_Menge / Produkt / Monat VK_Menge / Produkt / Monat EK_Menge / Produkt / Monat Kumulierte EK Menge / Produkt Kumulierte VK Menge / Produkt Mav_Produkt_Monat_einkaeufe Level 1 Mav_Produkt_Monat_Verkaeufe F_EINKAEUFE F_POSITION F_KAUF EA: Einkauf/Verkauf Kum: kumuliert

182 BI-Tool Server + Caches Der Weg in die BI-Tools So viel wie möglich in der DB vorbereiten User View Layer So Millionen von Sätzen Verhindert unnötiges Kopieren Keine Verlagerung von Pseudo-ETL in die BI-Tools Standardisierte Kennzahlen User View Layer Oder so WenigeSätze

183 Konzept zur Verteilung von Materialized im Star Schema MAV_Region_Zeit_Artikel_Umsatz MAV_Region_Umsatz MAV_Region_Artikel_Umsatz D_REGION D_ZEIT F_UMSATZ D_ARTIKEL D_KUNDE MAV_Zeit_Umsatz MAV_Artikel_Umsatz MAV_Region_Zeit_Umsatz MAV_Kunde_Umsatz MAV_Kunde_Zeit_Umsatz 191

184 Zugriffspfade planen Sprechende Name Übersichtliche Darstellung 192 Ziele: Keine MAV für spezielle Abfrage von Herrn M Abfragestatistiken verwenden Nutzung überwachen (siehe Systemtabellen) Architektur auch für Pflege optimieren...

185 Automatisches Query Rewrite 193

186 Rewrite Prüfung Abarbeitungsreihenfolge Textvergleich der SELECT-Liste Reihenfolge spielt dabei keine Rolle Auflösung von möglichen Berechnungen Vergleich der Join-Bedingung Vergleich der GROUP BY-Klausel 194

187 Beispiel-MAV für die folgenden Abfragen CREATE MATERIALIZED VIEW MV_UMS_ART_Zeit REFRESH COMPLETE 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; D_ZEIT DATUM_DESC TAG_DES_MONATS WOCHE_DES_JAHRES JAHR_NUMMER QUARTALS_NUMMER MONATS_NUMMER MONAT_DESC DATUM_ID sum / count F_UMSATZ ARTIKEL_ID ZEIT_ID KUNDE_ID REGION_ID UMSATZ MENGE BESTELL_DATUM D_ARTIKEL SPARTE_NAME SPARTE_NR GRUPPE_NAME GRUPPE_NR ARTIKEL_NAME ARTIKEL_ID 195

188 Exaktes Text-Matching Umstellen der Spalten und avg() anstelle von sum() SELECT z.jahr_nummer Jahr, sum(u.umsatz)summe, a.artikel_id ID, z.monat_desc Monat 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; SELECT z.jahr_nummer Jahr, avg(u.umsatz) Schnitt, a.artikel_id ID, z.monat_desc Monat 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; 196 D_ZEIT DATUM_DESC TAG_DES_MONATS WOCHE_DES_JAHRES JAHR_NUMMER QUARTALS_NUMMER MONATS_NUMMER MONAT_DESC DATUM_ID sum / count F_UMSATZ ARTIKEL_ID ZEIT_ID KUNDE_ID REGION_ID UMSATZ MENGE BESTELL_DATUM D_ARTIKEL SPARTE_NAME SPARTE_NR GRUPPE_NAME GRUPPE_NR ARTIKEL_NAME ARTIKEL_ID

189 Prinzip Aggregate Rollup SELECT FROM z.jahr_nummer Jahr, --> Bezugsgröße in MAV ist Monat sum(u.umsatz) Summe, a.artikel_id ID, count(u.umsatz) 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, a.artikel_id; Abfragen lässt sich alles, was in der GROUP BY-Klausel der MAV zu finden ist 197 D_ZEIT DATUM_DESC TAG_DES_MONATS WOCHE_DES_JAHRES JAHR_NUMMER QUARTALS_NUMMER MONATS_NUMMER MONAT_DESC DATUM_ID sum / count F_UMSATZ ARTIKEL_ID ZEIT_ID KUNDE_ID REGION_ID UMSATZ MENGE BESTELL_DATUM D_ARTIKEL SPARTE_NAME SPARTE_NR GRUPPE_NAME GRUPPE_NR ARTIKEL_NAME ARTIKEL_ID

190 Join Back-Methode SELECT FROM z.jahr_nummer Jahr, z.monat_desc Monat, a.artikel_name Artikel, sum(u.umsatz) Summe 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_name; Join Back-Tabelle muss einen Primary Key nutzen Ist nicht in der MAV-Definition enthalten 198 D_ZEIT DATUM_DESC TAG_DES_MONATS WOCHE_DES_JAHRES JAHR_NUMMER QUARTALS_NUMMER MONATS_NUMMER MONAT_DESC DATUM_ID sum / count F_UMSATZ ARTIKEL_ID ZEIT_ID KUNDE_ID REGION_ID UMSATZ MENGE BESTELL_DATUM D_ARTIKEL SPARTE_NAME SPARTE_NR GRUPPE_NAME GRUPPE_NR ARTIKEL_NAME ARTIKEL_ID

191 Ausführungsplan Join Back-Methode Ohne Join Back Id Operation Name Rows Bytes Cost (%CPU) Time SELECT STATEMENT K 172 (5) 00:00:03 1 HASH GROUP BY K 172 (5) 00:00:03 * 2 HASH JOIN 100K 7031K 168 (3) 00:00:03 3 TABLE ACCESS FULL D_ZEIT (0) 00:00:01 * 4 HASH JOIN 100K 5273K 159 (2) 00:00:02 5 TABLE ACCESS FULL D_ARTIKEL (0) 00:00:01 6 TABLE ACCESS FULL F_UMSATZ 100K 976K 155 (2) 00:00: Mit Join Back Id Operation Name Rows Bytes Cost (%CPU) Time SELECT STATEMENT (14) 00:00:01 1 HASH GROUP BY (14) 00:00:01 * 2 HASH JOIN K 14 (8) 00:00:01 3 TABLE ACCESS FULL D_ARTIKEL (0) 00:00:01 4 MAT_VIEW REWRITE ACCESS FULL MV_UMS_ART_ZEIT K 10 (0) 00:00:

192 Einfache Join-Bedingungen in MAVs Grundlage für flexiblere Abfragen Einfache Join-Bedingung CREATE MATERIALIZED VIEW MV_UMS_ART_Zeit_Join REFRESH COMPLETE ENABLE QUERY REWRITE AS SELECT z.jahr_nummer Jahr, z.monat_desc Monat, a.artikel_id ID, u.umsatz 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; SELECT z.jahr_nummer Jahr, z.monat_desc Monat, sum(u.umsatz) Summe FROM f_umsatz u, d_artikel a, d_zeit z WHERE a.artikel_id = u.artikel_id AND u.zeit_id = z.datum_id AND z.jahr_nummer = '2007' GROUP BY z.jahr_nummer, z.monat_desc; 200

193 Materialized Views und Hierarchisierung von Dimensionen 201

194 Dimensionale Tabelle als Optimizer-Hilfe Abfragen über alle Spalten der Dimensionstabelle Eine Definition für Dimensionen festlegen CREATE TABLE d_artikel ( dimension_key NUMBER(3) NOT NULL, nummer NUMBER(8), artikel_name VARCHAR2(50), artikel_nummer NUMBER(3), gruppe_nr NUMBER(3), gruppe_name VARCHAR2(50), sparte_name VARCHAR2(50), sparte_nr NUMBER(3)); CREATE DIMENSION d_artikel LEVEL artikel IS d_artikel.artikel_id LEVEL gruppe IS d_artikel.gruppe_nr LEVEL sparte IS d_artikel.sparte_nr HIERARCHY h_art (artikel CHILD OF gruppe CHILD OF sparte) ATTRIBUTE att_artikel LEVEL artikel DETERMINES d_artikel.artikel_name ATTRIBUTE att_gruppe LEVEL gruppe DETERMINES d_artikel.gruppe_name ATTRIBUTE att_sparte LEVEL sparte DETERMINES d_artikel.sparte_name; 202 D_ZEIT DATUM_DESC TAG_DES_MONATS WOCHE_DES_JAHRES JAHR_NUMMER QUARTALS_NUMMER MONATS_NUMMER MONAT_DESC DATUM_ID sum / count F_UMSATZ ARTIKEL_ID ZEIT_ID KUNDE_ID REGION_ID UMSATZ MENGE BESTELL_DATUM D_ARTIKEL SPARTE_NAME SPARTE_NR GRUPPE_NAME GRUPPE_NR ARTIKEL_NAME ARTIKEL_ID

195 Dimensionale Tabelle als Optimizer-Hilfe Definition auf Artikelebene Abfrage auf Spartenebene CREATE MATERIALIZED VIEW MV_UMS_ART_Dim REFRESH COMPLETE ENABLE QUERY REWRITE AS SELECT a.artikel_id ID, sum(u.umsatz) Umsatz FROM f_umsatz u, d_artikel a WHERE a.artikel_id = u.artikel_id GROUP BY a.artikel_id; SELECT FROM WHERE GROUP BY a.sparte_name Sparte, sum(u.umsatz) Summe f_umsatz u, d_artikel a a.artikel_id = u.artikel_id a.sparte_name; 203 D_ZEIT DATUM_DESC TAG_DES_MONATS WOCHE_DES_JAHRES JAHR_NUMMER QUARTALS_NUMMER MONATS_NUMMER MONAT_DESC DATUM_ID sum / count F_UMSATZ ARTIKEL_ID ZEIT_ID KUNDE_ID REGION_ID UMSATZ MENGE BESTELL_DATUM D_ARTIKEL SPARTE_NAME SPARTE_NR GRUPPE_NAME GRUPPE_NR ARTIKEL_NAME ARTIKEL_ID

196 Dimensionale Tabelle als Optimizer-Hilfe Ohne Rewrite auf Basis einer dimensionalen Tabelle Id Operation Name Rows Bytes Cost (%CPU) Time SELECT STATEMENT (5) 00:00:02 1 HASH GROUP BY (5) 00:00:02 * 2 HASH JOIN 100K 2734K 158 (2) 00:00:02 3 TABLE ACCESS FULL D_ARTIKEL (0) 00:00:01 4 TABLE ACCESS FULL F_UMSATZ 100K 585K 154 (1) 00:00: Mit Rewrite auf Basis einer dimensionalen Tabelle Id Operation Name Rows Bytes Cost (%CPU) Time SELECT STATEMENT (29) 00:00:01 1 HASH GROUP BY (29) 00:00:01 2 MERGE JOIN (17) 00:00:01 3 TABLE ACCESS BY INDEX ROWID D_ARTIKEL (0) 00:00:01 4 INDEX FULL SCAN PK_ART_ID 65 1 (0) 00:00:01 * 5 SORT JOIN (25) 00:00:01 6 MAT_VIEW REWRITE ACCESS FULL MV_UMS_ART_DIM (0) 00:00:

197 Prüfen der Stimmigkeit einer Dimension HIERARCHY-Klausel ATTRIBUTE-Klausel 1 : n-beziehung 1 : n-beziehung SPARTE_NAME SPARTE_NR GRUPPE_NAME GRUPPE_NR ARTIKEL_NAME ARTIKEL_ID funktionale Abhängigkeit funktionale Abhängigkeit funktionale Abhängigkeit 205

198 Prüfen der Stimmigkeit einer Dimension \ora-home\rdbms\admin\utldim.sql SQL> desc dimension_exceptions Name STATEMENT_ID OWNER TABLE_NAME DIMENSION_NAME RELATIONSHIP BAD_ROWID Legt Tabelle DIMENSION_EXCEPTIONS an DBMS_OLAP.VALIDATE_DIMENSION -- Prüfen der Dimension mit: variable stmt_id varchar2(30); execute :stmt_id := 'CUST_DIM_VAL'; execute dbms_dimension.validate_dimension ('MAV.D_ARTIKEL',FALSE,TRUE,:stmt_id ); -- Fehlermeldungen abfragen mit: SELECT distinct owner, table_name, dimension_name, relationship FROM dimension_exceptions WHERE statement_id = :stmt_id; 206

199 Hilfsmittel bei der Verwaltung von Materialized Views 207

200 EXPLAIN_MVIEW Auswertung start D:\O11\db11\RDBMS\ADMIN\utlxmv.sql SQL> desc MV_CAPABILITIES_TABLE; Name Null? Typ STATEMENT_ID VARCHAR2(30) MVOWNER VARCHAR2(30) MVNAME VARCHAR2(30) CAPABILITY_NAME VARCHAR2(30) POSSIBLE CHAR(1) RELATED_TEXT VARCHAR2(2000) RELATED_NUM NUMBER MSGNO NUMBER(38) MSGTXT VARCHAR2(2000) SEQ NUMBER 208

201 EXPLAIN_MVIEW-Routine Zeigt auf, welche Funktionen für die jeweilige MAV genutzt werden kann EXECUTE dbms_mview.explain_mview(_ 'SELECT sum(u.umsatz),a.artikel_name _ FROM f_umsatz u, d_artikel a _ WHERE a.artikel_id = u.artikel_id _ GROUP BY a.artikel_name'); 209

202 EXPLAIN_MVIEW-Routine SELECT capability_name, possible p, substr(related_text,1,20) obj, substr(msgtxt,1,100) erklaerung FROM mv_capabilities_table; CAPABILITY_NAME P OBJ ERKLAERUNG PCT N REFRESH_COMPLETE Y REFRESH_FAST N REWRITE Y PCT_TABLE N F_UMSATZ Relation ist keine partitionierte Tabelle PCT_TABLE N D_ARTIKEL Relation ist keine partitionierte Tabelle REFRESH_FAST_AFTER_INSERT N MAV.F_UMSATZ Detail-Tabelle enthσlt kein Materialized View-Log REFRESH_FAST_AFTER_INSERT N MAV.D_ARTIKEL Detail-Tabelle enthσlt kein Materialized View-Log REFRESH_FAST_AFTER_ONETAB_DML N SUM(U.UMSATZ) SUM(expr) ohne COUNT(expr) REFRESH_FAST_AFTER_ONETAB_DML N Siehe Grund, warum REFRESH_FAST_AFTER_INSERT deaktiviert ist REFRESH_FAST_AFTER_ONETAB_DML N COUNT(*) ist in SELECT-Liste nicht vorhanden CAPABILITY_NAME P OBJ ERKLAERUNG REFRESH_FAST_AFTER_ONETAB_DML N SUM(expr) ohne COUNT(expr) REFRESH_FAST_AFTER_ANY_DML N Siehe Grund, warum REFRESH_FAST_AFTER_ONETAB_DML deaktiviert ist REFRESH_FAST_PCT N PCT bei keiner der Detail-Tabellen in der Materialized View m glich REWRITE_FULL_TEXT_MATCH Y REWRITE_PARTIAL_TEXT_MATCH Y REWRITE_GENERAL Y REWRITE_PCT N Allgemeines Neuschreiben nicht m glich oder PCT bei keiner der Detail-Tabellen m glich PCT_TABLE_REWRITE N F_UMSATZ Relation ist keine partitionierte Tabelle PCT_TABLE_REWRITE N D_ARTIKEL Relation ist keine partitionierte Tabelle 210

203 EXPLAIN_REWRITE-Routine Angabe der Bedingungen für Query SQL> desc rewrite_table Name Null? Typ STATEMENT_ID VARCHAR2(30) MV_OWNER VARCHAR2(30) MV_NAME VARCHAR2(30) SEQUENCE NUMBER(38) QUERY VARCHAR2(4000) QUERY_BLOCK_NO NUMBER(38) REWRITTEN_TXT VARCHAR2(4000) MESSAGE VARCHAR2(512) PASS VARCHAR2(3) MV_IN_MSG VARCHAR2(30) MEASURE_IN_MSG VARCHAR2(30) JOIN_BACK_TBL VARCHAR2(4000) JOIN_BACK_COL VARCHAR2(4000) ORIGINAL_COST NUMBER(38) REWRITTEN_COST NUMBER(38) FLAGS NUMBER(38) RESERVED1 NUMBER(38) RESERVED2 VARCHAR2(10) 211

204 MAV-Definition EXPLAIN_REWRITE-Routine CREATE MATERIALIZED VIEW MV_UMS_ART_Zeit_Join REFRESH COMPLETE ENABLE QUERY REWRITE AS SELECT z.jahr_nummer Jahr, z.monat_desc Monat, a.artikel_id ID, FROM f_umsatz u, d_artikel a, d_zeit z WHERE a.artikel_id = u.artikel_id AND u.zeit_id = z.datum_id; select mv_name, message from rewrite_table; MV_UMS_ART_ZEIT_JOIN QSM-01150: Abfrage wurde nicht umgeschrieben DBMS_MVIEW.EXPLAIN_REWRITE MV_UMS_ART_ZEIT_JOIN QSM-01082: Materialized View, MV_UMS_ART_ZEIT_JOIN, kann nicht mit Tabelle, F_UMSATZ, verknüpft werden begin dbms_mview.explain_rewrite(' SELECT z.jahr_nummer Jahr, z.monat_desc Monat, sum(u.umsatz) Summe, a.artikel_id ID 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', 'MV_UMS_ART_Zeit_Join'); end; MV_UMS_ART_ZEIT_JOIN QSM-01102: Materialized View, MV_UMS_ART_ZEIT_JOIN, erfordert Join zurück zu Tabelle, F_UMSATZ, in Spalte, UMSATZ 212

205 Analytische SQL-Funktionen 213

206 Analytische Funktionen Einsatz bei dem Aufbau von festen, bekannten Kennzahlen Ideal in dem Zusammenspiel mit Materialized Views Lösung könnte auch mit reinem SQL erfolgen aber Analytische Funktionen machen die Abfrage schlanker Sie sind in der Regel schneller, weil man Mehrfachlesen von Tabellen verhindert Sie liefern mehr Flexibilität weil mit Gruppierungen gezielter umgegangen werden kann

207 215 Beispiel Star Schema D_ZEIT DATUM_ID TAG_DES_MONATS TAG_DES_JAHRES WOCHE_DES_JAHRES MONATS_NUMMER MONAT_DESC QUARTALS_NUMMER JAHR_NUMMER ZEIT_ID PK D_REGION REGION_ID ORTNR ORT KREISNR KREIS LANDNR LAND REGIONNR REGION PK D_VERTRIEBSKANAL KANAL_ID PK VERTRIEBSKANAL KANALBESCHREIBUNG VERANTWORTLICH KLASSE F_UMSATZ D_ARTIKEL ARTIKEL_NAME GRUPPE_NR GRUPPE_NAME SPARTE_NAME SPARTE_NR ARTIKEL_ID ARTIKEL_ID FK KUNDEN_ID FK ZEIT_ID FK REGION_ID FK KANAL_ID FK UMSATZ MENGE UMSATZ_GESAMT PK PK: Btree Index FK: Bitmap Index D_KUNDE KUNDEN_ID PK 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

208 Gruppierungen auf unterschiedlichen Leveln Over Partition By Allgemeines Format Function(arg1,..., argn) OVER ( [PARTITION BY <...>] [ORDER BY <...>] [<window_clause>] ) Beispiel Beispiel: sum(wert) over (partition by Artikelgruppe) Gruppengesamtwert

209 Einfaches Beispiel Mit nur einer Tabelle select Artikelname, Artikelgruppe, Wert, sum(wert) over (partition by Artikelgruppe) Gruppengesamtwert from Artikel ; Beispieltabelle: create table Artikel ( Artikelname Artikelgruppe wert varchar2(10), varchar2(10), number); insert into Artikel values('schraube','beschlag',1); insert into Artikel values('winkel','beschlag',2); insert into Artikel values('mutter','beschlag',1); insert into Artikel values('kabel','elektro',6); insert into Artikel values('lampe','elektro',5); insert into Artikel values('klemme','elektro',2);... ARTIKELNAM ARTIKELGRU WERT GRUPPENGESAMTWERT Schraube Beschlag 2 12 Winkel Beschlag 2 12 Mutter Beschlag 1 12 Winkel Beschlag 2 12 Schraube Beschlag 1 12 Mutter Beschlag 1 12 Winkel Beschlag 2 12 Schraube Beschlag 1 12 Mutter Beschlag 1 12 Kabel Elektro 6 39 Kabel Elektro 6 39 Lampe Elektro 5 39 Klemme Elektro 2 39 Klemme Elektro 2 39 Lampe Elektro 5 39 Kabel Elektro 6 39 Lampe Elektro 5 39 Klemme Elektro 2 39

210 Abgrenzung gegenüber GROUP BY / Aggregationen Bei der GROUP BY Lösung müssen aller Felder in dem SELECT-Teil auch unter GROUP BY aufgelistet werden SQL> select sum(wert), artikelname, artikelgruppe from artikel group by artikelname; ERROR at line 1: ORA-00979: not a GROUP BY expression

211 Verhindern von Mehrfachlesen Mit analytischen Funktionen select Artikelname, Artikelgruppe, Wert, sum(wert) over (partition by Artikelname) Artikelgesamtwert, sum(wert) over (partition by Artikelgruppe) Gruppengesamtwert, round(((sum(wert) over (partition by Artikelname))/(sum(wert) over (partition by Artikelgruppe))*100),0) Prozent from Artikel ; Ohne analytische Funktionen select wert_art, art.artikelname, wert_gr, art.artikelgruppe, round((art.wert_art/gr.wert_gr*100),0) Prozent from (select sum(wert) wert_art, artikelname,artikelgruppe from artikel group by artikelname,artikelgruppe) art, (select sum(wert) wert_gr, ARTIKELGRUPPE from artikel group by ARTIKELGRUPPE) gr where art.artikelgruppe = gr.artikelgruppe

212 Ohne analytische Funktionen Mit analytischen Funktionen ARTIKELNAM ARTIKELGRU WERT ARTIKELGESAMTWERT GRUPPENGESAMTWERT PROZENT Kabel Elektro Kabel Elektro Kabel Elektro Klemme Elektro Klemme Elektro Klemme Elektro Lampe Elektro Lampe Elektro Lampe Elektro Mutter Beschlag Mutter Beschlag Mutter Beschlag Schraube Beschlag Schraube Beschlag Schraube Beschlag Winkel Beschlag Winkel Beschlag Winkel Beschlag ARTIKELNAM ARTIKELGRU WERT ARTIKELGESAMTWERT GRUPPENGESAMTWERT PROZENT Kabel Elektro Kabel Elektro Kabel Elektro Klemme Elektro Klemme Elektro Klemme Elektro Lampe Elektro Lampe Elektro Lampe Elektro Mutter Beschlag Mutter Beschlag Mutter Beschlag Schraube Beschlag Schraube Beschlag Schraube Beschlag Winkel Beschlag Winkel Beschlag Winkel Beschlag

213 Verhindern von Doppellesen Mit analytischen Funktionen Id Operation Name Rows Bytes Cost (%CPU) Time SELECT STATEMENT (40) 00:00:01 1 WINDOW SORT (40) 00:00:01 2 WINDOW SORT (40) 00:00:01 3 TABLE ACCESS FULL ARTIKEL (0) 00:00: Ohne analytische Funktionen Id Operation Name Rows Bytes Cost (%CPU) Time SELECT STATEMENT (34) 00:00:01 * 1 HASH JOIN (34) 00:00:01 2 VIEW (25) 00:00:01 3 HASH GROUP BY (25) 00:00:01 4 TABLE ACCESS FULL ARTIKEL (0) 00:00:01 5 VIEW (25) 00:00:01 6 HASH GROUP BY (25) 00:00:01 7 TABLE ACCESS FULL ARTIKEL (0) 00:00:

214 Beispiel Mit mehreren Tabellen D_ARTIKEL ARTIKEL_NAME GRUPPE_NR GRUPPE_NAME SPARTE_NAME SPARTE_NR ARTIKEL_ID PK F_UMSATZ ARTIKEL_ID FK KUNDEN_ID FK ZEIT_ID FK REGION_ID FK KANAL_ID FK UMSATZ MENGE UMSATZ_GESAMT Wieviel Prozent machen der Gesamtumsatzes pro Artikel an dem Gesamtumsatz der zugehörigen Gruppe aus? Gesamtumsatz Einzelartikel im Vergleich zu durchschnittlichem Artikelumsatz pro Gruppe

215 Lösung 1 ohne analytische Funktion select Artikel, Artikel_Gesamt, Gruppe_Gesamt, round((artikel_gesamt/gruppe_gesamt*100),0) Prozent from ( with artikel_summe AS (SELECT a.artikel_name, sum(u.umsatz) Wert_p_Artikel FROM f_umsatz U, D_artikel a WHERE U.artikel_id = a.artikel_id group by a.artikel_name) SELECT distinct a.artikel_name Artikel, s.wert_p_artikel Artikel_Gesamt, sum(u.umsatz) over (partition by a.gruppe_name) Gruppe_Gesamt FROM f_umsatz U, D_artikel a, artikel_summe s WHERE U.artikel_id = a.artikel_id and a.artikel_name = s.artikel_name);

216 Lösung 2 mit sum() OVER (PARTITION...) select artikel, umsatz_pro_artikel, gruppe, sum(umsatz_pro_artikel) over (partition by Gruppe) Gruppe_Gesamt, round(umsatz_pro_artikel/(sum(umsatz_pro_artikel) over (partition by Gruppe))*100,0) Prozent from ( SELECT a.artikel_name Artikel, a.gruppe_name Gruppe, sum(u.umsatz) umsatz_pro_artikel FROM f_umsatz U, D_artikel a WHERE U.artikel_id = a.artikel_id group by a.artikel_name, a.gruppe_name )

217 Analog: Vergleiche mit Durchschnittsmengen Gesamtumsatz Einzelartikel im Vergleich zu durchschnittlichem Artikelumsatz pro Gruppe select artikel, umsatz_pro_artikel, gruppe, avg(umsatz_pro_artikel) over (partition by Gruppe) Gruppe_Gesamt, round(umsatz_pro_artikel/(avg(umsatz_pro_artikel) over (partition by Gruppe))*100,0) Prozent from ( SELECT a.artikel_name Artikel, a.gruppe_name Gruppe, sum(u.umsatz) umsatz_pro_artikel FROM f_umsatz U, D_artikel a WHERE ) U.artikel_id group by a.artikel_name, a.gruppe_name = a.artikel_id

218 Year-To-Date Analysen - Auflistung von Umsatz pro Monat und Jahr - Kumulierung der Monatsumsätze von Jahresbeginn an select z.jahr_nummer Jahr, z.monat_desc Monat, sum(u.umsatz) Umsatz, sum(sum(u.umsatz)) over (PARTITION by z.jahr_nummer order by z.monats_nummer) year_to_date from f_umsatz u, d_zeit z where z.zeit_id = u.zeit_id group by z.jahr_nummer, z.monats_nummer, z.monat_desc / F_UMSATZ ARTIKEL_ID KUNDEN_ID ZEIT_ID REGION_ID KANAL_ID UMSATZ MENGE UMSATZ_GESAMT D_ZEIT DATUM_ID TAG_DES_MONATS TAG_DES_JAHRES WOCHE_DES_JAHRES MONATS_NUMMER MONAT_DESC QUARTALS_NUMMER JAHR_NUMMER ZEIT_ID

219 Ausführungsplan Alle Tabellen werden nur einmal gelesen Ausführung der Kumulation am Ende kurz vor der Ausgabe Id Operation Name Rows Bytes Cost (%CPU) Time SELECT STATEMENT (4) 00:00:03 1 WINDOW BUFFER (4) 00:00:03 2 SORT GROUP BY (4) 00:00:03 * 3 HASH JOIN K 186 (2) 00:00:03 4 TABLE ACCESS FULL D_ZEIT K 13 (0) 00:00:01 5 TABLE ACCESS FULL F_UMSATZ 100K 1171K 171 (1) 00:00:

220 Rank() Over Partition Ranking / Reihenfolgen Was ist das umsatzstärkste Quartal pro Jahr select * from (select sum(u.umsatz) Umsatz, z.jahr_nummer Jahr,z.Quartals_nummer "Top-Quartal", RANK() OVER (PARTITION by z.jahr_nummer ORDER BY sum(u.umsatz) ASC ) AS Rangfolge from f_umsatz u, d_zeit z where z.zeit_id = u.zeit_id and z.jahr_nummer between 2006 and 2011 group by z.jahr_nummer,z.quartals_nummer) where Rangfolge = 1 order by Jahr; F_UMSATZ ARTIKEL_ID KUNDEN_ID ZEIT_ID REGION_ID KANAL_ID UMSATZ MENGE UMSATZ_GESAMT D_ZEIT DATUM_ID TAG_DES_MONATS TAG_DES_JAHRES WOCHE_DES_JAHRES MONATS_NUMMER MONAT_DESC QUARTALS_NUMMER JAHR_NUMMER ZEIT_ID

221 Ranking ohne Partition SELECT * FROM (SELECT Artikel_Name as Artikel, sum(u.umsatz) AS Umsatz, RANK() OVER (ORDER BY sum(u.umsatz) DESC ) AS Rangfolge from F_umsatz U, D_Artikel A WHERE group by a.artikel_name) WHERE rownum < 11; U.artikel_id = a.artikel_id Rangfolge-Feld wird mitgeliefert ARTIKEL UMSATZ RANGFOLGE Wandspiegel 50x Kehrschaufel Waschbecken 40x Badewannenfaltwand 50x50x Duschbecken Die 10 umsatzstärksten Artikel D_ARTIKEL ARTIKEL_NAME GRUPPE_NR GRUPPE_NAME SPARTE_NAME SPARTE_NR ARTIKEL_ID PK F_UMSATZ ARTIKEL_ID FK KUNDEN_ID FK ZEIT_ID FK REGION_ID FK KANAL_ID FK UMSATZ MENGE UMSATZ_GESAMT

222 Alternative Version für Ranking ohne analytische Funktion select * from (SELECT * FROM (SELECT Artikel_Name as Artikel, sum(u.umsatz) AS Umsatz from F_umsatz U, D_Artikel A WHERE U.artikel_id = a.artikel_id group by a.artikel_name) order by Umsatz desc) where rownum < 11 ; 2 geschachtelte Sub-Selects weil die Klausel where rownum < 11 erst nach der Klausel ORDER BY UMSATZ wirken soll. Es fehlt das Rangfolgenfeld. Das müßte man jetzt zusätzlich noch Konstruieren.

223 Ranking Die 5 umsatzstärksten Bundesländer D_REGION REGION_ID ORTNR ORT KREISNR KREIS LANDNR LAND REGIONNR REGION F_UMSATZ ARTIKEL_ID KUNDEN_ID ZEIT_ID REGION_ID KANAL_ID UMSATZ MENGE UMSATZ_GESAMT SELECT * FROM (SELECT R.land as Land, sum(u.umsatz) AS Umsatz, RANK() OVER (ORDER BY sum(u.umsatz) DESC ) AS Rangfolge from F_umsatz U, D_REGION R WHERE U.REGION_ID = r.region_id group by r.land) WHERE rownum < 6;

224 Ranking RANK Plätze werden aufsteigend vergeben Bei 2 gleichen Position bleibt der darauf folgende frei DENSRANK Plätze werden aufsteigend vergeben Bei 2 gleichen Position wird die darauf folgende Position belegt

225 Gruppierungen auf unterschiedlichen Leveln und Ranking auf Level-Ebene Partition By - Sortierung der Umsätze nach Top Artikel pro Artikelgruppe - Bilden der Rangfolge innerhalb einer Gruppe (SELECT artikel_name Artikel, gruppe_name Prod_Grp, sum(u.umsatz) AS Umsatz, RANK() OVER (PARTITION by a.gruppe_name ORDER BY sum(u.umsatz) DESC ) AS Rangfolge FROM f_umsatz U, d_artikel A WHERE U.artikel_id = a.artikel_id GROUP by a.gruppe_name,a.artikel_name ORDER by a.gruppe_name) D_ARTIKEL ARTIKEL_NAME GRUPPE_NR GRUPPE_NAME SPARTE_NAME SPARTE_NR ARTIKEL_ID PK F_UMSATZ ARTIKEL_ID FK KUNDEN_ID FK ZEIT_ID FK REGION_ID FK KANAL_ID FK UMSATZ MENGE UMSATZ_GESAMT

226 Gruppierungen auf unterschiedlichen Leveln und Ranking auf Level-Ebene Partition By - Sortierung der Umsätze nach Top 3 Artikel pro Artikelgruppe -Bilden der Rangfolge innerhalb einer Gruppe SELECT * FROM (SELECT artikel_name Artikel, gruppe_name Prod_Grp, sum(u.umsatz) AS Umsatz, RANK() OVER (PARTITION by a.gruppe_name ORDER BY sum(u.umsatz) DESC ) AS Rangfolge FROM f_umsatz U, d_artikel A WHERE U.artikel_id = a.artikel_id GROUP by a.gruppe_name,a.artikel_name ORDER by a.gruppe_name) WHERE Rangfolge < 4; D_ARTIKEL ARTIKEL_NAME GRUPPE_NR GRUPPE_NAME SPARTE_NAME SPARTE_NR PK ARTIKEL_ID F_UMSATZ ARTIKEL_ID FK KUNDEN_ID FK ZEIT_ID FK REGION_ID FK KANAL_ID FK UMSATZ MENGE UMSATZ_GESAMT

227 (Zeit-) Reihenvergleiche LAG() select z.jahr_nummer Jahr, z.monat_desc - Sortierung der Umsätze nach Monaten - Anzeigen des Vorjahresmonats Monat, sum(u.umsatz) Umsatz, LAG(sum(u.umsatz), 12) OVER (ORDER BY z.monat_desc) Vorjahresmonat, from f_umsatz u, d_zeit z where z.zeit_id = u.zeit_id group by z.jahr_nummer,z.monats_nummer,z.monat_desc F_UMSATZ ARTIKEL_ID KUNDEN_ID ZEIT_ID REGION_ID KANAL_ID UMSATZ MENGE UMSATZ_GESAMT D_ZEIT DATUM_ID TAG_DES_MONATS TAG_DES_JAHRES WOCHE_DES_JAHRES MONATS_NUMMER MONAT_DESC QUARTALS_NUMMER JAHR_NUMMER ZEIT_ID

228 Summenzeilen ausgeben GROUP BY ROLLUP / CUBE SELECT artikel_name Artikel, gruppe_name Prod_Grp, sum(u.umsatz) AS Umsatz FROM f_umsatz U, d_artikel A WHERE U.artikel_id = a.artikel_id GROUP by ROLLUP (a.gruppe_name,a.artikel_name) ORDER by a.gruppe_name ROLLUP Summenzeilen entsprechend der Felder unter GROUP BY CUBE Summenzeilen für alle Kombinationen SchraubenschluesselSet Heimwerker Stichsaege Heimwerker Wasserwaage_1m Heimwerker Heimwerker Abschleppseil KFZ-Zubehoer Aufkleber_D KFZ-Zubehoer Autatlas KFZ-Zubehoer ErsteHilfekoffer KFZ-Zubehoer Fahrradhalter KFZ-Zubehoer Felgenkappen KFZ-Zubehoer Gluebirnen_Set KFZ-Zubehoer Hydraulik_Wagenheber KFZ-Zubehoer KaelteSet KFZ-Zubehoer Oelfilter KFZ-Zubehoer Poliermittel KFZ-Zubehoer Reinigungsfilter KFZ-Zubehoer Reinigungstuecher KFZ-Zubehoer Sitzauflage KFZ-Zubehoer Universal_Wagenheber KFZ-Zubehoer Zusatzlicht_Front KFZ-Zubehoer KFZ-Zubehoer rows selected.

229 Ausgeben zusätzlicher Steuerinformation für programmiertes Auslesen des Ergebnisses SELECT artikel_name AS Artikel, gruppe_name AS Gruppe, sparte_name AS Sparte, sum(u.umsatz) AS Umsatz, GROUPING(Artikel_name) AS Art_g, GROUPING(gruppe_name) AS Grp_g, GROUPING(Sparte_name) AS Spr_g, GROUPING_ID(artikel_name,gruppe_name,sparte_name ) AS grouping_id FROM f_umsatz U, d_artikel A WHERE U.artikel_id = a.artikel_id GROUP by CUBE (a.sparte_name, a.gruppe_name,a.artikel_name) HAVING GROUPING(Artikel_name) = 1 OR GROUPING(gruppe_name) = 1 OR GROUPING(Sparte_name) = 1 ORDER by GROUPING(Artikel_name),GROUPING(gruppe_name),GROUPING(Sparte_name) /

230 Beispiel ART_G GRP_G SPR_G G ROUPING_ID Kombinationen von 0 und 1 werden genutzt um entsprechende Summenwerte anzuzeigen Grouping_ID sortiert die Kombinationsvarianten durch

231 In-Memory Database im Data Warehouse 239

232 Datenbank wahlweise im Hauptspeicher Keine Änderung der Anwendung Spaltenorientiert Komprimiert 2-20 fach Parallelisierung Nutzt bestehende DB-Architektur und Funktionalität Auf jeder Hardware möglich

233 Dual Format Database Beides Row- und Column- Format für dieselbe Tabelle Memory F_UMSATZ Row Format Memory F_UMSATZ Column Format Tabellen, Materialized Views, Partitionen Gleichzeitiges Lesen und Updaten, gesicherte Transaktionen Updates direkt persistiert Optimizer wählt optimalen Zugriff Analytics & Reporting können In-Memory Column-Format nutzen OLTP-Anwendungen mit umfangreicher Satzverarbeitung nutzen bewährtes Row Format Laden durch Hintergrundprozesse Bei erstmaligem Lesen oder Datenbank-Start ORA_W001_orcl / INMEMORY_MAX_POPULATE_SERVERS 241

234 Es ist nur ein Schalter!! Kein Migrationsprojekt D_ZEIT DATUM_ID TAG_DES_MONATS TAG_DES_JAHRES WOCHE_DES_JAHRES MONATS_NUMMER MONAT_DESC QUARTALS_NUMMER JAHR_NUMMER ZEIT_ID PK D_REGION REGION_ID ORTNR ORT KREISNR KREIS LANDNR LAND REGIONNR REGION PK D_VERTRIEBSKANAL KANAL_ID PK VERTRIEBSKANAL KANALBESCHREIBUNG VERANTWORTLICH KLASSE F_UMSATZ D_ARTIKEL ARTIKEL_NAME GRUPPE_NR GRUPPE_NAME SPARTE_NAME SPARTE_NR ARTIKEL_ID ARTIKEL_ID FK KUNDEN_ID FK ZEIT_ID FK REGION_ID FK KANAL_ID FK UMSATZ MENGE UMSATZ_GESAMT PK 50 Mio Sätze PK: Btree Index FK: Bitmap Index D_KUNDE KUNDEN_ID PK 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 Laden in den InMemory-Speicher: Einfaches Markieren Danach einmal anfassen Alter table F_UMSATZ INMEMORY; Alter table D_ZEIT INMEMORY; Alter table D_VERTRIEBSKANAL INMEMORY; Alter table D_REGION INMEMORY; Alter table D_KUNDE INMEMORY; Alter table D_ARTIKEL INMEMORY; CREATE TABLE F_UMSATZ PARTITION BY RANGE (PARTITION p1 INMEMORY NO MEMCOMPRESS PARTITION p2 INMEMORY MEMCOMPRESS FOR DML, PARTITION p3 INMEMORY MEMCOMPRESS FOR QUERY, : PARTITION p200 INMEMORY MEMCOMPRESS FOR CAPACITY );

235 In-Memory im Data Warehouse Komplexe Abfragen auf viele Daten mit mehreren Joins Sub-Selects Groupings Analytische Funktionen Keine repräsentative Hardware: Laptop mit Intel i5-3320m 2,6 GHz CPU und 4 GB In-Memory-Storage Beispielabfrage Umsatz pro Region, Zeit, Vertriebskanal,, Berufsgruppe Sortiert nach Kriterien (Abf. 2) Stärkster Umsatzmonat pro #Joins #Where Condition Subselect Analytic Functions Grouping Ohne In-Memory P1 P4 Mit In-Memory ,35 27,00 1,10 0,53 Bundesland in 2010 (Abf. 8) ,66 35,03 1,00 0,54 P1 P4 Top 10 Artikel bezogen auf Umsatz in einem Jahr pro Bundesland in 2010 (Abf. 10) ,14 32,03 3,02 1,55

236 Kompressions-Varianten NO MEMCOMPRESS MEMCOMPRESS FOR DML MEMCOMPRESS FOR QUERY LOW MEMCOMPRESS FOR QUERY HIGH MEMCOMPRESS FOR CAPACITY LOW MEMCOMPRESS FOR CAPACITY HIGH The data is not compressed. This method optimizes the data for DML operations and compresses IM column store data the least (excluding NO MEMCOMPRESS). This method results in the best query performance. This method compresses IM column store data more than MEMCOMPRESS FOR DML but less than MEMCOMPRESS FOR QUERY HIGH. This method is the default when the INMEMORY clause is specified without a compression method in a CREATE or ALTER SQL statement or when MEMCOMPRESS FOR QUERY is specified without including either LOW or HIGH. This method results in excellent query performance. This method compresses IM column store data more than MEMCOMPRESS FOR QUERY LOW but less than MEMCOMPRESS FOR CAPACITY LOW. This method results in good query performance. This method compresses IM column store data more than MEMCOMPRESS FOR QUERY HIGH but less than MEMCOMPRESS FOR CAPACITY HIGH. This method is the default when MEMCOMPRESS FOR CAPACITY is specified without including either LOW or HIGH. This method results in fair query performance. This method compresses IM column store data the most. 244

237 Oracle In-Memory Advisor New In-Memory Advisor Analysiert bestehenden DB Workload über AWR & ASH Repository Liefert eine Liste von Objekten, die am meisten von In- Memory-Column-Storage profitieren

238 Vector Register REGION Vektor-Scans Memory Example: Finde alle Verkäufe In der Region CA Jeder CPU Kern liest einzelne In-Memory Columns CPU Load multiple region values CA CA CA CA Vector Compare all values an 1 cycle SIMD Vektor Instruktionen Milliarden von Sätzen/Sekunde/Core 246

239 DateKey Amount Date DateKey Join-Verfahren: Bloom-Filter Example: Find all orders placed on Christmas eve DATE_DIM LINEORDER Erstellen von Filtertabellen (Bloom-Filter) Datekey is Type=d.d_date='December 24, 2013' Sum 247

240 Outlets In-Memory Aggregation Example: Report sales of footwear in outlet stores Products In-Memory Report Outline Sales Dynamisches Erstellen von In- Memory Aggregat-Objekten Footwear Stores $ Footwear $$ $$$ $ Outlets Sales 248

241 Wo und wie macht In-Memory im Data Warehouse Sinn und was ändert sich?

242 Zunächst ein wichtiges Prinzip: Verteilung von Tabellendaten über die Speicherhierarchie Umsatzdaten DISK SSD Flash In Memory Juni 14 Juni 14 Mai 14 Mai 14 April 14 April 14 März 14 März 14 Februar 14 Februar 14 Januar 14 Januar 14 Dezember 13 Dezember 13 November 13 November 13 Oktober 13 Oktober 13 September 13 September 13 August 13 August 13 Juli13 Juli13 Juni 13 Juni 13 April 13 April 13 März 13 März 13 Februar 13 Februar

243 An welchen Stellen macht In-Memory Sinn OLTP Systeme Disk-Daten In Memory Integration Layer Temporäre Daten T T Referenzdaten Stammdaten Enterprise Layer Core - DWH / Info Pool R R R S S S User View Layer Alle Dimensionen Bei sehr großen Dimensionen nur die am häufigsten genutzten Spalten Die aktuellen Partitionen In-Memory Partitionierte Transaktionsdaten nur wenn sie abgefragt werden Vorberechnete Kennzahlen C A MJ Q L A Data Mining Statistikdaten Operational Data Oracle R

244 Enge Verzahnung von OLTP und DWH wird möglich OLTP Systeme Integration Layer Temporäre Daten T T Ermöglichen von Realtime-Reporting und Realtime-ETL Disk-Daten In Memory Kein expliziter Ladevorgang für Transaktionsdaten Gelesen wird die In-Memory-Version während das OLTP-System klassisch die Disk-Version der Daten beschreibt Operational Data Stores entfallen, wenn sie nur OLTP-Daten 1:1 bereitstellen. (Wenn machbar können operative Daten direkt gelesen werden) Operational Data

245 Sind Star Schemen noch sinnvoll? Ja, natürlich! Star-Schemen hatten auch schon vor In Memory ihre Aufgabe als Performance-Bringer verloren Star Schemen stellen Kennzahlen (FAKT) in ihrem fachlichen Kontext (DIMENSION) dar. User View Layer Vorberechnete Kennzahlen C Welches Kundensegment macht in welcher Region in welcher Zeit mit welchem Produkt am meisten Umsatz Kunden Zeit A MJ Q L Data Mining Statistikdaten A Produkt Region Oracle R

246 Sind Materialized Views noch sinnvoll? Nicht als reine Performance-Objekte Aber: Bis zu 80% aller BI-Auswertungen sind vorhersehbar und sollten in der Datenbank vorberechnet werden Berechnung in der Datenbank ist wesentlich schneller Die Berechnung von Kennzahlen wird standardisiert Sie verhindern, das jeder BI-Benutzer Kennzahlen individuell berechnet Materialized Views bilden fixe Kennzahlensysteme im Warehouse ab Mit In-Memory sind sie noch schneller User View Layer Vorberechnete Kennzahlen C A MJ Q L Data Mining Statistikdaten A Oracle R

247 Klassisches Vorgehen Redundanz wegen Denormalisierung Bereitstellung physischer Tabellen wg. Star Query Vorberechnung von Kennzahlen in Form von MAVs Enterprise Layer Core - DWH / Info Pool Referenzdaten Stammdaten R S S Bewegungsdaten auf Transaktionslevel der operativen Systeme R R S User View Layer Physikalische Dimension Stammdaten Mav KZ F Physikalische Fakten Zusätzlich Bitmap Indexe 255

248 Mögliches Vorgehen: Virtualisierung User View Layer Dimensionale Modelle simulieren Vorberechnung von Kennzahlen on-the-fly Enterprise Layer Core - DWH / Info Pool Referenzdaten Stammdaten R S S Bewegungsdaten auf Transaktionslevel der operativen Systeme R R S User View Layer Dimension als View auf In-Memory Stammdaten Mav KZ Nur aktuelle Partitionen Und nur die wichtigsten Spalten Kleine Dimensionen Im klassischen Buffer Cache 256

249 Mögliches Vorgehen : Virtualisierung User View Layer Im Enterprise Layer Dimensionsschlüssel müssen bereits existieren Historisierung Historisierung Kaum physikalische Persistenz auf den Festplatten Zugewinn Flexiblere und schneller Bereitstellung multidimensionaler Strukturen Weniger Plattenplatz weil weniger Redundanz im Schichtenmodell Mehr Performance REGION REGIONNR REGIONNR LAND LANDNR LANDNR KREISNR KREIS KREISNR ORTNR ORT REGION_ID ARTIKEL_ID ARTIKEL_NAME GRUPPE_NR GRUPPE_NR GRUPPE_NAME SPARTE_NR SPARTE_NR SPARTE_NAME Enterprise Layer REGION REGIONNR LAND LANDNR KREISNR KREIS ORTNR ORT REGION_ID VW_ORT User View Layer ARTIKEL_ID ARTIKEL_NAME GRUPPE_NR GRUPPE_NAME SPARTE_NR SPARTE_NAME VW_ARTIKEL Dimension als View auf In-Memory Stammdaten Mav KZ ZEIT_ID DATUM_ID TAG_DES_MONATS TAG_DES_JAHRES WOCHE_DES_JAHRES MONATS_NUMMER MONAT_DESC QUARTALS_NUMMER JAHR_NUMMER Kleine Dimensionen Im klassischen 257

250 Herausforderungen Durch Wegfall von Tabellen Fehlende Orientierung bzgl. Hierarchisierung und mögliche Drill-Pfade Welche normalisierten Tabellen lassen sich zu Dimensionen formen? Lösung: Dokumentation über Metadaten-Layer REGION REGIONNR REGIONNR LAND LANDNR LANDNR KREISNR KREIS KREISNR ORTNR ORT REGION_ID Enterprise Layer REGION REGIONNR LAND LANDNR KREISNR KREIS ORTNR ORT REGION_ID VW_ORT User View Layer Dimension als View auf In-Memory Stammdaten Mav KZ ARTIKEL_ID ARTIKEL_NAME GRUPPE_NR GRUPPE_NR GRUPPE_NAME SPARTE_NR SPARTE_NR SPARTE_NAME ARTIKEL_ID ARTIKEL_NAME GRUPPE_NR GRUPPE_NAME SPARTE_NR SPARTE_NAME VW_ARTIKEL ZEIT_ID DATUM_ID TAG_DES_MONATS TAG_DES_JAHRES WOCHE_DES_JAHRES MONATS_NUMMER MONAT_DESC QUARTALS_NUMMER JAHR_NUMMER Kleine Dimensionen Im klassischen 258

251 Metadaten Basis für schnelles Agieren Zusammenhänge von Hierarchie-Leveln Hierarchisierung von Attributen Zusammenhänge von Dimensionen und Fakten Zusammenhänge von Fakten und Kennzahlen 259

252 Konsequenzen Auflösung der Schichtengrenzen Enterprise/End User Layer Trennung nur noch logisch bzgl. der Modellart Integration Layer Enterprise Layer Core - DWH / Info Pool User View Layer Physikalische Nähe von Enterprise/End User Layer Keine separate Datenhaltung für Data Marts Keine Datenkopien für Fachabteilungen Zugriffe von Endbenutzer auf zentrale Schicht Datenzentriertes Security-Modell Virtuelle Dimensionen (z. B. als Views) Neuer Umgang mit Faktentabellen Wegfall von Bitmap-Indizierung Selektiver Umgang mit Spalten Eventuell Ersatz von Faktentabellen durch In-Memory-MAVs 260

253 Jeder wird profitieren, der wichtige DWH-Prozesse in die Datenbank verlagert Komplette Schichten-Architektur in einer Datenbank, auf einem Server Advanced Analytics in der Datenbank InPlace-Data Mining R-Objekte + R-Skripte in der Datenbank Vorberechnete Kennzahlen Generieren von Graphiken Zentrale Security-Verwaltung mit Bordmittel der Datenbank ETL-Strecken mit Native-SQL in der Datenbank Vorberechnete Kennzahlen Zentrales Security in der Datenbank Single Point + In-Memory-fähig R-Objekte Alle Schichten in einer Datenbank ETL-Strecken mit Native SQL Data Quality Analysen In Place Data Mining 261

254 Fehlentwicklungen Integration Layer Enterprise Layer Core - DWH / Info Pool User View Layer BI Plattform 1 C a c h e 2 Integration Layer Enterprise Layer Core - DWH / Info Pool User View Layer Analytische Datenbank In Memory In Memory 262

255 Fehlentwicklungen Integration Layer Enterprise Layer Core - DWH / Info Pool User View Layer BI Plattform 1 1:1 Kopie! C a c h e! Verlängerung des Gesamtbeschaffungsprozesses Zusätzliche versteckte IT-Aufwende in den Fachabteilung Gefahr nicht abgestimmter Kennzahlen! Separate Hardware + Maintenance 2 Integration Layer Enterprise Layer Core - DWH / Info Pool User View Layer 1:1 Kopie Analytische Datenbank! In Memory In Memory 263

256 Mit In-Memory Integration Layer Enterprise Layer Core - DWH / Info Pool User View Layer BI Plattform 1 In Memory C a c h e Kompakte Analyse-Umgebungen profitieren am meisten von In-Memory direkt in der Datenbank 2 Integration Layer Enterprise Layer Core - DWH / Info Pool User View Layer Analytische Datenbank In Memory In Memory In Memory Eine Datenbank, ein Server 264

257 Mit In-Memory Integration Layer Enterprise Layer Core - DWH / Info Pool User View Layer BI Plattform 3 Virtuelle Strukturen C a c h e Virtualisierung des User View Layers - Mehr Flexibilität - Schnellere Weiterentwicklung / Reagieren - Weniger Redundanz von Daten - Volle multidimensionale Sicht 265

258 Sekundenschnelle Antworten des Systems unterstützen ein intuitives Analysieren Click and Think Click and Think Click and Think Click and Think Click and Think Click and Think Click and Think Click and Think Click and Think Click and Think Click and Think Click and Think Click and Think Das Analysesystem behindert nicht mehr den Gedankenfluss. Benutzer starten mehr Abfragen in der gleichen Zeit Benutzer haben mehr Mut für komplexere Abfragen Reaktionszeiten verkürzen sich - Schlagzahl wird erhöht Mehr Resultate -> mehr Aktionen -> mehr Nutzen aus den Daten Der Informationsvorrat der Systeme ist schneller erschöpft Bedarf nach vielfältigeren Daten und komplexeren Datenmodellen Noch mehr Daten aus unterschiedlichen Bereichen werden zusammenhängend abgefragt Noch intensivere Nutzung der Warehouse-Systeme 266

259 Ist In-Memory nur etwas für große Systeme? Nein Vor allem auch kleinere Umgebungen profitieren Sie haben oft kein eigenes Storage-System, sondern hängen am SAN und konkurrieren mit vielen OLTP- Anwendungen Das SAN wirkt oft als IO-Bremse Mit In-Memory machen sich kleinere Systeme IO-unabhängig! Ohne Inmemory Potenzielles Leistungsvermögen 200 MB / Sec / Core = 1,6 GB / Sec PARALLEL 4 optimal 700 MB / Sec Andere OLTP Anwendungen SAN Mit Inmemory Potenzielles Leistungsvermögen 200 MB / Sec / Core = 1,6 GB / Sec PARALLEL 16 optimal 700 MB / Sec Andere OLTP Anwendungen > 5 GB / Sec SAN In Memory Column Store 267

260 Noch einmal zum Schluss Die Ansprüche der Anwender werden wachsen und damit die Datenmengen und die Datenvielfalt Architekturen werden kompakter BI Caches wandern zurück in die Datenbank Direkt lesende BI-Werkzeuge haben Vorteile Analytische Datenbanken werden überflüssig In-Database-Prozesse sind auf dem Vormarsch In-Database Data Mining In-Database ETL 268

261 Laden und Updaten im Data Warehouse mit Bordmitteln der Datenbank 269

262 Ziele und Aufgaben 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 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? 270

263 ETL-Prozess planen und Lade-Aufwand minimieren Ladeläufe orientieren sich an den Daten, die man braucht 1. Erst die Datenstrukturen und Schichten entwerfen 2. Ladelauf planen Zur Orientierung hilft das 3-Schichten-Modell: Data Integration Layer T T T B B R ETL: Kosten pro Kunde Enterprise Information Layer R S S S B B B B ETL: Kosten pro Kunde ETL: Kosten pro Kunde D ETL: Kosten pro Kunde User View Layer D D D F D F F D D D Die frühest mögliche Stelle für Transformationen finden 271

264 Die Organisation des ETL-Prozesses Data Integration Layer Enterprise Information Layer User View Layer Richtig selektieren Die Masse aller Prüfungen Stamm- Referenzdaten aktualisieren Nur denormalisierende Joins Möglichst viele Kennzahlen in die Datenbank Repository (Glossar, alle Objekte) Für alle Aktionen den frühest möglichen Punkt finden 272

265 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 Normalisieren Historisieren (Granularisieren) Denormalisieren z.t. Aggregieren 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 273

266 Verfahren für schnelles ETL in der Datenbank Data Integration Layer Enterprise Information Layer User View Layer Selektieren Statt kopieren Direct Path in temporäre Tabellen Contraintfreies Prüfen mit Mengenbasiertem SQL Partition Exchange &LOAD in partit. Tabellen (PEL) Unveränderte Bewegungsdaten liegen lassen Große Fakten-Tab. über PEL. Kennzahlen ausschließlich über MAV- Refresh Beknnte Kennzahlen in die DB weniger Koipien in BI-Tools

267 Deltadaten Extrahieren OLTP DWH 1 Table Änderungsdatum Table 2 Table Trigger Table Queue 3 Table Deltabildung über MINUS Table 4 LogFile Logminer Table Queue 5 LogFile Streams Queue Table 6 LogFile Golden Gate Queue Table

268 Deltadaten-Erkennung Einmaliger Initial - Load SRC Table 1:1 Kopie SRC Table 1:1 Kopie TGT Table Regelmäßiges Laden SRC Table 1:1 Kopie SRC Table (neu) merge into TGT Table select * from ((select...from SRC_TABLE_neu) minus select * from SRC_TABLE_alt)) TGT Table SRC Table (-1) 276

269 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; 277

270 Einlesetechniken Vorsysteme EBCDIC ASCII SQL-Loader External Table Direct Save SQL Oracle Database Link Transportable TS Datapump SQL BS Copy BS Copy Non Oracle ODBC JDBC Gateway SQL SQL SQL Oracle DWH Applikation z. B. SAP R/3 API API CALL SQL

271 SQL*Loader Loader Modes Convential 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 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 279

272 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 ) 280

273 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 281

274 Data Pump Architektur Quelle: 282

275 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 283

276 Vereinfachte Verfahrensdarstellung OLTP DWH Export mit Data Pump (expdp) FTP Import mit Data Pump (impdp) Schema OLTP Besondere GRANTs Schema DWH Delta-Load 284

277 Export der Daten Optional Flashback zum Absichern des Entlade-Zeitpunktes nutzen Remote-Export möglich (per NETWORK_LINK) Wegfall von separatem FTP-Aufruf OLTP DWH Einschränkung durch Query-Bedingung Damit Zugriff z. B. auf Last Update-Sätze Default Export Location Export mit Data Pump (expdp) FTP Import mit Data Pump (impdp) D:\o11\admin\o11\dpdump\EXPDAT.DMP Schema OLTP Besondere GRANTs Schema DWH Delta-Load 285

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

279 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 287

280 External Tables TEXT DATA PUMP HDFS HIVE 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 Schreiben Alternative zum SQL*Loader 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 )) 288

281 Konzept für variable Directories oder Dateinamen Szenario: Z. B. sich täglich ändernde Dateinamen Datum im Dateinamen Lieferantenname im Dateinamen ABC ABC ABC ABC DWH alter table ex_orte default directory LC_Texte_2; create or replace directory LC_TEXTE AS 'D:\Szenario\Testdaten'; create or replace directory LC_TEXTE_2 AS 'D:\Szenario\Testdaten'; alter table ex_orte location ('ORTE_Y.CSV'); 289

282 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; 290

283 External Tables mit Data Pump OLTP DWH EX_T EX_T FTP select * from EX_Bestellung_2 291

284 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 292

285 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 Vorgehensweise 1. Anlegen des Tablespaces im Quellsystem 2. Zuweisung der zu kopierenden Daten des Tablespace Alle Daten sind dem Tablespace zugeordnet (Indizes etc.) 3. Ändern des Tablespaces auf Read-Only 4. Export der Metadaten mit Data Pump (EXPDP) 5. Eventuell Konvertierung des Tablespace Datafiles Über die RMAN CONVERT Function 6. Kopieren des Tablespace Datafiles und der Metadaten 7. Import der Metadaten in der Zielumgebung 8. Ändern des Tablespaces auf Read-Write 293

286 Transportable Tablespaces CREATE TABLE temp_jan_umsatz NOLOGGING TABLESPACE ts_temp_umsatz AS SELECT * FROM????????? WHERE time_id BETWEEN '31-DEC-1999' AND '01- FEB-2000'; Temp_jan_umsatz ALTER TABLESPACE ts_temp_umsatz READ ONLY; Kopieren des Tablespace zur Zielplattform BS-Copy Daten 'dd-mon-yyyy')); EXP TRANSPORT_TABLESPACE=y TABLESPACES=ts_temp_umsatz FILE=jan_umsatz.dmp Meta daten IMP TRANSPORT_TABLESPACE=y DATAFILES='/db/tempjan.f' TABLESPACES=ts_temp_umsatz FILE=jan_umsatz.dmp ALTER TABLESPACE ts_temp_umsatz READ WRITE; ALTER TABLE umsatz ADD PARTITION umsatz_00jan VALUES LESS THAN (TO_DATE('01-feb-2000', ALTER TABLE umsatz EXCHANGE PARTITION umsatz_00jan WITH TABLE temp_umsatz_jan INCLUDING INDEXES WITH VALIDATION; 294

287 ETL-Performance-Techniken in der Datenbank 295

288 Direct Path / Convential Path 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

289 Convential und Direct Path Load Convential Path Konkurriert mit allen anderen Prozessen im Buffer- Management Baut SQL-Struktur auf, die dann zu analysieren ist. Sucht nach nicht vollständig gefüllten Blöcken und füllt diese Sinnvoll bei: Beschreiben von indizierten Tabellen Parallel zu anderen Loadvorgängen stattfindenden Loads (kein exklusiver Zugriff möglich) Bei dem Laden von kleinen Datenmengen in Tabellen mit großen Indizes Bei Tabellen mit Constraints Direct Path Baut Column-Array-Struktur auf und gibt diese direkt an die Load Engine der DB Ohne zuvor in Buffer zu schreiben Bildet neue Blöcke und schreibt diese direkt weg Sinnvoll bei: Nicht indizierten Tabellen (Index würde bei dem Zusammenführen mit neuen Einträgen kopiert werden. Das kostet Zeit) Nicht mit Constraints (PK/FK) belegten Tabellen (Constraints werden zunächst ausgeschaltet und nachträglich wieder aktiviert. Das kann insgesamt länger dauern) 297

290 Hinweise zum Direct Path Load create table tab (a integer); insert /*+ append */ into tab select rownum from dual; select * from tab; FEHLER in Zeile 1: ORA-12838: Objekt kann nach paralleler Änderung nicht gelesen/geändert werden Zieltabelle ist exklusiv nur für den Ladelauf geöffnet Schreibt immer oberhalb der High Watermark Bei der Definition der Tabellen PCTFREE klein wählen (abhängig von späteren UPDATE- Vorgängen) Bei der Definition der Tabellen PCTUSED klein wählen (lässt die Blöcke möglichst voll werden) 298

291 Table Functions Pipeline-Verfahren Parallelisierung trotz aufwendiger Programmierlogik 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)) 299

292 Begriffe im Bereich Table Functions Table Function 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. 300

293 Mengenbasierte Verarbeitung Trotz Programmierung INSERT INTO Table SELECT Feld1, Feld2 FROM Variante 1 Variante 2 Table_Function( ) Funktion Cursor Fetch Loop If a = b... Update... Case... pipe row(record Type) Return Table Schnelle Verarbeitung (Pipelined) Objekttechnik Parallelisierung Mehrere Rückgabewerte und Einzelrückgaben Cursor als Input Schachtelbar 301

294 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; Definition Record-Type Definition Nested-Table auf der Basis des Rekord-Types 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 Cursor als Typ des Übergabeparameters 302

295 303 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 SELECT-Statement (Alternative zu PIPE). 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(' ','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; Übernahme von Ausgangssätzen als Cursor

296 Beispielaufrufe 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)) 304

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

298 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')); 1 -- Neue leere temporäre Tabelle erstellen CREATE TABLE Bestellung_temp AS SELECT * FROM Bestellung WHERE ROWNUM < 1; 2 -- 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'), 3 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;

299 Exchange Partition Data Integration Layer Enterprise Information Layer User View Layer Älteste Archivieren (drop partition) CTAS Checks Tmp_table Direct Path Mai Juni Juli August September Oktober November Alter table add partition Alter table exchange partition

300 Aufbau Fakten-Tabellen Data Integration Layer Enterprise Information Layer User View Layer Älteste Archivieren (drop partition) Fact-Table CTAS Checks Tmp_table Direct Path Mai Juni Juli August September Oktober November Tmp_table CTAS Tmp_table Juni Juli August September Oktober November Alter table exchange partition Alter table exchange partition

301 Native Support für Pivot und Unpivot Sinnvoller Einsatz im Rahmen des ETL-Prozesses SALESREP Q1 Q2 Q3 Q SALESREP QU REVENUE Q Q Q Q Q Q Q Q Q Q Q Q

302 Native Support für Pivot und Unpivot Sinnvoller Einsatz im Rahmen des ETL-Prozesses QUARTERLY_SALES SALESREP Q1 Q2 Q3 Q SALESREP QU REVENUE Q Q Q Q Q Q Q Q Q Q Q Q4 310 select * from quarterly_sales unpivot include nulls (revenue for quarter in (q1,q2,q3,q4)) order by salesrep, quarter ; 310

303 Native Support für Pivot und Unpivot Sinnvoller Einsatz im Rahmen des ETL-Prozesses SALESREP 'Q1' 'Q2' 'Q3' 'Q4' SALES_BY_QUARTER SALESREP QU REVENUE Q Q Q Q Q Q Q Q Q Q Q Q1 260 select * from sales_by_quarter pivot (sum(revenue) for quarter in ('Q1','Q2','Q3','Q4')) order by salesrep ; 311

304 Aggregate bilden Bereitstellung in Form von Materialized Views Spart einen separaten ETL-Lauf Flexibler, weil nur 1 SQL-Kommando nötig Geht zu Lasten der Dokumentation Mit Partition Change Tracking die Aktualisierung der MAVs steuern Auch andere Refresh-Mechanismen nutzen 312

305 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*/); 313

306 314 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 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";

307 Set-Based ETL-Prüf- und Transformations- Techniken in der Datenbank 315

308 Es gibt 6 Prüf-Kategorien A B C Attribut-bezogene Regeln 1. Not Null / Pflichtfelder 2. Formatangaben a) numeric b) Alphanumerisch c) Date d) Masken 3. Div. Check Constraint 4. Wertbereiche Ober-/Untergrenzen / Wertelisten Satz-bezogene Regeln 5. Abhängigkeiten von Werten in anderen Attributen desselben Satzes Satz-übergreifende Regeln 6. Primary Key / Eindeutigkeit 7. Aggregat Bedingungen a) Ober- Untergrenzen von Summen b) Anzahl Sätze pro Intervall usw. 8. Rekursive Zusammenhänge Verweise auf andere Sätze derselben Tabelle (Relation) D E F Tabellen-über greifende Regeln 9. Foreign Key a) Child-Parent (Orphan) b) Parent-Child 10. Aggregat Bedingungen a) Ober- Untergrenzen von Summen b) Anzahl Sätze pro Intervall usw. 11. Referenz-Zusammenhänge Verweise auf Sätze einer anderen Tabelle (Relation) Zeit-/ Zusammenhang-bezogene Regeln 12. Zeitinvariante Inhalte (z. B. Anz. Bundesländer) 13. Zeitabhängige Veränderungen 14. Über die Zeit mit anderen Daten korrelierende Feldinhalte Verteilungs-/Mengen-bezogene Regeln 15. Verteilung a) Arithmetische Mittel b) Varianz / Standardabweichungen 16. Qualitätsmerkmale und Mengen

309 Mengen-basierte Prüfungen mit SQL A B C Attribut-bezogene Regeln 1. Not Null / Pflichtfelder 2. Formatangaben a) numeric b) Alphanumerisch c) Date d) Masken 3. Div. Check Constraint 4. Wertbereiche Ober-/Untergrenzen / Wertelisten Satz-bezogene Regeln 5. Abhängigkeiten von Werten in anderen Attributen desselben Satzes Satz-übergreifende Regeln 6. Primary Key / Eindeutigkeit 7. Aggregat Bedingungen a) Ober- Untergrenzen von Summen b) Anzahl Sätze pro Intervall usw. 8. Rekursive Zusammenhänge Verweise auf andere Sätze derselben Tabelle (Relation) select bestellnr, case when -- wenn Feld BESTELLNR nicht numerisch REGEXP_LIKE(BESTELLNR, '[^[:digit:]]') then 1 else 0 End Num_Check_bestellnr from bestellung; select CASE WHEN (F1 = 3 and F2 = F3 + F4) then 1 ELSE 0 end from fx insert /*+ APPEND */ into err_non_unique_bestellung select bestellnr from (select count(bestellnr) n, bestellnr from bestellung group by bestellnr) where n > 1;

310 Umgang mit SQL und PL/SQL im DB-ETL So nicht... Aber z. B. so... Create or replace procedure Proc_A V1 number; V2 number; V3 varchar2; V4 varchar2;... Cursor CS as select s1,s2 from tab_src; Begin open CS; loop fetch CS into v1,v2,...; select f1 into v3 from tab1; select f1 into v4 from tab2; insert into Ziel _tab s1,s2,s3,s4 values(v1,v2,v3,v4); end; end; insert into ziel select f1, f2, f3, f4 from (with CS as select s1 v1,s2 v2 from tab_src Select tab1.f1 f1,tab2.f2 f2, CS.s1 f3,cs.s2 f4 from tab1,tab2,cs Where... );

311 Prüfungen Kategorie A Attribut-/Column-bezogene Regeln 1. Not Null / Pflichtfelder 2. Formatangaben a) numeric b) Alphanumerisch c) Date d) Masken 3. Div. Check Constraint 4. Wertbereiche Ober-/Untergrenzen / Wertelisten Prüfen mit oder ohne Constraints? Constraints verlangsamen den Massen-Insert des ETL-Prozesses => Ohne Constraints arbeiten => Prüfen mit SQL-Mitteln => Prüfen mit DML-Errorlogging Nur bei wenigen Daten sinnvoll

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

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

314 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',' ',2,'Haupstr.', ); FEHLER in Zeile 1: ORA-02290: CHECK-Constraint (DWH.CH_KD_NAME) verletzt Verwendung von Regular Expressions steigert die Performance bei Prüfungen 322

315 Wichtiges Hilfsmittel für Einzelfeldprüfungen: CASE 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; 323

316 Hilfsfunktion: Date_Check 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 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; 324

317 Abarbeitungslogik für Einzelfeldprüfung mit CASE Temporäre Tabelle ist optional Ist wesentlich übersichtlicher Erlaubt Kombination von unterschiedlichen Prüfkriterien Gepruefte_Daten Kopieren Stage-Tabelle Varchar2() Feld1 Feld2 Feld3 INSERT INTO temp_table SELECT CASE... FROM Stage_Table Temp-Tabelle Varchar2() Feld1 Feld2 Feld3 Feld1_is_null Feld1_is_numeric Feld2_is_numeric INSERT ALL WHEN Feld_1_is_null =1 into Error_Daten WHEN Feld_1_is_null=0 into Gepruefte_Daten Date Number Varchar2() Error_Daten Date Number Varchar2() 325

318 Abarbeitungslogik für Einzelfeldprüfung mit CASE OLTP_Kunden_tmp 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) then 1 ELSE 0 END Menge_isNumeric, CASE WHEN (isnumeric(summe) = 1) then 1 ELSE 0 END Summe_isNumeric, CASE WHEN (Summe is NULL) Bestellnr Menge Summe Name Ort BestDatum Bestellnr_isNull Menge_isNumeric Summe_isNumeric then 1 ELSE 0 END Summe_isNull, CASE WHEN (isdate(bestdatum) = 1) then 1 ELSE 0 END BestDatum_isDate FROM OLTP_Kunden; Summe_isNull BestDatum_isDate...

319 Prüfungen Kategorie B Satz-bezogene Regeln Satz-bezogene Regeln 5. Abhängigkeiten von Werten in anderen Attributen desselben Satzes Lösung: Analog zu Kategorie A über CASE F1 F2 F3 F select CASE WHEN (F1 = 3 and F2 = F3 + F4) then 1 ELSE 0 end from fx

320 Prüfungen Kategorie C Satz-übergreifende Regeln 6. Primary Key / Eindeutigkeit 7. Aggregat Bedingungen a) Ober- Untergrenzen von Summen b) Anzahl Sätze pro Intervall usw. 8. Rekursive Zusammenhänge Verweise auf andere Sätze derselben Tabelle (Relation)

321 6. Eindeutigkeit / PK BESTELLUNG BESTELLNR PK ORTNR FK KUNDENNR BESTELLDATUM ANZAHLPOS Lösung: Mengenbasiertes Sammeln doppelter Sätze in Fehlertabelle insert /*+ APPEND */ into err_non_unique_bestellung select bestellnr from (select count(bestellnr) n, bestellnr from bestellung group by bestellnr) where n > 1; BESTELLPOSITION BESTELLNR POSITIONSNR MENGE ARTIKELNR DEPOTSTELLE RABATT FK PK FK

322 7. Aggregatbildung Anforderung: Wenn der Umsatz pro Artikel unter 20% des Artikelgruppen-Gesamtwertes fällt, dann ROT Lösung: Mit analytischen Funktionen: Auf Satzebene über Informationen von Satzgruppen verfügen F_UMSATZ ARTIKEL_ID KUNDEN_ID FK ZEIT_ID FK REGION_ID FK KANAL_ID UMSATZ MENGE UMSATZ_GESAMT select Artikelname, Artikelgruppe, Wert, sum(wert) over (partition by Artikelname) Artikelgesamtwert, sum(wert) over (partition by Artikelgruppe) Gruppengesamtwert, case when (round(((sum(wert) over (partition by Artikelname))/(sum(wert) over (partition by Artikelgruppe))*100),0) ) < 20 then 'ROT' ELSE 'GRUEN' end Prozent from Artikel FK FK D_ARTIKEL ARTIKEL_NAME GRUPPE_NR GRUPPE_NAME SPARTE_NAME PK SPARTE_NR ARTIKEL_ID

323 8. Rekursive Zusammenhänge Anforderung: Die Summe aller Member_Value-Werte pro Parent muss gleich dem Group_Value-Wert des Parent sein. Lösung: Über Sub-Select in dem nach Parent gruppiert und summiert wird. F_Key Parent Member Group _Value _Value select distinct A.F_key from rk A, (select sum(member_value) sum_member, parent from rk where parent!= 0 group by group_value, parent) B where A.member_value = 0 and A.group_value = B.sum_member;

324 Prüfungen Kategorie D Tabellen-übergreifende Regeln 9. Foreign Key a) Child-Parent (Orphan) b) Parent-Child 10. Aggregat Bedingungen a) Ober- Untergrenzen von Summen b) Anzahl Sätze pro Intervall usw. 11. Referenz-Zusammenhänge Verweise auf Sätze einer anderen Tabelle (Relation)

325 9. Foreign Keys Anforderung: Zu jeder Bestellung muss es einen Kunden geben. Lösung: Sub-Select in Where-Klausel. KUNDE KUNDENNR PK KUNDENNAME BERUFSGRUPPE SEGMENT KUNDENTYP BESTELLUNG BESTELLNR PK ORTNR FK KUNDENNR BESTELLDATUM ANZAHLPOS insert /*+ APPEND */ into err_orphan_bestellung select bestellnr from bestellung where Kundennr not in (select Kundennr from kunde);

326 10. Aggregatbedingungen Anzahl Sätze pro Einheit Anforderung: Anzahl Positionen muss einen bestimmten Wert haben. Lösung: Sub-Select in FROM-Klausel. insert /*+APPEND */ into err_anz_pos_bestellposition select BESTELLNR, anzahl_pos, bst_anzahlpos from (select bestellnr, count(positionsnr) Anzahl_pos, ANZAHLPOS bst_anzahlpos from Best_Pos group by bestellnr,anzahlpos) where Anzahl_pos <> bst_anzahlpos; BESTELLUNG BESTELLNR PK ORTNR FK KUNDENNR BESTELLDATUM ANZAHLPOS BESTELLPOSITION BESTELLNR POSITIONSNR MENGE ARTIKELNR DEPOTSTELLE RABATT FK PK FK

327 Umgang mit Schlüsseln im Verlauf des Ladens 335

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

329 Key Lookup Dimension 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 Satz14 Satz15 DFG 64 dloidf KD_22 erf 78 ghzf KD_33 sdfg 4456 llkof KD_44 Bewegungsdaten DFG 64 dloidf erf 78 ghzf sdfg 4456 llkof Fakten 337

330 Lookup-Verfahren mit Aktualisierung (Stammdaten) Bewegungssätze Anti Join Join Zielsätze Referenzdaten Insert mit Dummy Schlüssel Tmp Table alle Sätze ohne Referenz Protokoll 338

331 1. Schritt Sequenz Next Val 7 Anti - Join Wenn nicht in Dimension enthalten dann INSERT INTO Dim SELECT... FROM Bew, Dim WHERE Log Key NOT IN Dim Künstl. Schlüssel (Primary Key) Log.Business Schlüssel (Alternate Unique) 7 KD_99 Dummy Dummy Dummy 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 2. Schritt Join Lookup Dimension Log.Business Schlüssel Satz12 XX 567 ddwer KD_99 Satz12 AA 34 dddf KD_ XX 567 ddwer 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 Bewegungsdaten Fakten 339

332 Lade- und Transaktionssteuerung innerhalb der Datenbank 340

333 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? 341

334 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 342

335 Flashback Technologie in der Datenbank Flashback Query Flashback Table Flashback Drop Flashback Versions Query Flashback Transaction Query Flashback Database Flashback Data Archive

336 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 ; SELECT * FROM x AS OF TIMESTAMP to_timestamp(' :15:00', 'YYYY-MM-DD HH:MI:SS'); Zurücksetzen Flashback table x to scn ; 344

337 Flashback Database Flashback Database Erstellen der Fast (Flash) Recovery Area Restart Database ( mount exclusive, wenn DB <11.2) ALTER DATASE FLASHBACK ON; ALTER SYSTEM SET db_flashback_retention_target = <number_of_minutes>; ALTER DATABASE OPEN; Restore Points (ab 11.2 im laufenden Betrieb) create restore point PRE_LOAD; create restore point PRE_LOAD guarantee flashback database; (impliziert das Anlegen von Flashback Logs) drop restore point PRE_LOAD; Anwendung eines Restores nur im DB Mount-Status flashback database to restore point PRE_LOAD;

338 Flashback Database Garantierter Rücksetzpunkt Muss explizit gelöscht werden (Achtung FRA-Size!) NOLOGGING Operationen sind erlaubt Archivelog Modus dennoch zwingend Restore nur zum Rücksetzpunkt möglich (keine beliebige SCN), wenn Flashback Logs nicht explizit aktiviert wurden 346

339 Lade-Tools außerhalb der Datenbank 347

340 Oracle GoldenGate-Technologie Datenintegration für alle Anwendungsfälle Oracle GoldenGate bietet mit geringer Belastung Capture, Routing, Transformation und Delivery von Datenbank-Transaktionen in heterogenen Umgebungen in Echtzeit Alleinstellungsmerkmale Performanz non-intrusiv, niedrige Belastung, Latenzzeit von Sekundenbruchteilen Erweiterbarkeit & Flexibilität Zuverlässig Offene, modulare Architektur - Heterogene Quellen & Ziele Erhält transaktionale Integrität Robust gegen Störungen und Fehler

341 Oracle GoldenGate Architektur Capture: Auslesen der committed Transaktionen (optional gefiltert) wie sie im Transaktionslog erscheinen. Trail files: Speichern der Daten für Weiterleitung. Pump: Datendistribution zu mehreren Zielen. Route: Daten können für Übertragung verschlüsselt werden. Delivery: Anwenden mit Transaktionsintegrität, Transformationen wie benötigt. Capture LAN / WAN / Internet (TCP/IP) Source Trail Pump Pump Target Trail Delivery Quell- Datenbank Delivery Target Trail Bidirektional Source Trail Capture Ziel- Datenbank 349

342 GoldenGate Heterogene Plattformen Datenbanken Capture: Oracle DB2 Microsoft SQL Server Sybase ASE Teradata Enscribe SQL/MP SQL/MX Delivery: Alle wie oben, und zusätzlich: HP Neoview, Netezza, Greenplum und beliebige kompatible Datenbanken ETL-Produkte JMS Message Queues MySQL TimesTen ODBC O/S und Plattform Windows 2000, 2003, XP, Windows7 Linux Sun Solaris HP NonStop HP-UX HP TRU64 HP OpenVMS IBM AIX IBM z/os 350

343 Oracle ETL/ELT-Tool-Suite für unterschiedliche Anforderungen Oracle Data Integrator Oracle Warehouse Builder OLTP A DWH A OLTP A A DWH PL/SQL Insert into A Select * from A Code Template Select Java based Agent Java based Agent Set Based Code Template Insert Row+Set Based OLTP Oracle Golden Gate DWH Log Capture Source Trail Target Trail Delivery Log

344 Security und Mandantensteuerung im Data Warehouse 352

345 Sicherheit in der Datenbank Service Logistik Servicekunde Logistikaufwand Controlling Profitabilität Integration Layer Enterprise Layer Core - DWH / Info Pool Referenzdaten (extern) (10%) Stammdaten (10%) Bewegungsdaten / Transaktionen (80%) Marketingsicht Sozialsituation Kundenhistorie Profitabilität BI-Anwendungen werden im Schnitt alle 4 Jahre ausgetauscht Oft laufen mehrere BI-Anwendungen parallel User View Layer Vorberechnete Kennzahlen BI Plattform ODBC C Einkauf Produkte&Trends Kunde A MJ Q L A Vertrieb Kundenhistorie Logistikaufwand für einen Kunden Produkte&Trends Servicekunde Data Mining Statistikdaten Oracle R Marketing Marketingsicht

346 Zwei Level des Zugriffs-Monitoring 1) Standard Auditing 2) Fine Grained Auditing By session By access Statement level. all statements in a sessions any objects X X Audit select on F_UMSATZ; Granting Priviliges activities X X Object level (update, insert delete, select) X X Monitoring of all activities by User by session, by object. - Action based auditing (e. g. analysing the predicate example: value > ) - all detailed commands - Timestemps -trials and successes - Additional triggers - notifications and other actions EXECUTE DBMS_FGA.ADD_POLICY( - object_schema => 'DWH, - object_name => 'F_UMSATZ, - policy_name => 'Chk_F_Umsatz', - statement_types => 'SELECT, - enable => TRUE); 354

347 Nicht so... sondern so... Channels Kunde Channels Kunde Channels Kunde Channels Kunde Channels Umsatz Kunde Channels Umsatz Kunde Umsatz Umsatz Zeit Produkte Umsatz Zeit Produkte Umsatz Zeit Produkte Zeit Produkte Zeit Produkte Zeit Produkte Mandant 1 Mandant 2 Mandant 3 Mandant4 Mandant 5 Mandant 6 Channels Umsatz Kunde Produkte Zeit Alle Mandanten in einer Tabelle Nur einmal pflegen und verwalten! 355

348 Fine Grained Security on Row level Zu lesenden Objekte User: DataMart1 User_Table Build Predicate Procedure C o n t e x t Zugreifende Users User 2 Set User Context select sum(umsatz) from umsatz; User 3 Set User Context select sum(umsatz) from umsatz; Partner Catalog Internet Direct Sales Add / DROP Policy Channels Umsatz Kunde P r e d i c a t e Sieht nur Partner-Umsatz Sieht nur Katalogwaren-Umsatz Zeit Produkte 356

349 Auf der Seite des zu lesenden Objektes Definieren der Policy create or replace package channel_security as function channelnum_sec (A1 VARCHAR2, A2 varchar2) return varchar2; end; / create or replace package body channel_security as function channelnum_sec (A1 VARCHAR2, A2 varchar2) return varchar2 is d_predicate varchar2(2000); v_channel_id number; begin select sys_context('channel_info','channel_num') into v_channel_id from DUAL; d_predicate := 'SALES.CHANNEL_ID = ' v_channel_id ' or ' v_channel_id ' = 10'; return d_predicate; end; end; / Aktivieren der Policy exec dbms_rls.drop_policy('area1','sales','channel_policy'); exec dbms_rls.add_policy('area1','sales','channel_policy','area1', 'channel_security.channelnum_sec','select'); Auf der Seite des zugreifenden Users Logon-Trigger CREATE OR REPLACE TRIGGER vpd_init_trig AFTER LOGON ON DATABASE BEGIN EXECUTE IMMEDIATE 'DROP CONTEXT channel_infostr'; EXECUTE IMMEDIATE 'CREATE CONTEXT channel_info using user_context'; system.user_context.select_user_channel; EXCEPTION WHEN NO_DATA_FOUND THEN null; end; Erstellen des Kontextes create or replace package User_context as Procedure select_user_channel ; end; / Create or replace Package Body User_context as Procedure select_user_channel is Channelnum number; begin select channel_id into Channelnum from area1.user_table where upper(user_name) = sys_context('userenv', 'SESSION_USER'); dbms_session.set_context('channel_info', 'channel_num',channelnum); end; end; 357

350 Multi-strukturierte Daten mit JSON

351 JSON (Java Script Object Notation) Standardisiertes Format ECMA-404 (JSON Data Interchange Format) ECMA-262 (ECMAScript Language Specification, third edition) Leichteres Format als XML Weniger Datenmenge /Overhead Einfacher Umgang Besonders beliebt bei nosql-db- Java Entwicklern Im Hadoop-Umfeld weit verbreitet Ab Oracle direkt in der Datenbank 359

352 Multi-Strukturierte Informationen INSERT INTO Web_Log_array VALUES (SYS_GUID(), SYSTIMESTAMP, '{"wl_rec_id" : 1600, "wl_ip_adr" : " ", "wl_dns" : "MP-AM5643", "wl_start_date" : " :23:21", "wl_end_date" : " :25:18", "wl_ses_id" : " ", "wl_ses_anz_sec" : "10", "wl_status" : "ACK"}'); 1 INSERT INTO Web_Log_array VALUES (SYS_GUID(), SYSTIMESTAMP, '{"wl_rec_id" : 1600, "wl_ip_adr" : {"ip" : " ", "sub" : " "}, "wl_dns" : "MP-AM5643", "wl_start_date" : " :23:21", "wl_end_date" : " :25:18", "wl_ses_id" : " ", "wl_ses_anz_sec" : "10", "wl_status" : "ACK"}'); 3 INSERT INTO Web_Log_array VALUES (SYS_GUID(), SYSTIMESTAMP, '{"wl_rec_id" : 1600, "wl_ip_adr" : [" "," "], "wl_dns" : "MP-AM5643", "wl_start_date" : " :23:21", "wl_end_date" : " :25:18", "wl_ses_id" : " ", "wl_ses_anz_sec" : "10", "wl_status" : "ACK"}'); 2 SQL> select wa.log_record.wl_ip_adr from Web_Log_array wa; WL_IP_ADR " " [" "," "] {"ip":" ","sub":" "} SQL> select wa.log_record.wl_ip_adr.sub from Web_Log_array wa; WL_IP_ADR " " 360

353 Beispiel 361

354 An welcher Stelle passen JSON-Objekte in das Data Warehouse? Daten für Auswertungen? Integration Layer Enterprise Layer Core - DWH / Info Pool User View Layer Daten zur Aufbewahrung? JSON Format als Vorstufe vor Einführung von Big Data JSON JSON JSON HDFS / NoSQL Unstructured Data

355 Big Data Analysen im Data Warehouse mit Big Data SQL

356 Hadoop Services und Projekte Besteht aus 2 Key Services Hadoop Distributed File System (HDFS) MapReduce Frame Work Weitere Projekte basierend auf dem Kern-Hadoop-Konzept Hive: SQL auf Hadoop Pig: Relationale komplexe Logik und Algorithmen auf Hadoop Sqoop: Datenaustausch zwischen zwischen Hadoop und relationalen Datenbanken Hbase: nicht-relationale verteilte Database Flume: sammeln und aggregieren von verteilten Daten und laden in zentralen Datenbestand Oozie: Workflow + Scheduling für Hadoop und andere mehr 2014 Oracle All Rights Reserved

357 Business Mehrwerte über Technologie Innovation Die passende Technologie für entsprechende Aufgaben UND Technologien im Verbund nutzen Hadoop NoSQL Relational Neue Geschäftsmodelle und Optionen Wettbewerbern zuvor kommen Vollständige Informationsketten Neu Paradigmen nutzen Neue Analysearten Scale the Business Schneller Daten bereitstellen Herausforderung Mobility Ökononisch sinnvolle Skalierung Run the Business Integration von Systemen Kritische Geschäftsprozesse Investitionsschutz Eingespielte Verfahren und Know how 365

358 Die Schwierigkeiten bei der Adaption neuer Technologien INTEGRATION SKILLS SECURITY Big Data in bestehende Architekturen einbinden und die Systeme beherrschen Noch fehlen sinnvolle Tools und das Know how um Big Data Daten direkt auszuwerten Keine klare Sicherheitsstrategie erkennbar 366

359 Die Schwierigkeiten bei der Adaption neuer Technologien Oracle s - Weg INTEGRATION SKILLS SECURITY SQL Engineered Systems SQL auf allen Daten Database Security auf allen Daten 367

360 Was wäre, wenn das alles mögliche wäre Alle Datenarten für alle Datenbank-Anwendungen verfügbar machen Die volle Bandbreite der Oracle SQL Query Language nutzen Mit allen Security-Features von Oracle 12c Ohne Daten zwischen dem Hadoop-Cluster und der Datenbank hin und her zu kopieren Eine sehr hohe Query Performance erreichen Das bestehende Wissen (SQL-Skills) nutzen Und dennoch immer die aktuellsten Hadoop-Neuerungen nutzen 368

361 Oracle Big Data SQL Eine neue Architektur Mächtiges und hoch-performantes SQL auf Hadoop Alle Oracle SQL Möglichkeiten auf Hadoop SQL query Processing auf den lokalen Hadoop Knoten Einfache Daten-Integration von Hadoop und Oracle Database Single SQL Zugriffspunkt auf alle Daten Skalierbare Joins zwischen Hadoop und RDBMS-Data Optimierte Hardware High-speed Infiniband Netzwerk zwischen Hadoop und Exadata 369

362 Standardisierte Metadaten: Übernahme Hive Metadaten in den Oracle Datenbank-Katalog Hive Metastore CREATE TABLE movieapp_log_json (click VARCHAR2(4000)) ORGANIZATION EXTERNAL (TYPE ORACLE_HIVE DEFAULT DIRECTORY DEFAULT_DIR ) REJECT LIMIT UNLIMITED; Oracle Catalog Hive metadata External Table External Table Big Data Appliance + Hadoop/NoSQL Exadata + Oracle Database 370

363 Abfragen auf Hadoop ausführen Hive metadata I/O und Smart Scan ausführen Auswahl der Zeilen und Spalten Select c_customer_id, c_customer_last_name, ca_county From customers, customer_address where c_customer_id = ca_customer_id and ca_state = CA Oracle Catalog HDFS Name Node HDFS Data Node HDFS Data Node HDFS Data Node HDFS Data Node Tables Nur relevante Daten bewegen relevante Zeilen relevante Spalten Hive metadata External Table External Table Join mit Daten aus der relationalen Datenbank 1 block = 256 MB Example File = 40 blocks InputSplits = 40 mögliche Parallelsisierung 371

364 Big Data SQL Minimizes Data Movement Big Data SQL Server Hadoop Smart Scan 1. Apply filter predicates 2. Apply column projections 3. Apply row-level functions JSON Parsing External Table Services 1. Read using Hadoop Classes 2. Convert to Oracle Data Stream Data Node Direktes Arbeiten auf den Daten Scans and serializations from Hadoop classes Transformation into Oracle data stream Smart Scan: Nur relevante Daten werden werden weitergeleitet Apply filter predicates Include complex predicates, e.g. JSON_EXISTS Bloom filters for faster joins Score Data Mining models Project columns Include projections from nested structures Disk 372

365 5 5 4 Hadoop / HDFS - Knoten 1 1 SELECT * FROM movielog WHERE rownum < 20; SELECT f.click.custid, m.title, m.year, m.gross, f.click.rating FROM movielog f, movie m WHERE f.click.movieid = m.movie_id AND f.click.rating > 4; Beispiel: Log-File JSON -Format hadoop fs -tail /user/oracle/moviework/applog_json/movieapp_3months.log [oracle@bigdatalite ~]$ hadoop fs -tail /user/oracle/moviework/applog_json/movieapp_3months.log,"recommended":"y","activity":2} {"custid": ,"movieid":240,"genreid":8,"time":" :02:04:15","recommended":"y","activity":5} {"custid": ,"movieid":1092,"genreid":20,"time":" :02:10:23","recommended":"n","activity":5} {"custid": ,"movieid":4638,"genreid":8,"time":" :02:10:54","recommended":"n","activity":7} {"custid": ,"movieid":4638,"genreid":8,"time":" :02:16:49","recommended":"n","activity":7} {"custid": ,"movieid":null,"genreid":null,"time":" :02:24:00","recommended":null,"activity":9} {"custid": ,"movieid":240,"genreid":8,"time":" :02:31:12","recommended":"y","activity":11, "price":2.99} {"custid": ,"movieid":59440,"genreid":7,"time":" :03:11:35","recommended":"y","activity":2} {"custid": ,"movieid":null,"genreid":null,"time":" :03:15:29","recommended":null,"activity":9} {"custid": ,"movieid":59440,"genreid":7,"time":" :03:19:24","recommended":"y","activity":11, "price":3.99} Datenbank Maschine / Linux CREATE TABLE movielog (click VARCHAR2(4000)) ORGANIZATION EXTERNAL (TYPE ORACLE_HDFS DEFAULT DIRECTORY DEFAULT_DIR LOCATION ('/user/oracle/moviework/applog_json/') ) REJECT LIMIT UNLIMITED; create or replace directory ORACLE_BIGDATA_CONFIG as '/u01/bigdatasql_config'; create or replace directory "ORA_BIGDATA_CL_bigdatalite" as ''; create public database link BDSQL$_bigdatalite using 'extproc_connection_data'; create public database link BDSQL$_DEFAULT_CLUSTER using 'extproc_connection_data'; /BigDataConfig /BigDatalite Files mit Pfadangaben zu HDFS, Hive, JavaClass etc 2 3

366 Zugriff über Hive Metastore Hadoop / HDFS Knoten / Hive Metabeschreibung CREATE EXTERNAL TABLE `movieapp_log_json`( `custid` int COMMENT 'from deserializer', `movieid` int COMMENT 'from deserializer', `genreid` int COMMENT 'from deserializer', `time` string COMMENT 'from deserializer', `recommended` string COMMENT 'from deserializer', `activity` int COMMENT 'from deserializer', `rating` int COMMENT 'from deserializer', `price` float COMMENT 'from deserializer') ROW FORMAT SERDE 'org.apache.hive.hcatalog.data.jsonserde' STORED AS INPUTFORMAT 'org.apache.hadoop.mapred.textinputformat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.hiveignorekeytextoutputformat' LOCATION 'hdfs://bigdatalite.localdomain:8020/user/oracle/moviework/applog_json' TBLPROPERTIES ( 'last_modified_by'='oracle', 'last_modified_time'=' ', 'transient_lastddltime'=' ') Datenbank Maschine / Linux CREATE TABLE movieapp_log_json ( custid INTEGER, movieid INTEGER, genreid INTEGER, time VARCHAR2 (20), recommended VARCHAR2 (4), activity NUMBER, rating INTEGER, price NUMBER ) ORGANIZATION EXTERNAL ( TYPE ORACLE_HIVE DEFAULT DIRECTORY DEFAULT_DIR ) REJECT LIMIT UNLIMITED; 374

367 Automatisierung: Oracle Data Modeler Übernahme der Hive Definitionen in das Modell Generieren Oracle DDL für die importierten Tabellen 375

368 Neue Daten-Quellen für Oracle External Tables CREATE TABLE movielog (click VARCHAR2(4000)) ORGANIZATION EXTERNAL ( TYPE ORACLE_HIVE DEFAULT DIRECTORY Dir1 ACCESS PARAMETERS ( com.oracle.bigdata.tablename logs com.oracle.bigdata.cluster mycluster) ) REJECT LIMIT UNLIMITED Neue Eigenschaften ORACLE_HIVE und ORACLE_HDFS Access Driver Identifizuierung Hadoop Cluster, Data Source Objects, Column Mapping, Error Handling, Overflow Handling, Logging Neue Tabellen Metadaten werden von Oracle DDL zu den Hadoop Lese-Routinen zur Query-Zeit geschickt Auf Erweiterung hin entwickelt StorageHandler wird künftig auch weitere Quellen-Arten lesen können Z. B.: MongoDB, HBase, Oracle NoSQL DB 376

369 Big Data Appliance X4-2 Hardware: 18 Knoten (mit je 2 * 8 Kerne) 1152 GB RAM (erweiterbar) 864 TB Plattenkapazität 40 Gb/s InfiniBand Integrierte Software: Oracle Linux Oracle Java VM Cloudera Distribution of Apache Hadoop (CDH) Cloudera Manager Oracle R Distribution NoSQL Database Community Edition (falls gewünscht) Die integrierte Software (außer NoSQL DB CE) wird als Teil von Premier Support für Systeme bzw. Premier Support für Betriebssysteme unterstützt

370 Komplettes Set des Oracle SQL über alle Daten hinweg nutzen Ausschnitt Oracle SQL Analytische Funktionen Ranking functions rank, dense_rank, cume_dist, percent_rank, ntile Window Aggregate functions (moving and cumulative) Avg, sum, min, max, count, variance, stddev, first_value, last_value LAG/LEAD functions Direct inter-row reference using offsets Reporting Aggregate functions Sum, avg, min, max, variance, stddev, count, ratio_to_report Statistical Aggregates Correlation, linear regression family, covariance Linear regression Fitting of an ordinary-least-squares regression line to a set of number pairs. Frequently combined with the COVAR_POP, COVAR_SAMP, and CORR functions Descriptive Statistics DBMS_STAT_FUNCS: summarizes numerical columns of a table and returns count, min, max, range, mean, stats_mode, variance, standard deviation, median, quantile values, +/- n sigma values, top/bottom 5 values Correlations Pearson s correlation coefficients, Spearman's and Kendall's (both nonparametric). Cross Tabs Enhanced with % statistics: chi squared, phi coefficient, Cramer's V, contingency coefficient, Cohen's kappa Hypothesis Testing Student t-test, F-test, Binomial test, Wilcoxon Signed Ranks test, Chi-square, Mann Whitney test, Kolmogorov-Smirnov test, One-way ANOVA Distribution Fitting Kolmogorov-Smirnov Test, Anderson-Darling Test, Chi-Squared Test, Normal, Uniform, Weibull, Exponential

371 next = linenext.getquantity(); } if (!q.isempty() && (prev.isempty() (eq(q, prev) && gt(q, next)))) { state = "S"; return state; Pattern } Matching mit Oracle SQL Ausschnitt Oracle SQL Analytische Funktionen if (gt(q, prev) && gt(q, next)) { state = "T"; return state; } if (lt(q, prev) && lt(q, next)) { state = "B"; return state; } if (!q.isempty() && (next.isempty() (gt(q, prev) && eq(q, next)))) { state = "E"; return state; Simplified, } sophisticated, standards based syntax if (q.isempty() eq(q, prev)) { state = "F"; return state; } Beispiel finden von Mustern in Aktien-Markt-Bewegung (W-Form) Ticker 10:00 10:05 10:10 10:15 10:20 10:25 } return state; private boolean eq(string a, String b) { if (a.isempty() b.isempty()) { return false; } return a.equals(b); } private boolean gt(string a, String b) { if (a.isempty() b.isempty()) { return false; } return Double.parseDouble(a) > Double.parseDouble(b); } private boolean lt(string a, String b) { if (a.isempty() b.isempty()) { return false; } return Double.parseDouble(a) < Double.parseDouble(b); } public String getstate() { return this.state; } } BagFactory bagfactory = public Tuple exec(tuple input) throws IOException { SELECT first_x, last_z FROM ticker MATCH_RECOGNIZE ( PARTITION BY name ORDER BY time MEASURES FIRST(x.time) AS first_x, LAST(z.time) AS last_z ONE ROW PER MATCH PATTERN (X+ Y+ W+ Z+) DEFINE X AS (price < PREV(price)), Y AS (price > PREV(price)), W AS (price < PREV(price)), Z AS (price > PREV(price) AND z.time - FIRST(x.time) <= 7 )) long c = 0; String line = ""; String pbkey = ""; V0Line nextline; V0Line thisline; V0Line processline; V0Line evalline = null; V0Line prevline; boolean nomorevalues = false; String matchlist = ""; ArrayList<V0Line> linefifo = new ArrayList<V0Line>(); boolean finished = false; 250+ Lines of Java UDF 12 Lines of SQL 379 DataBag output = bagfactory.newdefaultbag(); if (input == null) { return null; } if (input.size() == 0) { return null; } Object o = input.get(0); if (o == null) { return null; } Copyright 2014, Oracle and/or its affiliates. All rights reserved. //Object o = input.get(0); if (!(o instanceof DataBag)) { int errcode = 2114; 20x mal weniger Code

372 R als universelles Analyse-Mittel

373 R: Brücke zwischen den Welten Statistik Data / Text Mining Modellierung SocialMedia Connect Komplexe Graphik

374 ORAAH Einsatzbereiche Direktes Arbeiten mit HDFS Objekte Vollen Zugriff auf HDFS-Objekte (Command line interfaces) HDFS.LS() Analyse von HDFS Objekten Verschieben von Daten HDFS Dateien In-Memory R Objekte, lokale Dateien, HIVE-Objekte and Oracle Datenbank Arbeiten mit R auf HIVE Tabellen HIVE SQL Funktionalität mittels ORE-like transparent Layer Overloading R Funktionen auf ore.frame Objekte die im Hintergrund auf HIVE Tabellen/views gemappt werden Native advanced analytics Funktionen Allgemeine statistische Funktionen (z. B. table()) und Predictive Analytics Techniken (z. B. Lineare Regression) Starten von MapReduce Jobs ohne Java programmieren zu müssen Aus einer R-Session heraus Map und reduce Funktionen sind in in R geschrieben Testen von MapReduce Jobs im Single Threaded Mode mit orch.dryrun / Hadoop Verarbeitung wird simuliert Arbeiten in einer R Client Umgebung

375 HCache Hadoop Abstraction Layer Oracle R Enterprise User R Engine Database Server Maschine R Engine(s) managed by Oracle DB Oracle R Packages (ORE) SQL Results Oracle Database R-Skripte Lineare Modelle Clusterung Segmentierung Neuronale Netze R Results R Engine Other R packages Oracle R Enterprise packages JSON Excel R HDFS R MapReduce CSV R Hive R sqoop/olh MapReduce Nodes HDFS Nodes JSON {CRAN packages} ORD Hadoop Cluster (z. B. BDA)

376 HDFS API Funktionen

377 ORAAH Analytics Functions Function Description orch.cor Correlation matrix computation orch.cov orch.kmeans orch.lm orch.lmf orch.neural orch.nmf orch.princomp orch.sample Covariance matrix computation Perform k-means clustering on a data matrix stored as an HDFS file. Score data using orch.predict. Fits a linear model using tall-and-skinny QR (TSQR) factorization and parallel distribution. The function computes the same statistical parameters as the Oracle R Enterprise ore.lm function. Score data using orch.predict. Fits a low rank matrix factorization model using either the jellyfish algorithm or the Mahout alternating least squares with weighted regularization (ALS-WR) algorithm. Provides a neural network to model complex, nonlinear relationships between inputs and outputs, or to find patterns in the data. Score data using orch.predict. Provides the main entry point to create a nonnegative matrix factorization model using the jellyfish algorithm. This function can work on much larger data sets than the R NMF package, because the input does not need to fit into memory. Principal components analysis of HDFS data. Score data using orch.predict. Sample HDFS data by percentage or explicit number of rows specification

378 Beispiel zur Nutzung von Hive mit OREhive ore.connect(type="hive") ore.attach() # create a Hive table by pushing the numeric # columns of the iris data set IRIS_TABLE <- ore.push(iris[1:4]) # Create bins based on Petal Length IRIS_TABLE$PetalBins = ifelse(iris_table$petal.length < 2.0, "SMALL PETALS", + ifelse(iris_table$petal.length < 4.0, "MEDIUM PETALS", + ifelse(iris_table$petal.length < 6.0, + "MEDIUM LARGE PETALS", "LARGE PETALS"))) #PetalBins is now a derived column of the HIVE object > names(iris_table) [1] "Sepal.Length" "Sepal.Width" "Petal.Length" [4] "Petal.Width" "PetalBins" # Based on the bins, generate summary statistics for each group aggregate(iris_table$petal.length, by = list(petalbins = IRIS_TABLE$PetalBins), + FUN = summary) 1 LARGE PETALS MEDIUM LARGE PETALS MEDIUM PETALS SMALL PETALS Warning message: ORE object has no unique key - using random order 2014 Oracle All Rights Reserved

379 Notwendige Dinge, die niemand macht: Metadatenverwaltung im Data Warehouse 388

380 Informations-Repository Beispiele für Informations-Bedarfe Aufstellung zu allen ermittelten und formulierten Informationsanforderungen der Endbenutzer Abgestimmte, sachgebietsübergreifende Informationskataloge zu allen Tabellen und Spalten (bereinigt um Synonyme und Homonyme) Ein zusätzliches Klassifizierungsverfahren zum Verhindern von Synonymen und Homonymen Nachweis darüber, welcher Benutzer welche Daten nutzt Dokumentation der über Materialized Views aufgebauten Kennzahlen-Hierarchien -> Kennzahlenbäume Dokumentation aller Dimensionen sowie ihrer Hierarchien und die hierüber selektierbaren Felder Dokumentation der Kennzahlen in den Fakten-Tabellen Datenqualitätsregeln in dem Integration Layer mit Bezug zu den fachlichen Anforderungen Ein standardisierendes Schlagwortverzeichnis zu allen Fachbegriffen könnte noch hinzugefügt werden

381 Ein zentrales Metadaten-Repository für eine integrierte Informations-Verwaltung Business Process Modeling Logical Data Model Operative Prozesse Reporting Model (BI) Metadaten Repository Data Mapping Model (ETL) Mesures Model (Kennzahlenäume) Information-Standards (Glossars, Terms,Definitions) Organization Model Informaton Delivery Process Data Catalogue (Database) Data Quality Standards

382 Ein Meta-Information-Modell für das Data Warehouse

383 Metadaten Repository for Free Information Catalogue APEX - Anwendung

384 Die optimale Hardware für das Data Warehouse 393

385 Optimale ( Balanced ) Konfiguration Anzahl CPU s Größe des Hauptspeichers Anzahl Platten ~200 MB Datendurchsatz pro CPU Anzahl CPU = Max. Durchsatz in MB/s / 200 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 Anzahl Disk Controller = Controllerdurchsatz in MB = Max. Durchsatz in MB/s Controllerdurchsatz in MB 70% * Herstellerangaben in Gbit/s 8 394

386 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 395

387 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 396

388 Einfache Schätzmethode zur Lesegeschwindigkeit Blockgröße feststellen Anzahl Blöcke/ Anzahl Bytes 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 SELECT table_name, num_rows, blocks, blocks*8 KB,blocks*8/1000 MB,blocks*8/ GB FROM user_tables; TABLE_NAME NUM_ROWS BLOCKS KB MB GB BESTELLUNG_PART_RANGE ,84 7,69884 BESTELLUNG_PART_RANGE_ ,84 7,69884 Messen der Lesegeschwindigkeit Berechnung des Durchsatzes select count(*) from bestellung_part_range_4; -- liest komplette Tabelle COUNT(*) Abgelaufen: 00:00:31.32 select 7.7/31 from dual; SQL> 7.7/ , Ergibt ~0,25 GB pro Sekunde Lesegeschwindigkeit (Achtung Blöcke eventuell nicht voll, daher geringer ) 397

389 Calibrate_IO Einfaches Tool Bestandteil des Ressourcen Managers Wird aus der DB heraus aufgerufen SET SERVEROUTPUT ON DECLARE lat INTEGER; iops INTEGER; mbps INTEGER; BEGIN -- DBMS_RESOURCE_MANAGER.CALIBRATE_IO (<DISKS>, <MAX_LATENCY>, iops, mbps, lat); DBMS_RESOURCE_MANAGER.CALIBRATE_IO (2, 10, iops, mbps, lat); DBMS_OUTPUT.PUT_LINE ('max_iops = ' iops); DBMS_OUTPUT.PUT_LINE ('latency = ' lat); dbms_output.put_line('max_mbps = ' mbps); end; / max_iops = 73 latency = 12 max_mbps =

390 Orion (ORion IO Numbers) Physical Disks Luns Random small reads (8k) Random large reads (1M) Writes trace MBPS Orion IOPS lat orion -run simple -testname laufwerk -num_disks 6 orion -run advanced -testname ' laufwerk' -size_large num_large 1 -num_small 8 -type seq -num_disks 6 -num_streamio 2 (LUN: Logical Unit Number, logische Storage-Einheit, virtuelle Platte) Summary 399

391 Cluster-Einsatz 400

392 Oracle s Entwicklung für intelligenten Umgang mit Massendaten -> R8 R9 R10/11 R11 -> Rxx InMemory Parallel Execution RAC RAC RAC ASM ASM SAN SAN Oracle Storage / Exadata Oracle Storage / Exadata 401

393 Mit Leichtigkeit skalieren Lineare Skalierung jeweils bei Server und Storage Keine Änderung der Datenstrukturen Ohne Downtime Minimale Administration Faktor n Real Application Clusters Automatic Storage Management Oracle Clusterware Faktor n 402

394 Automatic Storage Management (ASM) Hotspot Dynamisches Zuschalten im Online-Betrieb 403

395 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 404

396 ASM Architektur ASM Disks 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 ASM Disk ASM Disk ASM Disk ASM Disk 405

397 Intelligent Data Placement Intelligent Placement Häufig genutzte Daten werden automatisch auf die äußeren Spuren der Platten gelegt Weniger häufige auf die inneren Minimiert Verwaltungsaufwand und steigert die Performance um bis zu 50 % Bereitstellung der Plattenkapazität nicht an dem benötigten Volumen messen sondern an der Performance Platten müssen nicht komplett gefüllt werden Mehr Daten erreichbar bei gleicher Drehzahl -> häufig genutzte Daten Weniger Daten erreichbar bei gleicher Drehzahl -> seltener genutzte Daten 406

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

399 Options: RAC Oracle Cluster-Umgebung Real Application Clusters und Automatic Storage Management Öffentliches Netzwerk RAC CPU CPU Privates Netzwerk (Interconnect) Knoten 1 Knoten 2 CPU CPU CPU CPU CPU CPU Instanz 1 Instanz 2 Oracle Clusterware Speichernetzwerk ASM 408

400 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 410

401 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 411

402 Monitoring Data Warehouse 412

403 Performance und Systemzustand überwachen / Hilfsmittel 2) Perfstat 1) Alerts 3) AWR (EE, Diagnostic Pack) analog Polling Beginn-Zeitpunkt Ende-Zeitpunkt ADDM (EE, Diagnostic Pack) SQL Tuning Tracing Permanente Betrachtung ASH Protokolldatei 413

404 Umgang mit Alerts Unvorhergesehene Vorgänge Statefull Alerts: Entstehen durch Überschreiten von Schwellwerten Stateless Alerts: Unvorhergesehene Vorgänge Z. B. zu wenig Recovery Area Space select metrics_name, warning_value, critical_value, object_type, object_name, status From dba_thresholds 414

405 Mit OEM 415

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

407 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 mit Awrrpt.sql OEM 417

408 Verwaltung von AWR Prozeduren MODIFY_SNAPSHOT_SETTINGS Rentention / Vorhaltezeit der Snapshots Interval / Zeitabstand zwischen den Snapshots Topnsql / Menge der erfassten SQL-Statements (Default 30/Typical) Feststellen der eingestellten Intervalle Select * from dba_hist_wr_control; Feststellen Oder V$SYSAUX_OCCUPANTS abfragen Select occupant_name, space_usage_kbytes from V$SYSAUX_OCCUPANTS where occupant_name = 'SM/AWR Auflistung der bestehenden Snapshots Select SNAP_ID, STARTUP_TIME, BEGIN_INTERVAL_TIME, END_INTERVAL_TIME, FLUSH_ELAPSED,SNAP_LEVEL from dba_hist_snapshot; 418

409 ADDM (Automatic Database Diagnostic Monitor) Automatic Database Diagnostic Monitor (ADDM) Gezielte Auswertung von AWR Daten Liefert Informationen zu Besonders teuere SQL-Statements I/O Performance Locking-Situationen Ressourcen-Engpässe (Speicher, CPU bottlenecks) Exzessive Logon/Logoff-Aktivitäten Manuelle Berichtserstellung: ADDMRPT.SQL 419

410 AWR über OEM modifizieren / einstellen 420

411 OEM Beispiel - Bericht 421

412 Automatic Database Diagnostic Monitor (ADDM) Läuft automatisch nach jedem AWR Snapshot Kann zusätzlich nach Alerts gestartet werden Bericht kann auf einen Zeitraum eingeschränkt werden Festlegen von Interval + Retention-Periode Aktivierung über Init-Parameter control_management_pack_access statistics_level SQL> Show parameter control_managem NAME TYPE VALUE control_management_pack_access string DIAGNOSTIC+TUNING SQL> show parameter statistics_ NAME TYPE VALUE statistics_level string TYPICAL 422

413 Art der Information Intelligente selbständige Analyse von Zuständen und Vorkommnissen in der DB Findings Basierend auf Erfahrungswerte und Best-Practises Sortiert nach der Schwere und dem Grad der Beeinflussung Recommendations Allgemeine Empfehlung mit einer Abschätzung über die prozentuale Gewichtung der Verbesserung der Situation (nn% benefits) Konkreter Action -Vorschlag Rationale Vorschlag: Sonstige, damit in Verbindung stehende Massnahmen. 425

414 Trace einer Session *** :08: ===================== PARSING IN CURSOR #1 len=62 dep=0 uid=0 oct=47 lid=0 tim= hv= 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= Identifizierung einer zu prüfenden Session *** :09: CLOSE #1:c=0,e=45,dep=0,type=0,tim= ===================== PARSING IN CURSOR #3 len=41 dep=0 uid=0 oct=3 lid=0 tim= hv= ad='34ab4260' sqlid='2b69gpx04v5tt' select count(*) from dwh.wh_transaktionen END OF STMT PARSE #3:c=0,e=63,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh= ,tim= EXEC #3:c=0,e=43,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh= ,tim= FETCH #3:c=0,e=792,p=0,cr=49,cu=0,mis=0,r=1,dep=0,og=1,plh= ,tim= 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= ,tim= *** :09: CLOSE #3:c=0,e=28,dep=0,type=0,tim= ===================== PARSING IN CURSOR #2 len=57 dep=0 uid=0 oct=47 lid=0 tim= hv= ad='34bc4a1c' sqlid='faaagm066mu1f' BEGIN dbms_monitor.session_trace_disable(135,181); END; END OF STMT select sid,serial#,terminal,program,module from v$session; 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); 426

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

416 DWH-bezogene Monitoring-Aktivitäten ASH-Report SQL-Monitoring (OEM) Informationsbedarf Endanwender Messung Platzverbrauch Lesestatistiken über tatsächlich genutzte Daten Ressourcen-Manager ETL-Monitoring 428

417 Beobachten des Informationsbedarfs Regelmäßige Teilnahme an Gremien Abstimmung / Feedback / Planung mit Fachabteilungen und DWH-Nutzern Statistiken über DWH-Nutzung Benutzerzahlen / Session-Statistik Datenmengen / Platzverbrauch Segment-Reads 432

418 Messung tatsächlich belegter Plattenplatz Häufig gibt es nur Zahlen über den allokierten Speicher Oft genannt von der Storage-Abteilung, die nicht in die Dateien hineinschauen kann Manchmal werden Zahlen genannt, die auch die gespiegelten Daten beinhalten oder den Backup-Storage umfassen Plattenplatz im DWH wird oft ähnlich organisiert wie Plattenplatz im OLTP-Umfeld Zu große Free-Space-Bereiche, obwohl die Zugänge zeitlich und mengenmäßig gut kalkulierbar sind Gibt kein realisitisches Bild über den tatsächlichen Bedarf und Kosten 433

419 Messung belegter Plattenplatz pro Tablespace Tablespace Name Filename FILE_ID FILESIZE USED Pct. Used DWH1 D:\ORA\ORADATA\ORCL\DWH1.DBF DWH1 D:\ORA\ORADATA\ORCL\DWH1_ DWH1 D:\ORA\ORADATA\ORCL\DWH1_ EXAMPLE D:\ORA\ORADATA\ORCL\EXAMPLE01.DBF PERFSTAT D:\ORA\ORADATA\ORCL\PERFSTAT01.DBF PERFSTAT D:\ORA\ORADATA\ORCL\PERFSTAT SYSAUX D:\ORA\ORADATA\ORCL\SYSAUX01.DBF SYSTEM D:\ORA\ORADATA\ORCL\SYSTEM01.DBF SELECT /*+ ordered */ 99 TEMP D:\ORA\ORADATA\ORCL\TEMP01.DBF d.tablespace_name TEST D:\ORA\ORADATA\ORCL\TEST.DBF TEST_ALERT D:\ORA\ORADATA\ORCL\TEST_ALERT.DBF TEST_ALERT D:\ORA\ORADATA\ORCL\TEST_ALERT UNDOTBS1 D:\ORA\ORADATA\ORCL\UNDOTBS01.DBF FROM 64 USERS D:\ORA\ORADATA\ORCL\USERS01.DBF , v$datafile v avg 62 sum SET LINESIZE 145 SET PAGESIZE 9999 SET VERIFY OFF COLUMN tablespace FORMAT a18 HEADING 'Tablespace Name' COLUMN filename FORMAT a50 HEADING 'Filename' COLUMN filesize FORMAT ,999,999,999 HEADING 'File Size' COLUMN used FORMAT ,999,999,999 HEADING 'Used (in bytes)' COLUMN pct_used FORMAT 999 HEADING 'Pct. Used BREAK ON report COMPUTE SUM OF filesize ON report COMPUTE SUM OF used ON report COMPUTE AVG OF pct_used ON report tablespace, d.file_name filename, d.file_id file_id, d.bytes filesize, NVL((d.bytes - s.bytes), d.bytes) used, TRUNC(((NVL((d.bytes - s.bytes), d.bytes)) / d.bytes) * 100) pct_used sys.dba_data_files d, ( select file_id, SUM(bytes) bytes from sys.dba_free_space GROUP BY file_id) s WHERE (s.file_id (+)= d.file_id) AND (d.file_name = v.name) UNION SELECT d.tablespace_name tablespace, d.file_name filename, d.file_id file_id, d.bytes filesize, NVL(t.bytes_cached, 0) used, TRUNC((t.bytes_cached / d.bytes) * 100) pct_used FROM sys.dba_temp_files d, v$temp_extent_pool t, v$tempfile v WHERE (t.file_id (+)= d.file_id) AND (d.file_id = v.file#) / 434

420 Einzelne Messungen -- total amount of allocated datafile size select sum(bytes)/1024/1024 "Meg" from dba_data_files; -- Size of all temp files select nvl(sum(bytes),0)/1024/1024 "Meg" from dba_temp_files; -- Size of on-line redo-logs select sum(bytes)/1024/1024 "Meg" from sys.v_$log; -- all together Datafile size, temp files, on-line redo-logs; select a.data_size+b.temp_size+c.redo_size "total_size" from ( select sum(bytes) data_size from dba_data_files ) a, ( select nvl(sum(bytes),0) temp_size from dba_temp_files ) b, ( select sum(bytes) redo_size from sys.v_$log ) c; 435

421 Einzelne Messungen -- freespace report col "Database Size" format a20 col "Free space" format a20 select round(sum(used.bytes) / 1024 / 1024 ) ' MB' "Database Size", round(free.p / 1024 / 1024) ' MB' "Free space" from (select bytes from v$datafile union all select bytes from v$tempfile union all select bytes from v$log) used, (select sum(bytes) as p from dba_free_space) free group by free.p / -- used space over all SELECT SUM(bytes)/1024/1024 "Meg" FROM dba_segments; -- used / free space in temp SELECT tablespace_name, SUM(bytes_used), SUM(bytes_free) FROM V$temp_space_header GROUP BY tablespace_name; 436

422 Einzelne Messungen -- true used / free space in temp SELECT A.tablespace_name tablespace, D.mb_total, SUM (A.used_blocks * D.block_size) / 1024 / 1024 mb_used, D.mb_total - SUM (A.used_blocks * D.block_size) / 1024 / 1024 mb_free FROM v$sort_segment A, ( SELECT B.name, C.block_size, SUM (C.bytes) / 1024 / 1024 mb_total FROM v$tablespace B, v$tempfile C WHERE B.ts#= C.ts# GROUP BY B.name, C.block_size ) D WHERE A.tablespace_name = D.name GROUP by A.tablespace_name, D.mb_total; 437

423 Welche Daten werden wirklich genutzt? Tabellen Tabellen Große Tabellen Partitioniert Namentlich bekannt > 70 % des Datenvolumens KleineTabellen Nicht Partitioniert Unkenntliche Masse < 30 % des Datenvolumens 438

424 Lesestatistiken für die wichtigsten Tabellen anlegen dba_hist. - Views zum Sammel der Lese-Zugriffe dba_hist_seg_stat dba_hist_seg_stat_obj dba_hist_snapshot Achtung: dba_hist_sqlstat dba_hist_sqltext Views werden nur aktualisiert wenn Auch tatsächlich gelesen wurde Ein AWR-Snapshot gezogen wurde Zähler fällt auf 0, wenn die DB durchgestartet wird Aufbau einer eigenen Statistik-Tabelle mit Tab-Name, Snap-ID, Datum/Uhrzeit, Physical Reads Aktualisieren immer nachdem ein AWR-Snapshot gezogen wurde 439

425 Lesestatistiken für die wichtigsten Tabellen anlegen 440 Select distinct * from (select to_char(begin_interval_time,'dd.mm.yyyy:hh24:mi') Zeit, logical_reads_total log_rd, logical_reads_delta log_rd_delta, physical_reads_total phy_rd, physical_reads_delta phy_rd_delta from dba_hist_seg_stat s, dba_hist_seg_stat_obj o, dba_hist_snapshot sn where o.owner = 'DWH1' and s.obj# = o.obj# and sn.snap_id = s.snap_id and object_name = 'UMSATZ') order by zeit; ZEIT LOG_RD LOG_RD_DELTA PHY_RD PHY_RD_DELTA :22: :23: :12: :15:

426 Zugriffsdaten auf Tabellen über SQL sammeln SQL-Statements pro User analysieren From-Klausel parsen Zugriffe auf Tabellen System-Zugriffe ausschließen Wegen der Menge Historien-Tabelle aufbauen Mit aus der FROM-Klausel herausgefilterten Tabellennamen Zuordnung zu USER, Zeit und SQL-Statement 441

427 Beispielabfrage select to_char(s.begin_interval_time,'mm-dd hh24') c1, sql.sql_id c2, t.sql_text C9, sql.executions_delta c3, sql.buffer_gets_delta c4, sql.disk_reads_delta c5, sql.iowait_delta c6, sql.apwait_delta c7, sql.ccwait_delta c8 from dba_hist_sqlstat sql, dba_hist_snapshot s, dba_hist_sqltext t where s.snap_id = sql.snap_id and sql.parsing_schema_name = 'DWH1' and t.sql_id = sql.sql_id and sql.sql_id = '01978kjxb5yd2' and to_char(s.begin_interval_time,'mm-dd hh24') = ' ' order by c1, c2; col c1 heading Begin Interval time format a8 col c2 heading SQL ID format a13 col c3 heading Exec Delta format 9,999 col c4 heading Buffer Gets Delta format 9,999 col c5 heading Disk Reads Delta format 9,999 col c6 heading IO Wait Delta format 9,999 col c7 heading Application Wait Delta format 9,999 col c8 heading Concurrency Wait Delta format 9,999 col c9 heading 'SQL-Text' format a50 break on c1 `Begin `Buffer `Disk Interval `SQL `Exec Gets time' ID' SQL-Text Delta' Delta' Delta kj Select * from (select Produkt, sum(u.summe)... AS Wert, 1 8,573 8, k2 Select * from (select Produkt, sum(u.summe)... AS Wert, 1 8,573 8, Auszug 442

428 Verwendungsinformationen speichern User Tabelle DWH-Zugriffshistorie Tabname Gelesen_Von_User Anzahl_Read_IO Lese_Datum 443

429 Aufgabenstellungen beim ETL-Monitoring Laufzeit-Kontrolle / ETL-Monitoring Gelesene/Geschriebene Sätze Ressource-Verbrauch (IO und Memory) Laufzeit Historischen Verlauf dokumentieren Trends ableiten Zuwachsmenge pro Tabelle Historischen Verlauf dokumentieren Mengen-Kontrolle Beobachtung des tatsächlichen Platzverbrauchs im DWH Alerts 444

430 Verbrauchsdaten sammeln Mess-Aufruf in der aktuellen ETL-Job-Session als letzten Aufruf einbauen Ergebnis-Daten in Historien-Tabelle eintragen SELECT /*+ use_nl (e s) ordered */ s.sql_id, s.plan_hash_value, to_char(s.hash_value), rawtohex(s.address), s.sql_text, s.disk_reads, s.buffer_gets, s.executions, s.sharable_mem, s.parsing_user_id, s.sorts, s.parse_calls, s.command_type, s.child_number, s.parsing_schema_id, s.rows_processed, e.username dbuser, u.name parsing_user, e.sid, s.module, s.action, s.open_versions, 1 current_set FROM v$session e, v$sql s, sys.user$ u WHERE s.address = e.sql_address AND s.hash_value = e.sql_hash_value AND s.child_number = e.sql_child_number AND u.type#!= 2 AND s.parsing_user_id = u.user# 445

431 Zusammenfassung

432 E x t e r n e I n t e r n e D a t e n Szenario DWH - Gesamtsicht OLTP Systeme Disk-Daten In Memory Integration Layer Temporäre Daten T T Referenzdaten Stammdaten Enterprise Layer Core - DWH / Info Pool R Partitionierte Transaktionsdaten nur wenn sie abgefragt werden R S S S Embedded Meta-Layer R Operational Data (virtuell) User View Layer (teils virtuell) Vorberechnete Kennzahlen C A MJ Q L JSON Unstructured JSON Data A Dimensionen als Views Fakten als In-Memory-Variante von Core-Transaktionen Kennzahlen-MAVs physikalisch R-Objekte physikalisch JSON-Objekte physikalisch JSON JSON Data Mining Statistikdaten HDFS / NoSQL Unstructured Data Oracle R

433 E x t e r n e I n t e r n e D a t e n SQL Szenario DWH - Gesamtsicht OLTP Systeme Disk-Daten In Memory Integration Layer Temporäre Daten T T SQL Referenzdaten Stammdaten Enterprise Layer Core - DWH / Info Pool R Partitionierte Transaktionsdaten nur wenn sie abgefragt werden R R S S S Embedded Meta-Layer Operational Data (virtuell) SQL User View Layer (teils virtuell) Vorberechnete Kennzahlen C A MJ Q L JSON Unstructured JSON Data A Dimensionen als Views Fakten als In-Memory-Variante von Core-Transaktionen Kennzahlen-MAVs physikalisch R-Objekte physikalisch JSON-Objekte physikalisch JSON JSON Data Mining Statistikdaten HDFS / NoSQL Unstructured Data Oracle R

434 449