Oracle Warehouse TechnologieSingle-Engine-Based-Data-Warehouse

Performantes Data WarehouseEffiziente, integrierte Data Warehouse Architekturen auf der Basis von Oracle 10 g

Stichpunkte zuRessourcen – schonenden Techniken

mit dem Oracle – basiertenData Warehouse

Alfred SchlaucherGerd Schoen

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

InformationManagementundDataWarehouse

Datenmengen

Granularität

Latenzzeit

Anzahl Benutzer

Klassisch Trends

Data Warehouse Anforderungen

Anzahl Schnittstellen

Anzahl Benutzergruppen

StagePrüfungen

Data Warehouse Data Mart

ODS

Top LevelManagement

Mitarbeiter operative

Ebene

Beliebig kom

plexe Abfragen

Oracle DWH ReferenzarchitekturEnterprise Service BusAdapter Routing UDDI

Unified Repository

BPEL Process Manager

Rules

Rules

Rules

RulesNativBPEL

Work-flow

operative und dispositive MetadatenQualitätsstandards und Servives

Wahlfreie Analysenzugriffe

Kenn-zahlen-systeme

KundenProdukte

Wahlfreie Positionierung ETL.

MasterData Hub

BI Services

RAC Verbund

Oracle DWH Plattform

Analyse-Komplexität

GenerischeVerwendung

Experten/Spezial-anwendung

Austauschbare Frontends und Anwendungen

Data Mining

Komplexemultidim.

Ad Hoc Standard

3 8

I n t e g r i e r t e D a t a W a r e h o u s eP l a t t f o r m

Vorgelagerte zentrale Transformationen und generische KennzahlenData Quality Regelbausteine / abgebildete Business Rules

Fachspezifische Transformationen

KennzahlenAbonnement

Metadaten

Flexible Bereitstellung von Business Intelligence Informationen

Fachspez. Kennzahlen

Schema CRM

SchemaPlanung

SchemaDWH

SchemaData

Mining

SchemaStamm-daten

Verteilung der Last in einem RAC-Verbund - Tagsüber

Load-Job 1 InteraktiveAnalysen

Standard-Reporting

InteraktiveAnalysen

Eine Datenbank

CPU

CPU CPU

CPU CPU

CPU CPU

CPU CPU

CPU CPU

CPU CPU

CPU CPU

CPUKnoten 1 Knoten 2 Knoten 3 Knoten 4

Options: RAC

Schema CRM

SchemaPlanung

SchemaDWH

SchemaData

Mining

SchemaStamm-daten

Verteilung der Last in einem RAC-Verbund - Nachts

Load-Job 1 Load-Job 2 Standard-Reporting Load-Job 3

Eine Datenbank

CPU

CPU CPU

CPU CPU

CPU CPU

CPU CPU

CPU CPU

CPU CPU

CPU CPU

CPUKnoten 1 Knoten 2 Knoten 3 Knoten 4

Options: RAC

Verwaltung und DokumentationMetadatenOwnerschaftenGrid Control

Technologien und Verfahren zum Aufbau und

zur Verwaltung von Data Warehouse-Umgebungen

Effiziente Datenhaltung SpeichertechnikILMHardwareASMOLAP

Datenintegrationschnelles Bereitstellen DB-basiertes Laden MDMETL-Option Qualitäts-

managementData ProfilingData Auditing Daten-Zugriff

SecurityMandanten BI-Anwendungen

Standard-Berichte Interaktive BerichteData MiningKomplexe Analysen

Verwaltung und DokumentationMetadatenOwnerschaftenGrid ControlB&R

Technologien und Verfahren

Effiziente Datenhaltung SpeichertechnikILMHardwareASMOLAP

Datenintegrationschnelles Bereitstellen DB-basiertes Laden Master Data ManagementETL-OptionSAP Zugriff

Qualitäts-managementData ProfilingData AuditingData Rules

Daten-ZugriffSecurityMandanten BI-Anwendungen

Standard-Berichte Interaktive BerichteData MiningKomplexe Analysen

Data Quality Option

Enterprise-ETL

Label Security

Data Mining

OBI SE OBI EE

Gateways

Oracle Enterprise Edition

Compression Bitmapped Parallel Query FlashbackStreams

Data Guard

Repository (OWB) Partition

OLAP

RAC

RMAN

Diagnostic Pack

Tuning Pack

SAP Connect

Oracle EE

Themen

• Datenintegration und Modellbasiertes ETL Komponenten

InformationManagement

undData

Warehouse

„Lösungen“ der Vergangenheit

