InfoCube Komprimierung
Beim Laden von Daten in den InfoCube werden jeweils ganze Requests auf einmal eingefügt. Jeder dieser Requests erhält eine eigene Request-ID, die in der Faktentabelle in der Paketdimension mitgeführt wird. Dadurch ist es möglich, einzelne Requests gesondert zu betrachten. Ein Vorteil des Request-ID Konzepts ist, dass Sie jeweils komplette Requests nachträglich wieder aus dem InfoCube löschen können.
Das Request-ID Konzept kann jedoch auch dazu führen, dass der gleiche Datensatz (alle Merkmale bis auf die Request-ID stimmen überein) mehrfach in der Faktentabelle vorkommt. Das Datenvolumen wir dadurch unnötig vergrößert und dadurch sinkt die Performance bei der Datenanalyse, da bei jeder Ausführung einer Query über die Request-ID aggregiert werden muss.
Mit Hilfe der Komprimierung können Sie diese Nachteile beseitigen und die Daten aus verschiedenen Requests in einem Request (Request-ID 0) zusammenfassen.
Diese Funktion ist kritisch, da die komprimierten Daten anschließend nicht mehr anhand ihrer Request-IDs aus dem InfoCube gelöscht werden können. Stellen Sie zunächst unbedingt sicher, dass die in den InfoCube geladenen Daten korrekt sind.
Sie können Request-IDs auswählen und zur Komprimierung freigeben. Sie können die Funktion sofort oder im Hintergrund einplanen und über eine Prozesskette einplanen.
Der Zeitbedarf für das Komprimieren eines Request beträgt ungefähr 2.5ms pro zu komprimierendem Datensatz.
Bei Bestands-InfoCubes hat die Komprimierung einen zusätzlichen Einfluss auf die Query-Performance. Zusätzlich wird bei Bestands-InfoCubes die Stützstelle der Bestände aktualisiert. Dies führt dazu, dass im allgemeinen weniger Daten für eine Bestands-Query gelesen werden müssen und dadurch die Antwortzeit verringert wird. Siehe dazu Modellierung von Beständen mit Bestandskennzahlen.
Wenn Sie die Komprimierung für einen Bestands-InfoCube ausführen, beträgt der Zeitbedarf für die Verdichtung (inklusive der Stützstellenaktualisierung) ungefähr 5ms pro zu komprimierendem Datensatz.
Falls Sie als Datenbank eine Oracle-Datenbank verwenden, können Sie auch während eines Komprimierungslaufs Queries auf dem betroffenen InfoCube ausführen. Bei Datenbanken von anderen Herstellern wird beim Versuch, während eines Komprimierungslaufs eine Query auf diesem InfoCube auszuführen, eine Warnung angezeigt. In diesem Fall können Sie die Query erst nach Ende des Komprimierungslaufs ausführen.
Wenn Sie verhindern wollen, dass nach einer Komprimierung Einträge, die nur Nullwerte als Kennzahlen enthalten (z.B. bei Stornobuchung) im InfoCube enthalten sind, können Sie gleichzeitig mit der Komprimierung eine Null-Elimination durchführen. In diesem Fall werden die Einträge, bei denen alle Kennzahlen gleich 0 sind, aus der Faktentabelle gelöscht.
Die Null-Elimination ist nur für InfoCubes erlaubt, bei denen ausschließlich Kennzahlen mit dem Aggregationsverhalten 'SUM' vorkommen. Insbesondere bei Bestandskennzahlen dürfen Sie keine Null-Elimination durchführen.
Zu weiteren Einschränkungen lesen Sie die SAP Hinweise 1587759 
und 1224631 .
Für Bestands-InfoCubes können Sie durch das Kennzeichen keine Stützstellenfortschreibung die Aktualisierung der Bestandsstützstelle verhindern. Diese Option müssen Sie nutzen, wenn Sie Bestandsveränderungen aus der Vergangenheit in einen InfoCube laden, nachdem bereits eine Initialisierung mit dem aktuellen Bestand erfolgt ist, sonst erhalten Sie falsche Ergebnisse in der Query. Darauf folgende Deltarequests sollten Sie zur Performanceverbesserung mit Stützstellenaktualisierung komprimieren.
Aus Performance- und Speicherplatzgründen sollten Sie einen Request komprimieren, sobald Sie festgestellt haben, dass er korrekt ist und nicht mehr aus dem InfoCube entfernt werden soll.