<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

eMail

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