Entwicklung einer Methodik zur Performanceoptimierung am Beispiel von SAP BW

Inhaltsverzeichnis

1 Einleitung
1.1 Vorstellung des Unternehmens
1.1.1 Hubert Burda Media
1.1.2 Burda Digital Systems
1.2 Problemstellung / Zielsetzung der Diplomarbeit
1.3 Stand der Forschung

2 Grundlagen
2.1 Business Warehouse als Bestandteil von SAP NetWeaver
2.2 Architektur des Business Warehouse
2.3 Hardware und Datenbanken
2.4 Warehousing-Prozess
2.4.1 Funktionen für den ETL-Prozess
2.4.1.1 Extraktionsschicht
2.4.1.2 Der ETL-Prozess
2.4.1.3 Performancerelevanz
2.4.2 Komponenten für die Datenablage
2.4.2.1 InfoObjects
2.4.2.2 InfoProvider
2.4.2.3 Performancerelevanz
2.4.3 Weitere Möglichkeiten der Performanceverbesserung
2.4.3.1 Komprimierung und Partitionierung
2.4.3.2 Aggregation
2.4.3.3 Indizierung
2.4.3.4 Queries
2.4.4 Werkzeuge für Analysen und Berichte
2.5 Werkzeuge der Performanceanalyse
2.5.1 Analyse von Datenbank, Speicher und Hardware
2.5.1.1 Datenbank
2.5.1.2 Speicher
2.5.1.3 Hardware
2.5.2 Analyse der Systemlast
2.5.3 Einflussfaktoren auf die einzelnen Laufzeitanteile einer Query
2.5.3.1 OLAP-Zeit
2.5.3.2 Datenbanklaufzeit
2.5.3.3 Frontend-Laufzeit
2.6 Zusammenfassung

3 Performanceanalyse
3.1 Rahmenbedingungen
3.1.1 Systemumgebung
3.1.2 Definition der Referenzmodelle
3.1.2.1 Referenzmodell Cube-Modellierung
3.1.2.2 Referenzmodell Query-Aufbau
3.2 Messreihen
3.2.1 Performancemessung InfoCube-Modellierung
3.2.1.1 InfoCube als Kennzahlenmodell
3.2.1.2 InfoCube als Kontenmodell
3.2.1.3 InfoCube mit MultiProvider
3.2.1.4 Komprimierter InfoCube
3.2.1.5 Partitionierung des InfoCubes auf Datenbankebene
3.2.1.6 Partitionierung des InfoCubes auf Applikationsebene
3.2.1.7 InfoCube mit LineItem-Dimension
3.2.1.8 InfoCube mit 3 Dimensionen
3.2.1.9 InfoCube mit 5 Dimensionen
3.2.1.10 InfoCube mit hoher Kardinalität
3.2.1.11 InfoCube mit Navigationsattributen
3.2.1.12 Optimierungsmatrix
3.2.2 Performancemessung Query-Aufbau
3.2.2.1 Kennzahlenberechnung beim Datenladen mit inaktivem Query-Cache
3.2.2.2 Kennzahlenberechnung beim Datenladen mit aktivem Query-Cache
3.2.2.3 Kennzahlenberechnung im Query-Designer mit inaktivem Query-Cache
3.2.2.4 Kennzahlenberechnung im Query-Designer mit aktivem Query-Cache
3.2.2.5 InfoCube mit Aggregat
3.2.2.6 Optimierungsmatrix
3.2.2.7 Weitere Einflussfaktoren
3.3 Zusammenfassung

4 Methodik der Performanceoptimierung
4.1 Hauptprozess
4.1.1 Analyseprozess
4.1.1.1 Zeitmessung Query
4.1.1.2 Zeiten der Testausführung übertragen
4.1.1.3 Anzahl der Datensätze im Datenmodell prüfen
4.1.1.4 Verschiedene Prüfungen
4.1.2 Adjustment
4.1.2.1 Adjustment OLAP-Zeit
4.1.2.2 Adjustment DB-Zeit
4.1.2.3 Adjustment Frontend-Zeit
4.1.3 Performancetest

5 Evaluierung
5.1 Analyse
5.2 Adjustment
5.3 Performancetest
5.4 Zusammenfassung

6 Zusammenfassung und Ausblick

7 Abbildungsverzeichnis

8 Abkürzungsverzeichnis

9 Literaturverzeichnis

10 Anhang

1 Einleitung

1.1 Vorstellung des Unternehmens

1.1.1 Hubert Burda Media

Hubert Burda Media gilt als eines der innovativen Unternehmen der Deutschen Medienlandschaft. 1987 übernahm Verleger Dr. Hubert Burda die alleinige Steuerung des Familienunternehmens mit über 100-jähriger Geschichte. Seit dem entwickelte sich Hubert Burda Media rasch zu einem Medienunternehmen.

Heute bilden über 250 Magazine im In- und Ausland, zahlreiche Internet- und Radiobeteiligungen, TV- Produktionen und Direktmarketing das Unternehmensportfolio. Hubert Burda Media setzt außerdem Maßstäbe in den Bereichen Digital Business und Digital Lifestyle.

Der Medienkonzern beschäftigt mehr als 7300 Mitarbeiter und besitzt Standorte in Deutschland, Mittel- und Osteuropa, Russland und Asien. Neben dem Stammsitz in Offenburg ist das Unternehmen in München, Berlin und Hamburg vertreten.

1.1.2 Burda Digital Systems

Die Burda Digital Systems GmbH (BDS) ist eine 100%ige Tochter des Hubert Burda Media Konzerns. Die BDS entwickelt und betreibt IT-Lösungen von SAP, Microsoft und Eigenentwicklungen für das Verlags- und Druckgeschäft. Kunden sind sowohl Konzernfirmen als auch externe Kunden.

Der Projektfokus des zentralen Konzerndienstleisters liegt unter anderem auf Themen wie anwenderfreundliche Integration vorhandener Applikationen in Unternehmensportalen, der mobilen Bereitstellung von Management-Informationen und der dynamischen Steuerung des Außendienstes.

Die ca. 160 Mitarbeiter verteilen sich auf die Standorte Offenburg, München und Hamburg.

1.2 Problemstellung / Zielsetzung der Diplomarbeit

