Скачать презентацию Oracle Warehouse Technologie Single-Engine-Based-Data-Warehouse Performantes Data Warehouse Скачать презентацию Oracle Warehouse Technologie Single-Engine-Based-Data-Warehouse Performantes Data Warehouse

083a2e0dcd023b05a78097dc54d997f0.ppt

  • Количество слайдов: 93

Oracle Warehouse Technologie Single-Engine-Based-Data-Warehouse Oracle Warehouse Technologie Single-Engine-Based-Data-Warehouse

Performantes Data Warehouse Effiziente, integrierte Data Warehouse Architekturen auf der Basis von Oracle 10 Performantes Data Warehouse Effiziente, integrierte Data Warehouse Architekturen auf der Basis von Oracle 10 g Alfred Schlaucher Gerd Schoen Stichpunkte zu Ressourcen – schonenden Techniken mit dem Oracle – basierten Data Warehouse

Information Management und Data Warehouse Themen • • • Anforderungen und Architekturen Vorgehensweisen und Information Management und Data Warehouse Themen • • • Anforderungen und Architekturen Vorgehensweisen und Modelle Datenintegration Datenqualität Aufbau eines Data Warehouse Systems Optimierungen der Datenhaltung

Data Warehouse Anforderungen Klassisch Trends Anzahl Benutzergruppen Anzahl Schnittstellen Latenzzeit Granularität Datenmengen Data Warehouse Anforderungen Klassisch Trends Anzahl Benutzergruppen Anzahl Schnittstellen Latenzzeit Granularität Datenmengen

Oracle DWH Referenzarchitektur Master Data Hub Kunden Produkte Enterprise Service Bus Adapter Routing UDDI Oracle DWH Referenzarchitektur Master Data Hub Kunden Produkte Enterprise Service Bus Adapter Routing UDDI Workflow Nativ BPEL Rules Stage BPEL Process Manager Data Mart Data Warehouse Kennzahlensysteme Rules ODS Rules Beliebig komplexe Abfragen Prüfungen Rules BI Services Top Level Management Wahlfreie Positionierung ETL. Wahlfreie Analysenzugriffe Unified Repository operative und dispositive Metadaten Qualitätsstandards und Servives RAC Verbund Mitarbeiter operative Ebene

Oracle DWH Plattform Experten/ Spezialanwendung Austauschbare Frontends und Anwendungen Standard Generische Verwendung Ad Hoc Oracle DWH Plattform Experten/ Spezialanwendung Austauschbare Frontends und Anwendungen Standard Generische Verwendung Ad Hoc Komplexe multidim. Data Mining Analyse. Komplexität Flexible Bereitstellung von Business Intelligence Informationen Kennzahlen Abonnement Fachspez. Kennzahlen Metadaten Fachspezifische Transformationen Vorgelagerte zentrale Transformationen und generische Kennzahlen Data Quality Regelbausteine / abgebildete Business Rules Integrierte Data Warehouse Plattform

Options: RAC Verteilung der Last in einem RAC-Verbund - Tagsüber Load-Job 1 CPU Knoten Options: RAC Verteilung der Last in einem RAC-Verbund - Tagsüber Load-Job 1 CPU Knoten 1 CPU Interaktive Analysen Standard. Reporting Interaktive Analysen CPU CPU Knoten 2 CPU CPU Knoten 3 CPU Knoten 4 CPU CPU Schema DWH Schema Data Mining Eine Datenbank Schema CRM Schema Planung Schema Stammdaten

Options: RAC Verteilung der Last in einem RAC-Verbund - Nachts Load-Job 1 CPU Knoten Options: RAC Verteilung der Last in einem RAC-Verbund - Nachts Load-Job 1 CPU Knoten 1 CPU Load-Job 2 CPU Standard. Reporting CPU Knoten 2 CPU CPU Knoten 3 CPU Load-Job 3 CPU Knoten 4 CPU CPU Schema DWH Schema Data Mining Eine Datenbank Schema CRM Schema Planung Schema Stammdaten

Technologien und Verfahren zum Aufbau und zur Verwaltung von Data Warehouse-Umgebungen Verwaltung und Dokumentation Technologien und Verfahren zum Aufbau und zur Verwaltung von Data Warehouse-Umgebungen Verwaltung und Dokumentation Metadaten Ownerschaften Grid Control Effiziente Datenhaltung Speichertechnik ILM Hardware ASM OLAP Datenintegration schnelles Bereitstellen DB-basiertes Laden MDM Qualitäts. ETL-Option management Data Profiling Data Auditing Daten-Zugriff Security Mandanten BI-Anwendungen Standard-Berichte Interaktive Berichte Data Mining Komplexe Analysen

