Obsolete Datensätze und InfoProvider

Es ist ja oft so, das etwas, was mal gebaut und produktiv geschoben wurde, oft nicht mehr gelöscht wird. Wer bezahlt schon einen Berater, damit er was löscht. OK stimmt nicht, gehört hab ich das schon. Vorkommen tut das aber aus meiner Sicht selten. Ich hab gerade 50 Mio! Datensätze gefunden, in Cubes und DSO's welche seit Monaten oder Jahren nicht mehr bewirtschaftet werden. Und die Change-Log's der DSO's habe ich da noch nichtmal mitgerechnet. Konservativ geschätzt kommen da locker nochmal 10 Mio Datensätze dazu. Interessanterweise gibt es auf den Cubes jedoch auch kaum Berichte...

Ich schätze mal diese 50 Mio Datensätze machen > 50% der Datenbank aus. Auch wenn man Festplattenkapazität prinzipiell schon fast nachgeschmissen bekommt, so ist das doch in einem Rechenzentrum was ganz anderes. Dazu kommt noch, das das wahrscheinlich alles ge-Backuped wird.

OK, nächste Woche wird mal Frühjahrsputz im BW gemacht, auch wenn das Frühjahr langsam vorbei sein dürfte.

Laufzeiten I

Ok, um das mal aus Lessons Learned festzuhalten. Um ca. 4,4 Mio Datensätze in zwei InfoCubes (3,4 & 1,0 Mio) zu komprimieren , also von der F-Faktentabelle in die E-Faktentabelle zu verschieben und über Request-ID und Datenpakete zu komprimieren, benötigte ich genau:
2.763 Sekunden = 46,05 Minuten.
Beide liefen über die Prozesskette gesteuert im gleichen Job BI_PROCESS_COMPRESS ab.
Die Komprimierung lief mit Nullstelleneleminierung. Man muss jedoch auch sagen, es war nur ein Request vom Initialload. Insofern war da ausser die Daten zu verschieben nicht viel zu tun.
Wenn ich das Job-Log richtig lese, hat das für den 1. IC mit 1,0 Mio Datensätzen 25 Minuten gedauert. Die 3,4 im zugehörigen Historie InfoCube lief 21 Minuten. Schon seltsam. An den Daten alleine kann das nicht liegen.

Noch ne Zahl. Um ein DSO mit 8774386 zu aktivieren benötigten wir in unserem Lieblings BW (ich nenne es mal B-BW) genau:
72.427 Sekunden = 1207 Minuten = 20 Stunden ...
Ein Wert den ich nicht unbedingt erwartet hatte. Wird Zeit das unser BW mal wieder auf einen anständigen Server umzieht...

Logische Partitionierung

Neulich habe ich einen InfoCube gesplittet, um die Datenmenge zu verkleinern. Den Splitt habe ich auf Basis 0CALMONTH gemacht. Hätte ich kein MaxDB sondern z. B. einen Oracle DB, hätte ich mittels Partitionierung den gleichen oder sogar besseren Effekt, mit weniger initialen und weniger Entwicklungsaufwand erreichen können. Soviel wollte ich nur mal sagen.

Auf jeden Fall habe ich nun über den DTP die Selektion < 01.2010 für den Historie-Cube und >= 01.2010 für den aktuellen IC hinterlegt. Beides wird aus dem gleichen DSO gespeist. Jetzt dachte ich, gut aus dem aktuellen IC löscht du die alten Daten einfach selektiv und lädst die Historie einmal voll. Nix wars. Historie hat schon geklappt, aber der aktuelle Cube wurde gleich nochmal komplett mit den Daten >= 01.2010 geladen.

Nunja, habe mir nun mit einem Neuaufbau geholfen. Waren nur ca. 1 Mio Datensätze. Da muss ich mal schauen wie ich das besser machen kann. Das muss doch auch sauber laufen können, ohne dass man jedesmal neu aufbauen muss...

Sybase IQ

BI goes Mobile und SAP geht seit der Übernahme von Sybase im letzten Jahr mit wie es scheint. In Richtung BO scheint sich ja schon was zu entwickeln.

Einen Artikel bzw. Blog mit Überblick zu Sybase IQ, welches u. a. einen spaltenbasierte Datenbank ist. Man sind wir hipp!

http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/24667

SAP Icons

Wenn man mal Standard SAP Icons benötigt und diese nicht im MIME Repository findet:

http://www.sapdesignguild.org/resources/icons_sap/index.htm

F4-Wertehilfe bei MultiProvidern

Offensichtlich hat sich bei SAP BW 7.0 etwas geändert bzgl. der F4-Hilfe wenn es extra einen SAP-Hinweis dazu gibt:

Hinweis 984229 - F4-Modi für Eingabehilfe ab SAP NetWeaver 2004s BI

Mein Problem war, das bei der Wertehilfe immer nur die Stammdatentabelle gezogen wurde. Nach der Suche im OSS bin ich auf obenstehenden Hinweis gestoßen.

Darin steht, dass bei MultiProvidern, wenn die darunterliegenden Merkmale in einer Line Item-Dimension liegen (was hier der Fall war), die Daten immer aus der Stammdatentabelle gezogen werden.

BI Prinzipien: Extract once - deploy many

Extract once - deploy many bedeutet die Daten/Information nur einmal aus den Quellsystem zu holen und diese Daten mehrfach zu verwenden. Soweit ich gelesen habe stammt das Konzept von Bill Inmon's Corporate Information Factory. Das schreibt zumindest Daniel Knapp

In der Umsetzung bedeutet es, das Daten in ein DWH-Layer 1:1 geladen werden. Von dort aus können sich weitere Layer daraus bedienen oder die Daten werden eben weiter fortgeschrieben.

Vorteil:
-> Entlastung des Quellsystems
-> Verbesserung der Extraktionsperformance
-> Anwendung als Single Point of Truth

Kritik:
-> Ist im BW z. B. bei LO DataSources garnicht immer möglich/sinnvoll.
-> Muss durch die Architektur (z.B. EDW/LSA) unterstützt werden