Einführung in SAP HANA - s3-eu-west-1. · PDF filefür ein Data Warehouse, SAP...

LeseprobeBevor Sie mit einer SAP-HANA-Implementierung beginnen können, müssen Sie zunächst einmal die Hintergründe und Zusammenhänge verstehen. In dieser Leseprobe werden Sie alle dafür erforderlichen Informationen erhalten.

Bjarne Berg, Penny Silvia

Einführung in SAP HANA605 Seiten, gebunden, 2. Auflage 2015 69,90 Euro, ISBN 978-3-8362-3459-7

www.sap-press.de/3748

»Planung einer SAP-HANA-Implemen- tierung« (Kapitel 6)

Inhalt

Index

Die Autoren

Leseprobe weiterempfehlen

Wissen aus erster Hand.

https://www.rheinwerk-verlag.de/einfuhrung-in-sap-hana_3748/?GPP=lpn

mailto:?body=Leseproben-Empfehlung: �Einf�hrung in SAP HANA�, SAP PRESS, http://gxmedia.galileo-press.de/leseproben/3748/leseprobe_sappress_einfuehrung_sap_hana.pdf&subject=Leseprobe: �Einf�hrung in SAP HANA�

183

Bevor Sie mit einer SAP-HANA-Implementierung beginnen können,müssen Sie zunächst einmal die Hintergründe und Zusammenhängeverstehen lernen. In diesem Kapitel werden Sie daher alle dafür erfor-derlichen Informationen erhalten.

6 Planung einer SAP-HANA-Implementierung

In diesem Kapitel werden Sie mehr über die Planung einer SAP-HANA-Implementierung erfahren. Zunächst erhalten Sie einen Überblick über dieSAP-HANA-Umgebung und die von der Implementierung unabhängigenOptionen. Anschließend erfahren Sie, wie SAP-HANA-Implementierungenfür ein Data Warehouse, SAP Business Suite auf SAP HANA und SAP BW aufSAP HANA umgesetzt werden.

6.1 Von der Implementierung unabhängigeÜberlegungen

Bevor Sie eine bestimmte SAP-HANA-Implementierung planen, sollten Sieeinige allgemeine Informationen in Betracht ziehen. In diesem Abschnitterläutern wir die unterschiedlichen SAP-HANA-Editionen sowie einigeOptionen zur Auswahl der Hardware für SAP HANA.

6.1.1 SAP-HANA-Editionen

SAP hat drei unterschiedliche Editionen von SAP HANA entwickelt, die Sieallerdings nicht mit den drei unterschiedlichen Implementierungsoptionenverwechseln sollten, die in Kapitel 2 erörtert wurden:

� SAP HANA Appliance Software Platform Edition

� SAP HANA Appliance Software Enterprise Edition

� SAP HANA Appliance Software Enterprise Extended Edition

Planung einer SAP-HANA-Implementierung6

184

Die Editionen bestimmen ausschließlich, welche Komponenten in der Soft-warelizenzierung enthalten sind und wie Sie Daten extrahieren, bewegenund replizieren können. Bei jeder Implementierung von SAP HANA – sei esals Data Warehouse oder als Datenbank für SAP BW bzw. die SAP BusinessSuite – können Sie zusätzlich unter den zur Verfügung stehenden Editionenwählen.

Hinweis

Die Editionen stehen ebenfalls für die SAP HANA Rapid Deployment Solutions zurVerfügung. Wie bereits erwähnt, gehen wir in diesem Buch nicht detailliert auf dieSAP HANA Rapid Deployment Solutions ein.

Falls Sie SAP HANA für klassische Extraktions-, Transformations- und La-dungsverfahren (ETL) verwenden möchten und Ihnen bereits die SAP DataServices zur Verfügung stehen, sollten Sie sich für die SAP HANA ApplianceSoftware Platform Edition entscheiden. Diese Edition stellt eine großartigeLösung für Nicht-SAP-Unternehmen und Kunden dar, die jegliche Quellen,wie z.B. maßgeschneiderte Data-Warehouse-Anwendungen, Data Martsoder Daten aus Nicht-SAP-ERP-Systemen, beschleunigen möchten.

Die SAP HANA Appliance Software Enterprise Edition wurde für Unterneh-men entwickelt, die ihr SAP-HANA-System mit einer triggerbasierten Repli-kation verwenden möchten. Die Enterprise Edition beinhaltet zudem dieSAP Data Services, sodass Sie sowohl ETL- als auch Trigger-Verfahren durch-führen können. In Kapitel 12, »Datenbereitstellung«, werden wir noch de-tailliert auf eine triggerbasierte Replikation eingehen.

Die SAP HANA Appliance Software Enterprise Extended Edition ist für diejeni-gen geeignet, die »alles« wollen. Im Vergleich zu den anderen Editionenwurde diese Edition zusätzlich mit der logbasierten Replikation ausgestattet.Die meisten Großunternehmen, die bereits SAP ERP oder BI-Software (Busi-ness Intelligence) in ihre Systemlandschaft integriert haben, werden sicher-lich diese Edition in Betracht ziehen.

In jeder dieser Editionen haben Power-User mit dem Information Composerdie Möglichkeit, eigene Daten hochzuladen oder über eine eigene Ansichtauf In-Memory-Daten zuzugreifen. Dieses Werkzeug wird von den Kompo-nenten in den verschiedenen SAP-HANA-Editionen getrennt installiert. Wirwerden uns in Kapitel 9, »Datenmodellierung mit dem Information Compo-ser«, noch eingehend mit dem Information Composer auseinandersetzen.

Von der Implementierung unabhängige Überlegungen 6.1

185

Die in den jeweiligen Editionen enthaltenen Komponenten sind in Ta-belle 6.1 in einer Übersicht zusammengefasst.

Neben diesen drei Haupteditionen werden auch spezielle Softwareeditionenfür spezifische Zwecke angeboten. Diese bestehen aus der Datenbankeditionfür SAP BW, einer Edition für Kunden, die über einen EDGE-Lizenztyp (eineLizenz, die üblicherweise von kleinen Unternehmen erworben wird) verfü-gen, und einer limitierten Edition für Anwendungen und Beschleuniger.Diese Editionen sind zieloptimierte Lösungen, die auf der SAP-HANA-Platt-form basieren. Mithilfe dieser Angebote können kleinere Unternehmen oder

Softwarekomponente Platform Edition

Enterprise Edition

Enterprise Extended Edition

SAP HANA Studio

SAP HANA Information Composer

SAP HANA Client

SAP HANA Client for Excel

SAP HANA UI for Information Access (INA)

SAP-HANA-Datenbank

SAP Host Agent

Software Update Manager (SUM)

SAP HANA Advanced Functions Library (AFL)

Diagnostics Agent

SAP Data Services

SAP HANA Direct Extractor Connection (DXC)

SAP Landscape Transformation Tool (SLT)

Landscape Transformation Replica-tion Server

SAP HANA Load Controller (LC)

SAP (Sybase) Replication Server and Agent

SAP (Sybase) Adaptive Service Enterprise (ASE)

Tabelle 6.1 Die verschiedenen Editionen von SAP HANA


186

solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine Edi-tion erwerben, die ihren Bedürfnissen entspricht.

Als Betriebssystem wird ein SUSE Linux Enterprise Server (SLES) oder Red HatLinux verwendet. Auf dem SAP Service Marketplace finden Sie Informationenzu weiteren technischen Unterkomponenten. Diese können am bestenanhand ihrer technischen Referenzen, wie in Tabelle 6.2 aufgezeigt wird,ermittelt werden.

Bereich Komponenten-ID Komponentenname

Lifecycle Management BC-HAN-SL-STP SAP HANA Unified Installer

BC-HAN-UPD Software Update Manager (SUM)

BC-DB-HDB-INS SAP-HANA-Datenbankinstallation

BC-DB-HDB-UPG SAP-HANA-Datenbank-Upgrade

Enterprise Edition

(enthält auch Kompo-nenten der Platform Edition)

BC-HAN-DXC SAP HANA Direct Extractor Connection (DXC)

EIM-DS SAP Data Services (ETL-basiert)

BC-HAN-LOA SAP HANA Load Controller (LC) (logbasiert)

BC-HAN-LTR SAP Landscape Transformation (SLT) (triggerbasiert)

BC-HAN-REP SAP (Sybase) Replication Server (logbasiert)

Enterprise Extended Edition

BC-DB-HDB SAP-HANA-Datenbank

BC-DB-HDB-ENG SAP-HANA-Datenbank-Engine

BC-DB-HDB-PER SAP-HANA-Datenbankpersistenz

BC-DB-HDB-SYS SAP-HANA-Datenbankschnittstelle

BC-DB-HDB-DBA SAP-HANA-Datenbank/DBA Cockpit

BC-DB-HDB-POR SAP-HANA-DB-Portierung

BC-DB-HDB-BAC SAP HANA Backup and Recovery

BC-CCM-HAG SAP Host Agent

BC-DB-HDB-CCM SAP HANA Computing Center Management System (CCMS)

BC-DB-HDB-CLI SAP HANA Clients (JDBC/ODBC)

BC-DB-HDB-R SAP-HANA-Integration mit R

BC-DB-HDB-SCR SAP HANA SQLScript

Tabelle 6.2 Interne Softwarekomponenten und -referenzen


187

Um Sie stets auf den neuesten Stand bringen zu können, hat SAP eine Reihevon SAP-HANA-Hinweisen erstellt, die den verschiedenen Releases und Ser-vice Packs angefügt und jeweils entsprechend abgewandelt werden. Partnerund Hardwareanbieter sollten diese Schlüsselinformationen wegen der darinenthaltenen Aktualisierungen sorgfältig und regelmäßig lesen. Die wichtigs-

BC-DB-HDB-MDX MDX-Engine (Microsoft-Excel-Client)

BC-HAN-MOD SAP HANA Studio: Information Modeler

BC-HAN-3DM Information Composer

BC-HAN-SRC SAP HANA UI Toolkit

BC-DB-HDB-TXT SAP-HANA-Text- und Suchfunktionen

BC-DB-HDB-DXC SAP HANA Direct Extractor Connection (DXC)

BC-DB-HDB-SEC SAP-HANA-Sicherheits- und Benutzerverwaltung

BC-DB-HDB-XS SAP-HANA-Anwendungsdienste

BC-DB-HDB-AFL SAP HANA Advanced Functions Library (AFL)

BC-DB-HDB-AFL-PAL SAP HANA Predictive Analysis Library

BC-DB-HDB-AFL-SOP SAP-HANA-Absatz- und Produktionsgrobplanung (SOP)

BC-DB-HDB-PLE SAP-HANA-Planungs-Engine

Endbenutzer-Clients BI-BIP-CMC, BI-BIP BI-Plattform

BI-RA-WBI SAP BusinessObjects Web Intelligence

BI-RA-XL SAP BusinessObjects Dashboards

BI-RA-CR, BI-BIP-CRS SAP Crystal Reports

BI-RA-EXP SAP BusinessObjects Explorer

BI-BIP-IDT Information Design Tool (für Zählbestände)

BI-RA-AO-XLA Microsoft-Excel-Add-In

Bereich Komponenten-ID Komponentenname

Tabelle 6.2 Interne Softwarekomponenten und -referenzen (Forts.)


188

ten SAP-Hinweise in Bezug auf SAP HANA stehen registrierten SAP-Kundenauf der SAP-Service-Marketplace-Webseite zur Verfügung. Einen Auszug ausdiesen allgemeinen SAP-Hinweisen zu SAP HANA finden Sie in Tabelle 6.3.

Weitere für die Installation der SAP-HANA-Box erforderliche Komponentensind u.a. folgende:

� Java Runtime Environment (JRE)Die JRE wird durch Java-Komponenten in SAP HANA Studio verwendet.Für das System ist mindestens die Version JRE 1.6 erforderlich.

� XULRunnerHierbei handelt es sich um eine Laufzeitumgebung für ein gängiges Back-end für XUL-basierte Anwendungen. Für das System ist mindestens dieVersion 1.9.2 erforderlich.

� LibicuHierbei handelt es sich um einen Satz internationaler Komponenten fürUnicode.

� Network Time Protocol (NTP)Obwohl aus technischer Sicht nicht erforderlich, sollte eine Installationdurchgeführt werden, um Trace-Dateien zwischen SAP-HANA-Knoten zuunterstützen.

� SyslogdHierbei handelt es sich um ein Protokollierungswerkzeug für Systemnach-richten.

� GTK2Hierbei handelt es sich um eine Softwarekomponente für grafische Benut-zeroberflächen (GUIs).

SAP-Hinweis SAP-Hinweisname (englischer Originaltitel)

1514967 SAP HANA: Central Note

1018839 Admin (HANA)

1514966 Sizing SAP HANA Database

1523337 SAP HANA Database: Central Note

1598623 Security

1599888 SAP HANA: Operational Concept

1637145 SAP BW on HANA: Sizing SAP HANA Database

1729988 SAP BW Check for HANA Migration

Tabelle 6.3 SAP-Schlüsselhinweise für die SAP-HANA-Installation


189

Die Netzwerkverbindungen zwischen den Quellsystemen und dem SAP-HANA-Server sollten 10 GB/s betragen, damit die Effizienz der Datenreplika-tion gewährleistet werden kann. Da eine beträchtliche Datenmenge zwi-schen diesen Servern bewegt wird, ist es ebenfalls wichtig, dass die Verbin-dung nicht mit anderen Komponenten über gemeinsam genutzte Routeroder Switches geteilt wird. SAP empfiehlt, diese Verbindungen ausschließ-lich den Servern zuzuordnen und dabei darauf zu achten, dass die Entfernun-gen nicht zu groß werden. Eine Verbindung zwischen einem Server inEuropa und Amerika mit einem SAP-HANA-System in Asien ist beispiels-weise nicht ideal. Obwohl diese Empfehlung kein Muss ist und eine solcheArchitektur dennoch implementiert werden kann, sollte trotzdem nichtaußer Acht gelassen werden, dass jede langsame Netzwerkverbindunggleichzeitig auch die Replikation von Daten verlangsamt.

Softwareinstallation

Nachdem Sie sich für eine Version entschieden haben, kann Ihr Hardwarepartnermit der Installation beginnen. Um die Installation zu vereinfachen, stellt SAP denPartnern die Software SAP HANA Unified Installer zur Verfügung. Zusammen mitder Installation erhalten Sie auch das Software Logistics Toolset (SL), das den Soft-ware Update Manager (SUM) enthält. Dieses Werkzeug wird dazu verwendet, Soft-ware-Updates der SAP-HANA-Komponenten durchzuführen, um eine langfristigeKompatibilität sicherzustellen. Weitere Einzelheiten zum automatischen Software-Updateprozess erfahren Sie in Kapitel 13, »Administration von SAP HANA«.

Bitte beachten Sie, dass ausschließlich Hardwareanbieter und Installationspartnerdie SAP-HANA-SL-Software und SAP-HANA-Komponenten installieren sollten. Daes sich bei SAP HANA um eine sich gerade neu entwickelnde Technologie handelt,ist es sehr unwahrscheinlich, dass Basis-Mitarbeiter aus Unternehmen bereits überdie erforderlichen Kenntnisse für eine solche Installation verfügen. Trotz des vonSAP online bereitgestellten und detaillierten Leitfadens für SAP HANA UnifiedInstaller empfehlen wir allen Kunden ausdrücklich, die Softwareinstallation vonHardwareanbietern und zertifizierten Partnern durchführen zu lassen.

6.1.2 Hardwarespezifikationen und -optionen

SAP HANA wird als In-Memory-Appliance verkauft. Das bedeutet, dasssowohl Software als auch Hardware von den einzelnen Anbietern bereitge-stellt werden. Seit Juli 2014 können SAP-HANA-Hardwarelösungen beiCisco/EMC, Dell, Fujitsu, Hitachi, Huawei, IBM, NEC und Hewlett-Packarderworben werden.

Die Verfügbarkeit der neuen Xeon-E7-CPUs von Intel, die auch als Ivy Bridgebekannt sind, ist besonders beachtenswert. Die Schnelligkeit dieser neuen


190

Chips beruht auf den 15 Cores. In den bisherigen E7-Versionen waren nurzehn Cores verfügbar. Außerdem weisen sie eine höhere Taktrate auf; vor-läufige Testergebnisse von SAP ergaben, dass die Performance von SAPHANA mehr als doppelt so hoch ist. Wenngleich es unterschiedliche Modellegibt – 2880/90, 4880/90 und 8880/90 –, werden nur die letzten beiden der-zeit in zertifizierten SAP-HANA- Appliances eingesetzt. Die Prozessoren un-terscheiden sich im Allgemeinen in ihren Taktraten, die zwischen 2,5 und2,8 GHz liegen. Einige Prozessoren sind also schneller als andere.

Entweder können die SAP-HANA-Hardwareserver vergrößert (Scale-Up)oder mehrere kleinere Server miteinander verbunden werden (Scale-Out).Die Vorteile einer Scale-Up-Lösung sind, dass Sie weniger Server erwerbenund verwalten müssen. Der Hauptvorteil einer Scale-Out-Lösung ist, dass Siebesonders große SAP-HANA-Systeme erstellen können. Beides wird im Fol-genden kurz erörtert. Am Ende dieses Abschnitts betrachten wir schließlichnoch ein spezifisches Beispiel für ein SAP-HANA-Hardware-Setup.

SAP-HANA-Scale-Up-Systeme

Die beiden Ansätze sollten von den Basis-Mitarbeitern eines Unternehmens,das SAP HANA implementieren möchte, sorgfältig abgewogen werden. DerVorteil eines einzelnen Systems ist offensichtlich. In großen und schnellwachsenden Unternehmen allerdings ist ein Knoten mit »nur« 2 TB Speicherlangfristig gesehen möglicherweise nicht ausreichend. Um zu sehen, obdiese Speicherkapazität für Ihr Unternehmen ausreicht, müssen Sie dasDatenwachstum betrachten. Ein System mit 2 TB kann 6 bis 8 TB unkompri-mierte Daten verarbeiten.

Ebenso müssen Sie die Anzahl der aktiven gleichzeitigen Benutzer berück-sichtigen. Wenn Sie das SAP-HANA-System für Berichte und Analysen nut-zen, benötigen Sie erfahrungsgemäß 0,2 Cores pro aktivem, gleichzeitigemBenutzer. Ein 2-TB-System wie das PQ 2800 von Fujitsu mit acht Ivy-Bridge-Prozessoren mit jeweils 15 Cores könnte entsprechend bis zu 600 aktive,gleichzeitige Benutzer unterstützen (8 × 15 ÷ 0,2). Wenn Sie eine gleichzei-tige Nutzung von 20 % Ihrer Benutzer einplanen, könnte das 3.000 festgeleg-ten Benutzern entsprechen. Dies sind nur einige Grundgedanken zu denMöglichkeiten eines Scale-Up-Systems. Selbstverständlich sollten Sie jedochmit Ihrem Hardwarepartner detailliert auf das Sizing-Vorhaben, Ihr Systemund die tatsächlich genutzten Daten eingehen.


191

Ab Juli 2014 verwenden alle Hardwareanbieter mit zertifizierten, auf Ivy-Bridge-Prozessoren basierenden SAP-HANA-Lösungen den Linux SLES fürSAP Version 11 (siehe Tabelle 6.4).

Es besteht noch die Möglichkeit, die älteren E7-10-Core-Prozessoren einigerAnbieter einzusetzen (siehe Tabelle 6.5). Die einzelnen Knoten in diesen Sys-temen können etwas langsamer sein. Mit entsprechender Konfigurationkann die Rechenleistung für das Gesamtsystem jedoch erhöht werden (d.h.in einer Scale-Out-Konfiguration).

System Speicher (RAM) Protokoll- und Daten-trägergröße

CPUs (Intel Ivy Bridge EX E7)

Geplanter Einsatz

SAP Busi-ness Suite

EDW/Data Mart

EDW/SAP BW

Fujitsu PQ 2400 E/S/L

128–512 GB 896–2.048 GB 2x 8890v2

1.024 GB 3.584 GB 4x 8890v2

PQ 2800 B/E/L

128–512 GB 896–2.048 GB 2x 8890v2

1.024 GB 3.584 GB 4x 8890v2

2.048 GB 6.656 GB 8x 8890v2

HP HP Con-verged System 500

256–512 GB 2.048 GB 2x 4880v2

1.024 GB 6.930 GB 4x 4880v2

2.048 GB 17.600 GB 4x 4880v2

DELL R920 128–1.024 GB 1.204–5.120 GB 4x 4880v2

Huawei RH5885H V3

128–512 GB 4.096–8.800 GB 2x 4890v2

1.024 GB 4.096–8.800 GB 4x 4890v2

IBM x3850 X6 128–512 GB 2.662 GB 2x 8880v2

512–1.024 GB 1.200–18.000 GB 4x 8880v2

x3950 X6 1.024 GB 2.662 GB 8x 8880v2

1.536–2.048 GB Noch nicht definiert

8x 8880v2

4.096 GB Noch nicht definiert

8x 8880v2

6.144 GB Noch nicht definiert

8x 8880v2

Tabelle 6.4 SAP-HANA-Scale-Up-Lösungen mit Intel Ivy-Bridge-15-Core-E7-Prozessoren


192

SAP-HANA-Scale-Out-Systeme

SAP-HANA-Scale-Out-Systeme sind im Wesentlichen Systeme, die aus meh-reren, über ein Netzwerk miteinander verbundenen Knoten bestehen. Die-ses Netzwerk hat eine Geschwindigkeit von mindestens 10 GB, um Engpässebeim Datentransfer zwischen den Servern zu vermeiden. Die meisten SAP-HANA-Systeme können in ihrer Konfiguration an diesen Aufbau angepasstwerden. Der Vorteil der Scale-Out-Lösung ist die Fähigkeit, sehr große SAP-HANA-Systeme mit Hunderten von CPU-Cores für Zigtausende Benutzer auf-zubauen. Dies ist wirklich die Big-Data-Plattform der Zukunft.