Technologien und Verfahren Oracle EE Compression Verwaltung und Dokumentation Bitmapped Metadaten Ownerschaften Grid Control Technologien und Verfahren Oracle EE Compression Verwaltung und Dokumentation Bitmapped Metadaten Ownerschaften Grid Control B&R Data Guard Flashback RMAN Parallel Query Effiziente Datenhaltung Speichertechnik ILM Hardware ASM OLAP Diagnostic Pack Tuning Pack Repository (OWB) RAC Partition OLAP Oracle Enterprise Edition Streams Datenintegration Enterprise-ETL schnelles Bereitstellen DB-basiertes Laden Data Quality Option Master Data Qualitäts. Management ETL-Option management OBI SE SAP Zugriff Data Profiling OBI EE Daten-Zugriff Data Auditing Data Rules Security SAP Connect BI-Anwendungen Mandanten Standard-Berichte Gateways Interaktive Berichte Data Mining Komplexe Analysen Label Security Data Mining

Information Management und Data Warehouse Themen • Datenintegration und Modellbasiertes ETL Komponenten Information Management und Data Warehouse Themen • Datenintegration und Modellbasiertes ETL Komponenten

„Lösungen“ der Vergangenheit • Programmierung von Hand • Zerstreute Programm-Sourcen • Fehler bei der „Lösungen“ der Vergangenheit • Programmierung von Hand • Zerstreute Programm-Sourcen • Fehler bei der Entwicklung • Unnötige Doppelarbeit • Schlechte oder fehlende Dokumentation • Schlechte Wartbarkeit Wie war das nur? • Enorme Folgekosten • Unkündbare „Inselexperten“ • Immer wieder „Katastrophen“ im Echtbetrieb

Die Geschichte der ETL-Tools geht in Richtung integrierter Werkzeuge 1992 1996 2000 2005 Datenbankbasierte Die Geschichte der ETL-Tools geht in Richtung integrierter Werkzeuge 1992 1996 2000 2005 Datenbankbasierte ETL-Werkzeuge Separate Engine-gestützte ETL-Werkzeuge Programmgeneratoren Handprogrammierung

Es gibt 3 Hauptgründe für den Einsatz von OWB 1. Performance 2. Effizientere Warehouse Es gibt 3 Hauptgründe für den Einsatz von OWB 1. Performance 2. Effizientere Warehouse Architekturen (integriert in Oracle) 3. Preis

Oracle Warehouse Builder ist das ETLTool der Wahl in Oracle-Umgebungen! • Design des kompletten Oracle Warehouse Builder ist das ETLTool der Wahl in Oracle-Umgebungen! • Design des kompletten Data Warehouse Systems • Logisches Design und Dokumentation • Physisches Oracle Datenbank Design • Fast alle Datenbankobjekte von Oracle 10 g • • 100 % SQL 100 % PL / SQL - Generierung Bereitstellung der Datenbeschaffungsroutinen Laufzeit – System zur Fehlerkontrolle Universelles Metadaten-Repository Automatisiertes ETL durch Scriptsprache Data Quality / Data Profiling • Hat bereits mehr Installationen als andere Mitbewerber

Schnittstellenkomponenten Oracle Data Warehouse In Memory nn JCA COM+ SOAP WSIF & JBI Enterprise Schnittstellenkomponenten Oracle Data Warehouse In Memory nn JCA COM+ SOAP WSIF & JBI Enterprise Service Bus Routing QOS BPEL Transform Rules Flat. File Oracle (Remote) DB 2 OS 390, UDB Sybase, Informix, SQL-Server. . . Access/Excel Message. Broker Peoplesoft Log XML e. Mail XML Port FTP Port SAP Int. Ext. Table Streams tcp UTL_FILE Gateway ODBC DB-Link Queue Adapter PL/SQL XML DB-Link XML Queue Tabellen View Sequenz Index Cube MView Procedure Function SQL Loader Flat. File Warehouse Datenbank CDC Siebel Webservices Flat. File XML

OWB live OWB live

Information Management und Data Warehouse Themen • Data Quality und Data Profiling Information Management und Data Warehouse Themen • Data Quality und Data Profiling

Ohne Daten kein Business Unternehmen funktionieren nur mit Daten Information Chain Marketing Werbung Adresse Ohne Daten kein Business Unternehmen funktionieren nur mit Daten Information Chain Marketing Werbung Adresse KD-Daten Bedarf Adresse Kreditdaten Kunde Angebot Kredit OK Kundenbetreuer Bestelldaten Bestand Stammdaten Order Logistiksystem Lager Buchhaltung Verkaufsdaten Lieferschein Spedition Rechnung Mahnung Bezahlung Reklamation Kunde Operative Prozesse

Data Profiling mit OWB Methoden Die operativen Daten Feintuning zu den Analysemethoden Protokollierung laufende Data Profiling mit OWB Methoden Die operativen Daten Feintuning zu den Analysemethoden Protokollierung laufende Analysen Drill Down zu den operativen Daten

