<Insert Picture Here> Oracle Developer Day Data Warehouse Von Konzept bis Betrieb

Transkript

1 <Insert Picture Here> Oracle Developer Day Data Warehouse Von Konzept bis Betrieb Christoph Blessing / Detlef Schroeder / Alfred Schlaucher

2 Themen ODD Data Warehouse Konzept und Referenzarchitektur des Oracle Data Warehouse Das Data Warehouse modellieren Den ETL-Prozess entwerfen und generieren Datenqualität optimieren / Metadaten Wichtige Technologien in der Datenbank ROLAP / MOLAP Die richtige Hardware für das Data Warehouse Exadata Die Appliance für das Data Warehouse Unstrukturierte Daten und Big Data Advanced Analytics Maintenance 2

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

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

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

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

7 Data Integration Real Time & Batch Oracle Data Warehouse Architektur für unternehmensweites Datenmanagement Any Source BI Server Data Integration Layer Enterprise Information Layer Data Management Concept Operational Data Layer Data Quality Rules Checks&Monitoring Information Layer Architecture Concept Reference Data Models InDatabase Dynamic Data Marts User View Layer InDatabase ROLAP InDatabase MOLAP InDatabase R Data Mining BI Apps Controlling HR Sales Interactive Dashboards Reporting & Publishing Ad-hoc Analysis DWH Logistic Utilities Oracle Database Management System Big Data Solution Metadata Utilities Business Catalogue Technical Auditing Marketing Financial Scorecards nosql Server Server Cluster Cluster Operating System Optimized Network Hadoop Storage Hierarchy Optimiertes Netzwerk Exadata / Database Machine / Exalytics Big Data Exadata Appliance Exalytics Lifecycle Management Concept DWH System Monitoring Utilities DWH Security Utilities DWH Backup / Recovery Concept Concept Framework Office Integration Mobile

8 Regeln einer effizienten DWH-Architektur Orientierung an den Informationsbedürfnissen der Benutzer Granularisierte 3NF-DWH Schicht schafft Neutralität gegenüber Vorsystemen Flexibilität bei der Bereitstellung neuer Abfragemodelle Über Data Mart-Grenzen hinweg gemeinsam genutztze Berechnungen Aggregationen usw. so früh wie möglich umsetzen Zusammenhängende Data Mart-Schicht Mehrfachnutzung von Dimensionen Geschikter Umgang mit sehr großen Faktentabellen Eher granulare Informationen auch in den Fakten-Tabellen Alle Schichten in einem DB-Raum Ein zusammenhängender DB-Server-Cluster zum Verhindern unnötiger Wege

9 Stammdaten- Informationen Aktivitäten- Informationen: Was geschieht, Bewegungsdaten Stammdaten- Informationen Analysemodell Prozess-Sicht Was wissen wir über den Prozess? Bewegungsdaten Stamm-Objekte Eigenschaften Stammobjekte Zeit Kunde kauft Artikel + wird geliefert Ort 9

10 Objektmodell (Datensicht) Strukturierung und Beziehungen der Objekte Bewegungsdaten Stamm-Objekte Eigenschaften Stammobjekte Kunde Bestellung Sparte Jahr Region Kontaktperson KD#... tätigt Bestelldatum Lieferdatum... Status Externe Personen Monat Land Spezialisierung Status Generalisierung Tag Ort Privatkd... Firmenkd... Artikel... Name Gruppe Sparte Gruppe... Kandidaten für Dimensions-Hierarchien finden Schlüsselpaare PK / FK für spätere Fakten-Joins 10

11 Gesammelten Input zusammenfassen Entwürfe für multidimensionale Sichten Stammdaten Bewegungsdaten Generalisierung Spezialisierung Kandidaten für Dimensionen Kandidaten für Fakten Kandidaten für Hierarchie-Level potentielle Ausprägung 11

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

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

14 Spielarten des Star Schemas Lieferant Produkte Fakt Gelieferte Teile Bestellkosten Connect by Parent Teil von Zentrale Fakt- Tabelle Intersection- Table (Degenerated Fact) Verkäufer Verkaufsanteil Ort Kreis Verkäufer Fakt Umsatz Pro Verk. Heterogenious Fact Land Hierarchie Degenerate Facts Degenerate Dimensions Conforming Dimensions Factless Facts Slowly changing dimensions Zeit Drill Down Roll up Drill Across Slice / Dice Pivot 14

15 Spielarten des Star Schemas Teile Parent Teil von Benutzte Teile Produkte Sparte Gruppe Produkt Intersection- Table (Degenerated Fact) Verkäufer Verkaufsanteil Verkäufer Fakt Umsatz Pro Verkäufer. Fakt Gelieferte Teile Bestellkosten Verkauf Fakten Region Ort Kreis Land Region Heterogenious Fact Lieferant Zeit Connect by Degenerate Facts Degenerate Dimensions Conforming Dimensions Factless Facts Slowly changing dimensions Drill Down Roll up Drill Across Slice / Dice Pivot 15

16 Degenerated Dimension Produkte ProdNr Prodname Attribute von degenerated Dimensions Summe ProduktNr BestellNr. Vorgangsnr. KD.Nr KD.Name In der Regeln sind Attribute aus Dimensionen in die Faktentabelle aufgenommen worden, die eine 1:1- Beziehung zu den Faktensätzen haben oder die sehr häufig genutzt werden und man dabei den Join umgehen will. Zeit Bestellungen BestellNr Vorgangnr Kunden KD_Nr KD_Name 16

17 Factless Fact Table ZeitNr ProduktNr VerkauferNr Zeit ZeitNr Produkt ProduktNr Verkäufer VerkauferNr 17

18 Dimensionen Dim_Artikel Artikelsparte_Langname Levelschlüssel Levelschlüssel Levelschlüssel Artikelsparte Sparte Artikelgruppe_Langtext Artikelgruppe Artikel_Langtext Artikel Artikel_Schlüssel Parent Parent Fakten 18

19 19 Star vs. Snowflake Schema

20 Auslagern von Attributen Häufig oder weniger häufig genutzt Separate Dimension 20

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

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

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

24 ETL Oracle Data Warehouse 24

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

26 Der Sinn des 3-Schichten-Modells Aus Sicht des Ladeprozesses CRM ETL: Kosten pro Kunde Data Mart Staging Area Stage Warehouse Data Mart ERP ETL: Kosten pro Kunde! ETL: Kosten pro Kunde ETL: Kosten pro Kunde Data Mart 26

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

28 Generieren statt Programmieren Vorteile Vermindern von Fehlern durch Handprogrammierung Tabellen- und Spaltennamen müssen nicht mehr mühsam geschrieben werden Steuerung vieler Entwicklungsschritte durch Wizards Automatische Steuerung von Ziel- und Quellschemata Automatische Validierung (z.b. Typverträglichkeiten) Debugging der Laderoutinen Laufzeitumgebung steht bereit Dokumentation 28

29 Quellen und Ziele Oracle (Remote) Log Golden Gate DB2 OS390, UDB Sybase, Informix, SQL-Server... Access/Excel DataPump tcp Gateway Streams CDC Oracle Database SAP MessageBroker Peoplesoft Siebel Webservices Flat File XML ODBC Adapter SQL Loader JDBC PL/SQL DB-Link Queue Ext. Table Tabellen View Index XML Procedure MView Agent Sequenz Cube Function UTL_FILE XML DB-Link Queue Queue