Derzeit gibt es viele interessante Ansätze für Scale-Out-Systeme. Beispiels-weise kann das X6-System mit 2 TB von IBM ab Juli 2014 in einer Scale-Out-Lösung mit bis zu 56 Knoten konfiguriert werden, sodass ein System mit112 TB Speicher und 3360 CPU-Cores entsteht. Das HP Converged System500 ist eine SAP-zertifizierte Plattform mit Scale-Out-Möglichkeiten bis zu16 TB (dieser Wert wird in naher Zukunft möglicherweise noch erhöht).

Ein weiterer Ansatz für ein Scale-Out-System ist der Einsatz von Bladesanstelle von eigenständigen Serverknoten. Für diesen Zweck bieten Cisco/EMC B440-Blade-Server und HP BL680-Blade-Server an. Cisco/EMC hat

System HANA-Speicher

128 GB 256 GB 512 GB 1.024 GB

Cisco C260

C460

B440

Dell R910

Fujitsu RX600 S5

RX900 S2

Hitachi CB2000

HP DL-580 G7

DL-980 G7

BL-680

IBM 3690 X5

3950 X5

NEC Express 5800

Tabelle 6.5 SAP-HANA-Knoten mit Intel-E7-10-Core-Knoten


193

zudem eine gemeinsam genutzte Plattform für ein Scale-Out namens Jupitergeschaffen, in dem SAP HANA, Nearline Storage (NLS) und Hadoop in einemeinzigen System mit über 8 TB Speicher eingebunden werden. Wie Siesehen, gibt es also ausreichend Möglichkeiten für SAP-HANA-Scale-Out-Systeme.

Einige Hardwareanbieter bieten auch einen sogenannten »Investitions-schutz«. Dies bedeutet im Wesentlichen, dass Sie ältere Hardware teilweisein neueren Systemen einsetzen können, während Ihre Umgebung weiterwächst. Wenn Sie beispielsweise vor einigen Jahren ein 10-Core-Prozessor-system wie IBM 3950 erworben haben, können Sie nun neue prozessorba-sierte Ivy-Bridge-Serverknoten mit 15 Cores zu Ihrem System hinzufügen.Diese sind mit den älteren 10-Core-Knoten kompatibel. Erst wenn Ihreneuen Knoten mehr als 50 % Ihres gesamten SAP-HANA-Systems ausma-chen, müssen Sie umsteigen. Mit diesem Ansatz können Sie Tausende vonEuro einsparen und sicherstellen, dass Ihre Hardwareinvestitionen nachhal-tiger sind als bisher.

Da es hier zu Verwirrung kommen kann, empfiehlt es sich, die SAP-HANA-Experten Ihres Beraters einzubeziehen und gemeinsam mit diesen undIhrem Hardwareanbieter eine passende Lösung für Ihr Unternehmen zuermitteln. Allerdings ändern sich die Hardwaremöglichkeiten rapide. Dahersollten Sie sich nur auf Berater erlassen, die darin entsprechende Erfahrun-gen aufweisen können. Falsche Hardware kann sehr kostspielig sein. Inves-tieren Sie also erst ein wenig Zeit, bevor Sie sich für eine Scale-Out-Lösungentscheiden.

Hardwarebeispiel

Die SAP-HANA-Hardware ist in vieler Hinsicht einzigartig und wird von denjeweiligen Anbietern optimiert, um SAP-Lösungen zu unterstützen. DieseAnbieter haben bereits Erfahrungen und Expertenwissen mit der Installationund dem Support von SAP-HANA-Landschaften sammeln können. Aus die-sem Grund sollten Sie von keinem nichtzertifizierten Hardwareanbietererwarten, dass dieser die Anwendung installieren, betreiben und unterstüt-zen kann. Abbildung 6.1 zeigt ein Beispiel für Hardwarelösungen von unter-schiedlichen Anbietern.

Während der Arbeit an diesem Buch haben wir mit IBM bei der Installationund Prüfung seines High-End-x3950-X5-Servers zusammengearbeitet. Dawir hierzu nur ein System mittlerer Größe benötigten, entschieden wir uns


194

für eine Speicherkapazität von 256 GB und ein mittleres Dateisystem (sieheAbbildung 6.2).

Abbildung 6.1 Einige Hardwarelösungen von verschiedenen Anbietern

Abbildung 6.2 Innenansicht von IBM 3950 X5: das SAP-HANA-System der fünften Generation

Hitachi CB 2000

Fujitsu RX 900 S2

Dell R910

NEC Express 5800

IBM x3950 X6

Cisco C460

HP BL 680

IBM FLEX X6

HP Converge System 500 Huawei RH5885H V3

Rückseite derMaschine

Vorderseite der Maschine

PCI-Karte: Die interne PCI-SSD-Karte verwaltet die SAP-HANA-Logs

auf einem separaten GPFS (Dateisystem).

Festplatten: 1 Hot-Swap-Platte; der Restfungiert als virtuelles Laufwerk. Sie

enthalten den Failover für SAP HANA.

Prozessoren (10 Kerne, Intel-Xeon-E7-Serie)

Hauptspeicher:256 GB installiert,

erweiterbar bis 512 GB.Das ist die SAP-HANA-DB.

Doppelte Strom-versorgung


195

2014 begannen wir mit dem Aufbau des neuen 3850-SAP-HANA-Modular-systems der sechsten Generation (X6) (siehe Abbildung 6.3).

Abbildung 6.3 Innenansicht von IBM 3850 X6: das SAP-HANA-System der sechsten Generation

Die Hardware ist völlig neu angeordnet. Sie umfasst Flash-Speicherbankenund eigenständige Recheneinheiten sowie einen Speicher für die Persistenzder SAP-HANA-Datenprotokolle und die Datendateien. Das neue Systembeinhaltete zudem 15-Core-Prozessoren, die viel schneller waren als das X5-2013-System. Wir haben das System mit 1,222 Milliarden Zeilen getestet.Die Abfragegeschwindigkeit erhöhte sich um mehr als 268 % – mehr als dop-pelt so schnell.

Obwohl sich dieses Hardwarebeispiel speziell auf die High-End-Systeme derx-Serie von IBM bezieht, sind die Komponenten anderer Anbieter damitdurchaus vergleichbar und somit für Sie eine gute Grundlage, um die Zusam-menhänge zu verstehen.

Ein modulares SAP-HANA-IBM-3850-X6-System mit 4 Sockeln und 4 Rechen-

blöcken. Eine Version mit 8 Einheiten war für die 3950-Konfiguration verfügbar.

Jede Recheneinheit hat zweiLüfter zur Kühlung. Es handelt

sich um ein Hot System.

Dies sind die Speicherbanken. Jede Rechen-einheit kann theoretisch über einen Speichermit 6 TB bzw. einen eXFlash-Speicherkanal

mit 12,8 TB verfügen.

Für den internen Speicherder Protokolldateien und

zur persistenten Datenspeicherung.

Bis zu 6,4 TBeXFlash bzw. 12,8 TB

herkömmlicher Speicherwaren möglich.

Wärmeableiterzur Kühlungdes Systems

Jede Recheneinheitumfasst einen Intel-E7-Ivy-Bridge-Prozessor mit

15 Kernen.


196

6.2 SAP HANA als Data Warehouse

Auch wenn die Implementierung von SAP HANA als Data Warehouse eineder einfachsten Möglichkeiten ist, die Geschwindigkeit dieser Plattform zunutzen, gibt es einige Aspekte, die sorgfältig geplant werden sollten. Die bei-den wichtigsten Aspekte sind die Datenmodellierung und das Sizing, die imfolgenden Abschnitt erörtert werden.

6.2.1 Datenmodellierung

Beim Modellieren von Daten für SAP HANA als Data Warehouse musssichergestellt werden, dass zwei Dinge berücksichtigt werden: Zum einensollte die Geschwindigkeit von SAP HANA ausgenutzt werden. Zum anderensollte die Geschwindigkeit nicht weiter optimiert werden, wenn dies nichterforderlich ist.

Zum besseren Verständnis betrachten wir nun die traditionellen Sternsche-mata und Schneeflockenmodellierungstechniken, die für ein In-Memory-Data-Warehouse möglicherweise nicht geeignet sind. Diese Techniken die-nen primär zur Reduzierung von Tabellen-Joins und Datenmengen im DataWarehouse. Hierbei wurden einfach die dritten Normalformmodelle imTransaktionssystem verwendet und denormalisiert, indem Ereignis- (Fakten)und Dimensionstabellen (Beschreibungen) erzeugt wurden. Dies hatte zweiVorteile. Zum einen erübrigten sich kostenintensive Tabellen-Joins, wennStammdaten, die über Dutzende von Tabellen verteilt waren, abgefragt undmit Transaktionsdaten verbunden wurden. Angepasste Dimensionen erzeug-ten einfach denormalisierte Tabellen für alle Kunden, Anbieter und Pro-dukte, und der Modellierer konnte diese Daten mit Vorgängen wie Verkauf,Lieferung und Fakturierung verknüpfen. Zum anderen entfielen die hohenKosten für die Aufzeichnung aller Ereignisse und Stammdaten in einer einzi-gen Tabelle, wie dies bei Modellen der ersten Normalform oder bei Vor-gangsdateien der Fall ist.

Um das System noch weiter zu beschleunigen, erstellten Dimensionsmodel-lierer Übersichtstabellen. Zudem stellten sie sicher, dass die langsamerenAbfragen, die zusammengefasste Daten benötigten, auf diese Tabellen undnicht auf die Faktentabellen mit detaillierten Vorgängen umgeleitet werdenkonnten. Andere erstellten zusammenfassende Sternschemata mit unter-schiedlicher Granularität (z.B. Gesamtumsatz nach Produkt, Geschäft, proTag). Um noch schnellere Ergebnisse zu erhalten, wurde es schließlich gän-gige Praxis, dass die Abfragen vorab durchgeführt und die Zwischenergeb-

SAP HANA als Data Warehouse 6.2

197

nisse auf den Anwendungsservern in den Speicher-Caches vorgehalten wur-den – es wurde keine Möglichkeit ausgelassen, um mehr Geschwindigkeitaus dem festplattenbasierten Data Warehouse herauszuholen.

Viele dieser Ansätze sind ungeeignet, wenn SAP HANA als Data Warehouseeingesetzt wird. In einem spaltenbasierten Speicher beispielsweise wirddurch die Kompression ein Großteil der Datenredundanzen aus den Model-len der ersten bzw. zweiten Normalform entfernt. Der Aufwand für dieseAnsätze kann also oft minimal sein. In SAP HANA gibt es keine »echten«Tabellen. Stattdessen stehen komprimierte zeilen- und spaltenbasierte Spei-cher auf Indexbasis bereit, die als Tabellen mit einfachem Zugriff und einfa-cher Modellierung angezeigt werden. Im Data Warehouse gibt es hauptsäch-lich Spaltenspeicherdaten und Tabellen-Joins. Es handelt sich lediglich umeine semantische Ansicht dessen, was in der neuen Datenbank stattfindet.Mit anderen Worten, die kostenintensiven Tabellen-Joins, die in den tradi-tionellen Dimensionsmodellen vermieden werden sollten, sind nicht mehrvorhanden.

Außerdem ist der Einsatz von Übersichtstabellen in den meisten Fällen nichtsinnvoll, wenn das System ohnehin schon sehr schnell ist. Das Zwischenspei-chern von Zwischenergebnissen (z.B. durch Übermittelung in den Cache) istnur in äußerst seltenen Fällen sinnvoll.

Sogar die Vorgehensweise zur Extraktion, Transformation und zum Laden(ETL) ändert sich bei SAP HANA. Bei herkömmlichen Data Warehouseserfolgt die Transformation während der Extraktion aus dem Quellsystembzw. auf Ebene des Anwendungsservers, auf dem die ETL-Werkzeuge instal-liert sind. Bei SAP HANA ist es oft sinnvoll, die Daten einfach in der vorlie-genden Form zu laden und die Transformationen innerhalb von SAP HANAüber Berechnungen, Analysesichten bzw. über SQL-Skripte durchzuführen,wenn die Daten zwischen den Staging- und Berichtsebenen in den Modellenbewegt werden. Dies kann die Transformationen deutlich beschleunigen,und Sie müssen sich nicht auf kleinere, langsamere Server auf der ETL- oderAnwendungsebene verlassen.

Kurzum, Sie sollten die Modellierungsansätze für das Data Warehouse noch-mals überdenken, wenn Sie mit SAP HANA arbeiten. Sie sollten sich fragen,ob die älteren Methoden tatsächlich noch sinnvoll sind. Es stehen viele, sehrgute Hilfsquellen im Internet und in Buchhandlungen zur Verfügung, dieerläutern, warum Operational Data Stores (ODS) in dieser neuen Herange-hensweise wichtiger sind als Sternschemata.


198

Hinweis

Wir empfehlen den Kurs HA-300 der SAP-Schulungen für Neulinge im BereichModellierung bei SAP HANA. Der Titel des Kurses ist »SAP HANA – Implementa-tion and Modeling«.

6.2.2 Sizing

Wenn Sie planen, Daten aus einem Transaktionssystem zu verschieben oderDaten aus einem bestehenden System zu konvertieren, ist ein besonderswichtiges Kriterium beim Sizing eines SAP-HANA-Systems das Komprimie-rungsverhältnis beim Verschieben von Daten in die In-Memory-Plattform.Einige Kunden konnten sehr hohe (8- bis 10-fache) Komprimierungen fest-stellen, während andere »nur« eine 3,8-fache Datenreduktion erzielt haben.Aus diesem Grund empfiehlt SAP, mit einer Planung von einem 3- bis5-fachen Faktor für das Sizing des jeweiligen Systems zu beginnen undanschließend detaillierter auf das Sizing-Vorhaben einzugehen.

Die Unterschiede bei diesen Komprimierungszahlen entstehen dadurch,dass einige Unternehmen bereits relationale Datenbanken mit umfangrei-chen Komprimierungsmethoden (z.B. DB2 v10 oder die native Komprimie-rung in der Oracle-12g-Datenbank) verwenden, während andere über Da-tenbanken mit eingeschränkteren Komprimierungsfähigkeiten verfügen.Natürlich erwarten wir höhere Komprimierungszahlen in Datenbanken, dieohnehin geringe Komprimierungsfähigkeiten aufweisen. Hinzu kommenUnterschiede in der Art und Weise, wie Datentypen komprimiert werden(d.h., Strings sind eigentlich Arrays in den meisten Datenbanken), währendZahlen in den meisten Versionen der Oracle-Datenbanken bereits auf bis zu50 % komprimiert sind. Und schließlich gibt es auch Unterschiede bei denIndexgrößen, die entweder zeilen- oder spaltenbasiert sind. Um eine grobeSchätzung zu erhalten, empfiehlt es sich, als ersten Schritt die Faustregel des3- bis 5-fachen Faktors anzuwenden.

Das Sizing von SAP HANA als Data Warehouse ist darüber hinaus auch einStück Wissenschaft. Es besteht aus dem Sizing des erforderlichen Speichers(spaltenbasierte Speicher, zeilenbasierte Speicher sowie Speicher für Cachesund Komponenten) und der Größeneinteilung des Datenträgers (Log undPersistenz) sowie des CPU-Sizings für die zu erzielende Rechenleistung.Glücklicherweise gibt es einige grundlegende Methoden, um die Größeeines Systems festzulegen:


199

� SAP QuickSizer Dieses Werkzeug ist für Unternehmen geeignet, die noch kein SAP-ERP-oder SAP-BW-System verwenden oder eine Rapid Deployment Solutionbevorzugen.

� Faustregel beim SizingFür all diejenigen, die eine Sizing-Übung überspringen möchten, gibt esauch die Möglichkeit, das Sizing eines Systems basierend auf einer Reihevon allgemeinen Empfehlungen durchzuführen. Das Ergebnis werden all-gemeine Schätzungen sein, die Ihnen einen vorläufigen Eindruck davonvermitteln können, was beim Sizing eines Systems zu erwarten ist. Den-noch sollten Sie vor der tatsächlichen Implementierung eines Systems eindetaillierteres Sizing durchführen.

� T-Shirt-ModellSAP bietet auch ein T-Shirt-Modell für umfangreiche Schätzungen. Wie dieanderen Methoden sollte auch diese nur für allgemeine Schätzungen ange-wendet werden. Sie ist nicht zuverlässig genug, um sie als einzige Sizing-Methode anzuwenden.

SAP QuickSizer

QuickSizer für SAP HANA steht unter dem Link http://service.sap.com/quick-sizer zur Verfügung (ein SAP-Service-Login ist hierzu erforderlich). Für diedrei verschiedenen Versionen von SAP HANA stehen entsprechend dreiunterschiedliche Versionen dieses Werkzeugs zur Verfügung (siehe Abbil-dung 6.4).

Abbildung 6.4 Arten der SAP-HANA-QuickSizer-Werkzeuge

Wenn Sie mit dem Sizing Ihres Data Warehouses beginnen, geben Sie dieProjektdaten, die Anzahl der Benutzer und den Speicherbedarf für die Daten


200

ein, die Sie auf SAP HANA übertragen möchten. Es ist wichtig, dass Sie dieseZahl als unkomprimierte Daten angeben. Ist in Ihrem Quellsystem eine Kom-primierung von 30 % aktiviert, sollten Sie 30 % zu der im Quellsystem ange-zeigten Datenmenge hinzufügen. Außerdem definieren Sie den Zeitraum, indem Ihr System aktiv ist (siehe Abbildung 6.5).

Abbildung 6.5 QuickSizer-Eingabe für SAP HANA als Data Warehouse

In diesem Beispiel gehen wir von 350 Benutzern und einer Datenmenge von600 GB aus, die aus einer Oracle-Datenbank geladen werden sollen. Hiermuss berücksichtigt werden, dass beim Sizing die bereits verfügbaren Daten(300 GB) sowie die Daten der nächsten drei Jahre einbezogen werden müs-sen (planmäßig 100 GB pro Jahr). Der Eingabewert ist also 600 GB insge-samt. Die Start- und Endzeiten sind von 9:00 bis 18:00 Uhr.

Sie können neue Quellsysteme hinzufügen, indem Sie eine Zeile markierenund darüber auf die Schaltfläche Insert klicken. So können Sie mehrereQuellsysteme in das Sizing einbeziehen. Wenn Sie Ihre Eingaben abgeschlos-sen haben, klicken Sie einfach auf Calculate result. Sie können nun mit derAnalyse der Sizing-Ergebnisse beginnen (siehe Abbildung 6.6).

In diesem Beispiel benötigen Sie 246 MB RAM in Ihrem System und einSystem, das 70.000 SAPS unterstützen kann. Der Begriff SAPS ist eine ein-heitliche Kennzahl der Systemperformance, die jeder Hardwareanbieter ineinem System-Sizing umsetzen können sollte. Ursprünglich sollte mit dieserKennzahl gemessen werden, ob Bestellungen verarbeitet werden können.100 SAPS wurden als 2.000 vollständig verarbeitete Business-Auftragsposi-tionen pro Stunde festgelegt. Mittlerweile ist es jedoch eine Standardmaß-einheit, mit der Hardwareanbieter die Größe von Anwendungsservern undder SAP-HANA-Datenbankserver ermitteln.


201

Abbildung 6.6 QuickSizer-SAP-HANA-Sizing-Ergebnisse

Sie können die Sizing-Ergebnisse einfach für die Anbieter ausdrucken undum ein Angebot für die Hardware bitten. Gehen Sie für Sandbox-, Entwick-lungs-, Qualitätssicherungs- und Hochverfügbarkeitssysteme gleichermaßenvor. Die Größe für diese Systeme kann variieren.

Faustregel für das Sizing

Es gibt auch noch andere schnelle Wege, um eine ungefähre Vorstellungdavon zu bekommen, wie groß Ihr System sein wird. Diese Faustregeln las-sen sich sehr gut für vorläufige Schätzungen und Budgetierungen auf hohemNiveau anwenden. Um jedoch genaue Zahlen zu erhalten, sollten Sie, wiebereits erklärt, eine echte Sizing-Methode verwenden. Zunächst müssen Sieden benötigten Speicherplatz abschätzen.

Speicher = 50GB + [Quelldaten + bestehende DB-Komprimierung] ÷ 4 × 2

Die 50 GB stehen SAP-HANA-Services und -Caches zur Verfügung. Der Wert4 ist die durchschnittliche Komprimierung, die für zeilen- und spaltenba-sierte Speichertabellen erwartet wird. Der Faktor 2 bezieht sich auf denerforderlichen Speicherplatz für Laufzeitobjekte und auf temporäre Ergeb-nissätze in SAP HANA. Und abschließend steht der Begriff bestehende DB-Komprimierung für Komprimierungen, die bereits auf Ihrem System durchge-führt wurden (falls zutreffend). Dieser Vorgang ist kompliziert, und wennSie lediglich einige Anhaltspunkte brauchen, können Sie auch einfach dieDatenbankgröße Ihres Systems als Grundlage nehmen und diese durch 4 tei-


202

len. Aber denken Sie daran, dass es sich hierbei nur um Faustregeln handelt.In einem echten System kann es eine 8- bis 9-fache Komprimierung geben.

Sie können beispielsweise mit einem Data-Warehouse-System anfangen, dieLog-Dateien bereinigen und Aggregate (mit SAP HANA nicht erforderlich)und die temporären Speicherdateien entfernen. Dieses bereinigte Data-Warehouse-System bietet Ihnen eine Ausgangsbasis für das SAP-HANA-Sizing.

In unserem Faustregel-Beispiel erhalten Sie eine Datenbank mit 1,4 TB un-komprimierten Daten, wenn Sie ein altes Data-Warehouse-System mit 1 TBhaben, das System bereits 40 % Komprimierung verwendet und Sie diesenProzentsatz erneut hinzurechnen. Wenn Sie diesen Wert durch 4 teilen, er-halten Sie eine SAP-HANA-Datenbank mit einer Größe von 350 GB. An-schließend multiplizieren Sie das Ergebnis mit 2, um Speicher für interneProzesse, Indizierung, Datenbewegung und Endanwender zu ermöglichen,und fügen zum Schluss 50 GB für den internen Speicher von SAP HANAhinzu. Das ergibt eine grobe Schätzung von 710 GB an erforderlichemSpeicher.

Als Nächstes benötigen Sie Festplattenplatz, der wie folgt abgeschätzt wer-den kann:

Festplatte für die Persistenzschicht = 4 SpeicherFestplatte für den Log = 1 Speicher

