Performance-Optimierung für SAP BW

Für Datenbanksysteme, die bereits einige Jahre im Betrieb laufen, wird die Performance zunehmend zum zentralen Thema der IT- und Fachbereichsverantwortlichen. In Zeiten von Massendaten und stetig wachsender Datenbestände wird nicht allein die Analysefähigkeit und Qualität solcher Datenbestände, sondern vor allem die Garantie einer schnellen Datenverfügbarkeit zur besonderen Herausforderung.

Jeder Beteiligte, vom Anwender über den Administrator bis zum Entwickler, hat seine ganz eigene Sicht auf das Thema Performance. Es gilt, einen Konsens bzgl. der Anforderungen und Betrachtungsweisen zu finden, ohne eine der beteiligten Gruppen zu benachteiligen.

Performance-Optimierung für SAP BW

Auf Ebene der Datenhistorie kommt es häufig zu Konflikten in den Sichtweisen. So wünschen sich etwa

• Administratoren einfach zu wartende Modelle,
• Entwickler eine hohe Entwicklungsgeschwindigkeit,
• Designer, wenig zu programmieren und
• User schnelle wie auch genaue Berichtergebnisse.

Im Rahmen der Performanceoptimierung gilt der Grundsatz: So viel Informationen wie nötig in so schlanken Datenmodellen wie möglich vorhalten. Dabei sollte selbstverständlich die Revisionshistorie aller Datenbestände garantiert sein.

Grundlegende Betrachtungen

Werkzeuge zur Datenanalyse reichen von einfachen Anwendungen bis hin zu komplexesten Lösungen. Ein wesentlicher Unterschied besteht in der Art der Datenhaltung. Eine davon ist das sogenannte Data Warehouse. In diesem Kapitel möchte ich Sie mit den grundlegenden Prinzipien der Datenhaltung in SAP Business Warehouse vertraut machen, um Ihnen das Verständnis der darauffolgenden Kapitel zu erleichtern.

Zur Analyse von Daten steht Ihnen heute eine Reihe von Werkzeugen zur Verfügung. Gern wird dabei auf Microsoft Excel zurückgegriffen, da es den Anwendern die Möglichkeit bietet, sich die eigenen Berichte gezielt zusammenzustellen und dabei Formeln und Funktionen einzusetzen, die den innerbetrieblichen Gegebenheiten des Unternehmens entsprechen.

Neben der Datenanalyse auf Basis von Microsoft Excel gibt es eine Reihe komplexer Lösungen, um Datenbestände miteinander in Beziehung zu setzen. All diesen Anwendungen liegt das Prinzip des Data Warehouse (DWH) zugrunde (siehe Abbildung 1.1).

Grundlagen der SAP BW-Datenhaltung

Um SAP BW-Systeme optimieren zu können, ist ein Verständnis der Datenhaltung unerlässlich. In diesem Kapitel werde ich Ihnen die häufigsten Arten der Datenhaltung und die entscheidenden Unterschiede zu anderen datenbankbasierten Systemen, insbesondere zum klassischen Data Warehouse, erläutern.

Innerhalb einer EDV werden – wie der Name schon sagt – Daten auf elektronischem Wege verarbeitet. Wenn es sich dabei um Daten handelt, die nach der Verarbeitung noch anderen Vorgängen oder auch demselben Prozess zur Verfügung stehen sollen, ist eine Datenbank erforderlich.

In der Regel folgen heutige Datenbanken dem Relationsprinzip nach Codd. (Edgar Frank Codd, Entwickler des Relational Database Management Systems RDBMS).

Nach diesem Prinzip besteht zwischen redundant verwendbaren Objekten und Informationen eine Primär-Fremdschlüssel-Beziehung, die dazu geeignet ist, Datenbanken schlanker, eindeutiger und wiederverwendbarer zu machen.

Datenbanken werden unter Verwendung der sogenannten Normalisierungsregeln aufgebaut. Sie bieten einen eindeutigen Schlüssel auf einen oder mehrere der zum Schlüssel gehörenden Werte.

