SAP BW auf SAP HANA – Implementierung und Migration · PDF file49 SAP HANA wird als...

23
Leseprobe SAP HANA wird als Appliance ausgeliefert und ist somit ein Gesamt- produkt aus Serverhardware, Betriebssystem und SAP HANA. Diese Leseprobe geht auf alle Bestandteile ein. Sie zeigt Ihnen, welche Aus- wahlmöglichkeiten Sie haben, und was es zu beachten gilt. Matthias Merz, Torben Hügens, Steve Blum SAP BW auf SAP HANA – Implementierung und Migration 489 Seiten, gebunden, Dezember 2014 69,90 Euro, ISBN 978-3-8362-2965-4 www.sap-press.de/3660 Kapitel 2: »Architektur von SAP HANA« Inhalt Index Die Autoren Leseprobe weiterempfehlen Wissen aus erster Hand.

Transcript of SAP BW auf SAP HANA – Implementierung und Migration · PDF file49 SAP HANA wird als...

LeseprobeSAP HANA wird als Appliance ausgeliefert und ist somit ein Gesamt-produkt aus Serverhardware, Betriebssystem und SAP HANA. Diese Leseprobe geht auf alle Bestandteile ein. Sie zeigt Ihnen, welche Aus-wahlmöglichkeiten Sie haben, und was es zu beachten gilt.

Matthias Merz, Torben Hügens, Steve Blum

SAP BW auf SAP HANA – Implementierung und Migration489 Seiten, gebunden, Dezember 2014 69,90 Euro, ISBN 978-3-8362-2965-4

www.sap-press.de/3660

Kapitel 2: »Architektur von SAP HANA«

Inhalt

Index

Die Autoren

Leseprobe weiterempfehlen

Wissen aus erster Hand.

49

SAP HANA wird als Appliance ausgeliefert, und ist somit ein Gesamtprodukt aus Serverhardware, Betriebssystem und SAP HANA. In diesem Kapitel möchten wir auf diese Bestandteile im Detail eingehen. Wir erklären, welche Rolle sie spielen, welche Auswahlmöglichkeiten Sie haben, und was es zu beachten gilt.

2 Architektur von SAP HANA

In Abschnitt 1.4, »Technische Grundlagen: Warum ist SAP HANA soschnell?«, haben wir bereits darauf beschrieben, welche innovativenPrinzipien SAP HANA von anderen Datenbanken unterscheiden.Nun möchten wir auf die Architektur eingehen, also auf das Zusam-menspiel zwischen den verschiedenen Komponenten eines HANA-Systems. Unter dem Begriff Architektur verstehen wir dabei Hard-ware und Software allgemein und die SAP-HANA-Prozesse im Spezi-ellen.

AufbauIn Abschnitt 2.1, »Hardware«, möchten wir uns mit der Frage ausein-andersetzen, welche Kriterien ein zertifiziertes HANA-System aus-machen. Für die Aufrüstung eines bestehenden HANA-Systems wer-den wir auf die Begriffe Scale-up und Scale-out eingehen. Der Einsatzeiner In-Memory-Datenbank stellt besondere Anforderungen an dieDatensicherheit und das Hauptspeichermanagement. Daher habenwir auch diesen Themen eigene Abschnitte gewidmet. Als Alterna-tive werden wir zudem auf die HANA-Cloud-Angebote von SAP ein-gehen und ihre Unterschiede verdeutlichen.

In Abschnitt 2.2, »Software«, werden wir uns mit der Frage beschäf-tigen, wie die parallele Nutzung eines HANA-Servers für mehrereZwecke möglich ist. Auf den Betrieb von HANA in virtuellen Maschi-nen gehen wir gesondert ein. Abschließend weisen wir auf einigeBesonderheiten der Betriebssystemwahl hin.

Im Rahmen der Architektur möchten wir auch detailliert auf dieFunktionsweise von SAP HANA eingehen. In Kapitel 6, »Administra-

Architektur von SAP HANA2

50

tion mit dem SAP HANA Studio«, sowie im sonstigen Verlauf diesesBuches werden Sie gelegentlich auf HANA-Prozesse oder -Enginesaufmerksam gemacht. Deren Funktionsweise erklären wir inAbschnitt 2.3, »SAP-HANA-Prozesse«. Den Indexserver-Prozessbehandeln wir dabei gesondert, da er als Herzstück von SAP HANAfür eine Vielzahl von Aufgaben zuständig ist.

Aktuelle

Informationen

Behalten Sie bitte beim Lesen im Hinterkopf, dass SAP HANA einsich schnell weiterentwickelndes Produkt ist: Allein während desVerfassens dieses Buches wurde ein weiteres Betriebssystem zur pro-duktiven Nutzung mit SAP HANA freigegeben, einige Details desHauptspeichermanagements verändert und der produktive Betriebin virtuellen Maschinen gestattet. Damit Sie sich über den aktuellenStand informieren können, verweisen wir, wenn möglich, auf dieentsprechenden SAP-Hinweise. Wenn ein Thema Ihr Interesseweckt, empfehlen wir Ihnen, sich mit diesen Hinweisen auf denaktuellen Stand zu bringen.

2.1 Hardware

Heutige Server verfolgen wie auch Desktop-PCs ein flexibles Hard-warekonzept. Ihre Hard- und Software ist darauf ausgerichtet, einemöglichst große Kombinationsvielfalt der unterschiedlichen Hard-warebestandteile zu unterstützen. Gut erkennen lässt sich dies amAufwand, den Hardware- und Betriebssystemhersteller ebenso wieKunden betreiben müssen, um Treiber zu entwickeln, zu warten undzu installieren.

Einheit von Soft-

ware und Hardware

In der IT-Welt gibt es jedoch auch populäre Gegenbeispiele wie dieGeräte von Apple, die Spielekonsolen von Sony, Microsoft oder Nin-tendo oder die bei Bastlern beliebten Kleinstcomputer wie denRaspberry Pi. Bei diesen Produkten wird versucht, die Hard- undSoftware möglichst eng zusammenarbeiten zu lassen. Je weniger derProgramm- und Treibercode an unterschiedliche Bauteile angepasstwerden muss, desto weniger Aufwand in der Entwicklung und Aus-führung. Als Folge davon entstehen Softwareprojekte, die eineerstaunliche Performance besitzen. Eine stark auf die Hardwarezugeschnittene Anwendungsentwicklung führt also zu besserer Per-formance.

Hardware 2.1

51

SAP HANA

Appliance

Auch bei SAP HANA wird ein ähnliches Konzept verfolgt. Dafür wur-den Richtlinien für die Hard- und Softwareumgebung auf den Ser-vern geschaffen, damit der Datenbankbetrieb stets in einer möglichsthomogenen Umgebung stattfindet. Dadurch soll für jede Applianceeine hohe Performance und niedrige Fehleranfälligkeit erreicht wer-den. Gegenwärtig wird nur eine zertifizierte Auswahl an Servern undBetriebssystemen für den produktiven Einsatz mit SAP HANA unter-stützt. Das Gesamtprodukt, bestehend aus Hardware, Betriebssys-tem, SAP HANA und allen dazugehörigen Tools, wird als Appliancebezeichnet. Ein Kunde hat also für die Anschaffung von SAP HANAfür produktive Zwecke die Wahl zwischen vordefinierten Paketen. Jenach Szenario werden zudem mehrere Server für Scale-out, Test- undEntwicklungssystem oder Hochverfügbarkeitsszenarien eingesetzt.

Im Folgenden möchten wir auf die zahlreichen Möglichkeiten einge-hen, welche Hardware Sie einsetzen und wie Sie diese verwendenkönnen.

2.1.1 Zertifizierung

Hardware-Zertifi-

zierungsprozess

Zertifizierte Hardware ist insbesondere für den produktiven Einsatzvon SAP HANA erforderlich. Die meisten SAP-Hardwarepartnerhaben bereits mehrere ihrer Server für den Einsatz mit SAP HANAvon SAP zertifizieren lassen. Im Zertifizierungsprozess werden dieHardwarebestandteile auf ihre Leistungsfähigkeit hin überprüft; diesbetrifft besonders die Geschwindigkeit der Prozessoren und Haupt-speicher sowie ihr Mengenverhältnis. Für ein BW-auf-HANA-Systembeträgt das notwendige Verhältnis z.B. 16 GB pro Prozessorkern beiNutzung eines 8-Kern-Prozessors. Zusätzlich wird die Geschwindig-keit der Netzwerkschnittstelle und der Festplatten in Betracht gezo-gen. Gegenwärtig werden nur Server mit Intel-Prozessoren unter-stützt. Server, die diesen Prozess erfolgreich durchlaufen haben,werden für den Kunden in der sogenannten Product AvailabilityMatrix (PAM) aufgelistet. Sie werden unterteilt in Server, die mitSUSE Linux Enterprise Server for SAP Applications oder mit Red HatEnterprise Linux betrieben werden. Einige hiervon unterstützenzudem die Virtualisierung über VMware vSphere auch für den pro-duktiven Betrieb.

Tailored Data

Center Integration

Eine Alternative ist die Tailored Data Center Integration. Dabei kön-nen Sie das Hardwarepaket, das üblicherweise in einer Appliance

Architektur von SAP HANA2

52