Analyseumgebung • Oracle Datenquellen LDAP / DBMS_LDAP / Table Function non Oracle DB 2, Analyseumgebung • Oracle Datenquellen LDAP / DBMS_LDAP / Table Function non Oracle DB 2, SQL Server Informix, Teradata SAP Integrator • Alle Gateway / ODBC / FTP lesbare Quellen • SAP-Daten • Flat Files • Adress-/LDAPVerzeichnisse Oracle 9 i / 10 g Source Schema Profiling Stage Oracle Source Schema Transportable Module External Table RAC

Unterstützung von Software-Projekten Durch den Feldnamen vermutet man rein numerische Inhalte Übereinstimmung von Feldname Unterstützung von Software-Projekten Durch den Feldnamen vermutet man rein numerische Inhalte Übereinstimmung von Feldname „. . . nr“ und Feldtyp Firmenrabatt ist in der Regel ein Rechenfeld Kundennr ist ein wichtiges Feld. Es sollte stimmig sein. ? ! sieht gut aus

Unterstützung von Software-Projekten Die Zahl 17 kommt häufig vor, hier muss es eine „systematische“ Unterstützung von Software-Projekten Die Zahl 17 kommt häufig vor, hier muss es eine „systematische“ Ursache geben ? Felder sind nicht gepflegt kritisch! da es sich um einen Schlüsselkandidaten handelt ? kritisch! weil doppelte Kundennummern OK

Metadatenmanagement Metadatenmanagement

Daten-Ownerschaft Die Rolle von Metadaten • Wem gehören welche Daten? • Wer nutzt welche Daten-Ownerschaft Die Rolle von Metadaten • Wem gehören welche Daten? • Wer nutzt welche Daten? • Wer hat an welchen Daten welches Interesse? • Wer hat welche Daten wie oft benutzt? • Welche Prozesse sich auf welche Daten angewiesen? • Welche Prozesse sind datenabhängig von anderen Prozessen?

Subject Area Cost Entity Data Set / Record (Name Location) Stakeholder Abteilung Data Owner Subject Area Cost Entity Data Set / Record (Name Location) Stakeholder Abteilung Data Owner Mitarbeiter Role Org

Impact / Lineage - Metadatenanalyse Zurück Impact / Lineage - Metadatenanalyse Zurück

Aufbau eines DWH Aufbau eines DWH

 • Starschema • Mviews • Analytische Funktionen • Mandantenfähigkeit • Partitioning • Transportable • Starschema • Mviews • Analytische Funktionen • Mandantenfähigkeit • Partitioning • Transportable Tablespace • Bitmap Indizierung • Table Function

Umsetzung in technische Lösungen Dimensionale Sicht und relationale Datenbank V 1 V 2 V Umsetzung in technische Lösungen Dimensionale Sicht und relationale Datenbank V 1 V 2 V 3 V 4 Einstiegspunkte für Abfragen Prod 1 Prod 3 Prod 5 Prod 6 Lief 1 Lief 4 Lief 5 Lief 9 Müller Schmid Engel 1: n P 1 P 2 P 3 P 4 R 1 R 2 R 3 R 4 Z 1 Z 2 Z 3 Z 4 V 1 4 V 2 4 V 3 9 V 4 8 Zeit n: 1 Z 2 Z 3 Z 4 N : 1 Starschema • flexibel • Graphisch auch für Business-User verständlich Verkäufer 1 : n Verkäufe Produkttabelle P 1 P 2 P 3 P 4 Maier R 1 R 2 R 3 R 4 München Berlin Hamburg Frankfurt Regionen 6. 7. 99 7. 7. 99 8. 7. 99 9. 7. 99 Q 3 Q 3

Die Datenbank für das Warehouse fit machen (Beispiele) Dimension Länder Analytical. Functions Regionen Level Die Datenbank für das Warehouse fit machen (Beispiele) Dimension Länder Analytical. Functions Regionen Level 3 Definitionen Attribute Zeit Orte Star-Transformation Bitmap-Index Partitions Produkt FK_Ort FK_Zeit FK_Produkt Level 2 Definitionen Attribute Level 1 Definitionen Attribute Query Rewrite Materialized View Umsätze Parallel+ Cluster Ort Kunde

Partitioning Partitioning

Fallbeispiel: 4 Terabyte Warehouse einer der grössten Banken Deutschlands 13 Tabellen Monatliches Ladevolumen von Fallbeispiel: 4 Terabyte Warehouse einer der grössten Banken Deutschlands 13 Tabellen Monatliches Ladevolumen von mehreren 100 GB Dez 02 Aug 02 Jul 02 View Jun 02 Mai 02 Apr 02 Nov 02 Mar 02 Sep 02 Feb 02 Jan 02 Okt 02 View 3000 Profitcentern • 4 Mill. Kunden • 8000 zugel. Nutzer • tägl. 2500 Report. Server. Zugriffe • tägl. 1500 Discoverer Zugriffe • tägl. Ca 800 Plain SQL Auswertungen View • Ergebnisrechnung von