30 OWB Architektur Oracle 10g /11.1/11.2 OWBSYS-Schema OWB11.2 WindowsXP, Vista, 7 oder Linux Metadaten Workspace OWB112 Control Center Service generiert Oracle 10g /11.1/11.2 (Warehouse-Datenbank) Remote DB (Source DB) DWH-Zielschema PL/SQL Control Center Agent OLTP-Quellschema Datentransfer DB Link Warehouse tabellen Warehouse tabellen Tabellen

31 Der Mapping-Editor

32 Graphik und SQL

33 Graphik und SQL Call Filter Distinct PL/SQL Multiple Insert Multiple Targets Text Files MINUS Merge External Table Table Function Lookup XML UNION

34 Metadaten-Dependency-Manager

35 E-LT Architecture with ODI-EE High Performance, Flexible, Lightweight Architecture Key Architecture Benefits: 100% Java, Open APIs, fast E-LT Packaged Application ODI Agent Business Intelligence & Data Warehouse ODI Agent may be deployed in any part of the architecture JKM A B LKM C$_0 IKM D File C RKM LKM C$_1 I$ E$ (Errors) IKM CKM Extract-Load Transform Check-Load

36 Wer glaubt schon bunten Charts?

37 Ohne Daten kein Business Schlechte Daten sind wie Sand im Getriebe der Geschäftsprozesse Marketing Werbung Information Chain Adresse Kunde Bedarf Adresse Kreditdaten Angebot Kundenbetreuer KD-Daten Kredit OK Bestelldaten Bestand Stammdaten Logistiksystem Order Verkaufsdaten Lager Buchhaltung Lieferschein Rechnung Mahnung Bezahlung Reklamation Spedition Kunde Operative Prozesse

38 Wo sollten Korrekturen stattfinden Correction Operative Anwendung Data Load Data Warehouse Vorsysteme bzw. Fachabteilungen sind in der Pflicht!

39 Wo sollten Korrekturen stattfinden Operative Anwendung? Correction Data Warehouse Operative Anwendung Data Load Operative Anwendung

40 Warum wächst die Herausforderung der Qualität der Daten Gewachsene Bedeutung des Faktors Information für den Erfolg von Unternehmen. Ausufernde Datenmengen Datenqualität Fehlende Praxis in Datenmanagement Immer häufigere Prozessänderungen Vermehrtes Inseltum durch Fertig- Anwendungen

41 Was ist Datenqualität? Aspekte (Dimensionen) der Datenqualität Brauchbarkeit der Daten! 1. Korrekt 2. Stimmig 3. Vollständig 4. Dokumentiert 5. Redundanzfrei 6. Aktuell 7. Verfügbar (Access) 8. Nützlich (TCO) 9. Handhabbar 10.Vertrauenswürdig 11.Harmonisch

42 Methoden und Hilfsmittel Vorgehensmodell Datenmodellierung Datenqualitätsprüfmethoden Data Profiling Data Profiling Tool Attribut-Klassifizierung (Namen) Kategorisierung von Qualitätsregeln ETL-Tool Datenbank

43 Top Down Vorgehensmodell Datenqualitätsanalyse Zieldefinition Erwartungen Geschäftsregeln Bestandsaufnahme Owner User Ressourcen Kosten Modelle Priorisieren Felder Planen Strukturanalysen Regelanalysen Umsetzung Ergebnisse Problemkomplexe Objekte Beziehungen Hierarchien Daten Werte Fach Abgleich-Alt Neudefinition Monitoring Bottom Up 6 Phasen, 95 Aktivitäten, 16 Ergebnis-Templates, 1 Metamodell, Klassifizierungen

44 Starten eines Profiling-Laufs Generierung- Rule Starten einer Correction- Mapping-Generierung Die Tabellen, die zu dem Analyse- fukus gehören Feintuning zu den Analyse- methoden Tabellen-Darstellung Chart-Darstellung Drill-Werte Auswahl und Ergebnisansicht Methoden Operative Datensätze Analyse- Job- Protokolle Aktivierbare Business Rules

45 Informations-Repository Aufstellung zu allen ermittelten und formulierten Informationsanforderungen der Endbenutzer Informationskataloge zu den Tabellen und Spalten der zentralen Warehouse-Schicht 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 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 Ein Schlagwortverzeichnis könnte noch hinzugefügt werden

46

47 Agenda Oracle Partitioning Compression Indizes Star Query Transformation Parallelisierung Result Cache Materialized Views Analytische Funktionen Oracle OLAP/ Cube-organized Materialized Views

48 Oracle Partitioning Oracle Data Warehouse 49

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

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

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

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

53 Range Partitioning Partitionierung nach Wertebereichen Partitionierung nach Wertebereichen Für sortierte Wertebereiche LESS THAN: Angabe eines maximalen Wertes pro Partition CREATE TABLE orders ( order_no number, part_no varchar2(40), ord_date date ) PARTITION BY RANGE (ord_date) ( 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

54 Range Partitioning Neue Tabellenzeilen Partition für neue Tabellenzeile muss vorhanden sein FEHLER in Zeile 1: ORA-14400: Eingefügter Partitionsschlüssel kann keiner Partition zugeordnet werden Lösung I: MAXVALUE-Partition Lösung II: Eigene Jobs Lösung III: Oracle11g 55

55 Range Partitioning Alphabetische Sortierung in den Partitionen CREATE TABLE kunde_part_alpha ( kundennummer NUMBER, vorname kundenname ) VARCHAR2(20), VARCHAR2(40) PARTITION BY RANGE (kundenname) ( PARTITION kunde_ae VALUES LESS THAN ('F%') PARTITION kunde_fl VALUES LESS THAN ('M%') PARTITION kunde_mr VALUES LESS THAN ('S%') TABLESPACE part_range1, TABLESPACE part_range2, TABLESPACE part_range3, PARTITION kunde_sz VALUES LESS THAN (MAXVALUE) TABLESPACE part_range4 ); 56

56 Hash Partitioning Gleichverteilung der Daten Partitionierung nach Hash-Funktion Schlüsseltypen: Alle built-in Datentypen außer ROWID, LONG, LOB Ziel: Gleichverteilung der Daten Anzahl Partitionen: als Potenz von 2 empfohlen CREATE TABLE orders ( order_no number, part_no varchar2(40), ord_date date ) PARTITION BY HASH (ord_date) PARTITIONS 4 57

57 Hash Partitioning CREATE TABLE bestellung_part_hash ( bestellnr NUMBER(10) NOT NULL, kundencode NUMBER(10), bestelldatum DATE, lieferdatum DATE, bestell_total NUMBER(12,2), auftragsart VARCHAR2(30), vertriebskanal NUMBER ) PARTITION BY HASH (bestellnr) PARTITIONS 8; 58

58 List Partitioning AMER Für diskrete, unsortierte Werte Angabe einer Werteliste pro Partition VALUES (DEFAULT) für alles andere Verhalten wie MAXVALUE in der Range-Partitionierung 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) ) 59

59 Partition Pruning Wie hoch waren die Verkäufe für das Wochenende vom Mai 2008? Sales Table May 18 th 2008 May 19 th 2008 SELECT sum(sales_amount) FROM sales WHERE sales_date BETWEEN to_date( 05/20/2008, MM/DD/YYYY ) AND to_date( 05/23/2008, MM/DD/YYYY ); Nur die 3 relevanten Partitionen werden betrachtet May 20 th 2008 May 21 st 2008 May 22 nd 2008 May 23 rd 2008 May 24 th

60 Partitionwise Join Sind beide am Join beteiligten Tabellen partitioniert, erfolgt Eine Portionierung der Abfragemenge Parallelisierung Full partitionwise Join Gleiche Partitionierungsmethode Gleicher Partitionierungsschlüssel Partial partitionwise Join Nur eine der beteiligten Tabellen ist partioniert Die andere Tabelle wird durch das System dynamisch partitioniert Der Cost Based Optimizer entscheidet über die Vorgehensweise 61