Die Integration von Data Warehäusern in Unternehmensportale erhält in den meisten Unternehmen eine immer größere Bedeutung. Die Akzeptanz bei den Endanwendern steht und fällt jedoch mit der Antwortzeit, welche leider oft über 6 Sekunden und in einzelnen Fällen bis zu 5 Minuten beträgt. Es gibt verschiedene Möglichkeiten Performanceoptimierungen durchzuführen, wobei es keinen Königsweg gibt. In vielen Data Warehouse Projekten wird oft entwickelt und erst im Nachhinein eine Optimierung der Performance durchgeführt. Die richtige Vorgehensweise wäre jedoch, das Thema bereits in der Konzeptionsphase anzugehen. Das Problem ist hier, dass es bisher keine geeignete Methodik für eine solche Vorgehensweise gibt.

Eine solche Methodik soll im Rahmen dieser Diplomarbeit entwickelt werden. Ziel dieser Arbeit ist:

1. Beschreibung der Problemstellung, wobei die für diese Arbeit notwendigen Definitionen aufgestellt und Rahmenbedingungen festgelegt werden sollen.
2. Recherche und Bewertung des „Stand der Technik“. Untersucht werden sollen hierbei Methoden und Werkzeuge zur Optimierung von Datenbanksystemen und Data Warehäusern.
3. Definition eines Referenzmodells, anhand dessen die unterschiedlichen Methodenansätze definiert bzw. am Ende getestet werden können.
4. Entwicklung der Optimierungsmethoden. Dabei sollen verschiedene Kategorien gebildet werden (z.B. Hardware, Software, Prozess). Der Schwerpunkt soll hierbei auf den Bereichen Software (Datenbankmodellierung, Queryaufbau, Caching, usw.) sowie dem Prozess (Vorberechnung, Information Broadcasting, usw.) liegen. Als Ergebnis soll eine Matrix entstehen, durch welche man in Abhängigkeit der Anforderungen, Datenbasis u.a. die geeignetste Optimierungsmethode findet.
5. Evaluation: Die Ergebnisse sollen mit Hilfe des Referenzmodells getestet und evaluiert werden.

Die Diplomarbeit wird am Beispiel von SAP BW erarbeitet.

1.3 Stand der Forschung

Die wesentliche Aufgabe eines Data Warehouse ist die zeitnahe Auswertung und Verdichtung von Daten und Informationen. Besonders durch die Globalisierung der Märkte müssen Unternehmen die Qualität, Quantität und Verfügbarkeit ihrer Informationen verbessern. Um heutzutage wirtschaftliche Entscheidungen zu treffen, muss ständig ein aktuelles Bild vom Unternehmen verfügbar sein.

Bereits seit den frühen 1980er Jahren wurden aus diesem Grund Data-Warehouse-Systeme entwickelt. Erst 1998 hat die SAP AG eine Data-Warehouse-Lösung bereitgestellt, das SAP Business Information Warehouse (SAP BW). Seit Anfang des Jahres 2006 ist SAP NetWeaver 2004s mit dem Business Warehouse 7.0 – der Nachfolger zu BW 3.5 – für alle Kunden verfügbar. Mit diesem Release lassen sich laut SAP entscheidende Verbesserungen in Bezug auf die Berichtsperformance erreichen. Dies sei möglich durch den Business Intelligence Accelerator (BI Accelerator), der eine bereits bekannte Technologie aus dem www-Suchmaschinenumfeld^[1] für das schnelle Durchsuchen der Unternehmensdaten in Cubes ermöglicht. Allerdings fallen für die Nutzung des BI Accelerators zusätzliche Hardware- und Lizenzkosten an. Ein Großteil der Anwender wird aber weiterhin eine gewisse Zeit ältere Versionen des SAP BW nutzen oder aus Kostengründen den BI Accelerator nicht einsetzen. Performanceprobleme bestehen dabei bei vielen Unternehmen. Eine Umfrage des Beratungsunternehmens Raad Consult unter 420 Controllern und IT-Leitern aus dem Jahr 2004 ergab, dass über 60 Prozent der Befragten die langen Antwortzeiten bei komplexen Abfragen beklagten und die allgemeine Systembelastung durch BW reduziert sehen möchten. Die Gründe dafür seien vielschichtig und könnten weder dem Produkt noch dem Anwender allein zugeschrieben werden. Viele Anwender wüssten oft nicht wie sie InfoCubes richtig modellieren und den Business Intelligent Content (BI Content) richtig entpacken. Auch seien Kunden von der Datenexplosion der letzten Jahre überrascht worden und hätten ihre Systeme nicht entsprechend ausgelegt.^[2]

Die allgemein verfügbare Literatur liefert viele Ansatzpunkte für die Performanceoptimierung, aber ein ganzheitlicher Ansatz, von der Analyse zur Optimierung der Reportingperformance, wird nicht dargestellt. Dies ist der Inhalt dieser Diplomarbeit, die Entwicklung einer standardisierten Vorgehensweise mit dem Aufzeigen der größten Optimierungsmöglichkeiten und wann diese Möglichkeiten eingesetzt werden können.

2 Grundlagen

Das Grundlagenkapitel beschreibt die Einordnung des Business Warehouse in die SAP-Umgebung und erläutert die grundlegende Architektur des Business Warehouse. Außerdem werden der Prozess des SAP BW der Datenmodellierung beschrieben und die Werkzeuge der Performanceanalyse für das bessere Verständnis der Diplomarbeit erklärt. Das Grundlagenkapitel und die Performanceanalysen im System basieren auf dem neusten Release des SAP BW 7.0, das Bestandteil von SAP Netweaver 2004s ist. Der BI Accelerator kommt nicht zum Einsatz.

2.1 Business Warehouse als Bestandteil von SAP NetWeaver

„SAP NetWeaver is a set of capabilities that are provided by many different SAP products constructed to work with each other to make applications work together, build new applications on top of existing applications, and lower the total cost of owning applications.”^[3]

Das Business Warehouse ist Teil der „Information Integration“, das sich in die Unterpunkte Business Intelligence, Knowledge Management und Master Data Management gliedert, wie aus dem nachfolgenden Schaubild hervorgeht.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1 : Aufbau des SAP NetWeaver^[4]

Das Data Warehouse im SAP BW bedeutet Integration, Transformation, Konsolidierung, Bereinigung und Ablage von Daten, sowie die Bereitstellung der Daten zur Analyse und Interpretation. Dabei umfasst der Warehousing-Prozess neben dem Modellieren der Daten, die Datenbereitstellung sowie die Verwaltung der Prozessketten.^[5]

2.2 Architektur des Business Warehouse

Das Business Warehouse von SAP ist eine vollständige Data-Warehouse-Lösung die alle Werkzeuge, Funktionen und Komponenten dispositiver Systeme bietet. Hierzu zählen insbesondere:^[6]

