Um BW-Objekte zu löschen gehe ich folgendermaßen vor:
-> Löschen der Daten (einschließlich Dimensionstabellen; in allen Systemen)
-> Löschen von Web Applications und Arbeitsmappen (über RSZDELETE)
-> Löschen von Queries (über RSZDELETE)
-> Löschen der Prozessketten
-> Löschen lokaler DTP's
-> Löschen transportierter DTP's
-> Löschen der Transformationen
-> Löschen von MultiProvidern
-> Löschen der Objekte (DSO, InfoSource, InfoCube)
Lessons Learned:
- Im Prinzip reicht es auch aus, nur die InfoProvider zu löschen. Alles andere wie Transformationen, DTP's und Queries wird automatisch angezeigt und bei Bestätigung gelöscht.
- Es scheint so, als würde beim ausführen eines Reports auf den InfoProvider, also ohne explizit eine Query anzulegen, eine Query in der Form !INFOPROVIDER generiert werden. Diesen konnte ich so zum löschen auch über RSZDELETE nicht finden. Wird aber beim Löschen des Objekts automatisch mitgelöscht.
Montag, 30. Mai 2011
SAP BusinessObjects System Landscape Types
Wie baue ich meine Systemlandschaft mit den BusinessObjects BI-Tools? Mit oder ohne BW, mit oder ohne SAP ERP, usw.
Bei SAP finden sich sechs System Landscape Types dazu. Als Präsentation oder Webinar.
Bei SAP finden sich sechs System Landscape Types dazu. Als Präsentation oder Webinar.
Samstag, 28. Mai 2011
Freitag, 27. Mai 2011
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.
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.
Dienstag, 24. Mai 2011
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...
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...
Labels:
B-BW,
DSO Aktivierung,
IC Komprimierung,
Laufzeit
Montag, 23. Mai 2011
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...
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...
Mittwoch, 18. Mai 2011
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
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
Abonnieren
Posts (Atom)