In diesem Beispiel benötigen Sie vier 750-GB-Festplatten für die Persistenz-schicht und etwa 750 GB für die Logs. Dies entspricht etwa 3,75 TB (keineSorge, Festplattenspeicher dieser Größe sind heutzutage recht kostengüns-tig). Die Persistenzschicht ist die Festplatte, die das System sichert und fürRedundanz sorgt, falls es zu Speicherfehlern kommt, und sollte daher nichtunterschätzt werden.

Sie können natürlich immer mehr Speicher hinzufügen, während das Systemweiter wächst. Es wird jedoch empfohlen, lieber etwas mehr Platz einzupla-nen, damit der Festplattenplatz nicht zu klein ist. So verhindern Sie, dass Siedirekt nach dem »Go-Live« als Erstes mehr Speicher hinzufügen müssen.Außerdem sollte diese Festplatte nicht auf einem gemeinsam und starkgenutzten Storage Area Network platziert werden. Versuchen Sie, die SAP-HANA-Festplatte so gut wie möglich als spezielle und separate Festplatte ein-zusetzen.

Die CPUs basieren auf der Anzahl der enthaltenen Kerne. Inzwischen existie-ren CPUs mit 15 Kernen. Wenn Sie einen Knoten mit 4 × 15 Kernen haben,


203

erhalten Sie 60 Kerne und können somit 300 aktive Benutzer auf diesemHardwareknoten arbeiten lassen – sowie eine viel größere Anzahl von festge-legten Benutzern. Beim Sizing durch SAP-Anbieter ist es üblich, Prozessorenbasierend auf der Speichergröße von SAP HANA hinzuzufügen, sodass ihreeigentliche Zahl durchaus unterschiedlich ausfallen kann. Der CPU-Bedarfwird mit der folgenden Formel ermittelt:

CPU = 0,2 CPU-Kerne pro aktivem Benutzer

Je nachdem, wem Sie Zugriff gewähren, kann es schwer sein, die Anzahl deraktiven Benutzer zu bestimmen. In der Vergangenheit waren in Data Ware-houses meist 20 bis 40 % der festgelegten Benutzer aktiv, während in ERP-Systemen eine höhere Zahl üblich ist. Wenn Sie ein älteres System auf SAPHANA verschieben, erhalten Sie die tatsächlichen Nutzungszahlen aus denSystemüberwachungswerkzeugen, die der Administrator wahrscheinlichbereits einsetzt. Sie werden daraus ersehen können, wie viele Ihrer festgeleg-ten Benutzer gegenwärtig Ihr System verwenden, wobei die Aktivitäten die-ser Benutzer in »niedrig«, »mittel« und »hoch« aufgegliedert werden. DieseInformationen können bei der Bestimmung der Anzahl erforderlicher CPU-Kerne sehr hilfreich sein.

Die CPU-Geschwindigkeit kann abhängig vom Kaufdatum Ihres SAP-HANA-Systems variieren. Seit Sommer 2014 ist die neue Intel-E7-Ivy-Bridge-Seriemit einer Taktrate von 2,5 bis 2,8 GHz ausgestattet. Es ist sehr wahrschein-lich, dass in Zukunft noch schnellere Prozessoren eingesetzt werden.

T-Shirt-Sizing

Für eine noch schnellere Referenz können Sie ein T-Shirt-Sizing-Modell ver-wenden. Diese Aufstellung asiert auf ähnlichen Regeln wie den zuvor erläu-terten, kategorisiert jedoch die Größen auf praktische Weise in extra kleinebis extra große SAP-HANA-Umgebungen (siehe Tabelle 6.6). Diese Aufstel-lung lässt sich leicht lesen, sollte aber nicht für die Budgetierung oder Ein-kaufsentscheidungen genutzt werden, da sie nicht absolut verlässlich ist.

Da mehr Kerne zur Verfügung stehen (aktuell zehn pro Prozessor), solltenKunden, die sich eine Speicherkapazität von mehr als 1.024GB wünschen,zusammen mit ihrem Hardwarepartner mehrere Knotensysteme miteinan-der verbinden oder größere Knoten für eine erhöhte Skalierbarkeit verwen-den. Derzeit haben SAP und IBM neue Systeme mit über 100 TB Speichervorgeführt, sodass die allgemeine Skalierbarkeit kein größeres Problem fürdie meisten Unternehmen darstellen sollte.


204

Ein anderer wichtiger Faktor für viele wird die Geschwindigkeit sein, mit derDaten repliziert werden können. Die kleineren Systeme sind auf ca. 5–10 GBpro Stunde beschränkt, während die größeren Systeme bis zu 30 GB undmehr erreichen können. Da sich diese Zahlen jedoch mit neuen Hardware-versionen und neuen SAP-HANA-Versionen häufig ändern, sollten sie ledig-lich als Orientierungshilfe dienen. Dieser Bereich entwickelt sich schnellweiter. Daher sind die meisten Hardwarebeispiele nur begrenzt gültig.

6.3 SAP Business Suite auf SAP HANA

Seit Januar 2013 bietet SAP Unterstützung für die SAP Business Suite auf SAPHANA. Dies bedeutet, dass Sie ein neues SAP-ERP-System auf SAP HANAinstallieren oder Ihr bestehendes System auf SAP HANA migrieren können,um die einfachere Architektur sowie die signifikanten Performancevorteilevon SAP HANA zu nutzen. Zahlreiche Unternehmen haben ihre SAP-ERP-Systeme bereits auf SAP HANA verschoben oder dieses installiert. DieserTrend setzt sich immer weiter fort. Seit Juli 2014 müssen Sie als Ramp-Up-Kunde registriert sein, um Zugriff auf diese Lösung zu erhalten.

Datenkompri-mierung (Daten-menge vor Komprimierung)

Arbeits-speicher

Prozessoren SAS/SSD (für Daten)

Replikations-geschwindig-keit (pro Stunde)

XXL 7.000–250.000 GB 3.072 GB bis 112+ TB

8 x 15 Cores + Intel E7 2,8 GHz

15+ TB 30+ GB

XL 3.500–7.000 GB 2.048–2.560 GB

8+ Intel E7 2,5+ GHz

5–10 TB 30+ GB

L 2.000–3.500 GB 1.024 GB 4 Intel E7 2,5+ GHz

4–5 TB 10–20 GB

M 1.250–2.000 GB 512 GB 4 Intel E7 2,5+ GHz

2.048 GB 10–20 GB

S 500–1.250 GB 256 GB 2 Intel E7 2,5+ GHz

1.024 GB 5–10 GB

XS 256–500 GB 128 GB 2 Intel E7 2,5+ GHz

1.024 GB 5–10 GB

Tabelle 6.6 SAP-HANA-T-Shirt-Sizing

SAP Business Suite auf SAP HANA 6.3

205

Hinweis

Vor der Migration sollten Sie das optionale Enhancement Package 6 für SAPERP 6.0 mit der SAP-HANA-Version installieren. Wenn Sie allerdings Branchen-lösungen mit Zusatzfunktionen nutzen, werden möglicherweise nicht alle durchdas Enhancement Package unterstützt. Lesen Sie SAP-Hinweis 1774566 sorgfäl-tig, bevor Sie mit diesem Prozess beginnen. Sollten Sie sich für den Prozess ent-scheiden, müssen Sie eine separate Vereinbarung unterzeichnen, in der Ein-schränkungen hinsichtlich der SAP-Lizenz- und Wartungsvereinbarung erläutertwerden. Weitere Informationen hierzu erhalten Sie in SAP-Hinweis 1768031.

Es gibt drei Implementierungsoptionen, um ein SAP-Business-Suite-Systemauf SAP HANA in Ihrem Unternehmen umzusetzen:

� vollständige Neuinstallation

� In-Place-Migration

� kopieren, upgraden und migrieren

Diese Optionen werden im Folgenden erörtert. Anschließend erhalten Sieeinige Tipps für das Sizing (passend zu den verschiedenen Implementie-rungsoptionen).

Zusätzlich zu diesem Abschnitt empfehlen wir die SAP-Hinweise zu SAPBusiness Suite auf SAP HANA (siehe Tabelle 6.7).

Name Beschreibung

SAP-Hinweis 774615 Support Package Levels for SAP ERP /SAP ECC Installa-tion and Upgrades

Liste der erforderlichen Support Packs

SAP-Hinweis 855498 Installation Prerequisite Checker

SAP-Software auf UNIX, Windows und IBM i: Über-prüfen der Abhängigkeiten der Betriebssysteme

SAP-Hinweis 998833 Release Restrictions: SAP ERP 6.0 – Enhancement Packages

Informationen über die Ein-schränkungen bei den SAP Enhancement Packages für SAP ERP 6.0

SAP-Hinweis 1730095 EHP6 for SAP ERP 6.0 on HANA – Release Infor-mation

Releaseinformationen und Äquivalenzebenen der Sup-port Packs

Tabelle 6.7 Wichtige Hinweise für SAP Business Suite auf SAP HANA


206

6.3.1 Vollständige Neuinstallation

Dies ist die einfachste Option, um die SAP Business Suite auf SAP HANA zuimplementieren. In diesem Szenario erwerben und installieren Sie ein völligneues SAP-HANA-System einschließlich SAP Business Suite. Auch wenn essich nicht für die Migration eines Produktivsystems empfiehlt, können Siehiermit einige Daten in das SAP-HANA-System (d.h. die Stammdaten undoffene Bestellungen) migrieren, um die neuen Funktionen von SAP HANAnutzen zu können.

Dieser Ansatz eignet sich vor allem für jene, die ältere Implementierungenbereinigen und dabei ein Upgrade auf neuere Versionen der SAP BusinessSuite vermeiden möchten. Er eignet sich ebenfalls für Benutzer, die die SAPBusiness Suite zum ersten Mal implementieren. Starten Sie für diese Installa-tion das Installationswerkzeug Software Provisioning Manager 1.0, und folgenSie dem SAP Installation Guide.

SAP-Hinweis 1760306 SAP EHP6 for SAP ERP 6.0, version for SAP HANA 1.0: Add-ons

Zu berücksichtigende Aspekte beim Einsatz von SAP Enhancement Package 6 für SAP ERP 6.0, Version für SAP HANA in Kombina-tion mit einem Add-on im selben System

SAP-Hinweis 1768031 SAP EHP 6 for SAP ERP 6.0, version for SAP HANA

Einschränkungen hinsicht-lich des produktiven Einsat-zes von SAP Enhancement Package 6 für SAP ECC 6.0, Version für SAP HANA

SAP-Hinweis 1774566 SAP Business Suite Powered by SAP HANA – Restrictions

Einschränkungen für SAP ECC auf SAP HANA

SAP-Hinweis 1785057 Preparatory Steps for Database Migration to SAP HANA

Informationen über die vor-bereitenden Schritte für die Datenbankmigration auf SAP HANA

SAP-Hinweis 1789632 EHP6 for SAP ERP 6.0 on HANA – HANA Content Activation

Informationen über manuell zu aktivierende Inhalte

Name Beschreibung

Tabelle 6.7 Wichtige Hinweise für SAP Business Suite auf SAP HANA (Forts.)


207

Vor der Installation sind folgende Schritte notwendig:

1. Deaktivieren Sie die Windows-Server-Firewall.

2. Vergewissern Sie sich, dass das Windows-Dateisystem NTFS ist (nichtFAT).

3. Überprüfen Sie die Windows-Domänenstruktur. Bei Domain-Installatio-nen sollten alle SAP-Systemhosts Teil einer einzigen Domäne sein.

4. Stellen Sie im Windows-Server den Hochleistungs-Energiesparplan ein.

5. Stellen Sie sicher, dass der Benutzer die Berechtigung zur Installation derSoftware in der Domäne hat. (Verwenden Sie nicht den Benutzer <sapsid>adm für die Installation des SAP-Systems.)

6. Erstellen Sie das Verzeichnis \usr\sap\trans auf dem Host, der als Trans-porthost verwendet werden soll, und geben Sie das Verzeichnis usr\sapauf dem Transporthost als SAPMNT frei. Setzen Sie bei dieser Freigabe dieBerechtigung für Everyone auf Full Control. Somit kann das Installati-onsprogramm das Transportverzeichnis im Standard \\SAPTRANSHOST\SAPMNT\trans adressieren. Erteilen Sie schließlich Everyone die Berech-tigung Full Control für das Transportverzeichnis.

7. Beschaffen Sie die physischen Installationsmedien als Teil des Installa-tionspakets. Sie können den Software Provisioning Manager 1.0 ver-wenden.

8. Ermitteln Sie die Komponenten für Ihre Installation, wie z.B. die zentraleServiceinstanz für ABAP (ASCS), die Datenbankinstanz, den Enqueue Rep-lication Server sowie die primäre(n) und zusätzliche(n) Anwendungsser-verinstanz(en).

9. Vergewissern Sie sich, dass die Anwendungsserver und die SAP-HANA-Datenbankserver für dieselbe Zeitzone eingerichtet sind.

Die eigentliche Installation umfasst folgende Schritte:

1. Stellen Sie sicher, dass die Ports für 21200, 4239 und 21212 nicht blo-ckiert sind. Das Installationswerkzeug Software Provisioning Manager 1.0verwendet Port 21200 zur Kommunikation mit dem GUI-Server; der GUI-Server verwendet Port 21212 zur Kommunikation mit dem GUI-Clientund Port 4239 des HTTP-Servers. Daher müssen alle Ports offen sein.

2. Sorgen Sie dafür, dass im Installationsverzeichnis mindestens 300 MBSpeicherplatz für jede Installationsoption sowie 300 MB freier Speicher-platz für die ausführbare Datei des Installationsprogramms zur Verfügung


208

stehen. Wenden Sie SAP-Hinweis 1697164 an, und vergewissern Sie sich,dass die Datenbank in Betrieb ist, bevor Sie die Installation starten.

3. Doppelklicken Sie auf sapinst.exe in dem Verzeichnis, in das Sie die DateiSWPM10SP<Support Package-Nummer>_<Versionsnummer>.SAR entpackthaben. Der Installationsprozess wird gestartet. Folgen Sie nun den Anwei-sungen auf dem Bildschirm (siehe Abbildung 6.7).

Abbildung 6.7 Installation des SAP-HANA-Anwendungsservers für SAP Business Suite

6.3.2 In-Place-Migration

Eine In-Place-Migration ist die gängigste Methode für Benutzer, die bereitsein funktionierendes SAP-Business-Suite-System haben und auf SAP HANAmigrieren möchten. Bei dieser Methode werden im Wesentlichen Änderun-gen an der Gesamtlandschaft vermieden, indem SID, Hostname, Anwen-


209

dungsserver und Konnektivität beibehalten werden. Folglich wird nur derDatenbankserver während der Installation verändert, und die anderen Teileder Landschaft bleiben weitestgehend intakt. Die Ausfallzeit bei der Migra-tion wird primär zum Verschieben der Datendateien von der alten Daten-bank auf die SAP-HANA-Datenbank genutzt. Daher richtet sich die notwen-dige Ausfallzeit meist nach der Größe des SAP-Business-Suite-Systems. Beiden ersten SAP-Business-Suite-Systemen, die auf SAP HANA migriert wur-den, erfolgte dies im Rahmen eines herkömmlichen Upgrades. Hierzu gehör-ten das Patchen des Systems, ein Upgrade der Anwendung auf die erforder-liche Ebene, die Implementierung von Unicode und schließlich dieMigration zu SAP HANA.

Heute können Sie ein neues Werkzeug mit dem Namen Database MigrationOption (DMO) einsetzen und all diese Aufgaben in einem Schritt erledigen.Die Ausfallzeit des Systems ist hierbei auf ein Minimum reduziert. DMO istkein separates Werkzeug, sondern eine im Software Update Manager (SUM)Version 1 Service Pack 9 verfügbare Option. Wenn Sie eine ältere Versionvon SAP ERP verwenden, ist das DMO-Werkzeug hervorragend für eine pa-rallele Durchführung von Upgrade und Migration geeignet. Dieses Werk-zeug wird auch für alle SAP-In-Place-Migrationen empfohlen. Mit der DMO-Option kann der Systemteil der SAP Business Suite 7.0 auf eine Stufe ent-sprechend zu SAP NetWeaver 7.40 migriert werden. Dieser Vorgang umfasstauch Migrationen von SAP ERP Version 6.0 EHP 7. DMO wird ebenfalls fürdie Migration von SAP BW auf SAP HANA genutzt.

Mithilfe des DMO-Werkzeugs wird innerhalb des SAP-Business-Suite-Sys-tems ein Schattensystem, ein sogenanntes Schatten-Repository, erstellt. Die-ses Schattensystem umfasst eine kleine Menge an Daten und wirkt sich nichtauf das bestehende System aus, wenn ausreichend Systemressourcen vor-handen sind. Sie können gemeinsam mit Ihrem Implementierungspartnervor einem Upgrade ermitteln, ob dies der Fall ist. Im zweiten Schritt derKonfigurationsphase stehen Ihnen drei Optionen für die DMO-Migrationzur Verfügung. Die Standardoption sollte automatisch ausgewählt werden,falls Sie nicht wissen, ob die Systemressourcen in Ihrem bestehenden SAP-ERP-System für eine Datenbankmigration mit geringer Ausfallzeit ausrei-chend sind (siehe Abbildung 6.8).

Wenn Sie die erweiterte Option ausgewählt haben, können Sie nun mit denverbleibenden Konfigurations- und Prüfaufgaben fortfahren. Mit dem DMO-Werkzeug werden Sie durch die einzelnen Schritte geleitet. Wenn Sie beiSchritt 4, der sogenannten Vorverarbeitung, angelangt sind, wird das Schat-


210

ten-Repository erzeugt. Zu diesem Zeitpunkt sind keine Änderungen an derSystemkonfiguration mehr möglich. Falls Sie dennoch Änderungen vorge-nommen haben, kann es sein, dass die Konfigurationen des Schatten- unddes tatsächlichen Systems nicht mehr übereinstimmen. Benutzer könnenjedoch weiterhin auf das System zugreifen und Transaktionen buchen; neueTransporte in die Umgebung sind allerdings nicht mehr möglich (sieheAbbildung 6.9).

Abbildung 6.8 »Database Migration Option« (DMO) – Reduzierung des Systemausfalls

Abbildung 6.9 »Database Migration Option« (DMO) – Sperrung der Entwicklungsumgebung

Die folgenden Upgradeschritte finden im Schattensystem statt, während dastatsächliche System weiterläuft. Sobald das Upgrade des Schattensystems


211

abgeschlossen ist, wird mit dem DMO-Werkzeug das Schattensystem in dasSAP-HANA-System verschoben. Die eigentlichen Datenverschiebungenerfolgen als Exporte und Importe. Bei großen SAP-Business-Suite-Systemenempfiehlt sich eine Aufteilung der sehr großen Tabellen, bevor diese ver-schoben werden. In einigen Fällen sollten Indizes zur Beschleunigung desProzesses hinzugefügt werden. Die Datenexporte und -importe finden nachder Vorverarbeitung in Schritt 4 statt.

Das System muss nun für weitere Datenaktualisierungen gesperrt werden,bis die Daten auf SAP HANA migriert wurden. Hierzu gehören Datenlade-jobs, Finanzzuordnung, Abschreibungen, Benutzereinträge sowie alle Jobs,mit denen Daten im System geändert, aktualisiert oder neu hinzugefügt wer-den. Sobald alle Vorbereitungen getroffen sind, können Sie das System sper-ren und mit dem Transfer beginnen (siehe Abbildung 6.10). Für gewöhnlichbietet sich dazu ein Wochenende an.

Abbildung 6.10 »Database Migration Option« (DMO) – Sperrung des Quellsystems

Nachdem die Daten auf das neue SAP-HANA-System migriert wurden, stehtIhnen ein funktionierendes System zur Verfügung, und die Benutzer könnenauf die neue Umgebung zugreifen. Im Master Guide des SAP Marketplacegibt es Empfehlungen zu den Nachbereitungsschritten. Sie sollten die aktu-elle Version zurate ziehen und prüfen, ob für Ihr System Änderungen not-wendig sind und welche Nachbereitungsschritte optional sind.


212

Hinweis

Weitere Informationen zu DMO finden Sie in den SAP-Hinweisen 1875197 und1813548. Für Basis-Mitarbeiter empfiehlt sich die zweitägige DMO-Schulung mitdem Titel »HA-250: Migration to SAP HANA Using DMO«.

6.3.3 Kopieren, upgraden und migrieren

Wenn Sie keinerlei Risiko eingehen möchten, können Sie SAP Business Suiteauf SAP HANA mit der Option zum Kopieren, Upgraden und Migrierenimplementieren. Bei dieser Option wird das SAP-Business-Suite-System mit-hilfe von herkömmlichen Basis-Werkzeugen auf ein anderes System kopiert.Anschließend wird im neuen SAP-HANA-System für die Kopie ein Upgradedurchgeführt. Dabei werden dieselben Schritte wie in Abschnitt 6.3.2 (unterEinsatz von DMO) ausgeführt. Diese Option erfordert mehr Hardware undSchritte als bei der In-Place-Migration. Allerdings sinkt auch das Projektri-siko. Für Benutzer, die vor einer vollständigen Migration einen »Proof ofConcept« durchführen möchten, ist diese Option auch sehr gut geeignet.

6.3.4 Sizing

Selbstverständlich müssen Sie auch die Größe des Systems anpassen, undzwar unabhängig davon, welche Implementierung von SAP Business Suiteauf SAP HANA Sie auswählen. Hierfür stehen Ihnen drei Optionen zur Ver-fügung: SAP QuickSizer (den Sie bereits aus Abschnitt 6.2.2 kennen und derim Folgenden beschrieben wird), ein ABAP-Bericht und Anbieterwerkzeuge.

SAP QuickSizer

Wenn Sie mit dem Sizing in der SAP-HANA-Umgebung beginnen, sollten Siezuerst die SAP-Richtlinien für das Datenbank-Sizing lesen. Diese finden Siein SAP-Hinweis 1514966. Mit diesem Grundwissen können Sie die erstenSizing-Versuche mithilfe des Werkzeugs SAP HANA QuickSizer unterneh-men. Dieses Werkzeug finden Sie unter http://service.sap.com/quicksizer.

