SAP Career Guide - A beginner’s manual on SAP careers for students and professionals

Themen werden sehr gut erklärt und mit anschaulichen Beispielen beschrieben.

N. Hildebrandt

Performance-Optimierung für SAP BW

Kennen Sie das auch? Die Geschwindigkeit ihres Data Warehouse Systems sinkt kontinuierlich – was eigentlich als Arbeitserleichterung gedacht war, löst zunehmend Unzufriedenheit aus. Mit diesem Buch lernen Sie, welche verschiedenen Faktoren dafür verantwor...

Leseprobe
10% Rabatt

Jetzt 10% Rabatt sichern! Melden Sie sich für unseren Newsletter an und erhalten Sie 10% Rabatt auf das Digital-Abo für unsere SAP-Lernplattform!

Inhaltsverzeichnis

  • Einleitung
  • 1 Grundlegende Betrachtungen
  • 2 Grundlagen der SAP BW-Datenhaltung
  • 3 Datenmodellierung aus Sicht der Performance
  • 4 Performancemessungen und deren Interpretation
  • 5 Performance-Optimierung
  • 6 Möglichkeiten der Archivierung
  • 7 Housekeeping-Konzept
  • 8 Zusammenfassung und Ausblick
  • 9 Glossar
  • A Über den Autor
  • B Disclaimer

Weitere Informationen

Autor/in:

Helmut Tack

Katgorie:

Analytics

Sprache:

Deutsch

Leseprobe

2.1 Flache Datenspeicher

Bei flachen Datenspeichern handelt es sich um BW-Objekte, die sich technisch als einfache Tabellen mit Kopf und Zeilen darstellen lassen. Im Kopf befinden sich die Felder, über die Tabellenspalten gebildet werden, während sich in den Zeilen die gespeicherten Informationen befinden.

Diese Tabellen können mit anderen in einer Relation stehen (siehe Abbildung 2.4). Besteht eine Beziehung zu einer oder mehreren anderen Tabellen auf Schlüsselebene, sprechen wir von einer Primär-Fremdschlüsselbeziehung. Die Fremdschlüssel beschaffen (verweisen auf) Werte in der verbundenen Tabelle.

Manche Tabellen stehen allerdings nicht in Relation zueinander, sondern bilden mit anderen Tabellen einen speziellen Modelltyp. Wie sich diese Beziehungen aufbauen können, soll Ihnen die folgende einfache Grafik verdeutlichen (siehe Abbildung 2.3).

Aus einer Reihe von Datenbanktabellen werden Informationen verwendet, um einen flüchtigen Datenwert (Bewegungsdatum) innerhalb eines Datenspeichers zu adressieren. Adressieren ist meiner Ansicht nach in diesem Zusammenhang der wohl beste Ausdruck, da die Kombination der verwendeten Stammdatenschlüssel eine eindeutige Datenbankadresse bildet. Dieser Schlüssel ist wiederum normalisiert und eindeutig.

HTML Performance

Abbildung 2.3: Adressierung über Schlüssel

Wie Sie in der Abbildung sehen, befinden sich aus Sicht der Datenbank an derselben Adresse zwei verschiedene Kunden, die unterschiedliche Umsätze generiert haben.

Über ein solches Konstrukt werden in der Regel Stammdaten am InfoProvider miteinander kombiniert und somit die Bewegungsdaten eindeutig den Stammdaten zugeordnet. Auf Stammdatenebene lassen sich dadurch zeitliche Gültigkeiten, Sprachversionen und Hierarchien abbilden und miteinander verknüpfen, was insbesondere bei der mehrdimensionalen Modellierung erhebliche Vorteile hat.

HTML Performance

Abbildung 2.4: Prinzip flacher Datenbankobjekte

2.1.1 Merkmale

Merkmale sind in SAP BW die Speicher von unveränderlichen oder selten veränderlichen Werten. Solche Tatsachen können sein:

technische Tatsachen:

