Oracle Warehouse Technologie Single-Engine-Based-Data-Warehouse
description
Transcript of Oracle Warehouse Technologie Single-Engine-Based-Data-Warehouse
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
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
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)