Erstellen Sie zunächst ein Projekt, und geben Sie auf dem Bildschirm in denBereichen Project Data, Customer Data, Platform and Communication,System Availability und Network Infrastructure so viele Informationenwie möglich ein (siehe Abbildung 6.11). Die meisten dieser Daten werdennicht für das Sizing verwendet, stellen aber SAP und Ihrem Hardwarepartnerwertvolle Informationen bereit, wenn Sie die Sizing-Ergebnisse mit diesenteilen.


213

Abbildung 6.11 Erstellen eines SAP-HANA-Sizing-Projekts für SAP Business Suite

In diesem Beispielprojekt planen wir die Implementierung eines neuen SAP-ERP-Financials-Systems mit Financial Accounting und Controlling für dieSAP Business Suite auf SAP HANA. Diese Aktivität unterscheidet sich in SAPQuickSizer nicht von einem Sizing eines herkömmlichen festplattenbasiertenSystems. Erst nachdem das Sizing abgeschlossen wurde, können wir mithilfeder SAP-Richtlinien das Ergebnis des klassischen Sizings auf das identischeSAP-HANA-Sizing übertragen. Daher müssen wir die zu implementierendeKomponente auswählen – in unserem Fall also FI-CO.

Es gibt 940 Benutzer, die nach ihren Aktivitäten in »niedrig«, »mittel« und»hoch« aufgegliedert werden. Wie Sie in der ersten Zeile der geplantenDatenmengen sehen können (Abbildung 6.12), planen wir die Verarbeitungvon durchschnittlich 5 Millionen Rechnungsdokumenten mit durchschnitt-lich zwei Auftragspositionen pro Tag. Von diesen Dokumenten werden plan-mäßig ca. 5 % pro Jahr geändert und 25 % angezeigt.

Insgesamt sollen in unserem System Daten aus 48 Monaten vorgehalten wer-den, und die Archivierung ist deaktiviert. Dies ist die durchschnittliche Nor-mallast zwischen 9:00 und 18:00 Uhr. Darunter ist die Spitzenlast zwischen12:00 und 13:00 Uhr eingetragen (Sie können diese Zeiten entsprechendIhren Spitzenlasten ändern). Zudem geben wir in Table 3 die geschätzteAnzahl an Datensätzen für die Datensatztypen ohne Auftragspositionen ein.Nachdem wir alle Informationen eingegeben haben, klicken wir im oberenBereich des Bildschirms auf die Schaltfläche Calculate result und erhaltendie Sizing-Ergebnisse (siehe Abbildung 6.13).


214

Abbildung 6.12 Eingabe der Sizing-Vorgaben für FI-CO

Abbildung 6.13 Sizing-Ergebnis für FI-CO


215

Aus dem Ergebnis geht hervor, dass es sich um ein sehr großes System mitSystemanforderungen von mindestens 2.080.000 SAPS und über 5 TB Spei-cher handelt. Zur Erinnerung: Dies gilt nur für ein herkömmliches festplat-tenbasiertes System, und die SAP-Richtlinien sind erforderlich, um dies inaussagekräftige und vergleichende SAP-HANA-Systemgrößen umzusetzen.Informationen darüber, wie Sie diesen Sizing-Schätzwert für SAP HANAumwandeln, erhalten Sie im PDF-Anhang von SAP-Hinweis 1779345.

Im Allgemeinen ist es ratsam, das durchsatzbasierte Sizing anstelle einesSizings zu nutzen, das auf der Anzahl der Benutzer beruht. Denn damit kön-nen Sie die Datenhaltungszeiten besser steuern und den benötigten Speicherreduzieren. Selbstverständlich können Sie die Daten auch im Nearline Sto-rage (NLS) vorhalten und auf diese zugreifen, selbst wenn sie nicht physischin SAP HANA gespeichert werden.

ABAP Report

Das Sizing der SAP Business Suite auf SAP HANA mithilfe des SAP-QuickSi-zer-Werkzeugs ist ein sehr guter Ausgangspunkt für eine Neuimplementie-rung. SAP bietet Ihnen aber auch ein auf ABAP basierendes Sizing-Pro-gramm, das für Bestandskunden mit vorhandenem SAP-ERP-Systemeingesetzt werden kann. Dieses Programm erhalten Sie als Anhang zu SAP-Hinweis 1872170 (siehe Abbildung 6.14). Sie können das Werkzeug gemäßden Anweisungen im Hinweis herunterladen und für sehr detaillierte SAP-HANA-Sizing-Schätzungen in Ihrem SAP-Business-Suite-Migrationsprojektnutzen.

Abbildung 6.14 Sizing-Programm für »SAP Business Suite auf SAP HANA« – SAP-Hinweis 1872170


216

Mit diesem Programm wird ein Ergebnisbericht generiert, der Sie genauüber die Speicheranforderungen für Datenbanktabellen informiert (live-Cache wird derzeit noch nicht unterstützt). Das ABAP-Programm ist sogar inder Lage, Ereignisse während der Migration zu prüfen, wie z.B. Depooling,Indizes, Declustering und LOBs (große Objekte). In diesem Werkzeug kön-nen Sie zudem über Filter bestimmte Bereiche für das Sizing auswählen.Somit können Sie spezifische Tabellen für das SAP-HANA-Sizing oder sogareinzelne Module wie Financial Accounting oder Materials Management ineiner Sidecar-Implementierung Ihres SAP-HANA-Systems auswählen.

Wenn Sie das Programm ausführen, wird Ihnen der Fortschritt in einemBildschirm angezeigt. Dies kann einige Zeit in Anspruch nehmen, abhängigdavon, wie viele parallele Dialogprozesse Sie im ersten Eingabebildschirmangegeben haben. Es ist durchaus möglich, dass das Programm in großenSystemen mehr als eine Stunde benötigt. Bei vielen Unternehmen sollte dasProgramm nach Feierabend ausgeführt werden, wenn mehr Ressourcenzugewiesen werden können und die Auswirkungen auf die Benutzer nurminimal sind.

Wie Sie in diesem Beispiel sehen können (Abbildung 6.15), wird die SAPBusiness Suite auf SAP HANA ungefähr 1,96 TB des Speichers benötigen.Diesen Schätzwert können wir den Anbietern vorlegen und Angebote für dieSAP-HANA-Hardware anfordern.

Abbildung 6.15 Ergebnis des SAP-HANA-Sizing-Programms für SAP Business Suite


217

Hinweis

In SAP-Hinweis 1872170 ist auch ein detailliertes PDF-Dokument mit dem Titel»Frequently Asked Questions« enthalten. Es informiert Sie, wie Sie das Programmherunterladen und ausführen und die Ergebnisse auswerten müssen.

Anbieterwerkzeuge

Neben SAP QuickSizer und den ABAP-Sizing-Werkzeugen haben viele Hard-wareanbieter eigene Tabellenkalkulationen zur Berechnung oder Verifizie-rung der Hardware-Sizing-Vorhaben generiert. Einige Unternehmen, wiez.B. HP, haben zudem Softwareprogramme entwickelt, die Unterstützungbei einem SAP-HANA-Sizing-Vorhaben bieten. Das Sizing-Werkzeug von HPkann von der Webseite des Unternehmens heruntergeladen und in wenigenMinuten auf dem Desktop installiert werden.

Der Vorteil vieler dieser Sizing-Werkzeuge ist, dass sie häufig Preislisten fürdie Hardware bereitstellen, die der Anbieter für Ihre Sizing-Anforderungenvorschlagen könnte. In unserem Sizing-Beispiel, bei dem das Sizing-Werk-zeug von HP zum Einsatz kommt, wird die Entwicklungs- und Sandboxum-gebung zur Kostenersparnis auf derselben Hardware positioniert (sieheAbbildung 6.16).

Abbildung 6.16 HP-Sizing-Werkzeug für »SAP Business Suite auf SAP HANA«

Die Qualitäts- und Testumgebung sowie die Produktivumgebung werdenseparat gehalten. Die drei Umgebungen werden in Abbildung 6.16 darge-


218

stellt. Das Sizing-Werkzeug von HP gibt an, dass im Produktivsystem dieAnforderungen mit einem einzigen SAP-HANA-System mit 1 TB Speichererfüllt werden können, wobei der interne Festplattenplatz 7 TB beträgt. Wei-terhin empfiehlt das Werkzeug zwei SAP-HANA-Systeme mit 256 GB Spei-cher und 3 TB Festplattenplatz für die anderen Umgebungen. Der Listen-preis für solch eine Konfiguration läge bei insgesamt 270.892 USD vorDienstleistungen, Steuer und Rabatten.

Andere Sizing-Werkzeuge und Tabellenkalkulationen von Unternehmen wieFujitsu, IBM, Dell, Huawei, NEC, Hitachi und Cisco/EMC sind auf Anfrageerhältlich.

6.4 SAP Business Warehouse auf SAP HANA

SAP BW auf SAP HANA ist bis heute die gängigste Form einer SAP-HANA-Implementierung, weil SAP BW die erste für SAP HANA zur Verfügung ste-hende Anwendung war und SAP BW gleichzeitig das am häufigsten ver-wendete Berichtssystem für SAP-Kunden ist. Trotz seines Status als meist-verwendetes Berichtssystem wurde SAP BW mit signifikanten Problemenkonfrontiert und stieß an die Grenzen seiner Leistungsfähigkeit, da sich dieDatenvolumen der meisten Unternehmen stetig vermehrten und zig Tera-byte groß wurden. Herkömmliche relationale Systeme auf Festplattenbasiskonnten mit den erforderlichen Datenlesevorgängen und Tabelleneinfü-gungen nicht Schritt halten.

Release 7.4

Auf SAP HANA können Sie Ihre älteren SAP-BW-Systeme auf SAP BW Version 7.3aktualisieren. Um jedoch die Geschwindigkeit und die Funktionen von SAP HANAvoll nutzen zu können, sollten Sie SAP BW 7.4 einsetzen. Diese Version wurde sogeschrieben und umgestaltet, dass alle neuen Funktionen von SAP HANA in einemeinheitlichen, flexiblen und leistungssteigernden Data Warehouse für Unterneh-men des 21. Jahrhunderts bereitgestellt werden. SAP hat z.B. einige Bereiche desstandardmäßigen Business Content in Content Release 7.47 SP 7 neu geschrieben,um das Laden der Daten und die Datenarchitektur zu vereinfachen und flexibleDatenmodelle zu erzeugen. Der neue, für SAP HANA optimierte Inhalt umfasstBereiche wie Debitoren- und Kreditorenbuchhaltung, Produktkostenprognoseund -simulationen, Profit-Center-Rechnung, Hauptbuch, Vertriebsübersicht, Lie-ferservices, Fakturakonditionen, Auftragsrückstände, Einkaufsübersicht, Rech-nungswesen im Einkauf, Vertragsmanagement, Rechnungsprüfung und Service-Levels. Neue Inhalte für andere Bereiche können in nachfolgenden Releases hinzu-gefügt werden.

SAP Business Warehouse auf SAP HANA 6.4

219

In den folgenden Abschnitten nennen wir Ihnen einige zentrale Aspekte, dieSie bei der Umstellung eines SAP-BW-Systems auf SAP HANA berücksichti-gen sollten. Wir organisieren die Abschnitte in verschiedene Hauptschritte:Sizing, Vorbereitung für eine Migration, Durchführung einer Migration undOptimierung einer Migration. Abschließend präsentieren wir einige neueFunktionen in SAP BW 7.4, die besonders relevant für die Migration vonSAP BW auf SAP HANA sind.

6.4.1 Sizing

Es gibt zwei Optionen für das Sizing eines SAP-BW-Systems auf SAP HANA:SAP QuickSizer (der bereits für das Sizing von SAP HANA als Data Warehouseund SAP Business Suite auf SAP HANA erörtert wurde) und das SAP BWMigration Cockpit für SAP HANA. Im Folgenden werden beide Möglichkeitenbeschrieben.

Sizing von SAP BW mit dem SAP-QuickSizer-Werkzeug

Das erste Sizing-Werkzeug von SAP ist QuickSizer (siehe Abbildung 6.17). Ereignet sich für Unternehmen, die noch kein SAP-ERP- bzw. SAP-BW-Systemeinsetzen oder SAP Rapid Deployment Solutions für SAP HANA nutzenmöchten und deshalb eine brandneue Implementierung planen. QuickSizerist nicht für Unternehmen vorgesehen, die bereits eine SAP-ERP- oder SAP-BW-Lösung einsetzen. Diese Kunden sollten stattdessen die von SAP undanderen Anbietern bereitgestellten Werkzeuge verwenden, die in diesemKapitel vorgestellt wurden.

Die Speicheranforderungen von SAP HANA für SAP-BW-Caches und zusätz-liche Komponenten sind auf ca. 50 GB festgelegt. (Der Rest wird anhand derGröße der spalten- und zeilenbasierten Speicher gesteuert.) Der erste Schrittfür die Anwendung von QuickSizer besteht in der Eingabe der Projektinfor-mationen: Betriebssystem, Hardware und Datenbank. Danach öffnen Sie dieQuickSizer-Menüs.

Im Bereich Table 1 geben Sie die Planungsinformationen ein (wenn Sie Inte-grated Planning [IP] in SAP BW verwenden). Die mit einem roten Sternchenmarkierten Felder sind Pflichtfelder. Für H-PLANN-1 geben Sie im FeldUsers die maximale Anzahl gleichzeitiger Benutzer ein. Die Felder S.t. undE.t. beziehen sich auf die Start- und Endzeiten für die Verarbeitung. DurchEingabe dieser Informationen erhalten Sie am Ende des Sizings zusätzlicheine Schätzung der Lastverteilung auf dem SAP-HANA-System nach Zeitperi-oden.


220

Abbildung 6.17 SAP QuickSizer für SAP BW auf neuen SAP-HANA-Implementierungen

Geben Sie in Table 2 die voraussichtliche Anzahl von Informationsverbrau-chern (H-BW-INFO), Anwendern (H-BW-BUSI.) und Experten (H-BW-

EXPER) ein. SAP empfiehlt ein Verhältnis von 71 %, 26 % bzw. 3 % für jedeBenutzergruppe. Sie können aber auch Ihre eigenen Berechnungen einge-ben, falls Sie bessere Schätzungen ermittelt haben. Es sollte auf jeden Falldarauf geachtet werden, dass sich die Anzahl von SAP-BW-Nutzern aufgleichzeitige Anwender (und nicht auf festgelegte Anwender) bezieht. Fürdiesen Zweck erhalten Sie sehr gute Schätzungen aus Ihrem EarlyWatch-Bericht im SAP Solution Manager. Ihr Basis-Team sollte in der Lage sein,Ihnen genauere Auskünfte darüber zu geben.

Geben Sie den geschätzten Verteilungsprozentsatz der Benutzer in den Spal-ten Report., OLAP und Explor. ein. In diesem Beispiel haben wir geschätzt,dass von den 438 Informationsverbrauchern 33 % statische vorformatierteBerichte verbrauchen, 56 % OLAP-Werkzeuge, wie z.B. SAP BEx Web Analy-zer oder SAP BusinessObjects Analysis, verwenden und die restlichen 11 %Daten untersuchen und eine große Menge an Navigationsaktivitäten aufwei-sen werden. Diese Schätzungen helfen SAP QuickSizer dabei, die Größe deserforderlichen Speichers zu berechnen.


221

In Table 3 schätzen Sie, wie viele Datensätze periodisch in SAP BW geladenwerden. In diesem Beispiel gehen wir davon aus, dass 279.994.355 Daten-sätze täglich zwischen 12:00 und 01:00 Uhr geladen werden.

In Table 4 schätzen Sie einen Speicherplatzbedarf von 2,9 TB im Spaltenda-tenspeicher und einen Speicherplatzbedarf von 500 GB im Zeilendatenspei-cher in SAP HANA. Diese Sizing-Zahl ist datenbankspezifisch, und SAP bieteteinige Programme, die bei der Berechnung realistischer Schätzungen hilf-reich sein können. Im SAP-Hinweis 1637145 finden Sie Programme, die aufSAP BW laufen und bei der Ermittlung realistischer Sizing-Zahlen helfen. DasShell-Skript für jeden Datenbanktyp befindet sich in der Datei get_size.zip,die extrahiert und zusammen mit der Datei load_RowStore_List.sql ausgeführtwerden sollte, um die Größe in Table 4 eingeben zu können. Die einzigeAusnahme stellt die IBM-DB2-Datenbank auf z/OS dar. Für letztere Kombi-nation steht stattdessen ein ABAP-Programm zur Verfügung (siehe SAP-Hin-weis 1736976). Wir sollten ebenfalls erwähnen, dass ausschließlich für DB2die Eigenkomprimierung der Datenbank in der Schätzung des Umfangs ent-halten ist. Bei anderen Datenbanken mit eingeschalteten Komprimierungen(z.B. Oracle) muss die Sizing-Zahl entsprechend angepasst werden. Wirmöchten ebenso darauf hinweisen, dass dieses Programm davon ausgeht,dass Ihr SAP-BW-System Unicode-fähig ist. Sollte dies nicht der Fall sein, istes ratsam, zusätzliche 10 % zu Ihrer Sizing-Ausgabe hinzufügen.

Obwohl tatsächliche Komprimierungsverhältnisse und Beispiele von SAP aufrealen Kundenszenarien beruhen, schätzen wir in diesem Beispiel die Kom-primierungsrate auf 1:5. Dieses Komprimierungsverhältnis wird wahr-scheinlich für Ihr eigentliches System höher oder niedriger sein. Eine fünffa-che Komprimierungsberechnung wird jedoch gewährleisten, dass wir unsereHardware nicht wesentlich unterdimensionieren.

Jetzt haben Sie die Voraussetzungen dafür geschaffen, die Informationen deseigentlichen SAP-BW-Systems hinzuzufügen. Der größte Teil der erforderli-chen Informationen für Table 5 und Table 6 (siehe Abbildung 6.18) steht inder Administrator Workbench (Transaktion RSA1) in SAP BW zur Verfügung(siehe Berichte wie SAP_ANALYZE_ALL_INFOCUBES, ANALYZE_RSZ_TABLES undSAP_INFOCUBE_DESIGNS, die jeweils auch Informationen für die einzelnenInfoProvider bereitstellen).

Geben Sie in Table 5 die InfoCube-Informationen ein. Sie können maximaleine Anzahl von 13 Dimensionen (in das Feld Dim.) eingeben. Die drei fest-gelegten Dimensionen eines InfoCubes sind bereits enthalten. Geben Siealso nur die freien Dimensionen ein. Das Feld KeyF. bezieht sich auf die


222

Anzahl der Kennzahlen in der Faktentabelle Ihres InfoCubes, und das FeldCom. stellt die geschätzte Komprimierung dar. Wenn Sie über keine besse-ren Schätzungen verfügen, kann ein Verhältnis von 1:5 für ein anfänglichesSizing dienen, bevor Sie die Schätzung mit Ihrem Hardwareanbieter genauerfestlegen.

Abbildung 6.18 QuickSizer für SAP BW auf SAP HANA: BW-Daten

Geben Sie im Feld Initial load die Anzahl der Datensätze im bestehendenInfoCube ein, und im Feld Period. Upld geben Sie die Anzahl der Datensätzeein, die schätzungsweise periodisch geladen werden. Die Informationen zudieser Datensatzzahl stehen in vielfältiger Weise in SAP BW zur Verfügung.Sie können diese Informationen finden, indem Sie in Transaktion RSA1 zujedem InfoCube gehen und anschließend auf der Registerkarte Content miteinem Rechtsklick Manage auswählen. Hier wählen Sie Number of Entries,um die Anzahl der Datensätze aus der Faktentabelle anzuzeigen. Das Pro-gramm ANALYZE_RSZ_TABLES wird alle Einträge auch in der Dimensionsta-belle erfassen. Diese Zahlen können für die anfängliche Schätzung derDatenladungen verwendet werden. Zum Schätzen der Uploads können Sieanhand der Datenpakete abschätzen, wie viele Datensätze täglich geladenwerden. Da diese einen wesentlichen Teil des SAP-HANA-Umfangs ausma-chen, ist es wichtig, genug Zeit für die sorgfältige Ermittlung dieser Zahlenaufzuwenden.


223

Bei der letzten Position in Table 5 müssen Sie schätzen, wie viele Datenla-dungen in SAP BW erhalten bzw. behalten werden. In diesem Beispiel schät-zen wir tägliche Ladungen für die meisten InfoCubes und beabsichtigen,Daten von einem Zeitraum von zwei Jahren zu behalten. Dies würde 2 × 365= 730 bedeuten. Wir haben jedoch planmäßige Ausfallzeiten für Upgrades,Patches und geplante Services für nächstes Jahr mit einkalkuliert, sodass dieZahl etwas niedriger ausfallen wird. Da der letzte InfoCube in der Schätzungperiodisch geladen wird, planen wir für diesen nur 208 Perioden ein.

In Table 6 werden die Schätzungen für die DataStores (DSOs) hinzugefügt.Die Logik ist derjenigen, die in Table 5 angewendet wurde, sehr ähnlich. DieFelder NumF., TxtFlds und CharL. beziehen sich jedoch auf die Anzahl dernumerischen Felder im DSO, die Anzahl an Textfeldern bzw. auf die durch-schnittliche Länge der Zeichenfelder. Dies lässt sich nur schwer einschätzenund erfordert von Ihrem SAP-BW-Team gute Designinformationen.

Das Kennzeichen WO ist nicht erforderlich, aber es identifiziert, ob das DSOschreiboptimiert ist und somit nicht so viele Log-Dateieinträge aufweist wieein reguläres DSO. Die restlichen Felder verhalten sich genauso wie für dieInfoCubes in Table 5.

Nachdem Sie die Einträge vollständig abgeschlossen haben, werden Sie vonSAP QuickSizer eine recht gute Erstschätzung der erforderlichen Komponen-ten erhalten. In Abbildung 6.19 sehen Sie ein Beispiel für die Resultate.

Abbildung 6.19 Die SAP-QuickSizer-Ergebnisse

Wie Sie sehen, setzt dieses Beispiel eines SAP-HANA-Sizings einen Speichervon 1,6 TB voraus. Da Sie diese Kapazität kaum mit einem einzigen Server-knoten erreichen können, sollten Sie ein Multiknotensystem verwenden. In