Mit welchem Vorgang wurde ein Datensatz geladen (z.B. Request-Nummer)?,

Einheiten-Tatsachen:

Welche Einheit ist zu einem Bewegungsdatum zu verwenden (z.B. Tonnen)?,

zeitliche Tatsachen:

Zu welchem Zeitpunkt ist ein Bewegungsdatum im Kontext eines Vorganges entstanden (z.B. Tag: 10, Monat: Januar, Jahr: 2013)?,

organisatorische (betriebliche) Tatsachen:

Welcher Vorgang hat das Bewegungsdatum erzeugt (z.B. Verkaufsbeleg)?

2.1.2 Merkmale mit Stammdaten

Eine besondere Form stellen Merkmale mit Stammdaten dar. Dabei beschreiben ein oder mehrere Merkmale, Kennzahlen oder Hierarchien ein sogenanntes Trägermerkmal und machen es dadurch eindeutiger. Technisch gesehen kommt es zu einer Tabellenkaskade.

HTML Performance

Abbildung 2.5: Attribut Kaskade

Berechnung der Ausprägungstiefe eines Merkmals

Lassen Sie uns die Kombinationsmöglichkeiten berechnen:

((1 Erde * 3 Kontinente) * 3 Länder) * 3 Bundesländer = 27 Ausprägungen

Unser Beispiel besagt, dass das Objekt »Erde« über direkte und indirekte Eigenschaften siebenundzwanzig unterschiedliche Zustände hat, also siebenundzwanzig Datensätze pro Datenverarbeitungsvorgang erzeugen kann. Wenn Sie wollen, können Sie gern die tatsächlichen Ausprägungen von »Erde« errechnen.

Stammdaten können nur sich selbst und ihre Werte (Werteliste) liefern oder über Attribute, Texte und Hierarchien das Trägermerkmal beschreiben und es damit konkretisieren. Erlangt ein Merkmal über seine Attribute eine Konkretisierung, nennen wir diesen Zustand Ausprägung. Dabei kann das Trägermerkmal durchaus seine eigenen Werte aufweisen (Erde = Kontinent).

Die Werte der Attribute des Trägermerkmals verhalten sich wie solche in der Werteliste des Trägermerkmals. Das bedeutet, dass im Reporting wie auch im Berichtsdesign ein Merkmal seine eigenen Werte sowie die des Attributs oder der Hierarchie, in einem Kontextmenü als Filterwert zur Verfügung stellt.

Wird ein Trägermerkmal durch Objekte und deren Werte beschrieben, so geschieht das nicht durch die Werte selbst, sondern durch Ersatzschlüssel (Surrogat-ID). Diese Ersatzschlüssel verweisen auf die Stammdatenschlüssel in der Stammdatentabelle des Attributs und werden in der Surrogat-Tabelle des Trägermerkmals abgelegt. Damit ist sichergestellt, dass jedes Objekt unendlich oft verwendet werden kann. Attribute lassen sich grundsätzlich differenzieren in:

  • Anzeigeattribute,
  • zeitabhängige Attribute,
  • Navigationsattribute,
  • zeitabhängige Navigationsattribute,
  • Texte mit und ohne Sprachabhängigkeit und oder Zeitabhängigkeit,
  • Hierarchien.

Durch diese Attribute wird eine extrem hohe Flexibilität und Wiederverwendbarkeit der Objekte erreicht. Somit benötigen Sie nur jeweils ein Objekt. Lassen Sie uns das notwendige Tabellenkonstrukt einmal in Abbildung 2.6 ansehen:

HTML Performance

Abbildung 2.6: Surrogat-Tabelle

Die jeweiligen Objekte Ort, Strasse, Nummer, Auftraggeber und Warenempfänger sind nicht fest an Kunden gebunden und können durchaus auch aus einer Hierarchie stammen. So freut sich Frau Meyer bestimmt darüber, dass sie auch an anderen Orten Waren empfangen kann.