• Programmierung von Hand• Zerstreute Programm-Sourcen• Fehler bei der Entwicklung• Unnötige Doppelarbeit

• Schlechte oder fehlende Dokumentation• Schlechte Wartbarkeit• Enorme Folgekosten

• Unkündbare „Inselexperten“• Immer wieder „Katastrophen“

im Echtbetrieb

Wie wardas nur?

Die Geschichte der ETL-Tools geht in Richtung integrierter Werkzeuge

Handprogrammierung

1992 1996 2000

Programm-generatoren

SeparateEngine-gestützteETL-Werkzeuge

DatenbankbasierteETL-Werkzeuge

2005

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 ETL-Tool der Wahl in Oracle-Umgebungen!

• Design des kompletten Data Warehouse Systems• Logisches Design und Dokumentation • Physisches Oracle Datenbank Design• Fast alle Datenbankobjekte von Oracle 10g

• 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

Warehouse Datenbank

TabellenIndex

ViewMView

SequenzFunctionProcedure

Cube

Log

Access/Excel

MessageBroker

Siebel

Peoplesoft

Webservices

eMail

DB2 OS390, UDBSybase, Informix,SQL-Server...

Oracle (Remote)

XML

PL/SQLUTL_FILE

XML

DB-Link

Queue

Gateway

ODBC DB-Link

Queue

CDCtcp

Adapter

StreamsExt. TableSAP Int.

Schnittstellenkomponenten Oracle Data Warehouse

XMLPort

XML

FlatFile

FlatFile

FTPPort

FlatFile

SQL Loader

XML

In MemoryIn Memory nnnn JCAJCA COM+COM+ SOAPSOAP

WSIF & JBIWSIF & JBI

Enterprise Service BusEnterprise Service BusRoutingRouting QOSQOS BPELBPEL TransformTransform RulesRules

OWB live

Themen

• Data Quality und Data Profiling

InformationManagement

undData

Warehouse

Ohne Daten kein Business Unternehmen funktionieren nur mit Daten

Operative Prozesse

Information Chain

KundeKunden-betreuer

Logistik- system

Stamm- daten

Marketing

Buch-haltung

Lager Spedition

Kunde

BedarfAdresseKredit-daten

Angebot Bestand

Bestell-daten

KD-Daten

Kredit OK Order

Adresse

Werbung

Verkaufs-daten

Rechnung

Bezahlung Reklamation

Mahnung

Liefer-schein

Data Profiling mit OWB Methoden

Feintuning zuden Analyse-methoden

Die operativenDaten

Proto-kollierunglaufendeAnalysen

Drill Down zu den operativen Daten

Analyseumgebung

• Oracle Datenquellen• Alle Gateway-

lesbare Quellen• SAP-Daten• Flat Files• Adress-/LDAP-

VerzeichnisseSourceSchema

Profiling Stage

Oracle

SourceSchema Transportable

Module

ExternalTable

SAPSAPIntegrator

non OracleGateway / ODBC/ FTP Oracle 9i / 10g

RAC

DB2, SQL ServerInformix, Teradata

LDAP / DBMS_LDAP/ Table Function

Unterstützung von Software-Projekten

!

Übereinstimmung vonFeldname „...nr“ undFeldtyp

Durch den Feldnamenvermutet man rein numerische Inhalte

sieht gut aus

?

Kundennr ist ein wichtiges Feld. Es solltestimmig sein.

Firmenrabatt ist in der Regel ein Rechenfeld

Unterstützung von Software-Projekten

kritisch! da es sichum einen Schlüssel-kandidaten handelt

Felder sind nichtgepflegt

Die Zahl 17 kommt häufig vor, hier muss es eine „systematische“Ursache geben

kritisch! weil doppelteKundennummern

?

?

OK

Metadatenmanagement

Daten-OwnerschaftDie 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?

Entity

Data Set / Record(Name Location)

Stakeholder

Data Owner

Role

Abteilung

MitarbeiterCost

SubjectArea

Org

Zurück

Impact / Lineage - Metadatenanalyse

Aufbau eines DWH

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

Umsetzung in technische Lösungen - Dimensionale Sicht und relationale Datenbank

ProdukttabelleP1P2P3P4

P1P2P3P4

4 4

89

VerkäufeProd1Prod3Prod5Prod6

Lief1Lief4Lief5Lief9

1 : n Z1Z2Z3Z4

6.7.99Zeit

7.7.998.7.999.7.99

Q3Q3Q3Q3

Z1Z2Z3Z4

n : 1

Regionen

R1R2R3R4

MünchenBerlinHamburgFrankfurt