224

einem solchen Fall wird SAP BW auf SAP HANA die Stammdaten, ABAP-Sys-temtabellen und die Daten der zeilenbasierten Speicher im Master-Knoteneinsetzen. Die anderen verbundenen Serverknoten werden die PersistentStaging Area (PSA), InfoCubes und DSOs enthalten.

Wenn viele Knoten hinzugefügt werden, findet mehr Verarbeitung im Mas-ter-Knoten statt (wie z.B. Stammdatenzugriffe). Aus diesem Grund solltenSie in Abstimmung mit Ihrem Hardwareanbieter den Speicher des Master-Knotens größer bemessen, als von SAP QuickSizer geschätzt wird. Mit diesenInformationen ausgestattet, können Sie Ihren Hardwarepartner um Ange-bote und Kostenvoranschläge bitten.

SAP-BW-Sizing mit dem SAP BW Migration Cockpit für SAP HANA

Kunden, die bereits über ein SAP-BW-System verfügen, haben bessere Alter-nativen zum Bereitstellen detaillierter Sizing-Ergebnisse. Im SAP BW Migra-tion Cockpit für SAP HANA steht Ihnen ein Werkzeug zur Verfügung, mitdem das aktuelle Betriebssystem und die Komprimierungsraten der Quellda-tenbank berücksichtigt werden. Das Werkzeug plant zudem ein, dass in SAPBW 7.4 unnötige Daten, wie z.B. die Tabellen der Persistent Staging Area(PSA), aus dem Speicher auf Datenträger ausgelagert werden, wenn diesenicht benötigt werden (siehe Abbildung 6.20).

Abbildung 6.20 Sizing von SAP BW auf SAP HANA mit dem »SAP BW Migration Cockpit für SAP HANA«

Wird dieses Programm in einem Produktivsystem ausgeführt, erhalten Siesehr genaue Sizing-Informationen. Darin eingeschlossen ist das Sizing für


225

RAM sowie für den dynamischen Laufzeitspeicher, Log-Speicher und Fest-plattenspeicher. Es liefert sogar Einzelheiten zu Datengrößen mit entspre-chendem dynamischen Laufzeitspeicher für zeilen- und spaltenbasierte Spei-cher sowie die berechnete und geschätzte Größe im SAP-HANA-Speicher.

Je präziser die Genauigkeit der durchgeführten Schätzung ist (die, wie inAbbildung 6.21 dargestellt, anhand von Optionsfeldern ausgewählt werdenkann), desto länger wird das Programm laufen. Bei 12 parallel laufenden Pro-zessoren und einem 9-TB-Datenlager ist eine Laufzeit von 30 bis 70 Minutennicht unüblich. Um die Geschwindigkeit des Prozesses zu erhöhen, könnenSie Analysetabellen unterdrücken, die kleiner als 1 MB sind.

Abbildung 6.21 Eingabeparameter für das Sizing von SAP BW auf SAP HANA

Da Ausfallzeiten beim Ausführen dieses Sizing-Programms durchaus vor-kommen können, sollten Sie zusätzlich den Parameter in rdisp/max_wprun_time in 0 ändern. Das können Sie in SAP BW mit der Transaktion RZ11durchführen. Abschließend schätzen Sie das Wachstum des Systems in


226

einem bestimmten Zeitraum als Prozentsatz oder als absolutes Wachstum inGigabyte. Abbildung 6.22 zeigt ein Beispiel für die Ergebnisse eines Sizings.

Abbildung 6.22 Ergebnisse für das Sizing von SAP BW auf SAP HANA

Die Ausgabe wird in der von Ihnen zuvor bestimmten Datei gespeichert, dieSie nun Ihren Hardwareanbietern für Sizing-Vorgaben und Hardwareaus-wahl per E-Mail zukommen lassen können. Weitere Informationen zumSizing finden Sie in den folgenden SAP-Hinweisen:

� SAP-Hinweis 1514966: Sizing SAP HANA Database

� SAP-Hinweis 1637145: SAP BW on HANA: Sizing SAP HANA Database


227

Bevor Sie Ihre Hardware bestellen oder Ihre Budgets festsetzen, empfehlenwir Ihnen, dass Sie Ihre Planungen mit Ihrem bevorzugten Anbieter erarbei-ten bzw. besprechen.

6.4.2 Vorbereiten einer Migration

Zur Vorbereitung einer Migration von SAP BW auf SAP HANA sind einigeSchritte notwendig. Diese werden im Folgenden erläutert.

Housekeeping im SAP-BW-System

SAP BW ist ein komplexes System mit vielen Redundanzen und kopiertenDaten in der Datenbank, die bereinigt werden können. Das betrifft Log-Dateien, Ergebnistabellen, das temporäre Staging von Daten und den Zwi-schenspeicher von Daten, in dem sich die Daten befinden, bevor sie inübergeordnete Datenmodelle geschoben werden. Sie können sich eine be-trächtliche Menge an Arbeit sparen, wenn Sie noch vor einer SAP-HANA-Migration oder einem SAP-BW-Upgrade-Projekt eine Bereinigung durch-führen.

Durch eine solche Bereinigung kann die Größe eines SAP-BW-Systems um20 bis 30 % reduziert werden. So konnte beispielsweise das SAP-BW-Systemeines großen Öl- und Gasunternehmens von 108 TB auf unter 36 TB redu-ziert werden, indem vor der SAP-HANA-Migration mehr Daten in den Near-line Storage (NLS) geschoben wurden. Dadurch konnte das UnternehmenMillionen von US-Dollar an Hardware- und Lizenzkosten sparen.

Da SAP HANA viele der Systemtabellen und Stammdaten (zeilenbasierteSpeichertabellen) auf dem Master-Knoten speichert, sollten diese Tabellen soklein wie möglich gehalten werden, um genügend Platz auf diesem Knotenzu schaffen. Die wichtigsten Punkte, auf die dabei geachtet werden sollte,sind die folgenden:

� Bereinigen Sie die PSA von Daten, die bereits auf DSOs geladen wurden.

� Löschen Sie die Aggregate (Ergebnistabellen), da sie nicht mehr gebrauchtwerden.

� Komprimieren Sie die E- und F-Tabellen in allen InfoCubes, um InfoCubeswesentlich zu verkleinern.

� Entfernen Sie Daten aus statistischen Cubes (diese beginnen mit dem tech-nischen Namen 0CTC_xxx). Sie enthalten Leistungsangaben für das auf derrelationalen Datenbank betriebene SAP BW. Das Löschen dieser Daten


228

kann mithilfe der Transaktion RSDDSTAT oder des Programms RSDDSTAT_DATA_DELETE durchgeführt werden.

� Achten Sie auf Log-Dateien, Lesezeichen und nicht verwendete Abfragenund Vorlagen des SAP Business Explorers (BEx) (Transaktion RSZDELETE).

� Entfernen Sie so viel wie möglich aus dem Zwischenspeicher, den DTP-Fehlerprotokollen und den temporären Datenbankobjekten des Daten-transferprozesses (DTP). Hilfe und Programme zu diesem Thema findenSie in den SAP-Hinweisen 1139396 und 1106393.

� Für schreiboptimierte DSOs, die Daten in meldepflichtige DSOs schieben(LSA++-Ansatz), entfernen Sie die Daten in den schreiboptimierten DSOs.Diese stehen bereits in übergeordneten Objekten zur Verfügung.

� Migrieren Sie alte Daten zu NLS auf einem kleinen Server. Der unregelmä-ßige Zugriff auf diese alten Daten durch einige Benutzer wird weiterhinmöglich sein. Abfragen auf diese Daten können auch weiterhin durchge-führt werden, wenn SAP BW auf SAP HANA liegt, auch wenn In-Memorynicht erforderlich ist.

� Entfernen Sie Daten in nicht verwendeten DSOs, InfoCubes und Dateien,die im SAP-BW-System für das Staging verwendet werden. Dies schließteine mögliche Restrukturierung von Stammdatentext und Attributen mit-hilfe von Prozesstypen in der Transaktion RSPC mit ein.

Sie sollten eventuell auch in der Tabelle RSBATCHDATA gespeicherte Hinter-grundinformationen bereinigen. Diese Tabelle kann sehr groß werden,wenn sie nicht gepflegt und verwaltet wird. Sie sollten außerdem in Erwä-gung ziehen, alle IDocs zu archivieren und die tRFC-Queues zu bereinigen.All diese Schritte werden die Größe des SAP-HANA-Systems reduzieren undSie dabei unterstützen, genügend Platz für die Systemtabellen auf dem Mas-ter-Knoten zu schaffen.

Des Weiteren bietet Ihnen SAP im SAP-Hinweis 706478 einige Vor-schläge, wie Sie in Zukunft ein zu schnelles Wachsen der Basis-Tabellenverhindern können. Falls Sie SAP BW 7.0 SP 23 oder höher verwenden,können Sie unerwünschte Stammdaten auch direkt löschen (siehe SAP-Hinweis 1370848).

Abschließend können Sie das Programm RSDDCVER_DIM_UNUSED anwenden,um alle unbenutzten Dimensionseinträge in Ihren InfoCubes zu löschen undsomit die allgemeine Systemgröße zu verringern.

Sie können diese Aufgaben manuell ausführen. Allerdings bietet SAP hierfürauch einige Bereinigungsprogramme an. Wenn Sie SAP BW 7.0 SP 32 oder


229

höher verwenden, können Sie eine Housekeeping-Aufgabenliste erstellenund automatisch Hilfe beim Bereinigen des Systems erhalten (siehe Abbil-dung 6.23). Sie müssen das Programm aus SAP-Hinweis 1829728 zuerstinstallieren, bevor Sie die Aufgabenliste SAP_BW_HOUSEKEEPING mithilfe vonTransaktion STC01 generieren können.

Abbildung 6.23 Die SAP-BW-Housekeeping-Aufgabenliste für die Systembereinigung

SAP bietet auch eine Bereinigungsliste und automatischen Support im SAPBW Migration Cockpit für SAP HANA 3.0 (siehe Abbildung 6.24). Dieseswichtige Cockpit-Werkzeug sollten Sie vor, während und nach der Migrationvon SAP BW auf SAP HANA nutzen. Es bietet Ihnen eine klare Übersichtüber alle wichtigen Aufgaben, die Sie im Rahmen einer Migration von SAPBW auf SAP HANA durchführen müssen.

Abbildung 6.24 »SAP BW Migration Cockpit für SAP HANA«-Housekeeping-Aufgaben


230

Prüfungen vor einer Migration von SAP BW auf SAP HANA

Nachdem Ihr System nun bereinigt wurde, müssen Sie sich darauf vorberei-ten, das System auf SAP HANA zu migrieren. Die Voraussetzungen hierfürsind, dass Sie mindestens über SAP BW Version 7.3 verfügen, dass Unicodeimplementiert ist und die Sicherheitsumstellung für das SAP-BW-7.0-Systemabgeschlossen ist. Diese Schritte wurden von vielen Unternehmen nicht alsTeil ihres früheren SAP-BW-Upgrades mit durchgeführt.

Wir empfehlen Ihnen, Migrationen von SAP BW auf SAP HANA mit SAP BW7.4 durchzuführen. Aus diesem Grund beginnen viele Migrationsprojektevon SAP BW 7.0 und 3.5 auf SAP HANA zuerst mit einem kurzen techni-schen SAP-BW-Upgrade. Sie können die Unicode- und Sicherheitsumstellungdirekt in Ihrem SAP-BW-7.0-System vornehmen und anschließend zu SAPBW 7.4 übergehen. Diese Aufgaben erledigen Sie am einfachsten mit demDMO-Werkzeug (Database Migration Option). Hiermit lassen sich alle zuvorgenannten Aufgaben in einem einzigen Schritt im Rahmen der Migrationvon SAP BW auf SAP HANA durchführen.

Zur Planung der DMO-Schritte im SAP Software Update Manager (SUM) stelltSAP ein Checklisten-Werkzeug im SAP BW Migration Cockpit für SAP HANA3.0 bereit. Mit diesen Checklisten werden automatische Prüfprogramme fürdie SAP-BW-Versionen 3.5 und 7.x zur Verfügung gestellt. Das Cockpit-Werkzeug erhalten Sie als Anhang zu SAP-Hinweis 1729988 (siehe Abbil-dung 6.25).

In der Version 3.x dieses Werkzeugs werden Hunderte von Prüfungen auto-matisch im SAP-BW-System durchgeführt, einschließlich Plattform-Checksder Datenbank-, Anwendungs- und Systeminformationen. Basis-Prüfungensind ebenfalls für Support Packs, ABAP/Java Stacks, Unicode, SAP-BW-Relea-ses und Add-ons zu Ihrem System enthalten.

Die Idee hinter dem Checklisten-Werkzeug von SAP BW Migration Cockpitfür SAP HANA ist, dass es während des laufenden Projekts mehrmals ausge-führt wird: Einmal, bevor Sie beginnen, dann regelmäßig, während Sie Pro-bleme und Upgrade-Anforderungen lösen, und abschließend, nachdem dasSystem auf SAP HANA migriert wurde. Der letzte Schritt ist äußerst wichtig,weil das Checklisten-Werkzeug auch über spezifische Prüfungen für das SAP-HANA-System verfügt und Ihnen somit helfen kann, sämtliche Probleme zuidentifizieren, bevor Sie das System an Endanwender übergeben. Wenn dasWerkzeug ein rotes Kennzeichen anzeigt, sollten Sie dieses Problem lösen,bevor Sie mit der SAP-HANA-Migration beginnen. Wenn ein neues rotes


231

Kennzeichen auftaucht, reparieren Sie den Fehler, bevor Sie mit der Migra-tion fortfahren und diese abschließen.

Abbildung 6.25 SAP BW Migration Cockpit für SAP HANA 3.0: Checkliste

Bei einem Upgrade von SAP BW auf eine höhere Version bietet SAP aucheine Aufgabenliste, die Sie vor dem eigentlichen Upgrade in der DMOdurchführen können (siehe Abbildung 6.26). Wenn Sie Version 7.0 SP 31oder höher nutzen, können Sie selbst eine Liste mit Aufgaben erstellen, dievor dem Upgrade erforderlich sind, und Unterstützung bei der Vorbereitungdes Systems erhalten. Je mehr Aufgaben Sie erledigen, desto schneller wirddas Upgrade sein, da Sie die Größe und Komplexität des Systems bereits vor-her reduzieren.

Um Zugriff auf diese Aufgabenliste zu erhalten, müssen Sie das Programmaus SAP-Hinweis 1734333 installieren und die Aufgabenliste SAP_BW_BE-FORE_UPGRADE mithilfe von Transaktion STC01 erzeugen.

Viele der Aufgaben aus diesen drei Werkzeugen überlappen sich teilweise,und einige sind nicht notwendig. Sie bieten jedoch eine sinnvolle Anleitung,wie Sie Ihr System vor dem SAP-BW-Upgrade und der SAP-HANA-Migrationbestmöglich bereinigen und dessen Größe reduzieren können.


232

Abbildung 6.26 SAP BW vor der Upgrade-Aufgabenliste

6.4.3 Durchführen der Migration

In Kapitel 2, »SAP-HANA-On-Premise-Implementierungsoptionen«, habenwir Ihnen die drei Optionen für die Implementierung eines SAP-BW-Sys-tems auf dem SAP-HANA-System vorgestellt:

� Migrieren Sie Ihr gesamtes SAP-BW-System auf SAP HANA.

� Richten Sie ein neues SAP-BW-System ein (mit einer SAP-HANA-Daten-bank), das parallel zum vorhandenen SAP-BW-System bereitgestellt wird,und setzen Sie die neue SAP-BW-Umgebung für besonders komplexeoder neue Anforderungen ein. Dies wird als Side-by-Side- oder Sidecar-Installation bezeichnet und erfordert oft eine partielle Migration der SAP-BW-Transaktionsdaten sowie eine vollständige Replikation der meistenStammdaten.

� Implementieren Sie ein neues SAP-BW-System, und führen Sie es vollstän-dig auf SAP HANA aus.

Die ersten beiden dieser drei Optionen beinhalten eine Migration. In derersten Option, der Standardmigration, migrieren Sie Ihr gesamtes SAP-BW-System nach SAP HANA. In der zweiten Option, der partiellen Migration,installieren Sie eine zusätzliche Instanz von SAP BW und migrieren anschlie-ßend einen Teil Ihrer Transaktionsdaten in das neue SAP-BW-System, aufdem Sie dann SAP HANA betreiben.

Jede dieser Optionen hat ihre eigenen Vorteile und Einschränkungen. Siesollten daher frühzeitig entscheiden, wie viel Risiko Sie auf sich nehmen


233

möchten, welche Prüfungen dafür erforderlich sind, wie viel Nichtverfügbar-keit des SAP-BW-Systems für Sie akzeptabel ist und welche Ressourcen Siefür das Migrationsprojekt verpflichten können. Wir werden als Nächstes diebeiden erstgenannten Optionen ausführlicher erörtern.

Standardmigration

Mit diesem Ansatz behandeln Sie Ihre SAP-BW-Umstellung auf SAP HANAals Datenbank-Migrationsprojekt. Sie beginnen mit dem SAP-BW-System,führen die zuvor erläuterte Bereinigung und die erforderlichen Vorbereitun-gen durch und migrieren die Datenbank auf SAP HANA, belassen aber dieAnwendungslogik und die Datenmodelle wie gehabt.

In diesem Szenario können Sie erneut das DMO-Werkzeug anwenden (sieheAbschnitt 6.3.2). DMO ist eine wichtige Option im Software Update Mana-ger (SUM) für Kunden mit veralteten SAP-BW-Systemen, die auf SAP HANAmigrieren möchten. Sie können das DMO-Werkzeug nutzen, wenn Sie min-destens SAP BW Version 7.0 mit Service Pack 17 (siehe SAP-Hinweis1799545 und Abbildung 6.27) installiert haben.

Abbildung 6.27 »Database Migration Option« für SAP BW auf SAP HANA

Die beste Herangehensweise bei der Datenbankmigration mit dem DMO ist,mit einem Sandbox-System zu beginnen und ein sogenanntes Runbook zuerstellen, in dem Listen mit Schrittanleitungen zu Problemen und Software-aufgaben geführt werden. Es ist durchaus üblich, dass nach der ersten Migra-tion ein Word-Dokument mit 90 bis 100 Seiten zur Verfügung steht, das


234

Screenshots und Dokumentation enthält. Dieses Runbook ist der Schlüsselzum Erfolg. Sie sollten darauf aufbauen, wenn Sie auf das Entwicklungs- undanschließend auf das QA- und Produktivsystem migrieren.

Wenn Sie mit einem SAP-BW-System arbeiten, das nicht stark genutzt wirdoder eine hohe Verarbeitungskapazität besitzt, können Sie die Ausfallzeitminimieren, indem Sie das Schattensystem während des Upgrades ausgiebignutzen. Bei Einsatz eines Schattensystems wird das System und nicht dieDaten kopiert. Viele der Upgrade-Aufgaben erfolgen im Schattensystem,während das eigentliche System weiter ausgeführt wird. Das System ist erstin den späteren Schritten nicht für die Benutzer verfügbar, wenn die Konfi-guration und Daten auf SAP HANA verschoben werden. So wird die Ausfall-zeit des Systems auf ein Minimum reduziert.

Durch Auswahl der Standardoption oder der erweiterten Option in Abbil-dung 6.28 können Sie die Ausfallzeit für Ihre Migration reduzieren, da dasUpgrade in der Schatteninstanz stattfindet und das System erst ausfällt, wenndie Daten exportiert und in die SAP-HANA-Instanz importiert werden.

Abbildung 6.28 Minimieren des Systemausfalls für SAP BW über DMO

Partielle Migration

Viele Unternehmen haben sich dafür entschieden, die Migration von SAPBW auf SAP HANA mithilfe des Sidecar-Ansatzes durchzuführen. Dazu ge-hört die Installation eines neuen SAP-BW-Systems auf SAP HANA, das paral-lel zum aktuellen SAP-BW-System auf einer relationalen Datenbank betrie-ben wird. Anschließend werden InfoCubes und DSOs in wichtige Bereicheder SAP-HANA-Box transportiert, und die Datenladungen werden auf dasneue System als Teil kleinerer Projekte transferiert (für Transporte zwischenverschiedenen Softwarereleases siehe SAP-Hinweis 1090842). Unterdessenwerden andere InfoCubes und DSOs auf dem alten SAP-BW-RDBS-Systemeingesetzt. Im Grunde genommen betreiben Sie zwei SAP-BW-RDBS-Sys-teme gleichzeitig, ohne dass die Ladungen für InfoProvider in beiden Syste-men dupliziert werden.

Obwohl dieser Ansatz kostspieliger ist, ermöglicht er Ihnen jedoch, Ihr Alt-system zu behalten und somit die Risiken einer SAP-HANA-Migration mini-mal zu halten. Die Nichtverfügbarkeit des Systems kann ebenfalls minimal


235

gehalten werden, da an einem Wochenende ein Funktionsbereich nach demanderen bearbeitet werden kann. Des Weiteren wird es Unternehmenermöglicht, schlecht gestaltete SAP-BW-Systeme mit vielen kundenspezifi-schen Codes, standardabweichenden Objekten und Workarounds, die dieAbfrageleistung verbessern sollen, neu zu implementieren. Viele dieser älte-ren Customizations werden eventuell nach einer Umstellung auf SAP HANAnicht mehr benötigt. Die Migration der InfoProvider kann ebenfalls übereinen längeren Zeitraum hinweg stattfinden.

Der Trick, um diesen Ansatz erfolgreich durchzuziehen, besteht jedoch inder Stilllegung der InfoProvider im Altsystem während des Wechsels zu SAPHANA. Das Laden in beide Systeme ist eine komplexe Angelegenheit undkönnte Stress für das SAP-ERP-System verursachen. Zum Beispiel könnte eserforderlich sein, Stammdaten während der Migrationsphase sowohl imSAP-BW-Altsystem als auch im neuen SAP BW, das auf das SAP-HANA-Sys-tem aufsetzt, zu duplizieren. Folglich sollten Sie diese Jobs stoppen und The-menbereiche mit gemeinsamen Stammdaten so bald wie möglich migrieren.Für weitere Informationen über das Laden von SAP-ERP-Daten auf zwei odermehr SAP-BW-Systeme empfehlen wir Ihnen die SAP-Hinweise 775568 und844222.