Partitioning • Hauptgründe für das Partitioning • Managebility • Abfrageperformance • Verfügbarkeit • Arten Partitioning • Hauptgründe für das Partitioning • Managebility • Abfrageperformance • Verfügbarkeit • Arten des Partitioning • Range • List • Hash • Composite Range-List

Range-Partitionierung Zeit Jahr Quartal Monat Region Umsatz FK_Ort FK_Zeit FK_Produkt Artikel Nach Quartalen und Range-Partitionierung Zeit Jahr Quartal Monat Region Umsatz FK_Ort FK_Zeit FK_Produkt Artikel Nach Quartalen und Jahren partitioniert Qx 9999 Q 12000 Q 22000 Q 32000 Kunde

Join-wise-Partitioning Zeit Jahr Quartal Monat Region Umsatz FK_Ort FK_Zeit FK_Produkt Artikel Partition-Join 1 1 Join-wise-Partitioning Zeit Jahr Quartal Monat Region Umsatz FK_Ort FK_Zeit FK_Produkt Artikel Partition-Join 1 1 2 3 4 5 6 7 8 9 Hash. Partition 1: 1 2: 2 3: 3 4: 4 5: 5 6: 6 7: 7 8: 8 9: 9 2 3 4 5 6 7 8 9 Kunde Hash. Partition

Join-wise-Sub Partitioning (Range und Hash) Zeit Jahr Quartal Monat Region Umsatz FK_Ort FK_Zeit FK_Produkt Join-wise-Sub Partitioning (Range und Hash) Zeit Jahr Quartal Monat Region Umsatz FK_Ort FK_Zeit FK_Produkt Artikel Partition-Join 1 Q 22000 Range. Partition Q 32000 nach Zeit Q 42000 1 2 3 4 5 6 7 8 9 Hash-Partition 1: 1 2: 2 3: 3 4: 4 5: 5 6: 6 7: 7 8: 8 9: 9 2 3 4 5 6 7 8 9 Kunde Hash. Partition

Arten der Indizierung bei der Partitionierung Partitionierte Tabelle Partition 1 Partition 2 Partition 3 Arten der Indizierung bei der Partitionierung Partitionierte Tabelle Partition 1 Partition 2 Partition 3 Partition 4 Partition 5 Partition 6 Local Index Global Partitioned Index Global Non Partitioned Index

Fallbeispiel zur Lade- und Abfrageperformance Fallbeispiel zur Lade- und Abfrageperformance

Customer 1. 000 HP Proliant DL 380 G 3 6 GB RAM 2 CPU Customer 1. 000 HP Proliant DL 380 G 3 6 GB RAM 2 CPU 3 GHz Sales 292. 282. 479 Promotions 1. 001 Products 10. 000 Times 2. 557

Allgemeines zum Verfahren 300 Mio Sätze Insert into TGT Select * from SRC Temp Allgemeines zum Verfahren 300 Mio Sätze Insert into TGT Select * from SRC Temp Table Index

 • Jährliches Wachstum 20% • Besonders viele Daten im November, Dezember, dafür weniger • Jährliches Wachstum 20% • Besonders viele Daten im November, Dezember, dafür weniger Daten im April, Juni, August (keine gleichmäßige Verteilung über alle Monate) • Initial Load Jan 2002 – Nov 2004 • External Tables • ca. 27 Minuten für beide Varianten

Zeit für die Indexerzeugung Initial Load Platzverbrauch für Bitmap Gesamtindex ca. 30 MB Zeit für die Indexerzeugung Initial Load Platzverbrauch für Bitmap Gesamtindex ca. 30 MB

Nachladen 1 Zeitscheibe Dezember 2004 Oracle 10 G 1 ALTER TABLE sales ADD PARTITION Nachladen 1 Zeitscheibe Dezember 2004 Oracle 10 G 1 ALTER TABLE sales ADD PARTITION sales_dec_2004 VALUES LESS THAN (TO_DATE('01 -jan-2005', 'dd-mon-yyyy')); < 1 Sec 2 CREATE TABLE sales_temp_dec_2004 AS SELECT * FROM sales WHERE ROWNUM < 1; < 1 Sec 3 INSERT INTO sales_temp_dec_2004 SELECT * FROM salesxt; 4 CREATE BITMAP INDEX sales_cust_id_bix_dec_2004 ON sales_temp_dec_2004 (cust_id) NOLOGGING PARALLEL; 29 Sec 5 ALTER TABLE sales EXCHANGE PARTITION sales_dec_2004 WITH TABLE sales_temp_dec_2004 INCLUDING INDEXES WITHOUT VALIDATION; < 1 Sec Drop Partition < 1 Sec 6 2 Min 6 Sec