R1R2R3R4

Verkäufer

MaierMüllerSchmidEngel

V1V2V3V4

V1V2V3V4

1 : n

N : 1Starschema

• flexibel• Graphisch auch für Business-User verständlich

Einstiegspunktefür Abfragen

Umsätze

Orte

Regionen

Länder

Level 1 DefinitionenAttribute

Level 2DefinitionenAttribute

Level 3DefinitionenAttribute

Die Datenbank für das Warehouse fitmachen (Beispiele) Dimension

Ort

Zeit

Produkt

FK_OrtFK_ZeitFK_Produkt

Kunde

QueryRewrite

MaterializedViewPartitions

Parallel+Cluster

Bitmap-IndexStar-Transformation

Analytical-Functions

Partitioning

Fallbeispiel:4 Terabyte Warehouse einer der grössten Banken DeutschlandsMonatliches Ladevolumenvon mehreren 100 GB

• Ergebnisrechnung von 3000 Profitcentern• 4 Mill. Kunden• 8000 zugel. Nutzer• tägl. 2500 ReportServer- Zugriffe• tägl. 1500 Discoverer Zugriffe• tägl. Ca 800 Plain SQL Auswertungen

13 Tabellen

Jan 02Feb 02

Mar 02

Apr 02

Mai 02

Jun 02Jul 02

Aug 02

Sep 02

Okt 02

Nov 02

Dez 02

View

ViewView

Partitioning

• Hauptgründe für das Partitioning• Managebility• Abfrageperformance• Verfügbarkeit

• Arten des Partitioning• Range• List• Hash• Composite Range-Hash• Composite Range-List

Quartal

Jahr

Monat

Range-Partitionierung

Region

Zeit

Artikel

FK_OrtFK_ZeitFK_Produkt

Kunde

Umsatz

Qx9999Q12000

Q22000

Q32000

Nach Quartalenund Jahren partitioniert

Quartal

Jahr

Monat

Join-wise-Partitioning

Region

Zeit

Artikel

FK_OrtFK_ZeitFK_Produkt Kunde

Umsatz

1 2 34 5 67 8 9

123456789

Partition-Join1:12:23:34:45:56:67:78:89:9

Hash-Partition

Hash-Partition

Quartal

Jahr

Monat

Join-wise-Sub Partitioning (Range und Hash)

Region

Zeit

ArtikelFK_OrtFK_ZeitFK_Produkt Kunde

Umsatz

1 2 3

4 5 6

7 8 9

123456789

Partition-Join1:12:23:34:45:56:67:78:89:9Hash-Partition

Hash-Partition

Q22000

Q32000

Q42000

Range-PartitionnachZeit

Arten der Indizierung bei der Partitionierung

Partition 1

Partition 4

Partition 5

Partition 2

Partition 3

Partition 6

PartitionierteTabelle

LocalIndex

GlobalPartitioned

Index

GlobalNon Partitioned

Index

Fallbeispiel zur Lade- und Abfrageperformance

Customer1.000.000

Products10.000

Times2.557

Promotions1.001

Sales292.282.479

HP Proliant DL380 G36 GB RAM 2 CPU3 GHz

Allgemeines zum Verfahren300 MioSätze

Insert into TGT Select * from SRC

Index

TempTable

• 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 BitmapGesamtindex ca. 30 MB

Nachladen 1 Zeitscheibe Dezember 2004 Oracle 10G

Drop Partition

ALTER TABLE sales EXCHANGE PARTITION sales_dec_2004WITH TABLE sales_temp_dec_2004 INCLUDING INDEXES WITHOUT VALIDATION;

CREATE BITMAP INDEX sales_cust_id_bix_dec_2004 ON sales_temp_dec_2004 (cust_id) NOLOGGING PARALLEL;

INSERT INTO sales_temp_dec_2004 SELECT * FROM salesxt;

CREATE TABLE sales_temp_dec_2004 AS SELECT * FROM sales WHERE ROWNUM < 1;

ALTER TABLE sales ADD PARTITION sales_dec_2004 VALUES LESS THAN (TO_DATE('01-jan-2005','dd-mon-yyyy')); < 1 Sec

2

3

4

5

6

1< 1 Sec

< 1 Sec

< 1 Sec

2 Min 6 Sec

29 Sec

Nachladen 1 Zeitscheibe Dezember 2004 ohne 10G - Features

Neuerzeugen des Index

Laden neue Daten (parallel) mit External Table

Drop auf alle Indexe wenige Sekunden

2

3

16 Minuten

Platzverbrauch für BtreeGesamtindex ca. 1094 MB