Innerhalb des SAP BW-Systems kommen sowohl normalisierte als auch nicht normalisierte Datenbankmodelle zur Anwendung

SAP BW unterscheidet grundsätzlich zwischen

• persistenter Datenhaltung (Datenziele) = physisch auf der Datenbank und
• transienter Datenbereitstellung (Nicht-Datenziele) = zur Laufzeit verfügbare Daten.

Eine weitere wesentliche Unterscheidung innerhalb der Datenhaltung des SAP BW besteht in der flachen und der mehrdimensionalen Datenhaltung:

• Merkmale, DataStore-Objekte (DSO) = flache Datenhaltung
• InfoCubes = mehrdimensionale Datenhaltung.

Lassen Sie uns in Abbildung 2.2 etwas genauer darauf eingehen. Zunächst zur Erinnerung:

Datenziele:

• sind InfoProvider,
• belegen physische Speicher auf der Datenbank,
• können zum Reporting herangezogen werden.

Nicht-Datenziele:

• sind InfoProvider,
• belegen keinen physischen Speicher auf der Datenbank,
• können zum Reporting herangezogen werden.

Datenmodellierung aus Sicht der Performance

Einen erheblichen Einfluss auf die Datenperformance in SAP Business Warehouse haben die verwendeten Modelle. Inwieweit die Modellierung Möglichkeiten der Performanceoptimierung bietet, wird in diesem Kapitel erläutert. Darüber hinaus werden Formeln und Parameter vorgestellt, wie die Datenbereitstellung optimiert werden kann.

Die Extraktionsmodellierung

Da die Verarbeitung von Quelldaten einen wesentlichen Einfluss auf die Performance der Datenbeschaffung hat, wollen wir zunächst die Datenbeschaffung betrachten.

Requestverarbeitung

In der Datenfortschreibung – egal, ob aus einer Quelle, innerhalb des Datenflusses des BWs oder bei der Datenfortschreibung in andere Systeme – werden die Daten immer in Requests gepackt.

Ein Request ist eine definierte Sammlung von Daten, die als Antwort auf eine Datenanfrage in das Zielsystem geschickt und dort verarbeitet wird. Er setzt sich aus den Untermengen »Paket« und »Record« zusammen.

In welchen Umfang die Requests gefüllt und verarbeitet werden, stellen Sie über die Steuerparameter zur Datenübertragung im Quellsystem ein.

Die Größe, also die Menge an Records eines Requests, hängt teilweise von der Anwendung ab, in der der Request eingesetzt wird. Diese Größe müssen Sie zwingend bei einigen Prozessen beachten.

• Planung: Nur Requests mit genau 50.000 Records werden automatisch geschlossen. Soll ein Request eher geschlossen werden, müssen Sie das manuell oder in einer Planungsfunktion mittels Funktionsbaustein erledigen.

• SAP-Quelle: In der Standardextraktion werden Requests unter Umständen aufgefüllt. In welchem Umfang aufgefüllt wird, hängt von den Einstellungen der Paketgröße ab. Die Standardpaketgröße kann pro Datenbeschaffung im BW variiert werden. Ein Request umfasst im Standard bis 100.000 Records

• Real Time Data Akquisition: Hierbei steuert ein separater Prozess, der Dämon, in welcher zeitlichen Abfolge die Daten im Quellsystem nachgelesen und in das SAP-BW fortgeschrieben werden. Der Dämon prüft in der Quelldeltaqueue, ob 50.000 Records vorhanden sind. Falls ja, holt er genau 50.000 Records ab. Die restlichen verbleiben in der Quelldeltaqueue bis zum nächsten Leseprozess.

Die Paketgrößen können, bei Fortschreibung in SAP BW, pro Fortschreibungsprozess innerhalb der DTP-Einstellungen variiert werden. Die Größe eines Requests kann vom Modellierer nicht beeinflusst werden, denn sie ist festgelegt.