61 Interval Partitioning Erweiterung der Range-Partitionierung Volle Automatisierung für gleichgroße Range-Partitionen Partitionierung wird als Metadaten-Information abgelegt Start-Partition ist dabei persistent Sobald neue Daten hinzukommen werden Segmente allokiert Lokale Indizes werden automatisch mitgepflegt 62

62 Interval Partition automatisch angelegt Mai Maidaten? April Aprildaten April März Märzdaten März Februar Januar Februardaten Januardaten Februar Januar Produkte Kunden 63

63 Interval Partitioning Syntax CREATE TABLE "BESTELLUNG" ( "BESTELLNR" NUMBER(10) NOT NULL, "KUNDENCODE" NUMBER(10), "BESTELLDATUM" DATE, "LIEFERDATUM" DATE, "BESTELL_TOTAL" NUMBER(12, 2), "AUFTRAGSART" VARCHAR2(30), "ORDER_ID" NUMBER ) 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", PARTITION "Feb07" VALUES LESS THAN (TO_DATE(' :00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN')) TABLESPACE "TS_PAR" ) ; 64

64 Reference Partitioning FK FK Child Tables mussten bisher die Spalte mit dem Partitioning Key mitführen, um so wie die Parent Table partitioniert zu werden Jetzt erfolgt das Equi-Partitioning von Child Tables über den Foreign Key Erspart Redundanz beim Speichern Vereinfacht die Administration Nicht für Interval Partitioning anwendbar 65

65 Reference Partitioning PK BestellNr KundenNr April BestellDatum FK PK BestellNr ArtikelNr Menge PosNr März Februar Januar Bestellungen April März Februar Januar Bestell_Positionen FK BestellNr LieferNr April März Februar Januar PosNr Auslieferungen 66

66 Sub- und Composite Partitioning Oracle Data Warehouse 67

67 Composite Partitioning Range... Range - Range [Oracle11g] Range - Hash [Oracle8i] Range - List [Oracle9iR2] 1st Level: Interval Partitioning möglich List... List - Range [Oracle11g] List - Hash [Oracle11g] List - List [Oracle11g] 2nd Level: Interval Partitioning nicht möglich 68

68 Composite Partitioning Kombinationen: Ein Beispiel für Range - List JAN 07 FEB 07 MAR 07 Produkt Service Storno 69

69 ...Und zu guter Letzt: Partition Advisor Erweiterung des SQL Access Advisors Partitionierung von nicht-partitionierten Materialized Views, Tabellen und Indizes Generierung von ausführbaren Skripts Nutzung via EM Tuning Pack Package DBMS_ADVISOR 70

70 Maintenance und Reorganisation ADD PARTITION DROP PARTITION TRUNCATE PARTITION MOVE PARTITION SPLIT PARTITION MERGE PARTITION COALESCE PARTITION (Hash Partition / Index) EXCHANGE PARTITION Verändern der Default-/ realen Attribute Partition Exchange Loading 71

71 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 Parallel Direct Path INSERT (Set Based) CREATE TABLE AS SELECT (CTAS) CREATE Indizes / Statistiken anlegen EXCHANGE Tabelle Unvergleichbar schnell! Monat 12 Monat 11 Monat 10 DROP PARTITION Faktentabelle Region 72

72 Information Lifecycle Management Rolling Window Operationen Ganze Partitionen löschen ALTER TABLE DROP PARTITION Partitionen verschieben ALTER TABLE MOVE PARTITION Oder: DBMS_REDEFINITION Tablespaces mit einzelnen Partitionen READ ONLY setzen Komprimieren Verschlüsseln (TDE) Jan 2008 Feb 2008 Mar 2008 Apr 2008 May 2008 Jun 2008 : Jan

73 Information Lifecycle Management (ILM) Mit Partitionierung und Storage Layern Für die Anwendung sind die Daten eine Tabelle Unterschiedliche Bereiche auf unterschiedlichen Storages Bedarfsgerechte Performance und Kosten Disk Group (DG) "High Perf " DG "Standard" DG "Historic" High End Storage Midrange Storage Entry Level Storage 74

74 Einsatz von Compression Oracle Data Warehouse 75

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

76 Anwendung für Komprimierung Nicht nur für Indizes Strukturierte Daten in Tabellen (bzw. Partitionen) mit DIRECT Load Mit Advanced Compression auch für Unstrukturierte Datentypen (SecureFiles) Konventionelles DML (OLTP Compression) DataPump Daten und RMAN Redo Traffic mit Data Guard Redo Logs Standby Backups 77

77 Advanced Compression in Oracle 11g Overhead Free Space Uncompressed Compressed Inserts are again uncompressed Block usage reaches PCTFREE triggers Compression Inserts are uncompressed Block usage reaches PCTFREE triggers Compression 78

78 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: 79

79 Schlüssel im DWH und Indizierung Oracle Data Warehouse 80

80 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 81

81 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 Neuer Schlüssel 82 Sequence

82 Indizes in Oracle Indexarten B*Tree Index Index organisierte Tabellen Cluster Index Reverse Key Index Descending Index Bitmap Index Bitmap Join Index Function based Index Textindex Hash Index Ausprägungen Invisible Indizes Lokale / Globale Indizes

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

84 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

85 Bitmap Index Zusammengesetzte Schlüssel sind ungünstiger als einzelne Bitmap-Schlüssel Langsamer zu verarbeiten Können nicht komprimiert werden Bei Änderungsoperationen an der Tabelle kann es zu Overflow-Operationen im Bitmap Index kommen Änderungen werden z.t. an anderer Stelle der Platte gespeichert 86

86 Platzverbrauch im Vergleich Tests mit unterschiedlicher Kardinalität CREATE TABLE I_Kunde (KD_NR Name Geb_Dat Bildungsgruppe KR_Rating_1_bis_Variabel number, varchar2(30), date, varchar2(30), number); 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_Variabe KD_NR

87 Rebuild Index Operation ALTER INDEX index_name REBUILD [ NOLOGGING ]; Schneller als DROP / CREATE NOLOGGING-Klausel Fragmentierung wird beseitigt Nach Änderungsaktivitäten Freien Platz richtig freigegeben Im DWH werden Änderungen aber oft als Batch-Lauf durchgeführt Zunächst DROP INDEX (beschleunigt den Batch-Lauf) Dann Neuerstellen des Index Usage-Monitor zeigt, ob ein Index wirklich genutzt wurde alter index PK_BESTELLNR_PART_RANGE_HASH monitoring usage SELECT INDEX_NAME, TABLE_NAME, MONITORING, USED FROM SYS.V$OBJECT_USAGE 88

88 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 Bitmap Join B*tree für Primary Keys In den Dimensionen Tabellen

89 Physische Strukturen im Star Schema Data Mart-Schicht Dimensionsobjekt Dimensionsobjekt Reg Zeit PK Constraint Primary Key Constraint Komprimiert Partitioniert Lokale Indizes Security Verschlüsselung Foreign Key (NOT NULL) Bitmap-Index Dimensionsobjekt Org. Linie PK Constraint Prod Dimensionsobjekt PK Constraint 90