- Werkzeuge für Administration, Customizing, Modellierung, Steuerung und Monitoring
- Funktionen für die Datenextraktion, Transformation und Laden
- Komponenten für Datenablage und Datenspeicherung
- Werkzeuge für das Meta-Datenmanagement
- Werkzeuge für Analyse und Reporting

Folgende Grafik zeigt, wie die Teilbereiche bzw. ihre Funktionsbereiche in die Architektur des SAP BW integriert sind.

Abb. 2 : Data-Warehouse-Architektur des SAP BW^[7]

Abbildung in dieser Leseprobe nicht enthalten

Die Daten liegen physisch auf einer Datenbank vor, dabei können unterschiedliche Daten-banksysteme wie Oracle, DB2/UDB, Informix, MS-SQL-Server, etc. zum Einsatz kommen. Der Applikationsserver, dessen Hauptbestandteil die OLAP Engine (Online Analytical Processing) ist, verarbeitet die Daten. Der Zugriff auf die Daten erfolgt dabei über den MDX-Prozessor des BW, der als Mittler zwischen der OLAP Engine und den Abfrageprotokollen der Zugriffsschnittstellen auftritt. Die Ergebnisse der verarbeiteten Daten werden auf dem Präsentationsclient ausgegeben. Die nach-folgende Abbildung zeigt den Informationszugriff über den Datenbankserver, Applikationsserver und Präsentationsclient.

Abb. 3 : Informationszugriff des SAP-Prozesses

Abbildung in dieser Leseprobe nicht enthalten

2.3 Hardware und Datenbanken

Die richtige Größenkategorie der Hardwareressourcen ist eine wichtige Voraussetzung für den performanten Betrieb eines BW-Systems. Das Hardwaresizing beschreibt die Berechnung und Prognose der erforderlichen Hardwareressourcen^[8] für eine gute Systemperformance. Einen ersten Anhaltspunkt bietet dabei der SAP Service Marketplace mit dem SAP Quick Sizer^[9]. Aufgrund der schnellen Entwicklung der Hardware soll im Rahmen der Diplomarbeit nicht weiter auf das Sizing eingegangen werden, es wird ein performantes Hardwaresystem vorausgesetzt.

Das SAP Business Warehouse unterstützt eine Vielzahl von Datenbanken die sich z.B. hinsichtlich dem Aufbau, der Struktur und der Indizierung unterscheiden. Die in dieser Diplomarbeit beschriebenen Performanceoptimierungen beziehen sich auf eine Datenbank der Firma Oracle.

2.4 Warehousing-Prozess

Für das Verständnis der Performanceoptimierung in SAP BW ist es unerlässlich die Komponenten zu kennen, die im Wesentlichen die Performance beeinflussen.

Das Business Warehouse unterteilt sich in drei Ebenen:^[10]

- Funktionen für den ETL-Prozess (Extraktion, Transformation, Laden)
- Komponenten für die Datenablage
- Werkzeuge für Analysen und Berichte

2.4.1 Funktionen für den ETL-Prozess

Durch den ETL-Prozess werden die Daten in das Business Warehouse System geladen und von InfoProvidern aufgenommen. Während des Ausführens dieser Prozessschritte können die Daten bereits verdichtet und bereinigt werden.

2.4.1.1 Extraktionsschicht

Das Business Warehouse kann aus unterschiedlichen Systemen Daten beziehen. Die Extraktionsschicht bildet die operativen Systeme ab, über die mit den Business Warehouse eigenen Kommunikationsschnittstellen Daten bezogen werden können. Bei den Quellsystemen handelt es sich dabei um:^[11]

- SAP ECC- bzw. R/3-Systeme
- SAP BW-Systeme
- File-Systeme
- Datenbanksysteme
- XML-Dokumente
- Quellsysteme mit JDBC-, ODBC- oder XML/A-Schnittstelle

Außerdem können Extraktionswerkzeuge anderer Hersteller (sogenannte 3rd party ETL-Tools) mit in den Extraktionsprozess eingebunden werden.

2.4.1.2 Der ETL-Prozess

Die Schritte des ETL-Prozesses teilen sich auf in:^[12]

- Extraktion
- Transformation
- Laden

Bei der Extraktion werden aus den unterschiedlichsten Quellsystemen die Daten zusammengestellt und über einen initialen Datenimport dem Business Warehouse zur Verfügung gestellt. Nach dem erstmaligen vollständigen Datenimport wird in zwei verschiedene Methoden unterschieden:

- Reloading, Full Load (das erneute, vollständige Laden)
- Incremental Load, Delta Load (nur Änderungen werden geladen)

Die Transformation bedeutet das Anpassen der Daten an das Data Warehouse-Format. Dieser Vorgang kann zu fehlerhaften und inkonsistenten Daten führen und muss mit einer geeigneten Datenqualitätssicherung bearbeitet werden.

Während des Ladens der Daten ist der Zugriff auf die Daten im Business Warehouse nicht möglich. Deswegen sollte dieser Vorgang nur dann ausgeführt werden, wenn wenige Zugriffe auf die Daten erfolgen, d.h. nachts oder am Wochenende.

Abb. 4 : Der ETL-Prozess

Abbildung in dieser Leseprobe nicht enthalten

2.4.1.3 Performancerelevanz

Auf die Extraktions- und Ladeperformance von einem Quellsystem in das BW wird in den folgenden Betrachtungen nicht näher eingegangen. Der Datenladeprozess hat keinen wesentlichen Einfluss auf die Reportingperformance, die für den Endanwender relevant ist.

2.4.2 Komponenten für die Datenablage

Das Business Warehouse Datenmodell besteht aus einer Vielzahl von Komponenten, die für unterschiedliche Aufgaben eingesetzt werden können. Dabei handelt es sich um:

- InfoObjects
- InfoProvider

2.4.2.1 InfoObjects

Im SAP BW bilden InfoObjects die Basis für das Datenmodell. SAP bezeichnet InfoObjects als „betriebswirtschaftliche Auswertungsobjekte“. InfoObjects gliedern sich in Merkmale und Kennzahlen:^[13]

- Merkmale
- Merkmale charakterisieren den Geschäftsvorfall und stellen Beziehungen her
- Für Merkmale können ggf. Stammdaten, Texte und Hierarchien abgelegt sein
- Kennzahlen
- Kennzahlen liefern die Werte (z.B. Beträge, Mengen, Zähler, Datum und Zeit), die zu analysieren sind

Abb. 5 : Gliederung InfoArea, InfoObjectCatalog, InfoObject^[14]

Abbildung in dieser Leseprobe nicht enthalten