insgesamt 800 Minuten

Löschen des alten Monats Januar 2002

Oracle 10g Traditionell

ALTER TABLE SALES DROP PARTITION SALES_JAN_2002;

ca. 1 Sec.

DELETE FROM SALES WHERE TIME_ID < TO_DATE('01-FEB-2002','DD-MON-YYYY');

7 Stunden 51 Minuten 28 Sekunden

Rollbacksegment wird genutzt:ca 4000 MB Plattenplatz

Abrageperformance

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;

Abfrage 1 Abfrage 2select 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-Q2' 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 = 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';

Quellen Stage

SRC1

SRC2Mart

Sich SelbstpflegendeMaterialized Views

Viele Auswertemodelle sind zu komplex für Endbenutzer (z. B. Snowflake)Komplizierte ETL-ProzesseAufwendige Erstellung und Wartung

Quellen StageSumme

SRC1

SRC2

ZusätzlicheVerdichtungs-/Abfragelogik

Summe

Mart

Inserts/ Updates

External Tables / Multiple InsertsMerge...

Aus 5 mach 3Verfahren einfach halten

Mandantenfähigkeit

Org.Linie

Reg Zeit

Org.Linie Prod

Mandantenfähige Data MartsAnwendungsbeispiel: Label-Security / Partitioning

Reg Zeit

Org.Linie Prod

Reg Zeit

Org.Linie Prod

Mandant 1(Abteilung A)

Mandant 2(Abteilung B)

Mandant 3(Abteilung C)

Prod

ZeitReg

Eine Kenn-zahlentabelle!

Physische getrennt gespeichert (als Partition)

Mandant1

Mandant 2

Mandant 3

Options: - Label-Security- Partition

Information Lifecycle Management

Information Lifecycle Management (ILM)

Information Lifecycle Management (ILM)mit Oracle ASM

Aktiv Weniger Aktiv Historisch Archiv

Dieser Monat Dieses Jahr Vorjahre

Disk Gruppe L Disk Gruppe H Disk Gruppe P

High End Storage $$$ Midrange Storage $$

Current MonthLast 11 months

Year 2002 and 2001 and 2000Years1995-1999

Historisches StorageLow End Storage $

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

ILM

ILM

Checkliste – Effizienter Betrieb DWHAlfred SchlaucherBU Database

Oracle Data WarehouseMit den Anforderungen wachsen

Verfahren und Techniken zum Aufbau und Verwalten von

Data Warehouse Umgebungen

Themen

• Sammlung von Effizienz steigernden Punktenim Data Warehouse

InformationManagement

undData

Warehouse

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

• Vereinheitlichung von Tools• Vermeiden von Tools-Inseln

• Administrationsaufwand bei isolierten Systemen ist oft sehr hoch

Oracle Warehouse TechnologieSingle-Engine-Based-Data-Warehouse

Alfred.Schlaucher@oracle.com

Themen

• Entwicklung multidimensionaler Modelle in der relationalen Datenbank

InformationManagement

undData

Warehouse

Umsetzung in technische Lösungen - Dimensionale Sicht und relationale Datenbank

ProdukttabelleP1P2P3P4

P1P2P3P4

4 4

89

VerkäufeProd1Prod3Prod5Prod6

Lief1Lief4Lief5Lief9

1 : n Z1Z2Z3Z4

6.7.99Zeit

7.7.998.7.999.7.99

Q3Q3Q3Q3

Z1Z2Z3Z4

n : 1

Regionen

R1R2R3R4

MünchenBerlinHamburgFrankfurt

R1R2R3R4

Verkäufer

MaierMüllerSchmidEngel

V1V2V3V4

V1V2V3V4

1 : n

N : 1Starschema

• flexibel• Graphisch auch für Business-User verständlich

Einstiegspunktefür Abfragen

Themen

• RAC

InformationManagement

undData

Warehouse

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

OrderOrder Entry Entry DWHDWHCRMCRM

1000IO/Sec

30% Kapazität

58%CPU

100%CPU

95% 70%

3500 IO/Sec,

23 %CPU

350IO/Sec,

KapazitätKapazität

• Dynamisches Load Balancing • Optimale Resourcen Auslastung • Reduzierter HW Bedarf• Weniger Oracle Lizenzen !

DWH CRM

Auslastung des GRID

100 %

60 %OE

65 %

Kapazität

CPU

• Kostengünstige Maschinen • In der Summe billiger• Mehr Ausfallsicherheit• Leichtere Skalierung

Grid Computing mit Oracle 10g

Themen

• SQL Advisor

