Data Platform & Data Management

Gerade im Umfeld von HCM und den Infotyp-Tabellen werden häufig Fullloads für eine Versorgung eines SAP BW genutzt, da eine eindeutige Erkennung von Änderungen (CRUD – Create, Read, Update und Delete) im Quellsystem nicht möglich ist. Zum Beispiel sind Termine (Infotyp 0019) nicht mit einer vollständigen Gültigkeit versehen, sodass bei einer Löschung kein neuer Datensatz erstellt wird, der diesen Zeitraum überschreibt. Im Quellsystem könnte der Einsatz vom SLT/RS (SAP Landscape Transformation/Replication Server) mit seiner Trigger-basierten Erkennung von Änderungen auf Datenbankebene jede einzelne Anpassung an den Daten überwachen. Allerdings ist ein Einsatz aufgrund der verhältnismäßig geringen Datenmenge nicht unbedingt notwendig und auch eine Änderungsverfolgung wäre an dieser Stelle „übertrieben“. (Bitte beachten Sie, dass der SLT/RS zum Teil in aktuellen SAP-BW-Lizenzpaketen mit enthalten ist und somit häufig genutzt werden kann, jedoch eine Installation auf dem Quellsystem benötigt.)

Als AWS Advanced Partner wollen wir in diesem Blog unsere Erkenntnisse im Kontext Data- und Analytics-Lösungen regelmäßig dokumentieren und mit AWS-Interessierten teilen. AWS stellt als Cloud-Provider mit seinem Ökosystem und seinen Services Lösungen für uns und unsere Kunden bereit, die für eine moderne Datenarchitektur sehr gut genutzt werden können. Ziel ist hierbei nicht die Wiederholung von allgemein zugänglichen AWS-Dokumentationen. Es wird hierbei vielmehr darum gehen, unsere technischen und fachlichen Erfahrungen verdichtet zu „Papier“ zu bringen.

Diese Blogreihe startet mit der Fragestellung: „Sizing einer Redshift-Datenbank für ein Cloud-DWH“.

Seitdem das Supportende für den OWB offiziell bekannt gemacht wurde, ist der Oracle Data Integrator (ODI) das ETL-Tool der Wahl in der Oracle-Welt. Die Entwicklung ist zu der Version 12 fortgeschritten, die einige Änderungen und Verbesserungen gebracht hat. Die GUI hat sich dem OWB noch weiter angenähert, jedoch stehen einige Möglichkeiten zur Verfügung, die der OWB so nicht bot. In diesem Eintrag wollen wir uns mit der Implementierung von Slowly Changing Dimensions im ODI beschäftigen.

Optimierte Hauptspeichernutzung bei SAP BW on HANA

Die Ausnutzung des Hauptspeichers ist bei SAP-HANA- und Data-Warehouse-Szenarien immer ein spannendes Thema im Vergleich zu ERP-Anwendungen bzw. Anwendungen mit einem sich gering verändernden Datenvolumen. Somit muss man eines im Hinterkopf behalten: Lasse niemals den freien Hauptspeicher ausgehen.

Die gute Performance einer HANA-Datenbank kommt von der konsequenten Orientierung auf eine hauptspeicherbasierte Datenhaltung sowie durch die Nutzung moderner Kompressions- und ColumnStore-Algorithmen. Somit muss die Datenbank bei Aggregationen über große Datenmengen vergleichsweise wenige Daten lesen und kann dies im Hauptspeicher auch noch außerordentlich schnell erledigen. Jedoch kann bei einem suboptimalen Design des Datenmodells einer dieser Vorteile sehr schnell hinfällig werden. So gehen sowohl der HANA-Datenbank als auch den Anwendern große Vorteile hinsichtlich der Laufzeit und Agilität während der Nutzung verloren.

b.telligent-Berater Simon hat das „Lift and Shift“ mit Exasol getestet und erläutert in diesem Beitrag, wie die Cloud-Migration Stück für Stück gelingt.

Wenn ein BW-System eine SAP-HANA-Datenbank im Einsatz hat, ist es möglich, die sogenannten „Mixed Scenarios“ zu nutzen. Bei solchen Szenarien kann man Daten zusammenspielen, die sowohl im BW-System als auch in SAP HANA mit SAP-HANA-Werkzeugen modelliert wurden.