InfoObjects sind in InfoObjectCatalog gruppiert, diese wiederum können nach Anwendungsgebieten in InfoAreas gegliedert werden.

Kennzahlen lassen sich in drei Kategorien untergliedern:

- Kennzahlen mit Merkmals-Charakter
- Gruppierte Kennzahlen
- Berechnete Kennzahlen

Für Performanceuntersuchungen ist die Gruppe der berechneten Kennzahlen besonders interessant. Für die Berücksichtigung der berechneten Kennzahlen im Datenmodell existieren drei Alternativen:^[15]

- Berechnung der Kennzahl im Rahmen der Analyse

- Verwendung von Ausnahmeaggregation

- Modellierung der Kennzahl im BasisCube und Berechnung der Kennzahl beim Füllen des BasisCubes

Alle drei Alternativen haben unterschiedliche Rahmenbedingungen und besitzen unterschiedliche Vor- und Nachteile hinsichtlich der Datenbasis der Berechnungen, Flexibilität der Berechnung, Detaillierungstiefe und Performanceeigenschaften.

2.4.2.2 InfoProvider

Alle reportingtauglichen Objekte werden als InfoProvider bezeichnet. Dabei handelt es sich um:

- Basis-InfoCubes
- DataStore-Objects
- InfoSets
- MultiProvider

2.4.2.2.1 Basis-InfoCubes

Für die Speicherung und die Analyse der Bewegungsdaten in Fakten- und Dimensionentabellen sind im BW so genannte BasisCubes vorgesehen. Diese BasisCubes bieten die meisten analytischen Funktionen bei der Auswertung von Bewegungsdaten, gerade auch aus Sicht der Performance-optimierung.^[16]

Den BasisCubes liegt das erweiterte Star-Schema zugrunde (siehe Exkurs).

Ein weiterer wichtiger Aspekt beim Aufbau von InfoCubes ist die Wahl der Modellierungsstrategie. Es wird in folgende zwei Strategien unterschieden die einen wesentlichen Einfluss auf die Reporting-Performance haben:

- Kennzahlenmodell
- Kontenmodell

Das Kennzahlenmodell wird verwendet bei einer beschränkten und konstanten Anzahl von Kennzahlen. Es sollte jede oder zumindest eine große Anzahl von Kennzahlen eines Datensatzes auch in anderen Datensätzen verwendet werden.

Abb. 6 : Kennzahlenmodell^[17]

Abbildung in dieser Leseprobe nicht enthalten

Das Kontenmodell kommt zum Einsatz, wenn mit einer hohen und vor allem wechselnden Anzahl von Kennzahlen gearbeitet wird, d.h., wenn die überwiegende Anzahl der Kennzahlen innerhalb eines Datensatzes leer sind.^[18]

Abb. 7 : Kontenmodell

Abbildung in dieser Leseprobe nicht enthalten

Weiterhin gibt es auch VirtualProvider, die lediglich logische Sichten auf Daten darstellen und keine Daten speichern. Darunter fallen der RemoteCube, der SAP RemoteCube und der virtuelle InfoCube, die nicht Bestandteil der Diplomarbeit sind. Ebenso wird in dieser Diplomarbeit der Realtime-InfoCube^[19], der beispielsweise in der Planung verwendet wird, nicht weiter erläutert.

Exkurs: Erweitertes Star-Schema

Das klassische Star-Schema besteht aus zwei Faktentabellen^[20] mit bis zu 16 Dimensionen-tabellen^[21], wovon 13 Dimensionen frei wählbar sind. Es gibt drei vordefinierte Dimensionen die da wären Zeit (Time), Einheit (Unit) und Datenpaket (Packet).

Das erweiterte Star-Schema – auch das BW-Datenmodell genannt – bietet durch die Erweiterung des klassischen Star-Schemas mit dem Konzept der SID-Schlüssel (Surrogate-ID) einige Vorteile in der Datenmodellierung.

Die SID-Schlüssel erlauben eine flexible Modellierung der Beziehungen von Merkmalen und Attributen in einer Dimensionentabelle. „Auf diese Weise können auch komplexe zeitliche Veränderungen der Objekte untereinander in Dimensionen zur Abbildung historischer Datenkonstellationen realisiert werden.“^[22]

Die Faktentabelle ist aus Fremdschlüsseln und Kennzahlen aufgebaut. Die Fremdschlüssel können auf Dimensionentabellen mit Hilfe der DIM-IDs verweisen, oder auf Line-Item-Dimensionen mit Hilfe der SID-Schlüssel. Durch die Kombination aus DIM-IDs und SID-Schlüsseln ist jede Zeile einer Faktentabelle eindeutig identifiziert.

Die Aufgabe einer Dimensionentabelle ist es, Merkmale zu gruppieren und in einen thematischen Zusammenhang zu bringen.

Line-Item-Dimensionen werden verwendet wenn Dimensionentabellen nur ein InfoObject enthalten. In diesem Fall wird die Verknüpfung der Faktentabelle des InfoCubes nicht über die DIM-Schlüssel erstellt, sondern direkt über die 4-Byte-Integer-SID-Schlüssel des Merkmals. Die Dimensionentabelle kann aufgrund der direkten Aufnahme der SID-Schlüssel in die Faktentabelle entfallen.

Das nachfolgende Schaubild verdeutlicht den Zusammenhang von Faktentabelle, Dimensionen-tabellen, SID-Tabellen und Stammdaten eines Merkmals.

Abb. 8 : Erweitertes Star-Schema^[23]

Abbildung in dieser Leseprobe nicht enthalten

2.4.2.2.2 DataStore-Objects

Die DataStore-Objects (DSO) sind die Nachfolger der Operational Data Store (ODS). DSO-Objects dienen ebenso wie Basis-InfoCubes zur Aufnahme von Bewegungsdaten. Grundsätzlich wird in drei Typen von DataStore-Objects unterschieden:^[24]

- Standard
- Direktes Schreiben
- Schreiboptimiert

Die Typen „Standard“ und „Direktes Schreiben“ sind mit den Objekten des Operational Data Store weitgehend identisch. Der Typ „Schreiboptimiert“ wurde mit dem Ziel entwickelt, Daten so performant wie möglich zu speichern. Die Daten werden dabei per Insert in eine Tabelle 1:1 aus dem Quellsystem geschrieben.

DataStore-Objects können auch für das Reporting benutzt werden, was aber i.d.R. gravierende Performancenachteile zur Folge hat. Hauptsächlich dienen DSO-Objects als Speicherschicht, in der detaillierte Massendaten vorgehalten und im Rahmen von Extraktion und Staging genutzt werden.

