Viele Anwender von SAP BW beklagen, dass die Datenbasis nicht sinnvoll strukturiert ist oder die eingesetzte Hardware nicht richtig zur Lösung passt. Ursache ist oft die ungenügende Geschwindigkeit, mit der die Daten verarbeitet werden. Die Probleme treten vor allem dann auf, wenn das System voll ausgelastet ist oder wenn Ladeprozesse und Reporting-Abfragen zugleich erfolgen und dabei manchmal mehrere Stunden dauern. Schnell kommen dann die entnervten Anwender zu Pauschalurteilen wie: "Meine R/3-Reports waren früher viel schneller" oder: "Wenn’s mal wieder länger dauert, dann ist es wahrscheinlich das BW."

Es beginnt bei der Datenmodellierung

Ein deshalb erforderliches Tuning und die Optimierung einer BW-Lösung hängen zwar immer von den individuellen An- forderungen im Unternehmen ab. Es lässt sich aber eine Checkliste aufstellen, die Leistungsprobleme von BW-Anwendungen bekämpfen hilft. Das beginnt bei der Datenmodellierung: Die Anforderungsspezifikationen der Fachabteilungen sind meist sehr breit gefächert, das heißt, sie wollen möglichst viele Kennzahlen und Merkmale in einem BW-Infocube abgebildet sehen, sei es für Plan-, Ist- oder historische Informationen. Die Folge sind oft inhaltlich überfrachtete Da- tenmodelle, die wenig effizient und transparent sind. Es empfiehlt sich deshalb, kleinere Ausschnitte von Basiscubes vergleichbar einem Data Mart auszu- wählen. Basiscubes umfassen einen in sich geschlossenen, themenbezogenen abgespeicherten Datenbestand und erleichtern auch die spätere Umsetzung einer BW-Anwendung. Der vom Hersteller empfohlene Maximalwert von 13 freien Dimensionen in einem Basiscube ist kein Hindernis beim Design des Star-Schemas. Wichti- ger ist vielmehr, Dimensionen mit sehr vielen Merkmalsausprägungen zu vermeiden.

Ein hervorragendes Mittel bei der Entwicklung performanter Infocubes sind "Line-Item-Positionen". Bei der Aktivierung der Cubes, wird für das Line-Item-Merkmal keine Dimensionstabelle angelegt, sondern die "Surrogat Identification" (SID) des Merkmals direkt als Schüsselfeld in der Faktentabelle gespeichert. Dadurch bedarf es keiner zusätzlichen Join-Verbindung mit der Dimensionstabelle beim Zugriff des Prozessors für Online Analytical Proces- sing (Olap) auf den Infocube, und der Lesevorgang wird schneller. Vor allem Merkmale mit einer sehr großen Ausprägung wie Material- oder Belegnummern soll- te man als Line Item verwenden, um die hohen Kosten für Datenbankzugriffe zu senken.

Je mehr Line Items in ein Schema integriert werden, desto höher ist die Auswertungsgeschwindigkeit. Merkmale mit wenigen Ausprägungen lassen sich hingegen weiter in der "klassischen" Struktur - einer Dimension mit mehreren Merkmalen - ablegen. Der Einsatz von Line Items hat jedoch den Nachteil, dass sich eine Line-Item-Dimension nicht um zusätzliche Merkmale erweitern lässt.

Geklammerte Merkmale und Navigationsattribute in den Infoobjekten erfüllen wichtige Aufgaben im BW. Sie müssen von Anfang an im Entwicklungsprozess berücksichtigt werden, um später keine Performance-Probleme zu verursachen. Will der Anwender auf sie verzichten und Merkmale nicht mit der System-ID des Quellsystems klammern, müsste er noch vor Beginn des BW-Projekts seine Stammdaten harmonisieren, um eine Eindeutigkeit in den Daten herzustellen. Eine andere Alternative wäre der Einsatz singulärer Merkmale als Workaround. Der Schlüssel setzt sich hierbei aus den Infoobjekten des geklammerten Elements zusammen. An diesem können dann die ursprünglichen Merkmale und Attribute als Navigationsattribute verfügbar gemacht werden. Manchmal führt jedoch kein Weg um Klammerungsmerkmale herum, wenn Merkmale ansonsten nicht eindeutig wären. Dann sollte eine Query zunächst den in Bezug auf die Feldlänge kleineren der beiden Schlüssel System-ID und Attribut wählen, und erst im zweiten Schritt das größere Element in den Drill-down einbeziehen.