ausgeliefert wird, in Zusammenarbeit mit ihrem Hardwarepartnerindividuell zusammenstellen. Sie benötigen dazu weiterhin einenzertifizierten Server und eine zertifizierte Storage-Lösung. Einspa-rungen sind möglich, wenn Sie Teile davon bereits besitzen. Ihnenist dann der produktive Einsatz von SAP HANA auf dieser Hardwaregestattet. Anders als bei dem Appliance-Ansatz müssen Sie anschlie-ßend jedoch selbst die Installation und Konfiguration des Betriebs-systems und von SAP HANA vornehmen. Der verantwortliche Mitar-beiter benötigt dafür ein Zertifikat einer Schulung für SAP-HANA-Installationsadministratoren. Für Kunden, die bereits über leistungs-fähige und geeignete Hardware verfügen, kann dies dennoch einekostengünstige Alternative darstellen. Zunächst sollten Sie dazu dasTesttool im SAP-Hinweis 1943937 (http://service.sap.com/sap/sup-port/notes/1943937) ausführen. Dieses Tool überprüft die Bestand-teile des Servers und liefert ein erstes Urteil über dessen Eignung.Dabei werden insbesondere die Netzwerkanbindung und die Schnel-ligkeit der Storage-Lösung überprüft.

2.1.2 Cloud

SAP HANA kann sowohl zum Testen als auch für produktive Zweckein der Cloud betrieben werden. Auf Cloud-Angebote wird üblicher-weise zurückgegriffen, wenn auf eine kostengünstige Skalierung undmöglichst niedrige fixe IT-Kosten Wert gelegt wird. In den vergange-nen Jahren hat sich eine Vielzahl an Angeboten entwickelt.

Definition Die Cloud ist einer der aktuellen Technologietrends. Da dieser Mode-begriff oftmals falsch verwendet wird, möchten wir zunächst klären,was ein Cloud-Angebot ist. Das National Institute of Standards andTechnology (NIST) hat 2011 eine Definition erstellt (siehe http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf), die fürCloud-Dienste folgende Merkmale feststellt:

� Der Kunde kann Hardwareressourcen automatisch mieten, alsoohne menschliche Interaktion.

� Der Dienst ist im Netzwerk (meist im Internet) verfügbar.

� Virtuelle und physische Ressourcen des Anbieters werden zwi-schen Kunden aufgeteilt.

� Ressourcen können flexibel an den Kundenbedarf angepasst undskaliert werden, falls notwendig.

Hardware 2.1

53

� Die Last und Nutzung wird gemessen, um Transparenz für Kundenund Anbieter zu bieten.

Dienst und KanalZusammengefasst kann man bei einer Cloud von einem IT-Dienstsprechen, der über ein Netzwerk mehreren Kunden angeboten wird.Zu unterscheiden ist, welcher Dienst angeboten wird und über wel-chen Kanal dies passiert. Es werden meist die folgenden drei Typenunterschieden.

� Infrastructure as a Service (ITaaS) stellt dem Kunden lediglich sei-nen Teil der beim Anbieter verwalteten Hardware zur Verfügung.

� Platform as a Service (PaaS) erlaubt keinen direkten Zugriff auf dieHardware, aber das Hochladen und Betreiben von selbst entwi-ckelter Software. Die Interaktion erfolgt über vom Anbieter bereit-gestellte Tools.

� Software as a Service (SaaS) erlaubt ausschließlich die Nutzungeiner vom Anbieter bereitgestellten Anwendung, die der Anbieterauf eigenen Servern betreibt und über ein Netzwerk, meist dasInternet, verfügbar macht. Sämtliche Angebote von SAP imBereich HANA sind dieser Methode zuzuordnen.

Private Cloud/

Public Cloud

Es wird nach dem Kundenkreis eines Cloud-Angebots unterteilt.Wenn es exklusiv von nur einer Organisation genutzt wird, sprichtman von einer Private Cloud. In ihr sind die Kunden z.B. Unterneh-mensabteilungen oder einzelne Mitarbeiter. Der Anbieter kanndabei eine externe Firma oder die eigene IT-Abteilung sein. Steht dasAngebot stattdessen allen Organisationen offen, so ist es eine PublicCloud. Sobald der Anbieter eine externe Firma ist, gehen zusätzlichdie Haftung für Ausfälle, die Wartung und Betriebskosten auf sieüber. Dies sind typische Gründe für die Nutzung einer Cloud-Lösung. Die Definition der private Cloud trifft stattdessen auf zahl-reiche Produkte zu, die bereits vor der Schöpfung des Begriffs exis-tierten, angefangen bei einfachen Netzlaufwerken.

Von SAP bekannt sind neben den neuen HANA-basierten Angebotenauch das Cloud-basierte SAP Business ByDesign oder Lösungen dervon SAP zugekauften Firmen, wie z.B. SuccessFactors und Ariba.Unternehmen wie Amazon bieten unterdessen im Rahmen von Ama-zon Web Services (AWS) das Cloud-Hosting »gewöhnlicher« SAP-Anwendungen an.

Architektur von SAP HANA2

54

Cloud-Angebote Für SAP HANA gibt es eine Vielzahl von Cloud-Angeboten:

� SAP HANA One/Development EditionUm SAP HANA schnell und ohne Hardwareausgaben ausprobierenzu können, gibt es mehrere Cloud-Angebote. SAP HANA One isteine 60 GB große HANA-Instanz, die z.B. über Amazon Web Ser-vices genutzt werden kann. Gegenwärtig (November 2014) beläuftsich der Preis für die Nutzung auf etwa 3,50 €/h. Sie erhalten diekomplette Kontrolle über eine virtuelle Maschine mit einer vorin-stallierten HANA-Datenbank. Wenn Sie auf dieser eigene Anwen-dungen entwickeln, dürfen Sie diese anschließend auch produktiveinsetzen.

Dies gilt nicht für andere Anbieter der SAP HANA Cloud Develop-ment Edition. Diese variieren auch in der Dimensionierung derHardware, sind dafür aber oft preiswerter. Für den Einsatz im BW-auf-HANA-Umfeld sind diese Varianten zwar nicht geeignet, siekönnen aber einen ersten und preiswerten Eindruck von SAPHANA vermitteln.

� Trial-AngeboteEinige Angebote sind für einen begrenzten Zeitraum kostenloserhältlich. Gegenwärtig existieren Trial-Programme für die HANADevelopment Edition, BW-auf-HANA und SAP ERP auf HANA. Inder Regel funktionieren diese Angebote über Amazon Cloud,wobei geringe Kosten abhängig von der Nutzungsdauer entstehen.Dennoch sollten Sie diese sehr preiswerten Angebote nutzen, umeinen ersten Eindruck von der entsprechenden Lösung zu gewin-nen.

� SAP HANA Infrastructure, DB Services und App ServicesDas Angebot SAP HANA Infrastructure Services wird ebenfallsdurch Amazon Web Services bereitgestellt und bietet nur diegeeignete Hardware für den Betrieb von SAP HANA in der Cloud.Die Lizenz ist nicht im Preis enthalten, sie müssen also bereits übereine SAP-HANA-Lizenz verfügen. Dafür bieten die HANA-Cloud-Infrastructure-Systeme bis zu über 1 TB Hauptspeicher und unter-stützen Scale-out. Haben Sie keine eigene Lizenz, ist SAP HANADB Services geeignet, da hier bereits die Lizenz enthalten ist. SAPHANA App Services verfügt darüber hinaus noch über erweiterteWerkzeuge und Möglichkeiten für Anwendungsentwickler.

Hardware 2.1

55

� SAP HANA Cloud PlatformSAP HANA Cloud Platform kann nicht für den Betrieb von HANA-Systemen verwendet werden. Sie ist allein für die Entwicklungnativer SAP-HANA-Anwendungen gedacht. Dafür kann jeder SAP-Partner oder -Kunde einen Entwickler-Account erstellen und ganzohne Kosten ausprobieren. Für die kostenlose Trial-Version wer-den von SAP aus Kostengründen Server betrieben, auf die mehrereEntwickler gleichzeitig zugreifen. Aus diesem Grund sind ihreRechte deutlich eingeschränkt. Besonders das User Management,die Administration und das Monitoring können nicht ausgeführtwerden. Das Verwalten von Daten, die Entwicklung eigenerAnwendungen auf SAP HANA sowie die Modellierung von HANAViews ist jedoch problemlos möglich. Somit ist die Trial-Versionder SAP HANA Cloud Platform eine gute und kostenlose Möglich-keit, sich mit diesen Themen auseinanderzusetzen.

� SAP HANA Enterprise Cloud (HEC)Die SAP HANA Enterprise Cloud ist für den produktiven Betriebvon SAP-Anwendungen auf SAP HANA gedacht. Auch für denCloud-Betrieb von BW-auf-HANA ist sie die Standardlösung. Diedazu genutzten Server werden von SAP selbst oder von ausge-wählten Partnern weltweit angeboten. In diesem Angebot wirddie Software für Sie vollständig administriert und gewartet. EinSupportteam steht jederzeit zur Verfügung und über die Ausstat-tung der Datencenter wird eine Ausfallsicherheit garantiert. Damitist SAP HANA Enterprise Cloud die erste Wahl für Unternehmen,die die IT-Tätigkeiten vollständig auslagern möchten.

2.1.3 Scale-up/Scale-out

Jeder Datenbankserver reicht nach einiger Zeit an die Grenze seinerSpeicherkapazität. Wenn Sie dann nicht auf eine ReorganisationIhrer Daten oder eine Nearline Storage-Lösung zurückgreifen wollen(mehr Informationen hierzu finden Sie in Kapitel 8, »Nearline Sto-rage für SAP BW auf SAP HANA«), ist eine Nachrüstung von Hardwa-reressourcen erforderlich. Im Fall von SAP HANA bedeutet das denKauf von zusätzlichem Hauptspeicher und damit verbunden weite-ren Prozessoren sowie gegebenenfalls einen höheren Bedarf an Fest-plattenspeicher für Backups, Logs und Datenabbilder. Es existierenzwei Nachrüstungsmethoden: Scale-up und Scale-out.

Architektur von SAP HANA2

56

Scale-up Scale-upbedeutet die Aufrüstung des oder der bereits vorhandenenServer, ohne ihre Anzahl zu erhöhen. Hierfür werden die bereitsbestehenden Server aufgerüstet; viele zertifizierte HANA-Server sinddaher aus mehreren Blades aufgebaut. Ein Blade beinhaltet alle typi-schen Hardwarebestandteile und stellt somit eine Leistungseinheitdar. Die Nachrüstung erfolgt durch das Hinzufügen einer weiterenPlatine und erfordert deshalb keinen tiefen Eingriff in den Hardwa-reaufbau. Ein Scale-up ist nur bis zu den von SAP zertifizierten Gren-zen für diesen Server möglich. Diese liegen gegenwärtig oftmals bei2 oder 4 TB Hauptspeicher und 80 Prozessorkernen.

Scale-out Für größere Aufrüstungsprojekte wird ein Scale-out-Szenario durch-geführt. Dabei wird das bestehende System um weitere Serverergänzt. SAP HANA läuft nun auf mehreren Servern gleichzeitig. Indem dann entstehenden Server-Cluster existiert ein Masterserver,der die Koordination übernimmt und einige HANA-Prozesse fortanallein betreibt (wie XS Engine und Statistikserver). Er und die restli-chen Server verteilen ihre Last untereinander. Dies wird u.a.dadurch erreicht, dass Tabellen partitioniert werden; die Partitionenwerden anschließend auf die einzelnen Server verteilt. Berechnun-gen und Datenbankzugriffe erfolgen nun abhängig von den erforder-lichen Daten auf unterschiedlichen Cluster-Servern. Aus diesemGrund sollten die Daten nach dem Umsetzen eines Scale-out-Szena-rios über die Partitionierung zwischen den Servern verteilt werden(siehe Abschnitt 1.4.4, »Partitionierung«). Genauere Informationenzu der Vorgehensweise dazu finden Sie im SAP-Hinweis 1908075.

Optimale Anzahl der HANA-Server

Prinzipiell gilt, dass die Leistung eines einzelnen Servers die Leistungmehrerer verbundener Server mit gleicher Gesamthardware übertrifft, dakeine Kommunikation zwischen den miteinander verbundenen Servernüber das Netzwerk notwendig ist.

Beim Betrieb von SAP-Systemen kommt es jedoch häufiger zu dem Fall,dass mehrere Prozesse um dieselben Ressourcen konkurrieren. Der Ein-satz einer auf mehrere Server verteilten HANA-Datenbank kann dahersogar eine Beschleunigung bewirken. Für den Fall von SAP BW auf SAPHANA informiert darüber der SAP-Hinweis 1702409.

Zudem sollten Sie in Erwägung ziehen, einen oder mehrere Server zubetreiben, die im Notfall einen fortlaufenden Betrieb nach Ausfällenermöglichen. Oftmals werden hierfür auch Server der Entwicklungs- oderTestsysteme verwendet.

Hardware 2.1

57

Gemeinsamer

Datenzugriff

Beim Betrieb mehrerer Server müssen alle über einen gemeinsamenZugriff auf die Daten verfügen. Logs und Daten werden z.B. aufeinem gemeinsam genutzten Netzlaufwerk abgelegt oder zwischenden Servern ausgetauscht. Die Umsetzung dieser Szenarien ist Auf-gabe des Hardwarepartners.

Fällt einer der Server aus, müssen Maßnahmen für eine Wiederauf-nahme des Betriebs greifen. Dies behandeln wir im nächstenAbschnitt.

2.1.4 Hochverfügbarkeit/Datenverfügbarkeit

Ein Stromausfall führt bei Daten im Hauptspeicher zu einem voll-ständigen Datenverlust. Da SAP HANA die Daten im Hauptspeicherablegt, muss diesem Verlust für den Ernstfall vorgebeugt werden.Ein erster Schritt hierfür ist das permanente Anfertigen von Save-points, Logs und Backups, auf das wir in Abschnitt 6.3.2, »Festplat-ten«, eingehen. Darüber hinaus unterstützt HANA mehrere Techni-ken:

� MirroringMirroring ist das parallele Betreiben baugleicher Server, derenDatenbestände laufend angeglichen (gespiegelt) werden. Wennder primär genutzte Server ausfällt, erkennt der Spiegelserver diesund setzt den Betrieb reibungslos fort. Diese Methode ist diesicherste, jedoch auch die teuerste. Im Normalfall erfüllt der Spie-gelserver keinen Nutzen, es fallen jedoch erhebliche Kosten fürHardwareanschaffung und Betrieb an. Zudem sollten Sie beachten,dass sich ein Spiegelserver an einem anderen Ort befinden sollteals der Originalserver. Nur so kann verhindert werden, dass beideServer aus dem gleichen Grund (Überschwemmung, Stromausfall,Brand, etc.) betriebsunfähig sind.

� Cold StandbyIn einem HANA-Cluster kann einer der Server als Cold-Standby-Server genutzt werden. Dabei handelt es sich um einen inaktivenServer, der bei Ausfall eines anderen Servers automatisch dessenPlatz einnimmt. Um den Betrieb weiterführen zu können, mussdieser Server dazu zunächst die Daten im Hauptspeicher des aus-gefallenen Servers rekonstruieren. Im Gegensatz zu einem Spiegel-server kann dies nicht fortlaufend durchgeführt werden, da vorhernicht bekannt ist, welcher Server ausfallen wird.

Architektur von SAP HANA2

58

� Service Auto RestartDurch einen Softwarefehler oder fehlerhafte Konfiguration vonSAP HANA kann es zu einem ungeplanten Abbruch eines HANA-Prozesses kommen. In diesem Fall wird SAP HANA den Prozessumgehend erneut starten und den Ausgangszustand wiederher-stellen.

2.1.5 Hauptspeichermanagement

Der gesamte Hauptspeicher ist in Bereiche aufgeteilt, die jeweils voneinem bestimmten Prozessor verwaltet werden.

NUMA-Architektur Für die gemeinsame Nutzung von Hauptspeicher ist daher die Kom-munikation zwischen den Prozessoren notwendig. Auf einer Platinekönnen sich bei Verwendung der NUMA-Architektur (Non-UniformMemory Access) bis zu vier Prozessorsockel befinden, die überSchnittstellen miteinander verbunden sind. Für die optimale Leis-tung sind alle Prozessoren untereinander verbunden (siehe Abbil-dung 2.1).

Abbildung 2.1 NUMA-Architektur

Bei Platinen mit mehr als vier Prozessorsockeln ist es aufgrund deraktuellen Bauweise nicht mehr möglich, eine Schnittstelle zwischenallen Prozessoren untereinander zu verbauen. Möchte ein Prozes-sorkern auf Daten zugreifen, die einem anderen Prozessorkern zu-geordnet sind, müssen die Daten über mehrere Zwischenstationen

CPURAM

CPURAM

CPU

CPU

RAM

RAM

Hardware 2.1

59

transportiert werden. Im Schnitt ist daher der Zugriff auf den Haupt-speicher in diesem Fall weniger performant. Bisher setzen derartigeSysteme oftmals acht Prozessoren in Form von zwei untereinanderverbundenen NUMA-Architekturen ein.

Da durch diese Kommunikation mit wachsender Anzahl an Prozesso-ren und Sockeln zunehmend Zeit verloren geht, wird es in größerenSystemen immer wichtiger, die Berechnungen zu einem bestimmtenHauptspeicherbereich auf den entsprechend zugewiesenen Prozes-sor zu verweisen.

HANA-Haupt-

speicherpool

Üblicherweise wird die Speicherverwaltung vollständig durch dasBetriebssystem übernommen. Dieses hat jedoch keine Informatio-nen über den Aufbau und die Relevanz bzw. die Abhängigkeiten derDatenbanktabellen und ihrer Zwischenergebnisse. SAP HANA sollaußerdem die Berechnungen auf möglichst viele Prozessorkerne ver-teilen, um die Bearbeitungszeit möglichst kurz zu halten. Aus diesemGrund übernimmt SAP HANA das Hauptspeichermanagement voll-ständig. Dazu legt der Indexserver-Prozess von SAP HANA beimStart der Datenbank einen eigenen Hauptspeicherpool an. Dieserreserviert während des Betriebs Hauptspeicher für den Programm-code, Datenbanktabellen, temporäre Berechnungen und weitereinterne Prozesse, wie z.B. die Datenbankstatistiken. Wird der reser-vierte Speicher nicht mehr benötigt, verbleibt er im Hauptspeicher-pool und wird im Gegensatz zu anderen Anwendungen nicht wiederin die Kontrolle des Betriebssystems übergeben. Soll er darauf wie-der belegt werden, kann SAP HANA selbst entscheiden, welcheBereiche hierfür geeignet sind. Daher wird das Betriebssystem oft-mals eine höhere Hauptspeicherbelegung durch die SAP HANA-Pro-zesse vermelden, als tatsächlich besteht.

Abbildung 2.2 zeigt einen beispielhaften Aufbau des Arbeitsspei-cherpools. Der Speicher für Tabellen wird hier noch einmal unter-teilt in Colum Store für spalten- und Row Store für zeilenbasierteTabellen. Wie viel freier Speicher vorhanden ist und wie er zusam-mengesetzt ist, weiß nur SAP HANA; an das Betriebssystem wird nurdie Gesamtheit des durch den Indexserver belegten Hauptspeichersübermittelt.

Architektur von SAP HANA2

60

Abbildung 2.2 Aufbau des Hauptspeicherpools von SAP HANA

Global Allocation

Limit

Der Prozess der Speicherbelegung wird bis zu einer vordefiniertenGrenze, dem Global Allocation Limit, weiterbetrieben (siehe auchAbschnitt 6.4.1, »global.ini«). Wird über diese Grenze hinaus Haupt-speicher benötigt, so muss bereits belegter Speicher freigegebenwerden. Dafür werden Datenbanktabellen »entladen«, d.h., ausdem Hauptspeicher entfernt. Sie sind nun nur noch auf der Fest-platte verfügbar und profitieren somit nicht mehr von der Ge-schwindigkeit des Hauptspeichers. SAP HANA versucht in diesemFall, besonders lange nicht mehr verwendete Daten zu entladen,und ist auch in der Lage, nur Teile von Tabellen aus dem Hauptspei-cher zu entfernen. Zudem ist es möglich, Tabellen vorzudefinieren,die in einem solchen Fall zuerst entladen werden sollen. In einemBW-System betrifft dies vorwiegend Daten aus PSA-Tabellen undschreiboptimierten DSO, die im Regelbetrieb nicht zur Auswertungoder der Durchführung von Analysen herangezogen werden (sieheAbschnitt 5.6, »Das Konzept nicht aktiver Daten (Hot/Warm/Cold)«).Im Idealfall kommt es durch eine ausreichende Dimensionierungder Hardware nicht zum Entladen von Tabellen. Ausnahmen stellenbesonders hauptspeicherintensive Aktivitäten, wie z.B. Datenbank-updates, dar. Dies ist ein typisches Beispiel für eine der vielen Opti-mierungen, die SAP in Zusammenarbeit mit verschiedenen Hard-warepartnern erarbeitet hat.

Hauptspeicher-

größen

Während eine Hauptspeicherknappheit schnell erkannt werdenkann, ist es sehr schwierig, die tatsächliche Hauptspeicherbelegungvon SAP HANA festzustellen. Dazu werden wir etwas detaillierter

Freier Speicher

Row StoreColumn Store

Programm-code

TemporäreBerechnungen

Datenbank-management

Hardware 2.1

61

auf das Hauptspeichermanagement eingehen. Abbildung 2.3 zeigteinige Hauptspeichergrößen im Verlauf des Datenbankbetriebs.

Abbildung 2.3 Hauptspeichergrößen von SAP HANA im Zeitverlauf (aus »SAP HANA Memory Usage Explained«, http://www.saphana.com/docs/DOC-2299, S. 10)

Wenn die Laufzeitumgebung von SAP HANA Hauptspeicher benö-tigt, wird eine Anfrage an das Betriebssystem geschickt und derjeweilige HANA-Prozess erhält Virtual Memory (virtuellen Speicher).Dieser ist noch keiner konkreten Stelle im Hauptspeicher zugeord-net, aber berechtigt SAP HANA im weiteren Programmverlauf zumtatsächlichen Belegen von Hauptspeicher. Wenn dieser Speicherdann physisch mit Daten gefüllt wird, spricht man von ResidentMemory (residentem Speicher). Dieser ist einem Hauptspeicherbe-reich zugeordnet und kann fortan von dem Prozess genutzt werden.Entsprechend ergibt sich eine Differenz zwischen Virtual Memoryund Resident Memory, die sich aus dem reservierten, aber nochnicht genutzten Hauptspeicher ergibt.

Unter Used Memory (verwendetem Speicher) versteht SAP HANA dieMenge an tatsächlich von Programmcode, Tabellen, temporärenBerechnungen und dem vom Datenbankmanagement reservierten(aber nicht notwendigerweise schon belegten) Speicher. Die Diffe-renz zu dem vom Betriebssystem reservierten Speicher (dem VirtualMemory) ist der freie Speicher des Hauptspeicherpools. WurdeHauptspeicher bereits reserviert und danach nicht mehr benötigt,verbleibt er trotzdem im residenten Speicher und ist somit Teil die-ses Pools. Der Used Memory kann somit größer oder kleiner sein alsder Resident Memory.

Architektur von SAP HANA2

62

Für die Hauptspeicherbelegung ist Used Memory die ausschlagge-bende Größe. Er darf das vordefinierte Hauptspeicherlimit nichtüberschreiten.

2.2 Software

Die Dimensionierung der Hardware sowie die Datenbankinnovatio-nen in SAP HANA entfalten ihr Potenzial besonders durch auf sieausgelegte Software. Bestehende Produkte wie SAP BW wurden hier-für angepasst. Zudem entsteht ein ganzes Produktportfolio von nati-ven HANA-Anwendungen. Wir möchten uns nun der Frage widmen,wie diese gemeinsam betrieben werden können.

Das ursprüngliche Betriebskonzept von SAP HANA sah einen dedi-zierten, also alleinigen, Betrieb der Datenbank auf dem Server vor.Die Verwendung mehrerer Anwendungen auf einer HANA App-liance oder mehrerer Datenbanken auf einem Server war für Produk-tivsysteme nicht freigegeben. Inzwischen sind die Regelungen deut-lich flexibler und entwickeln sich stetig weiter. Wir können dahernur eine Momentaufnahme bieten, die deutlich macht, welchezusätzlichen Möglichkeiten eröffnet werden und wo Sie sich zu denentsprechenden Themen informieren können.

2.2.1 SAP HANA und andere Anwendungen

Multiple

Components One

Database

Wenn Sie eine HANA-Datenbank im Unternehmen einsetzen, kön-nen Sie diese für unterschiedliche Zwecke gleichzeitig einsetzen. SAPnennt dieses Prinzip Multiple Components One Database (MCOD).Dies gilt jedoch nicht für jede denkbare Kombination, deshalb hatSAP eine ständig aktualisierte Whitelist veröffentlicht, die jedeerlaubte Kombination aufzählt. Sie können sie im SAP-Hinweis1661202 finden. Bedenken Sie dabei, dass der parallele Einsatz vonmehreren Anwendungen auf SAP HANA in der Planung des Ressour-cenbedarfs mit berücksichtigt werden muss. Diese Informationenwerden durch den SAP-Hinweis 1666670 ergänzt, der sich u.a. mitder Frage auseinandersetzt, ob mehrere BW-Systeme dieselbe SAP-HANA-Datenbank nutzen dürfen. Gegenwärtig ist dies nur für Test-und Entwicklungssysteme möglich, für Produktivsysteme aber aus-drücklich nicht erlaubt. In Abbildung 2.4 stellen wir diese Szenarienrechts oben und links unten dar.

Software 2.2

63

Paralleler BetriebEine weitere Möglichkeit ist der parallele Betrieb mehrerer SAP-HANA-Datenbanken auf demselben Server. Jede Installation einerSAP-Software wird in der Regel durch eine dreistellige sogenannteSID identifiziert. Dieses Szenario wird daher Multi-SID genannt. DerSAP-Hinweis 1681092 sagt gegenwärtig aus, dass Multi-SID-Szena-rien nur für Test- und Entwicklungssysteme zugelassen sind. InAbbildung 2.4 stellen wir dieses Szenario links oben dar. Eine Aus-nahme stellt die Umsetzung über virtuelle Maschinen dar, die wir inAbschnitt 2.2.2, »HANA in virtuellen Maschinen«, behandeln. InAbbildung 2.4 stellen wir dieses Szenario rechts unten dar.

Abbildung 2.4 Betrieb mehrerer Anwendungen auf einer Appliance

Einige Kunden setzen externe Produkte wie Backup- oder Monito-ring-Software sowie Antivirenprodukte ein. Auch diese unterliegenBeschränkungen, auf die der SAP-Hinweis 1730928 näher eingeht.

In Abbildung 2.4 sehen Sie eine Zusammenfassung der unterschied-lichen Szenarien. Bitte beachten Sie, dass sich diese Bedingungen imVerlauf der Zeit ändern können. Wenn Sie sich näher mit einerMethode auseinandersetzen wollen, sollten Sie daher unbedingt vor-her die bereits erwähnten SAP-Hinweise zurate ziehen.

2.2.2 HANA in virtuellen Maschinen

VirtualisierungEine Virtualisierungssoftware teilt die ihr zur Verfügung stehendeHardware für mehrere Systeme und Programme auf. Entsprechend

Appliance

HANA

Test /Entwicklung Produktiv

HANAHANA HANA

HANA HANA

BW

BW

Whitelist

BW

BeliebigesSystem

BW

BW

BW

Appliance

Appliance

Appliance

Mul

ti-BW

Mul

ti-SI

D MCOD

VM

Architektur von SAP HANA2

64

können mehrere Programme bzw. Systeme auf einer Hardware voll-ständig unabhängig voneinander gleichzeitig arbeiten. Die Virtuali-sierung ist daher eine Alternative zum normalen Betrieb mehrererAnwendungen oder zu Multi-SID-Installationen mit SAP HANA.

Es gibt zwei grundlegend unterschiedliche Ansätze der Virtualisie-rung, die wir für diesen Zweck betrachten möchten: Hardwarevirtua-lisierung und Betriebssystemvirtualisierung.

Hardwarevirtualisierung

Hypervisor Bei einer Hardwarevirtualisierung übernimmt eine Hypervisor oderVirtual Machine Monitor (VMM) genannte Komponente die Steue-rung und Aufteilung der Ressourcen. Abhängig von dem Server kannein Hypervisor schon vorinstalliert sein. Stellen Sie sich einen Hyper-visor als eine Art vorgeschaltetes Betriebssystem vor: Er allein kannauf die Hardware zugreifen und ermöglicht eine Überwachung undAdministrierung des Systems. Nach seiner Installation können Siemit ihm virtuelle Maschinen definieren, die eigene (Gast-)Betriebs-systeme enthalten. Anschließend ist ein vollständig unabhängigerBetrieb der virtuellen Maschinen gewährleistet.

Die CPU muss währenddessen zwischen den Prozessen der unter-schiedlichen virtuellen Maschinen unterscheiden können. Anstattdies über den Hypervisor abzuwickeln, haben AMD mit Pacifica undIntel mit Vanderpool spezielle Befehlssätze entwickelt, die von denGastsystemen ohne Umweg angesprochen werden können.

Vorteile Das Ergebnis ist eine durch unterschiedliche Betriebssysteme kom-plett voneinander abgegrenzte Umgebung. Hardwarezugriffe findendabei direkt und damit sehr performant statt. Zu den bekanntestenHypervisors zählen XEN (Citrix), KVM (Red Hat) und vSphere(VMware).

Wichtige

SAP-Hinweise

Der SAP-Hinweis 1788665 beschäftigt sich mit diesem Thema undwird fortlaufend aktualisiert. Gegenwärtig wird nur die Verwendungvon VMware vSphere zum Betrieb von SAP HANA in virtuellenMaschinen unterstützt. Hierfür muss weiterhin ein zertifizierter SAP-HANA-Server oder ein nach der SAP-HANA-Tailored-Data-Center-Integration verifizierter Server verwendet werden. In diesem Fallwird aber auch der Produktivbetrieb unterstützt. Wenn Sie dieses

Software 2.2

65

Szenario in Erwägung ziehen, sollten Sie zudem den SAP-Hinweis1995460 in Betracht ziehen. Er geht auf alle Einschränkungen undwichtigen Dokumente und Tipps ein, die für die Einrichtung der vir-tuellen Maschinen erforderlich sind. Generell wird gegenwärtig überdie Möglichkeit, mehrere SAP-HANA-Datenbanken gleichzeitig ineiner virtuellen Maschine zu betreiben, noch individuell entschie-den.

Betriebssystemvirtualisierung

Einen anderen Ansatz verfolgt die Betriebssystemvirtualisierung.Hierbei stellt ein normal installiertes Betriebssystem mehrere Gast-instanzen von sich zur Verfügung, die in voneinander getrenntenUmgebungen ausgeführt werden (Container).

Der produktive Betrieb von SAP HANA in einem solchen Containerwird gegenwärtig nicht unterstützt. Für Test- und Entwicklungssys-teme kann dieses Szenario jedoch verwendet werden.

Bei dieser Methode wird tatsächlich nur ein Betriebssystem ausge-führt, das in der Regel ein Abbild der tatsächlichen Hardware simu-liert. Diese kann demnach direkter angesprochen werden, und insge-samt ergibt sich ein Overhead, der nur 1 % betragen kann. Auch derAufwand zur Einrichtung eines Containers zur Virtualisierung istgeringer gegenüber der Hardwarevirtualisierung.

ContainerDie Container nutzen eigene Anwendungen, Benutzer, Dienste undVerzeichnisse, diese können aber auch vom Betriebssystem vererbtwerden. Intern gruppiert das Mutterbetriebssystem hierfür die aus-geführten Prozesse der Container. Diese sogenannten Kernel ControlGroups können sehr detailliert überwacht und administriert werden.So ist z.B. die Beschränkung auf konkrete Hauptspeicherbereicheoder CPU-Kerne möglich.

2.2.3 Betriebssystem

Ein Teil der SAP HANA Appliance ist das Betriebssystem. Für denoptimalen Betrieb war bisher nur die Verwendung von SUSE LinuxEnterprise Server for SAP Applications zulässig. Inzwischen wurdedie Auswahl für einige zertifizierte Server um Red Hat EnterpriseLinux Server erweitert. Für beide Betriebssysteme gelten einigegesonderte Regelungen, auf die wir zuerst eingehen werden.

Architektur von SAP HANA2

66

SUSE Linux Enterprise Server for SAP Applications

Die deutsche Firma SUSE Linux veröffentlicht zusätzlich zu ihremServerbetriebssystem eine für SAP angepasste Version, deren Paketezu SAP-Anwendungen kompatibel sind. Sie verfügt zusätzlich überdie firmeneigene Hochverfügbarkeitslösung (High Availability Exten-sion), einen Installationsassistenten für SAP-Anwendungen undzudem einen auf SAP-Kunden zugeschnittenen Support.

Für den Betrieb von SAP HANA auf diesem Betriebssystem gelteneigene Empfehlungen, die in dem SAP-Hinweis 1944799 zusammen-gefasst sind. Er umfasst die Auswahl der Softwarepakete sowieAnweisungen zu Wartung und Support des Betriebssystems.

Red Hat Enterprise Linux Server

Red Hat Enterprise Linux Server wird von der Firma Red Hat entwi-ckelt und ist Marktführer für Linux-Betriebssysteme auf Servern imUnternehmensbereich. Ihre Produkte sind besonders stark im US-amerikanischen Raum vertreten. Da es erst nach dem SUSE-Betriebs-system für SAP HANA zugelassen wurde, ist die Anzahl der mit RedHat angebotenen SAP HANA Appliances noch gering.

Anpassungen Für den Einsatz von SAP HANA auf Red Hat müssen Sie zunächsteinige Anpassungen vornehmen, die einen optimalen Betrieb sicher-stellen. Alle notwendigen Schritte hat SAP im SAP-Hinweis 2013638zusammengefasst. Für SUSE Linux Enterprise Server for SAP Appli-cations sind diese Schritte nicht notwendig, da es für den Betrieb vonSAP-Applikationen bereits entsprechend angepasst wurde.

Allgemeine Hinweise

Für beide Betriebssysteme sind neue Versionen der installierten Soft-warepakete notwendig, wenn SAP HANA ab Version 80 eingesetztwerden soll. Eine Liste der entsprechenden Änderungen finden Siein SAP-Hinweis 2001528.

Konfigurations-

änderungen

Jede Konfigurationsänderung am Betriebssystem sollte vorher aufihre eventuellen Auswirkungen auf den Betrieb von SAP HANAüberprüft werden. Allgemeine Anweisungen für Konfigurationsän-derungen finden Sie im SAP-Hinweis 1730999. Eine Blacklist mituntersagten Konfigurationsänderungen wird getrennt geführt im

SAP-HANA-Prozesse 2.3

67

SAP-Hinweis 1731000. Wir empfehlen, die Hinweise von SAP zumBetriebssystem in jedem Fall ernst zu nehmen, da eine fehlerhafteKonfiguration oder nicht kompatible Softwarepakete zu einemunvorhergesehenen Verhalten von SAP HANA führen können. Oft-mals sind Ihnen in diesem Fall die Ursachen nicht mehr bekannt undverantwortliche Personen suchen anschließend den Fehler aus-schließlich in der Datenbank.

2.3 SAP-HANA-Prozesse

Die Aufgaben von SAP HANA werden durch mehrere Prozesseumgesetzt. Über das Betriebssystem oder das SAP HANA Studio kön-nen Sie sowohl die Ressourcenauslastung als auch eventuelle Fehler-quellen dieser Prozesse überwachen (Abschnitt 6.3, »Monitoring«).

In diesem Abschnitt werden wir daher auf die Aufgaben der einzel-nen Prozesse eingehen. Zudem werden wir auf die innere Funktions-weise des besonders wichtigen Indexserver-Prozesses eingehen.

� IndexserverDer Indexserver ist das Herzstück von SAP HANA. Er enthält undverarbeitet alle Daten der Datenbank und belegt daher auch einenerheblichen Teil des Hauptspeichers. Berechnungen werden jenach Art von unterschiedlichen sogenannten Engines durchge-führt. Eine Ausnahme ist die Analyse von Textdaten, die im Pre-processor-Prozess durchgeführt wird. Auf die Funktionsweise desIndexservers gehen wir in Abschnitt 2.3.1, »Indexserver imDetail«, ein. Den HANA Engines haben wir einen eigenenAbschnitt gewidmet (siehe Abschnitt 2.3.2).

� Statistics ServerDer Statistikserver erfasst während des Betriebs von SAP HANAeine Vielzahl an Leistungs- und Hardwaredaten. Im Verlauf lassensich dadurch Schwachstellen oder Leistungsspitzen erkennen(siehe Abschnitt 6.3, »Monitoring«). Die Aufgaben des Statistikser-vers können ab HANA Revision 70 von dem Nameserver über-nommen werden (siehe Abschnitt 6.4.3, »statisticsserver.ini undnameserver.ini«).

In einem HANA-Cluster läuft der Statistikserver nur auf einemHost.

Architektur von SAP HANA2

68

� NameserverDer Nameserver ist für den Betrieb eines HANA-Clusters notwen-dig. Er kennt alle HANA-Server und die von ihnen verwaltetenDaten.

� Preprocessor ServerHANA verfügt über die Fähigkeit, Texte sprachlich und inhaltlichauszuwerten. Dazu gehört auch die Analyse von positiven odernegativen Stimmungen in den Texten (Sentiment Analysis). Dieskann z.B. für die Interpretation großer Mengen von Texten aussozialen Medien genutzt werden. Der Preprocessor führt dieseAnalyse durch.

� XS EngineDie XS Engine (XS = Extended Application Services) verwaltet undbetreibt native HANA-Anwendungen, die in JavaScript entwickeltwerden können (XSJS). Auch SAP nutzt diese Möglichkeit. Kom-ponenten zur Administration und zum Monitoring von HANAwerden zunehmend auf XS umgesetzt. Auch ganze SAP-Anwen-dungen, wie z.B. Operational Process Intelligence, werden in XSentwickelt und betrieben. Der Betrieb von SAPUI5-Anwendungensowie die Einrichtung von ODATA-Schnittstellen zur Anwen-dungsentwicklung geschieht ebenfalls über XS.

In einem HANA-Cluster läuft die XS Engine nur auf einem Host.

2.3.1 Indexserver im Detail

Der Indexserver ist der zentrale HANA-Prozess. Alle reinen Daten-banktätigkeiten werden in ihm durchgeführt. Entsprechend ist seinAufbau komplex und nur im Ansatz für die Öffentlichkeit dokumen-tiert. Wir möchten uns im Folgenden daher mit den Aufgaben desIndexservers beschäftigen und einen groben Überblick geben, wiediese von ihm ausgeführt werden.

Datenbankzugriffe

Authentifizierung

und Rechte-

management

Anwendungen, SAP-Systeme und technische wie menschliche Nut-zer verbinden sich ständig mit SAP HANA, um Operationen auszu-führen. Der Indexserver sorgt für das Management der Sitzungen.Dies betrifft insbesondere die Authentifizierung während des An-

SAP-HANA-Prozesse 2.3

69

meldeprozesses und das Rechtemanagement bestehender Daten-bankverbindungen. Auf das Rechtemanagement gehen wir in Ab-schnitt 6.2, »Benutzer- und Berechtigungsverwaltung«, näher ein.Die Authentifizierung kann auch von externen Systemen übernom-men werden (Kerberos, SAML-basierte Identity-Provider). In diesemFall stellt der Indexserver die Kommunikation mit diesen Systemensicher. Auch eine verschlüsselte Kommunikation über HTTPS kanneingerichtet werden.

Verwaltung von Datenbankobjekten

MetadatenAlle Tabellen, HANA Views, Datenbank-Views, Prozeduren, Ent-wicklungsobjekte, Schemata und sonstige Datenbankbestandteilewerden vom Indexserver verwaltet. Dies bedeutet u.a., dass er sämt-liche Metadaten vorhält. Metadaten sind z.B. die Struktur, dieBerechtigungen, Namen und Beschreibungen sowie auszuführenderCode.

Verwaltung der gespeicherten Daten

Row und Column

Store

In SAP HANA können Daten spaltenbasiert und zeilenbasiert gespei-chert werden. Die technische Umsetzung geschieht durch die beidenIndexserver-Komponenten Row Store und Column Store. Auch dieSpeicherung von Daten zur Wiederherstellung auf der Festplattewird durch den Indexserver organisiert. Mehr zur Funktionsweisedes Column Stores erfahren Sie in Abschnitt 1.4.3, »Insert-Only-Ver-fahren«.

Ausführung von SQL-Befehlen

EnginesIn der Regel werden Lese- und Schreiboperationen in SAP HANAüber SQL übermittelt. Bei Eingang einer SQL-Anweisung wird diesezunächst analysiert und an die entsprechende Komponente desIndexservers weitergeleitet. So werden z.B. Prozeduren von einereigenen Komponente bearbeitet, und spezielle SQL-Befehle der Plan-ning Engine werden an eine entsprechende Planungskomponenteweitergeleitet. Diese Komponenten werden Engines genannt. Sieübernehmen die eigentliche Bearbeitung der Anweisungen. FürBerechnungen in HANA Views (siehe Abschnitt 5.2, »Entwicklungs-

Architektur von SAP HANA2

70

und Modellierungsumgebung im SAP HANA Studio«) wird ebenfallseine eigene Engine verwendet, die Calculation Engine.

Die Ausführung der Befehle durchläuft mehrere Schritte und wird inder SQL Engine durchgeführt. Auf SQL und Calculation Enginegehen wir im nun folgenden Abschnitt näher ein.

2.3.2 HANA Engines

Die eigentliche Ausführung der Datenoperationen in SAP HANAerfolgt in sogenannten Engines. Jede Berechnungsart wird durcheine eigene Engine abgebildet. Auf einige davon möchten wir nuneingehen, um Ihnen einen tieferen Einblick in die Arbeitsweise vonSAP HANA zu geben.

Calculation Engine

Die Calculation Engine wird z.B. von SQL-Skripten oder CalculationViews genutzt. In Abschnitt 5.2, »Entwicklungs- und Modellierungs-umgebung im SAP HANA Studio«, gehen wir auf die Modellierungvon Calculation Views ein. In Calculation Views ist es sogar möglich,direkt Funktionen der Calculation Engine auszuführen. Bei ausrei-chender Kenntnis der HANA Architektur und der Engine-Perfor-mance kann dies zu schnelleren Auswertungen führen.

Application

Function Libraries

Ein Bestandteil der Calculation Engine sind sogenannte ApplicationFunction Libraries. Diese enthalten in C++ geschriebene Funktionen,auf die die Calculation Engine direkt zugreifen kann. Sie könnenjedoch nicht manuell entwickelt werden. Bekannte Beispiele sind diePredictive Analysis Library, die Funktionen für die Entwicklung vonVorhersagemodellen enthält, und die Business Function Library, dieFunktionen für Finanzberechnungen enthält.

Die Funktionen der Application Function Libraries können über spe-zielle SQL-Befehle genutzt werden oder über von SAP vordefinierteFunktionen. So können Sie z.B., wie in Abbildung 2.5 gezeigt, ineinem BW-auf-HANA-System über SAP HANA Analysis Process mitder Predictive Analysis Library eigene Prozesse einrichten undanschließend deren Ausführung in Prozessketten einplanen. Somitkönnen Sie die Vorteile der Calculation Engine ohne genauere tech-nische Kenntnis aus dem BW-System heraus nutzen.

SAP-HANA-Prozesse 2.3

71

Abbildung 2.5 Definition eines HANA Analysis Process

SQL Engine

OptimizerSQL-Befehle zum Lesen oder Schreiben von Daten werden vor ihrerAusführung von einer Optimizer genannten Komponente aufberei-tet. Hier werden Berechnungsschritte so angepasst, dass sie mög-lichst performant ausgeführt werden können. Dies bezieht sich z.B.auf die Behandlung von Zwischenergebnissen, das Zusammenführenvon Daten aus mehreren Tabellen oder das Suchen innerhalb vonTabellen.

Zusätzlich wird gewährleistet, dass das parallele Lesen und Schreibenauf denselben Tabellen nicht zu unterschiedlichen und entsprechendinkonsistenten Ergebnissen führt. Der optimierte Befehl wirdanschließend ausgeführt, wobei auf den Row Store und ColumnStore der entsprechenden Tabellen zugegriffen wird.

SQL Engine für SAP HANA Calculation Views

Bei der Modellierung von Calculation Views ist es möglich, die Ausfüh-rung nicht von der Calculation Engine, sondern von der SQL Enginedurchführen zu lassen.

Dies kann eine deutlich schnellere Ausführung bewirken, da die SQLEngine Befehlsketten stärker optimiert. Bei der Wahl der SQL Engine gibtes jedoch einige Einschränkungen zu beachten. So dürfen z.B. keine Ana-lytical Views, Attribute Views oder Calculation Views mit SQL-Skript als

Architektur von SAP HANA2

72

Datenquelle eingesetzt werden. Alle zu beachtenden Einschränkungenerfahren Sie im SAP HANA Modeling Guide unter help.sap.com/hana_platform.

Join Engine

Daten zusammen-

führen

Die einzige Aufgabe der Join Engine ist das Zusammenführen vonDaten aus mehreren Tabellen. Sie wird von Attribute Views verwen-det. Auch die Calculation Engine bietet eine Methode für Joins vonTabellen. Um zu verstehen, warum das notwendig ist, ist es wichtig,den Ressourcenverbrauch der Engines zu kennen. Wenn mehrereEngines denselben Befehl bearbeiten, dann ist ein Datenaustauschzwischen ihnen notwendig. Besonders bei HANA Views ist die Per-formance sehr unterschiedlich, wenn Sie nur eine statt mehrereHANA Engines einsetzen.

OLAP Engine

Die OLAP Engine wird von Analytical Views und InfoCubes aus demSAP-BW-System verwendet. Sie ist auf die Architektur des Sternsche-mas (siehe Abschnitt 1.2.2, »Nachteile relationaler Datenbanken«)ausgerichtet und verfügt wiederum über einen eigenen Optimizer.Ihr Vorteil liegt insbesondere in der schnellen Ausführung analyti-scher Berechnungen durch die parallele Durchführung von Aggrega-tionen.

7

Inhalt

Einleitung .................................................................................. 11

1 Einführung in SAP BW auf SAP HANA .................... 17

1.1 Einordnung und Abgrenzung des Implemen-tierungsszenarios »SAP BW auf SAP HANA« ............ 171.1.1 Side-by-Side- und integrierte Ansätze ........ 191.1.2 Operational Analytics ................................ 23

1.2 Aktuelle Herausforderungen für SAP BW ................ 251.2.1 Wandel der Rahmenbedingungen .............. 251.2.2 Nachteile relationaler Datenbanken ........... 261.2.3 Verteilte Datenhaltung .............................. 29

1.3 Beweggründe für die Migration eines BW-Systems auf SAP HANA ........................................................ 301.3.1 SAP-BW-Restriktionen .............................. 301.3.2 Vorteile von BW-auf-HANA ....................... 33

1.4 Technische Grundlagen: Warum ist SAP HANA so schnell? .............................................................. 371.4.1 In-Memory-Technologie ............................ 381.4.2 Spaltenbasierte Datenhaltung und

Komprimierung ......................................... 401.4.3 Insert-Only-Verfahren ............................... 421.4.4 Partitionierung .......................................... 431.4.5 Push-down-Prinzip .................................... 45

1.5 Fazit ....................................................................... 47

2 Architektur von SAP HANA ..................................... 49

2.1 Hardware ................................................................ 502.1.1 Zertifizierung ............................................. 512.1.2 Cloud ........................................................ 522.1.3 Scale-up/Scale-out .................................... 552.1.4 Hochverfügbarkeit/Datenverfügbarkeit ...... 572.1.5 Hauptspeichermanagement ....................... 58

2.2 Software ................................................................. 622.2.1 SAP HANA und andere Anwendungen ...... 622.2.2 HANA in virtuellen Maschinen .................. 63

Inhalt

8

2.2.3 Betriebssystem ........................................... 652.3 SAP-HANA-Prozesse ............................................... 67

2.3.1 Indexserver im Detail ................................. 682.3.2 HANA Engines ........................................... 70

3 Migration eines bestehenden SAP-BW-Systems auf SAP HANA ......................................................... 73

3.1 Migrationsszenarien ................................................ 733.1.1 Neuinstallation ........................................... 763.1.2 Manuelle Migration ................................... 853.1.3 Migrationsoptionen: Database Migration

Option (DMO) und Post Copy Automa-tion (PCA) .................................................. 90

3.1.4 Rapid Deployment Solutions ...................... 1013.2 Technische Voraussetzungen für die Migration ........ 1043.3 Vorbereitungsmaßnahmen ....................................... 110

3.3.1 Homogene Systemkopie erstellen ............... 1103.3.2 Bereinigungsaktivitäten (BW Housekeeping) 1143.3.3 Größenanforderungen bestimmen und

prüfen ........................................................ 1293.3.4 Systemvalidierung im Vorfeld ..................... 1413.3.5 Weitere Werkzeuge ................................... 146

3.4 BW-auf-HANA-Migration ........................................ 1523.4.1 Exportvorbereitungen ................................ 1543.4.2 Exportphase ............................................... 1593.4.3 Importvorbereitungen ................................ 1683.4.4 Importphase .............................................. 169

3.5 Maßnahmen nach der Migration ............................. 1773.5.1 Allgemeine Nacharbeiten ........................... 1783.5.2 BW-spezifische Nacharbeiten ..................... 1803.5.3 Inkonsistenzen erkennen und beheben ...... 1813.5.4 BW-auf-HANA spezifische Nacharbeiten .... 1863.5.5 Abschließende Maßnahmen ....................... 188

4 Tipps und Tricks zur Migration von SAP BW auf SAP HANA ......................................................... 191

4.1 Generelle Empfehlungen ......................................... 191

Inhalt

9

4.2 Proof of Concept .................................................... 2014.3 Migration einer BW-Systemlandschaft .................... 208

5 Neuerungen in der BW-Datenmodellierung ........... 223

5.1 Besonderheiten in der Datenmodellierung für BW-auf-HANA ........................................................ 2245.1.1 Optimierte Konzepte für BW-auf-HANA .... 2245.1.2 Neue Funktionalitäten mit BW-auf-HANA 2285.1.3 Auswirkungen von BW-auf-HANA auf

die ABAP-Entwicklung ............................... 2455.2 Entwicklungs- und Modellierungsumgebung

im SAP HANA Studio .............................................. 2485.2.1 BW Modeling Tools ................................... 2485.2.2 Modellierung von SAP HANA Views

im SAP HANA Studio ................................. 2575.3 SAP-HANA-optimierte InfoCubes ........................... 2675.4 Vereinfachung in den Prozessketten ........................ 2765.5 Layered Scalable Architecture ++ (LSA++) ............... 281

5.5.1 Konsistenter EDW-Kern einer LSA++ ......... 2885.5.2 Open Operational Data Store Layer ........... 2965.5.3 BW Virtual Data Mart Layer ...................... 3115.5.4 Vorteile der LSA++-Architektur ................. 312

5.6 Das Konzept nicht aktiver Daten (Hot/Warm/Cold) 3145.7 SAP-HANA-Datenmodelle in SAP BW konsumieren 3225.8 Planning Application Kit ......................................... 335

6 Administration mit dem SAP HANA Studio ............ 343

6.1 Administrationsperspektive ..................................... 3466.1.1 Der Systems View ...................................... 3466.1.2 Der Administration Editor .......................... 348

6.2 Benutzer- und Berechtigungsverwaltung ................. 3506.2.1 Anlegen und Verwalten von Benutzern ...... 3516.2.2 Anlegen und Verwalten von Rollen ............ 355

6.3 Monitoring ............................................................. 3566.3.1 Hauptspeicher und CPU ............................ 3576.3.2 Festplatten ................................................ 3636.3.3 Datenbank-Performance ............................ 3666.3.4 Historische Performance-Daten ................. 367

Inhalt

10

6.3.5 Fehlersuche ................................................ 3706.4 Datenbankkonfiguration .......................................... 376

6.4.1 global.ini .................................................... 3776.4.2 indexserver.ini ............................................ 3806.4.3 statisticsserver.ini und nameserver.ini ......... 3806.4.4 xsengine.ini ................................................ 3816.4.5 filter.ini ...................................................... 3826.4.6 Backups erstellen und wiederherstellen ...... 382

7 Reporting mit SAP BW auf SAP HANA ................... 385

7.1 Trends im Reporting durch SAP BW auf HANA ........ 3857.2 SAP BusinessObjects Business Intelligence als

Reporting-Plattform ................................................ 3907.2.1 Serverkomponenten ................................... 3907.2.2 Client-Tools ............................................... 4057.2.3 Fazit zum Reporting mit SAP-BW-auf-HANA 435

8 Nearline Storage für SAP BW auf SAP HANA ......... 437

8.1 Anbinden des Nearline-Storage-Systems an BW ...... 4408.2 Datenarchivierung ................................................... 443

9 Ausblick – die Zukunft des BW-Reportings ........... 453

9.1 SAP HANA Live für das operationale Reporting ....... 4549.2 Gründe für die Notwendigkeit von SAP BW ............. 460

Anhang

A Anhang .............................................................................. 465A.1 Abkürzungsverzeichnis ............................................ 465A.2 Verwendete SAP-Hinweise ...................................... 468A.3 Verwendete ABAP-Reports ...................................... 472A.4 Wichtige Transaktionen ........................................... 473A.5 Wichtige Views ....................................................... 475A.6 SQL-Statements ...................................................... 475

B Die Autoren ....................................................................... 479

Index ......................................................................................... 481

481

Index

A

ABABVARCHARMODE 219ABAP, SAP-HANA-Prozedur 246ABAP-Entwicklung 224

für BW-auf-HANA 245Performance-Tipps 246

ABAP-Report, Übersicht 472ABAP-Routinen-Analyzer 146, 247Abkürzungsverzeichnis 465abschließendes Leerzeichen 219Administration Console 345Administration Editor 359Administrationsaufwand 32, 35Administrationsperspektive 346AFL � Application Function LibraryAggregat 124Aggregation 36Akzelerator-Ansatz 20Alert 370Allocation Limit 357Alternativen zu BW-auf-HANA 206Amazon Web Services 53Analytic Privilege 260Analytic View 259analytischer Index 332Anforderung evaluieren 207Anwender sperren 154Application Function Library 46, 70Architected Data Mart 283Architected Data Mart Layer 283Archivierung 199, 437, 443

mit Nearline Storage 439Attribute View 259Aufgabenliste regelmäßig

ausführen 121Ausführungsdauer ermitteln 204Ausnahmeaggregationen 220Authentifizierung 68

B

Backup 133, 178, 382anlegen 382wiederherstellen 383

Basepath 378

Basistabelle bereinigen 121Benutzer

anlegen 351SYSTEM 354

Benutzerschema 351Benutzerverwaltung 350, 351

im SAP HANA Studio 352Berechtigung

anpassen 186fehlende 353

Berechtigungsverwaltung 350Bereinigungsaktivität 114, 198

Basistabelle 121Planung 116SAP-Basis 122zusätzliche Informationen 116

Bestands-InfoCube 211Betriebssystem 65Betriebssystemvirtualisierung 65BEx Analyzer 425BEx-Query 74, 226, 330, 403, 404

Optimierung 220BI Launch Pad 390

Alert 394Applikationen 392Dokument anzeigen 393Dokumente 391, 393Inhaltsverknüpfungen 397Nachrichten 391Startseite 391Warnmeldungen 392

BI-Arbeitsbereich 395erstellen 395Inhaltsverknüpfung 397Modul 396

BICS-Schnittstelle 401Big Data 387BI-Plattform � SAP BusinessObjects

Business IntelligenceBI-Server, Administration 398BI-Sperrserver 180Blade 56Business Transformation Layer 282Business Warehouse Accelerator 74BW Migration Cockpit 150

482

Index

BW Modeling Tools 233, 248Installation 248Update 250

BW prüfen 181BW Virtual Data Mart Layer 311

Reporting 311BWA � Business Warehouse

AcceleratorBW-Applikationsserver Java 188BW-auf-HANA

Architektur 460mit Nearline Storage 437Reporting 453Vorteile 22, 33

BW-auf-HANA vs. SAP HANA Live 460hybrider Einsatz 463

BW-Inkonsistenz beheben 184BW-integrierte Planung 335BW-Objekt archivieren 127BW-Quellsystem 180BW-System

aufrüsten 207BW-Transformationsfinder 148

auf SAP HANA 149

C

Calculated Column 265Calculation Engine 70Calculation View 70, 71, 259Central Management

Console 390, 398Zugriffsberechtigung 398

Change Log bereinigen 126Client-Tool 388, 405

BW-Version 406Dashboards & Apps 388Reporting 389SAP-HANA-Version 408Self-Service 388

Cloud 52Definition 52Kundenkreis 53Testversion 54

Cluster Encoding 40CMC � Central Management ConsoleCode-Push-down 21, 22, 241

Voraussetzung 242

Code-Push-down (Forts.)Vorteile 242

Cold Standby 57CompositeProvider 227, 233, 248,

255, 312, 327anlegen 255Einsatzgebiet 294Join 293konfigurieren 256Tipps 235Transport 235und InfoProvider 234und SAP HANA View 235verwenden 234

Container 65Corporate Memory 282

D

Dashboard 349Dashboard Builder � BI-Arbeits-

bereichData Acquisition Layer 282Data Propagation Layer 282Data Provisioning � DatenversorgungData Warehouse, unternehmens-

weites 387Database Instance Export 162Datacenter-Service-Point-Version 192Data-Mart-Ansatz 19DataSource 155Daten

auslagern 314extern verwaltete 297, 299nicht aktive 314Replikation vs. Extraktion 302von BW verwaltete 297, 299

Datenanalyse, flexible 387Datenarchivierung 437, 443Datenaufbereitung 461Datenbank

Backup 200Index 27relationale 27Version ermitteln 193verteilte 132

Datenbankkonfiguration 376Datenbankobjekt 69Datenbank-Performance 366

483

Index

Datenbankschema zusammen-führen 324

Datenbankverbindung 441Datenbankzugriff 68Datenextraktion 304Datenextraktion vs. Daten-

replikation 304Datenfluss-Template 285Datenhaltung 34

verteilte 29Datenhaltung in BW 31Datenklassifizierung nach Zugriffs-

häufigkeit 320Datenkonsolidierung 461Datenmodell

feldbasiertes und multi-dimensionales 306

im BW konsumieren 324Datenmodellierung 223

beschleunigen 233InfoProvider 306

Datenreplikationin SAP BW 303Stammdaten 307

Datentyp 215Datenverfügbarkeit 57Datenverlust 57Datenversorgung 236

Replikationsverfahren 236Datenverwaltung 69Datenvolumen 25Datenwachstum 25Datenzugriff, Echtzeit 26DBA Cockpit 185DDIC-Inkonsistenz auflösen 184DDIC-Passwort prüfen 159Decision Table 260Delta Merge 42Delta Storage 42Delta-Merge 227Delta-Queues leeren 155Demo-Szenario in SAP BW 331Design Studio � SAP BusinessObjects

Design StudioDesign-Studio-Applikation 417Diagnosedatei 371Dictionary Encoding 40Dispatcherprozess 195DNS � Domain Name SystemDomain Name System 198

DSO 225im Architected Data Marts Layer 291Konvertierung rückgängig

machen 274SAP-HANA-optimiertes 274

DTP-Daten löschen 127DTP-Fehler-Stack löschen 127

E

Echtzeit-Analyse 387Echtzeit-Datenzugriff 26Eclipse 248, 343Effective Allocation Limit 361Enterprise Data Warehouse Layer 283Entwicklungssystem 208erweitertes Schema 27Exportlauf starten 166Exportphase 159Exportreihenfolge 165Exportvorbereitung 154, 159

F

Facet 430FactView 209Favoriten 393Fehlerbehandlung 176Fehlersuche 370Festplatte 363

Performance 365filter.ini 382Forecasting 387, 389

G

Global Allocation Limit 60, 378

H

HANA Cookbook 192HANA Engine 70Hardware

Scale-out 56Scale-up 56Sizing 129Virtualisierung 64

484

Index

Hardware (Forts.)Zertifizierung 51

Hauptspeicher 58, 225, 357, 438begrenzen 378optimale Nutzung 321Typ 361verwalten 359

Hauptspeicherbedarf berechnen 130Heap Memory 362HEC � SAP HANA Enterprise CloudHintergrundjob löschen 123historische Daten 462Hochverfügbarkeit 57Housekeeping 114

Aufgabenliste 117Aufgabenliste ausführen 118Aufgabenliste erstellen 117

HTML5 417Hypervisor � Virtual Machine

Monitor

I

IDOC 128Importphase 169Importvorbereitung 168Indexserver 67, 68indexserver.ini 380InfoCube 32, 210, 224, 291

aus Datenfluss entfernen 291Datenmodell 268in BW-auf-HANA 225, 226komprimieren 126Komprimierung 269konvertieren 187, 210, 270Partition 269Partitionierung 211SAP-HANA-optimierter 267Sperre 213Standard 268Tabelle 273Tabelle nach Konvertierung 273

InfoProvider 149, 212, 226, 234, 312, 448archivierte Daten 449BW Modeling Tools 248EDW 309feldbasierter 300, 306HANA View erzeugen 243

InfoProvider (Forts.)InfoObjekt-basierter 300mögliche Eliminierung 295

Infrastructure as a Service 53Initialwert Datenbankfeld 216, 218Inkonsistenz 181Inkonsistenz in Tabelle

korrigieren 182In-Memory-Datenbank 38In-Memory-Technologie 38Input-Parameter 265Instanznummer 174integrierter Ansatz 20Interaktive Analyse 428Intermediate Document � IDOCITaaS � Infrastructure as a Service

J

Jobprotokoll löschen 124Jobverarbeitung anhalten 156Join Engine 72

K

Kernel 195Kommunikationsverzeichnis 174Kompressionsrate 41Komprimierung 40, 130konsistenter EDW-Kern 288

Vorteile 289Konsistenzprüfung 183

mit DBA COCKPIT 185Konzept nicht aktiver Daten 314

L

Ladeprozess 36Laufzeit 168Layered Scalable Archictecture

festlegen 284Vorteile 284

Layered Scalable Archictecture ++ 281, 286Business-Intelligence-Varianten 287Fokus 290Merkmal 287

leseoptimierte Tabelle 42

485

Index

Lifecycle Management 345Log_mode 379Log-Backup 364Logmodus 168LSA++ � Layered Scalable

Architecture ++LSA++-Architektur � Layered Scalable

Archictecture ++

M

Main Storage 42Marker-Update 211materialisierte Sicht 28MCOD � Multiple Components One

DatabaseMeldung löschen 127Memory Overview 362

Berechtigung 362Memory-Pool 358Microsoft Excel 425Microsoft PowerPoint 425Migration

Ablauf 153Anwender sperren 154beenden 188Berechtigung anpassen 186Datenbanktabelle 216DDIC-Passwort prüfen 159Delta-Queue leeren 155Export 159Exportvorbereitung 154Fehler vorher beheben 145Fehlerbehandlung 176Import 169Importvorbereitung 168Inkonsistenz 181Jobverarbeitung anhalten 156manuelle 75, 152Nacharbeiten 177native Datenbankobjekte

exportieren 157non-disruptive 209paralleler Export und Import 176Produktivsystem 214Prozesskette anhalten 155SWPM-Einstellungen 170Systemlandschaft 208Tabelle DBDIFF aktualisieren 157

Migration (Forts.)temporäre SAP-Tabelle leeren 156testen 199, 200Tipp 191

Migrationsschlüssel 173Migrationsszenario 73

Neuinstallation 73Mirroring 57Modulbibliothek 396Monitoring 356

Clustersystem 362Festplatte 364Prozessorlast 358

Multi-Level Partitioning 44Multi-Node 39Multiple Components One

Database 62MultiProvider 225, 226, 312

überprüfen 184Multi-SID-Szenario 63Myself-System 180

N

Nameserver 68, 381natives Datenbankobjekt

exportieren 157Nearline Storage 437

an SAP BW anbinden 440archivierte Daten anzeigen 448Archivierung 443Archivierung über Prozesskette 447Archivierungsprozess 443Archivierungs-Request 445Datenbankverbindung 441Installation 440Test-Query 445Treiber 440Vorteile 438weitere Informationen 439

Nearline-Storage-Lösung 55Netzwerkfreigabe 161Neuinstallation 73, 76NLS � Nearline Storagenon-disruptive 209NUMA-Architektur 58

486

Index

O

ODP � Operational Data ProvisioningODQ � Operational Delta Queueoffene Planungsanforderung 340OLAP 29

Cache 29OLAP-Datenquelle 401OLAP-Verbindung 401

Authentifizierung 402Provider 401

OLTP 29Open ODS Layer 296, 310

Dienst 297Vorteile 310

Open ODS View 230, 252, 306aktivieren 232anlegen 231, 253Smart Data Access 233

Open Operational Data Store Layer � Open ODS Layer

Operation, analytische 28Operational Analytics 23Operational Data Provisioning 236

DataSource 239Quellsystem 238und Open ODS View 240Voraussetzungen 241

Operational Data Store 283Operational Delta Queue 236

P

PaaS � Platform as a ServicePacifica 64Package 260PAK � Planning Application KitPAM � Product Availability Matrixparalleler Export und Import 176Parameter löschen 127Partitionierung 43, 56Partitionierungsart 44Passwort-Änderung 186Performance 33, 220, 366

historische Daten 367Performance-Messung, SAP HANA

PlanViz 368Persistent Staging Area 125

bereinigen 125

Perspektive 343einblenden 345

Physical Memory 361Planning Application Kit 74, 188, 335

aktivieren 188, 339Disaggregation 337Performance 336

Planungsszenario 462Platform as a Service 53POC � Proof of ConceptPost-Migration-Report 179Preprocessor Server 68Private Cloud 53Private View 457Procedure 260Product Availability Matrix 51Produktivsystem 214

Migration 214Proof of Concept 201

Ausführungsdauer von Reports ermitteln 204

Auswertung 206BW-Szenario 203Cloud 202Hardware 202Kosten 202Vorteile 201Wissenstransfer 202

Prozesskette 276anhalten 155Aufbau 277aufbauen 278Performance 279untersuchen 147

Prüfroutine 145PSA prüfen 181PSA � Persistent Staging AreaPublic Cloud 53

Q

Qualitätssicherungssystem 214Migration 214

Quality & Harmonisation Layer 282

R

R aktivieren 380R3-Programm 195

487

Index

Range Partitioning 44Rechtemanagement 69Red Hat Enterprise Linux Server 66Redo-Log 379relationale Datenbank 27reload_tables 380Remodeling Toolbox 32Report

RSDU_TABLE_CONSISTENCY 211SMIGR_CREATE_DDL 157

Reporting 248, 281, 311, 385, 453Einsatzzweck 385mit Drittdaten 296mit EDW Propagation Layer 292Trend 387

Reporting Layer 283Ressourcenverbrauch 367Restricted Column 265Reuse View 457Rolle 350

anlegen 355Round Robin Partitioning 44Run Length Encoding 41

S

SaaS � Software as a ServiceSAP Business ByDesign

Cloud 53SAP Business Planning and

Consolidation 402SAP Business Warehouse

Administrationsaufwand 32Datenaufbereitung 461Datenextraktion 304Datenkonsolidierung 461Demo-Szenario 331Echtzeit-Datenreplikation 303Nearline Storage 440Prozesskette 276Standardfunktion nutzen 247Vorteile 460

SAP Business Warehouse Accelerator � SAP BWA

SAP Business Warehouse Operative Datendienste 298, 302

SAP BusinessObjects 457SAP BusinessObjects Analysis, Edition

for Microsoft Office 425

SAP BusinessObjects Analysis, Edition for OLAP 427

SAP BusinessObjects Business Intelligence 387, 3904.1 390

SAP BusinessObjects Dashboards 420SAP BusinessObjects Design

Studio 417Datenquellen 418Komponente 419

SAP BusinessObjects Explorer 429SAP BusinessObjects Web

Intelligence 414Rich Client 415SAP HANA View 416

SAP BWA 30SAP Crystal Reports 409

Crystal Reports 2013 410Crystal Reports for Enterprise 410

SAP Data Services 282SAP GUI 402SAP HANA

Anforderungen 39Architektur 49Betriebssystemvirtualisierung 65Checklist-Tool 141Cloud 52Datenmodell 24Entwicklung 39Festplattenkapazität 132freigegebene BW-Komponenten 81Grundlagen 17Hardware-Sizing 130Hardwarevirtualisierung 64Hauptspeicher 357Hauptspeicherbedarf 130produktiver Betrieb 55Prozessorlast 358Server 51Speicherverwaltung 59Version prüfen 193Virtualisierung 63

SAP HANA App Services 54SAP HANA Appliance 18SAP HANA Cloud Platform 55SAP HANA DB Services 54SAP HANA Enterprise Cloud 55SAP HANA Infrastructure Services 54SAP HANA Live 24, 455

Architektur 460

488

Index

SAP HANA Live (Forts.)Berechtigung 462Datenaufbereitung 461hybrider Einsatz 463Vorteile 459

SAP HANA Live Browser 456SAP HANA One 54SAP HANA PlanViz 344, 368SAP HANA Studio 24, 194, 248, 343

Benutzerverwaltung 352BW-Modeling-Perspektive 250installieren 345Konfigurationsdatei 376Monitoring 356Project Explorer 250, 251SAP-HANA-Modellierungs-

perspektive 258Version ermitteln 194

SAP HANA View 326, 455aktivieren 267Aufbau 262Datenquelle 264erzeugen 243grafisches Element 263in BW konsumieren 324modellieren 257, 261, 264semantische Information 266und BW-auf-HANA 227Voraussetzung 261Zugreifen auf 244

SAP IQ 437SAP LT Replication Server 303, 308SAP Lumira 432

Story 434SAP OS/DB Migration Check 214SAP Predictive Analysis 389, 435SAP Profitability and Cost Manage-

ment 402SAP QuickSizer 133sap.hana.xs.admin.roles::SQLCCAdmi-

nistrator 356SAP-BW-EDW-Dienst 298, 309SAP-BW-Integrationsdienst 297, 299SAP-HANA-Client, Version

ermitteln 194SAP-HANA-Datenbankserver zum

View hinzufügen 346SAP-HANA-Development-Perspektive

344SAP-HANA-Modeler-Perspektive 344

SAP-HANA-Modellin SAP BW 299

SAP-HANA-Prozedur 246SAP-Hinweis 56, 195, 196, 209, 211

einspielen 196suchen 196Übersicht 468

SAP-Kundenmeldung 177SAPOffice-Dokument

reorganisieren 124Savepoint 364Scale-out 56, 131Scale-out-Ansatz 39Scale-up 56, 131Schulung 197SELECT * 246Server 51

Anzahl 56Serverkomponenten 390Service Auto Restart 58Shared Memory 362Sicherheitsaspekte 207Side-by-Side-Implemen-

tierung 18, 456Simulation 389Single Point of Truth 283Single Sign-on (SSO) 402, 404Single-Node 39Sizing, Beispielrechnung 138Sizing-Report 133SLT 308SLT � SAP LT Replication ServerSmart Data Access 229

Open ODS View 230, 233SAP HANA View 230

Software as a Service 53Software Provisioning Manager 195spaltenbasierte Speicherung 40Speicherengpass 132Speicherpfad ändern 378Speicherverwaltung 59SQL Engine 71SQL Plan Cache 368SQL-Statement, Übersicht 475Stammdaten 294, 307

Echtzeit-Aktualisierung 308Standardbenutzer 350State-of-the-Art-Technologie 35Statistics Server � StatistikserverStatistikdaten 119

489

Index

Statistikserver 67deaktivieren 380

Sternschema 24, 27Stored Procedure 462SUSE Linux Enterprise Server for

SAP Applications 66SWAP-Speicher 357SWPM 153SWPM-Einstellungen 170Systembenutzer einrichten 169Systemkopie 199

homogene 110Systemlandschaft 198

mehrstufige 208Migration 208

Systems View 346Systemvalidierung 141

Optionen 143

T

Tabelle DBDIFF aktualisieren 157Tabelle virtuell integrieren 229

Drittanbieter 229Tailored Data Center Integration 51temporäre SAP-Tabellen leeren 126,

156TemSe bereinigen 123Text auswerten 68Trace 374

Tabellenzugriff 376Typ 374

Training 197Transaktion

RSMIGRHANADB 210RSMRT 32RSRT 204, 220SARA 199Übersicht 473

Transformation, Code-Push-down 241

TransientProvider 300, 331Transport testen 213TREX 38Trigger Read Ratio 366Trigger Write Ratio 366

U

Used Memory 361

V

Vanderpool 64Version prüfen 194Versionsstand

DBSL_Bibliothek 195SAP HANA Studio 194SAP-HANA-Client 194SAP-HANA-Datenbank 193SAP-Kernel 195

verteilte Datenhaltung 29View, Übersicht 475Virtual Data Mart Layer 292Virtual Machine Monitor 64Virtual Memory 361Virtualisierung 63Virtualization Layer 283VirtualProvider 300, 333

anlegen 333virtuelles Datenmodell 457VMM � Virtual Machine MonitorVMware vSphere 64

W

webbasierte Analyse 429WHERE-Bedingung 246Windows, Systembenutzer 169Workbench 343Workprozess 195

X

Xcelsius � SAP BusinessObjects Dashboards

XS Debugger 381XS Engine 68XS Jobs 381

Z

Zugriffsberechtigungsgruppe 400

Wir hoffen sehr, dass Ihnen diese Leseprobe gefallen hat. Gerne dürfen Sie diese Leseprobe empfehlen und weitergeben, allerdings nur vollständig mit allen Seiten. Die vorliegende Leseprobe ist in all ihren Teilen urheberrecht- lich geschützt. Alle Nutzungs- und Verwertungsrechte liegen beim Autor und beim Verlag.

Teilen Sie Ihre Leseerfahrung mit uns!

Matthias Merz leitet das Center of Excellence SAP HANA bei der Camelot ITLab GmbH und berät Unternehmen insbesondere im Bereich BW-auf-HANA.

Matthias Merz, Torben Hügens, Steve Blum

SAP BW auf SAP HANA – Implementierung und Migration489 Seiten, gebunden, Dezember 2014 69,90 Euro, ISBN 978-3-8362-2965-4

www.sap-press.de/3660

Torben Hügens ist Head of Center of Excellence Business-Objects bei der Camelot ITLab GmbH. Zuvor war er Mitar-beiter der SAP Deutschland AG & Co. KG und als Berater im Bereich SAP BusinessObjects Business Intelligence/SAP Business Warehouse tätig.

Steve Blum ist Junior Consultant bei der Camelot ITLab GmbH und arbeitet im Center of Excellence SAP HANA.

Wissen aus erster Hand.