Jede Form eines Stammdatums wird in speziellen Tabellen verwendet, die in einer Beziehung zum Trägermerkmal stehen, ohne fest an dieses gebunden zu sein.

Da sich die Werte eines Attributs wie eine Werteliste des Trägermerkmals verhalten, gilt bei Navigationsattributen größte Vorsicht (siehe Abbildung 2.7). Große Navigationsattribute können schnell das Datenmodell sprengen und deutlich verlangsamen.

Berechnung der möglichen Ausprägungen aus der Praxis

Lassen Sie uns einmal ein echtes Szenario rechnen:

Ihr Unternehmen hat 2.432 Kunden. Jeder Kunde darf jedes Produkt erwerben.

Sie haben 21.788 Artikel in 214 Warengruppen. Jede Warengruppe hat in allen vier Saisons Gültigkeit.

Daraus ergibt sich, dass es für das Objekt »Kunde« technisch gesehen 45.358.084.096 Kombinationsmöglichkeiten während der Datenhaltung und während der Navigation im Reporting gibt.

HTML Performance

Abbildung 2.7: Exponentielles Wachstum der Datenlast bei Navigationsattributen

Es handelt sich dabei zwar um eine Worst-case-Berechnung, sie verdeutlich jedoch, dass Daten sich schnell vervielfachen können. Sie müssen gelesen, geladen und gepuffert werden.

Navigationsattribute und Performance

Die exzessive Verwendung von Navigationsattributen führt zu erheblichen Performanceverlusten.

Klammerung statt Attribut

Erwägen Sie im Modell die Verwendung von Klammerungen im Merkmal. Die Klammerung bindet das zusätzliche Objekt nicht an das Trägermerkmal.

Eine weitere Besonderheit bietet die Möglichkeit, ein Trägermerkmal über Attribute zu konkretisieren. Das mutet eher normal an. Ich will Ihnen aber zeigen, wie ungewöhnlich dieses Konstrukt sein kann.

Stellen wir uns vor, wir sollen folgende Reportmöglichkeit physisch modellieren:

Wie hoch sind die Produktionskosten für Furniermaschinen, die das Modul »Kantenglätter« verwenden?

Ziehen wir dazu unsere Tabellensicht zurate:

HTML Performance

Abbildung 2.8: Beziehung Produktionskosten zu Merkmalen

Wir stellen fest, dass das Objekt »Produktionskosten« zu den Merkmalen MACHINE und Modul in Beziehung steht. Das bedeutet für uns, dass wir das Merkmal Modul einfach an dem Trägermerkmal MACHINE als Attribut verwenden können. Im Reporting könnten wir dann über eine konstante Selektion festlegen, dass im Modell die Anforderungen für den Bericht sichergestellt sind.

Damit »Modul« nicht einfach als eigenständiges Merkmal verwendet werden kann, können wir den Schalter Ausschließlich Attribut im Merkmal Modul setzen.

Leider ist das zu kurz gedacht. Da die Werte eines Attributs durch eine Surrogat-ID (S-ID) am InfoProvider bekannt gemacht werden, stehen auch alle nicht benutzten Module sämtlicher Maschinen als Dimensions-ID (DIM-IDs) am InfoCube bereit. Wir erzeugen Metadaten, die wir nicht benötigen und verlangsamen damit die Leseperformance.

Die Lösung lautet Klammerung! Dazu werden wir das Objekt MACHINE um ein neues, und darüber das Objekt MACHINE erweitern.

Wir modellieren ein neues Merkmal KMODUL, welches den konstanten Wert »Kantenglätter« trägt (siehe Abbildung 2.9). Das Merkmal KMODUL referenziert auf das Merkmal MODUL und verwendet dadurch dessen Werte.

HTML Performance

Abbildung 2.9: Merkmal KMODUL mit Konstante

