19,99 €
Mehr erfahren.
- Herausgeber: Espresso Tutorials
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Deutsch
Dieses Praxishandbuch entführt Sie in die technische Welt von SAP HANA. Wer dort erstmals eintaucht, steht gleich zu Beginn vor Fragen zum Aufbau der Systemlandschaft mit passender Hard- und Software, Skalierung und Dimensionierung. Die anschließenden Kernpunkte der Verwaltung einer SAP-HANA-Datenbank werden Ihnen anhand des kompletten Lebenszyklus aufgezeigt: von der Installation, über den täglichen Betrieb, das Sicherstellen der Betriebskontinuität bis hin zur Fehleranalyse, -behebung und -vermeidung. Sie erhalten eine kurze Einführung in die Werkzeuge, die Ihnen für die Bewältigung dieser unterschiedlichen Aufgaben zur Verfügung stehen – allen voran das SAP HANA Cockpit. Auch grundlegende Sicherheitsaspekte in den Bereichen Benutzerverwaltung, Auditing und Verschlüsselung finden Berücksichtigung.
Das Buch wendet sich an Systemadministratoren und Berater, die sich neu in SAP HANA einarbeiten oder bereits erste Erfahrungen gemacht haben und ein handliches Nachschlagewerk für die wichtigsten Fragen der Planung und Administration einer SAP-HANA-Landschaft suchen.
- Architekturkonzepte von SAP HANA verstehen und anwenden
- Sizing, Skalierbarkeit, Mandantenfähigkeit, Hochverfügbarkeit
- Probleme vermeiden, frühzeitig erkennen und beseitigen
- einfach nachvollziehbar anhand der SAP HANA, express edition
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 206
Veröffentlichungsjahr: 2019
Ähnliche
Andreas Schuster
Praxishandbuch SAP® HANA – Administration
Andreas SchusterPraxishandbuch SAP® HANA – Administration
ISBN:978-3-945170-98-4 (E-Pub)
Lektorat:Anja Achilles
Korrektorat:Stefan Marschner
Coverdesign:Philip Esch
Coverfoto: istockphoto.com © bennymarty | ID 842372792
Satz & Layout:Johann-Christian Hanke
Alle Rechte vorbehalten
1. Auflage 2019
© Espresso Tutorials GmbH, Gleichen 2019
URL:www.espresso-tutorials.de
Das vorliegende Werk ist in allen seinen Teilen urheberrechtlich geschützt. Alle Rechte vorbehalten, insbesondere das Recht der Übersetzung, des Vortrags, der Reproduktion und der Vervielfältigung. Espresso Tutorials GmbH, Bahnhofstr. 2, 37130 Gleichen, Deutschland.
Ungeachtet der Sorgfalt, die auf die Erstellung von Text und Abbildungen verwendet wurde, können weder der Verlag noch Autoren oder Herausgeber für mögliche Fehler und deren Folgen eine juristische Verantwortung oder Haftung übernehmen.
Feedback:Wir freuen uns über Fragen und Anmerkungen jeglicher Art. Bitte senden Sie diese an: [email protected].
Inhaltsverzeichnis
Willkommen bei Espresso Tutorials!
Unser Ziel ist es, SAP-Wissen wie einen Espresso zu servieren: Auf das Wesentliche verdichtete Informationen anstelle langatmiger Kompendien – für ein effektives Lernen an konkreten Fallbeispielen. Viele unserer Bücher enthalten zusätzlich Videos, mit denen Sie Schritt für Schritt die vermittelten Inhalte nachvollziehen können. Besuchen Sie unseren YouTube-Kanal mit einer umfangreichen Auswahl frei zugänglicher Videos: https://www.youtube.com/user/EspressoTutorials.
Kennen Sie schon unser Forum? Hier erhalten Sie stets aktuelle Informationen zu Entwicklungen der SAP-Software, Hilfe zu Ihren Fragen und die Gelegenheit, mit anderen Anwendern zu diskutieren: http://www.fico-forum.de.
Eine Auswahl weiterer Bücher von Espresso Tutorials:
Bernd Klüppelberg:
Techniken im SAP-Berechtigungswesen
Daniel Kloppich, Bert Lorenz:
SAP Solution Manager 7.1 IT-Servicemanagement Web UI
Jörg Marenk:
IT-Projektmanagement im SAP Solution Manager
Stefan Köhler, Christina Dietrich:
SAP Solution Manager – Testautomatisierung mit CBTA
Christoph Kretner, Jascha Kanngießer:
Berechtigungen in SAP BW, HANA und BW/4HANA
Andreas Prieß:
SAP-Berechtigungen für Anwender und Einsteiger
Sabrina Heim, Andreas Dietrich, Julian Harfmann:
Compliant Identity Management mit SAP IdM und GRC AC
Vorwort
Kaum ein Produkt hat in den letzten Jahren einen derartigen Einfluss auf die Produktstrategie der SAP genommen wie die Datenbank SAP HANA.
Bis zur Markteinführung von SAP HANA im Jahr 2011 galt die Devise, die Anwendungslogik strikt von der Datenhaltung zu trennen. Allerdings entwickelte sich dieses Vorgehen mit zunehmender Datenmenge immer mehr zum Flaschenhals. Daten mussten von der Datenbank zur Anwendung übertragen, dort verarbeitet und zurück zur Datenbank gesendet werden. Eine Verarbeitung »am Speicherort«, die diesen enormen Aufwand verringert, war nur durch eine zunehmende Verschmelzung der Anwendung mit der Datenbank zu erreichen. Gleichzeitig konnten bei der Entwicklung neueste technologische Fortschritte des Datenbankmanagements berücksichtigt werden, allen voran die permanente Datenhaltung im Hauptspeicher sowie die spaltenbasierte Organisation der Daten.
Das Ergebnis spiegelt sich nicht zuletzt in der aktuellen Produktgeneration wider: S/4, BW/4 und C/4 – alle mit dem Zusatz »HANA« – heißen die neuesten Anwendungen aus dem Hause SAP für Enterprise Resource Planning, Data Warehousing und Customer Relationship Management. Allesamt sind speziell für den Betrieb auf und mit SAP HANA entwickelt und optimiert.
Die Einführung einer neuen Technologie hat jedoch immer auch eine Umstellung im Betrieb zur Folge. Prozesse müssen angepasst und Wissen über die neue Technologie muss aufgebaut werden. Ich selbst habe in meiner beruflichen Laufbahn einige von SAPs größten Kunden bei der Einführung von SAP HANA begleitet und bin dabei auf viele wiederkehrende Fragestellungen gestoßen:
Auf welchen technologischen Grundlagen basiert SAP HANA und welche Auswirkungen hat dies auf mich als Anwender und Betreiber?
Wie muss die Systemlandschaft aufgebaut und dimensioniert werden?
Wie kann Ausfallsicherheit hergestellt werden?
Welche Werkzeuge stehen zur Administration zur Verfügung?
Doch auch unmittelbar nach einer HANA-Einführung und teils noch lange darüber hinaus besteht Klärungsbedarf:
Wie halte ich die Datenbank-Software aktuell?
Wie kann ich die optimale Auslastung der Ressourcen und die Stabilität der Datenbank auch bei Hochlast sicherstellen?
Wie kann ich Fehler identifizieren und vermeiden?
Welche Analyse- und Optimierungsmöglichkeiten bieten sich mir?
Ich habe versucht, möglichst viele dieser Fragen in diesem Buch zu beantworten, und wende mich damit insbesondere an Systemadministratoren und Berater, die neu im Umfeld SAP HANA agieren. Es soll Ihnen den Einstieg erleichtern und Ihnen ein Nachschlagewerk der wichtigsten Aspekte der Datenbank SAP HANA an die Hand geben.
In jedem Kapitel bieten Ihnen Hinweiskästen Links zu weiterführenden Informationen zu den beschriebenen Themen. Zusätzlich enthält der Anhang eine Übersicht wichtiger SAP-Hinweise.
Im Text verwenden wir Kästen, um wichtige Informationen besonders hervorzuheben. Jeder Kasten ist zusätzlich mit einem Piktogramm versehen, das diesen genauer klassifiziert:
Hinweis
Hinweise bieten praktische Tipps zum Umgang mit dem jeweiligen Thema.
Beispiel
Beispiele dienen dazu, ein Thema besser zu illustrieren.
Achtung
Warnungen weisen auf mögliche Fehlerquellen oder Stolpersteine im Zusammenhang mit einem Thema hin.
Video
Schauen Sie sich ein Video zum jeweiligen Thema an.
Gender-Anmerkung
Um den Lesefluss nicht zu beeinträchtigen, wird im vorliegenden Buch bei personenbezogenen Substantiven und Pronomen zwar nur die gewohnte männliche Sprachform verwendet, stets aber die weibliche Form gleichermaßen mitgemeint.
Hinweis zum Urheberrecht
Sämtliche in diesem Buch abgedruckten Screenshots unterliegen dem Copyright der SAP SE. Alle Rechte an den Screenshots hält die SAP SE. Der Einfachheit halber haben wir im Rest des Buches darauf verzichtet, dies unter jedem Screenshot gesondert auszuweisen.
1 Grundlagen von SAP HANA
In diesem Kapitel möchte ich mich kurz den grundlegenden Konzepten widmen, die die Datenbank SAP HANA zu dem machen, was sie ist. Dies soll Ihnen den Einstieg in dieses komplexe Thema erleichtern und Licht in die grundlegende Frage bringen: »Was ist denn SAP HANA überhaupt?«
Dazu beleuchte ich das Grundkonzept, welchem SAP HANA zugrunde liegt: eine – im Kern – relationale Hauptspeicherdatenbank, die für anspruchsvolle Datenhaltung im Unternehmensumfeld konzipiert und gebaut wurde.
Des Weiteren erhalten Sie eine Einführung in die SAP HANA, express edition, eine vereinfachte HANA-Version, die für den Einsatz auf einer deutlich weniger leistungsfähigen Hardware ausgerichtet ist (z.B. Personal Computer).
SAP HANA FAQs
Wer auf der Suche nach Antworten auf häufig gestellte Fragen zum HANA-Betrieb ist, sollte sich unbedingt die SAP HANA FAQs ansehen, zu finden am einfachsten über SAP-Hinweis 2000003.
Die FAQs stammen direkt von Mitarbeitern der SAP-Support-Organisation (»Digital Business Services«, der frühere »Active Global Support« oder AGS), also denen, die sich tagtäglich mit Kundenanfragen zu genau diesem Thema beschäftigen.
SAP HANA Academy
Die SAP HANA Academy bietet eine Vielzahl von kurzen Einführungsvideos zu unterschiedlichsten Themen im Kontext von SAP HANA, frei verfügbar auf YouTube.
https://www.youtube.com/user/saphanaacademy/
openSAP: Einführung in die SAP-HANA-Administration
https://open.sap.com/courses/hsha1
1.1 Wofür steht HANA?
Im Gespräch mit Kunden, die gerade erst am Anfang von SAP HANA stehen, höre ich oft die Frage: »Woher kommt der Name HANA?« Meist folgen dieser Frage direkt Mutmaßungen über die Herkunft des Begriffs. Bemüht man bekannte Suchmaschinen oder Online-Enzyklopädien, tauchen Auslegungen auf wie »High-Performance Analytic Appliance« (Vijayan, 2010) oder auch schlicht »Hassos New Architecture« (Sikka, 2008). Beiden Varianten ist gemein, dass eine gewisse Sinnhaftigkeit nicht bestritten werden kann.
Die High-Performance – also die Leistungsfähigkeit – von SAP HANA wird niemand bestreiten, der je den direkten Vergleich mit anderen Datenbanken gezogen hat. Auch die initiale Positionierung im Analytics-Umfeld – SAP Business Warehouse war die erste der großen SAP-Anwendungen auf HANA – ist Fakt und wird mit BW/4HANA konsequent in der neuen Produktgeneration fortgeführt. Mit zunehmender Positionierung im Umfeld transaktionaler Anwendungen (siehe Abschnitt 1.3) ist der ausschließlich analytische Fokus allerdings mittlerweile verloren gegangen. SAP HANA wird heutzutage als Datenbank für nahezu jede SAP-Anwendung verwendet, allen voran für das transaktionale Flaggschiff S/4HANA als Anwendung für Enterprise Resource Planning (ERP).
Die Assoziation des Namens mit Hasso Plattner – Mitbegründer und heutiger Vorsitzender des Aufsichtsrates der SAP – liegt nahe. Schließlich war Prof. Plattner immer eine treibende Kraft sowie ein großer Unterstützer hinter SAP HANA und ist dies auch weiterhin.
Abschließend lässt sich sagen, dass SAP HANA schlicht für SAP HANA steht. Ob Akronym oder »Backronym« (also ein nachträglich definiertes Akronym), eine offizielle Stellungnahme dazu gibt es jedenfalls nicht.
1.2 Das In-Memory-Konzept
Sicherlich haben Sie im Zusammenhang mit SAP HANA bereits die Begriffe In-Memory-Datenbank oder auch »Hauptspeicher-Datenbank« gehört. Das dahinterstehende In-Memory-Konzept umfasst zwei grundlegende Aspekte:
1. »In-Memory« bedeutet, dass die komplette Datenbasis zu jeder Zeit im Haupt- bzw. Arbeitsspeicher des Servers vorgehalten wird. Dies ist ein Aspekt, der mittlerweile von vielen am Markt angebotenen Datenbanken ganz oder teilweise unterstützt wird.
2. Konsequent implementiert ist »In-Memory« allerdings erst, wenn sämtliche Operationen primär auf den Datenstrukturen im Hauptspeicher ausgeführt werden. Erst im Anschluss werden Änderungen auf ein, im Gegensatz zum Hauptspeicher, nicht-flüchtiges Medium (z.B. eine Festplatte) geschrieben, um einem Datenverlust durch den Ausfall des Systems vorzubeugen.
SAP HANA unterscheidet sich insbesondere im zweiten Punkt von anderen Datenbanken für Unternehmensanwendungen, die In-Memory unterstützen. Diese bieten zwar häufig die Möglichkeit an, zumindest einen Teil der Daten im Hauptspeicher vorzuhalten, führen Änderungen jedoch weiterhin auf dem nicht-flüchtigen Massenspeicher durch. Erst anschließend werden diese Änderungen – teils automatisiert in Echtzeit, teils manuell initiiert – an den Hauptspeicher übertragen.
Wie bei jeder anderen Anwendung müssen Daten zunächst in den Hauptspeicher eines Systems geladen werden, bevor sie der Prozessor – die Central Processing Unit (CPU) – verarbeiten kann. Je nachdem, wo die Daten vorgehalten werden, kann dieser Weg mitunter sehr beschwerlich und zeitaufwendig sein.
In der heutigen Zeit wird die Ausführungsgeschwindigkeit einer Anwendung in zunehmendem Maße nicht mehr allein durch die Geschwindigkeit der CPU bestimmt, sondern durch die Geschwindigkeit, mit der die CPU mit Daten versorgt werden kann. Dabei durchwandern Daten i.d.R. mehrere Speicherbereiche:
Massenspeicher oder Festplatte,
Hauptspeicher,
CPU-Caches (L1/L2/L3),
CPU-Register.
Dabei gilt: Mit zunehmender Entfernung von der CPU steigt die Latenz für den Zugriff auf Daten. Gleichzeitig nimmt allerdings in ähnlichem Umfang auch die Speicherkapazität zu. Diese Korrelation verhält sich nicht etwa linear, sondern exponentiell, wie in Abbildung 1.1 zu sehen. In Tabelle 1.1 finden Sie eine Übersicht der Größenordnungen für Latenz und Kapazität verschiedener Speicherbereiche.
Speicherbereich
Latenz
Kapazität
CPU-Cache
wenige CPU-Takte
Kilobyte bis wenige Megabyte
Hauptspeicher
Nanosekunden
Terabyte
Massenspeicher
mehrere 100 Millisekunden
Petabyte
Tabelle 1.1: Latenz und Kapazität unterschiedlicher Speicherbereiche
Abbildung 1.1: Zugriffszeiten und Performance in Relation
Die Leistungsfähigkeit eines Rechners profitiert also stark davon, wenn die Daten einer Anwendung möglichst dicht am Prozessor vorgehalten werden. Gleichzeitig nimmt die technisch mögliche Speicherkapazität ab, je näher sich der Speicher am Prozessor befindet. Können Daten nicht schnell genug von einem Speicherbereich in den nächsten geladen werden, entstehen leicht »Flaschenhälse«. Diese haben zur Folge, dass die CPUs nur unzureichend mit Daten versorgt werden können, was sich negativ auf die Leistung des Systems auswirkt.
An dieser Stelle hat der technologische Fortschritt in den letzten Jahren große Sprünge gemacht. Früher war es unvermeidbar, große Datenmengen auf einem Massenspeicher wie einer Festplatte abzulegen. Heutzutage ist man darauf nicht mehr angewiesen, da es problemlos möglich ist, große Server mit mehreren Terabyte Hauptspeicher zu bezahlbaren Preisen auszustatten. Die geringere Entfernung zur CPU wirkt sich dabei sehr positiv auf die Zugriffszeiten aus – ein Umstand, den SAP HANA konsequent ausnutzt, da sie speziell daraufhin optimiert wurde.
1.3 SAP HANA als relationale Datenbank
SAP HANA entwickelt sich mittlerweile mehr und mehr zur Multi-Modell-Datenbank, unterstützt also unterschiedliche Datenmodelle (Färber, et al., 2011). Ihren Kern bildet jedoch nach wie vor das von SAP-Anwendungen wohlbekannte relationale Modell, bestehend aus zweidimensionalen Tabellen. Jede Zeile der Tabelle repräsentiert einen Datensatz, dessen Attribute in Spalten organisiert sind. Das Datenmodell ergibt sich aus den Beziehungen – den Relationen – der Tabellen zueinander.
Multi-Modell-Datenbanken
Neben relationalen Datenbanken gibt es heutzutage vermehrt Datenbanken, die auch andere Datenmodelle verwenden. Während eine relationale Datenbank auf zweidimensionalen Tabellen basiert, verwendet eine Graph-Datenbank eine Kombination aus Knoten und Kanten. Eine Dokumenten-Datenbank wiederum speichert Daten z.B. im XML- oder JSON-Format.
Eine Multi-Modell-Datenbank zeichnet sich dadurch aus, dass mehrere dieser Datenmodelle unterstützt und diese auch miteinander kombiniert werden können.
Bei der Programmierung einer Datenbank stellt sich direkt zu Beginn die Frage, über welche Datenstrukturen eine Tabelle im Speicher abgebildet wird und wie diese angeordnet werden sollen. Datenstrukturen eines Rechners sind dabei immer eindimensional. Eine zweidimensionale Tabelle lässt sich demnach auf zweierlei Arten im Speicher ablegen:
zeilenbasiert, Zeile für Zeile, oder
spaltenbasiert, Spalte für Spalte.
Das Ziel beider Anordnungen ist, beim Zugriff auf die Tabelle Sprünge zwischen nicht zusammenhängenden Speicherbereichen zu vermeiden. Ein solcher Sprung kostet Zeit und geht zulasten der Leistung. Dabei ist das Speichermedium – Hauptspeicher oder Massenspeicher – zunächst unerheblich. Wie dieses Ziel am effektivsten erreicht werden kann, hängt stark vom Zugriffsmuster der Abfragen an die Datenbank ab. Dies wird klarer, wenn Sie einen Blick auf Abbildung 1.2 werfen.
Abbildung 1.2: Typische Zugriffsmuster für OLTP und OLAP auf zeilen- und spaltenbasierten Tabellen (Plattner, 2009)
Dargestellt sind typische Zugriffsmuster in OLTP- und OLAP-Szenarien. Bei einem OLTP-Zugriff werden häufig komplette Datensätze (also Zeilen einer Tabelle) angefragt. Deshalb ergibt es Sinn, diese in einem zusammenhängenden Speicherbereich abzulegen. Bei einem OLAP-typischen Zugriff werden hingegen zumeist die Werte kompletter Spalten aggregiert. In diesem Fall ist es sinnvoller, die Inhalte einer Spalte zusammenhängend abzuspeichern.
OLTP und OLAP
Arbeitsbelastungen im Datenbankumfeld werden häufig in transaktional und analytisch eingeteilt. Dabei haben sich insbesondere die Begriffe Online Transactional Processing (OLTP) bzw. Online Analytical Processing (OLAP) etabliert.Während bei OLTP typischerweise auf einen spezifischen Datensatz (z.B. einen einzelnen Buchungsbeleg) zugegriffen wird, werden bei OLAP sehr viele Datensätze zusammen ausgewertet (z.B. Umsatzzahlen von Produkten).
Um diesen unterschiedlichen Anforderungen Rechnung zu tragen, bietet SAP HANA zwei grundlegende Typen von Tabellen an, die es beide ermöglichen, Daten hauptspeicherbasiert (»In-Memory«) abzulegen:
1. den spaltenbasierten Column Store, der – zusammen mit dem bereits beschriebenen In-Memory-Konzept – das Rückgrat von SAP HANA bildet,
2. den zeilenbasierten Row Store.
Row Store für OLTP?
Obwohl OLTP-Abfragen klar dem typischen Muster für einen zeilenbasierten Speicher folgen, verwendet SAP HANA auch für transaktionale Systeme wie S/4HANA den Column Store. Dies begründet sich in der fortgeschrittenen Optimierung des Column Stores von SAP HANA für transaktionale Abfragen und dem zunehmenden Wunsch, auch analytische Abfragen auf eigentlich transaktionalen Systemen auszuführen – Stichwort: Operational Reporting oder Translytics, einem Kofferwort aus Transactional und Analytics.
Neben den beiden hauptspeicherbasierten Tabellentypen bietet SAP HANA einen festplattenbasierten Column Store namens Dynamic Tiering. Diesen beschreibe ich kurz in Abschnitt 2.3.3.
Auf wichtige Konzepte von Column und Row Store werde ich in den nachfolgenden beiden Abschnitten eingehen.
1.3.1 Der In-Memory Column Store
Im Gegensatz zu den meisten anderen etablierten Datenbanken legt SAP HANA Daten bevorzugt in spaltenbasierter Form ab (Färber, et al., 2011). Den Column Store kann man daher wohl zurecht als das Herzstück von SAP HANA bezeichnen. Obwohl HANA mit dem Row Store und Dynamic Tiering noch weitere Ablagemethoden für Daten bietet, werden in einer typischen HANA-Datenbank üblicherweise weit über 90% aller Daten im Column Store gespeichert. In Verbindung mit einer konsequenten Umsetzung des In-Memory-Paradigmas bringt dies viele Vorteile mit sich, erhöht aber auch die Anforderungen an die Hardware – insbesondere die Größe des Hauptspeichers betreffend.
Weitere Informationen zum Umgang mit Column-Store-Tabellen finden Sie im Abschnitt 5.8.
Aggregation von Daten
Durch die spaltenweise Ablage können Daten in einer gemeinsamen Spalte sehr effizient aggregiert werden, was insbesondere für analytische Szenarien einen sehr hohen Leistungsgewinn mit sich bringt. Dies ergibt sich aus dem Umstand, dass die Werte einer Spalte sequenziell im selben Hauptspeicherbereich abgelegt werden. Sprünge zwischen Speicheradressen – die häufig den CPU-Cache entwerten, wodurch wertvolle CPU-Zyklen verloren gehen – sind daher nur selten nötig.
Komprimierung von Daten
Im relationalen Modell haben die Daten einer Spalte immer denselben Datentyp. Dies wirkt sich positiv auf deren Komprimierung aus, da homogene Daten grundsätzlich deutlich effizienter komprimiert und dekomprimiert werden können. Die höhere Effizienz erstreckt sich dabei sowohl auf den Komprimierungsfaktor als auch auf die Geschwindigkeit. Eine höhere Verdichtung steigert zudem die Datenmenge, die im Hauptspeicher vorgehalten werden kann (Lemke, et al., 2010).
Weiterführende Informationen zur verwendeten Komprimierung finden Sie in Abschnitt 5.8.2.
Parallelisierung
Moderne Serversysteme sind mit einer Vielzahl an Prozessoren bzw. Prozessorkernen ausgestattet. Um diese effektiv nutzen zu können, muss die Arbeitslast ökonomisch auf diese Prozessoren verteilt werden. Diesem Umstand trägt SAP HANA Rechnung, indem die Daten einer Spalte automatisch in Arbeitspakete eingeteilt werden. Diese werden im ersten Schritt an die verfügbaren Prozessoren verteilt. Nicht jeder Prozessor kann dabei gleichermaßen auf jeden Bereich des Hauptspeichers zugreifen. Daher unterstützt SAP HANA Non-Uniform Memory Access (NUMA) (Wagle, et al., 2015). NUMA hat das Ziel, Daten nach Möglichkeit mit dem Prozessor zu verarbeiten, der am effizientesten auf diese Daten zugreifen kann.
1.3.2 Der In-Memory Row Store
Neben dem In-Memory Column Store bietet SAP HANA auch die Möglichkeit, Daten zeilenbasiert im Hauptspeicher abzulegen. Dies ist insbesondere für sehr kleine Tabellen (wenige 100 Zeilen) sinnvoll, deren Einträge sehr häufig geändert werden. Typisch sind hier z.B. Tabellen, die Anwendungen für die Verwaltung von Sperren (Locks) verwenden.
In der Literatur werden zeilenbasierte Datenbanken häufig als für transaktionale Anwendungen besonders effizient nutzbar dargestellt. Dieser Aussage steht entgegen, dass auch klassische transaktionale Anwendungen aus dem Hause SAP – wie die Business Suite und S/4HANA – den Column Store zur Speicherung von Daten bevorzugen. Dazu wurden umfangreiche Optimierungen vorgenommen, die den Column Store auch für transaktionale Arbeitsbelastungen gewappnet haben (Sikka, et al., 2012).
Gleichzeitig war dies ein wichtiger Schritt zur Realisierung der ultimativen Vision hinter SAP HANA als einzige einheitliche Datenbasis für transaktionale und analytische Aufgaben, die den mühsamen Datentransfer in spezialisierte Datenspeicher obsolet macht.
Weitere Informationen zum Umgang mit Row-Store-Tabellen finden Sie im Abschnitt 5.9.
1.4 SAP HANA, express edition
An dieser Stelle möchte ich Ihnen einen kleinen Einblick in eine der größten Neuerungen für die Entwicklergemeinde rund um SAP HANA geben. Die Rede ist von SAP HANA, express edition, häufig auch abgekürzt mit HANA Express bezeichnet.
HANA Express ist – aus technischer Sicht – beinahe identisch mit einer herkömmlichen HANA-Datenbank. Sie ist jedoch speziell dafür ausgelegt, auf deutlich genügsamerer Hardware – z.B. einem Personal Computer – betrieben zu werden, als dies bei einer regulären HANA-Datenbank möglich ist.
Wichtige Unterschiede bestehen außerdem im lizenzrechtlichen Bereich. Für HANA Express gilt:
ausschließlich Community Support,
»Free to use« bis 32 GB Hauptspeicher; bis zu 128 GB können gegen Gebühr lizenziert werden,
nicht freigegeben für den Betrieb von SAP-Anwendungen,
für den Produktivbetrieb ist evtl. eine zusätzliche Betriebssystemlizenz notwendig.
Einschränkungen im Funktionsumfang
Neben den eben beschriebenen Unterschieden bestehen Einschränkungen hinsichtlich des Funktionsumfangs. Diese betreffen Bereiche, die insbesondere für Unternehmensanwendungen relevant sind. Als Beispiele seien hier »Hochverfügbarkeit«, die Skalierung mittels »Scale-out« und »Daten-Tiering« genannt.
Einstieg in SAP HANA, express edition
Der Einstieg in SAP HANA, express edition wird auf der folgenden Website detailliert erläutert:https://developers.sap.com/germany/topics/sap-hana-express.html.
Ausführungen
SAP HANA, express edition ist in zwei Ausführungen verfügbar:
1. nur die SAP-HANA-Datenbank – mindestens 8 GB Hauptspeicherbedarf,
2. SAP-HANA-Datenbank inkl. der Extended Application Services, advanced model (XSA) – mindestens 16 GB Hauptspeicherbedarf.
Beide Angaben berücksichtigen nicht den Hauptspeicher, der zusätzlich zur Speicherung von Daten benötigt wird.
XSA erweitert SAP HANA um eine Anwendungsplattform, die als Basis für eigene, aber auch für verschiedene Anwendungen der SAP genutzt werden kann. Beispielsweise basiert das mittlerweile von SAP bevorzugte Administrationswerkzeug SAP HANA Cockpit auf XSA.
Bereitstellungsmethoden
Um der Entwicklergemeinde den Start mit SAP HANA, express edition möglichst leicht zu machen, werden verschiedene Bereitstellungsmethoden angeboten:
Binärinstallation,
Abbild einer virtuellen Maschine (VMWare),
Docker Container.
Zusätzlich offerieren mittlerweile einige der großen Cloud-Anbieter einen Zugriff auf die SAP HANA, express edition. Dadurch ist es auch ohne eigene Hardware möglich, eine »kleine« HANA-Datenbank für Testzwecke einzurichten.
Dadurch, dass HANA Express frei verfügbar ist und die Hardwareanforderungen – für HANA-Verhältnisse – relativ genügsam sind, eignet sich diese Version sehr gut zu Demonstrationszwecken. Im Kontext dieses Buches ermöglicht HANA Express Ihnen als Leser, die in diesem Buch beschriebenen Sachverhalte einfach nachzuvollziehen, selbst wenn Sie ansonsten keinen Zugang zu einer HANA-Datenbank haben.
2 Systemlandschaft
Bei jeder Einführung einer neuen Technologie steht ganz am Anfang der Aufbau der Systemlandschaft. SAP HANA bietet hier vielfältige Möglichkeiten, diese an die jeweiligen Bedürfnisse anzupassen – setzt aber an anderer Stelle auch starre Grenzen.
In diesem Kapitel möchte ich Ihnen einen Einblick in den Aufbau der Systemlandschaft einer SAP-HANA-Datenbank geben. Neben grundlegenden Themen wie der geeigneten Hardware und den unterstützten Betriebssystemen werde ich darauf eingehen, wie die Hardware zu dimensionieren ist und welche Möglichkeiten bestehen, SAP HANA zu skalieren. Außerdem werde ich Varianten vorstellen, mittels derer sich Anwendungen eine HANA-Datenbank teilen können.
2.1 Betriebssystem
SAP HANA wird seit jeher exklusiv für Linux angeboten. SAP unterhält Partnerschaften mit SUSE (bzw. Novell) und Red Hat, um sicherzustellen, dass SAP HANA auf den Distributionen beider Hersteller ohne Probleme lauffähig ist.
Offiziell unterstützt SAP HANA die folgenden Distributionen:
Red Hat Enterprise Linux for SAP Solutions,
Red Hat Enterprise Linux for SAP HANA,
SUSE Linux Enterprise Server for SAP Applications,
SUSE Linux Enterprise Server.
Auf anderen Linux-Distributionen ist SAP HANA zwar mitunter durchaus lauffähig. Diese werden jedoch nicht offiziell unterstützt, was die Behebung von Fehlern erschweren kann. Auch bietet die SAP keinerlei Hilfe – z.B. in Form einer Dokumentation – für die Konfiguration dieser Distributionen. Der Betrieb von SAP HANA erfolgt dort demnach auf eigene Verantwortung.
Konfiguration des Betriebssystems
Für einen optimalen Betrieb müssen auch bei der Konfiguration des Betriebssystems einige Dinge beachtet werden. Eine diesbezügliche Übersicht finden Sie in den folgenden SAP-Hinweisen:
1824819 – SUSE Linux Enterprise Server 11 SP2,1954788 – SUSE Linux Enterprise Server 11 SP3,2013638 – Red Hat Enterprise Linux 6.5,2136965 – Red Hat Enterprise Linux 6.6.Bei der Wahl des Betriebssystems sollten Sie beachten, dass unterschiedliche Versionen von SAP HANA mitunter verschiedene Versionsstände des Betriebssystems erfordern. So ist SAP HANA 1.0 beispielsweise für SUSE Linux Enterprise Server ab Version 11 SP3 freigegeben, während SAP HANA 2.0 mindestens Version 12 SP1 erfordert. Wichtig ist zudem die passende Prozessorarchitektur des Systems, auf dem SAP HANA installiert wird. Für Systeme auf Basis von Intels x86-Architektur gelten andere Einschränkungen als für Systeme, die IBM-Power-CPUs verwenden.
Eine aktuelle Übersicht der jeweils unterstützten Betriebssysteme und Betriebssystemversionen zeigen Tabelle 2.1 (für Intel CPUs) und Tabelle 2.2 (für IBM Power CPUs).
SAP HANA 1.0 (Intel)
SAP HANA 2.0 (Intel)
SLES 11 SP 2
nur bis SPS 11
-
SLES 11 SP 3
ab SPS 10
-
SLES 11 SP 4
ab SPS 10
-
SLES 12
ab SPS 10
-
SLES 12 SP 1
ab SPS 12
ab SPS 00
SLES 12 SP 2
ab SPS 12
ab SPS 01
SLES 12 SP 3
ab SPS 12, Rev. 122.15
ab SPS 02, Rev. 23
SLES 12 SP 4
ab SPS 12, Rev. 122.22
ab SPS 03, Rev. 35
SLES 15
ab SPS 12, Rev. 122.21
ab SPS 03, Rev. 34
SAP HANA 1.0 (Intel)
SAP HANA 2.0 (Intel)
RHEL 6.5
bis SPS 11
-
RHEL 6.6
bis SPS 11
-
RHEL 6.7
ab SPS 11
-
RHEL 6.10
ab SPS 12, Rev. 122.23
RHEL 7.2
ab SPS 12
ab SPS 00
RHEL 7.3
ab SPS 12
ab SPS 02, Rev. 21
RHEL 7.4
ab SPS 12, Rev. 122.14
ab SPS 00, Rev. 23
RHEL 7.5
ab SPS 12, Rev. 122.19
nur SPS03, ab Rev. 32
RHEL 7.6
ab SPS 12, Rev. 122.23
ab SPS 03, Rev. 36
Tabelle 2.1: Betriebssystemunterstützung mit Intel x86 CPUs
SAP HANA 1.0 (IBM)
SAP HANA 2.0 (IBM)
SLES 11 SP 4
ab SPS 11
-
SLES 12 SP 1
-
ab SPS 00
SLES 12 SP 2
-
ab SPS 02
SLES 12 SP 3
-
ab SPS 02, Rev. 23
SLES 12 SP 4
-
ab SPS 03, Rev. 35
SLES 15
-
ab SPS 03, Rev. 34
RHEL 7.3
-
ab SPS 02, Rev. 21
RHEL 7.4
-
ab SPS 02, Rev. 23
RHEL 7.6
-
ab SPS 03, Rev. 36
Tabelle 2.2: Betriebssystemunterstützung mit IBM Power CPUs
SAP-HANA-unterstützte Betriebssysteme
Einen stets aktuellen Überblick über die von SAP HANA unterstützten Betriebssysteme finden Sie in SAP-Hinweis 2235581 – »SAP HANA: Supported Operating Systems«.
2.2 Hardware
SAP HANA stellt aufgrund der bereits in Abschnitt 1.2 angesprochenen Paradigmen, sämtliche Daten kontinuierlich im Hauptspeicher zu halten, grundsätzlich hohe Anforderungen an die zugrunde liegende Hardware.
