SAP BW „wächst“

SAP Business Information Warehouse
mit Oracle Database
Maciej Berghof
Business Unit Datenbank
SAP BW „wächst“
Ÿ Betriebswirtschaftlich getriebener Bedarf
an mehr Informationen
Ÿ SAP BW konkurriert mit den bisherigen
DW-Marktführern
Ÿ Höhere Anforderungen puncto
Performance und Managability
Ÿ Notwendigkeit der engen Kopplung an
DW-Eigenschaften einer Datenbank
Page 1
1
Large SAP BW Systems
Ÿ SAP zeigte auf der SAPHIRE 2002 eine 5 TB Studie
mit 20.000 konkurierenden Benutzern
Ÿ SAP BW Implementierungen:
–
–
–
–
–
Colgate / USA
Officemax / USA
Coop / Schweiz
Saudi Aramco
Migros / Schweiz
...in Planung
– Postbank
– Karstadt
3.8 TB (Ziel: 5 TB)
4.0 TB (Ziel: 8 TB)
1.5 TB
1.0 TB
1.0 TB (Ziel: 5 TB)
Ziel: 3.0 TB
Ziel: 7.0 TB
Ÿ Alle diese Systeme arbeiten mit Oracle 8i/9i
Ÿ 100 % aller SAP BW‘s über 1 TB mit Oracle
Über 80 % aller SAP BW‘s mit Oracle
Colgate Palmolive
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Hardware: IBM Regatta p690, 24 CPU‘s, 96GB RAM
Disk: IBM Shark, 10 Terabytes
OS: AIX 5.1
SAP BW 2.0B
Datenbank Oracle 9.2
Größe der Oracle Datenbank: 3.8 Terabytes
– 78 Info Cubes wachsend (je 1M - 70M Rows)
– 900+ Aggregate
– 7x24h System mit ca. 2000 conc. Usern
Ÿ Range Partitioning mit Rolling Window
Ÿ Projektierte Größe ( 12 Monate ) 5.0 Terabytes
Page 2
2
OfficeMax
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Hardware: SUN E10000, 40 CPUs, 24 GB RAM
Disk: Hitachi, 13 Terabytes
OS: Solaris 2.8
SAP BW 3.0
Datenbank Oracle 9.2
Größe der Oracle Datenbank: 4.0 Terabytes
– 7 Info Cubes wachsend (je 10M – 4.212M Rows)
– 31 Aggregate
Projektierte Größe ( 12 Monate ) 8.0 Terabytes
Integration von Oracle DWH
Ÿ BW 1.0
–
–
Start der Entwicklung von mit Oracle 7.3
Erste Integration von Oracle DWH Funktionalität
(Bitmap Index, Star Query Join)
Ÿ BW 2.0
–
Einsatz von Oracle8i – Einbindung von Partitioning
(u.a. Range Partitionierung, Parallel Query)
Ÿ BW 3.1
–
Setzt Oracle 9.2 voraus und verwendet neue 9i Funktionen
(u.a. MERGE, LIST Partitioning )
Ÿ BW 3.5
–
Oracle9.2: Automatisches UNDO, Automatische
Sortierbereiche
Ÿ BW 4.0
–
(Ende 2003)
(Anfang 2004)
Oracle9i/10i: Data Compression
Page 3
3
Oracle 9iR2 – Speedup für SAP BW
Ÿ durch .. intelligentes Aufteilen von Datenmengen
– Range Partitioning
Ÿ durch .. 64-bit Technologie
Ÿ durch .. Parallelisierung
–
Parallel Query, automatisches Tuning
Ÿ durch .. optimale Nutzung des SAP BW Star Schemas
–
Persistente Bitmap Indizes und Star Query Transformation
Ÿ durch .. selbstständiges Tuning
–
Automatisches Sortieren, UNDO TS, Segment Space, LMTS
Ÿ durch .. langjährige Unterstützung aller HW-Architekturen
– SMP, ccNUMA, Cluster
Smart – Range Partitionierung
Ÿ Range Partition Schlüssel
–
(values less than ..., in (...)), auch mit mehreren Kriterien
Ÿ SAP Anwendungen
–
–
profitieren ‘transparent’ von der Range Partitionierung
Parallel DML / Partition Pruning (Elimination)
Sales
nov96
dez96
jan97
feb97
okt97
Page 4
4
Smart – Maintenance (Rolling Window)
SAP BW (ab 2.0) enthält den vollen Befehlssatz:
Ÿ neue Partition anhängen
(add)
Ÿ bestehende Partition ´löschen´
(drop)
Ÿ bestehende Partition aufteilen
(split)
Ÿ Daten einer Partition löschen
(truncate)
Ÿ Daten einer Partition mit Tabelle austauschen
(exchange)
Ÿ Partition verschieben an anderen Speicherort
(move)
Ÿ Partitionen zusammenfassen, ab 8i
(merge)
Ÿ Partitionen umbenennen
(rename)
Ÿ Partitionen exportieren/importieren
Parallel SQL
SELECT * FROM FACT order by ARTIKEL_NO;
Paralleles Sortieren
Set No 2
Ein Knoten/System
Ein SQL Statement wird vom
Optimizer in kleinere
Arbeitsschritte aufgeteilt und
läuft skalierbar ab
Paralleles Lesen
Set No 1
PQ 5
Tabelle FAKT
PQ 1
A- G
PQ 6
User
Process
Parallel
Coord .
PQ 2
H-M
PQ 7
PQ 3
N-S
PQ 8
PQ 4
T-Z
= Sortierung
Intra-
Page 5
5
Smart - Parallelisierung/Skalierung
Ÿ Parallelisierbare
Operationen
–
–
–
–
–
–
–
–
–
–
–
–
seriell
SQL
Load
Insert
Select
Sort Operationen
Create Index
parallel
Create Table/Mav
Backup/Recovery
Group By
Update / Delete
Join Operationen
Move / Split
Partition
Online Index
Rebuild
100%
CPU
I/O
CPU
I/O
50%
100%
SQL
50%
SMART – Dynamische Sortierungen
Ÿ Oracle setzt dynamisch je nach Bedarf der SQLOperation die Größe von Speicherbereichen
è Elementar
im Data Warehouse !!
Ÿ Management:
–
–
Der DBA muss keine *_AREA_SIZE Parameter einstellen
Nur ein Speicherbereich für alles: PGA_AGGREGATE_TARGET
Ÿ Performance:
–
Sortierungen finden nun wesentlich häufiger im Hauptspeicher statt
und nicht auf Festplatte
Page 6
6
Smart – Compressed Bitmap Index
Teile
Tabelle
SELECT count(*)
FROM teile
WHERE
größe = ‘MITTEL’
farbe = ‘ROT’
AND
teilnr
001
002
003
004
005
006
...
Farbe
GRÜN
GRÜ
ROT
ROT
BLAU
ROT
GRÜ
GR
ÜN
....
Größ
Gr
ößee
Gewicht
MITTEL
MITTEL
KLEIN
GROSS
MITTEL
KLEIN
98.1
1241
100.1
54.9
.....
124.1
60.1
...
Farbe = ‘BLAU
BLAU’’
Farbe = ‘ROT’
ROT’
Farbe = ‘GR
GRÜ
ÜN’
0
0
1
0 0 1 0 0 1 0 1 0 1 0 0 0 1 0
1
1 1 0 1
0
0 0 0 1 0 0 0 0 1 0 0 1
0 0 0 0
1 1 0 0 0 1 0 1 0 1 0 0
Bitmap
Index auf
Farbe
Größee = ‘KLEIN
Größ
KLEIN’’
Größ
Gr
ößee = ‘MITTEL
MITTEL’’
Größ
Gr
ößee =‘ GROSS
GROSS’’
0
1
0
0 1 0 0
1 1 0 1 0 1 0 0 0 1 0 1
0
1 0 0 1
0 0 1 0 0 0 0 1 0 1 0 0
0 0 1 0 0 0 0 1 0 1 0 1 0 1 0
1
Bitmap
Index auf
Größe
Star Query Join
Ÿ Star Schemata sind die typischen Datenstrukturen eines
Data Warehouses, auch von SAP BW
Ÿ Große Fakten Tabelle, der mehrere wesentlich kleinere
Dimensions-Tabellen zugeordnet sind
Ÿ Oracles Star-Query Join ist 10-30 x schneller als die
Verfahren der Mitbewerber ! Grund: Persistenter,
komprimierter Bitmap Index !
Fakten-Tabelle
Dimensions-Tabellen
Page 7
7
Oracle9i: Data Compression
Ÿ Was ist das?
–
–
–
–
–
Ein neuer Algorithmus zur Eliminierung redundanter
Daten
Transparent für Anwendungen
Gut einsetzbar in BW (lese-intensiv, wenige Updates)
Komprimierte Tabellen unterstützen DDL/DML
Indezies sind nicht supported (bitmap indexes sind
bereits komprimiert
Ÿ Vorteile:
–
–
Kann signifikant Platten- und Buffer Cache –
Naforderungen reduzieren
Beschleunigt Abragen
SAP 5TB study
(SAPPHIRE `02) Oracle
9i compression test
SPACE
ORIGINAL
COMPRESSED
COMPARISON
80 x PSA
3.5 TB (45 GB each)
1.1 TB (14 GB each)
-69%
1 TB (13 GB each)
480 GB (6 GB each)
800 x AGGREGATE
2GB
< 1 GB
-54%
-50%
PERFORMANCE
COMPARISON
80 x CUBE
ORIGINAL
COMPRESSED
ASCII -> PSA
45 h
tbm*
Create Index on PSAs
15.5 h
10.25 h
53%
Create Statistics on PSAs
19 h
7.5 h
153%
Load Data PSA -> Cube
65 h
tbm*
Create Indexes on Cubes
3h
3h
0%
Create Statistics on Cubes
6h
4h
50%
Create 800 Aggregates
14 h
18 h
-29%
Create Indexes on Aggregates
1h
1h
0%
11 sec
8 sec
38%
FTS Queries with 100% buffer hits
FTS Queries with 0% buffer hits
31 sec
17 sec
82%
Index Access Queries with I/O
313 sec
254 sec
23%
Page 8
8
Compression test at OfficeMax
Compression test at OfficeMax
Page 9
9
email: [email protected]
Q&
A
Q U E S T I O N S
A N S W E R S
Page 10
10