2.4.2.2.3 InfoSets

Bei einem InfoSet handelt es sich um ein Metadaten-Objekt ohne eigene Datenhaltung. Erst zum Zeitpunkt der Datenanalyse werden die Daten aus einer definierten Datenquelle in ein InfoSet geladen. Datenquellen können z.B. InfoObjects, DSO-Objects und seit NetWeaver 2004s auch ein InfoCube sein, die für das Reporting genutzt werden sollen. Typische Einsatzgebiete für InfoSets ist z.B. das Stammdatenreporting.^[25]

2.4.2.2.4 MultiProvider

MultiProvider existieren, um Daten aus mehreren InfoProvidern in einen gemeinsamen Zusammen-hang zu bringen. Ein MultiProvider stellt eine zusätzliche logische Schicht über die zugeordneten InfoProvider dar. Weiterhin ist es auch möglich, dass ein InfoProvider Teil mehrerer MultiProvider ist.^[26]

Der Vorteil eines MultiProviders besteht darin, dass Queries der beteiligten InfoCubes parallel verarbeitet werden können.

Seit NetWeaver 2004s ist es möglich, Änderungen^[27] am Datenmodell durchzuführen, auch wenn bereits InfoProvider mit Daten befüllt ist.

2.4.2.3 Performancerelevanz

Die Modellierung der InfoProvider, insbesondere das Design der Basis-InfoCubes, ist aus Performancesicht extrem wichtig. Nur mit der richtigen Modellierungsstrategie lässt sich ein performantes System aufbauen, das den Anforderungen der Endanwender gerecht wird.

2.4.3 Weitere Möglichkeiten der Performanceverbesserung

Eine Performanceverbesserung kann auch durch folgende Aspekte erreicht werden:

- Komprimierung und Partitionierung
- Aggregation
- Indizierung
- Queries

2.4.3.1 Komprimierung und Partitionierung

Komprimierung und Partitionierung bieten die Möglichkeit einer Reduzierung der Daten im InfoCube selbst. Zusätzliche Objekte zur Datenhaltung, wie z.B. Aggregate, werden nicht erzeugt.

2.4.3.1.1 Komprimierung eines InfoCubes

Ein InfoCube besteht aus der normalen und aus der komprimierten Faktentabelle. Die normale Faktentabelle enthält eine Request-ID, mit der nach einem Ladevorgang einzelne, jeweils komplette Requests wieder aus dem InfoCube gelöscht werden können, wenn z.B. die Daten der letzten Beladung fehlerhaft waren. Die Request-ID bewirkt weiterhin, dass identische Datensätze mehrfach in der normalen Faktentabelle abgelegt werden, was zu einer Vergrößerung des Datenvolumens führt. Außerdem muss bei jeder Query-Ausführung über die Request-ID aggregiert werden. Diese beiden Faktoren bewirken einen Performanceverlust beim Reporting. Die komprimierte Faktentabelle enthält keine Request-ID und die Daten sind aggregiert.

Ein wesentlicher Nachteil der InfoCube-Komprimierung besteht darin, dass die Komprimierung nicht mehr rückgängig gemacht werden kann.^[28]

Abb. 9 : Zusammenspiel einer normalen und einer komprimierten Faktentabelle^[29]

Abbildung in dieser Leseprobe nicht enthalten

2.4.3.1.2 Partitionierung von InfoCubes

[Abbildung in dieser Leseprobe nicht enthalten] Bei der Partitionierung wird der Datenbestand in mehrere kleine, physisch selbständige und redundanzfreie Einheiten auf der Datenbank aufgeteilt. ^[30] Dadurch kann die Reportingperformance verbessert werden. Den Performancegewinn beim Reporting erhält man dadurch, dass mehrere Lesevorgänge parallel die einzelnen Partitionen durchsuchen können. Außerdem ist es möglich auf ein Partitionsmerkmal in einer Query einzuschränken, was zur Folge hat, dass nicht mehr der gesamte Datenbestand gelesen wird.

Abb. 10 : Partitionierung der Faktentabelle^[31]

Abbildung in dieser Leseprobe nicht enthalten

Das Business Warehouse stellt zwei Möglichkeiten der Partitionierung zur Verfügung:

- Partitionierung auf Datenbankebene
- Partitionierung auf Applikationsebene

Die Partitionierung auf Datenbankebene gliedert sich weiter auf in:

- Partitionierung der unkomprimierten Faktentabelle
- Partitionierung der komprimierten Faktentabelle

Die Partitionierung der normalen Faktentabelle erfolgt über die Request-ID und wird durch das Business Warehouse automatisch beim Anlegen eines InfoCubes vorgenommen und kann nicht verändert werden.

Die Partitionierung der komprimierten Faktentabelle erfolgt über die Zeitmerkmale Geschäftsjahr/ Periode (0FISCPER) oder Kalendermonat (0CALMONTH). Dabei muss mindestens eines der beiden Merkmale im InfoCube enthalten sein. Partitionen sollten nicht zu groß oder zu klein angelegt werden, da es sonst zu Performanceeinbußen kommt. Bei einem Zeitbereich weit in die Zukunft sollten zunächst nur zeitlich begrenzte Partitionen angelegt werden, da sonst viele Partitionen reserviert und frei bleiben. Ab dem Release SAP NetWeaver 2004s besteht die Möglichkeit der Repartitionierung gefüllter InfoCubes.^[32]

In den Fällen, in denen eine Partitionierung auf Datenbankebene nicht möglich ist, kann die Partitionierung auf Applikationsebene erfolgen. Diese Möglichkeit ist unabhängig von dem Datenbanksystem und Zeitmerkmalen. Die gewünschten Partitionen werden als eigene BasisCubes modelliert und mit Hilfe eines MultiProviders zusammengefügt.

[Abbildung in dieser Leseprobe nicht enthalten] Durch das Anlegen mehrerer InfoCubes wird nicht nur die Reportingperformance verbessert, sondern auch die Komplexität und der Wartungsaufwand des Datenmodells um ein Vielfaches gesteigert. Aus diesem Grund ist das Partitionieren auf Applikationsebene nur zu empfehlen, wenn die unbedingte Notwendigkeit dafür besteht.

Abb. 11 : Partitionierung der Faktentabelle auf Applikationsebene^[33]

Abbildung in dieser Leseprobe nicht enthalten

2.4.3.2 Aggregation

„Bei einem Aggregat handelt es sich um eine redundante Speicherung von Daten eines BasisCubes mit einer geringeren Detaillierung und/oder nur einer Teilmenge der Daten des BasisCubes.“^[34]