Danach ordnen Sie dem Merkmal MACHINE Ihr neues Merkmal KMODUL als geklammertes hinzu (siehe Abbildung 2.10). Nehmen Sie in Ihrem InfoCube das Merkmal MACHINE auf. Das geklammerte Merkmal und das Navigationsattribut werden mit aufgenommen (siehe Abbildung 2.11).

HTML Performance

Abbildung 2.10: Merkmal MACHINE im InfoCube

HTML Performance

Abbildung 2.11: Automatische Übernahme der Merkmale

Vergessen Sie nicht, am InfoCube das Navigationsattribut für Ihr Merkmal MODUL einzuschalten!

Nun können Sie alle drei Merkmale in einer Query als eigenständiges InfoObjekt verwenden, z.B., um Umsatzunterschiede zwischen den Maschinen mit und ohne Kantenglätter zu vergleichen.

Die Klammerung hat darüber hinaus den Vorteil, dass Sie von InfoProvider zu InfoProvider entscheiden können, ob Sie KMODUL gemeinsam mit MACHINE verwenden wollen, bzw., ob Sie nur KMODUL verwenden wollen, aber MACHINE nicht und umgekehrt.

Wenn wir uns das erzeugte Datenmodell ansehen, wird uns schnell klar, was da passiert ist: Unser Objekt MODUL erscheint zweimal, was ja eigentlich nicht geht: einmal als MODUL mit Konstante und einmal als Navigationsattribut zu MACHINE (siehe Abbildung 2.12).

HTML Performance

Abbildung 2.12: Datenmodell nach Klammerung

Legen wir eine Transformation zwischen MACHINE und dem InfoCube an (siehe Abbildung 2.13), so stellen wir fest, dass KMODUL uns als Quelle in der konstanten Variante zur Verfügung steht. Wir könnten unseren Cube demnach gezielt mit Daten zur Kombination »Maschine mit Kantenglättern« füllen. Das hält ihn schlank und unsere Performance hoch.

HTML Performance

Abbildung 2.13: Fortschreibung von KMODUL

2.1.3 DataStore-Objekte

Eine weitere Form flacher Datenziele sind die sogenannten DataStore-Objekte (DSO).

Grundsätzlich werden drei DSO-Varianten unterschieden:

  • Standard–DSO,
  • schreiboptimiertes DSO,
  • DSO für direktes Schreiben/mit direkter Fortschreibung.

Aus Sicht der Performance ist das Standard-DSO von besonderem Interesse. Es verfügt über drei physische Tabellen, die zum selben Modell gehören. Die Datenfortschreibung erfolgt über korrespondierende Felder.

Jedes DSO modelliert sich über mindestens ein Schlüsselfeld und mindestens ein Datenfeld. Schlüsselfelder sind immer Merkmale, Datenfelder können Merkmale und/oder Kennzahlen sein. Ein DSO kann keine Bewegungsdaten aggregieren oder komprimieren.

Sehen wir uns das Modell eines Standard-DSO in Abbildung 2.14 einmal genauer an:

HTML Performance

Abbildung 2.14: Standard-DSO-Modell

Die Activation Queue ist die Eingangsschicht des DSOs. Jeder reguläre Datenladevorgang richtet sich gegen diese Tabelle.

Bei Aktivierung der Datenrequests (vgl. Abschnitt Requestverarbeitung und 5.9) werden diese 1:1 in die Change Log-Tabelle fortgeschrieben und anschließend aus der Activation Queue entfernt. Parallel werden die Daten ohne technischen Schlüssel in die Active Data-Tabelle fortgeschrieben.

Daten, auf die berichtet wird, sind die der Active Data-Tabelle. Werden die neuen Daten, wie das Beispiel in nachfolgender Abbildung 2.15 zeigt, nur angehangen, erfolgt zur Berichtszeit die Berechnung aller Einzelwerte zu einem Gesamtwert. Wie dies vonstattengeht, hängt vom Aggregationsverfahren der Kennzahl ab. Das Beispiel in Abbildung 2.15 geht von einer Summation aus.

HTML Performance