Vorsicht mit Navigationsattributen

Ebenso kann der Einsatz von Navigationsattributen im Infoobjekt die Systemleistung beim Reporting beeinträchtigen, da neben den Infocube-Daten auch Tabellenverbindungen für die verwendeten Stammdaten innerhalb der Datenbank aufgebaut werden müssen. Noch größere Vorsicht ist geboten, wenn Anwender mit zeitabhängigen Navigationsattributen arbeiten, denn der erweiterte Datenbankzugriff nimmt mehr Zeit in Anspruch. Auch verringert sich der Vorteil von Aggregaten, wenn durch Updates von Stammdaten oder Stichtagen die Verdichtungsebenen stets neu aufgebaut und aktualisiert werden müssen.

Ein weiterer Weg zur Performance-Steigerung von BW sind Data-Mining-Mo- delle. Sie dienen dazu, bereits im Vorfeld der BW-Implementierung Daten aus- zuwählen, und unterstützen deren Klassifizierung. So hilft beispielsweise ein "Scoring"-Verfahren in einem allgemeingültigen BW-Sternschema die Ausprä- gungen von Attributen favorisieren (siehe Grafik). Dies kann eine spezielle Variante (Indiz) zu einem Produkt oder einem Kunden sein. Zusätzlich lassen sich für einzelne Kennzahlen Indikatoren setzen, zum Beispiel wenn definierte Schwellwerte überschritten werden. So könnte eine Vorgabe in einem Finanzinstitut heißen, dass alle Transaktionen eines Bankkunden innerhalb einer Zeitperiode nicht die Summe von 30000 Euro überschreiten dürfen. Der Indikator wäre hier der Betrag von 30000 Euro. Jedem Indikator wird eine Wertigkeit (Score) zugeordnet.

Scoring hilft Daten auswählen

Aus der Summe der zutreffenden Scores wird pro Merkmal ein Gesamtscore ermittelt. Liegt dieser über einem vorgegebenen Endwert (Limit), so führt das zu einer Klassifizierung. Diese könnte heißen: "Suche alle Kunden, die aus der Summe aller zutreffenden Indizien heute einen Gesamtscore über 80 Punkte erreicht haben." Trifft das für den Kunden zu, wird über die Fortschreibungsregel ein Zeitstempel vergeben und in ein Data Mart mit wesentlich kleineren Datenmengen überführt. Der Performance-Gewinn liegt in der Auslagerung der Kategorisierung in die Fortschreibungsregeln des Ladeprozesses. Dadurch sinken die Antwortzeiten beim Reporting.

Eine homogene und konsistente Datenbasis zur Entscheidungsfindung erfordert eine hohe Datenqualität. Diese ist aber oft in den Daten aus den R/3- sowie aus Drittsystemen nicht gegeben und muss durch einen Prozess der Extraktion, Transformation und des Ladens (ETL) verbessert werden. Dabei ist die "referenzielle Integrität" zu wahren und eine applikationsübergreifende Harmonisierung der Datenbasis zu erzielen. Eines der häufigsten Probleme bei BW-Projekten sind inhomogene Stammdaten. Diese bestehen oft aus mehrfach angelegten Schlüsseln für das gleiche Objekt.

Probleme mit Stammdaten

So ist beispielsweise derselbe Kunde unter mehreren Kundennummern angelegt. Dies führt zu deutlichem Mehraufwand im BW, da in solchen Fällen die Klammerung an die Quellsystem-ID verwendet wird. Für ein BW-Reporting auf konsolidierten Daten müssen dann zusätzlich Hierarchien und Navigationsattribute auf den aufgeblähten Stammdaten erzeugt werden, was erhebliche Performance-Verluste nach sich zieht. Konzernweite BW-Projekte sind daher oft von zentralen Stammdaten-Harmonisierungen begleitet.