Aggregate orientieren sich an den Anforderungen des Reportings und können nachträglich aufgebaut werden. Die OLAP Engine trifft selbstständig die Entscheidung ob beim Reporting ein Aggregat oder der BasisCube verwendet wird. Für den Endanwender ist dieser Vorgang intransparent und nicht nachvollziehbar.

Um die Verringerung der Granularität in Aggregaten zu erreichen, wird nur eine Teilmenge der InfoObjects in die Aggregate übernommen. Dabei kann es sich um:

- Merkmale
- Zeitkonstante Navigationsattribute
- Zeitabhängige Navigationsattribute
- Hierarchieknoten

handeln, wobei alle InfoObjects innerhalb eines Aggregates kombiniert werden können.^[35]

2.4.3.3 Indizierung

Zur Verminderung von Suchzeiten während eines Lesevorgangs ist es möglich Indizes einzusetzen. Dabei ist in

- B-Tree-Indizes
- Bitmapped Indizes

zu unterscheiden.

Beim B-Tree-Index werden mit Hilfe von Zeigern (Verweisen) die gewünschten Datensätze gesucht, diese Zeiger können auf eine oder mehrere Spalten in einer Tabelle definiert werden. Der B-Tree-Index stellt alle Ausprägungen eines Feldes in einem binären Suchbaum dar, dessen jeweilige Knoten auf die entsprechenden Sätze der Datenbanktabelle verweisen. Bei einfachen Einschränkungen sind B-Tree-Indizes besonders gut geeignet, um die Performance von Abfragen zu verbessern.

Abb. 12 : B-Tree-Index^[36]

Abbildung in dieser Leseprobe nicht enthalten

Bitmapped Indizes besitzen Vorteile bei Merkmalen mit geringer Kardinalität, also möglichst wenigen Ausprägungen. Der Index wird nicht mehr als eine Baumstruktur abgebildet, sondern als eine Tabelle dargestellt. Für jede Ausprägung wird ein Bitmap-Feld erzeugt, das den Wert 1 erhält, wenn das Merkmal den Wert der Ausprägung besitzt. Ansonsten erhält das Bitmap-Feld den Wert 0. Dies ermöglicht den Datenbanksystemen die binäre Struktur von Bitmapped Indizes zu komprimieren, was zu einem geringeren Speicherplatzbedarf im Vergleich zu den B-Tree-Indizes führt.

Abb. 13 : Bitmapped Index

Abbildung in dieser Leseprobe nicht enthalten

Indizes bieten insbesondere für:

- BasisCubes
- InfoObjects
- DSO-Objects

Optimierungsmöglichkeiten. Bereits bei der Modellierung des BasisCubes werden die relevanten Tabellenfelder mit einem B-Tree-Index standardmäßig indiziert. Das bedeutet, dass bei Dimensionentabellen alle Felder, sowohl Dimensions-ID als auch die Stammdaten-ID mit B-Tree-Indizes versehen werden. Bitmapped Indizes sind bei Dimensionentabellen nicht vorgesehen.

Beim Anlegen der Faktentabellen hat der Anwender die Möglichkeit zwischen B-Tree-Index und Bitmapped Index für die Dimensions-ID zu wählen. Abhängig ist dies von der Kardinalität (Verhältnis der Anzahl der Datensätze) zwischen Faktentabelle und Dimensionentabelle.^[37]

Indizes können auch für InfoObjects eingesetzt werden, standardmäßig werden aber keine Indizes verwendet. Sinnvoll ist der Einsatz von Indizes bei Navigationsattributen, die nicht zur Navigation in Queries (Drill Down), sondern auch zur Selektion von Daten eingesetzt werden.

2.4.3.4 Queries

Die Queries bieten Performance-Optimierungspotential hinsichtlich der Einstellungen der Query-Eigenschaften. Besonders der Lesemodus und der Cachemodus einer Query bestimmt, wie oft der OLAP-Prozessor bei der Navigation die Daten von der Datenbank nachlädt.

Auch der Aufbau einer Query, welche Arten der Merkmalseinschränkungen gewählt werden, ob z.B. über einen Range-Bereich oder jedes Merkmal einzeln selektiert wird, spielt bei der Reportingperformance eine große Rolle.

2.4.4 Werkzeuge für Analysen und Berichte

Das SAP Business Warehouse stellt eine Vielzahl von Analyse- und Reportingwerkzeugen zur Verfügung. Dabei ist in die SAP-eigenen Tools und Third-Party-Tools zu unterscheiden. Die SAP Reportingtools sind in dem SAP BEx (Business Explorer) zusammengefasst. Das neue Release SAP NetWeaver 2004s enthält einen „Report Designer“ für die Formatierung von Berichten.

Die Queries der Reports werden ausschließlich mit dem Query Designer erstellt.

Abb. 14 : Komponenten der Business Explorer Suite^[38]

Abbildung in dieser Leseprobe nicht enthalten

2.5 Werkzeuge der Performanceanalyse

Dieses Kapitel gibt einen Überblick über die wichtigsten Werkzeuge der Performanceanalyse die das SAP BW zur Verfügung stellt. Es ist dabei grundsätzlich zu unterscheiden in:

- Analyse von Datenbank, Speicher und Hardware
- Analyse der Systemlast

2.5.1 Analyse von Datenbank, Speicher und Hardware

Die Werkzeuge der Performanceanalyse sind die SAP-Performancemonitore, die sich alle mittels der Transaktion STUN aufrufen lassen. Dieses Kapitel beschreibt die wichtigsten Transaktionen und hat nicht den Anspruch auf Vollständigkeit, da dies ein sehr umfangreiches Wissen seitens Systemtechnik und Datenbankadministration voraussetzt und nicht Teil dieser Diplomarbeit ist. Die folgenden angegebenen Werte beziehen sich auf ein Oracle-Datenbanksystem und werden von SAP als Richtwerte vorgegeben. Weiterhin gilt es zu beachten, dass die Analyse bei einem „eingeschwungenen“^[39] System zu erfolgen hat, da sonst die Werte abweichen können.

2.5.1.1 Datenbank

Mit der Transaktion ST04 gelangt der Anwender zu dem zentralen Datenbankmonitor. Den größten Einfluss auf die Datenbankperformance hat der „Data Buffer“, der Benutzerdaten (Tabelleninhalte) und Verwaltungsinformationen der Datenbank im Hauptspeicher speichert, um die langsameren Festplattenzugriffe zu reduzieren.^[40]

