Data Warehouse Technik im Fokus - oracledwh.de€¦ · Oracle Database Performance Tuning Guide 11g...

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |DATA WAREHOUSE

Data Warehouse Technik im FokusTechnik und Architekturen für effizienteInformationsgewinnung

Praxis-Seminar, Oracle, Mai 2018

1


Themenübersicht 1/2

• DWH Trends und Architekturen, Schichtenmodelle

• Abgrenzung DWH / OLTP

• Partitioning, Indizierung, Statistiken, Komprimieren

• Automatisierung/ILM, Parallelisierung, Caches

• Umgang mit Kennzahlen, Materialized Views

• SQL-Erweiterungen /Analytische Funktionen, Analytic Views

• In-Memory, Virtualisierung von Schichten

• ETL, Lade-Transaktionen

• Security, Sandboxes

DWH-Technik+Konzepte im Fokus

2


Themenübersicht 2/2

• Backup

• JSON

• Hardware, Monitoring

• Metadaten, Benennungsstandards, Glossar

• Modellierung im Warehouse

• Restthemen

• Möglich: Big Data, Machine Learning (nicht in diesem Foliensatz)


3


Informationsbedarfe: Wen interessiert was?

Standberichte

Interaktive Berichte

Tag, Monat, Quartal, Jahr

Vergangenes -> reagieren Zukünftiges -> agieren

Was ist geschehen

Warum ist es geschehen

Was wird geschehen

Was könnte geschehen

Simulation

Statistik

Data Mining

Algorithmen, Modelle

Machine Learning

Data Mining

Reife der Analyse-Aktivitäten im Unternehmen

Nu

tzen

u

nd

W

ett

bew

erb

svo

rteile

4


Evolution des Data Warehouse

DWH-Systeme werden zunehmend auch in einem operativen Sinn genutzt

5

Komplexe Informations-

Ausarbeitung und Analysen

Jahr/Quartal/MonatPeriodische Berichte

Woche/Tagoft und schnell

wiederholbare Einzel-informationen

Stunde/Minute/Sekunde/Realtime

überschaubar

Hochvolumig / granular

Taktisch

Überschaubar / aggregiert

DWH

Strategisch

Operativ


Modelle und Schichten

6


Unternehmensweites Data Warehouse

7

Service

Logistik

Controlling

Einkauf

Vertrieb

Marketing

Zentral, unternehmensweit,einheitlich, verstehbar, angereichert, historisch

D a t a W a r e h o u s e


Aufgaben innerhalb einer Warehouse-Architektur

8

Service

Logistik

Einkauf

Vertrieb

Controlling

Marketing

Integrieren Vorhalten

Redundanzfrei

Bereitstellen

Lokal zusammenfassen

Über entsprechende Schlüssel integrieren

Plausibilitäten

Fachliche Prüfungen

Feine Granularität

Beziehungen

Sortierte unddokumentierte Ablage

Bereich-/Themen-übergreifend

Anwendungs-neutral

Aspekt-/Themenbezogen

Auf konkrete Frage-stellungen hin ausgerichtet

Benutzergruppenbezogen

Bilden neuer Objektein der Folgeschicht

„Zugriffsgerechte“,„Benutzer-gerchte“

Modellform

Blick auf die Vorsysteme Blick auf den Nutzer


9

Historisches – DWH –Konzepte aus den 90ern

Stage Kern-SchichtAnalyse-Fokus-Bezogene Data Marts

Multi-dimensionNear 3NF

granular

D

DD

F

F

F

D

D

D

D

D

D

D

D

D

DD

F

F

F

D

D

D

D

Stage

Multi-dimension

Zusammenhängendemultidimensionale Modelle(conformed dimensions)

Inmon

Kimball

Große Nähe zu operativen Systemen

Große Nähe zu operativen Systemen

Service

Logistik

Einkauf

Vertrieb

Controlling

Marketing


10

Single Point of True – selten erreichtes Ziel

• Ursprung vieler Daten des Data Warehouse sind operative Vorsysteme mit teils isolierter Datennutzung

• Viele Warehouse – Systeme sind oft nur eine Ansammlung von Data Marts und zentraler technischer Administration – Historisch entstanden, aus zeitlicher Abfolge einzelner Data Mart-Projekte

– Falsch verstandenem Fachabteilungs-Fokus

• Echte Integrationsaufgaben wurden oft vernachlässigt– Fehlendes Verständnis

– Kostenscheu


11

Single Point Of True gelingt nur über die Eindeutigkeit und Bestimmtheit aller Objekte in dem Data Warehouse

• Zentrales einmaliges Vorhalten von Daten auch wenn Daten durch unterschiedliche (analytische) Anwendungen mehrfach genutzt werden

• Innerhalb des (Data Warehouse-) Systems werden Bezeichner nur einmal zur Identifizierung von Objekten genutzt

– Synonyme / Homonyme auf Attribut + Objektebene sind aufzulösen

• Eindeutigkeit ist das Ergebnis echter Integrationsarbeit

* S. Brenner 1988


Technisches Data Warehouse Data MartsStage

Das missverstandene Data Warehouse Prinzip

ControllingProfitabilität

LogistikLogistikaufwand

ServiceServicekunde

MarketingMarketingsicht

VertriebKundenhistorie

EinkaufProdukte&Trends

D

DD

F

F

F

D

D

D

DS S

B

S

S

S

B

B

BD

D

D

F DD

D

BS

S

SS

SS

S

Einfache Kopie

operativerDaten

Cleansing

Teilweiseisolierte

Daten

BI-Tool

Sachgebiets-bezogene(isolierte)Analysen

Isolierte Data

Marts

E i n d e u t i g k e i t k a u m k o n t r o l l i e r b a r

12


Das missverstandene Data Warehouse Prinzip

• Kein echter „Single Point of True“

• Bedeutungs-Schwergewicht liegt auf den Data Marts

– Müssen permanent weiter entwickelt werden

– Können nicht ad hoc neu aufgebaut werden

– Unflexibel, fehlende Änderungsfreundlichkeit

– Fehlendes übergreifende Abfragemöglichkeit

• Zentrale Warehouse-Schicht dient nur der Datenbereitstellung für die Data Marts

– keine konsolidierende Funktion

– nur Cleansing

• Stage: nur Durchgangs-Kopierfunktion aus Vorsystemen

13


Informationsbeschaffung organisieren

• Integration Layer (Stage)

– Zusammenführen von Daten aus unterschiedlichen Vorsystemen

– Prüfen, harmonisieren, brauchbar machen

• Enterprise Layer (DWH-Kernschicht)

– Zentrale Ablage aller Informationen des Data Warehouse

– Stammdaten, Referenzdaten, Bewegungsdaten

– Prozess- /Referenz, Stammdaten

– Langlebig, strategisch

• User View Layer (Data Marts)

– Nach Sachgebieten sortierte analysefähiger Ausschnitt von Daten der Kernschicht

– Endbenutzerverständlich

– Analysezeitraum- und Projekt-bezogen, taktisch

14


Enterprise LayerCore - DWH / Info Pool

User ViewLayer

IntegrationLayer

Die strategische Rolle der Warehouse-Schicht

Strategische Daten

E i n d e u t i g k e i t i n d e r K e r n s c h i c h t

Wirkungsweite des Systems muss festgelegt sein

Service

Logistik

Einkauf

Vertrieb

Controlling

Marketing

??

Service

Logistik

Einkauf

Vertrieb

Controlling

Marketing

15



User ViewLayer

IntegrationLayer


Strategische Daten

E i n d e u t i g k e i t i n d e r K e r n s c h i c h t

Wirkungsweite des Systems muss festgelegt sein

Service

Logistik

Einkauf

Vertrieb

Controlling

Marketing

??

Service

Logistik

Einkauf

Vertrieb

Controlling

Marketing

Die selbenGeschäfts-objektein unter-schiedlichenProzessen

Wunsch für

unter-schiedliche

Sichtenauf die selben

Geschäfts-objekte

16


Enterprise Layer User ViewIntegration

Was verdienen wir an gelben + bunten Fahrrädern?

Es geht um Gesamt-sichten:

„Breite“ derDatenmodelle

LogistikWAREWaren_NrGebindeGewichtHoeheLaengeBreiteVerpackung

EinkaufARTIKELArtikel_NrEinheitPreisLieferant

VertriebPRODUKTProdukt_NrEinheitFarbePreis

LIEFERANTPK_Lieferanten_IDLieferant_Name

VERPACKUNGSARTPK_Verpackungs_IDHoeheLaengeBreite

Rabatte Lieferanten-Discounts

FARBEPK_Farben_IDFarbeAufschlag

VerkaufteArtikelMenge + Preise

GelagerteArtikel,Menge +Größe

Verpackungen

LagerLieferanten

ZeitArtikel

GekaufteArtikel,Menge +Preise

Gewinn = Verkaufspr. –Einkaufspr. –Lagerkosten

S_ARTIKELPK_Artikel_IDEink_Artikel_NrLog_Waren_NrVert_Produkt_NrEink_EinheitEink_PreisFK_Lieferanten_IDGebindeGewichtPK_Verpackungs_IDVert_EinheitFK_Farben_IDVert_Preis

T_ARTIKELPK_Artikel_IDEink_Artikel_NrLog_Waren_NrVert_Produkt_NrEink_EinheitEink_PreisLieferantGebindeGewichtHoeheLaengeBreiteVerpackungVert_EinheitFarbeVert_Preis

17



Was verdienen wir an gelben + bunten Fahrrädern?

Es geht um

Gesamt-sichten:„Breite“

derDaten-

modelle

LogistikWAREWaren_NrGebindeGewichtHoeheLaengeBreiteVerpackung

EinkaufARTIKELArtikel_NrEinheitPreisLieferant

VertriebPRODUKTProdukt_NrEinheitFarbePreis

LIEFERANTPK_Lieferanten_IDLieferant_Name

VERPACKUNGSARTPK_Verpackungs_IDHoeheLaengeBreite

RabatteLieferanten-Discounts

FARBEPK_Farben_IDFarbeAufschlag

VerkaufteArtikelMenge + Preise

GelagerteArtikel,Menge +Größe

Verpackungen Lager

Lieferanten

Zeit

GekaufteArtikel,Menge +Preise

S_ARTIKELPK_Artikel_IDEink_Artikel_NrLog_Waren_NrVert_Produkt_NrEink_EinheitEink_PreisFK_Lieferanten_IDGebindeGewichtPK_Verpackungs_IDVert_EinheitFK_Farben_IDVert_Preis

T_ARTIKELPK_Artikel_IDEink_Artikel_NrLog_Waren_NrVert_Produkt_NrEink_EinheitEink_PreisLieferantGebindeGewichtHoeheLaengeBreiteVerpackungVert_EinheitFarbeVert_Preis

D_ARTIKEL_LAGERPK_Artikel_IDLog_Waren_NrGebindeGewichtVerpackung

D_ARTIKEL_VERTPK_Artikel_IDVert_Produkt_NrEink_EinheitVert_EinheitFarbenVert_Preis

D_ARTIKEL_EINKPK_Artikel_IDEink_Artikel_NrEink_EinheitEink_PreisLieferantenFarben

18



• Standardisierte Begriffe / Bezeichner

– Definition aller Datenobjekte (Sachverhalte, Kennzahlen)

– Lösung der Homonymen / Synonymen – Thematik

– Informationen (Daten) sind nur ein Mal vorhanden (Eindeutig / Redundanzfrei)

• Definieren der nötigen Granularität (Business Events)

• Bereithalten aller Informationen zum Aufbau von Auswertemodellen

– Historisierung / Langlebigkeit der Informationen

– Schlüsselinformationen (enthält künstliche und Original-Schlüssel)

– Hierarchisierungs-Informationen (Optionen für späteres multidimensionales Modell)

• Anwendungs- und Geschäftsprozess-neutral

19


• 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

• Schlüssel sind einfach zu benutzen und kurz, um– Speicherplatz zu sparen – Fehler zu vermeiden

• Nach Möglichkeit keine zusammengesetzten Schüssel– Erfordert beim Zugriff unnötig viel Vorwissen zu den einzelnen Schlüsselbestandteilen – Schlüsselbestandteile können leicht NULL-Wert annehmen, die Eindeutigkeit ist gefährdet

• Keine Felder wählen, die NULL werden können

• Spaltenwerte sollten stabil sein und sich nicht mehr ändern

Künstliche Schlüssel im Data Warehouse

20


21

Hilfsmittel bei dem Auffinden von Synonymen

• Ziel:– Wiederverwendung von Objekten

und Informationen

– Standardisierung von Bezeichnern

• Methodenmix

• Permanente Aufgabe während der Weiterentwicklung des Systems

• Aufwand sollte berücksichtigt werden

• Analyse von Bezeichnern – Feldliste

• Wortstammanalyse

• Arbeiten mit Standard-Abkürzungen

• Beschreibung durch Deskriptoren

• Systematische Datentypklassifikation

• Synonymen-Suche durch Normalisierung von Entitäten

Methoden und Hilfsmittel zur Synonymensuche

Hilfsmittel: Business Glossar


Sparten_NameSparten_Nr

Gruppen_NameGruppen_Nr

Artikel_NameArtikel_NrArtikel_ID

SanitärGartenElektro

FoodNon-FoodServices

Bohrhammer 4711Farbtopf_Lack_rotCU_Muffe_18mm

TagWocheMonatQuartalJahrDekade

HierarchieTag/Woche/Jahr

OrtVertGebietKreisBundeslandLandRegion

ArtikelZeit

RegionChannel

Channel

Medium

Kampagne

Zeit_IDArtikel_IDRegion_IDChannel_IDMengeUmsatz_Pos

Hierarchie Tag/Monat/Quartal/Jahr Keys

Facts /Kennzahlen

Business KeyKünstlicher

Dimension Key

Parent

Parent

AggregationHierarchie

Aggregation

Wo werden wann welche Artikel verkauft?

• Multidimensionales Modell

• Star Schema

• Intuitives (End-benutzer-geeignetes) Modell

22


Allgemeine Regeln für das Star Schema

• Eher weniger als zu viele Attribute– Star Schema einfach halten

– Für Endbenutzer überschaubarer

– Überfrachtete Dimensionen aufspalten

• Sprechende Attributnamen nutzen– Event. Level-bezogene Präfixe verwenden

• Verwendungszweck-spezifische Dimensionen

• Seltengenutzte Spalten über 1:1 Beziehungauslagern

• Star Schema = Virtualisierungs-Kandidat bei In-Memory

• Degenerated Dimensionens

• Keine Snowflakes

• Conformed Dimension nutzen

• So granular wie möglich

24


Integration Layer

• Arbeitsschicht für alles, was der technischen Bearbeitung unterliegt

• Überprüfung von Syntaktischer Korrektheit (Typ, Länge, NULL), Vollständigkeit, Mengenverhältnisse, gültige Wertebereichen, Vorhandensein von Referenzdaten, Eindeutigkeit (optional), Eliminierung von NULL-Werten

• In-Database Aktivitäten bevorzugen

• Zusammenführung operativ getrennter Daten

• Bilden neuer Informationsobjekte mit dem Ziel der einfacheren Weiterverarbeitung (optional)

• Waisen-Management (optional)

• Bildung von Daten-Deltas (optional)

• Keine 1:1-Kopien

• Keine besonderen Datenmodell-Strukturen

• Wenn möglich, bereits beim ExtrahierenPrüfungen und Wandlungen von Datenvornehmen

• Keine Indizes verwenden

Stage ist leer, wenn nicht geladen wird

25


Weiterentwicklung der Architekturen

26


27

Einschätzungen zu Inmon und Kimball

• Konzepte entstanden Mitte der 90er

• Mittlerweile viele Veränderungen

– Dynamik der Ablaufprozesse

– Fortschritt der Technologie• Datenbanken / In-memory / Hadoop

• Größe und Kosten von Hauptspeicher / Storage

• Das Inmon-Konzept ist gerade in großen Unternehmungen breit akzeptiert

• Aber es gibt zunehmend Kritik an der Art wie das Schichtenmodell gelebt wird– Oft zu starr, ohne Reflexion der Sinnhaftigkeit


Aufgaben innerhalb einer Warehouse-Architektur

28

Service

Logistik

Einkauf

Vertrieb

Controlling

Marketing


Redundanzfrei

Bereitstellen



Plausibilitäten


Feine Granularität

Beziehungen



Anwendungs-neutral






Modellform



Die Aufgaben bleiben –aber die technische Realisierung ändert sich aktuell

29

Service

Logistik

Einkauf

Vertrieb

Controlling

Marketing


Redundanzfrei

Bereitstellen



Plausibilitäten


Feine Granularität

Beziehungen



Anwendungs-neutral






Modellform


Interne Daten

Externe Daten

Fast Data

RelationaleDatenbank

Cloud

HadoopnoSQL

Virtualisierung

In-Memory

Big Data SQL

Analytic Views

Materialized Views

Logisches DWHKonzept


Technische und organisatorische Gegebenheiten in Data Warehouse Systemen Hilfen zur Einordnung von Technologie und Funktionen

30


31

Es gibt Data Warehouse-spezifische Rahmenbedingungen

OLTP Data Warehouse

Verteilung der Aktionen

Oft auf viele Tabellenverteilt

Oft zentrisches Arbeiten auf wenigen Tabellen

Art von Lese-/Schreib-Aktionen

Verteilt und nur einzelneSätze

Konzentriert und viele Sätze gleichzeitig

Hoch WenigerAnzahl Benutzer

Interaktion Lesen und Schreiben Eher nur Lesen / konzentriertes Mengen-Schreiben

Satzorientiert in kleinenBlöcken

Spaltenorientiert in sortieren BlöckenArt der physischenSpeicherung


32

Was bedeutet das für die eingesetzte Technologie?

OLTP Data Warehouse

Hoch Eher geringHochverfügbarkeit

komplett selektivBackup

Interaktion Lesen und Schreiben Eher nur Lesen / konzentriertes Mengen-Schreiben

SAN DedicatedStoragesystem

Gering HochParallelisierung


Bei der Wahl von Mitteln immer berücksichtigen:

10 – 50 Tabellen

500 – 1000 Tabellen

Große Tabellen PartitioniertNamentlich bekannt> 70 % des Datenvolumens

KleineTabellen Nicht PartitioniertUnkenntliche Masse< 30 % des Datenvolumens

33


34

5 %

35 %

60 %

100 %

10 %

50 %

A b f ra g e n S p e i c h e r p l at z

60 % aller Abfragen benötigen weniger als 10% der DWH Daten

60

95

100


35

50 TB Data Warehouse (z. B. Exadata ¼ Rack)

100-200 mal schneller

Flash

RAM

SAS/Sata

100-200 mal schneller

2010 2013 2017

80 %

15 %

5%

70 %

20 %

10%

0-50%

50-100 %

20%


36

60 – 70 % der Data Warehouse – Abfragenkönnen heute InMemory stattfinden

(allerdings sind nicht alle Abfragen InMemory-tauglich)


Partitionierung

37


Partitioning unterstützt viele Aufgaben

Query PerformancePartition Pruning

Beschleunigungdes Ladeprozesses

Hochverfügbarkeit auchwährend des Ladens und

Maintenance

Leichterer Umgang mitIndizierung

Unterstützung ILM(Information Lifecycle

Management)

Unterstützung im Backup-Prozess

Unterstützung bei der Aktuali-sierung von Materialized Views

(Partition Change Tracking)

Steuerung der Komprimierung

Große Tabellen

Feld für Partitionierungs-Kriterium nach fachlichen oder organisatorischenGesichtspunkten ausgewählt

RangeListHash

Tablespace

Tablespace

Tablespace

Tablespace

Tablespace

Tablespace

38


Partitioning-Typen

• Range

• List

• Hash

• Reference

• Interval

• Interval-Reference

• System

• Virtual Column

Partitioning Varianten und Verwaltung

Subpartitioning-Typen• Range - Hash• Range - List• Range - Range• List - Range• List - Hash• List – List• Hash - Hash

Management von Partitioning

• ADD PARTITION

• DROP PARTITION

• TRUNCATE PARTITION

• MOVE PARTITION

• SPLIT PARTITION

• MERGE PARTITION

• EXCHANGE PARTITION

• Verändern der Default-/ realen Attribute

• Partition Exchange Loading

39


SQL-Abfrage ist von Partitionierung unabhängig

• Gesamte Tabelle selektieren

• Abfrage nur auf eine Partition

Partitioning ist transparent

Jan 2017

Feb 2017

Mär 2017

Apr 2017

Mai 2017

Jun 2017

SELECT * FROM orders;

SELECT * FROM orders

WHERE order_dat between

to_date ('2017-01-01') AND

to_date ('2017-01-31');

Alle Partitionen werden selektiert

Partition Pruning: Automatische Beschränkung auf betroffene Partition

40


• Partitionierung nach Wertebereichen

– Für sortierte Wertebereiche

– LESS THAN: Angabe eines maximalen Wertes pro Partition

Range Partitioning - Partitionierung nach Wertebereichen

Jan 2017

Feb 2017

Mär 2017

Apr 2017

Mai 2017

Jun 2017