90 F_UMSATZ ARTIKEL_ID ZEIT_ID KUNDE_ID REGION_ID UMSATZ MENGE BESTELL_DATUM Bitmap D_REGION REGION_ID ORT_ID ORT_NAME KREIS_ID KREIS_NUMMER KREIS_NAME LAND_NAME LAND_ID LAND_NUMMER REGION_NAME REGION_NUMMER D_ZEIT DATUM_DESC TAG_DES_MONATS WOCHE_DES_JAHRES JAHR_NUMMER QUARTALS_NUMMER MONATS_NUMMER MONAT_DESC DATUM_ID F_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 STATUS BERUFSGRUPPEN_NR BILDUNGS_NR EINKOMMENS_NR WOHNART_NR PLZ ORT B*Tree PK PK PK PK Potentiell Bitmap Potentiell B*Tree Schlüsselverteilung im Star FKs 91

91 Star Query Transformation Oracle Data Warehouse 92

92 Star Query Transformation Optimierung für Joins mit großen Faktentabellen SELECT sum(summe) FROM F_Bestellungen B, D_Artikel A, D_Region R, D_Zeit Z, D_Kunde K WHERE B.FK_Kunden_ID AND B.FK_Datum_ID AND B.FK_Ort_ID AND B.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'); 93

93 STAR_TRANSFORMATION_ENABLED=FALSE; Abgelaufen: 00:00:03.48 Ausführungsplan Plan hash value: 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_BESTELLUNGEN 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:

94 95 STAR_TRANSFORMATION_ENABLED=TRUE; Abgelaufen: 00:00:00.76 Ausführungsplan Plan hash value: Id Operation Name Rows Bytes Cost (%CPU) Time SELECT STATEMENT (2) 00:00:03 1 SORT AGGREGATE TABLE ACCESS BY INDEX ROWID F_BESTELLUNGEN (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

95 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 101

96 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 102

97 Parallelisierung Oracle Data Warehouse 103

98 Parallelisierung und Skalierung Abfragen SELECT JOIN-Operationen seriell SQL 100% CPU I/O SORT-Operationen GROUP BY 50% DDL CREATE TABLE / MV CREATE INDEX Online Index Rebuild parallel SQL 100% 50% CPU I/O DML INSERT UPDATE / DELETE MOVE / SPLIT PARTITION Ein SQL Statement wird vom Optimizer in kleinere Arbeitsschritte aufgeteilt und läuft skalierbar ab. 104

99 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 105

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

101 Kontrolle über Parallelisierung behalten Parameter PARALLEL_DEGREE_POLICY Manual Verhalten wie vor 11gR2, der DBA konfiguriert alles manuell Kein Automated DOP Kein Statement Queuing Keine In-Memory Parallel Execution Limited Eingeschränkter Automated DOP für Abfragen auf Tabellen mit Default Parallelisierung Kein Statement Queuing Keine In-Memory Parallel Execution Auto Alle in Frage kommenden Statements werden parallel ausgeführt Statement Queuing In-Memory Parallel Execution 107

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

103 Parallel Statement Queuing SQL Monitoring im Enterprise Manager Klicken auf SQL ID für weitere Informationen Uhrsymbol zeigt ein wartendes Statement an Awaiting screen shot from EM 109

104 Query Result Cache Oracle Data Warehouse 110

105 Situation im Datawarehouse Lang andauernde, teure Abfragen Sich wiederholende Abfragen Rechenintensive PL/SQL Funktionen Randbedingungen Abfragen mit kleinen Ergebnismengen Zusätzliches Memory steht zur Verfügung Tabellen sind relativ statisch Ziel: SQL Performance mit möglichst einfachen Mitteln erhöhen

106 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 112

107 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

108 Parameter zum Result Cache RESULT_CACHE_MAX_RESULT 5 (%) RESULT_CACHE_MAX_SIZE abhängig vom OS RESULT_CACHE_MODE MANUAL/FORCE RESULT_CACHE_REMOTE_EXPIRATION 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 114

109 Tipps zum Einsatz von Result Cache Sinnvoll bei Zumeist statischem SQL Häufiger Read Only -Nutzung (nur wenige Invalidierungen) Rechenintensiven (teuren) Operationen FORCE-Einstellung Wirkt auf alle SQL-Statements: wird genutzt, wenn keine Änderung am SQL möglich ist Ausnahmen mit Hint /*+ NO_RESULT_CACHE */ Detailliertes Monitoring: V$RESULT_CACHE_OBJECTS Speicher anpassen mit RESULT_CACHE_MAX_SIZE Siehe auch DBA Community Tipp:

110 Materialized Views Oracle Data Warehouse 116

111 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 117

112 Ähnlichkeit von Result Cache und MAVs Result Cache Nutzung des Result Cache für Ergebnisse aus SQL-Abfragen und PL/SQL-Funktionen Automatisches Refresh nach Datenänderungen Eigener Speicherbereich im Shared Pool Wirkt wie eine just-in-time Materialized View Materialized Views Nutzung für häufig erfragte Ergebnisse (Summen, Joins etc.) Mehrere Refresh-Methoden bei Datenänderungen Speicherung auf Disk Caching von speziellen Ergebnissen (transparentes Rewrite) 118

113 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; 119

114 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.) 120

115 Skalierung bei der Auswertung Architekturbasierte Anwendergruppen-Unterstützung. Reg Detaillevel 0 Zeit Aggregationslevel 1 Aggregationslevel 2 Top Management (wenige hochverdichtete Kennzahlen) MAV MAV MAV MAV MAV. Sachmitarbeiter Planung / Marketing (verdichtete Daten)..... Org. Linie Prod Aggregat Summentabelle Summentabelle (Meier) Summentabelle (Müller) Mitarbeiter operative Ebene (Detaildaten auf dem Level von operativen Transaktionen) 121

116 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; 122

117 Materialized Views Query Rewrite Oracle Data Warehouse 123

118 Text Match 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 124

119 Exaktes Text-Matching 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; Umstellen der Spalten und avg() anstelle von sum() 125 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 F_ARTIKEL SPARTE_NAME SPARTE_NR GRUPPE_NAME GRUPPE_NR ARTIKEL_NAME ARTIKEL_ID

120 Ableitung von Aggregaten Wenn gebraucht Voraussetzung Optional COUNT(expr) - - MIN(expr) MAX(expr) SUM(expr) COUNT(expr) - SUM(col), col has NOT NULL constraint - AVG(expr) COUNT(expr) SUM(expr) STDDEV(expr) COUNT(expr) SUM(expr * expr) SUM(expr) VARIANCE(expr) COUNT(expr) SUM(expr * expr) SUM(expr) 126

121 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 127 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 F_ARTIKEL SPARTE_NAME SPARTE_NR GRUPPE_NAME GRUPPE_NR ARTIKEL_NAME ARTIKEL_ID

122 Join Back-Methode SELECT FROM z.jahr_nummer Jahr, z.monat_desc Monat, a.artikel_name Artikel, sum(u.umsatz) Summe Ist nicht in der MAV-Definition enthalten 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 128 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 F_ARTIKEL SPARTE_NAME SPARTE_NR GRUPPE_NAME GRUPPE_NR ARTIKEL_NAME ARTIKEL_ID

123 Materialized Views im Detail Verwaltung Oracle Data Warehouse 129

124 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 130

125 EXPLAIN_MVIEW-Routine Zeigt auf, welche Funktionen für eine 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'); 131

126 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 132

127 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) 133

128 EXPLAIN_REWRITE-Routine MAV-Definition 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 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; 134 MV_UMS_ART_ZEIT_JOIN QSM-01082: Materialized View, MV_UMS_ART_ZEIT_JOIN, kann nicht mit Tabelle, F_UMSATZ, verknpft werden MV_UMS_ART_ZEIT_JOIN QSM-01102: Materialized View, MV_UMS_ART_ZEIT_JOIN, erfordert Join zurck zu Tabelle, F_UMSATZ, in Spalte, UMSATZ