Damit die Zeit zum Laden und Harmonisieren der Daten im BW ausreicht, müssen Anwender frühzeitig über den Aufbau der Ladeprozesse und deren Zeitfenster nachdenken. Technischer Content und Erfahrungen aus anderen Projekten können dabei helfen, die Infosourcen zu ermitteln, welche sehr zeitintensiv sind und die Abläufe behindern. Zudem sollten selbst geschriebene Laderoutinen überprüft werden, da sich in der Praxis immer wieder Syntaxfehler finden, die für einen produktiven Ladeprozess verheerend sind.

Full- kontra Delta-Update

In einigen BW-Landschaften werden sogar große Datenbestände immer noch über ein Full-Upload-Verfahren geladen. Angesichts der seit Jahren gestiegenen Datenlast wäre es jedoch sinnvoll, über ein Re-Design des Produktivsystems und den Einsatz von Delta-Verfahren nachzudenken. Erfahrungsgemäß wird dieser Vorschlag auf den Widerstand des Fachbereichs stoßen. Dieser befürchtet, dass in den BW-Daten durch die Umstellung Fehler entstehen könnten und einen erheblichen zeitlichen Mehraufwand nach sich ziehen. Trotzdem ist eine solche Änderung unbedingt ein Bestandteil der BW-Optimierung.

Optimierung von Ladeprozessen

Sind bereits viele Daten im Infocube vorhanden, kann es Sinn machen, vor dem Laden großer Datenmengen einen "Drop Index" (Ausschaltung der Schlüsselindizierung) zu machen und anschließend wieder neu aufzubauen. Da dies natürlich auch Zeit braucht, müssen Anwender solche Konfigurationen testen. Dieses Vorgehen empfiehlt sich nur, wenn während des Ladelaufes kein Reporting auf dem Datenbestand stattfindet.

Eine andere Optimierungsfunktion ist es, die Datenbankstatistik für einen Datenwürfel immer aktuell zu halten, da nur so der Datenbank- Optimizer von BW seine volle Leistung erbringt. Zudem ist als wichtiges Hilfs- mittel gegen eine schwache BW-Perf- ormance die Komprimierung nicht zu vergessen. Stehen zu viele unkomprimierte Requests in einem Infocube, verschlechtert sich die Zugriffszeit für einige Datenbanksysteme drastisch. Dagegen hilft nur ein zeitnahes Komprimieren der Basiscubes, das Datenabfragen in der E-Faktentabelle des Cubes verdichtet ablegen hilft. Schließlich gehört zu performanten Ladeprozessen auch ein gutes Team aus Mitarbeitern, die durch ein gezieltes Monitoring und Detailkennt- nisse der Abläufe und Prozessketten den Ladeprozess überwachen und schnell auf Ladeprobleme reagieren können. Dies ist insbesondere wichtig, wenn die Zeitfenster für die Ladeprozesse recht eng aufeinander folgen. Kurze Kommunika- tionswege zwischen dem Team und den Bereichen Entwicklung, Basis, Support und Fachbereich sind hier unumgäng- lich.

Ein weiteres Feld für BW-Tuning ist das Reporting. So sollte die IT den Fachbereichen grundsätzlich nur auf gute Laufzeit geprüfte (Standard-)Queries anbieten. Dieser Ansatz wird indes in der Praxis oft durch selbsternannte Experten unterlaufen, die eigenmächtig Abfragen an ihre Bedürfnisse anpassen und so für einen Wildwuchs sorgen, der keinen Performance-Kontrollen unterliegt. Die so entstehenden "Langläufer" unter den Abfragen können bei einer hohen Systemlast selbst die besten Systeme in die Knie zwingen. Daher ist es wichtig, dass bei Entwicklern von Abfragen ein gesundes Verständnis zwischen technisch Machbarem und praktisch Sinnvollem besteht.

Aggregate

Neben den Optionen zum Query-Tuning (siehe Kasten "Tempo in die BW-Abfragen bringen") sind Aggregate ein weiterer praxiserprobter Schlüssel zu einer besseren Performance. Ein Aggregat speichert den Datenbestand eines Basiscubes in ver- dichteter Form redundant und persis- tent auf der Datenbank ab. Dies steigert die Query-Performance, weil ein schnellerer Zugriff auf den Datenbestand im Reporting möglicht ist. Da ein Basiscube mehrere Aggregate besitzen kann, greift der Optimizer des Olap-Prozessors bei einer Query auf das jeweils beste Aggregat zu.