Nachladen 1 Zeitscheibe Dezember 2004 ohne 10 G - Features 1 Drop auf alle Nachladen 1 Zeitscheibe Dezember 2004 ohne 10 G - Features 1 Drop auf alle Indexe 2 Laden neue Daten (parallel) mit External Table 3 Neuerzeugen des Index Platzverbrauch für Btree Gesamtindex ca. 1094 MB wenige Sekunden 6 Minuten insgesamt 800 Minuten

Löschen des alten Monats Januar 2002 Oracle 10 g Traditionell ALTER TABLE SALES DROP Löschen des alten Monats Januar 2002 Oracle 10 g Traditionell ALTER TABLE SALES DROP PARTITION SALES_JAN_2002; DELETE FROM SALES WHERE TIME_ID < TO_DATE('01 -FEB-2002', 'DD-MON-YYYY'); ca. 1 Sec. 7 Stunden 51 Minuten 28 Sekunden Rollbacksegment wird genutzt: ca 4000 MB Plattenplatz

Abrageperformance Abfrage 1 Abfrage 2 SELECT p. prod_name, SUM(s. amount_sold) FROM sales s, products Abrageperformance Abfrage 1 Abfrage 2 SELECT p. prod_name, SUM(s. amount_sold) FROM sales s, products p, channels ch, promotions pm WHERE s. prod_id = p. prod_id AND s. channel_id = ch. channel_id AND s. promo_id = pm. promo_id AND ch. channel_desc = 'Catalog' AND pm. promo_category = 'flyer' AND p. prod_subcategory = 'Shorts - Men' GROUP BY p. prod_name; select p. prod_name, sum(s. amount_sold) from sales s, products p, channels ch, promotions pm, times t where s. prod_id = p. prod_id and s. channel_id = ch. channel_id and s. promo_id = pm. promo_id and s. time_id = t. time_id and ch. channel_desc = 'Catalog' and pm. promo_category = 'flyer' and t. calendar_quarter_desc ='2000 -Q 2' and p. prod_subcategory = 'Shorts - Men' group by p. prod_name;

Abrageperformance 1. select count(*) from sales; 2. select count(*) from sales where promo_id = Abrageperformance 1. select count(*) from sales; 2. select count(*) from sales where promo_id = 714 and channel_id = 'S'; 3. select count(*) from sales where promo_id = 714 and time_id = to_date('20 -MAY-2004', 'DD-MON-YYYY') and channel_id = 'S';

Viele Auswertemodelle sind zu komplex für Endbenutzer (z. B. Snowflake) ÞKomplizierte ETL-Prozesse ÞAufwendige Erstellung Viele Auswertemodelle sind zu komplex für Endbenutzer (z. B. Snowflake) ÞKomplizierte ETL-Prozesse ÞAufwendige Erstellung und Wartung Aus 5 mach 3 Verfahren einfach halten Quellen Zusätzliche Verdichtungs/Abfragelogik Stage Summe SRC 1 Inserts/ Updates Summe SRC 2 Mart Quellen Stage Sich Selbstpflegende Materialized Views SRC 1 SRC 2 External Tables / Multiple Inserts Merge. . . Mart

Mandantenfähigkeit Mandantenfähigkeit

Options: - Label-Security - Partition Mandantenfähige Data Marts Anwendungsbeispiel: Label-Security / Partitioning Reg Eine Options: - Label-Security - Partition Mandantenfähige Data Marts Anwendungsbeispiel: Label-Security / Partitioning Reg Eine Kennzahlentabelle! Zeit Mandant 1 (Abteilung A) Org. Linie Zeit Prod Reg Zeit Mandant 1 Mandant 2 (Abteilung B) Org. Linie Reg Mandant 3 Prod Zeit Org. Linie Mandant 3 (Abteilung C) Prod Org. Linie Prod Physische getrennt gespeichert (als Partition)

Information Lifecycle Management Information Lifecycle Management

Information Lifecycle Management (ILM) Information Lifecycle Management (ILM)

Information Lifecycle Management (ILM) mit Oracle ASM Dieser Monat Aktiv Disk Gruppe P Current Information Lifecycle Management (ILM) mit Oracle ASM Dieser Monat Aktiv Disk Gruppe P Current Month Dieses Jahr Weniger Aktiv Disk Gruppe L Year 2002 and 2001 and 2000 Last 11 months High End Storage $$$ Midrange Storage $$ Vorjahre Historisch Archiv Disk Gruppe H Years 19951999 Historisches Storage Low End Storage $

ILM Siehe dazu auch online: http: //www. oracle. com/technology/deploy/ilm/index. html ILM Siehe dazu auch online: http: //www. oracle. com/technology/deploy/ilm/index. html

ILM ILM

Oracle Data Warehouse Mit den Anforderungen wachsen Verfahren und Techniken zum Aufbau und Verwalten Oracle Data Warehouse Mit den Anforderungen wachsen Verfahren und Techniken zum Aufbau und Verwalten von Data Warehouse Umgebungen Checkliste – Effizienter Betrieb DWH Alfred Schlaucher BU Database