129 Analytische Funktionen im SQL Oracle Data Warehouse 135

130 Analytische Funktionen Seit Oracle dabei Speziell für analytische Aufgaben wie: BI-Applikationen, Berichte, Ad-Hoc-Abfragen Sind ANSI Standard SQL-konform (SQL-99) Bieten erweiterte Abfrage-Performance Verarbeitung ist effizient und skalierbar Kann Verarbeitungslast der Anwendungen entlasten 136

131 Welche Antworten man von analytischen Funktionen erwarten kann Welches sind die Top 10 Kundenberater in jeder Region? Welches sind die 90-Tage-Durchschnitte der Produktbestände? Welchen Prozentsatz vom Jahres-Total machen die Dezember-Verkäufe aus? Welchen Rang hat ein Produkt, das für verkauft worden ist, verglichen mit anderen in seiner Kategorie? Welches ist der Median von den Verkäufen pro Produkt und Region? 137

132 Arbeitsweise analytischer Funktionen Analytische Funktionen berechnen einen aggregierten Wert basierend auf einer Gruppe (Partition / Window) von Zeilen Syntax: FUNCTION_NAME (<arg>,<arg>...)over (<partition clause><order by clause><windowing clause>) Ausführungsablauf: JOIN, WHERE, GROUP BY, HAVING Partitionen erzeugen, Funktionen auf Partionen anwenden ORDER BY 138

133 Favoriten: Beliebte Funktionen LAG / LEAD: Vorgänger und Nachfolger ohne SELF-JOIN FIRST / LAST oder MIN / MAX ROW_NUMBER: vergibt eindeutige Zahl, z.b. für TOP-N RANK, DENSE_RANK: Rangfolge RATIO_TO_REPORT: Verhältnis zur Summe Aggregatfunktionen wie AVG, SUM NTILE: Aufteilung in sog. Buckets PERCENTILE_CONT/_DISC: zur Berechnung des Median 139

134 Beispiel für analytische Funktionen Finde das höchste Gehalt in jeder Abteilung und gib die Liste der Gehälter der zugehörigen Angestellten aus 1.Schritt: SELECT department_id, MAX(salary) FROM employees GROUP BY department_id 2.Schritt: und für die Angestellten noch eine Subquery (korreliert?).. 140

135 Einfache Anwendung... SELECT department_id dept, first_name ' ' last_name name, salary FROM (SELECT department_id, first_name, last_name, MAX(salary) OVER (PARTITION BY department_id) dept_max_sal, salary FROM employees e) WHERE salary = dept_max_sal; DEPT NAME SALARY Jennifer Whalen Michael Hartstein Den Raphaely

136 ...Und hohe Flexibilität Doch eigentlich interessiert das höchste Gehalt je Job... SQL> SELECT job_id job, first_name ' ' last_name name, salary FROM (SELECT job_id, first_name, last_name, MAX(salary) OVER (PARTITION BY job_id) job_max_sal, salary FROM employees e) WHERE salary = job_max_sal; JOB NAME SALARY AC_ACCOUNT William Gietz 8300 AC_MGR Shelley Higgins AD_ASST Jennifer Whalen 4400 AD_PRES Steven King

137 Zusätzliche Funktionalitäten Sortierung innerhalb einer Partition Ohne Angabe der Partition-Klausel wird auf der gesamten Menge gearbeitet Jede analytische Funktion kann ihre eigene Partition- Klausel haben Windowing-Klausel für Teiloperationen in einer Partition Physikalische Rows: Anzahl, von Vorgänger bis Nachfolger etc. Logische Wertebereiche (Ranges) 143

138 Abfrage der Top 10 Artikel Zeit Artikelgruppe Artikel- Sparte Dimension Artikel Artikel Umsatz Top 10 Artikel SELECT * FROM (SELECT substr(a.artikel_name, 1, 15), SUM(U.umsatz) AS Wert, Region RANK() OVER (ORDER BY SUM(U.umsatz) Kunde DESC ) AS Rangfolge FROM f_umsatz U, d_artikel A WHERE U.artikel_ID = A.artikel_ID GROUP BY A.Artikel_Name) WHERE rownum < 11; 144

139 Abfrage Top 3 Artikel pro Artikelgruppe Zeit Artikelgruppe Artikel- Sparte Dimension Artikel Artikel Umsatz Top 3 Artikel pro Gruppe SELECT substr(artikel,1,25) AS Artikel, substr(artikelgruppe,1,25) AS Artikelgruppe, Wert, Rangfolge FROM (SELECT Artikel, Artikelgruppe, SUM(U.umsatz) AS Wert, RANK() OVER Region (PARTITION BY A.Artikelgruppe ORDER BY SUM(U.umsatz) DESC) AS Rangfolge Kunde FROM f_umsatz U, dim_artikel A WHERE U.artikel_ID = A.artikel_ID GROUP BY A.Artikelgruppe, A.Artikel ORDER BY A.Artikelgruppe) WHERE Rangfolge < 4; 145

140 Zeit Über Quartale kumulierte Umsätze Pro Kunde Jahr Quartal Q1_2003 Q4_2002 Q3_2002 Q2_2002 Q1_2002 Name Dimension Kunde Region Umsatz SELECT substr(k.kunden_name, 1, 25) AS kunde, Z.jahr, Z.quartal_des_jahr AS Quartal, SUM(U.umsatz) AS Umsatz, SUM(SUM(U.umsatz)) OVER (PARTITION BY K.kunden_Name ORDER BY K.kunden_Name, Z.jahr, Z.quartal_des_jahr ROWS UNBOUNDED PRECEDING) AS Umsatz_Summe FROM dim_kunde K, f_umsatz U, dim_zeit Z Kunde WHERE K.kunde_id = U.kunde_id AND to_char(z.datum) = to_char(u.datum) GROUP BY K.kunden_Name, Z.jahr, Z.quartal_des_jahr; 146

141 ¼ der Kunden tragen zu wieviel Prozent des Umsatzes bei? Zeit Buckets Name Dimension Kunde 4 Region Umsatz 1 2 SELECT SUM(umsatz), anteil, (SUM(umsatz) * 100 / Gesamt_umsatz) AS Prozent FROM (SELECT substr(k.nachname, 1, 25) AS kunde, SUM(U.umsatz) AS Umsatz, NTILE(4) OVER (ORDER BY sum(u.umsatz)) AS Anteil Kunde FROM d_kunde K, f_umsatz U WHERE K.kunden_id = U.kunde_id GROUP BY K.nachname), (SELECT SUM(U.umsatz) AS Gesamt_Umsatz FROM f_umsatz U) GROUP BY anteil, Gesamt_umsatz; 147

142 Zeit Durchschnittliche Bestellquote eines Kunden über 3 Monate Jahr Monat M5_2002 M4_2002 M3_2002 M2_2002 M1_2002 Name Dimension Kunde Region Umsatz SELECT substr(k.kunden_name,1,25) AS kunde, Z.jahr AS Jahr, Monat_des_jahres AS Mon, SUM(u.umsatz) AS Umsatz, AVG(SUM(u.umsatz)) OVER (ORDER BY K.kunden_Name, Z.jahr, Z.Monat_des_jahres ROWS 2 PRECEDING) AS Mov_3M_AVG FROM dim_kunde K, f_umsatz U, dim_zeit Z WHERE K.kunde_id = U.kunde_id AND to_char(z.datum) = to_char(u.datum) Kunde AND K.kunden_name = 'Bauer' GROUP BY K.kunden_Name, Z.jahr, Z.Monat_des_jahres ORDER BY Z.jahr, Z.Monat_des_jahres; 148

