Oracle Developer Day Data Warehouse Von Konzept bis …€¦ · Oracle 10g /11.1/11.2...
Transcript of Oracle Developer Day Data Warehouse Von Konzept bis …€¦ · Oracle 10g /11.1/11.2...
<Insert Picture Here>
Oracle Developer Day Data Warehouse
– Von Konzept bis Betrieb
Christoph Blessing / Detlef Schroeder / Alfred Schlaucher
Themen
• 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
• ODD Data Warehouse
Was macht das DWH-Konzept so
erfolgreich (auch nach 15 Jahren) ?
Zentrale
Bereit-
stellung
Business-
Daten
Semantik
Historisch
(-> Trends)
Entkop-
plung von
op. System
Flexibel und unabhängig
von operativen
Anwendungen
analysieren können
Daten sollten zentral
und leicht für alle
Benutzergruppen
gleichermaßen
zugänglich sein
Daten sollten leicht
leicht verstehbar sein
- Informationen statt Daten
- Semantische Zusammen-
hänge
Trendfähige
Informationen durch
Aufbewahrung und
Aufbereitung
historischer Daten
A
1 2
3 4
3
Evolution des Data Warehouse ¾ unserer Kunden nutzen ihr DWH auch zu operativen Zwecken
Komplexe Informations-
Ausarbeitung und Analysen
Jahr/Quartal/Monat
Periodische Berichte
Woche/Tag oft und schnell
wiederholbare Einzel-
informationen
Stunde/Minute/Sekunde/Realtime
überschaubar
Hochvolumig / granular
Taktisch
Überschaubar / aggregiert
DWH
Strategisch
Operativ
4
PD4711
AMKLB
9987865234
7769
0000000
KLABAUTER
IIO
???
EERWEERW
883466
888750000
888000
EU-Wert
735328567353654
i8886345
7746
PRODUKTDATEN
Produktsparten
Spartenname
Spartennr
Produktgruppen
Gruppenname
Gruppennr
Produkte
Produktname
Produktenr
Einzelpreis Müll, Altlast,
unverständliche
Daten
Operative
Daten
Normalisierte
Daten (DWH)
Spartenname
Spartennr
Gruppenname
Gruppennr
Produktdaten
Produktname
Produktenr
Einzelpreis
Neu
sortierte
Daten
Prinzip Normalisieren / Denormalisieren Granularisierung als Lösung
Verständliche
Information
(denormalisiert) Granulare Daten
Im DWH 5
Das Neutralitätsprinzip des DWH A
ny S
ourc
e/T
arg
et S
yste
m
Enterprise Information Layer
(Kern DWH)
Data
In
tegra
tion
User View Layer
(Data Marts)
Data Integration Layer
(Stage)
Process neutral / 3 NF
Any U
ser
Gro
up
Prüfen
Integrieren
Harmonisieren
Standardisieren
Erweitern
Verbinden
In Beziehung setzen
Anwenden
Aufbereiten
Aggregieren
Rohdaten Angebot Bedarf
Redundanzen
Anwendungs-
neutral,
granular,
Zeit-neutral
Neutral gegenüber
Vorsystemen,
Sprachen, OS
Neutral gegenüber
Endbenutzern:
Alle User! Alle Tools!
6
Reporting & Publishing
Ad-hoc Analysis
Office Integration
Mobile
Scorecards
Interactive Dashboards
BI Server
Oracle Database Management System
Oracle Data Warehouse Architektur für
unternehmensweites Datenmanagement D
ata
In
tegra
tion
Real T
ime &
Batc
h
Any
Source
Controlling
Financial
Marketing
Sales
HR
BI Apps
Dynamic Data Marts Data Quality Rules Checks&Monitoring
DWH Logistic Utilities Business
Catalogue
Technical
Auditing Metadata
Utilities
Lifecycle Management Concept
DWH System Monitoring Utilities
DWH Security Utilities
DWH Backup / Recovery Concept
Concept Framework Big Data
Appliance
Exadata Exalytics
Operational Data Layer
Information Layer Architecture Concept
Enterprise Information Layer
User View Layer Data Integration
Layer
noSQL Hadoop
Big Data Solution
Reference Data Models Data Management Concept
InDatabase
ROLAP
InDatabase
MOLAP
InDatabase
Data Mining R InDatabase
Optimiertes Netzwerk
Server
Cluster
Operating
System
Optimized Network
Storage
Hierarchy Server Cluster
Exadata / Database Machine / Exalytics
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
Kunde Artikel kauft
wird geliefert
Analysemodell – Prozess-Sicht Was wissen wir über den Prozess?
Sta
mm
date
n-
Info
rmati
on
en
Sta
mm
date
n-
Info
rmati
on
en
Akti
vit
äte
n-
Info
rma
tio
nen
:
“W
as g
esch
ieh
t”,
Bew
eg
un
gsd
ate
n
Zeit
Ort
+
Bewegungsdaten
Stamm-Objekte
Eigenschaften
Stammobjekte
9
Kunde
Kontakt-
person
KD#...
Status
Privatkd
...
Firmenkd
...
Bestellung
Externe
Personen
tätigt
Status
Bestelldatum
Lieferdatum
Artikel
...
Name
Gruppe
Sparte
Gruppe
...
Sparte
...
• Kandidaten für Dimensions-Hierarchien finden
• Schlüsselpaare PK / FK für spätere Fakten-Joins
Generalisierung Spezialisierung
Objektmodell (Datensicht) Strukturierung und Beziehungen der Objekte
Jahr
Monat
Tag
Region
Land
Ort
Bewegungsdaten
Stamm-Objekte
Eigenschaften
Stammobjekte
10
Gesammelten Input zusammenfassen
Entwürfe für multidimensionale Sichten
• Stammdaten Kandidaten für Dimensionen
• Bewegungsdaten Kandidaten für Fakten
• Generalisierung Kandidaten für Hierarchie-Level
• Spezialisierung potentielle Ausprägung
11
Multidimensionales Modell (Star Schema)
Artikel
A1
A2
A3
A4
A1
A2
A3
A4
4
4
8
9
Verkäufe
Art1
Art2
Art3
Art4
1 : n Z1
Z2
Z3
Z4
6.7.09
Zeit
7.7.09
8.7.09
9.7.09
Q3
Q3
Q3
Q3
Z1
Z2
Z3
Z4
n : 1
Regionen
R1
R2
R3
R4
Nord
Sued
West
Ost
R1
R2
R3
R4
Kunde
Maier
Müller
Schmid
Engel
V1
V2
V3
V4
V1
V2
V3
V4
1
:
n
n
:
1
Einstiegspunkte
für Anwender-Abfragen
Star Schema
• Flexibel
• Graphisch auch für
Business-User
verständlich
P
P
F
F
Blau
Gelb
Rot
Lila
Schwach
Mittel
Hoch
Schwach
Status
Farbe
Wohndichte
12
Dimensionen
Artikelgruppe
Sparte
Dim_Artikel
Artikel_Langtext
Artikelsparte
Artikel
Artikel_Schlüssel
Artikelgruppe_Langtext
Artikelsparte_Langname
Parent
Parent
Fakten
Levelschlüssel
Levelschlüssel/
Objektname
Levelschlüssel
Business Key
Künstlicher
Dimension Key Dim_Schlüssel
Aggregation
Aggregation
13
Spielarten des Star Schemas
Degenerate Facts
Degenerate Dimensions
Conforming Dimensions
Factless Facts
Slowly changing dimensions
Ort
Kreis
Land Hierarchie
Zeit
Produkte
Zentrale
Fakt-
Tabelle
Teil von
Parent Connect by
Lieferant
Gelieferte
Teile
Bestell-
kosten
Fakt
Intersection- Table
(Degenerated Fact)
Verkäufer Verkäufer
Verkaufs-
anteil
Fakt
Umsatz
Pro
Verk.
Heterogenious
Fact
Drill Down
Roll up
Drill Across
Slice / Dice
Pivot
14
Spielarten des Star Schemas
Degenerate Facts
Degenerate Dimensions
Conforming Dimensions
Factless Facts
Slowly changing dimensions
Zeit
Produkte
Verkauf
Fakten
Produkt
Gruppe
Connect by
Lieferant
Gelieferte
Teile
Bestell-
kosten
Fakt
Intersection- Table
(Degenerated Fact)
Verkäufer Verkäufer
Verkaufs-
anteil
Fakt
Umsatz
Pro
Verkäufer.
Heterogenious
Fact
Drill Down
Roll up
Drill Across
Slice / Dice
Pivot
15
Teile
Teil von
Parent Sparte
Region
Land
Kreis
Ort
Region
Benutzte
Teile
Degenerated Dimension
Zeit
Produkte
Summe
Prodname
ProdNr
BestellNr. Vorgangsnr. KD.Nr KD.Name ProduktNr
Attribute von degenerated
Dimensions
Bestellungen
BestellNr
Vorgangnr
Kunden
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.
16
Factless Fact Table
Zeit
ZeitNr
Produkt
ProduktNr
Verkäufer
VerkauferNr
ZeitNr
ProduktNr
VerkauferNr
17
Dimensionen
Artikelgruppe
Sparte
Dim_Artikel
Artikel_Langtext
Artikelsparte
Artikel
Artikel_Schlüssel
Artikelgruppe_Langtext
Artikelsparte_Langname
Parent
Parent
Fakten
Levelschlüssel
Levelschlüssel
Levelschlüssel
18
Star vs. Snowflake Schema
19
Auslagern von Attributen Häufig oder weniger häufig genutzt
Separate
Dimension
20
Die Schichten im Detail
Die (Kern-) Data Warehouse - Schicht
An
y S
ourc
e/T
arg
et S
yste
m
Enterprise Information Layer
Data
In
tegra
tion
User View Layer Data Integration Layer
Process neutral / 3 NF
An
y U
se
r G
roup
Operational Data Layer
21
Oracle Data Warehouse
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
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
ETL
24
Oracle Data Warehouse
Daten-nahe Transformation im DWH Den richtigen Platz finden
n-tier
Application Server
n-tier
Application Server
Quellsystem DWH-System
ETL?
ETL?
25
Data Mart
Staging
Area
Warehouse Stage
Data Mart
Data Mart
CRM
ERP ETL: Kosten
pro Kunde
ETL: Kosten
pro Kunde
ETL: Kosten
pro Kunde
ETL: Kosten
pro Kunde
!
Der Sinn des 3-Schichten-Modells Aus Sicht des Ladeprozesses
26
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
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
Log
Oracle
Database
DB2 OS390, UDB
Sybase, Informix,
SQL-Server...
Gateway Access/Excel
ODBC
Flat File
SAP
DB-Link
Queue
CDC
PL/SQL
UTL_FILE
XML
Oracle (Remote)
tcp
Adapter
MessageBroker
XML
DB-Link
Queue
Tabellen View
MView
Sequenz
Function
Cube
Streams
Siebel
Peoplesoft
Webservices
SQL Loader
Ext. Table
XML
DataPump
Golden Gate
JDBC Agent
Procedure
Index
Queue
Quellen und Ziele
Oracle 10g /11.1/11.2 (Warehouse-Datenbank)
Remote DB
(Source DB)
OWB11.2 WindowsXP,
Vista, 7 oder
Linux
generiert
OWBSYS-Schema
Oracle 10g /11.1/11.2
Warehouse
tabellen Warehouse
tabellen Warehouse
Tabellen
Metadaten
DB Link
Datentransfer
OWB Architektur
Workspace
OWB112
DWH-Zielschema
PL/SQL
OLTP-Quellschema
Control
Center
Service
Control
Center
Agent
Der Mapping-Editor
Graphik und SQL
Table Function External Table UNION XML
MINUS Merge PL/SQL Distinct Multiple
Insert
Filter Call Multiple
Targets
Lookup
Text
Files
Graphik und SQL
Metadaten-Dependency-Manager
• Key Architecture Benefits: 100% Java, Open APIs, fast E-LT
D A
B
File
C
C$_0
C$_1
LKM
LKM
IKM
I$ E$ (Errors)
CKM IKM
RKM
JKM
Check-Load Transform Extract-Load
ODI
Agent
Packaged
Application
Business Intelligence
& Data Warehouse
ODI Agent may be
deployed in any part
of the architecture
E-LT Architecture with ODI-EE High Performance, Flexible, Lightweight Architecture
Wer glaubt schon bunten Charts?
Ohne Daten kein Business Schlechte Daten sind wie Sand im Getriebe der Geschäftsprozesse
Operative Prozesse
Information Chain
Kunde Kunden- betreuer
Logistik- system
Stamm- daten
Marketing
Buch- haltung
Lager Spedition
Kunde
Bedarf Adresse Kredit- daten
Angebot Bestand
Bestell- daten
KD-Daten
Kredit OK Order
Adresse
Werbung
Verkaufs- daten
Rechnung
Bezahlung
Reklamation
Mahnung
Liefer- schein
Wo sollten Korrekturen stattfinden
Data
Warehouse Data Load
Correction
Operative Anwendung
Vorsysteme bzw. Fachabteilungen sind in der Pflicht!
Wo sollten Korrekturen stattfinden
Data
Warehouse
Data Load
Correction
Operative Anwendung
Operative Anwendung
Operative Anwendung ?
Fehlende Praxis in
Datenmanagement
Gewachsene Bedeutung
des Faktors Information
für den Erfolg von
Unternehmen.
Ausufernde
Datenmengen Vermehrtes Inseltum
durch Fertig-
Anwendungen
Daten-
qualität
Immer häufigere
Prozessänderungen
Warum wächst die Herausforderung
der Qualität der Daten
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
Methoden und Hilfsmittel
• Vorgehensmodell
• Datenmodellierung
• Datenqualitätsprüfmethoden
• Data Profiling
• Data Profiling Tool
• Attribut-Klassifizierung (Namen)
• Kategorisierung von Qualitätsregeln
• ETL-Tool
• Datenbank
Zieldefinition
Bestandsaufnahme
Planen
Strukturanalysen
Regelanalysen
Umsetzung Ergebnisse
Erwartungen Geschäftsregeln
Owner User Ressourcen Kosten Modelle
Felder
Priorisieren Problemkomplexe
Objekte Beziehungen Hierarchien
Daten Werte Fach
Abgleich-Alt Neudefinition Monitoring
Top D
ow
n B
otto
m U
p
Vorgehensmodell Datenqualitätsanalyse
6 Phasen, 95 Aktivitäten, 16 Ergebnis-Templates, 1 Metamodell, Klassifizierungen
Auswahl und Ergebnisansicht Methoden
Chart-Darstellung
Tabellen-Darstellung
Drill-Werte
Operative Datensätze
Die Tabellen,
die zu dem
Analyse-
fukus
gehören
Feintuning
zu den
Analyse-
methoden
Analyse-
Job-
Protokolle Aktivierbare Business Rules
Starten eines
Profiling-Laufs
Starten einer Correction-
Mapping-Generierung
Generierung-
Rule
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
Agenda
• Oracle Partitioning
• Compression
• Indizes
• Star Query Transformation
• Parallelisierung
• Result Cache
• Materialized Views
• Analytische Funktionen
• Oracle OLAP/ Cube-organized Materialized Views
Oracle Partitioning
49
Oracle Data Warehouse
Partitioning unterstützt viele Aufgaben
Query Performance
Partition Pruning Ladeprozess
Hochverfügbarkeit auch
während des Ladens und
Maintenance
Leichterer Umgang mit
Indizierung
Unterstützung ILM
(Information Lifecycle
Management)
Unterstützung im
Backup-Prozess
Unterstützung bei
der Aktualisierung
von Materialized Views
(Partition Change Tracking)
Unterstützung bei der
Komprimierung
Partitioning
Partitionierungs-
Kriterium fachlich
anwendbar oder
nicht?
Partitioning Typ:
- Range
- List
- Hash
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
SQL-Abfrage ist von Partitionierung unabhängig
• Gesamte Tabelle selektieren
• Abfrage nur auf eine Partition
Partitioning ist transparent
Jan 2007
Feb 2007
Mär 2007
Apr 2007
Mai 2007
Jun 2007
SELECT * FROM orders;
SELECT * FROM orders
WHERE order_dat between
to_date ('2007-01-01') AND
to_date ('2007-01-31');
Alle Partitionen werden selektiert
Partition Pruning:
Automatische Beschränkung
auf betroffene Partition
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
• Partitionierung nach Wertebereichen
• Für sortierte Wertebereiche
• LESS THAN:
Angabe eines maximalen Wertes pro Partition
Range Partitioning
Partitionierung nach Wertebereichen
Jan 2007
Feb 2007
Mär 2007
Apr 2007
Mai 2007
Jun 2007
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('2007-02-01','YYYY-DD-MM')),
PARTITION M2 VALUES LESS THAN
(to_date('2007-03-01','YYYY-DD-MM')),
:
54
Range Partitioning
Neue Tabellenzeilen
• Partition für neue Tabellenzeile muss vorhanden sein
• Lösung I: MAXVALUE-Partition
• Lösung II: Eigene Jobs
• Lösung III: Oracle11g
FEHLER in Zeile 1:
ORA-14400: Eingefügter Partitionsschlüssel kann keiner
Partition zugeordnet werden
55
Range Partitioning
Alphabetische Sortierung in den Partitionen CREATE TABLE kunde_part_alpha
(
kundennummer NUMBER,
vorname VARCHAR2(20),
kundenname VARCHAR2(40)
)
PARTITION BY RANGE (kundenname)
(
PARTITION kunde_ae VALUES LESS THAN ('F%') TABLESPACE part_range1,
PARTITION kunde_fl VALUES LESS THAN ('M%') TABLESPACE part_range2,
PARTITION kunde_mr VALUES LESS THAN ('S%') TABLESPACE part_range3,
PARTITION kunde_sz VALUES LESS THAN (MAXVALUE) TABLESPACE part_range4
);
56
• 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
Hash Partitioning
Gleichverteilung der Daten
CREATE TABLE orders (
order_no number,
part_no varchar2(40),
ord_date date
) PARTITION BY HASH (ord_date)
PARTITIONS 4
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
• Für diskrete, unsortierte Werte
• Angabe einer Werteliste pro Partition
• VALUES (DEFAULT) für “alles andere”
• Verhalten wie MAXVALUE in der Range-Partitionierung
List Partitioning
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)
)
AMER
EMEA
APAC
59
Sales Table
May 22nd 2008
May 23rd 2008
May 24th 2008
May 18th 2008
May 19th 2008
May 20th 2008
May 21st 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’);
Wie hoch waren die
Verkäufe für das
Wochenende vom
20-22 Mai 2008?
Nur die 3
relevanten
Partitionen
werden be-
trachtet
Partition Pruning
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
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
Interval Partition automatisch angelegt
Januar
Februar
März
April
Januar
Februar
März
April
Januardaten
Aprildaten
Februardaten
Märzdaten
Mai Maidaten ?
Kunden
Pro
du
kte
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(' 2007-01-31 00:00:00', 'SYYYY-MM-DD HH24:MI:SS',
'NLS_CALENDAR=GREGORIAN'))
TABLESPACE "TS_PAR",
PARTITION "Feb07"
VALUES LESS THAN (TO_DATE(' 2007-02-28 00:00:00', 'SYYYY-MM-DD HH24:MI:SS',
'NLS_CALENDAR=GREGORIAN'))
TABLESPACE "TS_PAR"
)
;
64
• 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
Reference Partitioning
FK FK
65
Reference Partitioning
Januar
Februar
März
April
Bestellungen
Januar
Februar
März
April
Bestell_Positionen
BestellNr KundenNr BestellDatum
BestellNr ArtikelNr Menge
FK
PK
Januar
Februar
März
April
Auslieferungen
BestellNr LieferNr
FK
PosNr
PosNr
PK
66
Sub- und Composite Partitioning
67
Oracle Data Warehouse
Composite Partitioning
• Range ...
• Range - Range [Oracle11g]
• Range - Hash [Oracle8i]
• Range - List [Oracle9iR2]
• List ...
• List - Range [Oracle11g]
• List - Hash [Oracle11g]
• List - List [Oracle11g]
1st Level:
Interval Partitioning möglich
2nd Level:
Interval Partitioning nicht möglich
68
Composite Partitioning
• Kombinationen: Ein Beispiel für Range - List
Produkt
Service
Storno
JAN 07 FEB 07 MAR 07
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
• Package DBMS_ADVISOR
Tuning Pack
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
Monat 10
Monat 11
Monat 12
Monat 13
Faktentabelle
Zeit
Region
Financial
Production
Human Res.
Store
Supplier
Marketing
Service
Neuer Monat
P1
P2
P3
P4
4
4
8
9
Z1
Z2
Z3
Z4
Temporäre
Tabelle
Parallel Direct Path INSERT
(Set Based) CREATE TABLE AS SELECT
(CTAS) CREATE Indizes / Statistiken anlegen
EXCHANGE Tabelle
Partition Exchange Loading (PEL)
DROP
PARTITION
• Unvergleichbar schnell!
72
• 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)
Information Lifecycle Management
Rolling Window Operationen
Jan 2008
Feb 2008
Mar 2008
Apr 2008
May 2008
Jun 2008
Jan 2010
:
73
Information Lifecycle Management (ILM) Mit Partitionierung und Storage Layern
DG "Standard" DG "Historic"
Entry Level Storage €
Disk Group (DG) "High Perf "
High End Storage €€€ Midrange Storage €€
2009 2006 2008 1990-
2005
• Für die Anwendung sind die
Daten eine Tabelle
• Unterschiedliche Bereiche auf
unterschiedlichen Storages
• Bedarfsgerechte Performance
und Kosten
74
Einsatz von Compression
75
Oracle Data Warehouse
Das Datenwachstum beherrschen Komprimieren: Verwaltung und Kosten reduzieren
Kompressions Typ: Einsatz für: Faktor
Basic Compression Read only Tabellen und Partitionen in Data
Warehouse Umgebungen oder “inaktive” Daten-
Partitionen in OLTP Umgebungen.
2-4
OLTP Compression Aktive Tabellen und Partitionen in OLTP und Data
Warehouse Umgebungen.
2-4
SecureFiles
Compression
Non-relational Daten in OLTP und Data Warehouse
Umgebungen.
2-4
Index Compression Indizes auf Tabellen in OLTP und Data Warehouse
Umgebungen.
2
Backup Compression Alle Umgebungen. 2
Hybrid Columnar
Compression –
Data Warehousing
Read only Tabellen und Partitionen in Data
Warehouse Umgebungen.
8-12
Hybrid Columnar
Compression –
Archival
“Inaktive” Daten Partitionen in OLTP und Data
Warehousing Umgebungen.
10-40
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
Advanced Compression in Oracle 11g
Overhead
Free Space
Uncompressed
Compressed
Inserts are uncompressed
Block usage reaches PCTFREE – triggers Compression
Inserts are again uncompressed
Block usage reaches PCTFREE – triggers Compression
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:
• Im Enterprise Manager:
CREATE TABLE sales_history(…) COMPRESS
FOR BASIC | OLTP
79
Schlüssel im
DWH und Indizierung
80
Oracle Data Warehouse
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
Umschlüsselung
Alter
Name
Kunden_NR
Anzahl Kinder
Berufsgruppe
Wohnart
Einkommensgruppe
Ort
PLZ
Verkaufsregion
Kunden_NR
Strasse
Ort
PLZ
Tel
Partnernummer
Partnernummer
Wohnart
Einkommensgruppe
Verkaufsregion
Dim_Kd_NR
...
Sequence
Anwendung 2
Anwendung 1
Data Warehouse
Neuer Schlüssel
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
B*Tree Index – 4 Zugriffe bis zum Wert
Zugriff über die
RowID
1
2
3
4
84
Clustering
Factor
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
AAAHfVAAJAAAKOKAAB
AAAHfVAAJAAAKOKAAC
AAAHfVAAJAAAKOKAAD
AAAHfVAAJAAAKOKAAE
AAAHfVAAJAAAKOKAAF
AAAHfVAAJAAAKOKAAG
AAAHfVAAJAAAKOKAAH
Abschluss=
Klasse_10
Abschluss=
Abitur
Abschluss=
Diplom
Abschluss=
Doktor
1
0
0
0
0
1
0
0
0
1
1
0
0
0
1
1
0
0
0
1
0
0
0
0
0
0
0
0
1
0
0
0
SELECT Name
FROM KD_Table
WHERE Abschluss=‘Diplom‘;
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
Platzverbrauch im Vergleich Tests mit unterschiedlicher Kardinalität
SELECT index_name,index_type blevel, leaf_blocks, distinct_keys
FROM user_indexes;
CREATE TABLE I_Kunde
(KD_NR number,
Name varchar2(30),
Geb_Dat date,
Bildungsgruppe varchar2(30),
KR_Rating_1_bis_Variabel number);
Anzahl
Sätze
Distinct
Werte Prozent
Leaf_
Blocks
BTree
Leaf_
Blocks
bitmap
Bildungsgruppe 100000 5 0.005 271 11
Bildungsgruppe 100000 100 0.1 192 34
Geb_Dat 100000 14575 14.575 265 97
KR_Rating_1_bis_Variabe 100000 43211 43.211 220 179
KD_NR 100000 100000 100 222 348
87
Rebuild Index Operation
• 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 index_name REBUILD [ NOLOGGING ];
88
alter index PK_BESTELLNR_PART_RANGE_HASH monitoring usage
SELECT INDEX_NAME, TABLE_NAME, MONITORING, USED FROM SYS.V$OBJECT_USAGE
Wo und wie wird im DWH indiziert
Enterprise Information Layer
User View Layer Data Integration Layer
Process neutral / 3 NF
Keine Indexe B*tree für Eindeutigkeit
und als Primary Key
Bitmaps
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
Bitmaps
Bitmap Join
B*tree für Primary Keys
In den Dimensionen
Tabellen
Physische Strukturen im Star Schema Data Mart-Schicht
Reg Zeit
Org.
Linie Prod
Primary Key Constraint
PK Constraint PK Constraint
PK Constraint
Foreign Key (NOT NULL)
Komprimiert
Partitioniert
Lokale Indizes
Security
Verschlüsselung
Dimensionsobjekt Dimensionsobjekt
Dimensionsobjekt
Bitmap-Index
Dimensionsobjekt
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
Star Query Transformation
92
Oracle Data Warehouse
SELECT sum(summe) FROM
F_Bestellungen B,
D_Artikel A,
D_Region R,
D_Zeit Z,
D_Kunde K
WHERE
B.FK_Kunden_ID = K.Kunden_ID
AND B.FK_Datum_ID = Z.Datum_ID
AND B.FK_Ort_ID = R.Ort_ID
AND B.FK_Artikel_Nummer = A.Nummer
AND Z.JAHR_NUMMER = 2008
AND A.GRUPPE_NR = 3
AND K.KUNDENART = 8
AND R.REGION_Name IN ('MITTE','SUED','NORD');
Star Query Transformation Optimierung für Joins mit großen Faktentabellen
1.000.000
65
12.834
3.074
1.029
93
STAR_TRANSFORMATION_ENABLED=FALSE; Abgelaufen: 00:00:03.48
Ausführungsplan
----------------------------------------------------------
Plan hash value: 876979892
--------------------------------------------------------------------------------------
| Id | Operation | Name Rows |Bytes |Cost (%CPU)| Time |
----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | 1 | 50 |1057 (2)| 00:00:13
| 1 | SORT AGGREGATE | 1 | 50 | |
| 2 | NESTED LOOPS | | | |
| 3 | NESTED LOOPS | 12 | 600 |1057 (2)| 00:00:13
|* 4 | HASH JOIN | 31 | 1209 |1026 (2)| 00:00:13
|* 5 | HASH JOIN | 121 | 3993 |1022 (2)| 00:00:13
|* 6 | TABLE ACCESS FULL | D_ZEIT 152 | 1216 | 7 (0)| 00:00:01
|* 7 | HASH JOIN | 2459 |61475 |1015 (2)| 00:00:13
|* 8 | TABLE ACCESS FULL | D_KUNDE 3 | 18 | 9 (0)| 00:00:01
| 9 | TABLE ACCESS FULL | F_BESTELLUNGEN 1010K| 18M|1001 (2)| 00:00:13
|* 10 | TABLE ACCESS FULL | D_ARTIKEL 16 | 96 | 3 (0)| 00:00:01
|* 11 | INDEX UNIQUE SCAN | PK_REGION 1 | | 0 (0)| 00:00:01
|* 12 | TABLE ACCESS BY INDEX ROWID| D_REGION 1 | 11 | 1 (0)| 00:00:01
----------------------------------------------------------------------------------------
94
Abgelaufen: 00:00:00.76 Ausführungsplan
----------------------------------------------------------
Plan hash value: 4213778833
------------------------------------------------------------------------------------------------
| Id | Operation | Name |Rows | Bytes| Cost (%CPU)| Time|
-------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 19 |199(2)| 00:00:03 |
| 1 | SORT AGGREGATE | | 1 | 19 | | |
| 2 | TABLE ACCESS BY INDEX ROWID | F_BESTELLUNGEN | 14 | 268 |199(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 | 3 | 18 | 9(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 | 16 | 96 | 3(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 | 152 | 1216 | 7(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 |5069 |55759 | 69(0)| 00:00:01 |
|* 20 | BITMAP INDEX RANGE SCAN| IDX_FK_ORT_ID_BM | | | | |
------------------------------------------------------------------------------------------------
STAR_TRANSFORMATION_ENABLED=TRUE;
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
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 15000 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
Parallelisierung
103
Oracle Data Warehouse
Parallelisierung und Skalierung
• Abfragen
• SELECT
• JOIN-Operationen
• SORT-Operationen
• GROUP BY
• DDL
• CREATE TABLE / MV
• CREATE INDEX
• Online Index Rebuild
• DML
• INSERT
• UPDATE / DELETE
• MOVE / SPLIT PARTITION
CPU SQL
seriell 100%
50%
I/O
100%
50%
parallel
SQL CPU I/O
Ein SQL Statement wird vom
Optimizer in kleinere Arbeitsschritte
aufgeteilt und läuft skalierbar ab.
104
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
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
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
Funktionsweise von Automated DOP
SQL Statement
Statement wird geparsed
Optimizer ermittelt Execution Plan
Statement wird seriell ausgeführt
Statement wird parallel ausgeführt
Optimizer bestimmt idealen DOP
Geschätzte Ausführung ist größer als Schwellwert
Tatsächlicher DOP
= MIN(Default DOP, idealer DOP) Geschätzte Ausführung ist kleiner als Schwellwert
PARALLEL_MIN_TIME_THRESHOLD
108
Parallel Statement Queuing SQL Monitoring im Enterprise Manager
Awaiting screen shot from EM
Uhrsymbol zeigt ein
wartendes Statement
an
Klicken auf SQL ID für
weitere Informationen
109
Query Result Cache
110
Oracle Data Warehouse
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
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
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.
• Falls RESULT_CACHE_MODE=FORCE gesetzt ist,
dann erfolgt ein automatisches Einfügen des Hints im Root-SELECT
SELECT /*+ result_cache */ count(*) FROM sales
SELECT count(*) FROM sales ...
113
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
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: http://www.oracle.com/global/de/community/dbadmin/tipps/result_cache/index.html
Materialized Views
116
Oracle Data Warehouse
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
Ä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
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
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
Reg Zeit
Org.
Linie Prod
MAV
MAV
MAV
MAV
MAV
Aggregations-
level 1
Aggregations-
level 2
. . Top Management
(wenige hochverdichtete
Kennzahlen)
. . Sachmitarbeiter
Planung / Marketing
(verdichtete Daten)
. .
Mitarbeiter
operative Ebene
(Detaildaten auf dem
Level von operativen
Transaktionen)
Skalierung bei der Auswertung Architekturbasierte Anwendergruppen-Unterstützung
Aggregat Summentabelle
Summentabelle (Meier)
Summentabelle (Müller)
. . . . . .
. .
Detaillevel 0
121
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
Materialized Views Query Rewrite
123
Oracle Data Warehouse
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
Exaktes Text-Matching
• Umstellen der Spalten und avg() anstelle von sum()
SELECT
z.jahr_nummer Jahr,
sum(u.umsatz)Summe,
a.artikel_id ID,
z.monat_desc Monat
FROM
f_umsatz u,
d_artikel a,
d_zeit z
WHERE
a.artikel_id = u.artikel_id AND
u.zeit_id = z.datum_id
GROUP BY
z.jahr_nummer, z.monat_desc,
a.artikel_id;
SELECT
z.jahr_nummer Jahr,
avg(u.umsatz) Schnitt,
a.artikel_id ID,
z.monat_desc Monat
FROM
f_umsatz u,
d_artikel a,
d_zeit z
WHERE
a.artikel_id = u.artikel_id AND
u.zeit_id = z.datum_id
GROUP BY
z.jahr_nummer, z.monat_desc,
a.artikel_id;
F_ARTIKEL
SPARTE_NAME
SPARTE_NR
GRUPPE_NAME
GRUPPE_NR
ARTIKEL_NAME
ARTIKEL_ID
F_UMSATZ
ARTIKEL_ID
ZEIT_ID
KUNDE_ID
REGION_ID
UMSATZ
MENGE
BESTELL_DATUM
D_ZEIT
DATUM_DESC
TAG_DES_MONATS
WOCHE_DES_JAHRES
JAHR_NUMMER
QUARTALS_NUMMER
MONATS_NUMMER
MONAT_DESC
DATUM_ID
sum / count
125
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
Prinzip Aggregate Rollup
SELECT
z.jahr_nummer Jahr, --> Bezugsgröße in MAV ist 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, a.artikel_id;
• Abfragen lässt sich alles, was in der GROUP BY-Klausel
der MAV zu finden ist
F_ARTIKEL
SPARTE_NAME
SPARTE_NR
GRUPPE_NAME
GRUPPE_NR
ARTIKEL_NAME
ARTIKEL_ID
F_UMSATZ
ARTIKEL_ID
ZEIT_ID
KUNDE_ID
REGION_ID
UMSATZ
MENGE
BESTELL_DATUM
D_ZEIT
DATUM_DESC
TAG_DES_MONATS
WOCHE_DES_JAHRES
JAHR_NUMMER
QUARTALS_NUMMER
MONATS_NUMMER
MONAT_DESC
DATUM_ID
sum / count
127
Join Back-Methode
SELECT
z.jahr_nummer Jahr,
z.monat_desc Monat,
a.artikel_name Artikel,
sum(u.umsatz) Summe
FROM
f_umsatz u,
d_artikel a,
d_zeit z
WHERE
a.artikel_id = u.artikel_id AND
u.zeit_id = z.datum_id
GROUP BY
z.jahr_nummer, z.monat_desc, a.artikel_Name;
Ist nicht in der
MAV-Definition
enthalten
• Join Back-Tabelle muss einen Primary Key nutzen
F_ARTIKEL
SPARTE_NAME
SPARTE_NR
GRUPPE_NAME
GRUPPE_NR
ARTIKEL_NAME
ARTIKEL_ID
F_UMSATZ
ARTIKEL_ID
ZEIT_ID
KUNDE_ID
REGION_ID
UMSATZ
MENGE
BESTELL_DATUM
D_ZEIT
DATUM_DESC
TAG_DES_MONATS
WOCHE_DES_JAHRES
JAHR_NUMMER
QUARTALS_NUMMER
MONATS_NUMMER
MONAT_DESC
DATUM_ID
sum / count
128
Materialized Views im Detail Verwaltung
129
Oracle Data Warehouse
EXPLAIN_MVIEW – Auswertung
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
start D:\O11\db11\RDBMS\ADMIN\utlxmv.sql
130
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');
EXPLAIN_MVIEW-Routine
• Zeigt auf, welche Funktionen für eine jeweilige MAV genutzt
werden kann
131
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
SELECT capability_name, possible p, substr(related_text,1,20) obj,
substr(msgtxt,1,100) erklaerung FROM mv_capabilities_table;
EXPLAIN_MVIEW-Routine
132
EXPLAIN_REWRITE-Routine
Angabe der Bedingungen für Query Rewrite
@D:\app\aths\product\11.1.0\db_1\RDBMS\ADMIN\utlxrw.sql
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
EXPLAIN_REWRITE-Routine
CREATE MATERIALIZED VIEW MV_UMS_ART_Zeit_Join
REFRESH COMPLETE
ENABLE QUERY REWRITE
AS SELECT
z.jahr_nummer Jahr,
z.monat_desc Monat,
a.artikel_id ID,
FROM
f_umsatz u,
d_artikel a,
d_zeit z
WHERE
a.artikel_id = u.artikel_id AND
u.zeit_id = z.datum_id;
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;
select mv_name, message from rewrite_table;
MV_UMS_ART_ZEIT_JOIN
QSM-01150: Abfrage wurde nicht umgeschrieben
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
MAV-Definition DBMS_MVIEW.EXPLAIN_REWRITE
134
Analytische Funktionen im SQL
135
Oracle Data Warehouse
Analytische Funktionen
• Seit Oracle 8.1.6 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
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 100000 verkauft worden ist, verglichen mit anderen in seiner Kategorie?
• Welches ist der Median von den Verkäufen pro Produkt und Region?
137
Arbeitsweise analytischer Funktionen
• Analytische Funktionen berechnen einen aggregierten
Wert basierend auf einer Gruppe (Partition / Window)
von Zeilen
• Syntax:
• Ausführungsablauf:
FUNCTION_NAME (<arg>,<arg>....)OVER
(<partition clause><order by clause><windowing clause>)
JOIN, WHERE, GROUP BY, HAVING
ORDER BY
Partitionen erzeugen,
Funktionen
auf Partionen anwenden
138
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
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:
• 2.Schritt: und für die Angestellten noch eine Subquery
(korreliert ?) ..
SELECT department_id, MAX(salary) FROM employees
GROUP BY department_id
140
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
---------- -------------------- ------------------
10 Jennifer Whalen 4400
20 Michael Hartstein 13000
30 Den Raphaely 11000
......
141
...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 12000
AD_ASST Jennifer Whalen 4400
AD_PRES Steven King 24000
....
142
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
Artikel
Artikelgruppe
Artikel- Sparte
Dimension Artikel Zeit
Region
Umsatz
Kunde
Top 10 Artikel
SELECT * FROM
(SELECT substr(A.Artikel_Name, 1, 15), SUM(U.umsatz) AS Wert,
RANK() OVER (ORDER BY SUM(U.umsatz) DESC ) AS Rangfolge
FROM f_umsatz U, d_artikel A
WHERE U.artikel_ID = A.artikel_ID GROUP BY A.Artikel_Name)
WHERE rownum < 11;
Abfrage der Top 10 Artikel
144
Artikel
Artikelgruppe
Artikel- Sparte
Dimension Artikel Zeit
Region
Umsatz
Kunde
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
(PARTITION BY A.Artikelgruppe
ORDER BY SUM(U.umsatz) DESC) AS Rangfolge
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;
Abfrage Top 3 Artikel pro Artikelgruppe
145
Name Dimension
Kunde Zeit
Region
Umsatz
Kunde
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
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;
Quartal
Jahr
Q1_2003 Q4_2002 Q3_2002 Q2_2002 Q1_2002
Über Quartale kumulierte Umsätze Pro Kunde
146
Name Dimension
Kunde Zeit
Region
Umsatz
Kunde
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
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;
1
2
1
2
3
4
Buckets
¼ der Kunden tragen zu wieviel Prozent des Umsatzes bei?
147
Name Dimension
Kunde Zeit
Region
Umsatz
Kunde
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)
AND K.kunden_name = 'Bauer'
GROUP BY K.kunden_Name, Z.jahr, Z.Monat_des_jahres
ORDER BY Z.jahr, Z.Monat_des_jahres;
Monat
Jahr
M5_2002 M4_2002 M3_2002 M2_2002 M1_2002
Durchschnittliche Bestellquote eines Kunden über 3 Monate
148
Artikelgruppe
Dimension Artikel Region
Region
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 ;
Ort
Bundesland
Kreis
Region
Artikel
Das Bundesland mit dem stärksten Umsatz für jede Artikelgruppe
149
Name Dimension
Kunde Zeit
Region
Umsatz
Kunde
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 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;
Monat
Jahr
M6_2002 M5_2002 M4_2002 M3_2002 M2_2002 M1_2002
M10_2002 M9_2002 M8_2002 M7_2002
M11_2002 M12_2002 M1_2003 M2_2003
Vergleiche Umsätze mit Vorjahreszeitraum
150
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
---------- ----------------------------------------
10 CLARK:KING:MILLER
20 ADAMS:FORD:JONES:SCOTT:SMITH
30 ALLEN:BLAKE:JAMES:MARTIN:TURNER:WARD
151
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
Grundlagen von
Oracle OLAP
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
BI-Funktionalität in der Datenbank
Ad-Hoc
Analysis
Ad Hoc-Analysen
“Analyse in
Denkgeschwindigkeit”
Advanced Aggregations
Wirtschaftsbezogene und
selbstdefinierte Funktionen
Planning
Vorhersagbare
Analysen
Statistisches Forecasting
Budgetzuordnungen
Modellberechnung
OLAP Transaktions-
Modell
Standard
Reporting
“Analyse-freie
Zone”
OLTP /
3NF DWH
Ad-Hoc
Reporting
Ad Hoc-Abfragen
Zeitreihen
Shares/Indizes
Star Schema OLAP
Komplexe Fragestellungen
• 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?
Rückblick / IST-Zustand Vorhersage / SOLL-Zustand
Zeit
OLAP: Daten als Cube organisiert
Umsätze
Kosten
Deckungsbeitrag in %
Zelle
Slicing und Dicing mit OLAP
Region
Wo?
Zeit
Wann?
Sicht des Vertriebs
Sicht der Produktmanager
Sicht des Controllings
Ad Hoc- Analysen
Produkt
Was?
Indikatoren
Vorteile der Integration in die Datenbank
• 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
Web Service Analysis
Dashboard Report
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
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
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
Ein großer vs. zwei kleine Cubes
Dimension Members Data Points
D1 100 100
D2 100 10,000
D3 100 1,000,000
D4 100 100,000,000
D5 100 10,000,000,000
D6 100 1,000,000,000,000
Dimension Members Data Points
D1 100 100
D2 100 10,000
D3 100 1,000,000
Dimension Members Data Points
D1 100 100
D2 100 10,000
D3 100 1,000,000
D4 100 100,000,000
Zwei kleinere Cubes mit insgesamt 101
Millionen Zellen
Ein großer Cube mit 1 Trillion Zellen
OLAP und Materialized Views
in Oracle 11g
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.)
SALES_MCC
month_id category_id
city_id quantiy sales
Month, City, Category
SALES_YCC
year_id category_id
city_id quantiy sales
Year, City, Category
SALES_YCC
year_id category_id region_id quantiy sales
Year, Region, Category
SALES_QSI
qtr_id item_id state_id quantiy sales
Qtr, State, Item
SALES_XXX
XXX_id XXX_id XXX_id
expense_amount potential_fraud_cost
Cust, Time, Prod, Chan Lvls
SALES_XXX
XXX_id XXX_id XXX_id
expense_amount potential_fraud_cost
SALES_XXX
XXX_id XXX_id XXX_id
expense_amount potential_fraud_cost
SALES_XXX
XXX_id XXX_id XXX_id quantiy revenue
SALES_YCT
year_id type_id
region_id quantiy sales
Year, District
SALES
day_id prod_id cust_id chan_id quantity
sales
SALES_MS
month state
quantiy revenue
Month, State
SALES_YC
year_id region_id quantity revenue
Year, Region
Oracle 11g: Cube-Organized MAVs
Automatisches Query Rewrite
SALES
day_id prod_id cust_id chan_id quantity
sales TIME
day_id month quarter
year
CUSTOMER
cust_id city
state country
PRODUCT
item_id subcategory
category type
CHANNEL
chan_id class
SQL
Materialized View Refresh
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
Hardware Komponenten
169
Balanced Konfigurationen
• Anzahl CPU‘s
• Größe des
Hauptspeichers
• Anzahl Platten
• Anzahl Disk Controller
170
• ~200 MB Datendurchsatz pro CPU
• Anzahl CPU = Max. Durchsatz in MB/s / 200
• 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
• Größe des Speichers in GB = 2 * Anz. CPUs
Anzahl Disk Controller = Max. Durchsatz in MB/s
Controllerdurchsatz in MB
Controllerdurchsatz in MB = 70% * Herstellerangaben in Gbit/s
8
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
• www.oracle.com/technology/software/tech/orion/index.html
171
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
ASM Architektur
173
Der physische Aufbau einer
RAC-Umgebung
Options: RAC
Speichernetzwerk
CPU
CPU CPU
CPU CPU
CPU CPU
CPU
Knoten 1 Knoten 2
Privates Netzwerk
(Interconnect)
Öffentliches Netzwerk
Instanz 1 Instanz 2
Daten
174
‘Typische’ Cluster Konfiguration – 2005
16-port switch
16-port switch
1 Gigabit ethernet
16 Storage arrays, each with
10-20 disks
4 nodes, each with
4 x 2 Ghz CPUs
5 PCI slots
175
Performance und Systemzustand
überwachen / Hilfsmittel
• 2) Perfstat
• 1) Alerts
• 3) AWR (EE, Diagnostic Pack)
• ADDM (EE, Diagnostic Pack)
• SQL Tuning
• ASH
Polling Beginn-Zeitpunkt
Ende-Zeitpunkt
Tracing Permanente
Betrachtung
Protokolldatei
analog
176
Automatic Database Diagnostic Monitor
(ADDM) und AWR
sysaux
User 1
User 2
AWR stündlich
ADDM Findings
1……nn%
2……nn%
3……nn%
…….
Statistics_level TYPICAL -> ON
BASIC -> OFF
8 Tage lang
Recommendations - Hardware
- Init-Parameter
- Space Konfig.
- Performance
Advisor
Action
1
2
3
OEM Addmrpt.sql
Rationale
4
DBMS_ADVISOR Package
MMON-
Process
use
SQL Tuning Advisor
Undo Advisor Segement Advisor
AWR-Report
177
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
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
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
Snapshot mit „Findings“
Weiterführende Aktivitäten
ADDM-Screen
181
182
Oracle Database Machine (Exadata)
Einführungsdauer
Personaleinsatz
Tuning
Platten-, Server-,
Netz-Integration
Investionen
Traditionelle
Umgebung
Database
Machine
notwendig
sorgfältige
Planung
erforderlich
Monate Tage
Ausgewogenes
System
minimal
(vorkonfiguriert)
25/50 GB/sec 0,5 – 5 GB/sec Extreme Performance
Oracle Database Machine X2-2
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!
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
25 GB / Sec IO – Datendurchsatz
50 GB / IO für Flash-Speicher
Query Processing: Das Problem mit klassischem Storage
What Were
Yesterday’s
Sales?
SUM
Oracle Database Server Grid Storage Array
Retrieve Entire Sales
Table
Select sum(sales) where salesdate= ‘22-Dec-2009’ …
Query Processing: Bei Exadata fliessen weniger Daten durch das Netz
What Were
Yesterday’s
Sales?
SUM
Oracle Exadata Storage Grid
Select sum(sales) where salesdate= 22-Dec-2009’ …
Retrieve Sales for Dec 22 2009
Oracle Database Server Grid
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
T1 22.241.978 43 11 28.5 28.5 40.6
T2 587.794.948 550 11.3 17.3 18.5 24
T4 17.952.967 29 8.6 16.6 17.3 24.9
T5 34.341.563 63 4.8 9.1 10.2 12.4
T6 354.985.310 360 9.9 10.9 26.6 39.1
T7 60.703.833 84 9.4 19.5 19.5 23.6
BigData – neue Optionen für das
Data Warehouse
DATA WAREHOUSE
Alfred Schlaucher, Oracle
Klassische Daten
• Messbare Größen und
Einheiten
• Transaktionsbezogene
Daten
• Misst OLTP-Systeme
• Definierte Kennzahlen
• 1 – 100 TB
• Tabellen und Spalten
• Täglich neue Daten
• Jeder Satz ist relevant
• „Buchungs“relevant
• Zeitrelevant
• Wachstum messbar
Der größte Teil der entstehenden Daten
wird noch nicht der Analyse zugeführt
• Verkehrsströme
• Kontaktinformations-
daten / CRM
• Briefwechsel
• Vertragsunterlagen
• Mailverkehr
• Energie-
Verbrauchsdaten
• Treuepunkt-Daten
• Mobile-Banking
• Verbrechensprofile
• Auto-Mobilitätsdaten
• Fahrzeug-
Informationssysteme
• Maschinen-Messdaten
Big Data: Potentielle Anwendungsfälle
Aufgabenstellung „Neue“ Daten Lösungen
Healthcare
Teures Gesundheitssystem
Remote Erfassung
von Patientendaten,
Krankenverläufe etc.
Genauere+günstigere
Medikation
Weniger Krankenhausaufenthalte
Produktion
Personeller Support
Sensoren an Maschinen
und Anlagen
Remote – Support
Ausfallvorhersagen
Öffentlicher Dienst
Bürger-Angebote
Bevölkerungsstatistiken
Verbrauchsdaten
Individualisierte Dienste
Kostensenkung
Retail
Marketing
Soziale Netzwerke /
Medien
Stimmungsanalysen
Genauere Segmentierungen
Location Based Services Realtime
Bewegungsdaten
potentieller Kunden
Geo-bezogenes Marketing,
Besucherstrom-Analyse
Verkehrsanalysen
BigData bedeutet nicht nur „Viele Daten“
sondern erweiterte Analysen mit anderen Daten
• Messbare Größen und
Einheiten
• Transaktionsbezogene
Daten
• Misst OLTP-Systeme
• Definierte Kennzahlen
• 1 – 100 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
+
• Exporative Analyse
•Komplexe statistische
Analysen
• Agile
Berichtsentwicklung
• Massive Skalierung
• Real Time Ergebnisse
• Abfragen mit extrem
hohen Daten-Durchsatz
• Bearbeitung am
Speicherplatz
•Hohe Parallelisierung
• Unvorhersehbares Auftreten
• Hohe Datenmengen
• Flexible Daten-Strukturen
• Arbeiten mit vielen Servereinheiten
Big Data: Infrastruktur Anforderungen
Acquire Organize Analyze
Heutige Lösungen sind isoliert und
“handgemacht”
Acquire Analyze Organize
MapReduce Solutions
(Hadoop MapReduce)
DBMS (DW)
DBMS (OLTP)
Advanced Analytics
Distributed
File Systems
(z. B. HDFS)
Transaction (Key-
Value)Stores
(Cassandra)
ETL
NoSQL
Flexible
Specialized
Developer
Centric
SQL
Trusted
Secure
Administered
Schema-less
Unstructured
Data
Variety
Schema
Information
Density
Home Grown BI
Home
Grown
ETL
“R”
RDBMS (OLTP)
RDBMS (DW)
Advanced Analytics
ETL
Oracle Loader for
Hadoop
Hadoop HDFS
Oracle
NoSQL DB
Acquire Analyze Organize
Oracle’s integrierte Software Lösung
Oracle (DW)
Oracle (OLTP)
Schema-less
Unstructured
Data
Variety
Schema
Information
Density
Cloudera
Hadoop HDFS
Oracle
NoSQL DB
Oracle Analytics
Mining R Spatial Graph
OBI EE
Oracle
MapReduce
Oracle
Data Integrator
Oracle
Hadoop
Loader
Acquire Analyze Organize
Oracle Engineered Systems
Schema-less
Unstructured
Data
Variety
Schema
Information
Density
Big Data
Appliance
Exadata Database Machine
Exalytics
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
Oracle Loader for Hadoop
• Leverage Hadoop
Cluster to pre-process
data for loading
Last stage in MapReduce workflow Partitioned and non-partitioned tables Online and offline loads
SHUFFLE
/SORT
SHUFFLE
/SORT
REDUCE
REDUCE
REDUCE
MAP
MAP
MAP
MAP
MAP
MAP
REDUCE
REDUCE
ORACLE LOADER FOR HADOOP
Oracle Direct Connector for HDFS
• Direct Access from
Oracle Database
SQL access to HDFS External table view Data query or import
DCH
External
Table
DCH
DCH
SQL Query
Infini Band
HDFS
Client
HDFS
Oracle Database
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 Storage Nodes
Data Center A
Storage Nodes
Data Center B
NoSQLDB Driver
Application
NoSQLDB Driver
Application
R Statistische Programmiersprache
Open source Sprache und Entwicklungsumgebung Geeignet für statistische Berechnungen und graphische Darstellung der Ergebnisse Endbenutzertaugliche Graphiken Erweiterbar
Oracle R Enterprise Lösung
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
Vorher Kleine Modelle oft nur auf Benutzer Laptops
Data Mining Provides Better Information, Valuable Insights and Predictions
Customer Months
Cell Phone Churners vs. Loyal Customers
Source: Inspired from Data Mining Techniques: For Marketing, Sales, and Customer Relationship Management by Michael J. A. Berry, Gordon S. Linoff
Data Mining Provides Better Information, Valuable Insights and Predictions
Customer Months
Cell Phone Churners vs. Loyal Customers
Source: Inspired from Data Mining Techniques: For Marketing, Sales, and Customer Relationship Management by Michael J. A. Berry, Gordon S. Linoff
Data Mining Provides Better Information, Valuable Insights and Predictions
Customer Months
Cell Phone Churners vs. Loyal Customers
Segment #1:
IF CUST_MO > 14 AND INCOME < $90K, THEN Prediction = Cell Phone Churner, Confidence = 100%, Support = 8/39
Segment #3:
IF CUST_MO > 7 AND INCOME < $175K, THEN Prediction = Cell Phone Churner, Confidence = 83%, Support = 6/39
Source: Inspired from Data Mining Techniques: For Marketing, Sales, and Customer Relationship Management by Michael J. A. Berry, Gordon S. Linoff
Data Mining Provides Better Information, Valuable Insights and Predictions
Customer Months
Cell Phone Churners vs. Loyal Customers
Insight & Prediction
Segment #1:
IF CUST_MO > 14 AND INCOME < $90K, THEN Prediction = Cell Phone Churner, Confidence = 100%, Support = 8/39
Segment #3:
IF CUST_MO > 7 AND INCOME < $175K, THEN Prediction = Cell Phone Churner, Confidence = 83%, Support = 6/39
Source: Inspired from Data Mining Techniques: For Marketing, Sales, and Customer Relationship Management by Michael J. A. Berry, Gordon S. Linoff
Data Mining Provides Better Information, Valuable Insights and Predictions
Customer Months
Cell Phone Fraud vs. Loyal Customers
Source: Inspired from Data Mining Techniques: For Marketing, Sales, and Customer Relationship Management by Michael J. A. Berry, Gordon S. Linoff
?
Oracle Data Mining Algorithms
Classification
Association
Rules
Clustering
Attribute
Importance
Problem Algorithm Applicability
Classical statistical technique
Popular / Rules / transparency
Embedded app
Wide / narrow data / text
Minimum Description
Length (MDL)
Attribute reduction
Identify useful data
Reduce data noise
Hierarchical K-Means
Hierarchical O-Cluster
Product grouping
Text mining
Gene and protein analysis
Apriori Market basket analysis
Link analysis
Multiple Regression (GLM)
Support Vector Machine Classical statistical technique
Wide / narrow data / text
Regression
Feature
Extraction
Nonnegative Matrix
Factorization
Text analysis
Feature reduction
Logistic Regression (GLM)
Decision Trees
Naïve Bayes
Support Vector Machine
One Class SVM Lack examples of target field Anomaly
Detection
A1 A2 A3 A4 A5 A6 A7
F1 F2 F3 F4
Traditional Analytics
Hours, Days or Weeks
In-Database Data Mining
Data Extraction
Data Prep & Transformation
Data Mining Model Building
Data Mining Model “Scoring”
Data Preparation and Transformation
Data Import
Source
Data
Dataset
s/ Work
Area
Analytic
al
Process
ing
Process
Output
Target
Results • Faster time for
“Data” to “Insights”
• Lower TCO—Eliminates
• Data Movement
• Data Duplication
• Maintains Security
Data remains in the Database
SQL—Most powerful language for data preparation and transformation
Embedded data preparation Cutting edge machine learning algorithms inside the SQL kernel of Database
Model “Scoring” Data remains in the Database
Savings
Secs, Mins or Hours
Model “Scoring”
Embedded Data Prep
Data Preparation
Model Building
Oracle Data Mining
Oracle Data Miner 11g Release 2 GUI Churn Demo—Simple Conceptual Workflow
Oracle Data Miner 11g Release 2 GUI Churn Demo—Simple Conceptual Workflow
Churn models to product and “profile” likely
churners
Oracle Data Miner 11g Release 2 GUI Churn Demo—Simple Conceptual Workflow
Market Basket Analysis to identify potential product
bundless
• 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
Oracle Data Mining and Unstructured Data
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
DWH-bezogenes Monitoring
217
Oracle Data Warehouse
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
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
Beispiel-Session
SQL> SELECT sid, serial# FROM gv$session WHERE username = 'MON';
SID SERIAL#
---------- ----------
134 63
SELECT sample_time, event, wait_time FROM gv$active_session_history
WHERE session_id = 134 AND session_serial# = 63
SAMPLE_TIME EVENT WAIT_TIME
---------------------------------- ---------------- -
05-SEP-11 08.47.44.282 PM 1
05-SEP-11 08.46.42.283 PM 1
SELECT sql_text, application_wait_time FROM gv$sql
WHERE sql_id IN (
SELECT sql_id
FROM gv$active_session_history
WHERE TO_CHAR(sample_time) = '05-SEP-11 08.44.53.283 PM'
AND session_id = 134
AND session_serial# = 63)
/
Sessiondaten
abfragen
Sample-Time
Mit Sessiondaten
abfragen
Aktives SQL
abfragen
221
Beobachtung des
Informationsbedarfs
222
Beobachten des Informationsbedarfs
• Regelmäßige Teilnahme an Gremien
• Abstimmung / Feedback / Planung mit Fachabteilungen und DWH-
Nutzern
• Statistiken über DWH-Nutzung
• Benutzerzahlen / Session-Statistik
• Datenmengen / Platzverbrauch
• Segment-Reads
223
Messung tatsächlich belegter Plattenplatz
• Häufig gibt es nur Zahlen über den allokierten Speicher
• Oft genannt von der Storage-Abteilung, die nicht in die Dateien
hineinschauen kann
• Manchmal werden Zahlen genannt, bei den auch den
Spiegel oder auch Backup-Platz beinhalten
• Plattenplatz im DWH wird oft ähnlich organisiert wie
Plattenplatz im OLTP-Umfeld
• Zu große Free-Space-Bereiche, obwohl die Zugänge zeitlich und
mengenmäßig gut kalkulierbar sind
Gibt kein realisitisches Bild über den tatsächlichen Bedarf und Kosten
224
Messung belegter Plattenplatz pro Tablespace
SET LINESIZE 145
SET PAGESIZE 9999
SET VERIFY OFF
COLUMN tablespace FORMAT a18 HEADING 'Tablespace Name'
COLUMN filename FORMAT a50 HEADING 'Filename'
COLUMN filesize FORMAT 999.999,999,999,999 HEADING 'File Size'
COLUMN used FORMAT 999.999,999,999,999 HEADING 'Used (in bytes)'
COLUMN pct_used FORMAT 999 HEADING 'Pct. Used‚
BREAK ON report
COMPUTE SUM OF filesize ON report
COMPUTE SUM OF used ON report
COMPUTE AVG OF pct_used ON report
SELECT /*+ ordered */
d.tablespace_name tablespace
, d.file_name filename
, d.file_id file_id
, d.bytes filesize
, NVL((d.bytes - s.bytes), d.bytes) used
, TRUNC(((NVL((d.bytes - s.bytes) , d.bytes)) / d.bytes) * 100) pct_used
FROM sys.dba_data_files d
, v$datafile v
, ( select file_id, SUM(bytes) bytes
from sys.dba_free_space
GROUP BY file_id) s
WHERE
(s.file_id (+)= d.file_id)
AND (d.file_name = v.name)
UNION
SELECT
d.tablespace_name tablespace
, d.file_name filename
, d.file_id file_id
, d.bytes filesize
, NVL(t.bytes_cached, 0) used
, TRUNC((t.bytes_cached / d.bytes) * 100) pct_used
FROM sys.dba_temp_files d
, v$temp_extent_pool t
, v$tempfile v
WHERE
(t.file_id (+)= d.file_id)
AND (d.file_id = v.file#)
/
225
Tablespace Name Filename FILE_ID FILESIZE USED Pct. Used
------------------ --------------------------------------------- ---------- ---------- ---------
DWH1 D:\ORA\ORADATA\ORCL\DWH1.DBF 7 52428800 25100288 47
DWH1 D:\ORA\ORADATA\ORCL\DWH1_1 8 209715200 32178176 15
DWH1 D:\ORA\ORADATA\ORCL\DWH1_2 9 2726297600 23068672 0
EXAMPLE D:\ORA\ORADATA\ORCL\EXAMPLE01.DBF 5 104857600 82247680 78
PERFSTAT D:\ORA\ORADATA\ORCL\PERFSTAT01.DBF 6 104857600 102498304 97
PERFSTAT D:\ORA\ORADATA\ORCL\PERFSTAT2 12 209715200 1048576 0
SYSAUX D:\ORA\ORADATA\ORCL\SYSAUX01.DBF 2 723517440 679608320 93
SYSTEM D:\ORA\ORADATA\ORCL\SYSTEM01.DBF 1 734003200 729874432 99
TEMP D:\ORA\ORADATA\ORCL\TEMP01.DBF 1 20971520 18874368 90
TEST D:\ORA\ORADATA\ORCL\TEST.DBF 10 3145728 1048576 33
TEST_ALERT D:\ORA\ORADATA\ORCL\TEST_ALERT.DBF 11 3145728 2097152 66
TEST_ALERT D:\ORA\ORADATA\ORCL\TEST_ALERT2 13 3145728 3145728 100
UNDOTBS1 D:\ORA\ORADATA\ORCL\UNDOTBS01.DBF 3 52428800 33816576 64
USERS D:\ORA\ORADATA\ORCL\USERS01.DBF 4 5242880 4325376 82
---------- ---------- ---------
avg 62
sum 4953473024 1738932224
226
Lesestatistiken für die wichtigsten Tabellen
anlegen
• dba_hist…. - Views zum Sammel der Lese-Zugriffe
• dba_hist_seg_stat
• dba_hist_seg_stat_obj
• dba_hist_snapshot
• Achtung:
• Views werden nur aktualisiert wenn
• Auch tatsächlich gelesen wurde
• Ein AWR-Snapshot gezogen wurde
• Zähler fällt auf 0, wenn die DB durchgestartet wird
• Aufbau einer eigenen Statistik-Tabelle mit
• Tab-Name, Snap-ID, Datum/Uhrzeit, Physical Reads
• Aktualisieren immer nachdem ein AWR-Snapshot gezogen wurde
• dba_hist_sqlstat
• dba_hist_sqltext
227
Lesestatistiken für die wichtigsten Tabellen
anlegen
Select distinct * from
(select
to_char(begin_interval_time,'dd.mm.yyyy:hh24:MI') Zeit,
logical_reads_total log_rd,
logical_reads_delta log_rd_delta,
physical_reads_total phy_rd,
physical_reads_delta phy_rd_delta
from
dba_hist_seg_stat s,
dba_hist_seg_stat_obj o,
dba_hist_snapshot sn
where
o.owner = 'DWH1' and
s.obj# = o.obj# and
sn.snap_id = s.snap_id and
object_name = 'UMSATZ')
order by zeit; ZEIT LOG_RD LOG_RD_DELTA PHY_RD PHY_RD_DELTA
---------------- ---------- ------------ ---------- ------------
06.09.2010:22:00 3357520 3357520 3355361 3355361
06.09.2010:23:00 4030816 673296 4028177 672816
07.09.2010:12:32 8060160 4029344 8054609 4026432
07.09.2010:15:50 688 688 1 1
228
Zugriffsdaten auf Tabellen über SQL sammeln
• SQL-Statements pro User analysieren
• From-Klausel parsen
• Zugriffe auf Tabellen
• System-Zugriffe ausschließen
• Wegen der Menge
• Historien-Tabelle aufbauen
• Mit aus der FROM-Klausel herausgefilterten Tabellennamen
• Zuordnung zu USER, Zeit und SQL-Statement
229
Beispielabfrage
select
to_char(s.begin_interval_time,'mm-dd hh24') c1,
sql.sql_id c2,
t.SQL_TEXT C9,
sql.executions_delta c3,
sql.buffer_gets_delta c4,
sql.disk_reads_delta c5,
sql.iowait_delta c6,
sql.apwait_delta c7,
sql.ccwait_delta c8
from
dba_hist_sqlstat sql,
dba_hist_snapshot s,
dba_hist_SQLTEXT t
where
s.snap_id = sql.snap_id and
sql.PARSING_SCHEMA_NAME = 'DWH1' and
t.SQL_ID = sql.SQL_ID and
sql.sql_id = '01978kjxb5yd2' and
to_char(s.begin_interval_time,'mm-dd hh24') = '09-12 13'
order by c1, c2;
col c1 heading ‘Begin|Interval|time’ format a8
col c2 heading ‘SQL|ID’ format a13
col c3 heading ‘Exec|Delta’ format 9,999
col c4 heading ‘Buffer|Gets|Delta’ format 9,999
col c5 heading ‘Disk|Reads|Delta’ format 9,999
col c6 heading ‘IO Wait|Delta’ format 9,999
col c7 heading ‘Application|Wait|Delta’ format 9,999
col c8 heading ‘Concurrency|Wait|Delta’ format 9,999
col c9 heading 'SQL-Text' format a50
break on c1
230
`Begin `Buffer `Disk `Application `Concurrency
Interval `SQL `Exec Gets Reads Wait Wait
time' ID' SQL-Text Delta' Delta' Delta' C6 Delta' Delta'
-------- ------------- ---------------------------------------------- ------ ------- ------ ---------- ------------ ------------
09-12 13 01978kjxb5yd2 Select * from 1 8,573 8,390 7448344 0 0
(select
Produkt, sum(U.summe) AS Wert,
RANK()
-------- ------------- ---------------------------------------------- ------ ------- ------ ---------- ------------ ------------
01978kjxb5yd2 Select * from 1 8,573 8,390 7494081 0 0
(select
Produkt, sum(U.summe) AS Wert,
RANK()
-------- ------------- ---------------------------------------------- ------ ------- ------ ---------- ------------ ------------
01978kjxb5yd2 Select * from 1 8,576 8,390 6601478 0 0
(select
Produkt, sum(U.summe) AS Wert,
RANK()
231
Verwendungsinformationen speichern
User
Tabname Gelesen_Von_User Anzahl_Read_IO Lese_Datum
Tabelle DWH-Zugriffshistorie
232
Verbrauchsdaten sammeln
• Mess-Aufruf in der
aktuellen
ETL-Job-Session
als letzten
Aufruf einbauen
• Ergebnis-Daten in
Historien-Tabelle
eintragen
SELECT
/*+ use_nl (e s) ordered */
s.sql_id, s.plan_hash_value,
to_char(s.hash_value),
rawtohex(s.address),
s.sql_text,
s.disk_reads,
s.buffer_gets,
s.executions,
s.sharable_mem,
s.parsing_user_id,
s.sorts,
s.parse_calls,
s.command_type,
s.child_number,
s.parsing_schema_id,
s.rows_processed,
e.username dbuser,
u.name parsing_user,
e.sid,
s.module,
s.action,
s.open_versions,
1 current_set
FROM
v$session e, v$sql s, sys.user$ u
WHERE s.address = e.sql_address AND
s.hash_value = e.sql_hash_value AND
s.child_number = e.sql_child_number AND
u.type# != 2 AND
s.parsing_user_id = u.user#
233