CREATE TABLE F_Umsatz (

Artikel_ID number,

Kunden_ID number,

Zeit_ID DATE,

Region_ID number,

Umsatz number,

Menge number

) PARTITION BY RANGE (Zeit_ID) (

PARTITION M1 VALUES LESS THAN

(to_date('2017-02-01','YYYY-DD-MM')),

PARTITION M2 VALUES LESS THAN

(to_date('2017-03-01','YYYY-DD-MM')),...

41


• 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

42


Multi Column List Partitioning

• Mehrere Spalten können zu einem LIST-Partition-Kriterium kombiniert werden

– PARTITION BY LIST (column1,column2)

43

CREATE TABLE bestellung (

bestellnr number,

auftragsart varchar2(40),

land varchar2(2),

Vertriebskanal varchar2(10)

)

PARTITION BY LIST (land,Vertriebskanal) (

PARTITION EMEA_ONLINE VALUES (('DE', 'ONLINE‘),('FR','ONLINE'), [..]),

PARTITION EMEA_DIREKT VALUES (('DE', 'DIREKT'),('FR','DIREKT'), [..]),

PARTITION AMER_ONLINE VALUES (('US', 'ONLINE‘),('CA','ONLINE'), [..]),

PARTITION AMER_DIREKT VALUES (('US', 'DIREKT'),('CA','DIREKT'), [..]),

PARTITION OTHERS VALUES (DEFAULT)

)


Automatic List Partitioning

• Automatisches Erstellen einer neuen Partition, wenn in einem „List-partitionierten“ Feld ein neuer Wert eingetragen wird.

• Neue Schlüsselwörter

– Automatic (Default)

– Manual

44

CREATE TABLE Artikelgruppen_Absatz(Artikelgruppen_id NUMBER(5),Artikel_Gruppe VARCHAR2(30),Artikel_Gruppen_Sparte VARCHAR2(20),Umsatz_Einzelwert_Summe NUMBER(10),Abrechnungs_Datum DATE)PARTITION BY LIST (Artikelgruppen_id ) AUTOMATIC(PARTITION P_Sanitaer VALUES (‘SANITAER'));


• Range ...

– Range – Range

– Range – Hash

– Range - List

• List ...

– List - Range

– List - Hash

– List - List

Composite Partitioning

Produkt

Service

Storno

JAN 07 FEB 07 MAR 07

45


• Erweiterung der Range-Partitionierung• Automatisierung für gleichgroße

Range-Partitionen

• Partitionierung wird alsMetadaten-Information abgelegt

– Start-Partition ist dabei persistent

• Sobald neue Daten hinzukommenwerden Segmente allokiert

• Lokale Indizes werden automatischmitgepflegt

Interval Partitioning

Januar

Februar

März

April

Januar

Februar

März

April

Januardaten

Aprildaten

Februardaten

Märzdaten

Mai Maidaten ?

Kunden

Pro

du

kte

• Partition Key muss NUMBER oder DATE sein • Partition-Typ muss RANGE sein

46


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

• Anwendung im DWH eher selten

• Beispiel abhängige Faktentabellen

• Bondaten (Kopf- / Positionsdaten)

47


• Add Partition (Globale und lokale Indizes bleiben “USABLE”)

• Umbenennen einer Partition

• Truncate einer Partition

• Ändern des Tablespace einer Partition (Wirkt sich nur auf künftige Partitionen aus)

Add / Rename / Truncate Partition

ALTER TABLE BESTELLUNG

ADD PARTITION "NOV08"

VALUES LESS THAN (to_date('2008-11-30 00:00:00','SYYYY-MM-DD HH24:MI:SS',

'NLS_CALENDAR=GREGORIAN'))

TABLESPACE "TS_PAR"

ALTER TABLE Bestellung RENAME PARTITION Andere TO Bestellung_Rest;

ALTER TABLE Bestellung TRUNCATE PARTITION Service DROP STORAGE;


MODIFY DEFAULT ATTRIBUTES FOR PARTITION "Jan08"

TABLESPACE TS_PAR_JAN ;

49


• Fragmentierung beheben

• Umziehen in einen anderen Tablespace

• Komprimierung der Daten einer Partition

Moving PartitionCREATE TABLESPACE TS_PAR_Archiv DATAFILE ‚

D:\o11\oradata\o11\TS_PAR_Archiv.f' SIZE 10m REUSE;


MOVE PARTITION "Jan08"

TABLESPACE TS_PAR_Archiv;

CREATE TABLESPACE TS_PAR_Archiv_Jan DATAFILE

'D:\o11\oradata\o11\TS_PAR_Archiv_Jan.f' SIZE

10m REUSE;


MOVE SUBPARTITION "Jan08_STORNO"

TABLESPACE TS_PAR_Archiv_Jan;TS_Gesamt

P1

P2

P3

P4

P5

P6

P7

sub

sub

sub

sub

sub

sub

sub

TS_Archiv

TS_Einzel_2

sub sub sub

sub

sub

sub

sub

sub

sub

sub

sub

sub

sub

sub

sub

sub

sub

sub

sub

TS_Einzel_1

• Transparente MOVE PARTITION ONLINE Operation

• Gleichzeitig DML und Abfragen möglich

• Index Pflege für lokale und globale Indizes

50


Split und Merge von Partition

ALTER TABLE Bestellung

SPLIT PARTITION "Jan08"

AT (to_date('15-JAN-2008','DD-MON-YYYY'))

INTO (PARTITION Jan08_1, PARTITION Jan08_2)

UPDATE GLOBAL INDEXES;

SELECT table_name, partition_name, high_value

FROM user_tab_partitions

WHERE table_name = 'BESTELLUNG ';

Par1

Par2

ParX

• Nicht für Reference / Hash PartitionedTables anwendbar

• Indizes werden UNUSABLE gesetzt


MERGE SUBPARTITIONS TELEFON_STORNO, TELEFON_ANDERE

INTO SUBPARTITION TELEFON_OBJEKTE

TABLESPACE TS_PAR;

sub1

sub2

subX

• Verschmolzen wird immer eine Liste von Partitionen / Subpartitionen

• Die neue Partition darf noch nicht existieren

• Funktioniert auch für Reference Partitioning, d.h. MERGE-Operation auf Parent Table wirkt sich auch auf die abhängige Tabelle aus

51


Filter für MOVE/MERGE/SPLIT-Operationen

• Einschränken der Sätze, die von einem MOVE, MERGE, SPLIT betroffen sind.

52

ALTER TABLE BESTELLUNGENMOVE PARTITION q1_2016 TABLESPACE TS_offene_bestellungen COMPRESS ONLINEINCLUDING ROWS WHERE bestell_status = ‘offen';

q1_2016

q2_2016

q3_2016

q4_2016

q1_2017

q2_2017

q3_2017

q4_2017

TS_bestellungen TS_offene_bestellungen

q1_2016

Bestell_status = ‘offen‘


Online-Split Operationen

• Aufteilen von Partitionen ohne Unterbrechung des Online-Betriebs ist möglich

• Alter Table – Statement

– ONLINE

53

CREATE TABLE orders(prod_id NUMBER(6),cust_id NUMBER,time_id DATE,channel_id CHAR(1),promo_id NUMBER(6),quantity_sold NUMBER(3),amount_sold NUMBER(10,2)) PARTITION BY RANGE (time_id)(PARTITION sales_q1_2016 VALUES LESS THAN (TO_DATE('01-APR-2016','dd-MON-yyyy')),PARTITION sales_q2_2016 VALUES LESS THAN (TO_DATE('01-JUL-2016','dd-MON-yyyy')),PARTITION sales_q3_2016 VALUES LESS THAN (TO_DATE('01-OCT-2016','dd-MON-yyyy')),PARTITION sales_q4_2016 VALUES LESS THAN (TO_DATE('01-JAN-2017','dd-MON-yyyy')) );ALTER TABLE ordersSPLIT PARTITION sales_q4_2016 INTO(PARTITION sales_oct_2016 VALUES LESS THAN (TO_DATE('01-NOV-2016','dd-MON-yyyy')),PARTITION sales_nov_2016 VALUES LESS THAN (TO_DATE('01-DEC-2016','dd-MON-yyyy')),PARTITION sales_dec_2016)ONLINE;


Erstellen einer Tabelle aus einer Partition EXCHANGE

SQL> CREATE TABLE Bestellung_Produkte AS

2 SELECT * FROM bestellung WHERE 1=2

SQL> /

Tabelle wurde erstellt.

SQL> ALTER TABLE Bestellung

2 EXCHANGE PARTITION Produkt

3 WITH TABLE Bestellung_Produkte;

Tabelle X Allgemeine Syntax:

ALTER TABLE <Tabellen-Name>

EXCHANGE PARTITION <Partition-Name>

WITH TABLE <neue Tabelle>

<including | excluding> INDEXES

<with | without> VALIDATION

EXCEPTIONS INTO <Schema.Tabellen-Name>;

Die Zieltabelle muss existieren

TS_Gesamt

P1

P2

P3

P4

P5

P6

P7

sub

sub

sub

sub

sub

sub

sub

sub

sub

sub

sub

sub

sub

sub

sub

sub

sub

sub

sub

sub

sub

54


Partitioning auf External Tables

55

CREATE TABLE sales (loc_id number, prod_id number, cust_id number, amount_sold number, quantity_sold number)ORGANIZATION EXTERNAL(TYPE oracle_loaderDEFAULT DIRECTORY load_d1ACCESS PARAMETERS( RECORDS DELIMITED BY NEWLINE CHARACTERSET US7ASCIINOBADFILELOGFILE log_dir:'sales.log'FIELDS TERMINATED BY ",„))REJECT LIMIT UNLIMITEDPARTITION BY RANGE (loc_id)(PARTITION p1 VALUES LESS THAN (1000) LOCATION ('california.txt'),PARTITION p2 VALUES LESS THAN (2000) DEFAULT DIRECTORY load_d2

LOCATION ('washington.txt'),PARTITION p3 VALUES LESS THAN (3000));

• Partition Pruning und

• Partition-Wise Joins

– Beide Join-Tabellen müssen über das gleiche Feld partitioniert sein

– Auch Reference-Partitioning (Join zwischen Parent / Child –Tables)

• Range-, List- und Composit-Partitioning


R R

B

S S S

D

D

DD

Enterprise Information Layer User View LayerData Integration Layer

T

T

T

T: Transfertabellen

R: Referenztabellen

S: Stammdaten

B: Bewgungsdaten

D: Dimensionen

F: Fakten

B

F

Wo und wie wird im DWH partitioniertL 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

Partitioning und Ladesteuerung laufen oft synchronParallelisierung

Partition PruningParallelisierung

80%

20%

ILM

PEL

VorbereitungTemporäreTabellen(Prüfungen etc)

Bewegungsdaten sindPartitioniert (80/20 – Prinzip)

Faktentabellenkönnen partitioniert sein

Backup

56


Partitionierung im Star

D_ZEITDATUM_ID TAG_DES_MONATS TAG_DES_JAHRES WOCHE_DES_JAHRESMONATS_NUMMER MONAT_DESC QUARTALS_NUMMER JAHR_NUMMER ZEIT_ID

D_VERTRIEBSKANAL

KANAL_IDVERTRIEBSKANAL KANALBESCHREIBUNG VERANTWORTLICH KLASSE

F_UMSATZ

PK

PK

PK: Btree Index

FK: Bitmap Index

AR

TIK

EL_I

DK

UN

DEN

_ID

ZEIT

_ID

REG

ION

_ID

KA

NA

L_ID

UM

SATZ

MEN

GE

UM

SATZ

_G

ESA

MT

FK

FK

FK

FK

FK

Range-Partitioning nach Zeit

Mehr als 80 % aller Partitionierungen sind so aufgebaut.

57


Partitionierung im Star


D_VERTRIEBSKANAL


F_UMSATZ

PK

PK

PK: Btree Index

FK: Bitmap Index

AR

TIK

EL_I

DK

UN

DEN

_ID

ZEIT

_ID

REG

ION

_ID

KA

NA

L_ID

UM

SATZ

MEN

GE

UM

SATZ

_G

ESA

MT

FK

FK

FK

FK

FK

Range-Partitioning nach ZeitList-Partitioning nach Vertriebskanal

Mehr als 80 % aller Partitionierungen sind so aufgebaut.

58


Schlüssel und Indizierung im Data Warehouse

59


B*Tree Index – 4 Zugriffe bis zum Wert

Zugriff über die RowID

1

2

3

4

Clustering Factor

60


Bitmap – Zugriff auf Werte per Bit StreamRowid 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‘;

61


Platzverbrauch im Vergleich

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

Tests mit unterschiedlicher Kardinalität

62


(Bitmap-) Indizierung – Ideal für Warehouse-Abfragen

D_ARTIKEL(Dimension)

ARTIKEL_IDARTIKEL_NAMEGRUPPE_NR GRUPPE_NAME SPARTE_NAME SPARTE_NR

F_UMSATZ(Fakten)

KANAL_IDKUNDEN_IDZEIT_IDREGION_IDARTIKEL_IDUMSATZMENGEUMSATZ_GESAMT

PK

FK

FK

FK

FK

FK

D_KUNDE (1 Million) (Dimension)

KUNDEN_IDKUNDENNR GESCHLECHTVORNAME NACHNAME TITEL GEBDAT BRANCHE WOHNART KUNDENARTBILDUNG ANZ_KINDER EINKOMMENSGRUPPE BERUFSGRUPPE STATUS KONTAKTPERSONFIRMENRABATT BERUFSGRUPPEN_NR BILDUNGS_NR EINKOMMENS_NR WOHNART_NR KUNDENKARTE 2 Werte

PK

100 Werte20 Werte

20 Werte

10 Werte

Unique

Unique

3 Werte 0,0003 %

0,0020 %

0,0010 %

0,0020 %0,01 %

0,0002 %

Selektivität • Bitmap-Indizierung für

• Werte-MengenorientierteBereichsabfragen

• Immer bei Selektivität < 30%

• Fast immer bei Dimensionsattributen

63


• OLTP-Option: Rebuild Index Operation

• Schneller als DROP / CREATE

– NOLOGGING-Klausel

• Fragmentierung wird beseitigt

• Wenig hilfreich im DWH

– Änderungen aber oft als Batch-Lauf durchgeführt

Zunächst DROP INDEX (beschleunigt den Batch-Lauf)

Dann Neuerstellen des Index

Aktualisieren von Indexen

ALTER INDEX index_name REBUILD [ NOLOGGING ];

1. INDEX auf Unusable setzen [Alter index index_name unusable]

2. ETL-Massen-Load

3. INDEX Rebuild [Alter index index_name rebuild]

Oder

64


Partitioning und Indizes

• Lokale Indizes

• Nicht-partitionierte oder partitionierte globale Indizes

• USABLE oder UNUSABLE Index Segmente

– Nicht-persistenter Index Status

– Losgelöst von der Tabelle

• Partielle lokale und globale Indizes

– Erwirkt spezielle Metadaten auf [Sub]Partitionsebene

– Interagiert mit dem USABLE/UNUSABLE Status für lokale Indizes

– Indizierung jederzeit anpassbar

65


Prefixed / Non Prefixed IndexesP

arti

tio

n K

eyB

est

elld

atu

m PartitionierteTabelle

“Bestellung”Indiziert nachBestelldatum,

Kundennummer

Indiziert nachAuftragsart

Prefixed localIndex

Non-Prefixed

Gut für Managementder Partitionen

Einfacher Index

Indiziert nachBestelldatum

Local Index

Ku

nd

en

nu

mm

er

Be

ste

lldat

um

Au

ftra

gsar

t

Gut für nicht Part-Key

gesteuerte Abfragen

Im DWH relevante Variante

66


Star Query Transformation

67


SELECT sum(summe) FROM

F_Umsatz U,

D_Artikel A,

D_Region R,

D_Zeit Z,

D_Kunde K

WHERE

U.FK_Kunden_ID = K.Kunden_ID

AND U.FK_Datum_ID = Z.Datum_ID

AND U.FK_Ort_ID = R.Ort_ID

AND U.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 TransformationOptimierung für Joins mit großen Faktentabellen

1.000.000

65

12.834

3.074

1.029

68


STAR_TRANSFORMATION_ENABLED=FALSE;Abgelaufen: 00:00:03.48

--------------------------------------------------------------------------------------

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

----------------------------------------------------------------------------------------

69


Abgelaufen: 00:00:00.76

------------------------------------------------------------------------------------------------

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


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


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


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

70


Bitmap-Indizierung im Star Schema D_ARTIKELARTIKEL_SPARTEN_NR ARTIKEL_SPARTE ARTIKEL__SEGMENT_NR ARTIKEL__SEGMENTARTIKEL_GRUPPEN_NR ARTIKEL_GRUPPE ARTIKEL_PREIS ARTIKEL_NAMEARTIKEL ID

D_VERTRIEBSKANAL


F_UMSATZ

PK

PK

PK: Btree Index

FK: Bitmap Index

AR

TIK

EL_I

DK

UN

DEN

_ID

ZEIT

_ID

REG

ION

_ID

KA

NA

L_ID

UM

SATZ

MEN

GE

UM

SATZ

_G

ESA

MT

FK

FK

FK

FK

FK

100.000

1.000

10010

Star-Transformation

71


Wo und wie wird im DWH indiziert


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

B*tree für Primary KeysIn den DimensionenTabellen

72


Query-Optimizer und System-Statistiken im Data Warehouse

73


• Regelmäßig aktuelle Statistiken sind wichtig für gute Ausführungspläne

• Ständiges Aktualisieren belastet das System

• Best Practice im DWH

– Statistiken in Verbindung mit dem ETL-Prozesse aktualisieren.

– Nur diejenigen Tabellen, Partitionen und Indexe aktualisieren, die aktuell geladen bzw. verändert wurden.

– => Automatisiertes Aktualisieren sollte genau überlegt werden

Statistiken sammeln

DBMS_STATS.GATHER_TABLE_STATS(Ownname=><OWNER>, Tabname=><TABLE_NAME>);

DBMS_STATS.GATHER_TABLE_STATS(Ownname=><OWNER>, Tabname=><TABLE_NAME>, Partname=><PARTITION_NAME>, GRANULARITY=>'PARTITION'); DBMS_STATS.GATHER_INDEX_STATS(Ownname=><OWNER>,Indexname=><TABLE_NAME>);

74


Sammeln von Statistiken

• Tabellen -> GATHER_TABLE_STATS

• Indexe -> GATHER_INDEX_STATS

• Schema -> GATHER_SCHEMA_STATS

• Automatisiertes Sammeln für ein Schema

• Automatisiertes Sampling– Parameter DBMS_STATS.AUTO_SAMPLE_SIZE

Begin

dbms_stats.gather_schema_stats(

ownname => 'PERF'

,options => 'GATHER AUTO'

,estimate_percent => 5

,block_sample => TRUE);

end;

EXEC DBMS_STATS.GATHER_TABLE_STATS (

'PART','BESTELLUNG_PART_RANGE',

estimate_percent=>100);

EXEC dbms_stats.gather_schema_stats(

ownname => 'PERF',

estimate_percent => 5,block_sample => TRUE)

EXECUTE DBMS_STATS.GATHER_SCHEMA_STATS(

'OE',DBMS_STATS.AUTO_SAMPLE_SIZE);

75


Sammeln von Column-bezogenen Statistiken (Histogramme)

• Sinnvoll bei komplexen where-Bedingungen und starker Ungleich-Verteilung der Werte innerhalb einer Spalte

begin

DBMS_STATS.GATHER_TABLE_STATS(Ownname=>'DWH',

Tabname=>'F_UMSATZ' ,

METHOD_OPT =>

'FOR COLUMNS SIZE AUTO KUNDEN_ID,ARTIKEL_ID,ZEIT_ID, REGION_ID, KANAL_ID’);

end;

begin

DBMS_STATS.GATHER_TABLE_STATS(Ownname=>'DWH',

Tabname=>'F_UMSATZ' ,

METHOD_OPT =>

'FOR COLUMNS SIZE 20 KUNDEN_ID,ARTIKEL_ID,ZEIT_ID, REGION_ID’);

end;

76


Abfrage der Art Histogramme

• HEIGHT BALANCED: Aufteilung aller Werte in n-Gruppen

– Hier kann der Grenzwert der jeweiligen Grueppen abgefragt werden

• FREQUENCY: Auflistung der Menge pro vorkommenden Wert

SELECT column_name, num_distinct, num_buckets, histogram

FROM user_tab_col_statistics

WHERE table_name = 'F_UMSATZ';

COLUMN_NAME NUM_DISTINCT NUM_BUCKETS HISTOGRAM

------------------------------ ------------ ----------- --

ARTIKEL_ID 129 20 HEIGHT BALANCED

KUNDEN_ID 1031 20 HEIGHT BALANCED

ZEIT_ID 6001 20 HEIGHT BALANCED

REGION_ID 7020 20 HEIGHT BALANCED

KANAL_ID 7 7 FREQUENCY

77


Histogramme machen Sinn wenn

• Histogramme machen Sinn wenn

– Wenn Spalten ungleichmäßig verteilte Werte haben und in der WHERE-Klausel von Abfragen vorkommen

– Spalten die seltener abgefragt werden, und daher keine Indexe haben

• Histogramme nicht anlegen bei– Gleich verteilten Spaltenwerten

– Nicht für alle Spalten einer Tabelle zu viel Overhead

– PKs oder indizierten Spalten

– Spalten, die nicht abgefragt werden

78


DynamicSampling

• Zusätzliche Hilfen für den Optimizer

– Werte von 1 – 10 (Default 2)

• Setting

– alter system set optimizer_dynamic_sampling=4;

– Manuelles Setzen ist sinnvoll wenn SQL seriell

– System wählt automatisch den Einstellwert bei Parallelisierung

• Testen

• Sinnvoll bei komplexen WHERE-Klauseln

79


• Incremental Global Statistics

– Synapsis Struktur in SYSAUX Tablespace

– Sehr schnelles Erzeugen der globalen Statistiken ohne die komplette Tabelle zu lesen

• Inkrementelles Aktualisieren einschalten

• Initiales einmaliges Sammeln

• Inkrementelles Sammeln geschieht automatisch über• EXEC DBMS_STATS.GATHER_TABLE_STATS(‚DWH1','UMSATZ');

Inkrementelles Statistiksammeln

DBMS_STATS.SET_TABLE_PREFS(<OWNER>, <TABLE_NAME>, 'INCREMENTAL', TRUE);

DBMS_STATS.GATHER_TABLE_STATS(Ownname=><OWNER>, Tabname=><TABLE_NAME>, DEGREE=><DESIRED_DEGREE>);

DBMS_STATS.GATHER_TABLE_STATS(Ownname=><OWNER>, Tabname=><TABLE_NAME>, Partname=><SUBPARTITION_NAME>, GRANULARITY=>'SUBPARTITION', DEGREE=><DESIRED_DEGREE>);

Oracle Database Performance Tuning Guide 11g Release 2 / Chapter 13 - Managing Optimizer Statistics

http://download.oracle.com/docs/cd/E11882_01/server.112/e10821/stats.htm 80


• Globale Statistiken regelmäßig sammeln– Z. B. einmal im Monat

• Einschalten des ‚Incremental‘- Modus für die entsprechende Tabelle:– EXEC DBMS_STATS.SET_TABLE_PREFS(‚DWH',‘UMSATZ,

'INCREMENTAL','TRUE');

• Nach jedem Laden einer neuen Partition, die Statistiken aktualisieren:– EXEC DBMS_STATS.GATHER_TABLE_STATS('DWH','UMSATZ');

Anwendung im DWH bei partitionierten Tabellen

Partition Tag 1

Partition Tag 2

Partition Tag 3

Partition Tag 4

Partition Tag 5

Partition Tag 7

Partition Tag 8

Partition Tag 9

Partition Tag 10

Partition Tag n

Globale tatistiken

Neu hinzugefügte Partiton verfälscht Statistiken

ETL

81


Empfehlungen

• Dynamic Sampling auf einen höheren Wert setzen (z. B. 4)

• Bei großen pratitionierten Tabellen mit „Inkrementellem Statistik-Sammeln“ arbeiten.

• Histogramme gezielt für Spalten mit ungleich verteilten Werten verwenden, wenn sie oft abgefragt werden.

• Große Tabellen in dem Kontext des ETL-Prozesses aktualisieren

-> ETL-Gesamt-Konzept

82


Komprimierung im Data Warehouse

83


84

Komprimierung

• Komprimierung besonders wichtig, da große Datenmengen

• Besonders grasser Unterschied zwischen– Daten, die häufig gelesen werden Sehr wenige– Daten, die selten bis kaum gelesen werden Sehr viele

• Umfang der Komprimierung abhängig von der Art der Speicherung– Satz- , Spalten-orientiert

• Steuerung über Automatismen– Information Life Cycle Management– Partitionierung

• Lese- und Schreib-Operationen sind bestimmbar– Massen-Schreibaktionen können explizit auch zum Komprimieren genutzt werden– Updates kommen seltener vor


85

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

Das Datenwachstum beherrschenKomprimieren: Verwaltung und Kosten reduzieren


86

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


Syntaxänderung in 12c

• Änderungen für Basic, OLTP und HCC Compression

• BASIC

• OLTP

• Beispiel für HCC

CREATE TABLE sales_history(…)

ROW STORE COMPRESS BASIC;


ROW STORE COMPRESS ADVANCED;


COLUMN STORE COMPRESS FOR QUERY HIGH;

87


Data Optimization

88


89

Automatic Data Optimization im Data Warehouse

In MemoryFlash / SSDDISKSata/SAS Juni 16

Mai 16

April 16

März 16

Februar 16

Januar 16

Dezember 15

November 15

Oktober 15

September 15

August 15

Juli15

Juni 15

April 15

März 15

Februar 15

Juni 16

Mai 16

April 16

März 16

Februar 16

Januar 16

Dezember 15

November 15

Oktober 15

September 15

August 15

Juli15

Juni 15

April 15

März 15

Februar 15

Umsatzdaten

Eine historisierteTabelle verteilt sich auf Automatisches

Verlagern über die Zeit

AutomatischesHervorholenüber die Häufigkeitder Verwendung


Automatisiertes Information Life Cycle Management (ILM)

90

• Regelgesteuertes Verfahren zur physikalischen Datenverwaltung

• Automatisierte Heatmaps sammelt

– Änderungs- und Lesevorgänge

– Auf Block- und Segmentlevel

• Automatic Data Optimization (ADO)

– Bewegt und komprimiert auf der Basis von Regeln

– Steuerung entweder über Heatmap oder selbsterstellte Prozeduren

• Ausnutzen von Partitioning und Komprimierung

• Steuern über

SQL> ALTER SYSTEM SET heat_map = 'ON';

SQL> ALTER SYSTEM SET heat_map = 'OFF'; SQL> ALTER SESSION SET heat_map = 'OFF';

SQL> ALTER SESSION SET heat_map = 'ON';


91


Automatisches Komprimieren wenn x-Tage nicht genutzt

92

• Steuerung auf Segment und Block-Ebene(Segmente: Tabellen, Partitionen, Materialized Views, Indexe)

• Automatisiertes Steuern von Komprimieren

– über die Heatmaps und zeitliche Verläufe

– über Füllgrade von Tablespaces

• Automatic Data Optimization (ADO)

– Bewegt und komprimiert auf der Basis von Regeln

– Steuerung entweder über Heatmap oder selbsterstellte Prozeduren

• Ausnutzen von Partitioning und Komprimierung

ALTER TABLE orders ILM ADD POLICY ROW STORE COMPRESS ADVANCED SEGMENT AFTER 30 DAYS OF NO MODIFICATION;

ALTER TABLE orders ILM ADD POLICY COLUMN STORE COMPRESS FOR QUERY HIGH SEGMENT AFTER 90 DAYS OF NO MODIFICATION;


Automatisches Verschieben wenn Füllgrad erreicht

93

ALTER TABLE orders ILM ADD POLICY COLUMN STORE COMPRESS FOR ARCHIVE HIGH SEGMENT AFTER 90 DAYS OF NO MODIFICATION;

ALTER TABLE orders ILM ADD POLICYCOLUMN STORE COMPRESS FOR QUERY HIGH SEGMENT AFTER 30 DAYS OF NO MODIFICATION;

ALTER TABLE orders ILM ADD POLICY tier to low_cost_store;

BEGIN DBMS_ILM_ADMIN.CUSTOMIZE_ILM(DBMS_ILM_ADMIN.TBS_PERCENT_USED, 85): DBMS_ILM_ADMIN.CUSTOMIZE_ILM(DBMS_ILM_ADMIN.TBS_PERCENT_FREE, 25):

END;

Wenn TablespaceNORMAL zu 85% gefüllt, dann automatisches Verschieben der„kältesten“ Partition nach COLD

Juni 16

Mai 16

April 16

März 16

Februar 16

Januar 16

Tablespace(datafile) COLD

Tablespace(datafile) NORMAL

?


Automatic Data Optimization und In-Memory

94

ALTER TABLE sales ilm ADD policyMODIFY INMEMORY memcompressFOR query high AFTER 3 days OFNo modification

ALTER TABLE sales ilm ADD policy NO INMEMORY SEGMENT AFTER 30 days OF no ACCESS;

CREATE OR REPLACE FUNCTION custom_im_ado (objn IN NUMBER)RETURN BOOLEAN ;

ALTER TABLE sales ilm ADD policyNO INMEMORY SEGMENT ON custom_im_ado;

• Zeitabhängiges Automatisches Komprimieren von Im-Memory-Tabellen

• Zeitabhängiges Entfernen von Tabellen aus dem In-Memory-Column-Store

• Steuern der In-Memory-Fähigkeitüber eine programmierte Funktion


Heat Map für Tabellen und Partitionen

“Segment” Level Tracking OWNER OBJECT_NAME TRACK_TIME WRI FUL LOO

---------- ----------------------- ---------------- --- --- --

SH CUSTOMERS_PK 25.06.2013 22:48 NO NO YES

SCOTT DEPT 25.06.2013 12:48 NO YES NO

SCOTT EMP 26.06.2013 12:30 YES YES NO

SCOTT EMP 25.06.2013 12:48 NO YES NO

SCOTT EMP 24.06.2013 11:47 NO YES NO

SCOTT PK_EMP 26.06.2013 22:30 NO NO YES

SCOTT PK_EMP 25.06.2013 22:48 NO NO YES

95

Auf Tabellen-Ebene.Abfrage über DBA_HEAT_MAP_SEG_HISTOGRAM

“Row” Level Tracking TABLESPACE FNO BLOCK_ID WRITETIME

---------- ---------- ---------- ---------------

USERS 6 347 25.06.2013 14:45

USERS 6 348 25.06.2013 14:45

USERS 6 349 25.06.2013 14:45

USERS 6 350 25.06.2013 14:45

USERS 6 351 25.06.2013 14:45

…

Auf Block-EbeneAbfrage über DBMS_HEAT_MAP


Parallelisierung

96


97

Parallelisierung: Faustregeln

• Verteilung von Lese-/Schreiboperationen auf mehrere Prozesse:

– Parallel 2 -> i. d. R. Halbierung der Wartezeit…

– Parallel 4 -> i. d. R. Drittelung der Wartezeit…

• Bei nicht IO-optimierten Systemen (nicht-Exadata, nicht-In-Memory)– Limitierung meist durch das Plattensystem

– Weitere Faktoren Anzahl CPU-Cores und Hauptspeicher

• Einführung von In-Memory erhöht in der Regel auch deutlich dieMöglichkeiten zur Parallelisierung

• Steuerung der Parallelität

– In ETL-Läufen: Gezielte manuelle Steuerung der Parallelität

– In der Online-Situation: Automatische Steuerung durch das System


98

• Abfragen– SELECT

– Join Operationen

– Sort Operationen

– GROUP BY

• DDL– CREATE TABLE/MV

– CREATE INDEX

– Online Index Rebuild

• DML– INSERT

– UPDATE / DELETE

– MOVE / SPLIT PARTITION

Parallelisierung und Skalierung

• Parallelisierbare Operationen

Ein SQL Statement wird vom Optimizer in kleinereArbeitsschritte aufgeteilt und läuft skalierbar ab

CPU

SQL

serial 100%

50%

I/O

100%

50%

parallel

SQL

CPU I/O


99

Steuerung der Parallelität mit “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;

SI : DOP = PARALLEL_THREADS_PER_CPU x CPU_COUNT

RAC: DOP = PARALLEL_THREADS_PER_CPU x CPU_COUNT x INSTANCE_COUNT


100

Parallel Degree PolicyAusführungsplan

----------------------------------------------------------

Plan hash value: 4226669230

-----------------------------------------------------------------------------------

| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |

-----------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 7 | 371 | 81975 (9)| 00:00:03 |

| 1 | VIEW | | 7 | 371 | 81975 (9)| 00:00:03 |

| 2 | WINDOW SORT | | 7 | 196 | 81975 (9)| 00:00:03 |

| 3 | HASH GROUP BY | | 7 | 196 | 81975 (9)| 00:00:03 |

|* 4 | HASH JOIN | | 51M| 1367M| 76249 (2)| 00:00:03 |

| 5 | TABLE ACCESS FULL| D_ARTIKEL | 129 | 2709 | 3 (0)| 00:00:01 |

| 6 | TABLE ACCESS FULL| F_UMSATZ | 51M| 341M| 75998 (2)| 00:00:03 |

-----------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

4 - access("U"."ARTIKEL_ID"="A"."ARTIKEL_ID")

Note

-----

- automatic DOP: Computed Degree of Parallelism is 1

Note

-----

- automatic DOP: skipped because of IO calibrate statistics are missing


Parallel Server leisten die Hauptarbeit

Query Coordinator

101

SQL Parallel Execution Plan

ID Operation Name TQ IN-OUT PQ Distribution

0 SELECT STATEMENT

1 PX COORDINATOR

2 PX SEND QC {RANDOM} Q1,01 P->S

3 HASH JOIN Q1,01 PCWP

4 PX RECEIVE Q1,01 PCWP

5 PX SEND BROADCAST Q1,01 P->P BROADCAST

6 PX BLOCK ITERATOR Q1,01 PCWP

7 TABLE ACCESS FULL CUSTOMERS Q1,01 PCWP

8 PX BLOCK ITERATOR Q1,01 PCWP

9 TABLE ACCESS FULL SALES Q1,01 PCWP

SELECT c.cust_name, s.purchase_date, s.amount

FROM sales s, customers c

WHERE s.cust_id = c.cust_id;


102

Execution Plan

ID Operation Name Pstart Pstop TQ PQ Distrib

0 SELECT STATEMENT

1 PX COORDINATOR

2 PX SEND QC (RANDOM) :TQ10001 Q1,01 QC (RAND)

3 SORT GROUP BY Q1,01

4 PX RECEIVE Q1,01

5 PX SEND HASH :TQ10000 Q1,00 HASH

6 SORT GROUP BY Q1,00

7 PX PARTITION HASH ALL 1 128 Q1,00

8 HASH JOIN Q1,00

9 TABLE ACCESS FULL Customers 1 128 Q1,00

10 TABLE ACCESS FULL Sales 1 128 Q1,00

“Partition Hash All” über dem Join & Einfaches PQ Set bezeichnet Partition-wise Join


Query Result Cache

103


• 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

Konzept und Einsatz des Result Cache

104


• 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

Implementierung und Nutzung

SELECT /*+ result_cache */ count(*) FROM sales

SELECT count(*) FROM sales ...

105


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

106


Flexibilisierung und Effizienz

107


Wo Flexibilität fehlt: Fälle aus der alltäglichen Praxis

• Schichtenmodell ist Blaupause für Verantwortlichkeiten -> Hoheitsgebiete

– Teure Abstimmprozesse und Formalismus

– Fehlende Spontanität für pragmatische Lösungen

– Zu starr und langsam bei der Umsetzung neuer Informations-Bedarfe

• Fehlendes zentrale Schicht

– Viele Redundanzen, wenig Wiederverwendung

– fehlende Synchronisation bei zusammenhängendenThemen -> nicht stimmige Daten

– Fehlende sachgebietsübergreifende Breite beim Informationsangebot

– Daten müssen immer wieder aus den Vorsystemen geholt werden -> Zeitaufwand


IntegrationLayer

DWH-

Admin

User ViewLayer

User ViewLayer

User ViewLayer

Fach

Anwender

IntegrationWarehouse

DWH-

Admin

User ViewLayer

User ViewLayer

User ViewLayer

Fach

Anwender

?

108


109

Möglichkeiten / Maßnahmen zur Flexibilisierung

• Architekturen

– Virtualisierung der Data Marts

– Fließende Übergänge zwischen Enterprise- und User View-Layer

– Wegfall von separaten BI-Schichten, außerhalb des Data Warehouse

– Standardisierte Kennzahlen-Festlegung bereits im Enterprise-Layer

• Organisatorisch– Zugriff von Endbenutzern auf zentrale Schicht

– Regelmäßige Informationsbedarfserhebung und Abstimmung zwischen IT und Benutzergruppen


Analysen vorwegnehmen / Kennzahlen standardisieren

110

• 50 – 80% aller Benutzerabfragen, Analysen, Kennzahlen sind vorhersehbar

• Vorhersehbare Informationsbedarfe sollten mittels eines Konzeptes vorbereitet werden

• Dazu sind keine weiteren Tools nötig

• Hilfsmittel

– Analytische Funktionen

– Pattern-Analyse

– Kennzahlensysteme / Materialized Views

– R-Analysen / Mining-Modelle


111

Betriebliche Kennzahlen...

• ...messen betriebliche Vorgänge

• ...beurteilen Sachverhalte

• ...reduzieren Komplexität durch kurzeund prägnante Darstellung

• ...können Ziele festlegen

• ...legen kritische Erfolgsfaktoren fest

Kennzahlen verdichten Informationen.Sie machen Sachverhalte sichtbar, die In den üblichen Betriebsdaten schwer erkennbar sind


Konzepte rund um Kennzahlen

• Abstimmung mit Fachanwendern

• Publizierbare Definition

• Metadatenartige Beschreibung von Kennzahlen

• Im Schichten Kennzahlen so früh wie möglich berechnen

• Keine Abhängigkeiten von flüchtigen Strukturen schaffen

– Z. B Auswertemodelle, die einem permanenten Wechsel unterliegen

• Auf Standardisierung achten

• Auf Wiederverwendung achten

• Kennzahlen in granularisierbare Teilinformationen zergliedern

– Granulare Teile hierarchisieren

112


113

Beschreibungsmerkmale „Kennzahl“• Name

• Synonym

– Referenz -> KENNZAHL

– Referenz -> GLOSSAR

• Bereich: Standardwerte z. B. - Finanzielle Ergebnisse

- Qualität von etwas (Produkt/Service)

- Ablauf, Fortschritt von etwas (Prozess)

- Leistungsfähigkeit von etwas

• Geschäftsprozess

- Referenz -> PROZESS

• Definition (Text)

• Beschreibung (Text)

• Ziel / Zweck (Text)

• Zielgruppe [Abteilung, MA, Rolle]

• Aktualisierungsfrequenz (Zeitangabe)

• Maßeinheit [%, Wertgröße, Zeit]

• Rechen-/Herleitungsregel

• Messwertvariante

– Absolute Größe

– Verhältniswert– Gliederungszahl (Bsp. Eigenkapital ist Teil von Gesamtkapital)

– Beziehungszahl (Verhältnis von 2 Werten untereinander)

– Indexzahl (Gleichartige Größen in zeitlich oder räumlich

getrennten Bereichen. Z. B. Veränderung im Vergleich zum Vorjahr)

– Richtwert / Orientierungsgröße

• Quelldaten (Text, Ursprung der Daten)

• Verwendete Größen

Referenz -> COLUMN/ATTRIBUT

• Regel / Referenz -> RULE

• Org-Level [Top, Mittel, operativ]

• Zeitmaß [Jahr , Quartal, Monat, Woche, Tag]

• Historie [Vergangenheit, Aktuell, Zukunft]

• Hierarchieposition- Referenz SUB_von -> KENNZAHL

- Referenz TOP_von -> KENNZAHL



User ViewLayer

IntegrationLayer

Wo wird „vorbereitet“

ControllingProfitabilität

LogistikLogistikaufwand

ServiceServicekunde

MarketingMarketingsicht

VertriebKundenhistorie

EinkaufProdukte&Trends

D

D

DD

F

F

F

D

D

D

D

R R BS S S

BBBT

T

T

B

B

Strategische Daten

TaktischeDaten

• Kennzahlen so früh wie möglich

• Keine Abhängig-keiten von flüchtigen Strukturen schaffen

• Auf Standardisierungachten

• Auf Wieder-verwendung achten

KennzahlenVorberechnungen

114


Dimensions-Level bereits im Kernmodell vorsehen

115

Artikelsparten

Artikelgruppen

Artikel

Liefereinheit

Verladeeinheit

Gebinde

Vermittlungsart

Produktart

Alle Produkte

Segment

Konzeptionelles Sicht

Create Materialized View …. AS SELECT a.artikel_name Artikel, sum(u.umsatz) umsatz_pro_Artikel,FROM f_Umsatz_2014 U, D_artikel a

WHERE U.artikel_id = a.artikel_idgroup by a.artikel_name

Artikelsparten

Artikelgruppen

Artikel

Liefereinheit

Verladeeinheit

Gebinde

Vermittlungsart

Produktart

Alle Produkte

Segment

Umsatz

Selectsum(UMSATZ) , Produktart

fromF_UMSATZ, D_Artikel

Group by Produktart;

Materialized View

Der Anwender fragt immer anders, als man denkt.Macht aber nichts.Die Wünsche werden trotzdem erfüllt.Modellsicht Enterprise Layer


• So viel wie möglich in der DB vorbereiten

• Wiederverwenden von bereits berechneten Kennzahlen

• Verhindert unnötiges Kopieren

• Keine Verlagerung von Pseudo-ETL in die BI-Tools

• Standardisierte Kennzahlen

• Abfragen werden gruppiert

Der Weg in die BI-Tools

User View Layer

BI-

Too

l Se

rve

r +

Cac

he

s

User View Layer

So

Oder so

Millionen von Sätzen

WenigeSätze

116


Materialized Views und Kennzahlenkonzepte

117


Prinzip und Aufgabenstellung - Summentabellen

Basistabelle Summentabelle

Änderungen

?

stale

Complete RefreshIncremental Refresh

118


σ 𝑼𝒎𝒔𝒂𝒕𝒛 𝒑𝒓𝒐 𝑹𝒆𝒈𝒊𝒐𝒏 𝒑𝒓𝒐 𝑺𝒑𝒂𝒓𝒕𝒆

σ 𝑼𝒎𝒔𝒂𝒕𝒛 𝒑𝒓𝒐 𝑳𝒂𝒏𝒅 𝒑𝒓𝒐 Sparte

σ 𝑼𝒎𝒔𝒂𝒕𝒛 𝒑𝒓𝒐 𝑲𝒓𝒆𝒊𝒔 𝒑𝒓𝒐 𝑺𝒑𝒂𝒓𝒕𝒆

σ 𝑼𝒎𝒔𝒂𝒕𝒛 𝒑𝒓𝒐 𝑶𝒓𝒕 𝒑𝒓𝒐 𝑺𝒑𝒂𝒓𝒕𝒆

Kennzahlen auf Data Mart-Ebene – Star Schema nicht zwingend

D_ARTIKEL(Dimension)

ARTIKEL_IDARTIKEL_NAMEGRUPPE_NR GRUPPE_NAME SPARTE_NAME SPARTE_NR

F_UMSATZ(Fakten)

KANAL_IDKUNDEN_IDZEIT_IDREGION_IDARTIKEL_IDUMSATZMENGEUMSATZ_GESAMT

FK

FK

FK

FK

FK

D_REGION(Dimension)

REGIONNR REGION LANDNRLANDKREISNRKREIS ORTNRORTREGION_ID

σ 𝑼𝒎𝒔𝒂𝒕𝒛 𝒑𝒓𝒐 𝑹𝒆𝒈𝒊𝒐𝒏

σ 𝑼𝒎𝒔𝒂𝒕𝒛 𝒑𝒓𝒐 𝑳𝒂𝒏𝒅

σ 𝑼𝒎𝒔𝒂𝒕𝒛 𝒑𝒓𝒐 𝑲𝒓𝒆𝒊𝒔

σ 𝑼𝒎𝒔𝒂𝒕𝒛 𝒑𝒓𝒐 𝑶𝒓𝒕

σ 𝑼𝒎𝒔𝒂𝒕𝒛 𝒑𝒓𝒐 𝑨𝒓𝒕𝒊𝒌𝒆𝒍

σ 𝑼𝒎𝒔𝒂𝒕𝒛 𝒑𝒓𝒐 𝑮𝒓𝒖𝒑𝒑𝒆

σ 𝑼𝒎𝒔𝒂𝒕𝒛 𝒑𝒓𝒐 𝑺𝒑𝒂𝒓𝒕𝒆

σ 𝑼𝒎𝒔𝒂𝒕𝒛 𝒑𝒓𝒐 𝑹𝒆𝒈𝒊𝒐𝒏 𝒑𝒓𝒐 𝑮𝒓𝒖𝒑𝒑𝒆

σ 𝑼𝒎𝒔𝒂𝒕𝒛 𝒑𝒓𝒐 𝑳𝒂𝒏𝒅 𝒑𝒓𝒐 Gruppe

σ 𝑼𝒎𝒔𝒂𝒕𝒛 𝒑𝒓𝒐 𝑲𝒓𝒆𝒊𝒔 𝒑𝒓𝒐 𝑮𝒓𝒖𝒑𝒑𝒆

σ 𝑼𝒎𝒔𝒂𝒕𝒛 𝒑𝒓𝒐 𝑶𝒓𝒕 𝒑𝒓𝒐 𝑮𝒓𝒖𝒑𝒑𝒆

σ 𝑼𝒎𝒔𝒂𝒕𝒛 𝒑𝒓𝒐 𝑹𝒆𝒈𝒊𝒐𝒏 𝒑𝒓𝒐 𝑨𝒓𝒕𝒊𝒌𝒆𝒍

σ 𝑼𝒎𝒔𝒂𝒕𝒛 𝒑𝒓𝒐 𝑳𝒂𝒏𝒅 𝒑𝒓𝒐 𝑨𝒓𝒕𝒊𝒌𝒆𝒍

σ 𝑼𝒎𝒔𝒂𝒕𝒛 𝒑𝒓𝒐 𝑲𝒓𝒆𝒊𝒔 𝒑𝒓𝒐 𝑨𝒓𝒕𝒊𝒌𝒆𝒍

σ 𝑼𝒎𝒔𝒂𝒕𝒛 𝒑𝒓𝒐 𝑶𝒓𝒕 𝒑𝒓𝒐 𝑨𝒓𝒕𝒊𝒌𝒆𝒍MAV

MAV

MAV

119


• Parameter des create Befehles I/II:

• BUILD IMMEDIATE (direkt bei der Erstellung, default)

– Problematisch bei großen Basistabellen und im Rahmen von Entwicklung / Test

• BUILD DEFERRED (Erstellung beim ersten Refresh)

– Sinnvoll bei erster Überführung neuer MAV-Definitionen in die Produktionsumgebung

• ON PREBUILD

– Sinnvoll, wenn es separate Erstellungroutinen gibt, die ihr Ergebnis nur in einerTabelle ablegen können, man aber die Rewrite-Vorteile der MAVs nutzen will

– Kopie von normalen Views (analog zum vorigen Punkt)

MAV-Erstellung und erstmaliges Füllen

120


• Parameter des create Befehles II/II:

• Refresh wie:

• COMPLETE

– Immer vollständiges Neuladen aus den Basistabellen

• FAST (inkrementell)

– Nur bei vorhandenem MAV Log auf derBasistabelle

• FORCE (inkrementell oder komplett, default)

– Je nach der zu erwartenden Refresh-Dauer

Refresh-Funktionen

• NEVER

– Vorhalten historischer Beständeoder bei separater Prozedur

• Refresh wann :

• ON COMMIT (oft bei OLTP)

– Commit einer Transaktion auf derBasistabelle

• ON DEMAND (sinnvoll im DWH, default)

121


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;

122


Testen und Ablaufbedingungen für MAV

set autotrace on; -- Anzeige des Ausführungsplans

show parameter query

query_rewrite_enabled TRUE -- erlaubt das Query Rewrite

query_rewrite_integrity STALE_TOLERATED -- erlaubt Query Rewrite, auch wenn

-- die Daten in der Basistabelle

-- nicht mehr aktuell sind

query_rewrite_integrity TRUSTED -- auch deklarierte

-- Basis-Informantionen gelten

-- als korrekt (z. B. Views oder

-- prebuild)

query_rewrite_integrity ENFORCED -- Daten müssen stimmen

-- Ändern der Parameter mit

ALTER SESSION SET query_rewrite_enabled=TRUE;

ALTER SESSION SET query_rewrite_enabled=FALSE;

123


Nested Materialized Views

124


125

Vorteile des Konzepts

• Übersicht gewinnen

– Minimieren von Komplexität

– Verhindern von Mehrfachzugriffen

• Minimieren von physischen IO-Zugriffen

• Aufbau von hierarchisch organisierten Kennzahlensystemen D_ARTIKEL

SPARTE_NAMESPARTE_NRGRUPPE_NAMEGRUPPE_NRARTIKEL_NAMEARTIKEL_ID

F_UMSATZARTIKEL_IDZEIT_IDKUNDE_IDREGION_IDUMSATZMENGEBESTELL_DATUM

D_ZEITDATUM_DESCTAG_DES_MONATSWOCHE_DES_JAHRESJAHR_NUMMERQUARTALS_NUMMERMONATS_NUMMERMONAT_DESCDATUM_ID

Umsatz pro Artikelaggregiert auf Monatslevel

sum / count group by Monat / Artikel

sum / count group by Jahr / Artikelgruppe

Umsatz pro Artikelgruppeaggregiert auf Jahreslevel


Nested Materialized Views

CREATE MATERIALIZED VIEW MV_Umsatz_Monat


AS SELECT

z.jahr_nummer Jahr,

z.monat_desc Monat,


a.artikel_id ID,

a.gruppe_name artikelgruppe,

count(u.umsatz)

FROM

f_umsatz u,

d_artikel a,

d_zeit z

WHERE



GROUP BY

z.jahr_nummer,

z.monat_desc,a.artikel_id;

CREATE MATERIALIZED VIEW MV_Umsatz_Jahr


AS SELECT

Jahr,

Artikelgruppe,

sum(summe) Summe,

count(summe)

FROM

MV_Umsatz_Monat

GROUP BY jahr,ID, artikelgruppe;

2 Kennzahlen- Umsatz pro Monat- Umsatz pro Jahr

Bewusste Entscheidung für 2 getrennte Materialized Views Und gegen implizites Query Rewrite, um nach außen zu dokumentieren, dass es diese beiden Kennzahlen gibt

126


F_EINKAEUFE F_POSITION F_KAUF

Mv_EA_Finanz_Kum_Monat

Mav_Produkt_Monat_einkaeufe Mav_Produkt_Monat_Verkaeufe

Mav_Einkauf_Verkauf_Diff_Jahr Mv_EA_Menge_Kum_Monat

LFD_Bestands_Wert / Produkt / MonatLFD_Saldo / Produkt / MonatKumulierter EK / ProduktKumulierter VK / ProduktKumuliertes Saldo

LFD_Bestands_Menge / Produkt / MonatVK_Menge / Produkt / MonatEK_Menge / Produkt / MonatKumulierte EK Menge / ProduktKumulierte VK Menge / Produkt

Finanz-Sicht / Berechnungen

Bestands-/Lager-Sicht / Berechnungen

Jahres-Sicht

Mv_EA_Finanz_Kum_Gruppe_Monat

EA: Einkauf/VerkaufKum: kumuliert

Produktgruppen-Sicht

Level 1

Level 2

Level 3

Level 4Hierarchisierungvon Kennzahlen

127


Minimierung von Komplexität mit Nested Materialized Views

CREATE MATERIALIZED VIEW MV_Umsatz_Komplex


AS SELECT

a.artikel_name, sum(u.umsatz)

FROM

f_umsatz u, d_artikel a

WHERE

a.artikel_id = u.artikel_id

GROUP BY

a.artikel_name

HAVING sum(u.umsatz) --> kein Fast Refresh möglich

IN (SELECT max(u.umsatz)

FROM f_umsatz u, d_zeit z

WHERE u.zeit_id = z.datum_id AND

z.monat_desc = 'November' AND

z.jahr_nummer = '2006'

GROUP BY u.artikel_id);

“Liefere die Artikel mit dem größten Umsatz im November 2006”

128


Minimierung von Komplexität mit Nested Materialized Views

“Liefere die Artikel mit dem größten Umsatz im November 2006”

CREATE MATERIALIZED VIEW

MV_Umsatz_Komplex_SUB1


AS

SELECT a.artikel_name Artikel,

sum(u.umsatz)umsatz_summe,

count(u.umsatz), count(*)

FROM f_umsatz u, d_artikel a

WHERE a.artikel_id = u.artikel_id

GROUP BY a.artikel_name;


MV_Umsatz_Komplex_SUB2


AS

SELECT u.artikel_id,

max(u.umsatz) umsatz_max

FROM f_umsatz u, d_zeit z

WHERE u.zeit_id = z.datum_id AND

z.monat_desc = 'November' AND


GROUP BY u.artikel_id;

CREATE MATERIALIZED VIEW MV_Umsatz_KOMBINATION

REFRESH COMPLETE


AS

SELECT artikel, umsatz_summe FROM MV_Umsatz_Komplex_SUB1

WHERE umsatz_summe IN (SELECT umsatz_max FROM MV_Umsatz_Komplex_SUB2);

129


Steuern des Refreshvon Materialized Views

130


Automatische Aktualisierung DBMS_MVIEW (Refresh-Funktionen)

• Refresh-Funktionen

– DBMS_MVIEW.REFRESH()

– DBMS_MVIEW.REFRESH_DEPENDENT()

– DBMS_MVIEW.REFRESH_ALL_MVIEW()

• Transaktionsverhalten (optional)

• ATOMIC_REFRESH

• REFRESH_AFTER_ERRORS

• NESTED

• Refresh-Methoden (optional)

• COMPLETE (C)

• FAST (F)

• FORCE (default) (?)

• PARTITIONED(P)

Bsp.: EXECUTE DBMS_MVIEW.REFRESH('MV_STANDARD‘,'C');

JOIN

D_Zeit FAKT D_PROD

U Prod.A

Umsatz Prod. Gr und Jahr

SUM/Monat

SUM/Jahr

U Prod B

Bas

is-

Tab

elle

nA

ufe

inan

de

rA

ufb

aue

nd

eM

-Vie

ws

131


• ATOMIC_REFRESH => TRUE | FALSE

– Refresh vollzieht sich in einer Transaktion

– Im Fehlerfall wird die Transaktion zurückgerollt

• REFRESH_AFTER_ERRORS => TRUE | FALSE

– Refresh von mehreren Materialized Views läuft weiter bzw. bricht ab, wenn bei einer MAV einFehler aufgetreten ist

• NESTED

– Eine Materialized View und alle von ihr abhängigen MAVs werden aktualisiert

Automatische Aktualisierung DBMS_MVIEW (Refresh-Funktionen)

EXECUTE DBMS_MVIEW.REFRESH('MV_STANDARD‘,'C');

EXECUTE DBMS_MVIEW.REFRESH('MV_STANDARD',atomic_refresh=>TRUE);

EXECUTE DBMS_MVIEW.REFRESH('MV_STANDARD',atomic_refresh=>TRUE,

nested => TRUE);

EXECUTE DBMS_MVIEW.REFRESH('MV_STANDARD',nested=>TRUE);

132


• Refresh wird in separater Tabelle / Partition durchgeführt und nach Abschluss „geswitcht“

• Bessere Online-Verfügbarkeit

• Höhere Refresh-Performance

• Ist für alle Refresh-Varianten möglich• COMPLETE (C)

• FAST (F)

• FORCE (default) (?)

• PARTITIONED (P)

Out-of-place Refresh

DBMS_MVIEW.REFRESH(‘MV_MONATS_KALULATION', method => '?',atomic_refresh => FALSE, out_of_place => TRUE);

133


• WITH ROWID

• SEQUENCE

• INCLUDING NEW VALUES

Fast Refresh-Varianten

• Join Dependency Expression

• Partition Key

• Partition Marker

BasistabelleMAV Log

MAV1 MAV2 MAV3

Partition 1

Partition 4

Partition 5

Partition 2

Partition 3

Partition 6

MAV1

MAV2

Basistabelle

Aktualisierung über MAV Logs Aktualisierung über Partition Change Tracking (PCT)

komplett

inkrementell

134


• Der Partitioning Key der Basistabelle ist in dem SELECT- und eventuell in demGROUP BY-Teil, aber nicht in der WHERE-Klausel der MAV enthalten

• Führt zur Aggregierungauf der Ebene des Partitioning Keys

• Höhere Datenmenge alsohne PCT

PCT Refresh mit Partition Key


MV_Standard_PCT_Richtig

AS SELECT

u.bestell_datum,

z.jahr_nummer Jahr,

z.monat_desc Monat,


a.artikel_id ID,

count(u.umsatz)

FROM

f_umsatz_Par u,

d_artikel a,

d_zeit z

WHERE



GROUP BY

u.bestell_datum, z.jahr_nummer,

z.monat_desc, a.artikel_id;

SQL> SELECT count(*)

2 FROM MV_Standard_PCT_Richtig;

COUNT(*)

----------

41492

135


• Partitioning Key kommt in der Join Condition vor und eine Spalte der Basistabelle im SELECT-Teil der MAV

PCT Refresh Join Dependency Expression


MV_Standard_PCT_Richtig

AS SELECT

z.jahr_nummer Jahr,

z.monat_desc Monat,


a.artikel_id ID,

count(u.umsatz)

FROM

f_umsatz_Par u,

d_artikel a,

d_zeit z

WHERE

a.artikel_id = u.artikel_id and

u.bestell_datum = z.datum_desc

GROUP BY

z.jahr_nummer, z.monat_desc,

a.artikel_id;


MV_Standard_PCT_Falsch

AS SELECT

z.jahr_nummer Jahr,

z.monat_desc Monat,


a.artikel_id ID,

count(u.umsatz)

FROM

f_umsatz_Par u,

d_artikel a,

d_zeit z

WHERE



GROUP BY


a.artikel_id;

136


PCT Refresh mit Partition Marker

SQL> SELECT count(*) FROM

MV_Standard_PCT_Par_MARKER;

COUNT(*)

----------

2869

• Die Partitionmarker-Funktion liefert pro Partition einen Wert, der beliebige Level für die Aggregationen in der MAV erlaubt

CREATE MATERIALIZED VIEW MV_Standard_PCT_Par_MARKER

AS SELECT

dbms_mview.pmarker(u.rowid) AS pmark,

z.jahr_nummer Jahr,

z.monat_desc Monat,


a.artikel_id ID,

count(u.umsatz)

FROM

f_umsatz_Par u,

d_artikel a,

d_zeit z

WHERE


u.bestell_datum = z.datum_desc

GROUP BY

z.jahr_nummer,z.monat_desc,a.artikel_id,

dbms_mview.pmarker(u.rowid) ;

137


Fast Refresh während Online Redefinition

• Anforderung: Änderung der Struktur einer Basistabelle

• Herausforderung: Abhängige Materialized Views mussten bislang entkoppelt (Offline) und danach komplett neu aufgebaut werden

• Ab 12.2

– Online Redefinition der Basis-Tabelle

– Automatisches „Umhängen“ der abhängigen Materialized Views mit Beibehaltung der bestehenden Werte

– Gilt für Refresh-Verfahren mit Log-Tabellen

– REDEF_TABLE bzw. START_REDEF_TABLE Prozedur

– Für den Fortschritt der Operation gibt es ein Monitoring

138


Automatisches “Query Rewrite”

139


• Textvergleich der SELECT-Liste

– Reihenfolge spielt dabei keine Rolle

– Auflösung von möglichen Berechnungen

• Vergleich der Join-Bedingung

• Vergleich der GROUP BY-Klausel

Rewrite Prüfung – Abarbeitungsreihenfolge

140

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |DATA WAREHOUSEDATA WAREHOUSE

Beispiel-MAV für die folgenden AbfragenCREATE MATERIALIZED VIEW MV_UMS_ART_Zeit

REFRESH COMPLETE


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



GROUP BY


D_ARTIKELSPARTE_NAMESPARTE_NRGRUPPE_NAMEGRUPPE_NRARTIKEL_NAMEARTIKEL_ID



sum / count

141


• Umstellen der Spalten und avg() anstelle von sum()

Exaktes Text-Matching

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



GROUP BY


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



GROUP BY


a.artikel_id;




sum / count

142


Prinzip Aggregate RollupSELECT

z.jahr_nummer Jahr, --> Bezugsgröße in MAV ist Monat


a.artikel_id ID,

count(u.umsatz)

FROM

f_umsatz u,

d_artikel a,

d_zeit z

WHERE



GROUP BY

z.jahr_nummer, a.artikel_id;

• Abfragen lässt sich alles, was in der GROUP BY-Klausel der MAV zu finden istD_ARTIKELSPARTE_NAMESPARTE_NRGRUPPE_NAMEGRUPPE_NRARTIKEL_NAMEARTIKEL_ID



sum / count

143


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



GROUP BY

z.jahr_nummer, z.monat_desc, a.artikel_Name;

Ist nicht in der MAV-Definitionenthalten

• Join Back-Tabelle muss einen Primary Key nutzenD_ARTIKELSPARTE_NAMESPARTE_NRGRUPPE_NAMEGRUPPE_NRARTIKEL_NAMEARTIKEL_ID



sum / count

144


Ausführungsplan Join Back-Methode

--------------------------------------------------------------------------------------------------


--------------------------------------------------------------------------------------------------


| 1 | HASH GROUP BY | | 65 | 5785 | 15 (14)| 00:00:01 |

|* 2 | HASH JOIN | | 6363 | 553K| 14 (8)| 00:00:01 |

| 3 | TABLE ACCESS FULL | D_ARTIKEL | 65 | 2860 | 3 (0)| 00:00:01 |

| 4 | MAT_VIEW REWRITE ACCESS FULL| MV_UMS_ART_ZEIT | 6363 | 279K| 10 (0)| 00:00:01 |

--------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------


----------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 3511 | 246K| 172 (5)| 00:00:03 |

| 1 | HASH GROUP BY | | 3511 | 246K| 172 (5)| 00:00:03 |

|* 2 | HASH JOIN | | 100K| 7031K| 168 (3)| 00:00:03 |

| 3 | TABLE ACCESS FULL | D_ZEIT | 3074 | 55332 | 8 (0)| 00:00:01 |

|* 4 | HASH JOIN | | 100K| 5273K| 159 (2)| 00:00:02 |


| 6 | TABLE ACCESS FULL| F_UMSATZ | 100K| 976K| 155 (2)| 00:00:02 |

----------------------------------------------------------------------------------

Ohne Join Back

Mit Join Back

145


Einfache Join-Bedingungen in MAVs Grundlage fürflexiblere Abfragen

CREATE MATERIALIZED VIEW MV_UMS_ART_Zeit_Join

REFRESH COMPLETE


AS SELECT

z.jahr_nummer Jahr,

z.monat_desc Monat,

a.artikel_id ID,

u.umsatz Umsatz

FROM

f_umsatz u,

d_artikel a,

d_zeit z

WHERE


u.zeit_id = z.datum_id;

Einfache Join-Bedingung

SELECT

z.jahr_nummer Jahr,

z.monat_desc Monat,

sum(u.umsatz) Summe

FROM

f_umsatz u,

d_artikel a,

d_zeit z

WHERE


u.zeit_id = z.datum_id AND


GROUP BY

z.jahr_nummer, z.monat_desc;

146


Materialized Views – technisch gesehen

• Kennzahlen nur als Materialized Views

• Automatisches Refresh anstatt ETL

• Hohe Verarbeitungsperformance

• Wegfall von ETL

• Wegfall von 1:1 Datenbewegungen

• Verwenden von SQL bzw. Analytische Funktionen

• Einbetten von R-Skripten

147


Zugriffspfade planen

Sprechende Name Übersichtliche Darstellung

DD

D D

MAV MAV

MAVMAV

MAV

MAV

MAV

MAV

MAVMAV

MAVMAV

• Abdecken von allen benötigten Join-Optionen

• Immer nur zwischen den untersten Levelneiner Dimension und der Fakten-Tabellen

F

148


Automatisches “Query Rewrite” mitMaterialized Views

149


• Textvergleich der SELECT-Liste

– Reihenfolge spielt dabei keine Rolle

– Auflösung von möglichen Berechnungen

• Vergleich der Join-Bedingung

• Vergleich der GROUP BY-Klausel

Rewrite Prüfung – Abarbeitungsreihenfolge

150


Beispiel-MAV für die folgenden AbfragenCREATE MATERIALIZED VIEW MV_UMS_ART_Zeit

REFRESH COMPLETE


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



GROUP BY





sum / count

151


• Umstellen der Spalten und avg() anstelle von sum()

Exaktes Text-Matching

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



GROUP BY


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



GROUP BY


a.artikel_id;




sum / count

152


Prinzip Aggregate RollupSELECT

z.jahr_nummer Jahr, --> Bezugsgröße in MAV ist Monat


a.artikel_id ID,

count(u.umsatz)

FROM

f_umsatz u,

d_artikel a,

d_zeit z

WHERE



GROUP BY

z.jahr_nummer, a.artikel_id;

• Abfragen lässt sich alles, was in der GROUP BY-Klausel der MAV zu finden istD_ARTIKELSPARTE_NAMESPARTE_NRGRUPPE_NAMEGRUPPE_NRARTIKEL_NAMEARTIKEL_ID



sum / count

153


Join Back-Methode

SELECT

z.jahr_nummer Jahr,

z.monat_desc Monat,


sum(u.umsatz) Summe

FROM

f_umsatz u,

d_artikel a,

d_zeit z

WHERE



GROUP BY

z.jahr_nummer, z.monat_desc, a.artikel_Name;

Ist nicht in der MAV-Definitionenthalten

• Join Back-Tabelle muss einen Primary Key nutzenD_ARTIKELSPARTE_NAMESPARTE_NRGRUPPE_NAMEGRUPPE_NRARTIKEL_NAMEARTIKEL_ID



sum / count

154


Ausführungsplan Join Back-Methode

--------------------------------------------------------------------------------------------------


--------------------------------------------------------------------------------------------------


| 1 | HASH GROUP BY | | 65 | 5785 | 15 (14)| 00:00:01 |

|* 2 | HASH JOIN | | 6363 | 553K| 14 (8)| 00:00:01 |

| 3 | TABLE ACCESS FULL | D_ARTIKEL | 65 | 2860 | 3 (0)| 00:00:01 |

| 4 | MAT_VIEW REWRITE ACCESS FULL| MV_UMS_ART_ZEIT | 6363 | 279K| 10 (0)| 00:00:01 |

--------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------


----------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 3511 | 246K| 172 (5)| 00:00:03 |

| 1 | HASH GROUP BY | | 3511 | 246K| 172 (5)| 00:00:03 |

|* 2 | HASH JOIN | | 100K| 7031K| 168 (3)| 00:00:03 |

| 3 | TABLE ACCESS FULL | D_ZEIT | 3074 | 55332 | 8 (0)| 00:00:01 |

|* 4 | HASH JOIN | | 100K| 5273K| 159 (2)| 00:00:02 |



----------------------------------------------------------------------------------

Ohne Join Back

Mit Join Back

155


Einfache Join-Bedingungen in MAVs Grundlage fürflexiblere Abfragen


REFRESH COMPLETE


AS SELECT

z.jahr_nummer Jahr,

z.monat_desc Monat,

a.artikel_id ID,

u.umsatz Umsatz

FROM

f_umsatz u,

d_artikel a,

d_zeit z

WHERE



Einfache Join-Bedingung

SELECT

z.jahr_nummer Jahr,

z.monat_desc Monat,

sum(u.umsatz) Summe

FROM

f_umsatz u,

d_artikel a,

d_zeit z

WHERE


u.zeit_id = z.datum_id AND


GROUP BY

z.jahr_nummer, z.monat_desc;

156


Materialized Views und Hierarchisierung von Dimensionen

157


• Abfragen über alle Spalten der Dimensionstabelle

• Eine Definition für Dimensionen festlegen

Dimensionale Tabelle als Optimizer-Hilfe

CREATE DIMENSION d_artikel

LEVEL artikel IS d_artikel.artikel_id

LEVEL gruppe IS d_artikel.gruppe_nr

LEVEL sparte IS d_artikel.sparte_nr

HIERARCHY h_art

(artikel CHILD OF gruppe CHILD OF

sparte)

ATTRIBUTE att_artikel LEVEL artikel

DETERMINES d_artikel.artikel_name

ATTRIBUTE att_gruppe LEVEL gruppe

DETERMINES d_artikel.gruppe_name

ATTRIBUTE att_sparte LEVEL sparte

DETERMINES d_artikel.sparte_name;

CREATE TABLE d_artikel

(

dimension_key NUMBER(3) NOT NULL,

nummer NUMBER(8),

artikel_name VARCHAR2(50),

artikel_nummer NUMBER(3),

gruppe_nr NUMBER(3),

gruppe_name VARCHAR2(50),

sparte_name VARCHAR2(50),

sparte_nr NUMBER(3));




sum / count

158



SELECT a.sparte_name Sparte,

sum(u.umsatz) Summe

FROM


WHERE


GROUP BY

a.sparte_name;

CREATE MATERIALIZED VIEW MV_UMS_ART_Dim

REFRESH COMPLETE


AS SELECT

a.artikel_id ID,

sum(u.umsatz) Umsatz

FROM


WHERE


GROUP BY

a.artikel_id;

Definition auf Artikelebene Abfrage auf Spartenebene




sum / count

159



--------------------------------------------------------------------------------------------------


--------------------------------------------------------------------------------------------------


| 1 | HASH GROUP BY | | 1 | 48 | 7 (29)| 00:00:01 |

| 2 | MERGE JOIN | | 63 | 3024 | 6 (17)| 00:00:01 |

| 3 | TABLE ACCESS BY INDEX ROWID | D_ARTIKEL | 65 | 1430 | 2 (0)| 00:00:01 |

| 4 | INDEX FULL SCAN | PK_ART_ID | 65 | | 1 (0)| 00:00:01 |

|* 5 | SORT JOIN | | 63 | 1638 | 4 (25)| 00:00:01 |

| 6 | MAT_VIEW REWRITE ACCESS FULL| MV_UMS_ART_DIM | 63 | 1638 | 3 (0)| 00:00:01 |

--------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------


---------------------------------------------------------------------------------


| 1 | HASH GROUP BY | | 1 | 28 | 163 (5)| 00:00:02 |

|* 2 | HASH JOIN | | 100K| 2734K| 158 (2)| 00:00:02 |



---------------------------------------------------------------------------------

Ohne Rewrite auf Basis einer dimensionalen Tabelle

Mit Rewrite auf Basis einer dimensionalen Tabelle

160


Prüfen der Stimmigkeit einer Dimension

ARTIKEL_NAMEARTIKEL_ID

GRUPPE_NAMEGRUPPE_NR

SPARTE_NAMESPARTE_NR

1 : n-Beziehung

1 : n-Beziehung

funktionaleAbhängigkeit

HIERARCHY-Klausel ATTRIBUTE-Klausel



161


Prüfen der Stimmigkeit einer Dimension

SQL> desc dimension_exceptions

Name

-------------------------------

STATEMENT_ID

OWNER

TABLE_NAME

DIMENSION_NAME

RELATIONSHIP

BAD_ROWID

\ora-home\RDBMS\ADMIN\utldim.sql Legt Tabelle DIMENSION_EXCEPTIONS an

-- Prüfen der Dimension mit:

variable stmt_id varchar2(30);

execute :stmt_id := 'CUST_DIM_VAL';

execute dbms_dimension.validate_dimension ('MAV.D_ARTIKEL',FALSE,TRUE,:stmt_id );

-- Fehlermeldungen abfragen mit:

SELECT distinct owner, table_name, dimension_name, relationship

FROM dimension_exceptions

WHERE statement_id = :stmt_id;

DBMS_OLAP.VALIDATE_DIMENSION

162


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

163


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');

• Zeigt auf, welche Funktionen für die jeweilige MAV genutzt werden kann

EXPLAIN_MVIEW-Routine

164


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

165


@D:\app\aths\product\11.1.0\db_1\RDBMS\ADMIN\utlxrw.sql

EXPLAIN_REWRITE-Routine

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)

Angabe der Bedingungen für Query Rewrite

166


EXPLAIN_REWRITE-Routine


REFRESH COMPLETE


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



begin

dbms_mview.explain_rewrite('

SELECT

z.jahr_nummer Jahr,

z.monat_desc Monat,


a.artikel_id ID

FROM

f_umsatz u,

d_artikel a,

d_zeit z

WHERE



GROUP BY


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


QSM-01082: Materialized View, MV_UMS_ART_ZEIT_JOIN, kann nicht mit Tabelle, F_UMSATZ,

verknpft werden


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

167


SQL-Erweiterungen- With-Klausel, LISTAGG, Fetch n rows- Analytische SQL-Funktionen- Statistische Funktionen

168


With-Klausel

169

select s.Artikelgruppe,s.Jahr,s.Monat,s.monatlicher_umsatz

from (select

a.gruppe_name Artikelgruppe,

z.jahr_nummer Jahr,

z.monat_desc Monat,

sum(u.umsatz) monatlicher_umsatz

from d_artikel a, f_umsatz u, d_zeit z

where

u.zeit_id = z.Zeit_id and

u.artikel_id = a.artikel_id

group by a.gruppe_name,z.jahr_nummer,z.monat_desc) s

where s.monatlicher_umsatz

in (select max(v.monatlicher_umsatz)

from

(select


z.jahr_nummer Jahr,

z.monat_desc Monat,



where



group by a.gruppe_name,z.jahr_nummer,z.monat_desc) v

group by v.Jahr,v.Monat);

- Liefere für jede Produktgruppe den besten Verkaufsmonat

Mehrfacher Aufruf

• Diese Schreibweise

– ist unübersichtlich weil mehrfach geschachtelt und

– Enthält Mehrfachaufrufe von denselben Tabellen

• Schlechte Performance

> 300 Sekunden Laufzeit auf Laptop mit 50 Millionen Sätze in F_UMSATZ


With-Klausel

170

WITH Produkt_verkauf_pro_Monat

AS

(

select


z.jahr_nummer Jahr,

z.monat_desc Monat,



where



group by a.gruppe_name,z.jahr_nummer,z.monat_desc

)

select s.Artikelgruppe,s.Jahr,s.Monat,s.monatlicher_umsatz

from Produkt_verkauf_pro_Monat s

where

s.monatlicher_umsatz

IN (select MAX(v.monatlicher_umsatz)

from Produkt_verkauf_pro_Monat v

group by v.jahr,v.monat);

- Liefere für jeder Produktgruppe den besten Verkaufsmonat

Grundlegendes Select. Nurin diesem Select wird physikalisch gelesen.

Alle weiteren Selects bedienen sichaus dem Ergebnis-Set des grundlegendenSelects

15 Sekunden Laufzeit auf Laptop mit 50 Millionen Sätze in F_UMSATZ


FETCH FIRST n ROWS

171

SELECT * FROM

(SELECT

Artikel_Name as Artikel,

sum(U.umsatz) AS Umsatz,

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 Rangfolge < 11; SELECT




from



group by a.artikel_name

FETCH FIRST 10 ROWS ONLY;


172

LISTAGG – Formatieren eines überlangen Outputs

SELECT

g.country_region,

LISTAGG(c.cust_first_name||' '||c.cust_last_name, ',' ON OVERFLOW TRUNCATE '...' WITH COUNT)

WITHIN GROUP (ORDER BY c.country_id) AS Customer

FROM customers c, countries g

WHERE g.country_id = c.country_id

GROUP BY country_region

ORDER BY country_region;

…


Analytische Funktionen

• Einsatz bei dem Berechnen von standardisierten Kennzahlen in der Datenbank

– Kennzahlensysteme

– Erstellen von Standardberichten in der Datenbank

• Ideal in dem Zusammenspiel mit Materialized Views

• Lösung könnte auch mit reinem SQL erfolgen aber

– Analytische Funktionen machen die Abfrage schlanker

– Sie sind in der Regel schneller, weil man Mehrfachlesen von Tabellen verhindert

– Sie liefern mehr Flexibilität weil mit Gruppierungen gezielter umgegangen werden kann

173


Gruppierungen auf unterschiedlichen LevelnOver Partition By

• Allgemeines Format

Beispiel:Select artikel_name,gruppe_name,umsatz, Monat_Desc,

avg(wert) over (partition by GRUPPE_NAME ORDER BY MONATS_NUMMER range interval ‘3' MONTH preceding ) GRW from D_Artikel a,f_umsatz u, d_zeit zwhere

Function(arg1,..., argn) OVER ( [PARTITION BY <...>] [ORDER BY <....>] [<window_clause>] )

D_ARTIKELARTIKEL_NAMEGRUPPE_NR GRUPPE_NAME SPARTE_NAME SPARTE_NR ARTIKEL_ID

F_UMSATZARTIKEL_IDKUNDEN_IDZEIT_IDREGION_IDKANAL_IDUMSATZMENGE

Artikelgruppe

Artikel

Artikelsparte

Menge Sortierung Fensterausschnitt


174


Prinzip der Wirkungsweise von Analytischen Funktionen:

175

Select Feld1, Feld2,Analytische Funktion

FromTabellen-Name

Where Bed1 Group by feld1,feld2;

Zusätzliche Möglichkeiten der Bearbeitung nachdem eine Datenmenge bereits gelesen ist und jetzt angeliefert wird

IO-relevant undteuer

Rechen-relevant undschnell im Hauptspeicher

Einmal ein Daten-Set lesen und dieses Daten-Set immer wieder analysieren


Prinzip:Aggregierte Sichten entlangvon Dimensionshierarchien

176


F_UMSATZARTIKEL_IDKUNDEN_IDZEIT_IDREGION_IDKANAL_IDUMSATZMENGEUMSATZ_GESAMT

Umsatz pro Artikel

Select

sum(u.umsatz) umsatz_pro_Artikel,

a.artikel_name

from D_ARTIKEL a,F_UMSATZ_2015 u

where a.artikel_id = u.artikel_id

group by a.artikel_name;

Umsatz pro Artikel und Anzeige der zugehörigen ArtikelgruppeSelect


a.artikel_name,

a.gruppe_name



group by a.artikel_name;

ORA-00979: Kein GROUP BY-Ausdruck00979. 00000 -"not a GROUP BY expression"

Select


a.artikel_name,

a.gruppe_name



group by a.gruppe_name,a.artikel_name;

Group By muss ergänzt werden



177



Umsatz pro Artikel_Gruppe

Select

sum(u.umsatz) umsatz_pro_Gruppe,

a.gruppe_name



group by a.gruppe_name;

Jetzt mit analytischen Funktionen

Select gruppe_name,

sum(umsatz) over (partition by gruppe_name)


where a.artikel_id = u.artikel_id ;

Der Output liefert zwar die Summe pro Artikel-Gruppe allerdings wird allesdargestellt , was hinter der FROM-Klauselentsteht.



178



Umsatz pro Artikel_Gruppe

Select

sum(u.umsatz) umsatz_pro_Gruppe,

a.gruppe_name



group by a.gruppe_name;

Mit analytischen Funktionen(Distinct)

Select

distinct gruppe_name,

sum(umsatz) over (partition by gruppe_name)


where a.artikel_id = u.artikel_id ;


Abfrage über mehrere Hierarchie-Level ohne Mehrfachlesen



PK

FK

FK

FK

FK

FK

Wieviel Prozent machen der Gesamtumsatzes pro Artikel an dem Gesamtumsatz der zugehörigen Gruppe aus?

Gesamtumsatz Einzelartikel im Vergleich zu durchschnittlichem Artikelumsatz pro Gruppe

Artikelgruppe

Artikel

Artikelsparte

Aufgabenstellung

179


180

select a.artikel,a.gruppe,a.umsatz_pro_artikel,b.gruppe,b.umsatz_pro_gruppe,

round((a.umsatz_pro_artikel/b.umsatz_pro_gruppe*100),0) Prozent

from

(SELECT a.artikel_name Artikel,

a.gruppe_name Gruppe,

sum(u.umsatz) Umsatz_pro_Artikel

FROM

f_Umsatz_2015 U,

D_artikel a

WHERE

U.artikel_id = a.artikel_id

group by a.gruppe_name,a.artikel_name) A

,

(SELECT a.gruppe_name gruppe,

sum(u.umsatz) umsatz_pro_Gruppe

FROM

f_Umsatz_2015 U,

D_artikel a

WHERE


group by a.gruppe_name) B

where a.gruppe = b.gruppe;

Variante 1 ohne analytische Funktion

Doppeltes Lesen der 50 Millionen-Tabelle


Variante 2 mit analytischen

Funktionen

181

select artikel,umsatz_pro_Artikel,Gruppe,umsatz_pro_gruppe,

round((umsatz_pro_Artikel/umsatz_pro_gruppe*100),2) Prozent

from

(SELECT


a.GRUPPE_NAME Gruppe,


sum(sum(u.umsatz)) OVER (PARTITION BY a.GRUPPE_NAME) umsatz_pro_Gruppe

FROM f_Umsatz U, D_artikel a


group by a.GRUPPE_NAME, a.artikel_name

);

Lesen der 50 Millionen-Tabelle erfolgt nur einmal


Das gleiche Beispiel mit mehreren analytischen Funktionen

182

select artikel,umsatz_pro_Artikel,Gruppe,umsatz_pro_gruppe,Schnitt_pro_Gruppe,

round((umsatz_pro_Artikel/umsatz_pro_gruppe*100),2) Prozent

from

(SELECT


a.GRUPPE_NAME Gruppe,


sum(sum(u.umsatz)) OVER (PARTITION BY a.GRUPPE_NAME) umsatz_pro_Gruppe,

round(avg(sum(u.umsatz)) OVER (PARTITION BY a.GRUPPE_NAME),0) Schnitt_pro_Gruppe

FROM f_Umsatz U, D_artikel a


group by a.GRUPPE_NAME, a.artikel_name

);Lesen der 50 Millionen-Tabelle erfolgt nur einmal, obwohl neben dem prozentzualen Summenanteil auch der Durchschnitts-Artikelumsatzpro Gruppe berechnet wird


Variante 2 – ausführliches BeispielViele Kennzahlen – aber nur einmal lesen

select * from (SELECT

a.artikel_name Artikel, a.GRUPPE_NAME Gruppe,sum(u.umsatz) umsatz_pro_Artikel,sum(sum(u.umsatz)) OVER (PARTITION BY a.GRUPPE_NAME) Gesamt,rank() over (PARTITION BY a.GRUPPE_NAME order by a.artikel_name ) lfd_nr,count(sum(u.umsatz)) OVER (PARTITION BY a.GRUPPE_NAME) Anz_Art_pro_Gruppe,round(avg(sum(u.umsatz)) OVER (PARTITION BY a.GRUPPE_NAME),2) Schnitt_pro_Gruppe,sum(sum(u.umsatz)) OVER (PARTITION BY a.GRUPPE_NAME ORDER BY a.artikel_name) Kumuliert,round(((sum(u.umsatz))/(sum(sum(u.umsatz)) OVER (PARTITION BY a.GRUPPE_NAME))*100),2) Prozent

FROM f_Umsatz_2014 U, D_artikel aWHERE U.artikel_id = a.artikel_idgroup by a.GRUPPE_NAME, a.artikel_name

) where lfd_nr < 4

Liefert nach Gruppe gruppierte Artikel-Aggregationen

Gesamtsumme pro Artikel

Gesamtsumme pro Artikel_Gruppe

Aufsteigende Artikelsummenposition pro Artikel_Gruppe

Anzahl Artikelsummen pro Gruppe

Durchschnittliche Anzahlsummeinnerhalb einer Artikelgruppe

Kumulierte Artikelsummenpro Gruppe

Prozentanteil Artikelsumme an Gesamtgruppenwert

183


Year-To-Date Analysen - Auflistung von Umsatz pro Monat- Kumulierung der Monatsumsätze von Jahresbeginn an

select z.Jahr_nummer Jahr,z.MONAT_DESC Monat,sum(u.umsatz) Umsatz,sum(sum(u.umsatz)) over (PARTITION by z.Jahr_nummer order by z.MONATS_NUMMER) year_to_date

from f_umsatz_2014 u,d_zeit z

wherez.zeit_id = u.zeit_id

group by z.Jahr_nummer,z.MONATS_NUMMER,z.MONAT_DESC;



184


Ranglisten erstellen Innerhalb einer Gruppe werden Werte nach Rang sortiertIn diesem Beispiel wird der Umsatz pro Quartal berechnet und danach das umsatzstärkste Quartal als erstes gelistet.

select * from

(select sum(u.umsatz) Umsatz,

z.Jahr_nummer Jahr

,z.Quartals_nummer "Top-Quartal",

RANK() OVER (PARTITION by z.Jahr_nummer ORDER BY sum(U.umsatz) DESC ) AS Rangfolge

from

f_umsatz u, d_zeit z

where

z.zeit_id = u.zeit_id

group by z.Jahr_nummer,z.Quartals_nummer)

order by Jahr;



185


Ranglisten: Top Quartale Das gleiche Beispiel wie zuvor, jetzt wird jedoch nur das Top-Quartal ausgegeben

select * from

(select sum(u.umsatz) Umsatz,

z.Jahr_nummer Jahr

,z.Quartals_nummer "Top-Quartal"

,RANK() OVER (PARTITION by z.Jahr_nummer ORDER BY sum(U.umsatz) DESC ) AS Rangfolge

from f_umsatz u, d_zeit z

where


group by z.Jahr_nummer,z.Quartals_nummer)

where Rangfolge = 1

order by Jahr;



186


Ranking ohne PartitionSELECT * FROM

(SELECT




from

F_umsatz U,

D_Artikel A



WHERE Rangfolge < 11; Rangfolge-Feldwird mitgeliefert.Es wäre auch rownum möglich



PK

FK

FK

FK

FK

FK

Die 10 umsatzstärksten Artikel

187


Ranking ohne PartitionFETCH FIRST….SELECT




from

F_umsatz U,

D_Artikel A






PK

FK

FK

FK

FK

FK

Die 10 umsatzstärksten Artikel. Das gleiche Beispiel wievorher, nur jetzt einfacher mit Hilfe von FETCH FIRST 11 ROWS ONLY. Der Output ist gleich.

select * from(SELECT *

FROM (SELECT

Artikel_Name as Artikel, sum(U.umsatz) AS Umsatz

from F_umsatz U, D_Artikel A


group by a.artikel_name)order by Umsatz desc)

where rownum < 11 ;

Alternative ohne analytische Funktion

188


Rank / Densrank• RANK

– Plätze werden aufsteigend vergeben

– Bei 2 gleichen Position bleibt der darauf folgende frei

• 1 2 3 3 5 6 7 8 8 10

• DENSRANK

– Plätze werden aufsteigend vergeben

– Bei 2 gleichen Position wird die darauf folgende Position belegt

• 1 2 3 3 4 5 6 7 8 8 9

SELECT

R.land as Land,



from

F_umsatz U, D_REGION R

WHERE U.REGION_ID = r.region_id

group by r.land


Die 5 umsatzstärksten Bundesländer

D_REGIONREGION_IDORTNRORTKREISNRKREIS LANDNRLANDREGIONNR REGION


189




PKFK

FK

FK

FK

FK

SELECT * FROM

(SELECT artikel_name Artikel,

gruppe_name Prod_Grp,

sum(U.Umsatz) AS Umsatz,

RANK() OVER (PARTITION by a.gruppe_name ORDER BY sum(U.umsatz) DESC ) AS Rangfolge

FROM f_umsatz U, d_artikel A


GROUP by a.gruppe_name,a.artikel_name

ORDER by a.gruppe_name)

WHERE Rangfolge < 4;

Gruppierungen auf unterschiedlichen Leveln und Ranking auf Level-EbeneRank … Partition By

- Sortierung der Umsätze nach Top 3 Artikel pro Artikelgruppe

-Bilden der Rangfolge innerhalb einer Gruppe

Lässt man das äußere SELECT weg, erhält man alle Artikel pro Gruppe nach Umsatz sortiert

190


(Zeit-) Reihenvergleiche



LAG()

select

z.Jahr_nummer Jahr,

z.MONAT_DESC Monat,

z.MONATS_NUMMER,

sum(u.umsatz) Umsatz,

LAG(sum(u.umsatz), 12) OVER (ORDER BY z.Jahr_Nummer, z.MONATS_NUMMER) Vorjahresmonat

from f_umsatz u, d_zeit z

Where z.zeit_id = u.zeit_id

group by

z.Jahr_nummer,z.MONATS_NUMMER,z.MONAT_DESC

order by z.Jahr_nummer,z.MONATS_NUMMER;

- Sortierung der Umsätze nach Monaten- Anzeigen des Vorjahresmonats

191


Vergleich / Steigerung zum Vormonat

select

z.Jahr_nummer Jahr,

z.MONAT_DESC Monat,

sum(u.umsatz) Umsatz,

LAG(sum(u.umsatz)) OVER (ORDER BY z.MONATS_NUMMER) Vormonat,

round(((sum(u.umsatz))/ NVL((LAG(sum(u.umsatz)) OVER (ORDER BY z.MONATS_NUMMER)),NULL)),2) Steigerung,

sum(sum(u.umsatz)) over (PARTITION by z.Jahr_nummer order by z.MONATS_NUMMER) year_to_date

from

f_umsatz_2015 u, d_zeit z

where


group by

z.Jahr_nummer,

z.MONATS_NUMMER,

z.MONAT_DESC;

- Sortierung der Umsätze nach Monaten- Anzeigen des Vormonats- Steigerung in Prozent zum Vormonat- Year-To-Date pro Monat


F_UMSATZ

ARTIKEL_IDKUNDEN_IDZEIT_IDREGION_IDKANAL_IDUMSATZMENGEUMSATZ

LAG()

192


Quartalsvergleiche

select

z.Jahr_nummer Jahr,

z.Quartals_Nummer Quartal,

sum(u.umsatz) Umsatz_Quartal,

lag(sum(u.umsatz)) over (ORDER BY z.Quartals_nummer) Vor_Quartal,

round((sum(u.umsatz))/(lag(sum(u.umsatz)) over (ORDER BY z.Quartals_nummer)),2) Steigerung

from


where


group by

z.Jahr_nummer,

z.Quartals_nummer;

- Das Jahr 2015 sortiert nach Quartalen- Anzeigen des Vorquartals- Steigerung in Prozent zum Vorquartal


F_UMSATZ


LAG()

193


Quartalsübersichten

select

z.Jahr_nummer Jahr,

z.Quartals_Nummer Quartal,

sum(u.umsatz) Umsatz_Quartal,

RANK() OVER (ORDER BY sum(U.umsatz) DESC ) AS Rangfolge,

sum(sum(u.umsatz)) over (PARTITION by z.Jahr_nummer ) Jahres_Umsatz,

round(sum(u.umsatz)/( sum(sum(u.umsatz)) over (PARTITION by z.Jahr_nummer ) ) * 100,2) Prozentualer_Jahresanteil,

lag(sum(u.umsatz)) over (ORDER BY z.Quartals_nummer) Vor_Quartal,

round((sum(u.umsatz))/(lag(sum(u.umsatz)) over (ORDER BY z.Quartals_nummer)),2) Steigerung

from


where


group by

z.Jahr_nummer,

z.Quartals_nummer;

- Sortierung nach Umsatzstärke der Quartale- Anteil eines Quartals am Jahresumsatz- Vorquartal- Steigerung zum Vorquartal


F_UMSATZ


LAG()

194


Der n-ten-Anteil von etwas

195

NTILE(n)

select artikel, umsatz from

(SELECT



ntile(10) OVER (ORDER BY sum(U.umsatz) DESC ) AS N_ter_Anteil

from

F_umsatz U,

D_Artikel A



where N_ter_Anteil = 10;

- Welche Artikel gehören zu dem letzten 10tel Umsatz pro Jahr


Position/Ranking innerhalb einer Gruppe

196

CUME_DIST() PERCENT_RANK()

- Wieviel Prozent einer Gesamtmenge betragen weniger als der aktuelle Wert

SELECT a.artikel_name as Artikel,

a.gruppe_Name as Gruppe,


round(CUME_DIST() OVER (PARTITION BY a.gruppe_Name order by sum(U.umsatz)),2) as Kumulierte_Position,

round(PERCENT_RANK() OVER (PARTITION BY a.gruppe_Name order by sum(U.umsatz)),2) as Prozentrang

from

F_umsatz_2015 U, D_Artikel A

WHERE


group by a.gruppe_Name,A.ARTIKEL_NAME;

KUMULIERTE_POSITION43% der Artikel tragen zu weniger Umsatz bei als dieser aktuelleArtikel „Toster_modern_standard“.

PROZENTRANGDieser Artikel hat die Position 38 von100 aller Produkte


Histogramme über Anzahl proUmsatzranges

197

select WIDTH_BUCKET, min(Umsatz), max(Umsatz), count(*)

from

(SELECT a.artikel_id,

sum(U.Umsatz) AS Umsatz,

WIDTH_BUCKET(sum(U.Umsatz), 0, 50000000, 12) as WIDTH_BUCKET

FROM f_umsatz_2015 U, d_artikel A


GROUP by a.artikel_id)

GROUP BY WIDTH_BUCKET ;

- Wieviele x Verkäufe pro n Wertebereich gibt es

WIDTH_BUCKET()


Anteile einer Gesamtliste

198

with gruppenliste as (

SELECT a.gruppe_name as Artikelgruppe ,

sum(U.Umsatz) AS Umsatz

FROM f_umsatz_2015 U, d_artikel A


GROUP by a.gruppe_name)

select Artikelgruppe, Umsatz,

round(ratio_to_report(umsatz) over(),2)*100

Prozentanteil

from gruppenliste

;

- Wieviele Prozentanteile hat eine Einzelpositionzu einer Gesamtsumme

RATIO_TO_REPORT()


Übersicht zu den Windowing-Möglichkeiten

• Mit Window-Aggregation-Funktionen können Funktionen relativ zu einer aktuellen Zeile berechnet werden

• Unterscheidung

– „Physical Window“: Zählen von absoluten Records

– „Logical Window“: logische Einheiten wie Zeiten

• Möglich mit folgenden Funktionen– Sum()

– Avg()

– Max()

– Min()

– Count()

199

Records⇨ rows between 1 preceding and n following

Numerische Felder:⇨ range between 1000 preceding and n following

Datumsfelder⇨ range between 30 preceding and 10 following⇨ range between interval ‘1’ MONTH preceding

and interval ‘2’ YEAR following

Selbst erstellte Funktionen⇨ range between myFunc(x) preceding

and myFunc2(x) following

Die Steuerung der Fenstergröße ist möglich über

– Sttdev()

– Variance()

– First_Value()

– Last_Value()


Physical Window

200

with Umsatz_pro_Monat as (

Select z.jahr_nummer,a.gruppe_name, z.Monat_Desc,z.monats_nummer,

sum(u.umsatz) as umsatz

from D_Artikel a,f_umsatz_2015 u, d_zeit z

where

a.Artikel_id = u.artikel_ID and


Group by

z.jahr_nummer,

z.Monat_Desc,

z.monats_nummer,

a.gruppe_name

order by a.gruppe_name,z.monats_nummer)

select GRUPPE_NAME, Jahr_nummer,MONAT_DESC,monats_nummer, umsatz,

avg(umsatz) over (partition by GRUPPE_NAME

ORDER BY monats_nummer rows between 3 preceding and 1 preceding ) GRW

from Umsatz_pro_Monat;

- Durchschnittliche Umsatz der beiden Vormonatepro Artikelgruppe


Logical Window

201

select z.ZEIT_ID,

sum(u.umsatz) as Umsatz,

sum(sum(u.umsatz)) over (ORDER BY z.Zeit_id

RANGE BETWEEN INTERVAL '2' DAY PRECEDING and

INTERVAL '2' DAY FOLLOWING) as Fuenf_Tage_Umsatz

from f_umsatz_2015 u, d_zeit z

where


group by z.zeit_id;

- 5-Tages-Umsatz vom aktuelle Tag + 2 Tage davor und 2 Tage danach

currentLogicalWindow


Summenzeilen ausgebenGROUP BY ROLLUP / CUBE

• ROLLUP

– Summenzeilen entsprechendder Felder unter GROUP BY

• CUBE

– Summenzeilen für alleKombinationen

SELECT artikel_name Artikel, gruppe_name Prod_Grp, sum(U.Umsatz) AS Umsatz

FROM f_umsatz U, d_artikel A


GROUP by ROLLUP (a.gruppe_name,a.artikel_name)

ORDER by a.gruppe_name

SchraubenschluesselSet Heimwerker 1559999

Stichsaege Heimwerker 1519724

Wasserwaage_1m Heimwerker 1586078

Heimwerker 24997230

Abschleppseil KFZ-Zubehoer 1611334

Aufkleber_D KFZ-Zubehoer 1581215

Autatlas KFZ-Zubehoer 1577793

ErsteHilfekoffer KFZ-Zubehoer 1468262

Fahrradhalter KFZ-Zubehoer 1606904

Felgenkappen KFZ-Zubehoer 1654885

Gluebirnen_Set KFZ-Zubehoer 1609519

Hydraulik_Wagenheber KFZ-Zubehoer 1491170

KaelteSet KFZ-Zubehoer 1490092

Oelfilter KFZ-Zubehoer 1582112

Poliermittel KFZ-Zubehoer 1561724

Reinigungsfilter KFZ-Zubehoer 1640785

Reinigungstuecher KFZ-Zubehoer 1495886

Sitzauflage KFZ-Zubehoer 1539511

Universal_Wagenheber KFZ-Zubehoer 1511483

Zusatzlicht_Front KFZ-Zubehoer 1552300

KFZ-Zubehoer 24974975

199802537

137 rows selected.

202


Ausgeben zusätzlicher „Steuerinformation“ für „programmiertes“ Auslesen des ErgebnissesSELECT

artikel_name AS Artikel,

gruppe_name AS Gruppe ,

sparte_name AS Sparte ,

sum(U.Umsatz) AS Umsatz ,

GROUPING(Artikel_name) AS Art_g ,

GROUPING(gruppe_name) AS Grp_g ,

GROUPING(Sparte_name) AS Spr_g ,

GROUPING_ID(artikel_name ,gruppe_name,sparte_name ) AS grouping_id

FROM

f_umsatz U, d_artikel A

WHERE


GROUP by CUBE

(a.sparte_name, a.gruppe_name,a.artikel_name)

HAVING

GROUPING(Artikel_name) = 1 OR

GROUPING(gruppe_name) = 1 OR

GROUPING(Sparte_name) = 1

ORDER by

GROUPING(Artikel_name),GROUPING(gruppe_name),GROUPING(Sparte_name)

/

ART_G GRP_G SPR_G G ROUPING_ID

---------- ---------- ---------- -----------

0 1 0 2

0 1 0 2

0 1 0 2

0 1 0 2

0 1 0 2

0 1 0 2

0 1 0 2

0 1 0 2

0 1 0 2

0 1 0 2

0 1 0 2

• Kombinationen von 0 und 1 werden genutzt um entsprechende Summenwerte anzuzeigen

• Grouping_ID sortiert die Kombinationsvarianten durch

203


Statistische SQL-Funktionen

204


y = 𝒂 + 𝒃𝟏𝒙𝟏 + 𝒃𝟐𝒙𝟐 + ε.

y = bx + aRegressionen

• Regr_Count #rows used in fit

• Regr_Avgx Average x Value

• Regr_Avgy Average y Value

• Regr_Slope Slope of Curve

• Regr_Intercept y-Axis intercept of Curve

• Regr_R2 r-square Goodness of Fit

• Regr_SXX #rows * var_pop(x)

• Regr_SYY #rows * var_pop(y)

• Regr_SXY #rows * covar_pop(x,y)

205


Correlation

• Korrelierende Werte aus zwei Merkmalen (Variablen)„Gibt es Abhängigkeiten zwischen zwei Variablen“

• Der Korrelations-Koeffizient nimmt Werte an von

– 0 – 1 -> Positiver Zusammenhang (proportional)

– 0 – (-1) -> Negativer Zusammenhang (umgekehrt proportional

206

select CORR_S(Gehalt, LEBENSALTER, 'COEFFICIENT‘) coefficient,

CORR_S(Gehalt, LEBENSALTER, 'TWO_SIDED_SIG') p_value

from d_kunde;

CORR_S -> Spaerman‘ rhoCORR_K -> Kendall‘s tau-b

In diesem Beispiel gibt es einen schwachen Zusammenhang zwischen Lebensalter und Gehalt von nur 0,11.


t-Test

• Die Art der Verteilung der Werte von zwei Mengen miteinander vergleichen

207

•STATS_T_TEST_ONE: A one-sample t-test

•STATS_T_TEST_PAIRED: A two-sample, paired t-test (also known as a crossed t-test)

•STATS_T_TEST_INDEP: A t-test of two independent groups with the same variance (pooled variances)

•STATS_T_TEST_INDEPU: A t-test of two independent groups with unequal variance (unpooled variances)

SELECT

Einkommensgruppe,

round(avg(decode(GESCHLECHT,0,GEHALT,null)),2) Gehalt_Maenner,

round(avg(decode(GESCHLECHT,1,GEHALT,null)),2) Gehalt_Frauen,

round(stats_t_test_indep(GESCHLECHT, GEHALT, 'STATISTIC',1),2) t_observed,

round(stats_t_test_indep(GESCHLECHT, GEHALT),2) two_sided_p_value

from

D_KUNDE

GROUP BY rollup(EINKOMMENSGRUPPE);

unabhängigeStichproben

homogeneVarianzen

heterogeneVarianzen

t-Teste fürhomogeneVarianzen

t-Test fürheterogeneVarianzen

abhängigeStichproben

Zwei Mittelwerte miteinandervergleichen

t-Test für abhängige

Stichproben


Weitere statistische Funktionen

• Var_Pop Population Variance

• Stddev_Pop

• Var_Samp Sample Variance

• Stddev_Samp

• Covar_Pop Population Covariance of a Set of pairs

• Covar_Samp Sample Covariance of a Set of pairs

• Corr Correlation Coefficient

208


Approximate Query Processing

209


210

Aggregierte Berichte müssen nicht immer 100% genau sein

• Kernproblem

– Viele BI-Abfragen nutzen oft aggregierte Informationen

– Oft besonders intensive Ressourcennutzung

– “Teure Abfragen”

• Beobachtungen

– Viele BI Anwendungen benötigen nicht exakte Ergebnisse sondern begnügensich mit einer Trenderkennung

– Auf aggregierter Ebene sind Unterschiede im Detail kaum noch wahrnehmbar

– Explorative Analysen begnügen sich oft mit einem “ersten groben Blick”. EineDetail-Analyse kann später nachfolgen


211

“Ungefähre SQL-Abfrage-Ergebnisse“

• Dennoch hohe Genauigkeit > 95 – 97%

• Antworten sind massiv schneller als bei 100 % exakten Abfragen

• Die “Approximate”-Lösung gibt es für einige häufig genutzte(und teure) Aggregate– APPROX_COUNT_DISTINCT (12.1)

– APPROX_PERCENTILE (12.2)

– APPROX_MEDIAN (12.2)

– APPROX_COUNT() (18c)

– APPROX_SUM() (18c)

– APPROX_RANK() (18c)

• Materialized Views (MV) speichern “Ungefähre Ergebnisse“ für Query Rewrite auf höheren Aggregat-Leveln


Approx_count_distinct

212

select a.artikel_name,

approx_count_distinct(u.kunden_id)

Kunden_Pro_Artikel

from f_umsatz u, d_artikel a

where u.artikel_id = a.artikel_id

GROUP BY a.artikel_name

order by a.artikel_name;

select a.artikel_name,

count(distinct(u.kunden_id))

Kunden_Pro_Artikel

from f_umsatz u, d_artikel a

where u.artikel_id = a.artikel_id

GROUP BY a.artikel_name

order by a.artikel_name;• Intensivere Memory-Nutzung pro Group By

Massiv weniger Disk-IO z. B. bzgl. Temp Space

• Parallelisierbar

Gleiche Anwendung wie count(distinct …)


213

• APPROX_COUNT()

• APPROX_SUM()

• APPROX_RANK()

Noch mehr analytische Funktionen

SELECT r.land, k.Kunden_ID,

APPROX_RANK(PARTITION BY r.land ORDER BY APPROX_SUM(u.umsatz) DESC) Rank_p_Land,

APPROX_SUM(u.umsatz) umsatz

FROM F_UMSATZ u, D_REGION r, D_KUNDE k

where u.kunden_ID = k.kunden_id and u.region_id = r.region_id

GROUP BY r.land, k.Kunden_ID;

18cNEU IN


Approx_Count_Distinct: Beispiel bei großen Datenmengen

214

Exact query

Approx query

Lots of temp

no temp

44X faster!


215

Approx_percentile/Approx_median

• Für numerische und Date-bezogene Feld-Typen

• Intensivere Speichernutzung, weniger IO

• Angabe von Fehlerrate und Confidence Level der Schätzung

SELECT APPROX_MEDIAN (sal) AS median_sal,APPROX_MEDIAN (sal, 'ERROR_RATE') AS error_rate,APPROX_MEDIAN (sal, 'CONFIDENCE') as confidence

FROM emp ;


216

select

jahr_nummer Jahr,

APPROX_PERCENTILE(0.25 deterministic) WITHIN GROUP (ORDER BY umsatz ASC) as "p-0.25" ,

APPROX_PERCENTILE(0.25 deterministic, 'ERROR_RATE') WITHIN GROUP (ORDER BY umsatz ASC) as "p-0.25-er",

APPROX_PERCENTILE(0.25 deterministic, 'CONFIDENCE') WITHIN GROUP (ORDER BY umsatz ASC) as "p-0.25-ci",

Approx_MEDIAN(umsatz) Median,

APPROX_PERCENTILE(0.75 deterministic) WITHIN GROUP (ORDER BY umsatz ASC) as "p-0.75",

APPROX_PERCENTILE(0.75 deterministic, 'ERROR_RATE') WITHIN GROUP (ORDER BY umsatz ASC) as "p-0.75-er",

APPROX_PERCENTILE(0.75 deterministic, 'CONFIDENCE') WITHIN GROUP (ORDER BY umsatz ASC) as "p-0.75-ci"

from f_umsatz u,d_zeit z

where u.zeit_id = z.zeit_id

group by jahr_nummer

order by jahr_nummer;

Die Suche nach Ausreißern überunregelmäßige Datenverteilungen,als Abweichung von der Normalverteilung

unterstes Quartil

oberstes Quartil

maxmin Median


Approx_Percentile: Beispiel bei großen Datenmengen

217

Exact query

Approx query

Lots of temp

No temp

13x faster!


218

• Anwendbar auf bestehende Umgebungen. Wirkt auch bei BI-Tool-Abfragen, die von außen nicht beeinflußt werden können:–Grundlegende Einstellung

• approx_for_aggregation = TRUE

– Unterparameter

• approx_for_count_distinct = TRUE

• Approx_for_percentile = 'all'|'percentile_disc'|'percentile_cont'|...

• Einsetzbar auf Session und System Level

Anwendung auch auf bestehende AbfragenOhne Änderung von Code


Approximate Aggregate für Query Rewrite in Materialized Views

3 Funktionen zur Erstellung von Aggregat “approximations”:

• APPROX_xxxxxx_DETAIL(expr)

– Erstellt Summentabellen (Aggregate) basierend auf Eintragungen in der GROUP BY Klausel

• APPROX_xxxxxx_AGG (expr)– Aggregiert von einem niedrigeren Dimensions-Level zu einem höheren Level

• TO_APPROX_xxxxxx(detail, …)– Wandelt gespeicherte Aggregat-Werte in lesebare Werte um

219


220

Artikel

Gruppe

Sparte


Hierarchie Tag/Woche/Jahr


ArtikelZeit

RegionChannel

Channel

Medium

Kampagne


Hierarchie Tag/Monat/Quartal/Jahr

Keys

Facts

Artikel

Gruppe

Sparte

All

Tag

Monat

Quartal

Jahr

AllOrt

Kreis

Land

Region

AV_UMSATZMengeUmsatzVorjahres_UmsatzYear_To_Date_Umsatz….

Artikel

Zeit

Region


CREATE MATERIALIZED VIEW MV_percentile_per_LandENABLE QUERY REWRITE ASSELECT Land, Kreis

APPROX_PERCENTILE_DETAIL(umsatz)AS detailFROM f_umsatz,d_artikel,d_zeit,d_RegionWhere FK=PK….GROUP BY Land, Kreis;

221

Artikel

Gruppe

Sparte

All

Tag

Monat

Quartal

Jahr

AllOrt

Kreis

Land

Region

F_UMSATZMengeUmsatzVorjahres_UmsatzYear_To_Date_Umsatz….

Artikel

Zeit

Region

SELECT state, APPROX_MEDIAN(land) AS detailFROM umsatzGROUP BY state;

SELECT TO_APPROX_PERCENTILE(APPROX_PERCENTILE_AGG(detail), 0.5)

FROM percentile_per_state_mvGROUP BY state;

MV rewrite


FETCH FIRST n ROWS

222

SELECT * FROM

(SELECT




from




WHERE Rangfolge < 11; SELECT




from






Analytic Views

223


Wie funktionieren heutige Analyse-Infrastrukturen?

224

BI-Tool und BI Anwendungen

Business Modell und Kalkulationen

Query Generator

DatenbankDaten und Abfrageausführung

• Metadata und Kalkulationen sind im Anwendungs-Layer definiert

– Wenig Wiederverwendungseffekte

– Mehrfacharbeit

– Mögliche Inkonsistenzen

– Eventuell unnötige Datentransporte

– Zuviel und zu teure Infrastrukturen auf der Client-Seite

– Zu viel IT-Know how / Personal in den Fachabteilungen

– ….

• Komplexe Code-Generatoren

– Inflexibel

– Schwergewichtige Tools


Analytical Views

• Vollständige Beschreibung einer multidimensionale Sicht mittels Metadaten in der Datenbank

– Dimension-Attributes

– Hierarchies mit Level

– Measures (direkte und virtuelle berechnete Spalten)

• Implementieren von Business-Logik

• Über MDX ansprechbar

225


Vereinfachung multidimensionaler Abfragen

226

Physical Layer

Tables

Views

External Tables

Big Data SQL

Business Model

Attributes

Levels + Hierarchies

Aggregation Rules

MeasureCalculations

PresentationLayer

Einfaches SQL

MDX / OLE DB forOLAP

PresentationMetadata


3 neue Datenbank - Objekte

227

Keys

LevelAttribute

SourceTabellen

Beschreibungen

AttributeDefinition

All

Land

Kreis

Ort

All

Jahr

Monat

Tag

WocheAnalytic

View

Aggregation Rules

Hierarchien

Fact Tables

Kennzahlen

Berechnungen

• Hierarchien• Level und Drillpfade• Abfragbare Strukturen• Strukturauflösungen auf

Werteebene

• Attribut-Dimensionen• Identifizieren von

Daten-Objekte• Funktion von Spalten

wird festgelegt

• Analytic Views• Kopplung Dimensionen und

Fakten• Eine neuer View-Typ, der

über Metadaten Daten-Objekte zusammen-zieht


228

Artikel

Gruppe

Sparte



Bohrhammer 4711Farbtopf_Lack_rotCU_Muffe_18mmTag

WocheMonatQuartalJahrDekade



ArtikelZeit

RegionChannel

Channel

Medium

Kampagne



Keys

Facts

Was ist nötig, um diesen Output zu erzeugen?- Umsatz pro Artikel- Gruppiert nach Jahren- Anteil des Artikelumsatzes am

Gesamt-Artikelgruppenumsatz- Vorjahresvergleich


229

Artikel

Gruppe

Sparte



Bohrhammer 4711Farbtopf_Lack_rotCU_Muffe_18mmTag

WocheMonatQuartalJahrDekade



ArtikelZeit

RegionChannel

Channel

Medium

Kampagne



AttributeDimension

Hierarchy

Analytic View

Source TableAttribute-MappingOrderLevels

Attribute-Dimension

Level-Hierarchien

Source-Fact-TableAttribute-

DimensionHierarchie-ObjekteMeasuresBerechnung_1Berechnung_2Berechnung_3Berechnung_4…….

Keys

Facts

SELECTdim_Zeit.att1, dim_Artikel.att2Measure1,Berechnung_2….

FROMAV_Umsatz

HIERARCHIES (H1,H2)WHERE

H1.level_name in (‘xxxxx‘ )and H2.level_name in (‘yyyyy‘ )

ORDER BYH1.level_order


230

Artikel

Gruppe

Sparte




ArtikelZeit

RegionChannel

Channel

Medium

Kampagne



Keys

Facts

Artikel

Gruppe

Sparte

All

Tag

Monat

Quartal

Jahr

AllOrt

Kreis

Land

Region



231

Artikel

Gruppe

Sparte

All

Tag

Monat

Quartal

Jahr

AllOrt

Kreis

Land

Region


selectArtikel_hier.member_name as Artikel, ZEIT_HIER.jahr,umsatzanteil_artikel_parentumsatz_vorjahr

fromav_umsatz hierarchies (Artikel_hier, ZEIT_HIER)

whereArtikel_hier.level_name = 'ARTIKEL' andZEIT_HIER.level_name = 'JAHR'order by ZEIT_HIER.jahr;


232

Artikel

Gruppe

Sparte

All

Tag

Monat

Quartal

Jahr

AllOrt

Kreis

Land

Region


selectArtikel_hier.member_name as Artikel, ZEIT_HIER.jahr,umsatzanteil_artikel_parentumsatz_vorjahr

fromav_umsatz hierarchies (Artikel_hier, ZEIT_HIER)

whereArtikel_hier.level_name = 'ARTIKEL' andZEIT_HIER.level_name = 'JAHR'order by ZEIT_HIER.jahr;

Analytic-View-Definion

Hierarchie-Definitionen

Zusätzliche Berechnungen

Daten-Spalte in Fakt-Tabelle

Level-Wert-Vertreter aus den jeweiligen Dimensionen

Festlegen des Hierarchie-Levelsfür die Betrachtung der jeweiligen Kennzahl


Strukturierter Zugriff auf dimensionale Werte

233

SELECTCASE is_leaf

WHEN 0 then lpad(' ',depth * 2,'.') || '+ ' || member_nameELSE lpad(' ',depth * 3,'.') || member_name END AS DRILL,depth

FROM Ort_hierORDER BY hier_order;

SELECTCASE is_leaf

WHEN 0 then lpad(' ',depth * 2,'.') || '+ ' || member_nameELSE lpad(' ',depth * 3,'.') || member_name END AS DRILL,depth

FROM Artikel_hierORDER BY hier_order;

Standardisierte Definitionen und Schlüsselwörter


Create Dimension /Hierarchy• Level-Definition

• Schlüssel auf Level-Ebene

• Standardisierte Terminologie

– Z. B. MEMBER NAME

• Parent / Child Festlegung

– Drillpfade

234

Create or replace force attribute dimension Att_dim_Artikeldimension type STANDARDUSING D_ARTIKELAttributes (

"ARTIKEL_NAME" as ARTIKEL_NAME , "ARTIKEL_ID" as ARTIKEL_ID ,"GRUPPE_NR" as GRUPPE_NR , "GRUPPE_NAME" as GRUPPE_NAME , "SPARTE_NAME" as SPARTE_NAME , "SPARTE_NR" as SPARTE_NR , "QUALITAET" as QUALITAET ,"WERTIGKEIT" as WERTIGKEIT , "EK_PREIS" as EK_PREIS , "VK_PREIS" as VK_PREIS)

LEVEL ARTIKELKEY ARTIKEL_IDMEMBER NAME ARTIKEL_NAMEMEMBER CAPTION ARTIKEL_NAMEORDER BY ARTIKEL_ID

DETERMINES (GRUPPE_NR,EK_PREIS,VK_PREIS,QUALITAET,WERTIGKEIT)LEVEL ARTIKEL_GRUPPEKEY GRUPPE_NRMEMBER NAME GRUPPE_NAMEMEMBER CAPTION GRUPPE_NAME

DETERMINES (SPARTE_NR)LEVEL ARTIKEL_SPARTEKEY SPARTE_NRMEMBER NAME SPARTE_NAMEMEMBER CAPTION SPARTE_NAME

ALL MEMBER NAME 'Alle Artikel'

CREATE OR REPLACE HIERARCHY Artikel_hierUSING Att_dim_artikel(ARTIKEL CHILD OF ARTIKEL_GRUPPE CHILD OF ARTIKEL_SPARTE)


Definition Analytic View

235

CREATE OR REPLACE ANALYTIC VIEW av_umsatzUSING F_UMSATZ DIMENSION BY

(Att_dim_Artikel KEY ARTIKEL_ID REFERENCES ARTIKEL_ID HIERARCHIES ( Artikel_hier ),-- List of hierarchies that use

Att_dim_REGION KEY REGION_ID REFERENCES ORTNR HIERARCHIES (Ort_hier ),Att_dim_zeit KEY ZEIT_ID REFERENCES ZEIT_ID HIERARCHIES (Zeit_hier)

) MEASURES

(umsatz FACT umsatz,as (SHARE_OF (UMSATZ HIERARCHY Artikel_hier PARENT)),

antanteil_artikel_parenteil_Region_parent as (SHARE_OF (UMSATZ HIERARCHY ort_hier PARENT)),umsatz_vorjahr as (LAG(umsatz) OVER (HIERARCHY Zeit_hier OFFSET 1 ACROSS ANCESTOR AT LEVEL jahr)),menge FACT menge)

DEFAULT MEASURE UMSATZ;


Datenbank wahlweise im Hauptspeicher

Keine Änderung der Anwendung

Spaltenorientiert

Komprimiert2-20 fach

Parallelisierung

Nutzt bestehende DB-Architektur und Funktionalität

Auf jeder Hardwaremöglich

236


Was macht In-Memory Database-Option so schnell

• In-Memory Speicherung

• Spaltenorientierte Speicherung

• Dynamischer Column-Index

• Komprimierung

• SIMD-Verarbeitung

• Bessere Parallelisierung

• Bloom-Filter

• In-Memory-Aggregation

237

Buffer-Pool Column-Store

F_UMSATZ F_UMSATZ

RowFormat

ColumnFormat


Es ist nur ein Schalter!! – Kein MigrationsprojektD_ARTIKEL

ARTIKEL_NAMEGRUPPE_NR GRUPPE_NAME SPARTE_NAME SPARTE_NR ARTIKEL_ID

F_UMSATZ

PK

PK

PK

PK

FK

FK

FK

FK

FK

D_KUNDEKUNDEN_IDKUNDENNR GESCHLECHTVORNAME NACHNAME TITEL ANREDE GEBDAT BRANCHE WOHNART KUNDENARTBILDUNG ANZ_KINDER EINKOMMENSGRUPPE ORTNR NUMBER, BERUFSGRUPPE STATUS STRASSE TELEFON TELEFAX KONTAKTPERSONFIRMENRABATT BERUFSGRUPPEN_NR BILDUNGS_NR EINKOMMENS_NR WOHNART_NR HAUSNUMMERPLZ ORT KUNDENKARTEZAHLUNGSZIEL_TAGE TOTAL TOTAL_NR

Alter table F_UMSATZ INMEMORY;

Alter table D_ZEIT INMEMORY;

Alter table D_VERTRIEBSKANAL INMEMORY;

Alter table D_REGION INMEMORY;

Alter table D_KUNDE INMEMORY;

Alter table D_ARTIKEL INMEMORY;

• Laden in den InMemory-Speicher:Einfaches Markieren

• Danach einmal anfassen

20 Mio Sätze~ 3,1 GB CREATE TABLE F_UMSATZ ……

PARTITION BY RANGE ……

(PARTITION p1 ……

INMEMORY NO MEMCOMPRESS

PARTITION p2 ……

INMEMORY MEMCOMPRESS FOR DML,

PARTITION p3 ……

INMEMORY MEMCOMPRESS FOR QUERY,

:

PARTITION p200 ……

INMEMORY MEMCOMPRESS FOR CAPACITY

);

D_ZEIT

DATUM_ID TAG_DES_MONATS TAG_DES_JAHRES WOCHE_DES_JAHRESMONATS_NUMMER MONAT_DESC QUARTALS_NUMMER JAHR_NUMMER ZEIT_ID


D_VERTRIEBSKANAL


ARTIKEL_IDKUNDEN_IDZEIT_IDREGION_IDKANAL_IDUMSATZMENGEUMSATZ_GESAMT

UMSATZ_GESAMTVERTRIEBS_KZSTEUERVERPACKUNGSARTHANDELSKLASSEKOMMISSIONSWARELAGERWAREBESCHREIBUNGLIEFER_DATUMRECHNUNGS_DATUMZAHLUNGS_ZIEL

238


239

Der Blick in den Column-Store

Alter table F_UMSATZ_BREIT inmemory

alter table f_umsatz_breit INMEMORYINMEMORY MEMCOMPRESS FOR QUERY HIGH (ARTIKEL_ID,KUNDEN_ID,ZEIT_ID,REGION_ID,KANAL_ID,UMSATZ,MENGE)NO INMEMORY (UMSATZ_GESAMT,VERTRIEBS_KZ,STEUER,VERPACKUNGSART,HANDELSKLASSE,KOMMISSIONSWARE,LAGERWARE,BESCHREIBUNG, LIEFER_DATUM,RECHNUNGS_DATUM,ZAHLUNGS_ZIEL);

2

1


Was macht In-Memory so schnell?

240

Der Aufwand für die Abarbeitung analytischer Abfragen lässt sich aufteilen in

Joins• SIMD Enhanced

Bloom Filters

• Join Group

Data Access

• In-Memory Scan

Aggregation• In-Memory Aggregation

• In-Memory-Expression

40%40%20%

Sum / avg / group by....

Column-orientedCompressionParallel Query


> 7 Milliarden Wertepro Sekunde pro CPU Core

241

Vec

tor

Reg

iste

rLoadmultipleregion values

VectorCompare all valuesan 1 cycle

CPU

Memory

REG

ION

CA

CACA

CA

LINEORDERDATE_DIM

Dat

eKey

Am

ou

nt

Type=d.d_date='December 24, 2013'

Datekey is 24122013

Dat

eKey

Dat

e

Sum

Sales

Stores

ProductsIn-Memory

Report Outline

Footwear

Ou

tlet

s $$$

$$$$

Footwear

SalesOutlets

Vektor Scans (SIMD)

Bloom Filter

In-Memory Aggregieren


In-Memory zusätzlich schnell machen

242

Net = Price + Price * Tax

In-Memory-Expression

Sales

Tax

Pri

ce

Pri

ce +

Pri

ce X

Tax

Pri

ce +

Pri

ce *

Tax

CREATE TABLE SALES (

PRICE NUMBER, TAX NUMBER, …,

NET AS (PRICE + PRICE * TAX))

INMEMORY;

CREATE INMEMORY JOIN GROUP V_name_jg

(VEHICLES(NAME),SALES(NAME));

Sales

VEH

ICLE

NA

ME

Join-Group-Objekte

SalesVehicle

NAMEis join

columnNA

ME

Sammelt automatisch dieTop 20 analytischen Abfragen


Im-Memory Expressions

243

EXEC DBMS_INMEMORY_ADMIN.IME_CAPTURE_EXPRESSIONS('CUMULATIVE');

# Starten (Achtung: dabei wird die betroffene Tabelle im Column-Store komplett ausgetauschtEXEC DBMS_INMEMORY_ADMIN.IME_POPULATE_EXPRESSIONS();

# Löschen von IM-ExpressionsEXEC DBMS_INMEMORY.IME_DROP_EXPRESSIONS('SYS_IME00010000000D7B1F');

# Abfragen von gespeicherten ExpressionsSELECT OWNER, TABLE_NAME, COLUMN_NAME, SQL_EXPRESSION FROM DBA_IM_EXPRESSIONS;

SELECT TABLE_NAME, COLUMN_NAME, SQL_EXPRESSION FROM USER_IM_EXPRESSIONS;


Join-Groups - Beispiel

244

SELECT j.NAME AS JOIN_GROUP_NAME, o.OBJECT_NAME, d.COL#, d.DOMAIN#

FROM IM_DOMAIN$ d, DBA_OBJECTS o, IM_JOINGROUP$ j

WHERE d.OBJN=o.OBJECT_ID;

CREATE INMEMORY JOIN GROUP Umsatz_Zeit (F_UMSATZ(ZEIT_ID), D_ZEIT(ZEIT_ID));


• Komplexe Abfragen auf viele Daten– mit mehreren Joins– Sub-Selects– Groupings– Analytische Funktionen

#Joins #WhereCondition

Subselect AnalyticFunctions

P4P1

Mit In-MemoryOhne In-Memory

P4P1Beispielabfrage

Umsatz pro Region, Zeit,Vertriebskanal, , BerufsgruppeSortiert nach Kriterien (Abf. 2)

5 5 - 1 14,35 27,00 1,10 0,53

Stärkster Umsatzmonat pro Bundesland in 2010 (Abf. 8) 3 2 1 3 26,66 35,03 1,00 0,54

Top 10 Artikel bezogen auf Umsatz in einem Jahr pro Bundesland in 2010 (Abf. 10)

4 3 1 4 23,14 32,03 3,02 1,55

Grouping

1

2

3

Keine repräsentative Hardware: Laptop mit Intel i5-3320M 2,6 GHz CPU und 4 GB In-Memory-Storage

In-Memory im Data Warehouse

245


Partitionierung und In-Memory-Kompression

März 14

Februar 14

Januar 14

Dezember 13

November 13

Oktober 13

September 13

August 13

Juli13

Juni 13

April 13

März 13

Februar 13

Juni 14

Mai 14

April 14

PartitionierteTabelle

MEMCOMPRESS FOR CAPACITY HIGH

MEMCOMPRESS FOR CAPACITY LOW

MEMCOMPRESS FOR QUERY LOW

MEMCOMPRESS FOR DML ständige Updates

ausschließlich Lesen

gelegentliches Lesen

kaum Leseaktivitäten

246


Vorgehensweise / Statements / Demo / Test

247

# Starten DB mit modifizierter init.orastartup PFILE='D:\app\admin\orcl\pfile\init.ora'' # Abfragen aller gesetzter In-Memory-Paramter

show parameter inmemory;

ALTER SESSION set inmemory_query = enable;

# Markieren einer Tabelle mit In-Memoryalter table F_UMSATZ inmemory;

# Tabellen-Information select TABLE_NAME, CACHE, inmemory_priority,inmemory_distribute, INMEMORY_COMPRESSION from user_tables;

# Laden der Tabelle in den Column-StoreSelect count(*) from F_UMSATZ;

Select v.segment_name name, ……… From v$im_segments V;

SELECT * FROM (SELECT a.Artikel_Name as Artikel, …………


Monitoring Column-Store

248

Select v.owner,v.segment_name name, v.bytes,round(v.bytes/1000000000,6) GB,v.BYTES_NOT_POPULATED Rest_Bytes,round(v.BYTES_NOT_POPULATED/1000000000,6) Rest_GB,v.populate_status Status, round(v.inmemory_size/1000000000,6) in_mem_GB,round(v.bytes / v.inmemory_size,2) comp_ratio,v.INMEMORY_PRIORITY Prioritaet,v.INMEMORY_COMPRESSION comp_Art

Fromv$im_segments V;


Schichten reduzieren mit In-Memory

249

Mit

In-M

em

ory Enterprise Layer

Core - DWH / Info PoolIntegration

LayerBI Plattform

C a c h e

Virtualisierung des User View Layers- Mehr Flexibilität- Schnellere Weiterentwicklung / Reagieren- Weniger Redundanz von Daten- Volle multidimensionale Sicht

Virtuelle Strukturen

User ViewLayer


Weniger Schichten in der Architektur mit In-Memory

250


User ViewLayer

IntegrationLayer C a c h e

BI Plattform

Analytische Datenbank

1:1 Kopie

Separate Hardware +Maintenance

In Memory


IntegrationLayer

BI Plattform

Virtuelle Strukturen

User ViewLayer

1:1 Kopie

Früher

Heute


251

Mögliches Vorgehen : Virtualisierung User View LayerEnterprise Layer User View Layer

MavKZ

• Im Enterprise Layer müssen– Dimensionsschlüssel müssen bereits

existieren

– Historisierung

• Historisierung

• Kaum physikalische Persistenz auf den Festplatten

• Zugewinn– Flexiblere und schneller Bereitstellung

multidimensionaler Strukturen

– Weniger Plattenplatz weil weniger Redundanzim Schichtenmodell

– Mehr Performance

Dimension als View auf In-MemoryStammdaten

Kleine Dimensionenterden persistiert

ARTIKEL_IDARTIKEL_NAMEGRUPPE_NRGRUPPE_NAMESPARTE_NRSPARTE_NAME

REGIONREGIONNR

KREISNRORTNRORTREGION_ID

REGIONNRLANDLANDNR

LANDNRKREISNRKREIS

ARTIKEL_IDARTIKEL_NAMEGRUPPE_NR

GRUPPE_NRGRUPPE_NAMESPARTE_NR

SPARTE_NRSPARTE_NAME

ZEIT_IDDATUM_IDTAG_DES_MONATSTAG_DES_JAHRESWOCHE_DES_JAHRESMONATS_NUMMERMONAT_DESCQUARTALS_NUMMERJAHR_NUMMER

REGIONREGIONNRLANDLANDNRKREISNRKREISORTNRORTREGION_ID

VW_ORT

VW_ARTIKEL


252

Effekte des Virtualisierungs-Szenarios

Plattenplatz

AntwortzeitBeispielabfrage

Indexe

ETL-Aufwand

Anzahl Tabellen

Virtualisierung Data Marts

Klassische Lösung

Bitmap-Indexe

30- 50 Sek. (Platte)3- 5 Sek. (Cache)

0.5 – 1 Sek.

keine

Redundanzen zwischenKern-DWH und Data Marts

Minus 20 – 50 % Wegfall Redundanz + Indexe

Aufbau Data Marts ~ minus 20%(einfache ETL-Strecken fallen weg)

~ minus 10% Gesamt-Anzahl~ minus 50 % der großen Tabellen100 %


DatenbewirtschaftungLaden und Updaten im Data Warehouse

253


Ziele und Aufgaben

• Bereitstellen von Daten in adäquater Weise

– Zeitlich passend

– Richtige Form

– Passende Inhalte

• Daten so ablegen, dass man sie wiederfindet

– Dokumentation

• Daten Ressourcen-ökonomisch speichern

– Berücksichtigung von Plattenplatz

Was wird geladen

• Es sollte nur das geladen werden, was wirklich gebraucht wird

• Gibt es einen Auftrag für das Laden bestimmter Daten?

– Wer braucht die Daten?

– Welche Daten werden gebraucht?

• Sind die zu ladenden Daten in einem brauchbaren Zustand?

– Welche Anforderungen sind an Quelldaten zu stellen?

– Wer definiert die Anforderungen?

254


Schichtenmodell zur Organisation des ETL-Prozesses nutzen


Nur denormalisierende

Joins

Die Masse aller

Prüfungen

Möglichst vieleKennzahlen in die

Datenbank

Repository(Glossar, alle Objekte)

Stamm-Referenzdatenaktualisieren

Richtigselektieren

R R

BS S

S

D

D

DDT

T

TB

F

ETL: Kosten pro Kunde

F

F

D

D

D

D


ETL: Kosten pro KundeB

B


B

B

Die frühest mögliche Stelle für Transformationen finden

255


Aufgaben und Konzepte im ETL-Prozess

Integration Enterprise User ViewFlüchtige Daten Persistent Kopien / teilpersistent

dynamisch

KopierenSelektieren

Generische Datenstrukturen(isolierte Tabellen,teil-ausgeprägte Datentypen)

Keine Constraints

3 NF Datenstrukturen(ER-Tabellen,ausgeprägte Datentypen)

Aktivierte Constraints

Multidimensionale Modelle(ER-Tabellen,ausgeprägte Datentypen)

MengenbasiertesPrüfen ohne Constraints

UmschlüsselungLookups -> Referenz-/StammdatenJoinsAufbauen von Distinct-Strukturen(Normalisieren)

„Umschlüsselung“ -> NeinLookups -> DimensionsdatenJoins - Denormalisieren

NormalisierenHistorisieren

(Granularisieren)

Denormalisierenz.T. Aggregieren

Clearing-Verfahren,technisches, logisches,semantisches Prüfen

Modelle

Konzepte

Transformationen

Daten

256


Verfahren für schnelles ETL in der Datenbank

Enterprise Information Layer

User View Layer

Data Integration Layer

SelektierenStattkopieren

Direct Pathin temporäreTabellen

Contraint-freies Prüfen mit Mengen-basiertemSQL

PartitionExchange&LOADin partit.Tabellen(PEL)

UnveränderteBewegungs-daten liegenlassen

Große Fakten-Tab.über PEL.

Kenn-zahlen aus-schließlich über MAV-Refresh

BekannteKennzahlenin die DBweniger Koipien inBI-Tools

257


High Water Mark

Free spaceafter delete

Unused block

Extent ID 0 1 2 3 4

Extent ID 0 1 2 3 4

Used block

Nach INSERTS:

High-water mark

Segm

en

tSe

gme

nt

Nach DELETES:

258


Segm

en

t

Direct Path Load

Free space after delete Blocks used by inserted rows

High-water markUsed block

F_UMSATZ

INSERT /*+APPEND */ INTO DWH.F_UMSATZ

NOLOGGING

SELECT * FROM OLTP.BESTELLUNGEN;

Serverprocess

259


Segm

en

t

Paralleler Direct Path Load

Free space after delete Temporary segments

High-water markUsed block

F_UMSATZ

ALTER SESSION ENABLE PARALLEL DML;

INSERT /*+APPEND PARALLEL(F_UMSATZ,2) */

INTO DWH.F_UMSATZ NOLOGGING

SELECT * FROM OLTP.BESTELLUNGEN;

Slaveprocess

Slaveprocess

260


Direct Path / Convential PathConvential Path• Commits• Reuse Free Space in Blöcken• Constraint Checks• Immer Undo Data / Logging• Daten zunächst immer in SGA Buffer• Tabelle für andere Benutzer offen

Direct Path• Data Save• Schreiben oberhalb der High Water Marks • Keine Constraint Checks

• Nur PK, Not Null, Unique Key• Kein Logging• Daten nicht in SGA Buffer• Tabelle gesperrt für andere Benutzer

Convential Path

SQL LoaderExternal TableInsert AppendCTAS

Benutzer

SQL Command Processing

Space ManagementGet new extents

Adjust High Water Mark

Find partial blocksFill partial blocks

Buffer Cache

Buffer Cache Management- Manage queues- Manage contention

Read DatabaseBlocks

Write DatabaseBlocks

Direct Path

Database

Or

ac

le

S

er

ve

r261


Data Quality-Checks mit System: es gibt 6 Prüf-KategorienAttribut-bezogene Regeln

1. Not Null / Pflichtfelder

2. Formatangabena) numeric

b) Alphanumerisch

c) Date

d) Masken

3. Div. Check Constraint

4. Wertbereiche– Ober-/Untergrenzen / Wertelisten

Satz-bezogene Regeln5. Abhängigkeiten von Werten in anderen

Attributen desselben Satzes

Satz-übergreifende Regeln6. Primary Key / Eindeutigkeit

7. Aggregat – Bedingungena) Ober- Untergrenzen von Summen

b) Anzahl Sätze pro Intervall usw.

8. Rekursive ZusammenhängeVerweise auf andere Sätze derselben Tabelle (Relation)

Tabellen-übergreifende Regeln

9. Foreign Keya) Child-Parent (Orphan)b) Parent-Child

10. Aggregat – Bedingungena) Ober- Untergrenzen von Summenb) Anzahl Sätze pro Intervall usw.

11. Referenz-Zusammenhänge– Verweise auf Sätze einer anderen Tabelle (Relation)

Zeit-/ Zusammenhang-bezogene Regeln

12. Zeitinvariante Inhalte (z. B. Anz. Bundesländer)13. Zeitabhängige Veränderungen 14. Über die Zeit mit anderen Daten korrelierende Feldinhalte

Verteilungs-/Mengen-bezogene Regeln15. Verteilung

a) Arithmetische Mittelb) Varianz / Standardabweichungen

16. Qualitätsmerkmale und Mengen

A

B

C

D

E

F

262


Mengen-basierte Prüfungen mit SQL

select bestellnr,case

when -- wenn Feld BESTELLNR nicht numerischREGEXP_LIKE(BESTELLNR, '[^[:digit:]]')

then 1else 0

End Num_Check_bestellnrfrom bestellung;

insert /*+ APPEND */ into err_non_unique_bestellung

select bestellnr from (select

count(bestellnr) n,

bestellnr

from bestellung

group by bestellnr)

where n > 1;

select CASE

WHEN (F1 = 3 and F2 = F3 + F4)then 1 ELSE 0

endfrom fx

Attribut-bezogene Regeln

1. Not Null / Pflichtfelder

2. Formatangabena) numeric

b) Alphanumerisch

c) Date

d) Masken

3. Div. Check Constraint

4. Wertbereiche– Ober-/Untergrenzen / Wertelisten

Satz-bezogene Regeln5. Abhängigkeiten von Werten in anderen Attributen

desselben Satzes

Satz-übergreifende Regeln6. Primary Key / Eindeutigkeit

7. Aggregat – Bedingungena) Ober- Untergrenzen von Summen

b) Anzahl Sätze pro Intervall usw.

8. Rekursive ZusammenhängeVerweise auf andere Sätze derselben Tabelle (Relation)

A

B

C

263


Umgang mit SQL und PL/SQL im DB-ETL

So nicht ... Aber z. B. so ...

Create or replace procedure Proc_AV1 number;V2 number;V3 varchar2;V4 varchar2;....Cursor CS as select s1,s2 from tab_src;Beginopen CS;loop

fetch CS into v1,v2,...;select f1 into v3 from tab1;select f1 into v4 from tab2;

insert into Ziel _tab s1,s2,s3,s4values(v1,v2,v3,v4);

end;end;

insert into ziel select f1, f2, f3, f4 from

(with CS as select s1 v1,s2 v2 from tab_src

Select tab1.f1 f1 ,tab2.f2 f2, CS.s1 f3,CS.s2 f4 from tab1,tab2,CS

Where...);

264


• Temporäre Tabelle ist optional

– Ist wesentlich übersichtlicher

– Erlaubt Kombination von unterschiedlichen Prüfkriterien

Arbeiten mit temporären Tabellen erleichtert das Prüfen

Stage-Tabelle

Varchar2()

Kopieren

Gepruefte_Daten

Date

Number

Varchar2()Feld1Feld2Feld3

Temp-Tabelle

Varchar2()

Feld1Feld2Feld3

Feld1_is_nullFeld1_is_numericFeld2_is_numeric

INSERT INTO

temp_table

SELECT

CASE

....

FROM

Stage_Table

Error_Daten

Date

Number

Varchar2()

INSERT ALL

WHEN

Feld_1_is_null =1

into

Error_Daten

WHEN

Feld_1_is_null=0

into

Gepruefte_Daten

265


Error Logging

• Constraints

– Unique Key / Primary Key

– Foreign Key

– NOT NULL

– Check Constraint

Kunde

Kunde_err

KUNDENNRVORNAME NACHNAME ORTNR STRASSE TELEFON

KUNDENNRVORNAME NACHNAME ORTNR STRASSE TELEFON

ORA_ERR_NUMBER$ORA_ERR_MESG$ ORA_ERR_ROWID$ORA_ERR_OPTYP$ ORA_ERR_TAG$

INSERT INTO Kunde

VALUES (......)

LOG ERRORS INTO

kunde_err('load_20040

802')

266


Testfall

Bestellung

1.100.000Sätze

100.000doppelt

Bestellung_Check

BESTELLNRORTNRKUNDENNRDATUMANZAHLPOS

BESTELLNRORTNRKUNDENNRDATUMANZAHLPOS

UNIQUE-CONSTRAINT

Bestellung_Check_Errors

BESTELLNRORTNRKUNDENNRDATUMANZAHLPOSORA_ERR_NUMBER$ORA_ERR_MESG$ORA_ERR_ROWID$ORA_ERR_OPTYP$ORA_ERR_TAG$

267


Testfall

begin

dbms_errlog.create_error_log(

dml_table_name => 'BESTELLUNG_CHECK',

err_log_table_name => 'BESTELLUNG_CHECK_ERRORS'

);

end;

SQL> insert into bestellung_check select * from bestellung

2 LOG ERRORS INTO bestellung_check_errors ('daily_load') REJECT LIMIT 200000

3 ;

1000000 Zeilen erstellt.


268


Die Alternative

create table Bestellung_non_unique as

select bestellnr from

(select count(BESTELLNR) n, bestellnr

from bestellung

group by bestellnr)

where n > 1;

Tabelle wurde erstellt.


insert /*+ APPEND */ into bestellung_check

select B.BESTELLNR,B.ORTNR,B.KUNDENNR,B.DATUM , B.ANZAHLPOS

from bestellung B

where B.BESTELLNR not in (select bestellnr from Bestellung_non_unique);

900000 Zeilen erstellt.

Abgelaufen: 00:00:02.26 Zusammen 00:00:03.15

1.

2.

269


Check Constraint mit Regular ExpressionsCREATE TABLE Check_KUNDE (

KUNDENNR NUMBER,

GESCHLECHT NUMBER,

VORNAME VARCHAR2(50),

NACHNAME VARCHAR2(50),

ANREDE VARCHAR2(10),

GEBDAT DATE,

ORTNR NUMBER,

STRASSE VARCHAR2(50),

TELEFON VARCHAR2(30)

);

ALTER TABLE check_kunde

ADD CONSTRAINT Ch_KD_Name

CHECK(REGEXP_LIKE(NACHNAME, '[^[:digit:]]'));

Regel: Im Kundennamen müssen Buchstaben vorkommen und keine reine Zahlenkolonne

INSERT INTO check_kunde (Kundennr, Geschlecht, Vorname, Nachname, Anrede, Gebdat,

Ortnr, Strasse, Telefon)

VALUES (9,1,'Klaus','123','Herr','01.01.60',2,'Haupstr.',08923456);

FEHLER in Zeile 1:

ORA-02290: CHECK-Constraint (DWH.CH_KD_NAME) verletzt

• Verwendung von Regular Expressions steigert die Performance bei Prüfungen

270


271

• Optimal bei der Übernahme von nicht geprüften Feldern aus Vorsystemenvom Typ Text (z. B. varchar)

• Gerade Feld-bezogene Prüfungen sind sehr teuer

• Typ-Prüfungen für

– Binary_Double, Binary_float

– Date, number

– Interval DAY to Second / Year to Month

– Timestamp / with time zone / with local time zone

validate_conversion für schnellere Typ-Prüfungen

Oracle Confidential –Restricted


272

Beispiel

create table tmp_transaktionen asselect

bestelldatum, validate_conversion(Bestelldatum as date) Bestelldatum_Datum_check,Menge,validate_conversion(Menge as number) Menge_number_check,KUNDEN_ID,validate_conversion(KUNDEN_ID as number) KUNDEN_ID_number_check,ARTIKEL_ID,validate_conversion(ARTIKEL_ID as number) ARTIKEL_ID_number_check

from Transaktionen;

Ist das Feld BESTELLDATUM vom Typ Date? Wenn ja dann „1“ wenn nein dann „0“

Ist das Feld MENGE numerisch?Wenn ja dann „1“ wenn nein dann „0“

Ist das Feld KUNDEN_ID numerisch?Wenn ja dann „1“ wenn nein dann „0“

Ist das Feld ARTIKEL_ID numerisch?Wenn ja dann „1“ wenn nein dann „0“


• Temporäre Tabelle ist optional

– Ist wesentlich übersichtlicher

– Erlaubt Kombination von unterschiedlichen Prüfkriterien

– Leichte Fehlerstatistik

Konzept für Einzelfeldprüfung

273

Stage-Tabelle

Varchar2()

Kopieren

Gepruefte_Daten

DateNumberVarchar2()

Feld1Feld2Feld3

Temp-Tabelle

Varchar2()

Feld1Feld2Feld3

Feld1_is_nullFeld1_is_numericFeld2_is_numeric

INSERT INTO

temp_table

SELECT

validate_conversion

....

FROM

Stage_Table

Error_Daten

DateNumberVarchar2()

INSERT ALL

WHEN

Feld_1_is_null =1

into

Gepruefte_Daten

WHEN

Feld_1_is_null=0

into

Error_Daten

• Automatisch aussortierte Fehlersätze

• Alle Feld-bezogenen Prüfungen an einer Stelle

– Mengenbasiert mit SQL

– Extrem schnell


274

UmsetzungsbeispielTransaktionenBestelldatum varchar2(20),Menge varchar2(20),Artikel_ID varchar2(20),Kunden_ID varchar2(20)

Tmp_Transaktionen

Transaktionen_ok

Transaktionen_error

create table tmp_transaktionen asselectbestelldatum, validate_conversion(Bestelldatum as date) Bestelldatum_Datum_check,Menge,validate_conversion(Menge as number) Menge_number_check,KUNDEN_ID,validate_conversion(KUNDEN_ID as number) KUNDEN_ID_number_check,ARTIKEL_ID,validate_conversion(ARTIKEL_ID as number) ARTIKEL_ID_number_check

fromTransaktionen;

insert all when Bestelldatum_Datum_check = 1 and

MENGE_NUMBER_CHECK = 1 andKUNDEN_ID_NUMBER_CHECK = 1 andARTIKEL_ID_NUMBER_CHECK = 1then into transaktionen_ok(BESTELLDATUM,Menge,Kunden_id,Artikel_ID)values(BESTELLDATUM,Menge,Kunden_id,Artikel_ID)

else into transaktionen_error(BESTELLDATUM,Menge,Kunden_id,Artikel_ID)values(BESTELLDATUM,Menge,Kunden_id,Artikel_ID)

selectBESTELLDATUM,BESTELLDATUM_DATUM_CHECK,MENGE,MENGE_NUMBER_CHECK,KUNDEN_ID,KUNDEN_ID_NUMBER_CHECK,ARTIKEL_ID,ARTIKEL_ID_NUMBER_CHECK

fromtmp_transaktionen;

Messungselect count(*) from transaktionen_ok;select count(*) from transaktionen_error;select count(*) from tmp_transaktionenwhere Bestelldatum_Datum_check = 0;

Gesamtlaufzeit bei 1 Million Sätze inweniger als 3 Sekunden(auf Laptop – DB , ohne Parallelisierung)


275

Prüfungen über die CAST-und TO_xxx-Funktionen

select * from D_KUNDE k, ext_log_file swhere k.KUNDEN_ID = CAST(s.cust_id AS NUMBER DEFAULT NULL ON CONVERSION ERROR)

• Analog gibt es Prüfungen für

– TO_NUMBER

– TO_BINARY_FLOAT

– TO_DATE

– TO_TIMESTAMP

– TO_TIMESTAMP_TZ

– TO_DSINTERVAL

– TO_YM_INTERVAL


276

LISTAGG – Formatieren eines überlangen Outputs

SELECT

g.country_region,

LISTAGG(c.cust_first_name||' '||c.cust_last_name, ',' ON OVERFLOW TRUNCATE '...' WITH COUNT)

WITHIN GROUP (ORDER BY c.country_id) AS Customer

FROM customers c, countries g

WHERE g.country_id = c.country_id

GROUP BY country_region

ORDER BY country_region;

…


AA 34 dddf KD_11Satz12

DFG 64 dloidf KD_22Satz13

erf 78 ghzf KD_33Satz14

1

Log.Business Schlüssel (Alternate Unique)

Stamm Info

sdfg 4456 llkof KD_44Satz15

Stamm Info Stamm Info

2 Stamm Info Stamm Info Stamm Info




KD_11

KD_22

KD_33

KD_44

KD_55

6 Stamm Info Stamm Info Stamm InfoKD_66

Künstl. Schlüssel (Primary Key)

DFG 64 dloidf1

DFG 64 dloidf2

erf 78 ghzf3

sdfg 4456 llkof4

Log.Business Schlüssel

Dimension

Fakten / Bewgungsdaten

Bewegungsdaten

Join Lookup

Umschlüsseln mit Key Lookup

277


Native Support für Pivot und Unpivot

SALESREP Q1 Q2 Q3 Q4

---------- ----- ----- ----- -----

100 230 240 260 300

101 200 220 250 260

102 260 280 265 310

SALESREP QU REVENUE

---------- -- ----------

100 Q1 230

100 Q2 240

100 Q3 260

100 Q4 300

101 Q1 200

101 Q2 220

101 Q3 250

101 Q4 260

102 Q1 260

102 Q2 280

102 Q3 265

102 Q4 310

Sinnvoller Einsatz im Rahmendes ETL-Prozesses

278



select * from quarterly_sales

unpivot include nulls

(revenue for quarter in (q1,q2,q3,q4))

order by salesrep, quarter ;

QUARTERLY_SALES

SALESREP Q1 Q2 Q3 Q4

---------- ----- ----- ----- -----

100 230 240 260 300

101 200 220 250 260

102 260 280 265 310

SALESREP QU REVENUE

---------- -- ----------

100 Q1 230

100 Q2 240

100 Q3 260

100 Q4 300

101 Q1 200

101 Q2 220

101 Q3 250

101 Q4 260

102 Q1 260

102 Q2 280

102 Q3 265

102 Q4 310


279



SALESREP 'Q1' 'Q2' 'Q3' 'Q4'

---------- ----- ----- ----- -----

100 230 240 260 300

101 200 220 250 260

102 260 280 265 310

SALES_BY_QUARTER

SALESREP QU REVENUE

---------- -- ----------

100 Q1 230

100 Q2 240

100 Q3 160

100 Q4 90

100 Q3 100

100 Q4 140

100 Q4 70

101 Q1 200

101 Q2 220

101 Q3 250

101 Q4 260

102 Q1 260

select * from sales_by_quarter

pivot (sum(revenue)

for quarter in ('Q1','Q2','Q3','Q4'))

order by salesrep ;


280


• Bereitstellung in Form von Materialized Views

– Spart einen separaten ETL-Lauf

– Flexibler, weil nur 1 SQL-Kommando nötig

– Geht zu Lasten der Dokumentation

• Mit Partition Change Tracking die Aktualisierung der MAVs steuern

– Auch andere Refresh-Mechanismen nutzen

Aggregate bilden

281


Multiple Inserts

INSERT ALL

WHEN STATUS = 'P'‚

THEN INTO WH_TRANS_PRIVAT

(BESTELLMENGE,KUNDENCODE,BESTELL_TOTAL,STATUS)

VALUES

(BESTELLMENGE$1,KUNDENCODE$1,BESTELL_TOTAL$1,STATUS)

WHEN STATUS = 'F'‚

THEN INTO WH_TRANS_FIRMA

(BESTELLMENGE,KUNDENCODE,BESTELL_TOTAL,STATUS)

VALUES

(BESTELLMENGE$1,KUNDENCODE$1,BESTELL_TOTAL$1,STATUS)

SELECT WH_TRANSAKTIONEN.BESTELLMENGE BESTELLMENGE$1,

WH_TRANSAKTIONEN.KUNDENCODE KUNDENCODE$1,

WH_TRANSAKTIONEN.BESTELL_TOTAL BESTELL_TOTAL$1,

WH_TRANSAKTIONEN.STATUS STATUS

FROM

WH_TRANSAKTIONEN WH_TRANSAKTIONEN

WHERE

(WH_TRANSAKTIONEN.STATUS = 'P‚ /*SPLITTER.PRIVATKUNDEN*/)

OR

(WH_TRANSAKTIONEN.STATUS = 'F‚ /*SPLITTER.FIRMENKUNDEN*/);

282


MERGE INTO "Kunde_TGT" USING

(SELECT

"KUNDEN_STAMM"."KUNDENNR" "KUNDENNR",

"KUNDEN_STAMM"."VORNAME" "VORNAME",

"KUNDEN_STAMM"."NACHNAME" "NACHNAME",

"KUNDEN_STAMM"."STATUS" "STATUS",

"KUNDEN_STAMM"."STRASSE" "STRASSE",

"KUNDEN_STAMM"."TELEFON" "TELEFON",

"KUNDEN_STAMM"."TELEFAX" "TELEFAX„

FROM "KUNDEN_STAMM" "KUNDEN_STAMM") MERGE_SUBQUERY

ON ( "Kunde_TGT"."KUNDENNR" = "MERGE_SUBQUERY"."KUNDENNR")

WHEN NOT MATCHED THEN

INSERT

("Kunde_TGT"."KUNDENNR",

"Kunde_TGT"."VORNAME",

"Kunde_TGT"."NACHNAME",

"Kunde_TGT"."STATUS",

"Kunde_TGT"."STRASSE",

"Kunde_TGT"."TELEFON",

"Kunde_TGT"."TELEFAX")

VALUES

("MERGE_SUBQUERY"."KUNDENNR",

"MERGE_SUBQUERY"."VORNAME",

"MERGE_SUBQUERY"."NACHNAME",

"MERGE_SUBQUERY"."STATUS",

"MERGE_SUBQUERY"."STRASSE",

"MERGE_SUBQUERY"."TELEFON",

"MERGE_SUBQUERY"."TELEFAX")

WHEN MATCHED THEN UPDATE

SET

"VORNAME" = "MERGE_SUBQUERY"."VORNAME",

"NACHNAME" = "MERGE_SUBQUERY"."NACHNAME",

"STATUS" = "MERGE_SUBQUERY"."STATUS",

"STRASSE" = "MERGE_SUBQUERY"."STRASSE",

"TELEFON" = "MERGE_SUBQUERY"."TELEFON",

"TELEFAX" = "MERGE_SUBQUERY"."TELEFAX";

MERGE-Funktion

• Funktion MERGE dient dem gleichzeitigen INSERT und UPDATE

• Basierend auf dem Matching des definierten Schlüssels (ON-Klausel)

• Auch DELETE-Operationen möglich

283


If a = b...Update...Case...

CursorFetchLoop

Funktion

Table_Function( )

INSERT INTO Table

SELECT Feld1, Feld2

FROM

Mengenbasierte Verarbeitung

• Schnelle Verarbeitung (Pipelined)

• Objekttechnik

• Parallelisierung

• Mehrere Rückgabewerte und Einzelrückgaben

• Cursor als Input

• Schachtelbar

Return Table

pipe row(record Type)Variante 1

Variante 2

Trotz Programmierung

284


drop type Bestellung_X_t;

create type Bestellung_X_t as object (

BESTELLNR NUMBER(10),

KUNDENCODE NUMBER(10),

BESTELLDATUM DATE,

LIEFERDATUM DATE,

BESTELL_TOTAL NUMBER(12,2),

Fehler_Datum DATE);

drop type Bestellung_X_t_table;

create type Bestellung_X_t_table

as TABLE of Bestellung_X_t;

create or replace package cursor_pkg as

type Bestellung_t_rec IS RECORD (

BESTELLNR NUMBER(10),

KUNDENCODE NUMBER(10),

BESTELLDATUM DATE,

LIEFERDATUM DATE,

BESTELL_TOTAL NUMBER(12,2));

END;

DefinitionRecord-Type

DefinitionNested-Table aufder Basis des Rekord-Types

DefinitionCursor als Typdes Übergabeparameters

Die Hilfstypen für Daten und Cursor

285


create or replace function f_Bestellung_X(cur cursor_pkg.refcur_t)RETURN Bestellung_X_t_table IS

BESTELLNR NUMBER(10);KUNDENCODE NUMBER(10);BESTELLDATUM DATE;LIEFERDATUM DATE;BESTELL_TOTAL NUMBER(12,2);Fehler_Datum DATE;ORDER_ID NUMBER(10);

objset Bestellung_X_t_table := Bestellung_X_t_table();i number := 0;beginLOOP

-- read from cursor variable FETCH cur into BESTELLNR,KUNDENCODE, BESTELLDATUM,LIEFERDATUM,BESTELL_TOTAL,ORDER_ID;

-- ext when last row EXIT WHEN cur%NOTFOUND; i := i+1;if substr(to_char(LIEFERDATUM,'YYYY.MM.YY'),1,4) >2002 then

Fehler_Datum := to_date('9999.12.12','YYYY.MM.DD');else Fehler_Datum := LIEFERDATUM;End if;objset.extend;objset(i) :=

Bestellung_X_t(BESTELLNR,KUNDENCODE, BESTELLDATUM,LIEFERDATUM,BESTELL_TOTAL,Fehler_Datum);END LOOP;

CLOSE cur;Return objset;

END;

Übernahme von Ausgangssätzen als Cursor

Definieren einer Nested-Table-Strukturfür die spätere Rückgabe.

Lesen aus Cursor

Erweitern Nested-Table um einenSatz und Überführen eines Satzes indie Nested-Table

Rückgabe der kompletten Tabelle an das aufrufende SELECT-Statement(Alternative zu PIPE).

286


insert into bestellung_X

select * from

TABLE(f_Bestellung_X(CURSOR(SELECT * from Bestellung)))

select * from

TABLE(f_bestellung(CURSOR(SELECT * from Bestellung)))

select count(*) from

TABLE(f_bestellung(CURSOR(SELECT * from Bestellung))

Beispielaufrufe

287


Monat 10

Monat 11

Monat 12

Monat 13

Faktentabelle

Zeit

Region

Financial

Production

Human Res.

Store

Supplier

Marketing

Service

Neuer Monat

P1P2P3P4

4

4

8

9

Z1Z2Z3Z4

Temporäre Tabelle

Parallel Direct Path INSERT(Set Based) CREATE TABLE AS SELECT

(CTAS)CREATE Indizes / Statistiken anlegenEXCHANGE Tabelle

Partition Exchange Loading (PEL)

DROP

PARTITION

• Unvergleichbar schnell!

288


Partition Exchange Loading (PEL)-- Leere Partition an Zieltabelle hinzufügen

ALTER TABLE Bestellung ADD PARTITION "Nov08"

VALUES LESS THAN (to_date('30-Nov-2008','dd-mon-yyyy'));

-- Neue leere temporäre Tabelle erstellen

CREATE TABLE Bestellung_temp AS

SELECT * FROM Bestellung WHERE ROWNUM < 1;

-- Inhalte laden

INSERT INTO "PART"."BESTELLUNG_TEMP"

(BESTELLNR, KUNDENCODE, BESTELLDATUM, LIEFERDATUM, BESTELL_TOTAL, AUFTRAGSART, VERTRIEBSKANAL)

VALUES ('2', '3', TO_DATE('23.Nov.2008', 'DD-MON-RR'),

to_date('23.Nov.2008', 'DD-MON-RR'), '44', 'Service', '6');

Commit;

-- Erstellen Index auf temporäre Tabelle

CREATE INDEX Ind_Best_Dat_Nov ON Bestellung_temp ("BESTELLNR") NOLOGGING PARALLEL;

-- Temporäre Tabelle an die Zieltabelle anhängen

ALTER TABLE Bestellung EXCHANGE PARTITION "Nov08“ WITH TABLE Bestellung_temp

INCLUDING INDEXES WITHOUT VALIDATION;

2

3

4

5

1

289


Exchange Partition


User View Layer


November

Mai

Juni

Juli

August

September

Oktober

Tmp_table

Älteste

Alter tableadd partition

Archivieren(drop partition)

CTAS

Checks

Direct Path

Alter table exchange partition

290


Aufbau Fakten-Tabellen


User View Layer


November

Mai

Juni

Juli

August

September

Oktober

ÄltesteArchivieren(drop partition)

CTASAlter table

exchange partitionTmp_table

Tmp_tableNovember

Juni

Juli

August

September

Oktober

Fact-Table

Tmp_tableCTAS

Checks

Direct Path

Alter table exchange partition

291


Deltadaten Extrahieren

1

3

2

4

5

6

Änderungsdatum

Trigger

Deltabildungüber MINUS

Logminer

Streams

Golden Gate

LogFile

LogFile

LogFile

Table

Table

Table Table

Table

TableQueue

OLTP DWH

TableQueue

QueueTable

Queue Table

292


Einlesetechniken Vorsysteme

Oracle

NonOracle

EBCDICASCII

Applikationz. B.

SAP R/3

SQL-Loader

External Table

Database Link

Transportable TS

Datapump

ODBC

JDBC

Gateway

AP

I

API CALL

OracleDWH

SQL

SQLSQLSQL

SQL

SQL

BS CopyBS Copy

Direct Save

293


Nicht so ....sondern


T

T

T

T

T


T

Logik so früh wie möglichWarum?

1:1

1:1

1:1

1:1

CTAS


Große unveränderte Tabellen liegen lassen

Zugriff auf beide Schichten

Security mit Bordmittel anstatt durch Kopieren lösen

Minimales Bewegen

BD

D

DD


User View Layer

B

F

PEL

295


Weitere Einflussfaktoren und Techniken

• Parallelisierung -> abhängig von Hardware-> direktes Steuern über Hints

• Aktuelle Statistiken -> Source Tabellen-> auch während des ETL-Laufes

• Ausnutzen des Cache-Effektes

-> Organisieren der Abarbeitungsreihenfolge-> Eventuell Query-Result-Cache nutzen

• Vermeiden von großen Join-Tabellen

-> eventuell kleine Join-Tabellemit wenigen Spalten


Weitere Einflussfaktoren und Techniken

• Schnelle mengen-basierte Prüfungen kommen zuerst, teuere Prüfungen (Feld-Prüfungen) zuletzt durchführen

• Möglichst viel Hauptspeicher für Join-Operationen mit großen Tabellen

• Sort-Area-Size hoch setzen

• Blocksize auf 16 bzw. 32 K

• PCTfree auf Null setzen

• Partition Change Tracking (PCT) für inkrementelles Refresh der MAVs

297


Keine unnötige Daten-Transporte ...

Enterprise Information

Layer


User View Layer

User View Layer

User View Layer

1:1

1:1

1:1

Vorsystem mitVorrechnerVorsystem

1:11:1

Externe ETL-Server


Lade-Transaktionssteuerung innerhalb der Datenbank

299


• Markieren von Sätzen eines Ladelaufs in zusätzlichen Feldern

– Ladelauf-Nummer, Ladelauf-Datum, ...

– Zurückrollen durch langsames Einzel-DELETE

• Arbeiten mit Partitioning– Aufbau einer neuen Partition unabhängig von der Zieltabelle

– Schnelles DROP PARTITION im Fehlerfall

– Einfachste und schnellste Variante

• Flashback Database / Table / Query– Transaktions-genaues Zurückrollen

– Flashback DB benötigt zusätzlichen Plattenplatz

Transaktionssteuerung / -rücksetzung

1

2

3

300


301

Flashback

ETL / ODIFlashback Recovery Area

• Steuerung über

– SCN ( Sequence Change Number / Log Archiving)– Zeit (Timestamp)– Restore Point

Zeit SCN Restore Point

Log


Flashback Technologie in der Datenbank

• Flashback Table

• Flashback Drop

• Flashback Query

• Flashback Versions Query

• Flashback Transaction Query

• Flashback Database

• Flashback Data Archive

SELECT * FROM employees AS OF TIMESTAMP

TO_TIMESTAMP('2004-04-04 09:30:00', 'YYYY-MM-DD HH:MI:SS')

WHERE last_name = 'Chung';

SELECT versions_startscn, versions_starttime,

versions_endscn, versions_endtime,

versions_xid, versions_operation,

last_name, salary

FROM employees

VERSIONS BETWEEN TIMESTAMP

TO_TIMESTAMP('2008-12-18 14:00:00', 'YYYY-MM-DD HH24:MI:SS') AND

TO_TIMESTAMP('2008-12-18 17:00:00', 'YYYY-MM-DD HH24:MI:SS') WHERE

first_name = 'John';

Flashback table x to scn 16552768;

SELECT xid, operation, start_scn,

commit_scn, logon_user, undo_sql

FROM flashback_transaction_query

WHERE xid = HEXTORAW('000200030000002D');

Flashback Database to scn 16552768;

Flashback Database AS OF TIMESTAMP

TO_TIMESTAMP('2004-04-04 09:30:00', 'YYYY-MM-DD HH:MI:SS') ;

302


Flashback Database

• Flashback Database

– Erstellen der Fast (Flash) Recovery Area

– Restart Database ( mount exclusive, wenn DB <11.2)

– SQL> ALTER DATASE FLASHBACK ON;

– SQL> ALTER SYSTEM SET db_flashback_retention_target = <number_of_minutes>;

– SQL> ALTER DATABASE OPEN;

• Restore Points (ab 11.2 im laufenden Betrieb)

– create restore point PRE_LOAD;

– create restore point PRE_LOAD guarantee flashback database; (impliziert das Anlegen von Flashback Logs)

– drop restore point PRE_LOAD;

• Anwendung eines Restores nur im DB Mount-Status

– flashback database to restore point PRE_LOAD;

303


Security und Mandantensteuerung im Data Warehouse

304


Service

Logistik

Controlling

Vertrieb

Marketing

Einkauf

Referenzdaten (extern) (10%)Stammdaten (10%)Bewegungsdaten / Transaktionen (80%)


User ViewLayer

IntegrationLayer

Sicherheit in der Datenbank

Marketingsicht

Kundenhistorie

ServicekundeProdukte&Trends

Logistikaufwandfür einen Kunden

Profitabilität

Sozialsituation

Profitabilität

Logistikaufwand

Servicekunde

Marketingsicht

Kundenhistorie

Produkte&Trends

KundeMJ

A

C

A

Q

L

Vorberechnete Kennzahlen

Data MiningStatistikdaten

Oracle R

BI Plattform

ODBC

BI-Anwendungen werden im Schnitt alle 4 Jahre ausgetauscht

Oft laufen mehrere BI-Anwendungen parallel

305


DATA WAREHOUSE

306

Zwei Level des Zugriffs-Monitoring

Statementlevel. all

statementsin a sessionsany objects

GrantingPriviligesactivities

Objectlevel

(update, insertdelete, select)

By session

By access

X

X

X

X

X

X

1) Standard Auditing 2) Fine Grained Auditing

Monitoring of all activities byUser by session, by object.- Action based auditing(e. g. analysing the predicateexample: value > 100000)

- all detailed commands- Timestemps-trials and successes- Additional triggers- notifications and other actions

EXECUTE DBMS_FGA.ADD_POLICY( -

object_schema => 'DWH‘ , -

object_name => 'F_UMSATZ’, -

policy_name => 'Chk_F_Umsatz', -

statement_types => 'SELECT’ , -

enable => TRUE);

Audit select on F_UMSATZ;


DATA WAREHOUSE

307

Umsatz

Kunde

Produkte

Channels

Zeit

Umsatz

Kunde

Produkte

Channels

Zeit

Umsatz

Kunde

Produkte

Channels

Zeit

Umsatz

Kunde

Produkte

Channels

Zeit

Umsatz

Kunde

Produkte

Channels

Zeit

Umsatz

Kunde

Produkte

Channels

Zeit

Umsatz

Kunde

Produkte

Channels

Zeit

Mandant 1Mandant 2

Mandant 3Mandant4

Mandant 5Mandant 6

Nicht so... sondern so...

Alle Mandantenin einer Tabelle

Nur einmal pflegen und verwalten!


Fine Grained Security on Row level

308

Umsatz

Kunde

Produkte

Channels

Zeit

User_Table

User: DataMart1

Add / DROP Policy

Build Predicate Procedure

Pr

ed

ica

te

User 2

select

sum(UMSATZ)

from umsatz;

Set User Context

User 3

select

sum(UMSATZ)

from umsatz;

Set User Context

C o n t e x t

Sieht nur Partner-Umsatz

PartnerCatalogInternetDirect Sales Sieht nur

Katalogwaren-Umsatz

Zugreifende UsersZu lesenden Objekte


309

CREATE OR REPLACE TRIGGER vpd_init_trig AFTER LOGON ON DATABASEBEGIN

EXECUTE IMMEDIATE 'DROP CONTEXT channel_infostr'; EXECUTE IMMEDIATE 'CREATE CONTEXT channel_info using user_context'; system.User_context.select_user_Channel;EXCEPTIONWHEN NO_DATA_FOUND THEN null;end;

Logon-Trigger

create or replace package User_context asProcedure select_user_Channel ;end;/Create or replace Package Body User_context as Procedure select_user_Channel isChannelnum number;begin

select channel_id into Channelnum from area1.user_table whereupper(User_name) = sys_context('USERENV', 'SESSION_USER');dbms_session.set_context('channel_info', 'channel_num',Channelnum);

end;end;

Erstellen des Kontextes

create or replace package channel_security asfunction channelnum_sec (A1 VARCHAR2, A2 varchar2)return varchar2;end;/create or replace package body channel_security as function channelnum_sec (A1 VARCHAR2, A2 varchar2)return varchar2isd_predicate varchar2(2000);v_channel_id number;begin

select sys_context('channel_info','channel_num') into v_channel_id from DUAL;

d_predicate := 'SALES.CHANNEL_ID = '||v_channel_id||' or '||v_channel_id||' = 10';return d_predicate;end;end;/

exec dbms_rls.drop_policy('AREA1','SALES','CHANNEL_POLICY');

exec dbms_rls.add_policy('AREA1','SALES','CHANNEL_POLICY','AREA1','channel_security.channelnum_sec','SELECT');

Aktivieren der Policy

Definieren der Policy

Auf der Seite des zugreifenden UsersAuf der Seite des zu lesenden Objektes


310

Label Security

• Regelgestützter Zugriffsschutz auf Record-Ebene

Data Label Components Label Security Policies User Labels

Maximum / Minumum / Default / Row Level

Read / Write Compartments

Read / Write GroupsBis zu 9999 Bis zu 9999 Bis zu 9999


311

Beispiel über die Wirkungsweise

Sätze einer Tabelle werden „gelabelt“

Benutzer erhalten „User Labels“


Redaction und Encryption

312


Encryption

313

• Schutz vor nicht autorisiertem Lesen von Datenträgern, Tablespaces, Files etc.

• Findet im Verlauf der DB-Installation statt

• Online – Encryption von Tablespaces

• Ausnutzen von CPU-basierter Hardware (Intel + SPARC Plattform)

– Performance

• Ausnutzen der Smart-Scan-Prozessen in Storage-Servern (Exadata)

• Separates Vorhalten von Encryption Schlüssel


314

Redaction (Maskierung)

• Selektives Maskierung von sensiblen Daten als Schutz vor unberechtigtem Lesen

• SQL-Leseoperation und die gespeicherten Daten bleiben unverändert

– Daten werden erst nach dem Lesevorgang und unmittelbar vor der Anzeige der Daten für den Benutzer „überschrieben“

– -> optimal für Performance

• Varianten– Full

– Partial (*)

– Regular Expressions


315

Redacting Data - Beispiel

Die Daten selbst werden nicht verändert.Die Maskierung erfolgt erst unmittelbar vor der Anzeige.

In diesem Bsp. Werde die ersten 7 Zeichen der Column ‘CUSTID‘ mit der Ziffer ‘9‘ maskiert.

Die Spalte LAST_NAME aus der customer-Tabelle wurde ab dem 3. Zeichen mit ‘*‘ maskiert.


Sandboxes

316


317

Sandboxes

• Separate Arbeitsumgebungen für Fachabteilungen zum Ausprobieren, Planen

• In der Regel Kopien (Cloning) aus einem zentralen bzw. gepflegten und abgesicherten Datenbestand

• Eigenverantwortung der Fachanwender für die neuen Daten

• Punktuelles Zurückführen von neuen Arbeitsergebnissen, z. B. Planungsdaten in zentralen Bestand

Container Datenbank (CDB)

Pluggable Database (PDB)Seed Database (PDB)

Multitenant Architektur


Minimierung von Kosten und Verwaltungsaufwand durch Pluggable Database (PDB)

Oracles Multitenant Architektur

GL OE

APSeparate Datenbanken (PDB) für unterschiedlicheAnwendungen• Im DW§H-Kontext sinnvoll für Sandbox-

Anforderungen• Schnelles Erstellen (als Clones)• Portability (via pluggability)

Verwaltungsaufgaben können gemeinsachftlichzentral auf Container-Datenban-Level erfolgen(Patches, Upgrades, HA, Backup)

Shared memory und Background Prozesse• Mehrere Anwendungen pro Server

Complementary to VMs

318


Oracle Multitenant

319

Architektur mit Oracle 12c Release 1

SeedPDB$SEED

Root (CDB$ROOT)

Pluggable Databases (PDBs)


Oracle Multitenant

320

Architektur mit Oracle 12c Release 2

SeedPDB$SEED

Application SeedPDB$SEED

Application Root Application Root

Root (CDB$ROOT)

Application PDBs

PDBs and Application Containers


Sandbox-Konzept mit Multitenancy Application Container

• Erstellen einer Pluggable Datenbank“Data Mart-Ausschnitt” alsApplication Container

• Einrichten einer Master-Definition Data Mart / Datenausschnitt CDB(Root)

• Erzeuge eine Seed-Datenbank

• Erstelle neue Pluggable Datenbankenals Sandbox für jedes ProjektData

MartAus-

schnitt

Data Mart / Datenausschnitt CDB

SandboxSeed

SandboxProj. 1

SandboxProj.2

SandboxProj. 3


321


Backup für das Data Warehouse

322


Grundgedanken

• Administration, z. B. Backup, ist Warehouse meistens viel zu teuer, weilOLTP-Maßstäbe angelegt werden

• Ein eigenes Backup – Konzept für das Data Warehouse

• Nur das sichern, was sich wirklich verändert hat

• Höher Ausfallzeiten planen

• ETL-Strecken als Backup-Hilfsmittel mit berücksichtigen

• Stage und Data Marts aus dem Backup herausnehmen

• Read-Only-Tablespaces und Partitions mit einplanen

323


RMAN- Backup-Verfahren: Was wird gesichert?

R R

BS S S D

D

DD


T

T

T

T: TransfertabellenR: Referenztabellen

S: StammdatenB: BewgungsdatenD: DimensionenF: Fakten

B

F

Keine SicherungInkremental Backup nur für Referenz- und Stammdaten

Keine Sicherung,wenn Data Martskomplett neu aufgebautWerden große

Bewegungsdatentabellenam besten nach Abschluss desETL-Laufes sichern

RMAN(Incremental)

RMAN (Incremental)

324


Logging / Nologging

• Wird der Archivelog-Modus benötigt oder nicht?

• Relevant für

– Backup

– DataGuard / Golden Gate

– Flashback

• Wichtigster Punkt ist: BACKUP

– Abhängig vom Backup-Konzept

325


Auswirkungen auf das Backup-Konzept

• Plattensicherung

– Oft einfach, weil eingespielte Verfahren

– Grosser Ressourcenverbrauch

• Alle (DWH-Bereiche) werden gesichtert -> großer Platzbedarf

• Teure Backup-Software

– Nicht immer sicher, weil korrupte Datenbank-Blöcke nicht erkannt werden können

– Man kann ohne Archivlog fahren -> ETL schneller und einfacher

• Sicherung mit RMAN

– Ressourcen-günstigstes Verfahren

– Man muss mit Archivlog fahren

• ETL etwas langsamer

• Massenloads mit Driect Path Load (NOLOGGING) -> separate Sicherung

326


Multi-strukturierte Daten mit JSON

327


328

JSON (Java Script Object Notation)

• Standardisiertes Format

– ECMA-404 (JSON Data Interchange Format)

– ECMA-262 (ECMAScript Language Specification, third edition)

• Leichteres Format als XML– Weniger Datenmenge /Overhead

– Einfacher Umgang

• Besonders beliebt bei noSQL-DB- Java – Entwicklern

• Im Hadoop-Umfeld weit verbreitet

• Ab Oracle 12.1.0.2 direkt in der Datenbank


329

Beispieltabelle mit JSON-Spalte

create table Web_Log

( id raw (16) not null,

date_loaded TIMESTAMP WITH TIME ZONE,

Log_Record VARCHAR2(350)

CONSTRAINT log_ensure_json CHECK (Log_Record IS JSON))

Diese Spalte nimmt die JSON-Sätze auf.Die Prüfung der korrekten JSON-Notation übernimmt ein spezieller JSON-Constraintim Verlauf des INSERT.

{“Spalten-Name-1“ : wert, “Spalten-Name-2“ : wert, “Spalten-Name-3“ : wert,…}


330

Multi-Strukturierte InformationenINSERT INTO Web_Log_arrayVALUES (SYS_GUID(),

SYSTIMESTAMP,'{"wl_rec_id" : 1600,"wl_ip_Adr" : "168.192.1.10","wl_dns" : "MP-AM5643","wl_start_date" : "11-08-2014:23:21",

"wl_end_date" : "11-08-2014:25:18","wl_ses_id" : "77763576423",

"wl_Ses_anz_sec" : "10","wl_status" : "ACK"}');

INSERT INTO Web_Log_arrayVALUES (SYS_GUID(),

SYSTIMESTAMP,'{"wl_rec_id" : 1600,"wl_ip_Adr" : ["168.192.1.10","168.192.1.11"],"wl_dns" : "MP-AM5643","wl_start_date" : "11-08-2014:23:21",



SQL> select wa.Log_Record.wl_ip_Adr from Web_Log_array wa;WL_IP_ADR------------------------------------------------------------------"168.192.1.10"["168.192.1.10","168.192.1.11"]{"ip":"168.192.1.10","sub":"255.255.255.0"}

INSERT INTO Web_Log_arrayVALUES (SYS_GUID(),

SYSTIMESTAMP,'{"wl_rec_id" : 1600,"wl_ip_Adr" : {"ip" : "168.192.1.10", "sub" : "255.255.255.0"},"wl_dns" : "MP-AM5643","wl_start_date" : "11-08-2014:23:21",



SQL> select wa.Log_Record.wl_ip_Adr.sub from Web_Log_array wa;WL_IP_ADR---------------------------------------------------------------"255.255.255.0"

1

2

3


331

Generierung von JSON-Files aus der Oracle – DB herausSELECT json_object(

'a.artikel-name' VALUE Artikel_Name || ' ' || a.gruppe_name,

'hoher_umsatz' VALUE CASE WHEN u.umsatz < 1000 THEN 'false' ELSE 'true'

END FORMAT JSON)

FROM

D_ARTIKEL a,F_UMSATZ_2015 u

where

a.artikel_id = u.artikel_id;

s. a. Funktionen:JSON_OBJECTJSON_ARRAYJSON_OBJECTAGGJSON_ARRAYAGG


332

Ab 18c vollständige Typen-Unterstützung

• AB 18c auch CLOB BLOB – Unterstützung

• Damit sind beliebige Value-Objekte abbildbar

– Bilder

– Digitalisierte Tondokumente

– Filme

– Scoring-Modelle

18c


Gründe fürJSON-optimaleDatenhaltung

▪ SQL

▪ Input/update/delete…

▪ Komplexe Datenstrukturen +

Transaktionssicherheit

▪ Row/Column -Security

RelationalNoSQL

▪ Schnelle Verarbeitung von

Einzelinformationen

▪ Transaktionsorientiert

▪ Einfache Daten

Key ValueKey ValueKey ValueKey ValueKey Value

PythonJava

SQL

Column Row

JSON-Format ist in beiden Welten machbar

Es muss nicht immer noSQL sein

333


Die optimale Hardware für das Data Warehouse

334


Optimale („Balanced“) Konfiguration

• Anzahl CPU‘s

• Größe des Hauptspeichers

• Anzahl Platten

• Anzahl Disk Controller

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

335


• 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

Die Hardware Umgebung – Storage

336


Monitoring Data Warehouse

337


• 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

Messung von IO-Durchsatz

338


Einfache Schätzmethode zur Lesegeschwindigkeit

SELECT table_name, num_rows, blocks, blocks*8 KB,blocks*8/1000 MB,blocks*8/1000000 GB FROM user_tables;

select tablespace_name, block_size from dba_tablespaces;TABLESPACE_NAME BLOCK_SIZE

------------------------------ ----------

MON_G 8192

MON 8192

MON_D 8192

MON_E 8192

MON_F 8192

TABLE_NAME NUM_ROWS BLOCKS KB MB GB

------------------------------ ---------- ---------- ---------- ---------- ----------

BESTELLUNG_PART_RANGE 163840000 962355 7698840 7698,84 7,69884

BESTELLUNG_PART_RANGE_4 163840000 962355 7698840 7698,84 7,69884

select count(*) from bestellung_part_Range_4; -- liest komplette TabelleCOUNT(*)

----------

163840000


Ergibt ~0,25 GB pro Sekunde Lesegeschwindigkeit(Achtung Blöcke eventuell nicht voll, daher geringer )

select 7.7/31 from dual;SQL>

7.7/31

----------

,248387097

Blockgröße feststellen

Anzahl Blöcke/Anzahl Bytes

Messen der Lese-geschwindigkeitBerechnung desDurchsatzes

339


• Einfaches Tool

• Bestandteil des Ressourcen Managers

• Wird aus der DB heraus aufgerufen

Calibrate_IO

SET SERVEROUTPUT ON

DECLARE

lat INTEGER;

iops INTEGER;

mbps INTEGER;

BEGIN

-- DBMS_RESOURCE_MANAGER.CALIBRATE_IO (<DISKS>, <MAX_LATENCY>,

iops, mbps, lat);

DBMS_RESOURCE_MANAGER.CALIBRATE_IO (2, 10, iops, mbps, lat);

DBMS_OUTPUT.PUT_LINE ('max_iops = ' || iops);

DBMS_OUTPUT.PUT_LINE ('latency = ' || lat);

dbms_output.put_line('max_mbps = ' || mbps);

end;

/

max_iops = 73

latency = 12

max_mbps = 20

340


Automatic Database Diagnostic Monitor (ADDM) und AWR

sysaux

User 1

User 2

AWRstündlich

ADDM Findings1……nn%2……nn%3……nn%…….

Statistics_level TYPICAL -> ONBASIC -> OFF

8 Tage lang

Recommendations- Hardware- Init-Parameter- Space Konfig.- Performance Advisor

Action

1

2

3

OEMAddmrpt.sql

Rationale

4

DBMS_ADVISOR Package

MMON-Process

use

SQL Tuning Advisor

Undo Advisor Segement Advisor

AWR-Report

341


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

342


Verwendungsinformationen speichern

User

Tabname Gelesen_Von_User Anzahl_Read_IO Lese_Datum

Tabelle DWH-Zugriffshistorie

343


344

Daten-Owner und Verursachung von Aufwand

D_ZEIT



D_ARTIKEL

D_VERTRIEBSKANAL


F_UMSATZ

ARTIKEL_IDKUNDEN_IDZEIT_IDREGION_IDKANAL_IDUMSATZMENGEUMSATZ_GESAMT

PK

PK

PK

PK

FK

FK

FK

FK

FK

PK: Btree Index

FK: Bitmap Index

D_Org_Unit

Org_unitOrg_Unit_Nr Mitarbeiter_Name Mitarbeiter_Nr

D_ZEIT


F_Usage_Count

Mitarbeiter_NrZEIT_IDSegment_NrSparten_OwnerChannel_OwnerRegion _OwnerCount_RecordAmount_Byte

SummeSpartensätzepro Tag

• Indirektes Dokumentieren von Verursachern für ein bestimmtes Datenvolumen

• Kriterien aus den Stammdaten ableiten• Tägliche Messung

SPARTEN_MANAGERSPARTE_NAME SPARTE_NR GRUPPE_NR GRUPPE_NAME ARTIKEL_NAMEARTIKEL_ID

D_Table

Segment_NrTable_NamePartition_Name


Datenwachstum dokumentieren

Segment_Nr

Anzahl_Zeilen

Anzahl_Byte

Comp_Faktor

Mess_Tag

• Täglich Messung

• Wachstumskurve

• Prognosemöglichkeit

• Star Schema analoge Darstellung

Index_Byte

D_ZEIT

JAHR_NUMMER QUARTALS_NUMMERMONATS_NUMMER WOCHE_DES_JAHRESWochen_Tag_Nr DATUM_TagTAG_DES_MONATS TAG_DES_JAHRES Mess_Tag

Tabellen_Name Segment_NameSegment_Type Partition_NameSegment_Nummer

D_Segment

345


346

Werden Tabellen und deren Daten genutzt

Segment_Nr

User_Name

Logical_Reads_TotalPhysical_Reads_TotalLogical_Reads_DeltaPhysical_Reads_Delta

Tag_Stunde

• Tägliche/stündlicheMessung

• Welche Segmente (Partitionen) werden genutzt

• History und Monitoring-Views*- dba_hist_seg_stat- dba_hist_seg_stat_obj- dba_hist_snapshot- v$sql_Monitor

• Star Schema analoge Darstellung

• Alternative:AUDIT select ON table-name

D_ZEIT

JAHR_NUMMER QUARTALS_NUMMERMONATS_NUMMER WOCHE_DES_JAHRESWochen_Tag_Nr DATUM_TagTAG_DES_MONATS TAG_DES_JAHRES Tag_Stunde

Tabellen_Name Segment_NameSegment_Type Partition_NameSegment_Nummer

D_Segment

Org_EinheitOrg_Einheit_NummerKostenstelleUser_Name

D_Org_User

* Siehe passende Skripte in TiF-Skripte-Sammlung


• Laufzeit-Kontrolle / ETL-Monitoring

– Gelesene/Geschriebene Sätze

– Ressource-Verbrauch (IO und Memory)

– Laufzeit

– Historischen Verlauf dokumentieren

– Trends ableiten

• Zuwachsmenge pro Tabelle– Historischen Verlauf dokumentieren

• Mengen-Kontrolle

– Beobachtung des tatsächlichen Platzverbrauchs im DWH

– Alerts

Aufgabenstellungen beim ETL-Monitoring

347


Metadaten im Data Warehouse

• Was sind Metadaten im DWH

• Pragmatische Lösungen der Metadaten-Herausforderung

• Synonymen- / Homonymen-Thematik

• Beschreibung von Kennzahlen

• Aufbau eines Glossars


348


349

Ziele

• Verständnis schaffen für Aufgabenstellung „Metadaten im Data Warehouse“

• Umschreiben des Aufgabenspektrums„Weg von den verkürzten Sichten“Metadaten als Lösung für eine Reihe von Herausforderungen

• Aufzeigen von Lösungswegen

• Entwickeln einer pragmatischen Sicht


Was sind Metadaten?

• Metadaten sind Beschreibungen jeglicher Art, die als Orientierung bei der Lösung von Aufgaben helfen

• Technische Metadaten• Strukturen• Herkünfte / Auswirkungen

• Fachliche Beschreibungen• Glossars• Kennzahlen / Definitionen / Formeln

• Katalogisierungsinformationen

• Listen, Synonyme

• Datenstatistiken / operationale Informationen über Zustände• Welche Stellen / Abt. haben wieviele Daten • Datenlieferstatistiken

• Beschreibungen zur Unterstützung des Information Life Cycle Management (ILM)• Welche Benutzergruppe / Abt benutzt/braucht

welche Daten• Welcher operative Prozess benötigt welche Daten• Welche Daten sind wann wie oft benutzt worden

350



User ViewLayer

(teils virtuell)

IntegrationLayer

DWH – Architektur: Was macht man wo?

MJ

A

C

A

Q

L

Vorberechnete Kennzahlen

• Dimensionen als Views• Fakten als In-Memory-Variante

von Core-Transaktionen• Kennzahlen-MAVs

physikalisch • R-Objekte physikalisch• JSON-Objekte physikalisch

R R

S S S

Referenz-datenStamm-daten

R

PartitionierteTransaktionsdatennur wenn sie abgefragt werden

OLTPSysteme

T T

TemporäreDaten

Operational Data(virtuell)

Disk-Daten In Memory

Data MiningStatistikdaten

Oracle RMulti-Strukturierte DatenHDFS / NoSQL

JSON JSON

JSON UnstructuredJSON Data

In

te

rn

e

Da

te

nE

xt

er

ne

Embedded Meta-Layer

351


Was könnte alles beschrieben / dokumentiert werden

Welche Berichte beinhalten welche Kennzahlen?

Welchem Prozess ist welche Kennzahl zugeordnet?

Welche Tabellen werden von welchen ETL-Prozessen gelesen?

Welches Ladeprogramm läuft wann und in welcher Abfolge?

Welche Regeln werden in welchen Mapping-Programmen geprüft?

Reporting-Modell

Welche Geschäftsobjektewerden bemessen?

Kennzahlen-Modell

Datenmodell

Data Quality Modell

Lineage / Impact – ETL-Modell

Workflow-Modell

352


353

Lösungen / Aspekte eines Metadaten-Tools

• Investition und Nutzen

• Organisatorischer Aufwand

• Entwicklungs-Aufwand

• Regelmäßiger Pflegeaufwand der Metadaten

• Schnittstellenanforderung

• Kosten/Nutzen-Kompromiss finden

• Mit überschaubarer einfacher Lösung beginnen=> Quick Wins suchen=> einfache erste Lösungen anbieten (z. B. Glossar)

• Kein „HauRuck“- Projekt

• Automatismen schaffen

• Falle: manuelle Pflege,automatische Scanner schaffen

Gute Lösung am Markt schwer zu finden. Vorallem die Aspekte: • Integration der verschiedenen Metadaten-Arten• Automatisiertes Pflegenwerden kaum erfüllt

=> Selbst entwickelte Lösung mit einfachen DB-Tabellen kann ein Kompromiss sein


354


Einfachste Lösung: Selbst gepflegte Datenbanktabellen

• Schnell und einfach zu implementieren

• Manueller Aufwand bei Erweiterungen

• Beziehungen zwischen Metadaten-Typen müssen über zusätzliche Beziehungstabellen abgebildet werden

• Metadaten-Abfragen, Strukturauflösungen (Herkünfte/Auswirkungen)müssen manuell erstellt werden

• Allerdings:

• Trotz regelmäßigem Änderungsaufwand: Metadaten-Struktur ändern sich relativ wenig

• Entscheidend sind die Automatismen zur Pflege der Metadaten: Datenbank-Tabellen und PL/SQL in der Oracle – DB ergänzen sich ideal und auch bei fertigen Tools muss man Schnittstellen meist programmieren

355


Entwurf und Weiterentwicklung eines integrierten Datenmodells im Kern-Data Warehouse

356



User ViewLayer

Entwurf und Weiterentwicklung eines integrierten DM

Bestehendes DatenmodellEntitäten und Attribute

E i n d e u t i g k e i t i m g e s a m t e n S y s t e m

Sicht Sicht

SichtSicht

Kennzahlen

Sicht Sicht

SichtSicht

Kennzahlen

+

• Abgleichen des neu festgestellten und bereits modellierten Informationsbedarfs gegenüber dem bereits bestehendenzentralen Datenmodell

• Abstimmaufwand

•

Bedeutung, Inhalt

BezeichnerWort, Name

Reales ObjektSachverhalt

• Themen- und sachgebietsbezogene Sprache

• Betonung individueller Sichten

• Unpräzise Ausdrucksweiseder Anwender

• Hohe Gefahr von Missverständnissenzwischen Anwender und IT

357



• Standardisierte Begriffe / Bezeichner

• Definition aller Datenobjekte (Sachverhalte, Kennzahlen)

• Lösung der Homonymen / Synonymen – Thematik– Informationen (Daten) sind nur ein einziges Mal in dem Gesamtsystem vorhanden

• Definieren der nötigen Granularität (Business Events)

• Bereithalten aller Informationen zum Aufbau von Auswertemodellen– Historisierung

– Schlüsselinformationen

– Hierarchisierungs-Informationen

358



User ViewLayer

Für welche Objekte besteht Handlungsbedarf

Sicht Sicht

SichtSicht

Kennzahlen

Sicht Sicht

SichtSicht

Kennzahlen

+

• Kennzahlen– Aus Vorsystem abgeleitet

– Innerhalb des DWH berechnet

• Bewegungsdaten– Alle Felder

• Stammdaten– Im Warehouse gebildete

künstliche Schlüssel

– alle Felder, die in das integrierte Modell einfließen

• Neu gebildete Felder

• Übernommen Felder

• Modifizierte Felder

R R

B

S S S B

BB

• Referenzdaten– Felder sollten als

„Fremdbestand“markiert sein

Werden zusätzlich beschrieben

359


IntegrationLayer

Herausforderung: Synonyme in den Vorsystemen

ErtragAnwendung A

Anwendung B

ErlösAnwendung C

Ertrag + Gewinn+ Erlös

Transformation

• Steht der Informationsbedarf fest, beginnt die Suche in den Quellsystemen

• Synonymität und Homonymität ist oft schon in den Vorsystemen angelegt

• Ähnlichkeitssuche über Feldinhalte

• Dokumentation:

• ETL-Tool Herkunfts-/Auswirkungsanalyse

• Repository-Referenzinformation


TransaktionaleDaten

Erlös

Analyse der potenziell gleichen Felder

Gewinn

Einigung auf ein gut dokumentiertes Zielfeld

360


361

Entwurf eines integrierten Datenmodells

Informationsbedarfanalysieren

Analysemodell

Objektmodell

MultidimensionalesModell

Datenbedarf “bearbeiten” / Sammeln von Datenelementen

Vorläufige Bezeichner(Konventionen)

Synonymensuche im zentralen Bestand

Homonymenensucheim zentralen Bestand

Erweiterung deszentralen Bestands

E i n z e l p r o j e k t Z e n t r a l e A u f g a b e

Daten aus Vorsystemen

MappingregelnETL


362

Hilfsmittel bei dem Auffinden von Synonymen

• Ziel:– Wiederverwendung von Objekten

und Informationen

– Standardisierung von Bezeichnern

• Methodenmix

• Permanente Aufgabe während der Weiterentwicklung des systems

• Aufwand sollte berücksichtigt werden

• Analyse von Bezeichnern – Feldliste

• Wortstammanalyse

• Arbeiten mit Standard-Abkürzungen

• Beschreibung durch Deskriptoren

• Systematische Datentypklassifikation

• Synonymen-Suche durch Normalisierung von Entitäten

Methoden und Hilfsmittel zur Synonymensuche


Namensvergabe hilft bei der Orientierung

• Prefixe für die unterschiedlichen Datenarten

– Fakten -> F_

– Dimensionen -> D_

– Referenzdaten -> R_

– Stammdaten -> S_

– Temporäre Daten -> tmp_

– Bewegungsdaten -> B_

▪ Suffixe für die unterschiedlichen Feld-Arten

– PK_/Schlüsselfelder -> _ID

– FK- Felder -> _ID

(gleiche Namen wie PK-Fleder)

– Allgemeine Nummerierungen / Zählfelder

-> _NR

– Datumsfelder -> _Dat / _Datum

– Beschreibungsfelder -> _Desc

▪ Ziel: Die Wartbarkeit des Modells

363


Kunden_Wohnart_Nr

Informationzu einem Kunden wird beschrieben

Die Art und Weise, wie ein Kundewohnt wirdbeschrieben

unter-schiedlicheWohnungs-arten sind durch-nummeriert

Hauptwort Eigenschafts-benennung

Basistyp

Bezugsobjekt BeschreibendeInformation

Charakter desAttributes

Wortstammanalyse hilft bei der Klassifizierung von Column-Namen

364


select

substr(table_name,1,20) Tab,

substr(column_name,1,20) Col,

substr(data_type,1,8) Typ,

substr(data_length,1,3) Len

From dba_tab_columns

WHERE

owner = 'SV' and

(table_name like 'F_%' or

table_name like 'D_%')

order by col

/

Über alle Tabellen

Alphabetisch sortiert nach Spaltennamen

Hilft beim Erkennen von Homonymen und Synonymen

Hilft bei der Bewertung der Tauglichkeit von Spaltennamen

Erlaubt Vorahnungen von Schlüsselkandidaten

Hilfsmittel Feldliste

365


Die Feldliste(Beispiel)

TAB COL TYP LEN

-------------------- -------------------- -------------------------------- ------------

D_FILIALEN ALLE_FILIALEN VARCHAR2 20

D_KUNDE ALLE_KUNDEN VARCHAR2 20

D_LAGER ALLE_LAGER VARCHAR2 40

D_MITARBEITER ALLE_MA VARCHAR2 10

D_REGION ALLE_ORTE CHAR 9

D_PRODUKT ALLE_PRODUKTE VARCHAR2 50

D_ZEIT ALLE_ZEITEN CHAR 11

D_KUNDE ANREDE VARCHAR2 10

D_SPEDITEUR ANZ_FAHRZEUGE NUMBER 22

D_KUNDE ANZ_KINDER VARCHAR2 5

D_ARTIKEL ARTIKEL_ID NUMBER 22

D_ARTIKEL ARTIKEL_NAME VARCHAR2 50

D_KUNDE BERUFSGRUPPE VARCHAR2 30

D_KUNDE BERUFSGRUPPEN_NR NUMBER 22

F_ZAHLUNGEN BEZAHLT VARCHAR2 5

F_ZAHLUNGEN_PARTITIO BEZAHLT VARCHAR2 5

D_KUNDE BILDUNG VARCHAR2 30

D_KUNDE BILDUNGS_NR NUMBER 22

D_KUNDE BRANCHE VARCHAR2 30

D_REGION BUNDESLAND VARCHAR2 255

D_LAGER BUNDESLAND VARCHAR2 50

D_LIEFERANTEN BUNDESLAND VARCHAR2 255

D_LAGER BUNDESLAND_NR NUMBER 22

D_LIEFERANTEN BUNDESLAND_NR NUMBER 22

D_REGION BUNDESLAND_NR NUMBER 22

F_POSITION DISCOUNT_PROZENT NUMBER 22

366


• Ableiten von Feldnamen aus den fachlichen Beschreibungen der Anwender

• Sammeln von allen Wortstämmen aller Feldnamen in dem System

• Dictionary-Unterstützung

Synonymen-Suche:Analyse von Bezeichnern – Wortstammanalyse

1. Ein neues Datenelement wird mit einem selbstsprechenden Bezeichner beschrieben.

Beispiel: Summe des täglichen Umsatzes pro Filiale.

2. Mit Hilfe einer firmenspezifischen Stoppwortliste (negative Auswahl) werden inhaltlose Bestandteile eliminiert.

Beispiel: Summe täglichen Umsatzes pro Filiale.

3. Der Rest wird durch grammatikalische Vereinfachung auf den Wortstamm reduziert. Ergebnis ist eine Beschreibung des Datenelements durch Stichworte.

Beispiel: SUMM TAG UMSATZ FILIALE

4. Man vergleicht den Namen mit eventuell vorhandenen.Die Wortstämme kann man in das Metadaten-Repository übernehmen,und sie mit Referenzen zu den sie nutzenden Feldnamen versehen.

367


enthaelt

is_referenced_by

generalise

use_as_business_key

use_as_PK

use_as_field

prueft

is_synonym_of

is_related_to

is_homonyme_of

matches

has_checked_col

is_checked_by

Attribut

Tabelle

Glossar

(Definition)

Geschäftsobjekt

Column Rule

Abkürzungen Wortstämme

is_homonyme_of is_synonym_of

nutztnutzt

erklärt

Das Metamodell zum Synonymen / Homonymen-Abgleich

View

• Die wichtigsten Metadaten-Typen

• Die Kontrolle muss über die Felder/Attribute laufen

368


369

Attributierung Metadaten-Typ „Kennzahl“• Name

• Synonym

– Referenz -> KENNZAHL


• Bereich: Standardwerte z. B. - Finanzielle Ergebnisse

- Qualität von etwas (Produkt/Service)

- Ablauf, Fortschritt von etwas (Prozess)

- Leistungsfähigkeit von etwas

• Geschäftsprozess

- Referenz -> PROZESS

• Definition (Text)

• Beschreibung (Text)

• Ziel / Zweck (Text)

• Zielgruppe [Abteilung, MA, Rolle]

• Aktualisierungsfrequenz (Zeitangabe)

• Maßeinheit [%, Wertgröße, Zeit]

• Rechen-/Herleitungsregel

• Messwertvariante

– Absolute Größe

– Verhältniswert– Gliederungszahl (Bsp. Eigenkapital ist Teil von Gesamtkapital)

– Beziehungszahl (Verhältnis von 2 Werten untereinander)

– Indexzahl (Gleichartige Größen in zeitlich oder räumlich

getrennten Bereichen. Z. B. Veränderung im Vergleich zum Vorjahr)

– Richtwert / Orientierungsgröße

• Quelldaten (Text, Ursprung der Daten)

• Verwendete Größen

Referenz -> COLUMN/ATTRIBUT

• Regel / Referenz -> RULE

• Org-Level [Top, Mittel, operativ]

• Zeitmaß [Jahr , Quartal, Monat, Woche, Tag]

• Historie [Vergangenheit, Aktuell, Zukunft]

• Hierarchieposition- Referenz SUB_von -> KENNZAHL

- Referenz TOP_von -> KENNZAHL


370

Kennzahlen-Metadaten-Modell

• Die benötigten Metadatentypen

enthaelt

is_referenced_by

generalise

use_as_business_key

use_as_PK

use_as_field

prueft

is_synonym_of

is_related_to

is_homonyme_of

matches

has_checked_col

is_checked_by

Attribut

Tabelle

Glossar

(Definition)

Geschäftsobjekt

Column Rule

Abkürzungen Wortstämme

is_homonyme_of is_synonym_of

nutzt

nutzt

erklärt

View

Enthaelt (1)

is reported_byBericht

Sub_Von

enthältenBeschrieben_durch

TransactionalData (Fakt)

Dimension

Kennzahl

Synonym_von

nutzt

prueft

erklärt

group _of _unit

Org_Unit

Wird_genutzt_von

Prozess

Einsatz_in

Homonym_von


Aufbau eines Glossars

371


372

Ein Glossar...

• ...ist eine Zusammenstellung von Fachbegriffen

• ...standardisiert und definiert Begriffe

• ...erklärt Begriffe auf eine leicht verständliche allgemeinsprachliche Art

• ...ist firmenöffentlich allen Mitarbeitern zugänglich

Regelmäßige manuelle Pflege nötig


373

Attributierung Metadaten-Typ „GLOSSAR“

• Begriff

• Synonyme


• Schlagworte [Liste von Suchbegriffen]

• Definition_Kurz (Text)

• Beschreibung_Lang (Text)

• Verantwortlich (MA-Name)

• Angelegt_Am (Datum)

• Geändert_Am (Datum)

• Referenzen (Weiterführende Begriffe)– Referenz -> GLOSSAR

• Externe_Referenzen [Fundstelle, Literatur]

Das Glossar-Metadaten-Modell

is_synonym_of

Referenz is_homonyme_of

Glossar

(Definition)


Zusammenfassung

374



Le

ga

cy

D

at

aN

ew

D

at

a

Log +Produktions

Daten

Big Data Discovery Studio

FinancialProcurement&SpendHR, SCM, & OM, PIM

Find Explore

TransformDiscover

S i n g l e - E n t e r p r i s e A n a l y s e - P l a t t f o r m Oracle BusinessIntelligence Suite

(Dashboards, Reporting)

Oracle BI Apps

In-Memory Discovery Index

Big Data Appliance

Exalytics IM Machine

Exadata

AlleUnternehmens

Prozesse

IoT

SAP R/3

Hadoop-Datastore (HDFS/noSQL)

Business LogikIn Memory Oracle 12c

Data GovernanceMetadata Repository

Large Objects

IotDataHuman/Trends

Mu

ltyT

en

an

cie

s

Integrierte Modelle Granulares LevelMeist 3NF

Relational Database Oracle 12c

ER Modeler

Integriertes Row Level Security

SAP BW

All DataData Lake Concept

Oracle Database 12cOracle Data

Integrator

BatchRealimeRemoteAccess

Logical/Physical

Access

StreamAnalytics

HarmonizingData QualityData Profiling

Si

ng

el

eA

cc

ce

ss

SQ

L

IoTService

Interactive Dashboards

MobileConsumption

Published Reporting

Ad-hoc Analysis

Office Integration

Cloudera Hadoop Distribution

Advanced / Predictive AnalyticsR + Data Mining

375


376

Regeln einer effizienten Data Warehouse Architektur

• Breite Abfragemodelle bereitstellen

• Verbund-Data Marts

• Über Data Mart-Grenzen hinweg gemeinsam genutzte Berechnungen + Aggregationen usw. so früh wie möglich umsetzen

• Kern-Warehouse-Schicht schon mit Blick auf Auswertemodelle / Hierarchien modellieren

• Alle Schichten in einem DB-Raum

• In-Database-Aktivitäten (Prüfen/Laden)

• 1:1 Kopien verhindern

• Permanente Orientierung an den Informationsbedürfnissen der Benutzer

• Dokumentation aller Informationen Im Warehouse(Business Glossar)

• Technisches und fachliches Monitoring von Inhalten und System

• Kompaktes Schichtenmodell schaffen

– Data Marts so weit wie möglich virtualisieren

– Redundanzen in unterschiedlichen Schichten vermeiden

– Berechnungen / Aggregate so früh wie möglich durchführen

• Zusammenhängende Data Mart-Schicht

– Mehrfachnutzung von Dimensionen / ConformedDimensions

– Geschickter Umgang mit sehr großen Faktentabellen / Vermeiden unnötiger Kopien

– Eher granulare Informationen auch in den Fakten-Tabellen

Data Warehouse Technik im Fokus - oracledwh.de€¦ · Oracle Database Performance Tuning Guide 11g...

Documents

Transcript of Data Warehouse Technik im Fokus - oracledwh.de€¦ · Oracle Database Performance Tuning Guide 11g...