143 Das Bundesland mit dem stärksten Umsatz für jede Artikelgruppe Region Bundesland Artikelgruppe Dimension Artikel Region Ort Artikel Region Kreis Umsatz SELECT ArtGr, Land, Umsatz FROM (SELECT Artikelgruppe AS ArtGr, Bundesland AS Land, SUM(umsatz)AS Umsatz, MAX(SUM(umsatz)) OVER (PARTITION BY Artikelgruppe) AS Max_Ums_Land FROM dim_region R, dim_artikel A, f_umsatz U WHERE R.ort_ID = U.ort_ID AND A.Artikel_ID = U.artikel_ID GROUP BY Artikelgruppe, Bundesland ORDER BY Artikelgruppe, Bundesland) WHERE Umsatz = Max_Ums_Land ; 149

144 Vergleiche Umsätze mit Vorjahreszeitraum Zeit Jahr M2_2003 M1_2003 M12_2002 M11_2002 M10_2002 M9_2002 M8_2002 M7_2002 M6_2002 M5_2002 M4_2002 M3_2002 M2_2002 M1_2002 Name Dimension Kunde 150 Region Monat Umsatz SELECT substr(k.kunden_name,1,25) AS kunde, z.jahr AS Jahr, Monat_des_jahres AS Mon, SUM(U.umsatz) AS Umsatz, LAG(SUM(U.umsatz),12) OVER (ORDER BY Z.jahr, Z.Monat_des_jahres) AS vorjahr FROM dim_kunde Kunde K, f_umsatz U, dim_zeit Z WHERE K.kunde_id = U.kunde_id AND to_char(z.datum) = to_char(u.datum) AND K.kunden_name = 'Bauer' GROUP BY K.kunden_Name, Z.jahr, z.monat_des_jahres ORDER BY z.jahr, z.monat_des_jahres;

145 Eine der SQL-Neuigkeiten in 11.2 Die LISTAGG-Funktion aggregiert VARCHAR2 Neue Aggregatsfunktion für Zeichenketten Beispiel (Tabelle EMP): select deptno, listagg(ename, ':') within group (order by ename) ename_list from emp group by deptno DEPTNO ENAME_LIST CLARK:KING:MILLER 20 ADAMS:FORD:JONES:SCOTT:SMITH 30 ALLEN:BLAKE:JAMES:MARTIN:TURNER:WARD 151

146 Aggregate und Materialized Views Bereitstellung von Aggregaten auch in Form von Materialized Views Spart separaten ETL-Lauf Ist flexibler, weil nur ein SQL-Statement ausgeführt wird Weitreichende Funktionalitäten für SQL-Query-Rewrite Aufbau eines mehrstufigen Kennzahlensystems möglich Optimierung durch OLAP-basierte Materialized Views 152

147 Grundlagen von Oracle OLAP

148 8 Gründe für OLAP Performance Multidimensionale Technologie ermöglicht maximale Performance für Ad Hoc-Analysen Managebility Einfache Administration in / mit der Datenbank MAV Lösung für viele gleichartige MAVs Nähe zum ODS Drill -Through und Recalculation leicht gemacht DB Calculation Power Datenbank-Engine berechnet komplexeste Formeln, Verhältniskennzahlen u.v.m. Mehr als Reporting OLAP-Analysen gehen über traditionelles Reporting hinaus bis hin zu hypothetischen und kausalen Fragestellungen Benutzer-Logik Keine Einarbeitung und Desktop- Einbindung notwendig Offenheit Support aller BI-Applikationen durch die Offenheit der Datenbank

149 BI-Funktionalität in der Datenbank OLTP / 3NF DWH Star Schema OLAP Standard Reporting Ad-Hoc Reporting Ad-Hoc Analysis Planning Analyse-freie Zone Ad Hoc-Abfragen Zeitreihen Shares/Indizes Ad Hoc-Analysen Analyse in Denkgeschwindigkeit Advanced Aggregations Vorhersagbare Analysen Statistisches Forecasting Budgetzuordnungen Modellberechnung Wirtschaftsbezogene und selbstdefinierte Funktionen OLAP Transaktions- Modell

150 Komplexe Fragestellungen Rückblick / IST-Zustand Vorhersage / SOLL-Zustand Was sind die Top10-Märkte? Abweichung zum Forecast? Welche Kunden, Produkte, Dienste sind profitabel? Umsatz pro Produkt im Vergleich zum letzten Jahr? Verkaufszahlen pro Produkt, pro Filiale und pro Quartal? Entwicklung Personalkosten? Personalbestand vs. offene Stellen? Wie können Promotions unsere Verkäufe um 10% steigern? Wie ändert sich das Ergebnis, wenn der US- Dollar um 5% fällt? Wenn Rohstoffpreise um 20% steigen, was heißt das für den Gewinn? Mit welchen Kunden erzielen wir 80% unseres Gewinns? Wie ändern sich die Verkäufe einer Filiale bei einem um 5% höheren Warenumschlag?

151 OLAP: Daten als Cube organisiert Umsätze Zelle Kosten Deckungsbeitrag in % Zeit

152 Slicing und Dicing mit OLAP Zeit Wann? Sicht des Vertriebs Region Wo? Indikatoren Sicht der Produktmanager Produkt Was? Sicht des Controllings Ad Hoc- Analysen

153 Vorteile der Integration in die Datenbank Report Dashboard Analysis Web Service Business Rules liegen im Data Dictionary Rules werden einmalig definiert zur Erstellung des OLAP Cubes Zugriff mit allen Client Tools und Applikationen Komplexität der Berechnung wird in die Datenbank verlegt Vereinfacht die Implementation (Daten sind bereits im DWH) Effiziente Verarbeitung

154 Bestandteile von Oracle OLAP OLAP Catalog Speichert das logische Modell der Cubes (Metadaten) Analytic Workspace Enthält die multidimensionalen Daten in der Datenbank (gespeichert als LOB-Daten) OLAP Calculation Engine Ehemals eigenes Produkt (Oracle Express Server) Seit Oracle 9iR2 integriert in der Datenbank Schnittstellen mit Applikationen OLAP DML SQL

155 OLAP Cubes anlegen Metadaten der Cubes liegen im OLAP Catalog Messgrößen, Cubes und Dimensionen Level, Hierarchien und Attribute Definition der Metadaten erfolgt hauptsächlich über zwei Werkzeuge Analytic Workspace Manager Wird zusammen mit dem Oracle DB Client installiert Speziell auf den Aufbau von OLAP Cubes zugeschnitten Oracle Warehouse Builder Fast gleicher Arbeitsgang wie beim Anlegen eines Star oder Snowflake Schemas

156 Kennzahlen und Dimensionen Die Kennzahlen stellen die Fakten dar, die Zellen des Cubes bilden die einzelnen Werte Kennzahlen setzen sich aus zwei oder mehr Dimensionen zusammen Es gibt nicht nur das numerische Format, sondern auch Text, Boolean, etc. Die Kanten des Cubes werden mit den Dimensionen definiert Die Dimensionen weisen durch Pointer auf die angeforderten Zellen im Cube

157 Ein großer vs. zwei kleine Cubes Dimension Members Data Points D D ,000 D ,000,000 D ,000,000 D ,000,000,000 D ,000,000,000,000 Ein großer Cube mit 1 Trillion Zellen Dimension Members Data Points D D ,000 D ,000,000 Dimension Members Data Points D D ,000 D ,000,000 D ,000,000 Zwei kleinere Cubes mit insgesamt 101 Millionen Zellen

158 OLAP und Materialized Views in Oracle 11g