Abbildung 2.15: Ergebnis im Reporting

Ein DSO ermöglicht auf Ebene der Active Data-Tabelle die folgenden Operationen:

After Image (siehe Abbildung 2.16):

  • Es wird über dem bestehenden der neue Satz geschrieben.
  • Die Active Data-Tabelle vergrößert sich nicht.
  • Die Veränderung ist in der Change Log nachvollziehbar.

HTML Performance

Abbildung 2.16: After Image

Before Image/After Image (siehe Abbildung 2.17):

  • Es werden erst ein Entlastungssatz und dann ein Satz mit den neuen Werten geschrieben.
  • Die Active Data-Tabelle vergrößert sich um zwei Sätze.
  • Die Veränderung ist in der Change Log nachvollziehbar.

HTML Performance

Abbildung 2.17: Before Image/After Image

Additive Image (siehe Abbildung 2.18):

  • Es wird ein neuer Datensatz angehängt.
  • Die Active Data-Tabelle vergrößert sich um einen Satz.
  • Die Veränderung ist in der Change Log nachvollziehbar.

HTML Performance

Abbildung 2.18: Additive Image

Delete Image (siehe Abbildung 2.19):

  • Es wird ein bestimmter Datensatz entleert.
  • Die Active Data-Tabelle verändert sich nicht.
  • Die Veränderung ist in der Change Log nachvollziehbar.

HTML Performance

Abbildung 2.19: Delete Image

Besonderheit beim Delete Image

Glauben Sie nicht, dass sie mit »Delete Images« Ihre Active Data-Tabelle schlank halten können! Der Satz wird nur entleert, aber nicht gelöscht (siehe Abbildung 2.19)!

Reverse Image (siehe Abbildung 2.20):

  • Es wird nur ein Entlastungssatz geschrieben.
  • Die Active Data-Tabelle vergrößert sich.
  • Die Veränderung ist in der Change Log nachvollziehbar.

HTML Performance

Abbildung 2.20: Reverse Image

Da sich die Daten der Change Log pro Ladeprozess erhöhen, besteht hier die Gefahr, dass nicht mehr notwendige Daten aufbewahrt werden und das Datenbanksystem unnötig belasten.

Das Aufbewahren der Ladehistorie ist nur dann sinnvoll, wenn die Datenbestände des DSOs nicht in andere Ziele fortgeschrieben wurden oder aus Revisionsgründen die Daten aufbewahrt werden müssen. In beiden Fällen bietet sich jedoch die Archivierung der nicht mehr benötigten Requests an.

Fortschreibungsquelle aus Standard-DSOs

Denken Sie daran, dass die Fortschreibung bei Standard-DSOs, nach Initialisierung des Initialdatenbestandes im Ziel, aus der Change Log erfolgt.

Überdimensionierte Change Log-Tabelle

Hier ein Beispiel aus der Praxis:

Ein Kunde beklagte zunehmende Ladezeiten bei der Fortschreibung innerhalb des BW. Eine Analyse zeigte, dass sein Konsolidierungs-DSO mit alten Daten überfrachtet war. Abbildung 2.21 lässt sehr gut erkennen, dass der Datenbestand der Change Log fast doppelt so hoch wie die Active Data war.

HTML Performance

Abbildung 2.21: Beispiel-Change Log zu Active Data

Alle Inhalte. Mehr Informationen. Jetzt entdecken.

et.training - Ihre Lernplattform für SAP-Software

  • Zugriff auf alle Lerninhalte1
  • Regelmäßige Neuerscheinungen
  • Intelligenter Suchalgorithmus
  • Innovatives Leseerlebnis
  • Maßgeschneidere Lernpfade
  • Zertifikate & QA-Tests2

Sie haben bereits ein Konto?

1 Sie erhalten Zugriff auf alle Lerninhalte. Online-Trainings, Zertifikate sind NICHT Teil der Flatrate.

2 Weitere Informationen auf Anfrage.