Information Management und Data Warehouse Themen • Sammlung von Effizienz steigernden Punkten im Data Information Management und Data Warehouse Themen • Sammlung von Effizienz steigernden Punkten im Data Warehouse

Drei Bereiche in denen effizienter gearbeitet werden kann • Hardware • Projekte • Tools Drei Bereiche in denen effizienter gearbeitet werden kann • Hardware • Projekte • Tools

Hardware • Vor einer Hardware-Aufrüstung zunächst alle Software- gestützten Verfahren ausnutzen • Investitionen hier Hardware • Vor einer Hardware-Aufrüstung zunächst alle Software- gestützten Verfahren ausnutzen • Investitionen hier veralten nicht • Hardware bereits nach 1 Jahr 50% weniger wert • Software-Verfahren • Partitioning / Bitmapped-I. Mat. Views / Star Query • Die Wahl der Platten an den tatsächlichen Bedürfnissen ausrichten • Keine teueren Platten für weniger wichtige Daten • ILM-Verfahren nutzen / Ownerschaften feststellen • ASM • Komprimierung nutzen -> weniger Plattenplatz • Cluster-Technik statt Monoliten-Systeme

Effiziente Projektarbeit • Verwendung von Data Profiling-Tools • schnelleres Auffinden von Schwachstellen • Iterative Effiziente Projektarbeit • Verwendung von Data Profiling-Tools • schnelleres Auffinden von Schwachstellen • Iterative Vorgehensweise • Nacheinander-Realisieren von Data Marts • bei gleichzeitiger Pflege von zentralen, synchronisierenden Strukturen • Ersetzen handgeschriebener Lade-Routinen durch Modelle und generierten Code

Effiziente Architektur und Verfahren (1/3) • Mehr-Schichten-Architektur • Trennung von Vorsystemen und Data Marts Effiziente Architektur und Verfahren (1/3) • Mehr-Schichten-Architektur • Trennung von Vorsystemen und Data Marts durch eine zentrale, synchronisierende (DWH-)Schicht • Möglichst große Nähe zwischen DWH und operativen Vorsystemen • Minimiert Ladeaufwand bei kürzeren Ladezyklen • Keine 1: 1 Kopien zwischen Vorsystemen und DWH (Stage) • nach Möglichkeit bereits mit dem ersten Zugriff transformieren und filtern • Keine Aggregat-Tabellen verwenden • stattdessen sich selbst-aktualisierende Materialized Views -> spart ETL-Schritte

Effiziente Architektur und Verfahren (2/3) • ETL-Verfahren ganzheitlich sehen • zwischen zentralen und nachgelagerten Effiziente Architektur und Verfahren (2/3) • ETL-Verfahren ganzheitlich sehen • zwischen zentralen und nachgelagerten ETL-Schritten unterscheiden • Keine separaten ETL-Server • Datenbank-interne Lademechanismen nutzen, weil schneller und billiger • Bedingtes Mehrfachschreiben in unterschiedliche Ziele bei nur einmaligem Extrakt aus Quell-Strukturen • Automatisierte Insert/Update-Steuerung • Automatisierte Regelprüfung und Protokollierung durch den Kern der Datenbank • Verschieben kompletter Datenbereiche mit gleichen Merkmalen (sog. Partitions) • Flash-Back-Verfahren zum Zurückrollen kompletter Ladeläufe • Datentransport auf Datenbank-Block-Ebene • Datenbank-gesteuertes Wiederholen von Ladeläufen ohne Entwicklungsaufwand (keine Unterscheidung von Initial- und Delta-Load)

Effiziente Architektur und Verfahren (3/3) • Sicherheitsanforderungen Tabellen-intern lösen • nicht durch kopieren von Effiziente Architektur und Verfahren (3/3) • Sicherheitsanforderungen Tabellen-intern lösen • nicht durch kopieren von Tabellen • z. B. Label Security + Partitioning • Zentrale Kennzahlen im Kern-DWH berechnen • und nicht erst in den BI-Tools • BI-Tools muss die Arbeit so leicht wie möglich gemacht werden • Metadatendokumentation zu allen Objekten und Prozessen im DWH pflegen • universelle Repositories verwenden

Tools • Vor einer Tool-Auswahl auf die tatsächlichen Bedürfnisse achten • Gesamtsystem betrachten • Tools • Vor einer Tool-Auswahl auf die tatsächlichen Bedürfnisse achten • Gesamtsystem betrachten • Vereinheitlichung von Tools • Vermeiden von Tools-Inseln • Administrationsaufwand bei isolierten Systemen ist oft sehr hoch

Oracle Warehouse Technologie Single-Engine-Based-Data-Warehouse Oracle Warehouse Technologie Single-Engine-Based-Data-Warehouse