159 Wachsende Anzahl an Materialized Views Bei zunehmender Menge von MAVs Können zahlreiche Ergebnisse für verschiedene Nutzer vorgehalten werden Wird die Administration erschwert (Indexes, Storage, Anlegen und Löschen welcher MAVs, etc.) Month, City, Category SALES_MCC month_id category_id city_id quantiy sales Year, City, Category SALES_YCC year_id category_id city_id quantiy sales Year, Region, Category SALES_YCC year_id category_id region_id quantiy sales Qtr, State, Item SALES_QSI qtr_id item_id state_id quantiy sales SALES day_id prod_id cust_id chan_id quantity sales Year, District SALES_YCT year_id type_id region_id quantiy sales Month, State SALES_MS month state quantiy revenue Year, Region SALES_YC year_id region_id quantity revenue Cust, Time, Prod, Chan Lvls SALES_XXX SALES_XXX XXX_id XXX_id SALES_XXX XXX_id SALES_XXX expense_amount XXX_id potential_fraud_cost XXX_id XXX_id XXX_id XXX_id expense_amount XXX_id potential_fraud_cost quantiy revenue

160 Oracle 11g: Cube-Organized MAVs PRODUCT item_id subcategory category type CUSTOMER cust_id city state country TIME day_id month quarter year CHANNEL chan_id class SALES day_id prod_id cust_id chan_id quantity sales SQL Automatisches Query Rewrite Materialized View Refresh

161 Vorteile von Cube-organized MAVs Ein Cube ersetzt viele Summierungs-Kombinationen (implementiert als Materialized Views) Der Query Optimizer in Oracle 11g behandelt OLAP Cubes als Materialized Views und leitet SQL- Abfragen transparent auf den Cube um Der Cube wird mit den für Materialized Views verfügbaren Mechnismen aktualisiert

162 169 Hardware Komponenten

163 Balanced Konfigurationen 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 Anzahl Disk Controller = Controllerdurchsatz in MB = Max. Durchsatz in MB/s Controllerdurchsatz in MB 70% * Herstellerangaben in Gbit/s 8 170

164 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 171

165 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 172

166 173 ASM Architektur

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

168 Typische Cluster Konfiguration Gigabit ethernet 4 nodes, each with 4 x 2 Ghz CPUs 5 PCI slots 16-port switch 16-port switch 16 Storage arrays, each with disks 175

169 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 ASH Tracing Permanente Betrachtung Protokolldatei 176

170 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 sysaux 8 Tage lang ADDM use 1 Findings 2 1 nn% 2 nn% 3 nn%. Recommendations - Hardware - Init-Parameter - Space Konfig. - Performance Advisor 3 Action 4 Undo Advisor SQL Tuning Advisor Segement Advisor Rationale 177

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

172 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 179

173 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. 180

174 ADDM-Screen Snapshot mit Findings Weiterführende Aktivitäten 181

175 182

176 Oracle Database Machine (Exadata) Traditionelle Umgebung Database Machine Extreme Performance 0,5 5 GB/sec 25/50 GB/sec Einführungsdauer Monate Tage Personaleinsatz Tuning Platten-, Server-, Netz-Integration notwendig sorgfältige Planung erforderlich minimal (vorkonfiguriert) Ausgewogenes System Investionen

177 Oracle Database Machine X2-2 Oracle Database Server Grid 8 compute servers 96 Intel Cores (gesamt) (Six-Core Intel X5670, 2,93 GHz) 768 GB DRAM (gesamt) Jeder Server 2x10Gb Ethernet Port 4x1Gb Ethernet Port 4x300 GB SAS Disks InfiniBand Network 40 Gb/sec unified server and storage network Fault Tolerant Enterprise Linux Exadata Storage Server Grid 14 storage servers 168 Platten / 112 Intel Cores 100 TB raw SAS disk storage or 336 TB raw SATA disk storage 5,3TB flash storage! 25 GB / Sec IO Datendurchsatz 50 GB / IO für Flash-Speicher

178 Query Processing: Das Problem mit klassischem Storage What Were Yesterday s Sales? Oracle Database Server Grid Storage Array Select sum(sales) where salesdate= 22-Dec-2009 Retrieve Entire Sales Table SUM

179 Query Processing: Bei Exadata fliessen weniger Daten durch das Netz What Were Yesterday s Sales? Oracle Database Server Grid Oracle Exadata Storage Grid Select sum(sales) where salesdate= 22-Dec-2009 Retrieve Sales for Dec SUM

180 Hybrid Columnar Compression Storage und IO sparen (Beispiele) Table Anzahl Sätze GB Vor K. EHCC Query Low EHCC Query High EHCC Archive Low EHCC Archive High T T T T T T

181 DATA WAREHOUSE BigData neue Optionen für das Data Warehouse Alfred Schlaucher, Oracle

182 Klassische Daten Messbare Größen und Einheiten Transaktionsbezogene Daten Misst OLTP-Systeme Definierte Kennzahlen TB Tabellen und Spalten Täglich neue Daten Jeder Satz ist relevant Buchungs relevant Zeitrelevant Wachstum messbar

183 Der größte Teil der entstehenden Daten wird noch nicht der Analyse zugeführt Verkehrsströme Kontaktinformationsdaten / CRM Briefwechsel Vertragsunterlagen Mailverkehr Energie- Verbrauchsdaten Treuepunkt-Daten Mobile-Banking Verbrechensprofile Auto-Mobilitätsdaten Fahrzeug- Informationssysteme Maschinen-Messdaten

184 Big Data: Potentielle Anwendungsfälle Aufgabenstellung Neue Daten Lösungen Healthcare Teures Gesundheitssystem Produktion Personeller Support Remote Erfassung von Patientendaten, Krankenverläufe etc. Sensoren an Maschinen und Anlagen Genauere+günstigere Medikation Weniger Krankenhausaufenthalte Remote Support Ausfallvorhersagen Location Based Services Öffentlicher Dienst Bürger-Angebote Retail Marketing Realtime Bewegungsdaten potentieller Kunden Bevölkerungsstatistiken Verbrauchsdaten Soziale Netzwerke / Medien Geo-bezogenes Marketing, Besucherstrom-Analyse Verkehrsanalysen Individualisierte Dienste Kostensenkung Stimmungsanalysen Genauere Segmentierungen

185 BigData bedeutet nicht nur Viele Daten sondern erweiterte Analysen mit anderen Daten Messbare Größen und Einheiten Transaktionsbezogene Daten Misst OLTP-Systeme Definierte Kennzahlen TB Tabellen und Spalten Täglich neue Daten Jeder Satz ist relevant Buchungs relevant Zeitrelevant Wachstum messbar + Keine klassischen Masseinheiten Daten entstehen durch zufällige Begebenheiten Abfallprodukt Die Relevanz ist zunächst noch unbestimmt Ansammlung von unterschiedlichen Objekten Mengen und Anhäufungen sind interessant Einzelnes Objekt ist unwichtig Wachstum indifferent

186 Big Data: Infrastruktur Anforderungen Acquire Organize Analyze Unvorhersehbares Auftreten Hohe Datenmengen Flexible Daten-Strukturen Arbeiten mit vielen Servereinheiten Abfragen mit extrem hohen Daten-Durchsatz Bearbeitung am Speicherplatz Hohe Parallelisierung Exporative Analyse Komplexe statistische Analysen Agile Berichtsentwicklung Massive Skalierung Real Time Ergebnisse

187