Der „Shared Pool“ ist ein gemeinsam genutzter Speicherbereich, der Strukturen des Data-Dictionary-Cache und des Shared-SQL-Bereichs enthält.

Alle Änderungen der Datenbank werden in dem „Log Buffer“ protokolliert. Das bedeutet, dass für jede Datenänderung ein „Redo-Eintrag“ erzeugt wird, mit dem die Datenänderungen bei einer Wiederherstellung der Daten in einen früheren Zustand rekonstruiert werden.

[Abbildung in dieser Leseprobe nicht enthalten] Abfragen eines Datenbanksystems werden als „Calls“ bezeichnet. Besonders wichtig ist der Parameter „Reads/User calls“, der das Verhältnis der aus dem Datenpuffer gelesenen Blöcke zur Gesamtzahl der Anfragen an die Datenbank seit dem Start der Datenbank angibt. Ist dieser Wert sehr hoch, ist dies schon ein erster Hinweis auf zu teure und komplexe Queries.

Abb. 15 : Datenbankmonitor (Transaktion ST04)

Abbildung in dieser Leseprobe nicht enthalten

Bei den „Table Scans“ wird festgestellt, wie viel vollständige Tabellendurchsuchungen durchgeführt werden, wenn die gesamte Tabelle gelesen wird, ohne dafür einen Index zu verwenden. Dabei wird unterschieden in „Short table scans“ und „Long table scans“. „Short Tables“ haben eine Tiefe von weniger als fünf Datenblöcken und deswegen ist die Suche ohne Indizes oftmals günstiger als die Suche mit Indizes. Anders verhält es sich bei den „Long Table“, hier ist die Suche mit einem Index vorteilhaft. Der Anteil der „Long table scans“ an allen „Table scans“ sollte sehr klein sein, andernfalls deutet dies auf das Fehlen von Indizes hin. Fehlende und fehlerhafte Indizes können auch mit der Transaktion DB02 ermittelt werden.

Abb. 16: Übersicht der Datenbankvorgabewerte der
SAP AG

In der nebenstehenden Übersicht sind die wichtigsten Rubriken des Datenbankperformance-Monitors zusammengefasst mit den Vorgabewerten der SAP.

2.5.1.2 Speicher

Die SAP-Speicherbereiche werden mit der Transaktion ST02 – SAP-Memory-Management-Monitor analysiert. Der Hauptbildschirm teilt sich in die Bereiche SAP-Puffer und SAP-Memory auf.

Abb. 17 : SAP-Memory-Management-Monitor (Transaktion ST02)

Abbildung in dieser Leseprobe nicht enthalten

Der wichtigste Faktor der Kennzahlen des SAP-Puffers ist der „Hitratio“, der die Trefferrate des Puffers bedeutet. Dieser Wert sollte laut SAP bei allen Puffern größer als 98 Prozent sein. Weitere wichtige Faktoren sind der „Free space“ und „Free directory“. Diese Werte sollten bei einem eingeschwungenen System größer als 10 Prozent sein. Außerdem sollten keine Swaps^[41] auftreten, ansonsten muss der Puffer vergrößert bzw. die maximale Anzahl der Puffereinträge erhöht werden.^[42]

Bei dem SAP-Speicher gilt es zu beachten, dass das System nicht in einen Speicherengpass läuft. Das Sizing ist von SAP-System zu SAP-System unterschiedlich. Es kann dazu keine allgemeingültige Aussage getroffen werden.

2.5.1.3 Hardware

Der Betriebssystemmonitor wird mit der Transaktion ST06 aufgerufen. Hier stehen die wichtigsten Parameter für CPU- und Hauptspeicherauslastung zur Verfügung, wie z.B.:

- Verbrauch von virtuellem und physischem Speicher
- CPU-Auslastung
- Auslastung von physischen Festplatten und Dateisystemen
- Ressourcenverbrauch laufender Prozesse

Die Daten werden aufgezeichnet und die stündlichen Durchschnittswerte der letzten 24 Stunden gebildet. Damit besteht die Möglichkeit, Engpässe des Systems in Abhängigkeit der Tageszeit festzustellen. Zusätzlich lassen sich die SAP-Workprozesse (Transaktion SM50) identifizieren, die den hohen CPU-Verbrauch verursachen.

2.5.2 Analyse der Systemlast

Der zentrale Bestandteil einer Performanceuntersuchung ist die Analyse der Systemlast. Es ist dabei die allgemeine Systemlast und die BI-Systemlast zu unterscheiden.

Die allgemeine Systemlast des SAP-Systems ist nach Applikationen, also nach Programmen, Transaktionen, Funktionsbausteinen etc. gegliedert. Für jeden Transaktionsschritt im System werden Statistikdaten gesammelt, die zu Lastprofilen verdichtet und untersucht werden können.

Die BI-Systemlast ist ein spezielles Lastprofil, mit dem sich BI-Queries und BI-Ladeprozesse detailliert untersuchen lassen. Zentrales Werkzeug der Performanceuntersuchung ist der BI-Systemlastmonitor, der mit der Transaktion ST03N aufgerufen wird.

Für die Verwendung des BI-Systemlastmonitors muss der technische Content BI-Statistik ausgepackt werden. Dieser beinhaltet eine Reihe von InfoPackages, DataSources, Transformationen, Fortschreibungsregeln und InfoCubes, die für das Reporting benötigt werden. Die Aufzeichnung von Statistikdaten bei Queryausführungen wird in dem InfoCube 0TCT_C01 protokolliert.

Die zu berücksichtigenden InfoCubes und Queries müssen explizit in die Protokollaufzeichnung^[43] aufgenommen werden. Seit BW 7.0 ist es auch möglich, WebTemplates und Workbooks in die Protokollaufzeichnung aufzunehmen. Aggregate können nicht in die Protokollaufzeichnung aufgenommen werden. Bei der Ausführung einer Query werden die Laufzeiten der Aggregate automatisch durch den OLAP-Prozessor berücksichtigt. Bei MultiProvider-Queries werden die an der Query beteiligten InfoCubes in den Statistikdaten nicht aufgenommen. Somit wird nur die Query-Gesamtlaufzeit des MultiProviders ermittelt, nicht aber die einzelnen Laufzeitanteile der beteiligten InfoCubes.^[44]

Abb. 18 : Systemlastmonitor (Transaktion ST03N)

Abbildung in dieser Leseprobe nicht enthalten

[...]

---

^[1] Die Trex-Technologie ermöglicht parallele Indizierungsfunktionen für die Aufbereitung von Geschäftsinformationen im
Hauptspeicher.

