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.
Tempo in die BW-Abfragen bringen
Grundregeln
Eine Query sollte über die Variablen so eingeschränkt sein, dass nur in Ausnahmefällen mehrere Ausprägungen von Attributen gestattet sind. Komplexe Arbeitsmappen und Zugriffe auf ODS-Objekte sollten die Ausnahme bleiben.
Laufzeit-Verbesserung bei der F4-Hilfe
Beim Navigieren in der Query kommt es oft zu Wartezeiten, wenn zur Filterung eines Merkmals die Wertehilfe (F4-Hilfe) genutzt wird. Die Ursache liegt oft in der Einstellung "Nur gebuchte Werte anzeigen", mit der alle gültigen Kombinationen zwischen den gebuchten Werten unter Berücksichtigung der ausgewählten Filterwerte überprüft werden. Es sollte deshalb bei den Infoobjekt- Einstellungen auf eine Prüfung der gebuchten Werte verzichtet werden, da sich die Werte so deutlich schneller aus den Stammdaten sequenziell lesen lassen. Allerdings können dadurch Kombinationen auftreten, die zu einem ungültigen Ergebnis der aktuellen Query führen. Beispielsweise werden keine Daten gefunden (leere Menge), weil ein Kunde in der laufenden Periode keine Artikel bestellt hat.
Verwendung von Berechtigungsvariablen
Kommen Berechtigungsvariablen zum Einsatz, sinkt die Performance umso stärker, je komplexer das dazugehörige Berechtigungskonzept ist. Je mehr Berechtigungsobjekte (Rollen oder Zugriffe auf Teil-Cubes) geprüft werden und je vielschichtiger die einzelnen Ausprägungen sind, desto schlechter ist das Laufzeitverhalten.
Neuer Speed für Templates
Bei Web-Anwendungen, die statische und vorab errechnete HTML-Seiten nutzen, macht es Sinn, Seiten mit Hilfe des Tools "Reporting Agent" vorzuberechnen. Besonders brisante Informationen, die für den Vorstand gedacht sind, liegen so immer zeitgenau vor, wenn der Manager auf den Button klickt. Ferner ist der Aufruf der HTML-Seite durch dieses Vorgehen wesentlich effektiver, da der Bericht schon fertig errechnet gespeichert wird. Zudem kann die Vorberechnung von Web-Templates als Batch-Prozess erfolgen, ohne das System zu stören.
Werkzeuge zum Tuning
Mit dem Query Monitor von BW (Transaktion RSRT) lässt sich eine laufende Abfrage im Debugging-Modus auf verschiedene Weisen analysieren, um Leistungsengpässe aufzudecken. Wertvolle Hilfe bei der Performance-Analyse bietet auch die Transaktion ST05, der SQL-Trace. Sie bewertet die einzelnen Schritte einer Query und speichert die Tabellenzugriffe temporär ab. Dadurch wird erkennbar, welche relationalen Tabellen die längste Zugriffszeit verursachen. Über das Multicube-Verfahren können dann die zeitkritischen Zugriffe auf die Fakten- und Dimensionstabellen der zugehörigen Basiscubes ermittelt werden.