188 Heutige Lösungen sind isoliert und handgemacht Data Variety Unstructured Schema-less Distributed File Systems (z. B. HDFS) HDFS Transaction (Key- Oracle Value)Stores (Cassandra) NoSQL DB Hadoop MapReduce Solutions (Hadoop MapReduce) Oracle Loader for Hadoop R NoSQL Flexible Specialized Developer Centric Schema RDBMS (OLTP) Home Grown ETL ETL RDBMS (DW) Advanced Home Analytics Advanced Grown BI Analytics SQL Trusted Secure Administered Information Density Acquire Organize Analyze

189 Oracle s integrierte Software Lösung Data Variety Unstructured Schema-less Schema HDFS Oracle NoSQL DB Oracle (OLTP) Cloudera Hadoop Oracle Hadoop Loader Oracle Data Integrator Oracle MapReduce Oracle (DW) Oracle Analytics Mining R Spatial Graph OBI EE Information Density Acquire Organize Analyze

190 Oracle Engineered Systems Data Variety Unstructured Exalytics Schema-less Big Data Appliance Schema Exadata Database Machine Information Density Acquire Organize Analyze

191 Big Data Appliance Hardware: 216 CPU cores with 864 GB RAM 648 TB of raw disk storage 40 Gb/s InfiniBand Integrated Software: Oracle Linux Oracle Java VM Cloudera Distribution of Apache Hadoop (CDH) Cloudera Manager Open-source distribution of R NoSQL Database Community Edition All integrated software (except NoSQL DB CE) is supported as part of Premier Support for Systems and Premier Support for Operating Systems

192 Oracle Loader for Hadoop ORACLE LOADER FOR HADOOP Leverage Hadoop Cluster to pre-process data for loading MAP MAP MAP SHUFFLE /SORT REDUCE REDUCE Last stage in MapReduce workflow MAP MAP MAP SHUFFLE /SORT REDUCE REDUCE REDUCE Partitioned and non-partitioned tables Online and offline loads

193 Oracle Direct Connector for HDFS HDFS Oracle Database SQL Query External Table Direct Access from Oracle Database SQL access to HDFS External table view Data query or import Infini Band DCH DCH DCH HDFS Client

194 Oracle NoSQL Database A distributed, scalable key-value database Simple Programming and Operational Model Simple Major + Sub key and Value data structure ACID transactions Configurable consistency & durability Scalable throughput, bounded latency Commercial Grade Software and Support General-purpose Reliable Based on proven Berkeley DB JE HA Easy to install and configure Easy Management Web-based console, API accessible Manages and Monitors: Topology; Load; Performance; Events; Alerts Application NoSQLDB Driver Storage Nodes Data Center A Application NoSQLDB Driver Storage Nodes Data Center B

195 R Statistische Programmiersprache Open source Sprache und Entwicklungsumgebung Geeignet für statistische Berechnungen und graphische Darstellung der Ergebnisse Endbenutzertaugliche Graphiken Erweiterbar

196 Oracle R Enterprise Lösung Vorher Kleine Modelle oft nur auf Benutzer Laptops Oracle R Modelle laufen in der skalierbaren Datenbank Große Datenmengen können verarbeitet werden Nutzt die Performance der Oracle DB und von Exadata Gleicher Code nur schneller

197 Data Mining Provides Better Information, Valuable Insights and Predictions Cell Phone Churners vs. Loyal Customers Customer Months Source: Inspired from Data Mining Techniques: For Marketing, Sales, and Customer Relationship Management by Michael J. A. Berry, Gordon S. Linoff

198 Data Mining Provides Better Information, Valuable Insights and Predictions Cell Phone Churners vs. Loyal Customers Customer Months Source: Inspired from Data Mining Techniques: For Marketing, Sales, and Customer Relationship Management by Michael J. A. Berry, Gordon S. Linoff

199 Data Mining Provides Better Information, Valuable Insights and Predictions Cell Phone Churners vs. Loyal Customers Segment #3: IF CUST_MO > 7 AND INCOME < $175K, THEN Prediction = Cell Phone Churner, Confidence = 83%, Support = 6/39 Segment #1: IF CUST_MO > 14 AND INCOME < $90K, THEN Prediction = Cell Phone Churner, Confidence = 100%, Support = 8/39 Customer Months Source: Inspired from Data Mining Techniques: For Marketing, Sales, and Customer Relationship Management by Michael J. A. Berry, Gordon S. Linoff

200 Data Mining Provides Better Information, Valuable Insights and Predictions Cell Phone Churners vs. Loyal Customers Segment #3: IF CUST_MO > 7 AND INCOME < $175K, THEN Prediction = Cell Phone Churner, Confidence = 83%, Support = 6/39 Insight & Prediction Segment #1: IF CUST_MO > 14 AND INCOME < $90K, THEN Prediction = Cell Phone Churner, Confidence = 100%, Support = 8/39 Customer Months Source: Inspired from Data Mining Techniques: For Marketing, Sales, and Customer Relationship Management by Michael J. A. Berry, Gordon S. Linoff

201 Data Mining Provides Better Information, Valuable Insights and Predictions Cell Phone Fraud vs. Loyal Customers? Customer Months Source: Inspired from Data Mining Techniques: For Marketing, Sales, and Customer Relationship Management by Michael J. A. Berry, Gordon S. Linoff

202 Oracle Data Mining Algorithms Problem Algorithm Applicability Classification Regression Anomaly Detection Attribute Importance Association Rules Clustering Feature Extraction A1 A2 A3 A4 A5 A6 A7 F1 F2 F3 F4 Logistic Regression (GLM) Decision Trees Naïve Bayes Support Vector Machine Multiple Regression (GLM) Support Vector Machine One Class SVM Minimum Description Length (MDL) Apriori Hierarchical K-Means Hierarchical O-Cluster Nonnegative Matrix Factorization Classical statistical technique Popular / Rules / transparency Embedded app Wide / narrow data / text Classical statistical technique Wide / narrow data / text Lack examples of target field Attribute reduction Identify useful data Reduce data noise Market basket analysis Link analysis Product grouping Text mining Gene and protein analysis Text analysis Feature reduction

203 In-Database Data Mining Source Data Traditional Analytics Data Import Data Mining Model Scoring Data Preparation and Transformation Data Mining Model Building Data Prep & Transformation Data Extraction Hours, Days or Weeks Dataset s/ Work Area Analytic al Process ing Process Output Target Oracle Data Mining Model Scoring Embedded Data Prep Savings Model Building Data Preparation Secs, Mins or Hours Results Faster time for Data to Insights Lower TCO Eliminates Data Movement Data Duplication Maintains Security Model Scoring Data remains in the Database Embedded data preparation Cutting edge machine learning algorithms inside the SQL kernel of Database SQL Most powerful language for data preparation and transformation Data remains in the Database

204 Oracle Data Miner 11g Release 2 GUI Churn Demo Simple Conceptual Workflow

205 Oracle Data Miner 11g Release 2 GUI Churn Demo Simple Conceptual Workflow Churn models to product and profile likely churners

206 Oracle Data Miner 11g Release 2 GUI Churn Demo Simple Conceptual Workflow Market Basket Analysis to identify potential product bundless

207 Oracle Data Mining and Unstructured Data Oracle Data Mining mines unstructured i.e. text data Include free text and comments in ODM models Cluster and Classify documents Oracle Text used to preprocess unstructured text

208 Oracle Communications Industry Data Model Example Better Information for OBIEE Dashboards ODM s predictions & probabilities are available in the Database for reporting using Oracle BI EE and other tools

209 DWH-bezogenes Monitoring Oracle Data Warehouse 217

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

211 ASH Reports Active Session History Auflisten der wichtigsten Aktivitäten in den letzten 30 Minuten Langläufer Waits Top SQL-Statements Aktive Session Blocking Sessions Report erzeugen mit Ashrpt.sql HTML-Report 220