Warum ein Standard-Request bis zu 100.000 Records umfasst, liegt darin begründet, dass ein Request nach 50.000 Records geschlossen und fortgeschrieben wird. Um dies besser verständlich zu machen, zeigt Abbildung 3.1, wie die Verarbeitung bei Requests mit fester Größe von 50.000 Records verläuft.

Sie sehen, dass die Größe des Standard-Requests dazu führt, dass die Daten der Quelle in einzelne Requests zerlegt werden.

Gleichzeitig erkennen Sie, dass die feste Requestgröße dazu führt, dass es zu Requests mit weniger als 50.000 Records kommen kann. Eigentlich müsste dieser nun ungültig sein, da er die Mindestvoraussetzung von 50.000 Records nicht erfüllt. Das System weiß sich aber zu helfen. Tritt eine solche Situation ein, wird ein Datenbestand mit weniger als 50.000 Records einfach an den letzten gültigen Request angehängt (siehe Abbildung 3.2).

Performancemessungen und deren Interpretation

Das Messen leistungsrelevanter Parameter ist der erste Schritt, um die Ursachen für Performanceverluste aufzuspüren. Welche die wichtigsten Parameter sind, und wie Sie die gewonnenen Erkenntnisse interpretieren können, wird Thema dieses Kapitels sein.

Innerhalb von SAP existiert eine sehr bekannte Transaktion, über die Sie einige mögliche Messungen erreichen können. Diese Transaktion STUN zeigt Abbildung 4.1.

Bei dieser Transaktion handelt es sich um eine Sammlung von Werkzeugen, die für den Systemadministrator von größerer Bedeutung sind. Zur Auswertung und Interpretation von performancerelevanten Parametern ist sie nur begrenzt einsetzbar. Aus diesem Grund gehe ich darauf nicht weiter ein.

Performance-Optimierung

Die Optimierung von Datenbanksystemen ist immer eine große Herausforderung. Einerseits besteht der Wunsch nach Vielfältigkeit und Genauigkeit der Daten, andererseits erwarten die Nutzer eine hohe Performance ihrer Datenabfragen. Diese Erwartungshaltungen tragen den Konflikt bereits in sich.

Welche Möglichkeiten bieten sich Ihnen, um bestehende Performanceprobleme zu beheben bzw. dauerhaft zu vermeiden? Dieser Frage werden wir im folgenden Kapitel vor allem unter dem Aspekt der Notwendigkeit technischer Informationen (Statistikdaten und Protokolle) nachgehen.

Reorganisieren von BEx Web Application Bookmarks

Innerhalb des Reportings besteht für den User die Möglichkeit, durch Anlage von Bookmarks auf häufig aufgerufene Berichte und Anwendungen rasch zuzugreifen. Um die damit einhergehenden Probleme zu verdeutlichen, müssen wir zunächst einige Begrifflichkeiten klären.

Jeder kennt Bookmarks von seinem Computer bzw. dem Internetbrowser. Sie können schnell und einfach angelegt werden und stellen Verweise (Links) auf ein Programm oder eine Internetadresse dar.

Bookmarks in SAP Business Warehouse sind Verweise auf einen Navigationszustand innerhalb der Datenbank. Diese müssen verwaltet und dem User ständig zur Verfügung gestellt werden. Da es sich um benutzerspezifische Informationen handelt, müssen sie mit der Anmeldung des Benutzers am System aus einer Tabelle geladen und ihm während der gesamten Anmeldezeit zugänglich sein.

Innerhalb der Datenbank sind Bookmarks nichts weiter als Daten. Technisch gesehen sind es allerdings nicht einfach nur Daten wie etwa konkrete Werte, sondern »Daten, die Daten beschreiben«. Man bezeichnet diese in der Informatik als Metadaten.

Exkurs Metadaten

Metadaten beschreiben Daten, Datenobjekte und Prozesse auf technischer, Ordnungs- und semantischer Ebene.