InformationManagement

undData

Warehouse

Themen

• Automatisches Error Logging

InformationManagement

undData

Warehouse

DBMS_ERRLOG.CREATE_ERROR_LOG ( dml_table_name IN VARCHAR2, err_log_table_name IN VARCHAR2 := NULL, err_log_table_owner IN VARCHAR2 := NULL, err_log_table_space IN VARCHAR2 := NULL, skip_unsupported IN BOOLEAN := FALSE);

Fehlertabelle definieren

• Massen-DML (Set-Based)• Ohne Abbruch• Fehlerhafte Eingabesätze werden separat

protokolliert(analog SQL Loader und External Table)

SQL> desc ERR$_T3; Name Type ----------------------------------------- ------------- ORA_ERR_NUMBER$ NUMBER ORA_ERR_MESG$ VARCHAR2(2000) ORA_ERR_ROWID$ ROWID ORA_ERR_OPTYP$ VARCHAR2(2) ORA_ERR_TAG$ VARCHAR2(2000) F1 VARCHAR2(4000) F2 VARCHAR2(4000)

SQL> desc T3 Name Type --------------------------------- -------- -------- F1 NUMBER F2 NUMBER

insert into t3 values(1,2) LOG ERRORS INTO err$_T3

exec DBMS_ERRLOG.CREATE_ERROR_LOG ('T3')

1* select substr(ora_err_number$,1,10) Nr,substr(ora_err_mesg$,1,50) Err from ERR$_T3SQL> /NR ERR---------- --------------------------------------------------1 ORA-00001: unique constraint (DWH4.IDX_T3) violate

2

3

4

5

1

Themen

• Tabellen-Komprimierung

InformationManagement

undData

Warehouse

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%

Themen

• Real Application Cluster (RAC)• Automatic Storage Manager (ASM)

InformationManagement

undData

Warehouse

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

OrderOrder Entry Entry DWHDWHCRMCRM

1000IO/Sec

30% Kapazität

58%CPU

100%CPU

95% 70%

3500 IO/Sec,

23 %CPU

350IO/Sec,

KapazitätKapazität

• Dynamisches Load Balancing • Optimale Resourcen Auslastung • Reduzierter HW Bedarf• Weniger Oracle Lizenzen !

DWH CRM

Auslastung des GRID

100 %

60 %OE

65 %

Kapazität

CPU

• Kostengünstige Maschinen • In der Summe billiger• Mehr Ausfallsicherheit• Leichtere Skalierung

Grid Computing mit Oracle 10g

Schema CRM

SchemaPlanung

SchemaDWH

SchemaData

Mining

SchemaStamm-daten

Verteilung der Last in einem RAC-Verbund - Tagsüber

Load-Job 1 InteraktiveAnalysen

Standard-Reporting

InteraktiveAnalysen

Eine Datenbank

CPU

CPU CPU

CPU CPU

CPU CPU

CPU CPU

CPU CPU

CPU CPU

CPU CPU

CPUKnoten 1 Knoten 2 Knoten 3 Knoten 4

Options: RAC

Schema CRM

SchemaPlanung

SchemaDWH

SchemaData

Mining

SchemaStamm-daten

Verteilung der Last in einem RAC-Verbund - Nachts

Load-Job 1 Load-Job 2 Standard-Reporting Load-Job 3

Eine Datenbank

CPU

CPU CPU

CPU CPU

CPU CPU

CPU CPU

CPU CPU

CPU CPU

CPU CPU

CPUKnoten 1 Knoten 2 Knoten 3 Knoten 4

Options: RAC

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

Options: RAC

„Extrem“-Referenz: AmazonBeispiel in Deutschland: Quelle

Schema CRM

SchemaPlanung

SchemaDWH

SchemaData

Mining

RechnerDW

Anwendungen 1ETL, Planung

RechnerDW

Anwendungen 2(DWH, BI,Mining)

Cache Fusion

SchemaStamm-daten

Dispositive Anwendungen gemeinsam verwalten

ETL Data MartPlanung

NeutralesData Warehouse

Data MartMining

Eine Datenbank SAN Storage

Instanz 1 Instanz 2

Automatic Storage Management (ASM)

Storage Management

SAN SAN Management

Datenbank Management

Dateisystemmanagement

Volumemanagement

Automatic Storage Management

DWH A DWH B

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 (DataFiles,ArchiveLogs …) Spiegelung der Datenbereiche auf bis zu 3 Ziele automatische „Reparatur“ durch Rebalance (via redundantem Storage) verringerte Downtimes (geplant und ungeplant)