Anpassung der Aggregate

Neue Anforderungen im Reporting machen in der Praxis ein Re-Design der BW-Objekte nötig. Doch Änderungen und Erweiterungen an den Dimensionen, Navigationsattributen oder am Query-Design können die Performance der genutzten Aggregate beeinträchtigen. Deshalb sollten Letztere regelmäßig überprüft und gegebenenfalls neu justiert werden. Zudem lassen sich für die Query-Optimierung Aggregate bei einer Abfrage gezielt ein- und ausschalten. Dies steigert die Performance.

Datenkonsistenz durch Rollup

Ein Rollup ist erforderlich, sobald sich die Daten des Basiscubes geändert haben, um Datenkonsistenz zwischen Cube und Aggregat zu gewährleisten.

Erst durch das Hochrollen der neu geladenen Daten werden die Aggregate für das Reporting verwendet. Bei Cubes mit großen Datenmengen empfiehlt es sich einen Prozess zu etablieren, der den Cube erst dann zum Reporting frei gibt, wenn die Aggregate hochgerollt sind. Der Roll-Up lässt sich beschleunigen, wenn die Aggregate in hierarchischer Beziehung untereinander stehen.

Beim Einsatz von Navigationsattributen werden deren Stammdaten im Aggregat gespeichert. Ändern sich die Stammdaten, muss dies per Change Run in den betroffenen Aggregaten nachvollzogen werden. Dieses Vorgehen kann bei größeren Anpassungen schnell aufwändiger sein als ein kompletter Neuaufbau. Wo dieser Schwellwert liegt, kann der Anwender über Customizing-Einstellungen (Transaktion RSCUSTV8) selbst festlegen. Dies hilft, die Laufzeit des Change Run bei umfassenden Stammdatenänderungen deutlich zu verkürzen.

Weitere Hilfe findet man im technischen Content, der statistische Angaben über Merkma- le und Navigationsattribute der Basiscubes enthält. Für jeden Basiscube lassen sich die Ag- gregats- und Zugriffsnutzun- gen auswerten, um die Häufigkeit der benutzten Merkmale und Navigationsattribute zu bestimmen. Dies hilft, Basisaggregate gezielter aufzubauen und die Performance zu verbessern.

Altlasten beseitigen

Oft sind neue BI-Anwendungen und BW-Projekte mit einem enormen organisatorischen Aufwand verbunden, um Transporte (von Daten und BW-Objekten) auf das Produktivsystem des Kunden freizugeben. Gegen den sich mit der Zeit ansammelnden produktiven "Datenmüll" in BW wird hingegen fast nichts unternommen. Spricht man die Altlasten an den entsprechenden Stellen an, ist oft von "historisch gewachsenen Lösungen" die Rede. Damit fragt sich, wer denn innerhalb des Unternehmens überhaupt noch die BW-Daten- und Reporting-Strukturen überblickt und weiß, ob eine Überprüfung oder ein Re-Design notwendig ist.

Wer sich auf die Suche nach Leistungsbremsen in den bestehenden Systemen macht, soll- te beispielsweise nach ungelöschten Daten in der Persistant Staging Area (PSA) Ausschau halten. In drastischen Fällen können diese Altlasten dazu führen, dass die Speicherbereiche der Datenbank in den roten Bereich geraten und dadurch die Performance extrem belasten. Ferner kann der Anwender über die Tabelle RSDCUBEMULTI die Beziehung zwischen Multi- cube und Infocubes abrufen. Oftmals handelt es dabei um eine Eins-zu-n-Beziehung von mehreren Infocubes an einem Multicube, die in der aktuellen Version nicht mehr bestehen und die Systemlast unnötig erhöhen. Hat sich aber der Anwender zum Ziel gesetzt, den gesamten Wildwuchs zu beseitigen, bleibt ihm nichts anderes übrig, als das ganze BW-System zu durchforsten. (as)