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.