Alfred. Schlaucher@oracle. com Alfred. [email protected] com

Information Management und Data Warehouse Themen • Entwicklung multidimensionaler Modelle in der relationalen Datenbank Information Management und Data Warehouse Themen • Entwicklung multidimensionaler Modelle in der relationalen Datenbank

Umsetzung in technische Lösungen Dimensionale Sicht und relationale Datenbank V 1 V 2 V Umsetzung in technische Lösungen Dimensionale Sicht und relationale Datenbank V 1 V 2 V 3 V 4 Einstiegspunkte für Abfragen Prod 1 Prod 3 Prod 5 Prod 6 Lief 1 Lief 4 Lief 5 Lief 9 Müller Schmid Engel 1: n P 1 P 2 P 3 P 4 R 1 R 2 R 3 R 4 Z 1 Z 2 Z 3 Z 4 V 1 4 V 2 4 V 3 9 V 4 8 Zeit n: 1 Z 2 Z 3 Z 4 N : 1 Starschema • flexibel • Graphisch auch für Business-User verständlich Verkäufer 1 : n Verkäufe Produkttabelle P 1 P 2 P 3 P 4 Maier R 1 R 2 R 3 R 4 München Berlin Hamburg Frankfurt Regionen 6. 7. 99 7. 7. 99 8. 7. 99 9. 7. 99 Q 3 Q 3

Information Management und Data Warehouse Themen • RAC Information Management und Data Warehouse Themen • RAC

Herausforderung: “Insellösungen” • Limitierte Skalierbarkeit, keine Verteilung von Ressourcen • Konfiguration für die Höchstlast Herausforderung: “Insellösungen” • Limitierte Skalierbarkeit, keine Verteilung von Ressourcen • Konfiguration für die Höchstlast und maximale Kapazität • Single Point of Failure • Schwierige Anpassung an neue Business Anforderungen 23 % CPU 1000 IO/Sec Order Entry 95% Kapazität 70% CRM 100% CPU 3500 IO/Sec, 58% CPU 350 IO/Sec, Kapazität DWH 30% Kapazität

Grid Computing mit Oracle 10 g • Dynamisches Load Balancing • • Kostengünstige Maschinen Grid Computing mit Oracle 10 g • Dynamisches Load Balancing • • Kostengünstige Maschinen Optimale Resourcen Auslastung • In der Summe billiger Reduzierter HW Bedarf • Mehr Ausfallsicherheit Weniger Oracle Lizenzen ! • Leichtere Skalierung 100 % DWH CRM 60 % OE CPU 65 % Kapazität Auslastung des GRID

Information Management und Data Warehouse Themen • SQL Advisor Information Management und Data Warehouse Themen • SQL Advisor

Information Management und Data Warehouse Themen • Automatisches Error Logging Information Management und Data Warehouse Themen • Automatisches Error Logging

Fehlertabelle definieren • Massen-DML (Set-Based) • Ohne Abbruch • Fehlerhafte Eingabesätze werden separat protokolliert Fehlertabelle definieren • Massen-DML (Set-Based) • Ohne Abbruch • Fehlerhafte Eingabesätze werden separat protokolliert (analog SQL Loader und External Table) DBMS_ERRLOG. CREATE_ERROR_LOG ( dml_table_name IN VARCHAR 2, err_log_table_name IN VARCHAR 2 : = NULL, err_log_table_owner IN VARCHAR 2 : = NULL, err_log_table_space IN VARCHAR 2 : = NULL, skip_unsupported IN BOOLEAN : = FALSE);

1 4 SQL> desc T 3 Name Type -----------------F 1 NUMBER F 2 NUMBER 1 4 SQL> desc T 3 Name Type -----------------F 1 NUMBER F 2 NUMBER insert into t 3 values(1, 2) LOG ERRORS INTO err$_T 3 5 2 exec DBMS_ERRLOG. CREATE_ERROR_LOG ('T 3') 3 SQL> desc ERR$_T 3; Name Type ---------------------ORA_ERR_NUMBER$ NUMBER ORA_ERR_MESG$ VARCHAR 2(2000) ORA_ERR_ROWID$ ROWID ORA_ERR_OPTYP$ VARCHAR 2(2) ORA_ERR_TAG$ VARCHAR 2(2000) F 1 VARCHAR 2(4000) F 2 VARCHAR 2(4000) 1* select substr(ora_err_number$, 1, 10) Nr, substr(ora_err_mesg$, 1, 50) Err from ERR$_T 3 SQL> / NR ERR ------------------------------1 ORA-00001: unique constraint (DWH 4. IDX_T 3) violate

Information Management und Data Warehouse Themen • Tabellen-Komprimierung Information Management und Data Warehouse Themen • Tabellen-Komprimierung

