In-Memory und seine Tücken

Analog zur SAP Hana In-Memory Lösung bieten seit einer Weile auch die anderen von SAP unterstützten Datenbank-Provider entsprechende Lösungen an. Man muss ja konkurrenzfähig und möglichst performant bleiben. Aber resultiert eine In-Memory Verarbeitung auch automatisch in einer schnelleren Antwortzeit?

Mit dem Release 12c führte Oracle das In-Memory Feature. Der Microsoft SQL Server unterstützt die Funktion seit Version 2014. Auch IBM hat für Ihre DB2 Datenbank ab Version 10.5 FP5SAP2 eine In-Memory Lösung geschaffen. Hier wird die Funktion „BLU Acceleration“ genannt. Hierzu möchte ich einen kurzen Überblick über das Thema und einen möglichen Fallstrick geben.

Umsetzung

DB2 BLU ergibt sich aus zwei Hauptfeatures - SAP bietet derzeit jedoch nur eine Unterstützung für BW Systeme und den Solution Manager.

  • In-Memory Data
  • Column-Stored Data 

Vor kurzem hatte ich eine Kundenanfrage bezüglich DB2 BLU für ein 7.31 BW-System. Ich habe mich also mit den technischen Voraussetzungen auseinander gesetzt:

  • Mindestens DB2 Version 10.5 FP5SAP2
  • Unicode
  • Automatic Storage Tablespaces
  • 64GB RAM exklusiv für die DB2
  • 4 CPU Cores

Möchte man sein Datawarehouse über BLU beschleunigen, müssen diverse Datenbank- und SAP-Parameter angepasst werden und im Anschluss via dem gesonderten gelieferten Report DB6CONV die zugehörigen Objekte in den Column Store konvertiert werden. Persönliches Einschätzung: Das sieht überschaubar aus. Schnell den Aufwand errechnet, ein entsprechendes Angebot erstellt und dem Kunden ein Wohlfühlpaket verkauft. Soweit so gut…

Wenn man alles richtig gemacht hat und die Voraussetzungen sowohl auf technischer, als auch auf applikationsseitiger Ebene erfüllt sind, kann der Kunde sich in der Regel über 3-10mal beschleunigte Queries und Beladungen in seiner BW-Landschaft freuen.

Und es klemmt doch

Wenn allerdings ein winziger Teilaspekt nicht zusammen passt, hat man mehrere Personentage investiert und kann leider von keinem Leistungsschub profitieren. Diese Erfahrung mussten mein Kunde und ich schmerzlich erleben. Denn nach erfolgter Implementierung, wollte der Vergleichstest zwischen Sandbox mit BLU und Produktion ohne BLU hinsichtlich Performance leider keinen Unterschied vermelden.

Diese Herausforderung hat mich in einer länglichen Analysesitzung in basisfernen BW-Transaktionen gefesselt. Zudem musste ich mir Unterstützung von einem bekannten BW Berater suchen, der diverse Unstimmigkeiten hinsichtlich des Datenmodells festgestellt hat – zum Beispiel:

  • Es werden noch Aggregate verwendet: Dies ist bei der Verwendung von DB2 Blu zu deaktiveren
  • BW SID’s und alte Requests werden sehr lange gespeichert: Dies belastet jede neue Beladung, vor allem da kein Delta-Load getätigt wird, sondern immer mit einem Full-Load gearbeitet wird
  • Keine Adaptive Table Compression
  • Und andere Kleinigkeiten …

Einerseits eine sehr bereichernde Erfahrung, wenn man sich mit der RSA1 und der RSRT auseinander setzt und die DB2 Datenbank hinsichtlich Ihrer Performance auf Herz und Nieren untersucht. Andererseits ist es allerdings auch sehr zeit- und nervenraubend, wenn sich herausstellt, dass das Problem nicht in der Datenbank liegt. Bei der Ausführung und Analyse einer Query, deren Datenbestand eigentlich komplett im Column Store und In-Memory liegen – und damit im Vorher-/Nachher-Vergleich spür- und messbar schneller sein sollte , ist mir mir folgender Datensatz in der STAD aufgefallen:

Hier sieht man recht deutlich, dass von der gesamten Laufzeit der Query (552.020ms) lediglich 4.410ms in der Datenbank verbracht wurden. Das sind nur 0.8% der Gesamtlaufzeit. Die restlichen 99,2% hat die Query im ABAP Wokrprozess verbracht. Da die Datenbankzeit nur einen winzigen Faktor ausmacht, ist es nicht zielführend, diesen weiter zu analysieren oder zu optimieren. Der einzig richtige Ansatz wäre nun, mit entsprechendem KnowHow ein Redesign der BW Struktur vorzunehmen.

Fazit

Selbst wenn die Technik zu 100% korrekt umgesetzt wurde und alle relevanten BW-Objekte in ColumnStore konvertiert wurden, werden Queries und Beladungen nur dann davon profitieren, wenn deren Design applikationsseitig auch so ausgerichtet ist, dass die Technik genutzt werden kann.

Quellen

Autor: Fabian HürtenWebsite: /index.php/prof/profile-fh