Migrieren einer Kopie von SAP BW auf SAP HANA

Sowohl bei einer Standardmigration als auch bei einer partiellen Migration könnenSie zunächst auch nur eine Kopie von SAP BW auf SAP HANA migrieren. DieserAnsatz ist bei Unternehmen mit einer sehr geringen Risikotoleranz beliebt, diezudem sehr viel Zeit für die Migration von SAP BW auf SAP HANA zur Verfügunghaben. In diesem Fall wird ein SAP-BW-System zunächst kopiert, dann werden dieSAP-Hinweise und SAP-BW-Upgrades übernommen, die auf der kopierten Versiondes SAP-BW-Produktionssystems benötigt werden, und abschließend werden dieFunktionen des alten SAP-BW-Systems mit dem neuen System abgeglichen, dasauf SAP HANA aufsetzt. Dies kann Interfaces, Open Hubs, SAP-BusinessObjects-BI-Berichte, Sicherheit, Broadcast-Berichte, Abfragen und Datenabgleich mit ein-schließen.

Nach der Durchführung solcher Tests werden die Prozessketten auf Funktionalitätund Laufzeiten geprüft, und die Daten werden anschließend erneut abgeglichen.Um diese Schritte durchziehen zu können, müssen Sie sorgfältig planen und Ihreduplizierten Prozessketten über das Wochenende laufen lassen, um negative Aus-wirkungen auf das SAP-ERP-System zu vermeiden. Es bedarf auch einer Planungund einiger Verbesserungen bzw. Erweiterungen an Ihren Ladeprogrammen, umdie Daten sowohl auf das SAP-BW- als auch auf das SAP-HANA-System zu laden,ohne dabei die Delta-Datenübernahme zu beeinflussen. Dies ist zwar nicht ein-fach, aber es ist möglich.


236

Nachdem die Prüfungen abgeschlossen wurden, migrieren Sie einfach die Benutzerauf das neue SAP BW, das auf SAP HANA aufsetzt, und setzen das alte SAP BW aufder relationalen Datenbank außer Betrieb. Sie können es sogar während des Cut-overs als Risikominderungsstrategie einige Wochen lang inaktiv im Hintergrundlaufen lassen. Zusätzliche und hilfreiche Informationen dazu finden Sie im SAP-Hinweis 886102.

Wichtig zu beachten ist hierbei, dass die Datenbankmigrationen von SAP BW aufSAP HANA am besten mit dem in diesem Kapitel beschriebenen DMO-Werkzeugdurchgeführt werden. Obwohl es möglich ist, ist eine schrittweise Migration vonSAP BW auf SAP HANA außerhalb dieses Werkzeugs nicht die beste Methode. DieDMO kann auf dem primären SAP-BW-System oder einer Kopie davon verwendetwerden.

Zusammenfassung der Migrationsansätze

Für die meisten Unternehmen stellt die standardmäßige Migration von SAPBW auf SAP HANA ohne wesentliche Optimierungsaktivitäten die einfachsteund am besten geeignete Lösung dar. Bis jetzt haben die meisten Unterneh-men ihre SAP-BW-Migrationsprojekte auf diese Weise geplant; die anderenAnsätze werden jedoch auch angewendet. Tabelle 6.8 fasst die Implementie-rungsoptionen in einer Übersicht zusammen (einschließlich einer Zeilesowohl für optimierte als auch für nicht optimierte Versionen der Standard-migration; die Optimierung wird im Folgenden erläutert).

Um Ihr Migrationsprojekt von SAP BW auf SAP HANA schneller abzuschlie-ßen, sollten Sie ernsthaft in Erwägung ziehen, die technische Datenbankmi-gration von der SAP-HANA-Optimierung zu trennen. Dies erörtern wiranschließend. Viele Aufgaben können auch zu einem späteren Zeitpunktdurchgeführt werden.

6.4.4 Optimieren einer Migration

Nachdem Sie die Datenbankmigration durchgeführt haben, können Sie IhrSystem optimieren. Wenn Sie sich gegen eine Optimierung entscheiden,wird Ihr Datenbanksystem zwar SAP HANA sein, es werden jedoch keine

Aufwand Risiko Nutzen Gängig

Standardmigration ohne Optimierung niedrig niedrig mittel Ja

Standardmigration mit Optimierung mittel mittel hoch Ja

Tabelle 6.8 Zusammenfassung der Implementierungsoptionen


237

Modelländerungen an Ihrem System vorgenommen. Die Migration hat indiesem Fall keine Auswirkungen auf Ihre Abfragen, Links zu NLS, Interfacesoder das Laden von Daten, sondern führt lediglich zu einer wesentlichschnelleren Leistung und einigen internen Änderungen in Bezug auf Pro-zesse von SAP HANA auf Datenbankebene (d.h. Datenaktivierung und Kom-primierung). Funktionell werden Sie das gleiche System haben, daher ist die-ser Ansatz der schnellste und üblichste.

Wenn Sie sich für eine Optimierung entscheiden, werden die Datenstruktu-ren verbessert, um die neuen Fähigkeiten in SAP HANA optimal nutzen zukönnen, die u.a. auch SAP-HANA-optimierte InfoCubes mit einschließen.Auch zusätzliche SAP-HANA-Hinweise zu Ihren Datentransformationenkönnen hier enthalten sein, um Abfragen beim Laden von Daten schnellerausführen zu können. Dieser Migrationsansatz ist im Grunde genommengleichzeitig ein technisches und ein funktionelles Upgrade. Obwohl die Aus-wirkungen auf die Abfragen minimal sind, bietet die Optimierung eine signi-fikante zusätzliche Leistung in Datenladungen und in der Abfragegeschwin-digkeit.

Für sehr große SAP-BW-Systeme kann dieser Ansatz jedoch ziemlich zeitauf-wendig sein und erfordert möglicherweise wesentlich mehr Prüfungen. Umdiesen Nachteil auszugleichen, können Besitzer großer SAP-BW-Systeme dasfunktionelle Upgrade auf langsame Leistungsbereiche limitieren, die diesenExtraschub benötigen. Sie können aber auch zuerst das standardmäßigeUpgrade durchführen und anschließend das System im Zuge zukünftiger undneuer Entwicklungsbemühungen optimieren bzw. dann, wenn Erweiterun-gen oder Verbesserungen an bestehenden InfoCubes vorgenommen werden.

Sie können auch auswählen, ob die Datenarchitektur aus der Layered ScalableArchitecture (LSA) im älteren SAP-BW-System in eine vereinfachte LSA++-Architektur mit weniger Schichten und Partitionen in SAP BW auf SAPHANA migriert werden soll. In der neuen LSA++-Datenarchitektur wird derTatsache Rechnung getragen, dass die Aufteilung von Tabellen und das Sta-ging im alten SAP-BW-System für eine bessere Lade- und Abfrageleistunghäufig nicht benötigt wird, wenn SAP BW auf SAP HANA betrieben wird.Wie viel Aufwand Sie in die Optimierung zu investieren bereit sind, hängtvon den zur Verfügung stehenden Ressourcen sowie von dem Zeitrahmenab, in dem Sie die Migration abschließen möchten.

In diesem Abschnitt werden einige Optimierungsschritte für SAP BW aufSAP HANA erläutert.


238

Optimierte DataStore-Objekte (DSO)

In früheren Versionen von SAP BW auf SAP HANA wurde empfohlen, die DSOs inSAP BW mithilfe der Transaktion RSMIGRHANADB zu optimieren oder diesemanuell in der Data Warehousing Workbench zu konvertieren. Dies ist nun nichtmehr der Fall. Ab dem Jahr 2014 hat SAP die Funktionsweise von SAP-BW-DSOsauf SAP HANA so verändert, dass die SAP-HANA-optimierten DSOs nicht mehrerforderlich sind. SAP empfiehlt nun, dass die für SAP HANA optimierten DSOswieder zur alten Version rückkonvertiert werden. Neue Kunden sollten ihre DSOsbei einer Migration auf SAP HANA generell nicht konvertieren. Weitere Informa-tionen erhalten Sie in SAP-Hinweis 1849498.

Optimieren von Code

Wenn keine Änderungen vorgenommen werden, laufen möglicherweiseeinige einzelne Datensatzabfragen für Datentransformationen während desLadens der Daten in SAP BW auf SAP HANA langsamer als auf einer relatio-nalen Datenbank. Dies muss nicht im Rahmen einer Migration geändert wer-den. Um jedoch diese Transformationstypen besser identifizieren zu kön-nen, stellt SAP ein Programm namens ABAP Routine Analyzer im SAP BWMigration Cockpit für SAP HANA zur Verfügung (siehe Abbildung 6.29). Mitdiesem Programm können Sie ermitteln, wo der suboptimale Code gespei-chert ist und wie er verbessert werden kann.

Abbildung 6.29 »ABAP Routine Analyzer« und »ABAP Code Inspector« im »SAP BW Migration Cockpit für SAP HANA«


239

Dieses Programm kann sowohl SAP-BW-7.x-Transformationen als auch SAP-BW-3.5-Update- und Transferregeln automatisch überprüfen sowie alleABAP-Codes kennzeichnen, die von weiteren SAP-HANA-Optimierungenprofitieren würden (Abbildung 6.30).

Abbildung 6.30 »SAP BW ABAP Routine Analyzer« für SAP-HANA-Migrationen

Arbeiten mit optimierten InfoCubes

Sie können weiterhin bestehende Standard-InfoCubes verwenden, die keineSAP-HANA-optimierte Eigenschaft haben, Sie können sie aber auch umwan-deln. Der Kern des neuen optimierten InfoCubes besteht darin, dass das Sys-tem außer der Paketdimension keine weiteren Dimensionstabellen erstellt,wenn Sie Merkmale und/oder Kennzeichen bestimmten Dimensionenzuordnen. Stattdessen werden einfach die Stammdaten-Identifier (SIDs) indie Faktentabelle geschrieben, und die Dimensionsschlüssel (DIM IDs) wer-den nicht länger verwendet. Das Resultat ist ein schnelleres Lesen und Ladenvon Daten. Kurz gesagt entwickeln sich Dimensionen zu logischen Einheitenanstatt zu physischen Datentabellen. Das logische Konzept von Dimensionenwird ausschließlich zur Vereinfachung der Abfrageentwicklung in BEx QueryDesigner angewendet. Die InfoCubes können in der standardmäßigen SAP-BW-Administrationsoberfläche oder anhand eines von SAP bereitgestelltenProgramms (RSDRI_CONVERT_CUBE_TO_INMEMORY) optimiert werden.

In Abbildung 6.31 sehen Sie ein Beispiel für ein SAP-BW-InfoCube-Modellvor der SAP-HANA-Optimierung. Da die physische Tabelle des Sternschemaswährend der SAP-HANA-Optimierung verändert wird, muss jedes speziellentwickelte Programm, das direkt auf InfoCubes zugreift, anstatt dafür Stan-


240

dard-Interfaces zu verwenden, neu geschrieben werden. Da sich nur sehrwenige Unternehmen in diesen Bereich gewagt haben, wird die optionaleKonvertierung mit Ausnahme einer schnelleren InfoCube-Leistung nurgeringe Auswirkungen auf die meisten Unternehmen haben.

Abbildung 6.31 SAP-BW-InfoCube-Modell vor der SAP-HANA-Optimierung

In Abbildung 6.32 sehen Sie ein Beispiel für ein SAP-BW-InfoCube-Modellnach der SAP-HANA-Optimierung.

Abbildung 6.32 SAP-BW-InfoCube-Modell nach der SAP-HANA-Optimierung

Faktentabelle

Dimensions-tabelle

Dimensions-tabelle

Merkmale

Merkmale

Attribute &Hierarchien




Merkmale

Merkmale

Merkmale

Merkmale

Merkmale

Merkmale









Dimensions-tabelle

Dimensions-tabelle





Faktentabelle

Merkmale

Merkmale





Merkmale

Merkmale

Merkmale

Merkmale

Merkmale

Merkmale














241

Um bestehende InfoCubes zu konvertieren, können Sie diese entweder ein-zeln in der Administrator Workbench bearbeiten (siehe Abbildung 6.33),oder Sie öffnen einfach das Programm RSDRI_CONVERT_CUBE_TO_INMEMORYund wählen die InfoCubes aus, die konvertiert werden sollen. Der Job wirdim Hintergrund als Speichervorgang ausgeführt und ist extrem schnell. ImDurchschnitt können Sie hier mit einer Dauer von 10 bis 20 Minuten rech-nen, selbst bei sehr großen InfoCubes mit mehreren Hundert Millionen Zei-len. Während der Konvertierung können Benutzer sogar die InfoCubesabfragen, Datenladungen müssen jedoch aufgeschoben werden. Aktuell las-sen sich traditionelle InfoCubes mit maximal 233 Kennzahlen und 248Merkmalen in optimierte InfoCubes konvertieren.

Abbildung 6.33 Konvertieren der SAP-BW-InfoCubes in optimierte InfoCubes

Nach der Konvertierung zu SAP HANA werden optimierte InfoCubes ineinem spaltenbasierten Speicher der SAP-HANA-Datenbank gepflegt und miteinem logischen Index gekennzeichnet (CalculationScenario). Falls dieInfoCubes jedoch vor der Konvertierung nur im SAP BW Accelerator (BWA)gespeichert waren, werden die InfoCubes während der Konvertierung deak-tiviert, sodass Sie diese vor einer erneuten Verwendung reaktivieren und dieDaten neu laden müssen.

Obwohl optimierte InfoCubes nicht ummodelliert werden können, ist esdennoch möglich, InfoObjects mithilfe der InfoCube-Pflegeoption zu lö-schen und hinzuzufügen, selbst nachdem bereits Daten in den InfoCube ge-laden wurden.


242

Da optimierte InfoCubes nur eine Faktentabelle haben, anstatt der zwei Fak-tentabellen, die traditionelle InfoCubes besitzen (eine E-Tabelle mit leseopti-mierter Partitionierung und eine F-Tabelle mit schreib-/löschoptimierter Par-titionierung), ist das Sternschema wesentlich einfacher und ähnelt auchmehr den klassischen logischen Data-Warehouse-Designs, die auf RalphKimballs dimensionalen Modellierungsprinzipien basieren. Diese Vereinfa-chung der Faktentabellen zusammen mit dem Entfernen physischer Dimen-sionstabellen hat zwei- bis dreifach schnelleres Laden von Daten zur Folge.

Bestandskennzahlen sollten auch berücksichtigt werden. Da SAP HANA dieinitialen Bestands-, Delta- und historischen Transaktionen separat lädt, sindzwei DTPs für InfoCubes mit Bestandskennzahlen erforderlich (z.B.Bestands-Cubes). In diesem Fall wird ein DTP benötigt, um die Bestandsda-ten zu initialisieren, und ein weiterer DTP ist erforderlich, um Daten undhistorische Transaktionen zu laden (für weitere Details lesen Sie bitte dieSAP-Hinweise 1548125 und 1558791). Außerdem können traditionelle Info-Cubes mit Bestandskennzahlen nur in optimierte InfoCubes konvertiert wer-den, wenn sie nicht in einen 3.x-Datenfluss eingeschlossen sind.

Aufgrund der erforderlichen manuellen Intervention und der notwendigenDTP-Änderungen sollten Bestands-Cubes und Cubes mit Bestandskennzah-len in einer Sandbox oder einer Entwicklungsbox geprüft werden, bevor siein Produktionssysteme konvertiert werden. Alternativ können diese Info-Cubes in einem nicht konvertierten Status bleiben. In SAP BW 7.4 gibt esneuen Support für Bestandskennzahlen. Daher sollten Kunden auf diese Ver-sion migrieren anstatt auf SAP BW 7.3.

Konvertieren der SAP-BW-3.x-Datenflüsse auf 7.x-DTPs für die SAP-HANA-Migration

Um die Datenflüsse von SAP BW 3.x auf den neuen Datentransformations-prozess (DTP) der SAP-BW-7.x-Systeme konvertieren zu können, hat SAP einKonvertierungswerkzeug im SAP BW Migration Cockpit für SAP HANA inte-griert (siehe Abbildung 6.34).

Mit dem Werkzeug wird der 3.x-Datenfluss einfach kopiert und dieser Ko-pie konvertiert. Somit steht die alte 3.x-Version noch bereit, wenn Sie dieMigration testen. Nach Abschluss des Tests können Sie die ältere Versionlöschen.


243

Abbildung 6.34 SAP-BW-Datenflusskonvertierung für 3.x auf SAP-BW-7.x-DTPs

Partitionierung von InfoCube-Faktentabellen und -Komprimierung

Nach der Optimierung von SAP-HANA-InfoCubes können die Faktentabellennicht länger semantisch partitioniert werden – und das ist auch gar nichtmehr erforderlich. Hinter den Kulissen befinden sich jedoch noch vier Parti-tionen. Die erste Partition wird für unkomprimierte Requests verwendet,während die zweite die komprimierten Requests enthält. Eine andere Parti-tion enthält die Referenzpunkte der Bestandsdaten, und noch eine weiterewird für die historischen Bestandsdatenbewegungen verwendet. Die zweiletzten Partitionen sind leer, wenn ihre Bestandskennzahlen nicht verwen-det werden.

Dennoch erfordern die ersten zwei Partitionen eine regelmäßige Kompri-mierung, um den verwendeten physikalischen Speicher zu reduzieren unddie Ladezeiten bei Zusammenführungsprozessen zu erhöhen (ähnlich dertraditionellen SAP-BW-Datenpflege). Dies hat nur geringe Auswirkungen aufkleine InfoCubes (mit weniger als 100 Millionen Datensätzen) sowie aufInfoCubes ohne ein signifikantes Zurückladen von Daten oder vielenRequests. Da die Komprimierung auch als ein gespeicherter Vorgang inner-halb von SAP HANA ausgeführt wird, läuft die Komprimierung sehr schnellund nimmt selbst bei sehr großen InfoCubes nur wenige Minuten inAnspruch.


244

Die Zukunft der InfoCubes

Derzeit findet in Internet-Blogs und -Foren eine große Debatte darüber statt, obInfoCubes in einem SAP-HANA-System überhaupt erforderlich sind. Vorläufigwerden InfoCubes jedoch aus unterschiedlichen Gründen noch gebraucht.

Sowohl für die Integrierte Planung (IP) als auch für die Write-back-Option werdentransaktionale InfoCubes gebraucht. Außerdem werden InfoCubes zum Speichernund Verwalten von Bestandskennzahlen benötigt, und auch das Interface fürdirektes Schreiben (RSDRI) funktioniert nur für InfoCubes. Zudem wird dieUmstellung von SAP BW auf SAP HANA erleichtert, indem es Kunden ermöglichtwird, zur neuen Plattform zu wechseln, ohne Anwendungslogik, Abfragen, Multi-Provider und Datentransformationen von DSOs zu InfoCubes umschreiben zumüssen.

Nichtsdestotrotz muss infrage gestellt werden, ob InfoCubes weiter verwendetwerden sollen. Die Einführung des Stern- und Schneeflockenschemas und andererTechniken für die dimensionale Datenmodellierung (DDM) in den 1990er-Jahrenreduzierte kostspielige Tabellen-Joins in relationalen Datenbanken, wobei dieDatenredundanz gespeicherter Daten in der ersten Normalform in OperationalData Stores (ODSs) vermieden wurde.

Das Entfernen der relationalen Datenbank aus der In-Memory-Verarbeitung vonSAP HANA stellt die meisten Vorteile der dimensionalen Datenmodellierung zurDiskussion, und eine fortgesetzte Anwendung dieser Strukturen ist fragwürdig. InZukunft werden stattdessen möglicherweise mehrschichtige DSOs mit unter-schiedlicher Datenhaltung und Granularität verwendet werden. Bis es so weit ist,werden InfoCubes in den meisten Unternehmen aber noch als Übergangslösungfür die Datenhaltung eingesetzt.

6.4.5 Neue Funktionen in SAP BW 7.4

In den früheren Versionen von SAP BW auf SAP HANA war es nicht möglich,Daten in nativen SAP-HANA-Schemata mit jenen in SAP BW physisch abzu-fragen. Dies hat sich mit SAP BW 7.4 nun geändert. Diese Version bietetzwei neue Funktionen zur Unterstützung der Modellintegration, unabhängigvon der Quelle:

� erweiterte Composite Provider

� Ansichtsmodelle der Open Operational Data Stores (ODS)

Mithilfe der erweiterten Composite Provider können Sie nun SAP-BW-MultiProvider, SAP-HANA-basierte VirtualProvider, Transient Providerund InfoSets konsolidieren. Dies hat den Vorteil, dass Sie diese über eineeinzige Schnittstelle abfragen können, ohne die Daten zwischen den einzel-nen Quellsystemen oder Modellen verschieben zu müssen (siehe Abbil-dung 6.35).


245

Abbildung 6.35 Erweiterte Composite Provider für SAP BW 7.4 auf SAP HANA

Sie können die Composite Provider auch verwenden, um Daten aus anderenSAP HANA Data Marts und -Anwendungen zu verknüpfen. Außerdem gibtes neue Unterstützung für Bestandskennzahlen in SAP BW 7.4 auf SAPHANA. Der Modellierungsbildschirm zum Erstellen von Composite Provi-dern, der auf der Eclipse-Plattform basiert, ist in Abbildung 6.36 dargestellt.

Abbildung 6.36 Eclipse-Modellierung für SAP BW 7.4 auf SAP HANA

Composite Provider zur Kombination von Daten

SAP BW

MDX, OData, BICS, SQL …

Arbeitsplatz

SAP HANA Data Mart

Tabelle

Modell

Sicht

DSOs

SAP ERP SAP BW Oracle

Hadoop DB2


246