^[2] Vgl. IDG-Publikationen im Internet, http://www.computerwoche.de/produkte_technik/business_intelligence/543007/
(5.10.2006)

^[3] Woods, Dan; u.a.: SAP NetWeaver for Dummies, 1. Auflage, Indianapolis 2004, S. 11.

^[4] Quelle: Woods, Dan; u.a.: SAP NetWeaver for Dummies, 1. Auflage, Indianapolis 2004, S. 11, Figure 1-1.

^[5] Vgl. SAP Help Portal, http://help.sap.com/saphelp_nw04/helpdata/de/e3/e60138fede083de10000009b38f8cf/frameset.htm/
(18.10.2006)

^[6] Vgl. Schröder, Thomas: SAP BW Performanceoptimierung, 1. Auflage, Bonn 2006, S. 95.

^[7] Quelle: SAP Help Portal, http://help.sap.com/saphelp_nw04/helpdata/de/e3/e60138fede083de10000009b38f8cf/frameset.htm/
(12.10.2006)

^[8] Hardwareressourcen: CPU, Hauptspeicher, Festplattenkapazität, usw.

^[9] http://service.sap.com/quicksizer

^[10] Vgl. Egger, Norbert; u.a.: SAP BW Datenmodellierung, 1. Nachdruck, Bonn 2004, S. 69.

^[11] Vgl. Mehrwald, Christian: Datawarehousing mit SAP 3.5, 3. Auflage, Heidelberg 2005, S. 8.

^[12] Vgl. Egger, Norbert; u.a.: SAP BW Datenbeschaffung, 1. Auflage, Bonn 2005, S. 69.

^[13] Vgl. Egger, Norbert, u.a.: SAP BW Datenmodellierung, 1. Nachdruck, Bonn 2004, S. 71ff.

^[14] Quelle: Egger, Norbert, u.a.: SAP BW Datenmodellierung, 1. Nachdruck, Bonn 2004, S. 140, Abbildung 5.1.

^[15] Vgl. Mehrwald, Christian: Datawarehousing mit SAP 3.5, 3. Auflage, Heidelberg 2005, S. 177f.

^[16] Vgl. Mehrwald, Christian: Datawarehousing mit SAP 3.5, 3. Auflage, Heidelberg 2005, S. 104f.

^[17] Quelle: SAP Help Portal, http://help.sap.com/saphelp_nw04/helpdata/de/0f/903d41d4cc4c0de10000000a1550b0/frame-
set.htm/ (21.11.2006)

^[18] Vgl. SAP Help Portal, http://help.sap.com/saphelp_nw04/helpdata/de/0f/903d41d4cc4c0de10000000a1550b0/frameset.htm/
(21.11.2006)

^[19] Im SAP BW 3.5 als „Transaktionaler InfoCube“ bekannt.

^[20] Es gibt die „normale“ F-Faktentabelle und die komprimierte E-Faktentabelle. Die Struktur der beiden Faktentabellen ist
identisch, wobei die komprimierte Faktentabelle weniger auf die Administration und Durchführung von Ladevorgängen,
sondern vielmehr auf analytische Performance optimiert ist. Die Nutzung der komprimierten Faktentabelle ist optional.
Ohne vorherige Einstellung wird die komprimierte Faktentabelle im BW nicht verwendet.

^[21] Jede Dimension kann maximal 248 InfoObjects aufnehmen.

^[22] Schröder, Thomas: SAP BW Performanceoptimierung, 1. Auflage, Bonn 2006, S. 95.

^[23] Quelle: Schröder, Thomas: SAP BW Performanceoptimierung, 1. Auflage, Bonn 2006, S. 95, Abbildung 6.2.

^[24] Vgl. Egger, Norbert; u.a.: Business Intelligence, 1. Auflage, Bonn 2006, S. 86.

^[25] Vgl. Mehrwald, Christian: Datawarehousing mit SAP 3.5, 3. Auflage, Heidelberg 2005, S. 116.

^[26] Ebd., S. 118.

^[27] Es lassen sich nachträglich Merkmals- und Kennzahländerungen an InfoCubes durchführen.

^[28] Vgl. Schröder, Thomas: SAP BW Performanceoptimierung, 1. Auflage, Bonn 2006, S. 374.

^[29] Quelle: Mehrwald, Christian: Datawarehousing mit SAP 3.5, 3. Auflage, Heidelberg 2005, S. 158, Abbildung 8.26.

^[30] Vgl. Schröder, Thomas: SAP BW Performanceoptimierung, 1. Auflage, Bonn 2006, S. 376.

^[31] Quelle: Mehrwald, Christian: Datawarehousing mit SAP 3.5, 3. Auflage, Heidelberg 2005, S. 124, Abbildung 8.1.

^[32] Vgl. Schröder, Thomas: SAP BW Performanceoptimierung, 1. Auflage, Bonn 2006, S. 380f.

^[33] Quelle: Schröder, Thomas: SAP BW Performanceoptimierung, 1. Auflage, Bonn 2006, S. 382, Abbildung 12.6.

^[34] Mehrwald, Christian: Datawarehousing mit SAP 3.5, 3. Auflage, Heidelberg 2005, S. 143.

^[35] Vgl. Mehrwald, Christian: Datawarehousing mit SAP 3.5, 3. Auflage, Heidelberg 2005, S. 145.

^[36] Quelle: Mehrwald, Christian: Datawarehousing mit SAP 3.5, 3. Auflage, Heidelberg 2005, S. 114f., Abb. 8-6

^[37] Vgl. Mehrwald, Christian: Datawarehousing mit SAP 3.5, 3. Auflage, Heidelberg 2005, S. 135.

^[38] Quelle: Egger, Norbert; u.a.: Business Intelligence, 1. Auflage, Bonn 2006, S. 86, Abbildung 2.5.

^[39] “Eingeschwungenes” System bedeutet, dass nach dem Neustart des Systems zwei bis drei Tage im Produktivbetrieb
vergangen sein müssen.

^[40] Vgl. Schröder, Thomas: SAP BW Performanceoptimierung, 1. Auflage, Bonn 2006, S. 130ff.

^[41] Anzahl der Verdrängungen aus dem Puffer in den Swap-Space.

^[42] Vgl. Schröder, Thomas: SAP BW Performanceoptimierung, 1. Auflage, Bonn 2006, S. 148f.

^[43] Die relevanten InfoCubes müssen in die Data Warehousing Workbench (Werkzeuge à BI Statistik Einstellungen) eingestellt
werden.

^[44] Vgl. Schröder, Thomas: SAP BW Performanceoptimierung, 1. Auflage, Bonn 2006, S. 173ff.