SAP BW/4HANA und BW auf HANA, 2. erweiterte Auflage

2.1 Sizing

In den letzten Jahren waren wir beim Sizing vieler BW-auf-HANA-Systeme beteiligt. Der mit Abstand häufigste Fall ist, ein bestehendes BW-System auf HANA zu migrieren, der sogenannte Brownfield-Ansatz. Weniger häufig kommt der Greenfield-Ansatz vor, bei dem ein neues BW nur auf einem HANA-System betrachtet wird. Selten ist tatsächlich die Überführung eines Non-SAP-Data-Warehouse (DWH) in ein BW-System, weshalb wir diesen Fall nur kurz ansprechen werden.

Das richtige Sizing des Datenbankservers für HANA ist sehr wichtig, denn bereits hier können viele Fehler gemacht werden. Um das zu vermeiden, hat Marc Bernard einen sehr guten Blog mit den häufigsten Fehlern beim Sizing eines BWs auf HANA geschrieben.

2.1.1 Sizing bei der Migration eines bestehenden BW-Systems

Bei der Migration bestehender BW-Systeme auf HANA wird dringend empfohlen, für das Datenbank-Sizing den ABAP Sizing Report zu nutzen. Er garantiert eine höhere Genauigkeit der Ergebnisse und ist unabhängig von der Datenbankkomprimierung. Außerdem kann er das nicht aktive Datenkonzept, Extended Tables (Details zu beiden Themen in Abschnitt 4.1) sowie künftiges Wachstum miteinbeziehen. Der SAP-Hinweis 2296290 und seine Anhänge beschreiben sehr detailliert, wie Sie diesen Report ausführen und welche Funktion die einzelnen Parameter haben.

Der Sizing-Report heißt /SDF/HANA_BW_SIZING und wird ab dem Service-Plug-in ST-PI 2008_1_7xx SP8 oder ST-PI 740 SP01 ausgeliefert. Die Mindestvoraussetzung für den Report ist NetWeaver BW 7.0 SP1. Für BW-3.5-Systeme gibt es einen eigenen Report (SAP-Hinweis 2021372).

Der Report kann unterschiedlich parametrisiert werden, sodass Sie benötigte Ressourcen und damit die Belastung des Systems sehr gut kontrollieren können. Darüber hinaus nimmt Ihnen der Report viel Arbeit ab, indem er beispielsweise Einflüsse wie die Umstellung auf Unicode und eine eventuelle Komprimierung der Quelldatenbank automatisch berücksichtigt. Sie können den Report auch nur für bestimmte Teilbereiche des Systems ausführen, falls Sie planen, Ihr Systems nur teilweise zu migrieren.

Wir empfehlen, den Report unter Angabe von Wachstumswerten auf Basis Ihrer Erfahrung aus den vergangenen Jahren auszuführen. Damit erhalten Sie einen besseren Überblick über den Hardwarebedarf in den kommenden Jahren. Übliche Werte des organischen Wachstums bewegen sich erfahrungsgemäß zwischen 10 und 30 % jährlich. Ebenfalls empfehlen wir, die Berücksichtigung der nicht aktiven Daten einzuschalten.

Beim Präzisionslevel genügt die Einstellung »Low« für aussagekräftige Ergebnisse. Nur bei kleinen Systemen mit weniger als 500 GB Datenbankgröße empfehlen wir, diese Einstellung auf »High« zu setzen.

Wie schon erwähnt, liegt dem SAP-Hinweis 2296290 eine sehr gute Dokumentation mit Beispiel bei. Darin sind sämtliche Eingabeparameter, die Arbeitsweise des Tools und die Ergebnisse detailliert beschrieben. Deshalb verzichten wir an dieser Stelle auf weitere Ausführungen und ein Beispiel. Wir beschränken uns auf typische Fragen oder wichtige Hinweise, die wir trotz des ausführlichen Sizing-Reports häufig erhalten.

Beim Sizing wird oft vergessen, dass jeder Server ein Betriebssystem mit einem gewissen Hauptspeicherbedarf hat. Es werden 10 % der ersten 64 GB und 3 % des restlichen Hauptspeichers für das Betriebssystem reserviert. Pro Serverknoten sind zudem 50 GB für Services und Caches zu reservieren. Damit ergeben sich die in Tabelle 2.1 dargestellten Werte für die derzeit verfügbaren unterschiedlichen Servergrößen. Der Sizing-Report berücksichtigt diese Werte bereits vollautomatisch.

Tabelle 2.1: Verfügbarer Hauptspeicher bei unterschiedlichen Servergrößen

Scale-out-Konfigurationen für BW-Systeme haben mindestens drei Rechnerknoten. Im Minimum sind hier zwei Worker-Knoten zu einem Master dringend empfohlen. Mehr Informationen zu Scale-out finden Sie im Abschnitt 2.4.2 zur Skalierbarkeit. Zusätzliche Details zum Sizing des Master-Knotens und zur optimalen Anzahl an Scale-out-Knoten erhalten Sie auch in den SAP-Hinweisen 1855041 und 1702409.

Am Sizing des Applikationsservers ändert sich zunächst nichts im Vergleich zu einem BW-System mit einer anderen Datenbank. Dies gilt sowohl für den ABAP- als auch einen JAVA-Applikationsserver. Verwenden Sie hierzu den Quicksizer (siehe nachfolgender Abschnitt).

Ein nützlicher Nebeneffekt des Sizing-Reports ist die Ausgabe der Information, wie groß die Datenmenge in bestimmten Objekten ist. Bei sehr großen Row-Stores, Change-logs oder PSA-Tabellen erkennt man schnell, ob ein System gut gepflegt ist. Mehr zum Thema »Housekeeping« erfahren Sie in Abschnitt 2.2.7.

2.1.2 Sizing eines neuen BWs auf HANA

Beim Sizing eines brandneuen Systems für BW auf HANA sollte der Quicksizer eingesetzt werden (http://service.sap.com/quicksizer). Es gibt eine spezielle Quicksizer-Version für HANA-basierte Systeme (http://service.sap.com/hanaqs). Das Tool hilft Ihnen, nicht nur die Größe des Datenbankservers zu bestimmen, sondern auch wenn es darum geht, die Applikationsserver richtig zu dimensionieren. Es sind sehr gute und detaillierte Informationen und Videos von SAP verfügbar, sodass wir hier auf weitere Erläuterungen verzichten.

Sizing eines nicht-BW Data Warehouse für BW auf HANA

Angenommen, Sie haben ein bestehendes Data Warehouse, das nicht auf BW-Technologie basiert. Dieses System möchten Sie in ein BW auf HANA überführen. Für das Sizing gibt es zwei Möglichkeiten:

1.   Quicksizer (siehe voriger Abschnitt),

2.   manuelles Sizing.

2.1.3 Systemvermessung

Abbildung 2.1: Systemvermessung

Da es inzwischen weit über Tausend produktive BW-Systeme auf HANA gibt, steigt die Anzahl der Anfragen nach einer Systemvermessung und wie diese durchgeführt wird. Im HANA Studio können Kunden jederzeit einen Vermessungsreport generieren. Dieser erfasst die Größe des maximal von der Datenbank genutzten Hauptspeichers in den letzten zwölf Monaten. Im nachfolgenden PDF-Dokument auf dem Service Marktplatz ist das für Kunden gut dokumentiert.