Table Compression: Performance Impact • Example: TPC-H benchmark • NOTE: This is NOT an Table Compression: Performance Impact • Example: TPC-H benchmark • NOTE: This is NOT an official TPC-H result • Based on 300 GB HP (Compaq) configuration: • Composite metric w/o compression: 5976 • Composite metric with compression: 5957 • Compression had only a. 3% impact on overall performance • Performance of individual queries varied by +/- 15%

Information Management und Data Warehouse Themen • Real Application Cluster (RAC) • Automatic Storage Information Management und Data Warehouse Themen • Real Application Cluster (RAC) • Automatic Storage Manager (ASM)

Herausforderung: “Insellösungen” • Limitierte Skalierbarkeit, keine Verteilung von Ressourcen • Konfiguration für die Höchstlast Herausforderung: “Insellösungen” • Limitierte Skalierbarkeit, keine Verteilung von Ressourcen • Konfiguration für die Höchstlast und maximale Kapazität • Single Point of Failure • Schwierige Anpassung an neue Business Anforderungen 23 % CPU 1000 IO/Sec Order Entry 95% Kapazität 70% CRM 100% CPU 3500 IO/Sec, 58% CPU 350 IO/Sec, Kapazität DWH 30% Kapazität

Grid Computing mit Oracle 10 g • Dynamisches Load Balancing • • Kostengünstige Maschinen Grid Computing mit Oracle 10 g • Dynamisches Load Balancing • • Kostengünstige Maschinen Optimale Resourcen Auslastung • In der Summe billiger Reduzierter HW Bedarf • Mehr Ausfallsicherheit Weniger Oracle Lizenzen ! • Leichtere Skalierung 100 % DWH CRM 60 % OE CPU 65 % Kapazität Auslastung des GRID

Options: RAC Verteilung der Last in einem RAC-Verbund - Tagsüber Load-Job 1 CPU Knoten Options: RAC Verteilung der Last in einem RAC-Verbund - Tagsüber Load-Job 1 CPU Knoten 1 CPU Interaktive Analysen Standard. Reporting Interaktive Analysen CPU CPU Knoten 2 CPU CPU Knoten 3 CPU Knoten 4 CPU CPU Schema DWH Schema Data Mining Eine Datenbank Schema CRM Schema Planung Schema Stammdaten

Options: RAC Verteilung der Last in einem RAC-Verbund - Nachts Load-Job 1 CPU Knoten Options: RAC Verteilung der Last in einem RAC-Verbund - Nachts Load-Job 1 CPU Knoten 1 CPU Load-Job 2 CPU Standard. Reporting CPU Knoten 2 CPU CPU Knoten 3 CPU Load-Job 3 CPU Knoten 4 CPU CPU Schema DWH Schema Data Mining Eine Datenbank Schema CRM Schema Planung Schema Stammdaten

Options: RAC senkt die Hardware-Kosten im Data Warehouse massiv! • Geringere Anschaffungskosten • weil Options: RAC senkt die Hardware-Kosten im Data Warehouse massiv! • Geringere Anschaffungskosten • weil kleine Maschine im Vergleich zu den großen Monoliten • Wegfall Backup-Maschine • die RAC-Knoten sichern sich gegenseitig • Minimierte Anforderung an Rechenkapazität • weil ETL- und Abfragelasten flexibler verteilt werden können „Extrem“-Referenz: Amazon Beispiel in Deutschland: Quelle

Dispositive Anwendungen gemeinsam verwalten Data Mart Planung ETL Rechner DW Anwendungen 1 ETL, Planung Dispositive Anwendungen gemeinsam verwalten Data Mart Planung ETL Rechner DW Anwendungen 1 ETL, Planung Neutrales Data Warehouse Cache Fusion Instanz 1 Rechner DW Anwendungen 2 (DWH, BI, Mining) Instanz 2 Eine Datenbank Schema CRM Data Mart Mining SAN Storage Schema Planung Schema Stammdaten Schema DWH Schema Data Mining

Automatic Storage Management (ASM) DWH A DWH B Datenbank Management Dateisystemmanagement Automatic Storage Management Automatic Storage Management (ASM) DWH A DWH B Datenbank Management Dateisystemmanagement Automatic Storage Management Volumemanagement SAN Management Storage Management

ORACLE ASM Nutzen / Vorteile durch ORACLE ASM: Vereinfachtes Storagemanagement (weniger administrative Schritte) Kein ORACLE ASM Nutzen / Vorteile durch ORACLE ASM: Vereinfachtes Storagemanagement (weniger administrative Schritte) Kein Volumemanager notwendig manuelles IO-Tuning entfällt höhere Performance (ca. 15 %) durch „SAME“ und „Redistribute“ weniger „Verschnitt“ durch freie Bereiche Ein Storage für alle Datenbank-Objekte (Data. Files, Archive. Logs …) Spiegelung der Datenbereiche auf bis zu 3 Ziele automatische „Reparatur“ durch Rebalance (via redundantem Storage) verringerte Downtimes (geplant und ungeplant)