Die neue Open-ODS-Funktion in SAP BW 7.4 ermöglicht es Ihnen, SAP-BW-basierte DSOs mit Tabellen zusammenzuführen, die während der nativenSAP-HANA-Entwicklung erstellt wurden. Somit können Sie SAP-BW-Datenmit Nicht-SAP-BW-Daten auf vielfältige Weise verknüpfen, wie es in vorhe-rigen Versionen von SAP BW nicht möglich war. Den Open-ODS-Modellie-rungsbildschirm sehen Sie in Abbildung 6.37.

Abbildung 6.37 Sicht der Open-ODS-Modellierung in SAP BW 7.4 auf SAP HANA

Zahlreiche Unternehmen haben Probleme bei der Integration der SAP-BW-basierten Data Warehouses in die traditionellen Data Marts anderer Plattfor-men. Mit diesem neuen Werkzeug allerdings kann die Verschiebung derNicht-SAP-BW-Data Marts auf das native SAP HANA einfacher gerechtfertigtwerden, während weiterhin die Möglichkeit besteht, die Tabellen virtuellzusammenzuführen und diese in einer einheitlichen BI-Schnittstelle abzufra-gen. Nicht-SAP-BW-Entwickler können zudem in SAP HANA arbeiten, ohnesämtliche Daten physisch in SAP BW zusammenführen zu müssen.

6.5 Zusammenfassung

Die Planung einer SAP-HANA-Implementierung erfordert fundierte techni-sche Fähigkeiten sowie ein solides Verständnis der langfristigen Architektur-und Systemeinsatzstrategie eines Unternehmens. Sie stellt einen großenUnterschied zum Upgraden von Servern, Datenbanken und Betriebssys-temen dar. Unternehmen erhalten stattdessen eine Appliance, die brand-

Zusammenfassung 6.5

247

neue Funktionen bietet und die Arbeitsweise von Servern und Datenbankenim Unternehmen grundlegend verändert.

Unternehmen sollten den Aufwand einer solchen Implementierung nichtunterschätzen. Die langfristigen Vorteile einer Vereinfachung von Anwen-dungs- und Datenbankservern bei gleichzeitiger Beseitigung von Leistungs-einschränkungen relationaler Datenbanken sind jedoch so zahlreich, dassUnternehmen sie nicht einfach ignorieren können. Um eine SAP-HANA-Implementierung erfolgreich umsetzen zu können, ist es zudem wichtig,kompetente Partner während der Umstellungsphase mit einzubeziehen undseriöses Personal für das Training der vorhandenen Support-Mitarbeiter ein-zusetzen. Die Wahl des richtigen Plattformanbieters und eines erfahrenenPartners ist daher entscheidend.

7

Inhalt

Vorwort zur 2. Auflage ............................................................................ 17Einführung .............................................................................................. 19Danksagung ............................................................................................ 21

TEIL I Was, warum und wann?

1 In-Memory-Computing, Big Data und SAP HANA .............. 25

1.1 Einführung in das In-Memory-Computing und Big Data ......... 261.1.1 In-Memory-Computing und Analysen ........................ 261.1.2 Big Data .................................................................... 31

1.2 SAP HANA – Einführung ........................................................ 351.2.1 SAP HANA als In-Memory-Computing-Lösung .......... 361.2.2 SAP HANA und Big Data als Wegbereiter für

Big-Data-Lösungen .................................................... 391.2.3 Spaltenbasierte Speicherung versus zeilenbasierte

Speicherung .............................................................. 431.2.4 Die Möglichkeiten von SAP HANA ............................ 501.2.5 SAP HANA – Akzeptanzkriterien ................................ 53

1.3 Einführung in die Implementierungsoptionen ........................ 551.3.1 Data Warehouse für Analysen .................................... 551.3.2 SAP BW auf SAP HANA ............................................. 561.3.3 SAP Business Suite auf SAP HANA ............................. 56

1.4 Zusammenfassung .................................................................. 58

2 SAP-HANA-On-Premise-Implementierungsoptionen ......... 59

2.1 SAP HANA als Data Warehouse für Analysen ......................... 592.1.1 Technische Voraussetzungen ..................................... 632.1.2 Erforderliche Qualifikationen ..................................... 662.1.3 Schritte der Projektplanung ....................................... 71

2.2 SAP BW auf SAP HANA ......................................................... 732.2.1 Technische Voraussetzungen ..................................... 812.2.2 Erforderliche Qualifikationen ..................................... 842.2.3 Schritte der Projektplanung ....................................... 87

2.3 SAP Business Suite auf SAP HANA ......................................... 902.3.1 Technische Voraussetzungen ..................................... 942.3.2 Erforderliche Qualifikationen ..................................... 95

Inhalt

8

2.3.3 Schritte der Projektplanung ....................................... 982.4 Auswählen einer SAP-HANA-Implementierungsoption .......... 101

2.4.1 Auswahlmöglichkeit: SAP HANA als Data Warehouse für Analysen ............................................ 103

2.4.2 Auswahlmöglichkeit: SAP BW auf SAP HANA ............ 1042.4.3 Auswahlmöglichkeit: SAP Business Suite auf

SAP HANA ................................................................ 1052.5 Zusammenfassung .................................................................. 106

3 SAP HANA in der Cloud ........................................................ 111

3.1 Cloud – Grundlagen ............................................................... 1113.2 SAP HANA Cloud Platform und SAP HANA

Enterprise Cloud .................................................................... 1133.2.1 SAP HANA Cloud Platform ........................................ 1133.2.2 SAP HANA Enterprise Cloud ...................................... 1153.2.3 SAP HANA Cloud Platform im Vergleich zu

SAP HANA Enterprise Cloud ...................................... 1163.3 Auswählen von SAP HANA in der Cloud ................................ 117

3.3.1 SAP HANA als Data Warehouse für Analysen ............. 1203.3.2 SAP BW auf SAP HANA ............................................. 1213.3.3 SAP Business Suite auf SAP HANA ............................. 122


4 Erweiterte Anwendungen für SAP HANA ............................ 125

4.1 SAP HANA Live ..................................................................... 1254.2 SAP Predictive Analysis für SAP HANA ................................... 1284.3 SAP Business Planning and Consolidation für SAP HANA ....... 1334.4 SAP-Simple-Suite-Lösungen ................................................... 1364.5 Zusammenfassung .................................................................. 137

5 SAP HANA und Ihre Geschäftsstrategie .............................. 139

5.1 Transformationsmöglichkeiten identifizieren .......................... 1415.2 Ihre Bedürfnisse erkennen ..................................................... 145

5.2.1 Unternehmensbedürfnisse ......................................... 1455.2.2 Datenbedarf .............................................................. 147

5.3 Mit bestehenden Lösungen arbeiten: SAP HANA versus SAP BWA ............................................................................... 1515.3.1 Ersetzt SAP HANA meine bestehende

BWA-Lösung? ............................................................ 151

Inhalt

9

5.3.2 Vor- und Nachteile des BWA ..................................... 1545.3.3 Vor- und Nachteile von SAP HANA ........................... 1565.3.4 Ergebnis .................................................................... 158

5.4 Schreiben eines Business Case, Budgetierung und Personalbesetzung für SAP HANA .......................................... 1605.4.1 Schreiben eines Business Case ................................... 1615.4.2 Budgetierung für eine SAP-HANA-

Implementierung ....................................................... 1665.4.3 Personalbesetzung einer SAP-HANA-

Implementierung ....................................................... 1695.4.4 Gestalten einer Roadmap .......................................... 171

5.5 Häufig gestellte Fragen zu SAP HANA .................................... 1745.5.1 Ist SAP HANA eine Datenbank, eine Hardware

oder eine Lösung? ..................................................... 1745.5.2 Welcher Kundentyp zieht SAP-HANA-Lösungen

in Erwägung? ............................................................. 1745.5.3 Was sind die Problemstellungen, die den Bedarf

an SAP HANA aufzeigen? ........................................... 1755.5.4 Was ist das Unterscheidungsmerkmal für SAP

mit SAP HANA? ......................................................... 1755.5.5 Ist SAP HANA sofort betriebsbereit? .......................... 1765.5.6 Funktionieren Nicht-SAP-Business-Intelligence-

Werkzeuge auf SAP HANA? ....................................... 1765.5.7 Was muss ein Kunde alles kaufen, um SAP HANA

anwenden zu können? ............................................... 1775.5.8 Was kostet SAP HANA? ............................................. 1775.5.9 Ersetzt SAP HANA die BWA-Lösung für Kunden? ...... 1785.5.10 Kann SAP HANA als Cloud-Lösung eingesetzt

werden? .................................................................... 1795.5.11 Ist SAP HANA eine weitere »Modeerscheinung«

wie mySAP, die nicht von langer Lebensdauer sein wird? .................................................................. 179


TEIL II Wie wird SAP HANA eingesetzt?

6 Planung einer SAP-HANA-Implementierung ....................... 183

6.1 Von der Implementierung unabhängige Überlegungen .......... 1836.1.1 SAP-HANA-Editionen ................................................ 183

Inhalt

10

6.1.2 Hardwarespezifikationen und -optionen .................... 1896.2 SAP HANA als Data Warehouse ............................................. 196

6.2.1 Datenmodellierung .................................................... 1966.2.2 Sizing ........................................................................ 198

6.3 SAP Business Suite auf SAP HANA ......................................... 2046.3.1 Vollständige Neuinstallation ...................................... 2066.3.2 In-Place-Migration .................................................... 2086.3.3 Kopieren, upgraden und migrieren ............................ 2126.3.4 Sizing ........................................................................ 212

6.4 SAP Business Warehouse auf SAP HANA ............................... 2186.4.1 Sizing ........................................................................ 2196.4.2 Vorbereiten einer Migration ...................................... 2276.4.3 Durchführen der Migration ........................................ 2326.4.4 Optimieren einer Migration ....................................... 2366.4.5 Neue Funktionen in SAP BW 7.4 ............................... 244


7 SAP HANA und SAP Business Intelligence .......................... 249

7.1 Die Werkzeuge im Überblick ................................................. 2497.1.1 SAP BusinessObjects Dashboards .............................. 2497.1.2 SAP BusinessObjects Web Intelligence ...................... 2517.1.3 SAP BusinessObjects Explorer .................................... 2527.1.4 SAP BusinessObjects Analysis .................................... 2577.1.5 SAP BusinessObjects Design Studio ........................... 2597.1.6 SAP Crystal Reports ................................................... 2607.1.7 SAP Lumira ................................................................ 262

7.2 SAP-BusinessObjects-BI-Werkzeuge mit SAP HANA verbinden .............................................................................. 2657.2.1 Universen mit Open und Java Database

Connectivity (ODBC/JDBC) ........................................ 2667.2.2 Herstellen einer Verbindung zu Excel mit

Open Database Objects und MDX ............................. 2747.2.3 Erstellen einer Microsoft-Query-Abfrage für

SAP HANA ................................................................ 2777.2.4 BICS-Verbindungen ................................................... 2797.2.5 Verbindungsoptionen im Überblick ........................... 279


Inhalt

11

8 Entwicklerwerkzeuge für SAP HANA ................................... 281

8.1 UI Development Toolkit für HTML5 (SAPUI5) ........................ 2818.1.1 Die Bibliotheken des UI Development Toolkit

für HTML5 ................................................................. 2848.1.2 Grundlagen ............................................................... 2858.1.3 Erste Schritte ............................................................. 288

8.2 SAP HANA Extended Application Services (XS) ...................... 2928.3 SAP HANA Live ..................................................................... 2968.4 SAP HANA Cloud Platform .................................................... 298

8.4.1 Erste Schritte ............................................................. 2998.4.2 Datenbankschemata und der SAP HANA Cloud

Catalog ...................................................................... 3028.4.3 Die Rollen in der SAP HANA Cloud Platform

festlegen ................................................................... 3048.5 SAP River ............................................................................... 305

8.5.1 Erstellen einer SAP-River-Anwendung ...................... 3058.5.2 Hinzufügen von Aktionen in SAP River ...................... 3078.5.3 Erstellen von Sichten in SAP River ............................. 3088.5.4 Verwenden des SAP River Editors .............................. 3098.5.5 Hinzufügen von Daten in SAP River ........................... 310


9 Datenmodellierung mit dem Information Composer .......... 313

9.1 Einführung in die Bedienung des Information Composers ...... 3159.1.1 Funktionsweise .......................................................... 3169.1.2 Beispielszenario ......................................................... 318

9.2 Hochladen von Daten auf SAP HANA .................................... 3219.2.1 Datenquelle angeben und Daten laden ...................... 3219.2.2 Datenbereinigung ...................................................... 3259.2.3 Klassifizieren von Datenspalten ................................. 3299.2.4 Sichern der Daten ...................................................... 331

9.3 Erstellen von Informationssichten .......................................... 3329.3.1 Datenquellen angeben .............................................. 3329.3.2 Daten zusammenführen ............................................. 336

9.4 Anzeigen hochgeladener Daten und erstellter Informationssichten ............................................................... 3439.4.1 Der Bildbereich »My Data« ........................................ 3439.4.2 Der Bildbereich »My Information Views« ................... 345


Inhalt

12

10 Datenmodellierung mit SAP HANA Studio .......................... 347

10.1 SAP HANA Studio – Überblick und Terminologie ................... 34810.2 Erste Schritte mit dem SAP HANA Information Modeler ........ 353

10.2.1 Hinzufügen eines Systems .......................................... 35510.2.2 Öffnen von Perspektiven ........................................... 35710.2.3 Verwenden von Quick Launch ................................... 35810.2.4 Anlegen eines Pakets ................................................. 35910.2.5 Beispielszenario ......................................................... 360

10.3 Anlegen von Attributsichten .................................................. 36210.3.1 Anlegen einer Attributsicht ........................................ 36210.3.2 Erstellen von Drilldown-Funktionen in einer

Attributsicht .............................................................. 37110.3.3 Überprüfen, Speichern und Aktivieren von

Attributsichten .......................................................... 37110.3.4 Anlegen der Zeitattributsicht ..................................... 373

10.4 Anlegen von Analysesichten .................................................. 37410.4.1 Anlegen einer Analysesicht ........................................ 37410.4.2 Hinzufügen von Sichten und Tabellen ........................ 37510.4.3 Auswählen verfügbarer Felder für eine Analysesicht ... 37710.4.4 Hinzufügen eines Sprachenfilters zur Analysesicht ...... 37810.4.5 Hinzufügen einer Berechnung zu einer Analysesicht ... 37810.4.6 Anzeigen einer Datenvorschau in einer

Analysesicht .............................................................. 38010.4.7 Kopieren einer Analysesicht ....................................... 381

10.5 Anlegen von Berechnungssichten über die grafische Methode ............................................................................... 382

10.6 SQL und SQLScript ................................................................ 39310.6.1 Verwenden von SQL .................................................. 39310.6.2 Verwenden von SQLScript ......................................... 400


11 Erweiterte Konzepte in SAP HANA Studio .......................... 409

11.1 Data-Mart-Virtualisierung ...................................................... 40911.2 Abgeleitete Attributsichten .................................................... 41111.3 Berechnete Attribute ............................................................. 41711.4 Eingeschränkte und berechnete Kennzahlen .......................... 42011.5 Filter und Variablen ............................................................... 426

11.5.1 Filter ......................................................................... 42611.5.2 Variablen und Eingabeparameter ............................... 436

Inhalt

13

11.6 Währungsumrechnung ........................................................... 44011.6.1 Verwenden eines Eingabeparameters zum

Festlegen der Zielwährung ......................................... 44311.6.2 Verknüpfen von Kennzahlen mit Währungen

ohne Verwendung der Umrechnung .......................... 44511.7 Hierarchien ............................................................................ 446

11.7.1 Anlegen einer abgeflachten Hierarchie ....................... 44611.7.2 Anlegen einer Eltern-Kind-Hierarchie ........................ 451

11.8 Personalisierung von SAP HANA Studio ................................. 45311.8.1 Modellvalidierung ..................................................... 45311.8.2 Versionierung ............................................................ 45511.8.3 Modellreferenzen prüfen ........................................... 45511.8.4 Customizing von Perspektiven ................................... 457


12 Datenbereitstellung ............................................................. 461

12.1 Auswählen einer Methode für die Datenbereitstellung .......... 46212.1.1 Strategische Überlegungen ........................................ 46512.1.2 Technische Überlegungen .......................................... 472

12.2 Triggerbasierte Datenreplikation: SAP Landscape Transformation (SLT) .............................................................. 47512.2.1 Installation ................................................................ 47612.2.2 Funktionsweise von SLT ............................................. 47712.2.3 Konfiguration von SLT ............................................... 48012.2.4 Administration von SLT (Start, Replicate, Stop,

Suspend, Resume) ..................................................... 48112.2.5 Erweiterte Funktionen ............................................... 48312.2.6 Einrichten einer neuen Replikationskonfiguration

in SAP HANA ............................................................ 48812.2.7 Hinzufügen von Tabellen zu einer vorhandenen

Replikationskonfiguration .......................................... 49512.3 ETL-basierte Datenreplikation: SAP Data Services .................. 500

12.3.1 Voraussetzungen für die Konfiguration ...................... 50212.3.2 SAP HANA für den Empfang von Daten über

SAP Data Services vorbereiten ................................... 50312.3.3 Daten laden .............................................................. 506

12.4 Transaktionsprotokollbasierte Datenreplikation: SAP (Sybase) Replication Server und Load Controller ............. 52612.4.1 Installation ................................................................ 528

Inhalt

14

12.4.2 Ausführen der Replikation mit SAP/Sybase Replication Server ...................................................... 530

12.5 Direct Extractor Connection ................................................... 53012.5.1 Die DXC-Technologie ................................................ 53112.5.2 Wichtige Überlegungen zum Einsatz von DXC ........... 53412.5.3 SAP HANA für DXC vorbereiten ................................ 53812.5.4 Das Quellsystem für DXC vorbereiten ........................ 53912.5.5 Mit DHX Daten in SAP HANA laden .......................... 540


13 Administration von SAP HANA ............................................ 543

13.1 Die Administration Console von SAP HANA verwenden ......... 54413.1.1 Hinzufügen von Systemen .......................................... 54513.1.2 Exportieren und Importieren von Systemen ............... 54813.1.3 Anzeigen von Details zur Systeminstallation .............. 54813.1.4 Administration Editor und Diagnosemodus ................ 55113.1.5 Ändern des Speicherorts für Dateien ......................... 55113.1.6 Ändern von Konfigurationen ..................................... 55113.1.7 Anpassen der Administration Console ........................ 552

13.2 Überwachen von Systemen .................................................... 55413.2.1 Überwachen der Datenträgerverwendung .................. 55613.2.2 Überwachen der Performance .................................... 55713.2.3 Überwachen mithilfe von Alerts ................................. 55813.2.4 Konfigurieren von Alerts ............................................ 55913.2.5 Überwachen von Services und verteilten Systemen .... 56013.2.6 Exportieren und Importieren von Tabellendaten ........ 56213.2.7 Überwachen der Speichernutzung ............................. 56313.2.8 Große Tabellen durch Partitionierung verwalten ........ 56413.2.9 Lastausgleich durch Verschieben von Dateien

und Partitionen ......................................................... 56713.2.10Beheben von Disk Full Events .................................... 56813.2.11Unterstützung für nicht reagierende Systeme ............. 568

13.3 Aktualisierung ........................................................................ 56913.3.1 Aktualisieren der SAP HANA Appliance ..................... 56913.3.2 Aktualisieren von SAP HANA Studio .......................... 570

13.4 Sicherheit .............................................................................. 57213.4.1 Systemberechtigungen ............................................... 57213.4.2 Sicherheit bei der Authentifizierung ........................... 57313.4.3 Sicherheit von Berechtigungen .................................. 574

Inhalt

15

13.4.4 Eine Kennwortrichtlinie definieren ............................. 57913.5 Lizenzschlüssel ....................................................................... 580

13.5.1 Temporäre Lizenzschlüssel ......................................... 58113.5.2 Permanente Lizenzschlüssel ....................................... 582

13.6 Sicherung und Hochverfügbarkeit .......................................... 58313.6.1 Sicherung .................................................................. 58313.6.2 Hochverfügbarkeit ..................................................... 58513.6.3 Mehrere Datenbanken und Komponenten auf

derselben Hardware .................................................. 58613.7 SAP Solution Manager und SAP HANA .................................. 58813.8 DBA Cockpit für SAP HANA ................................................... 59013.9 Zusammenfassung .................................................................. 593

A Die Autoren ....................................................................................... 595

Index ...................................................................................................... 597

597

Index

A

ABAP Code IRnspector 238ABAP Routine Analyzer 238, 239ACID � Atomarität, Konsistenz, Isoliert-

heit, DauerhaftigkeitAdministration 67, 85, 95, 96, 543

Administration Editor 66, 551Aktualisierung 569, 570Alert 558, 559Configuration, Registerkarte 551, 561Datenträgerverwendung überwachen 556Diagnosemodus 551Disk Full Event 568große Tabellen verwalten 564Installation 548Konfiguration ändern 551Lastausgleich 567mit Alerts überwachen 558nicht reagierendes System 568Partitionierung 564, 565, 566, 567Performance überwachen 557Performance, Registerkarte 557Services überwachen 560Services, Registerkarte 560Speichernutzung überwachen 563Speicherort für Dateien ändern 551System exportieren/importieren 548System hinzufügen 545, 546System Information, Registerkarte 543Tabellendaten 562Überwachung 554, 555

Administration Console 348, 354, 543, 544anpassen 552Katalog 356Schema 357Zugriff 545

Administrator Workbench 241Aggregate, Aggregations-Engine 78aggregierte Daten 79, 83, 90, 162,

227, 266Aktualisieren vs. Einfügen 46Alias, Systemvorschlag 416

Aliasname 415pflegen 415

Amazon 118Amazon Web Services (AWS) 118, 119Amount with currency 441Analysesicht 273, 349, 350, 353, 374

anlegen 374Berechnung hinzufügen 378Datenvorschau 380Felder auswählen 377kopieren 381Sichten und Tabellen 375Sprachenfilter hinzufügen 378

Analysesichten 266, 351Anwendung ShowBusiness 305Atomarität, Konsistenz, Isoliertheit,

Dauerhaftigkeit (AKID) 28, 29Attribut 329, 330, 348, 391

berechnetes 417Attributsicht 266, 273, 349, 350, 351,