Innerhalb von SAP BW gibt es natürlich auch Metadaten. Beispielsweise beschreibt eine Domäne ein Datenelement, oder eine Transferstruktur beschreibt die Felder, die der Extraktor (das Programm) bei der Datenbeschaffung verwenden soll.

Da Datenobjekte ihre grundlegenden technischen Informationen nicht in sich tragen, sondern aus einem Metadatum erben, müssen bei der Verwendung des Datenobjekts sowohl das Datenobjekt selbst als auch sein Metadatum geladen sein. Das erhöht natürlich die Verarbeitungslast im System.

Möglichkeiten der Archivierung

Neben den üblichen Archivierungskonzepten innerhalb von SAP-Systemen, stelle ich Ihnen eine Möglichkeit vor, wie Sie lückenlose Informationen und schlanke Datenspeicher miteinander kombinieren können.

Es ist üblich, für das aktuelle Reporting bzw. die aktuelle Planung nicht mehr benötigte Daten requestweise zu archivieren. Ein Beispiel dazu habe ich Ihnen in Abbildung 6.1 zusammengestellt.

Aus gutem Grund wehren sich die Fachbereiche gegen solche Archivierungskonzepte, weil die Archivierung mit dem Verlust von direkt verfügbaren Informationen einhergeht.

Eine hervorragende Alternative bietet hier das Konzept des Nearline Storage (NLS). Wie die Datenverarbeitung mit NLS zur Berichtszeit erfolgt, können Sie in Abbildung 6.2 sehen.

Housekeeping-Konzept

Eine Reihe der Ihnen im Kapitel 5 vorgestellten Programme und Funktionen können Sie für das Housekeeping heranziehen und sinnvoll miteinander kombinieren. In diesem Kapitel werden Möglichkeiten für das Housekeeping vorgestellt, welche das System regelmäßig optimieren und bereinigen.

Das Housekeeping ist ein regelmäßiger Vorgang, der in sinnvoller Abfolge von Einzelschritten- und prozessen zu einer kontinuierlich guten Systemperformance führt. Dabei muss zwischen Housekeepingaufgaben für das Reporting und für das Data Warehousing unterschieden werden.

Obwohl Reporting und Data Warehousing gern voneinander getrennt behandelt werden, greifen beide durch gemeinsam verwendete Ressourcen eng ineinander. Eine rigorose Trennung erfolgt daher in diesem Kapitel nicht

Tägliche Maßnahmen

Zu den täglichen Kernprozessen eines BW-Systems gehört die Neubeschaffung von Daten aus den zugeordneten Quellen. In Abhängigkeit vom Release des BW-Systems und der Art der Datenquelle müssen unterschiedliche Betrachtungen zugrunde gelegt werden. Der größte Unterschied zeigt sich in der Verwendung der PSA.

Wöchentliche Maßnahmen

Einmal pro Woche, jedoch spätestens einmal im Monat, sollten fehlerhafte Indizes identifiziert und repariert werden. Nutzen Sie diese Gelegenheit, um die DB-Statistik gleich mit zu aktualisieren. In der folgenden Abbildung 7.3 sehen Sie einen komfortablen Workaround, wenn es zu DTP-Abbrüchen aufgrund fehlerhafter Indizes in InfoCubes kommt.

Monatliche Maßnahmen

Einmal im Monat sollten Sie sich Ihrem System zuwenden und überschüssige Daten entfernen. Dazu zählen Statistikdaten wie auch Bewegungs- und Stammdaten. In welchem Umfang die Bereinigung durchgeführt wird, ist natürlich Ihnen überlassen. Lassen Sie mich Ihnen beispielhaft ein monatliches Housekeeping vorstellen (siehe Abbildung 7.7). Dabei werden Prozesse der Datenbereinigung innerhalb der PSA-Tabellen mit Indexreparaturen kombiniert.

Um zu verhindern, dass die Systembetreuer zu spät von einem Fehler Kenntnis erlangen, wird ein Alerting eingebunden. Jeder einzelne Schritt wird überwacht, sodass dem Systemadministrator ein Abbruch des Prozesses sofort bekannt gemacht wird.