362, 435abgeleitete 409, 411, 412anlegen 362Ausgabe 369basierend auf einer Kundentabelle 364Country 361Customer 361Drilldown-Funktionen 371Fehler überprüfen 372in einem Paket 362Join 364, 365Kunde 351, 352Sales Organization 361Schlüsselattribut 370standardmäßige 363Typ 362überprüfen 371überprüfen, speichern und aktivieren 371Zeit 373

Ausgabeparameter, SQL-Sicht 397

B

Bandbreite 120, 122B-Baum-Index 43

598

Index

Benutzererlebnis (UX) 284Berechnungs-Engine 77Berechnungssicht 266, 273, 296, 316,

350, 382anlegen 384, 395, 403Feld auswählen 391Feld hinzufügen 392Feldzuordnung überprüfen 390Objekte ausrichten 388Verbindung erstellen 386

Beschaffung und Suite auf SAP HANA 92Bestands-Cube 242BI Consumer Services (BICS) 177

Verbindung 279Big Data 26, 31, 33, 34, 41, 148

Beispiel 41, 42Bitmap-Index 44Bring Your Own License (BYOL) 115Business Content 103, 125, 127Business-Analyst 86, 97BWA 36, 76, 151, 152, 153, 158, 178, 241

Hardware 152versus SAP HANA 151, 152, 153Vor- und Nachteile 154

C

Cache 151Calculate Column Editor 379CalculationScenario 241CE-Funktion 401Change and Transport System 589Change Data Capture (CDC) 506, 507, 509Checkbox für Dezimalverschiebung

aktivieren 443Checkbox für Umrechnung aktivieren 442Cisco 189Cisco/EMC 192, 218Client-Abhängigkeit 427

Variable $$client$$ 433Cloud 111

Amazon 118IaaS, PaaS, SaaS 112öffentliche 117private 116

Cloudera 43Composite Provider 244, 410

erweitert 244Configuration, Registerkarte 561

Content 358Controller-Baustein 478Converged System 500 192CO-PA 176CPU 64, 82, 162, 202, 353CPU-Auslastung 555CTS 589Cube, im Arbeitsspeicher optimierter 134

D

Data Governance 35, 40Data Mart 409Database Migration Option (DMO) 209DataStore-Objekt � DSODatenbankbenutzer 572Datenbankmigration 85Datenbereitstellung 461

technische Überlegungen 472Datenintegrität 35, 40Datenladevorgang 101Datenmenge 34, 39Datenmodellierung 72, 88, 196

Beispielszenario 318, 360Bottom-Up-Ansatz 352konzeptueller Ansatz 352physischer Ansatz 352Top-Down-Ansatz 352

Datenqualität 150Datenspeicher 83Datenträgerauslastung 555Datentransferprozess (DTP) 228, 242Datentransformation 101Datenumfang 34, 39DB02 58, 85DBA Cockpit 590, 592

DB Performance Monitor 590Dell 189, 218Dictionary-Komprimierung 48dimensionale Datenmodellierung 244Direct Extractor Connection 530, 531

Datentransformation 534Exklusivität der Datenquelle 535Primärschlüsseleinschränkung 537Quellsystem vorbereiten 539Side-by-Side-Konfiguration 533Standardkonfiguration 532Vorbereitung von SAP HANA 538

direkt verbundener SAS-Speicher 83

599

Index

Disaster Recovery 30, 85Domänenfestwert 434DSO 78, 164, 228

SAP-HANA-optimiert 238

E

EarlyWatch-Bericht 220Echtzeit 27, 57, 61, 65, 69, 103, 104,

128, 480Eclipse 245, 288EDGE 185Eingabeparameter 436

anlegen 439für Formel 436für Währung 436statische Liste 436, 439Währung 443

Enterprise Connect Data Access (ECDA) 528

Enterprise Information Manage-ment (EIM) 69, 86, 97

Entwicklung 70, 87, 98ETL 55, 72, 103ETL-basierte Datenreplikation 463, 500Export Wizard 562Exportdatei 548Exportieren/Importieren von

Tabellendaten 562Expression Editor 380Extended Application Services

� SAP HANA XSExtraktion, Transformation, Laden � ETL

F

Facette 253Feldreferenz duplizieren 414Fertigungsindustrie und Suite auf SAP

HANA 92Filter 426

Bedingungsfilter 426Finanzwesen und Suite auf SAP HANA 91Formel validieren 419Fujitsu 189, 218

PQ 2800 190

G

Generieren, Select-Statement 396Gesamtbetriebskosten 140, 161GTK2 188

H

Hadoop 42, 43, 193Hadoop Distributed File

Systems (HDFS) 43Hardware 189Hash-Partition 566Hauptspeicher 29Help, Registerkarte 548Hewlett-Packard 189Hierarchie 446

abgeflachte 446, 447Datenvorschau 451Eigenschaften 450Eltern-Kind 446, 451, 452rekursive 451

Hintergrundjob 505, 508, 519, 524Hitachi 189, 218Hitachi Data Systems 43Hive 43Hochverfügbarkeit 585HP 43, 217

Sizing-Werkzeug für SAP Business Suite 217

HTML5 282Huawei 189, 218Human Resources und Suite auf

SAP HANA 92

I

IBM 43, 65, 120, 189, 192, 218IBM Labs 193InfoCube 77, 162, 221, 228, 241

Faktentabelle 243nach Optimierung 240SAP-HANA-optimiert 239, 241vor Optimierung 239Zukunft 244

Information Composer 313, 315Beispielszenario 318Bildbereich My Data 343, 345Bildbereich My Information Views 345

600

Index

Information Composer (Forts.)Data Summary View 324Daten anpassen 342Daten hochladen 317, 321, 322, 324Daten sichern 331Daten teilen 331Daten und Sichten anzeigen 343Daten zusammenführen 336, 337Datenbereinigung 325Datenquelle angeben 332, 334, 335Datenspalte klassifizieren 329Datenvorschau 320Datenzuordnung festlegen 340Draft 321Einstiegsbildschirm 318Felder verwalten 342Funktionen 315, 316Informationssicht aufbauen 317Informationssicht erstellen 332Sicht veröffentlichen 317veröffentlichen 331Wert ändern 327, 328Werte zusammenführen 326, 327

Information Design Tool (IDT) 265, 269, 270, 271, 272, 273

Informationsmodell 266Informationssicht 313InfoSets 244InfoSys 120Infrastructure as a Service (IaaS) 113In-Memory-Computing 26, 27, 28, 29, 36In-Memory-Computing-Engine 38Instanzfähigkeit 121, 122Integrierte Planung (IP) 56, 219Intel 189IT-Management und Suite auf HANA 92Ivy Bridge 189

J

Java Database Connection (JDBC) 555Java Runtime Environment 188Join 337, 338, 339, 364

Cardinality 366Join-Typ 366

full 367inner 366referential 366, 367right outer 367

Join-Typ (Forts.)text 368

JSON 287, 300Jupiter 193

K

Kennwortrichtlinie 579Kennzahl 329, 330, 349, 391

auswählen 422berechnete 420, 423, 424Bestand 242eingeschränkte 420festlegen 422mit Währungen verknüpfen 445Typ 441

Kerberos 573komprimierter Request 243kontextbezogenes Dashboard 57

L

Lastausgleich auf mehreren Hosts 567Lesebaustein 478liveCache 36, 216Lizenzschlüssel 580

permanent 580, 582temporär 580, 581Vermessung 583

Load Controller (LC) 38, 526Logical View, Registerkarte 376LSA++ 228, 237, 410

M

M_Service_Memory 563Marketing und Suite auf SAP HANA 92Massive Parallel Processing (MPP) 39, 73MaxDB 36MCOD-Konfiguration (Multiple

Components One Database) 586MDX 38, 66, 177mehrere Knoten 83, 223mehrstufige Partitionierung 565Microsoft Excel 60, 66, 276, 277Microsoft Query 277, 278Microsoft Silverlight 317Modeler 348, 353Modellreferenz prüfen 455

601

Index

Modellvalidierung 453Multiple Components One

System (MCOS) 586, 587MultiProvider 80, 81, 350

N

Nearline Storage (NLS) 227, 592NEC 189, 218Network Time Protocol (NTP) 188NLS 592

O

Object Linking and Embedding Database (OLE DB) 275

OLAP 56OLTP 56Open Database Object (ODO)

und MDX 274Open Operational Data

Store (ODS) 197, 244Open und Java Database Connectivity

(ODBC/JDBC) 266Operational Data Provisioning (ODP) 75operative Delta-Queue 75operativer Bericht 57, 104Oracle 58, 85Oracle 11g 76

P

Parameter, Eingabe 436Partitionierung, Round-Robin 567Persistent Staging Area (PSA) 224persistenter Speicher 29personalisierte Sicht 253Perspektive

Customizing 457öffnen 357

physischer Speicher 555, 563Platform as a Service (PaaS) 112Power-User 86Preferences (Window) 454Produktentwicklung und Suite auf

SAP HANA 93Projektphasen 72

Protokollierungstabelle für SAP Landscape Transformation 478

Protokollspeicher 82

Q

QlikView 27Quick Launch 358QuickSizer 199, 212, 220, 223

R

R3load 527RAM 82Range Partition 565Rapid Application Develop-

ment (RAD) 305relationale Datenbankmanagement-

systeme (RDBMs) 44Remote Function Call (RFC) 68RFC-Verbindungen (Remote Func-

tion Call) 85RICEF 164River Development Language (RDL) 305Rolle 576

Administration 577Entwickler 171Personal des Hardwareanbieters 170Projektleiter 169SAP-HANA-Architekt 169SAP-Support 171Wirtschaftsanalyst 170

Runbook 233

S

Sales and Distribution (SD) in SAP ERP 127SAP (Sybase) IQ 42, 592SAP (Sybase) Replication Agent 527SAP (Sybase) Replication Server 38, 60,

62, 526Installation 528Überblick 464

SAP Advanced Planner and Optimizer (APO) 36, 56

SAP Business One 57SAP Business Planning and Consoli-

dation 56, 133, 134, 135Cube 134

602

Index

SAP Business Suite auf SAP HANA 56, 90, 105, 122, 151, 184, 204Anforderungen 94, 95, 96Architektur 95Branchen 91für KMU 57Geschäftsprozesse 91Implementierungsoptionen 93In-Place-Migration 208kopieren, upgraden, migrieren 212Neuinstallation 206

SAP Business Warehouse Accelerator � BWA

SAP Business Warehouse � SAP BWSAP BusinessObjects Analysis 257

Microsoft-Version 257OLAP 257

SAP BusinessObjects BI 52, 62, 81, 88, 249mit SAP HANA verbinden 265, 266, 279

SAP BusinessObjects Dashboards 249SAP BusinessObjects Design Studio

258, 259SAP BusinessObjects Explorer 62, 252

Information Space 254, 256SAP BusinessObjects Web Intelligence 251SAP BW 56, 60, 76, 77, 104, 151, 174,

227, 230, 244, 245, 246BW 7.3 Unicode 81Cube 73, 84, 103Schneeflockenschema 134, 244Upgrade 242

SAP BW Administrator Workbench 221SAP BW Analytical Engine 592SAP BW auf SAP HANA 52, 56, 73, 84,

87, 102, 104, 108, 121, 151, 153, 184, 218, 531Anforderungen 81, 84Architektur 82Checklisten-Werkzeug 230Code optimieren 238Implementierung planen 233, 234Implementierungsmöglichkeiten 74Migration 227, 235Migration optimieren 236Migration vorbereiten 227Migrationsansätze 236optimieren 239Prüfungen vor einer Migration 230Vorteile 74

SAP BW Migration Cockpit für SAP HANA 219, 224, 230, 238

SAP CRM 91, 126SAP Crystal Reports 260, 261SAP Data Integrator 43SAP Data Services 38, 42, 62, 65, 70,

72, 88, 126, 184, 500Data Services Designer 525DataStore 514DataStore einrichten 512Daten laden 506Datenaktualisierungsmethode 506Datenempfang 503Datenfluss 520File Format Editor 518Hintergrundjob ausführen 524Hintergrundjob erstellen 519Konfiguration 502Local Object Library 513, 516Metadaten definieren 517Metadaten importieren 515, 516Metadatenreplikation 503Überblick 463Verbindung mit SAP HANA 503

SAP Data Services 4.2 502SAP Data Services Designer 511, 512

Project Area 513SAP ERP 58SAP ERP 6.0 205SAP Fiori 283SAP Global Trade Services (GTS) 126SAP HANA 25, 35, 36, 37

Akzeptanzkriterien 53als Anwendung 174als Datenbank 65, 174Anforderungen 102Arbeitsplatzbeschreibung 67Branchen 50Business-Analysten 68Cloud 111Editionen 183, 185Einsatzbereiche 51erweiterte Anwendungen 125Geschäftsstrategie 139, 140, 141,

145, 148häufig gestellte Fragen 174, 175,

176, 177, 178, 179Implementierung planen 183Implementierungsoptionen 55, 111

603

Index

SAP HANA (Forts.)Möglichkeiten 61native Entwicklung 281On-Premise-Implementierungsoptionen

59, 101Pilotprogramm 62Preismodell 37Softwarekomponenten 186und Big Data 39, 40, 41versus BWA 156was SAP HANA kann 50was SAP HANA nicht kann 52Web IDE 292

SAP HANA als Data Warehouse 55, 59, 60, 61, 120, 184, 196Anforderungen 63, 66

SAP HANA Application Services 114, 119SAP HANA Cloud Platform 113, 298

Anwendung ausführen 302Catalog 302Cockpit 298Datenbankschema 302Entwicklung 298Instanz erstellen 300kostenlose Entwicklerlizenz 115Rolle 304Testversion 299Workbench Editor 301

SAP HANA Database Services 114, 119SAP HANA Developer Edition 118, 119SAP HANA Enterprise Cloud

113, 115, 119Anwendungen 116

SAP HANA Infrastructure Services 115, 119

SAP HANA Live 125, 164, 296Architektur 126Beispiel 127Berechnungssicht 297Entwicklung 296

SAP HANA Live View Browser 297, 298SAP HANA Load Controller 60SAP HANA One 119SAP HANA Studio 52, 347

Beispielszenario 360Data Foundation, Registerkarte 376im Vergleich zu Information

Composer 314, 347Navigator 354

SAP HANA Studio (Forts.)nicht-strukturelles Paket 360Paket 359Personalisierung 453Perspektive 348strukturelles Paket 360System hinzufügen 355, 356

SAP HANA Unified Installer 189SAP HANA XS 292, 294, 538SAP Host Agent 60SAP Landscape Transformation

Administration 481Data Transfer Monitor 498Daten filtern 483Datentransformation 486Installation 476Konfiguration 480load 481replicate 481Replikationshäufigkeit 480Replikationskonfiguration 488, 495resume 482selektive Tabellenreplikation 483spezielle Filterregel für Mandanten 487stop 482suspend 482Überblick 462

SAP Landscape Transformation (SLT) 60, 62, 65, 72, 88, 126, 462, 475

SAP Lumira 262Anbindung an SAP HANA 264Auswählen der SAP-HANA-Sichten 265Visualisierung 263

SAP Predictive Analysis 128, 131, 132Architektur 131Integration in SAP HANA 132

SAP Rapid Deployment Solutions 55, 184, 219

SAP River 305Aktion hinzufügen 307Anwendung erstellen 305Daten hinzufügen 311Editor 309Entwicklung 305Model-Perspektive 310Sicht erstellen 308

SAP SCM � SAP Supply Chain Management

SAP Simple Finance 136

604

Index

SAP Simple Suite 136SAP Solution Manager 220, 588

System Landscape Setup Guide 589SAP Solution Manager Diagno-

stics (SMD) 592SAP Supplier Relationship Management

(SAP SRM) 91SAP Supply Chain Management

(SCM) 36, 91, 126SAP_BW_HOUSEKEEPING-Aufgaben-

liste 229SAPCAR 60SAP-HANA-Geschäftsstrategie

Ausbildungsplan 169Budgetierung 166Business Case 161, 162, 164, 165Datenbedarf 147Personalbesetzung 167, 169Projektkosten 167Roadmap 171, 172Speicherkosten 163Unternehmensbedürfnisse 145, 146

SAP-Hinweis 188, 228SAPUI5 281, 283

Bibliothek 284mobile Anwendung 290sap.ui.commons 284sap.ui.core 284sap.ui.table 284sap.ui.ux3 284Steuerelemente für SAP HANA 288

Savepoint 29Scale-Out SAP HANA 192Scale-Up SAP HANA 190Schattensystem 234Schedule by Interval 480Schedule by Time 480Schreibbaustein 478Schritte der Projektplanung 72

SAP BW auf SAP HANA 87, 89SAP HANA als Data Warehouse 71Suite auf SAP HANA 98, 100

Secure Sockets Layer (SSL) 546Security Assertion Markup Language

(SAML) 573Server 82Service Level Agreement (SLA) 558Service und Suite auf SAP HANA 93

Sicherheit 572Administrationsrolle zuordnen 577Authentifizierung 573Benutzer hinzufügen oder

deaktivieren 574Benutzer und Berechtigungen 85Berechtigung 574Kennwortrichtlinie 579Rolle hinzufügen und anpassen 576Systemberechtigung 572

Sicherung 583Sizing 198

ABAP-Routine 215Anbieterwerkzeuge 217Eingabeparameter 225Faustregel 199, 201SAP Business Suite auf SAP HANA 212SAP BW auf SAP HANA 219, 226SAP HANA als Data Warehouse 198SAP QuickSizer 199, 223T-Shirt-Modell 199, 203, 204

Skalierbarkeit 120, 122SLT Replication Server 69Smart Business 296Software as a Service (SaaS) 112, 136Software Logistics Toolset (SL) 189Software Update Manager (SUM) 189, 230spaltenbasierte Speicherung 43, 44, 46,

47, 49im Vergleich zu zeilenbasiertem

Speicher 49Vor- und Nachteile 45

spaltenbasierte Tabelle 266Speicherverbrauch 563SQL 38, 66, 177, 382, 393, 396

Ausgabeparameter definieren 398Beispielcode 394Sichtausgabe definieren 399

SQL-Engine 78SQLScript 393, 400, 403

Beispielcode 404gängige Befehle 402

Standard-Clientsichtspezifischer 430Standard-Modellparameter 432

Standard-Session-Client 428, 444ändern 432pflegen 429

Statistiken zur Abfrageperformance 557

605

Index

Sternschema 244SUMFORHANA 570Supply Chain Management

und Suite auf HANA 93SUSE Linux Enterprise Server 82Sybase � SAP (Sybase)Syslogd 188Systemdefinition importieren 548

T

Tabelle, client-abhängige 427Tabelle RSBATCHDATA 228Tivoli Storage Manager 584Tools Palette 386Transaktion

IUUC_SYNC_MON 492, 493, 495LTR 488, 491, 494, 497

transaktionsprotokollbasierte Daten-replikation 464, 526

Transformationsmöglichkeiten 69, 79, 141, 142, 143, 144

Transient Provider 244, 410Trendanalyse 31TREX 36triggerbasierte Datenreplikation 462, 475T-Systems 120

U

Überwachen von Systemen 554Überwachung der Datenträger-

verwendung 556Unicode 188, 230Unified Installer 569Union 337, 338, 339Union-Vorgang 389Unternehmensanalyse 145Upload with Column Headers 324

V

Variable 436Attributwertvariable 437für Attributwert 436optionale 437

Versionierung 455Vertrieb und Suite auf SAP HANA 93VirtualProvider 244, 410virtueller Data Mart 409vorausschauende Analyse 128

Anomalien 130beeinflussende Hauptfaktoren 129Beziehungen 130Herausforderungen 129Prognose 129Prognosewerkzeug SPSS 131Trends 129

VorgangFilter 426Variable 426

W

Währungsumrechnung 440Fehleroption 443für eine Kennzahl 441Tabelle 441

Web IDE 292Where-Used List 455

X

x3950 193XULRunner 188

Z

zeilenbasierte Speicherung 43, 44, 47, 49im Vergleich zu spaltenbasiertem

Speicher 49Vor- und Nachteile 45

Zuordnung 339, 389Zusammenführungseinstellung

anlegen 337

Wir hoffen sehr, dass Ihnen diese Leseprobe gefallen hat. Sie dürfen sie gerne empfeh-len und weitergeben, allerdings nur vollständig mit allen Seiten. Bitte beachten Sie, dass der Funktionsumfang dieser Leseprobe sowie ihre Darstellung von der E-Book- Fassung des vorgestellten Buches abweichen können. Diese Leseprobe ist in all ihren Teilen urheberrechtlich geschützt. Alle Nutzungs- und Verwertungsrechte liegen beim Autor und beim Verlag.

Teilen Sie Ihre Leseerfahrung mit uns!

Bjarne Berg verfügt über umfangreiche Erfahrungen bei der Im- plementierung von SAP Business Warehouse Accelerator und SAP HANA in Europa und in den USA. Er tritt häufig als Sprecher auf SAP-Konferenzen auf, schreibt Artikel für SAPinsider und lei-tet als Professor der SAP University Alliance an der Lenoir Rhyne University Kurse zu SAP HANA und SAP.

Bjarne Berg, Penny Silvia

Einführung in SAP HANA605 Seiten, gebunden, 2. Auflage 2015 69,90 Euro, ISBN 978-3-8362-3459-7

www.sap-press.de/3748

Penny Silvia ist Mitglied des IBM Global Leadership Team for SAP Data and Analytics und verfügt über weitreichende Erfah-rungen bei der Implementierung von fortschrittlichen Systemen und In-Memory Analyselösungen für SAP-Kunden. Sie hält häu- fig Vorträge auf SAP-Konferenzen und ist Mitglied des Beratungs- ausschusses für verschiedene SAP-Veröffentlichungen.

Wissen aus erster Hand.

https://www.rheinwerk-verlag.de/einfuhrung-in-sap-hana_3748/?GPP=lpn

https://www.facebook.com/rheinwerkverlag

https://plus.google.com/118435207805510651040

http://twitter.com/rheinwerkverlag

Einführung in SAP HANA - s3-eu-west-1. · PDF filefür ein Data Warehouse, SAP...

Documents

Transcript of Einführung in SAP HANA - s3-eu-west-1. · PDF filefür ein Data Warehouse, SAP...