19,99 €
Mehr erfahren.
- Herausgeber: Espresso Tutorials
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Deutsch
Mit der HANA stellt die SAP dem Kunden eine höchst leistungsfähige Datenbank zur Verfügung. Allerdings ist es eine hohe Kunst für den Datenbankadministrator, dieses komplexe Konstrukt so zu steuern, dass sich bei optimal dimensionierter Hardware ein Maximum an Leistung aus ihm »herauskitzeln« lässt und dabei größtmögliche Stabilität gewahrt bleibt.
In diesem Fachbuch teilen zwei Spezialisten für HANA-Migrationen und HANA-Optimierung ihren jahrelangen Erfahrungsschatz und stellen so einen umfangreichen Werkzeugkasten zur Verfügung, der dem HANA-Verantwortlichen hilft, die Leistung »seiner« Datenbank noch weiter zu verbessern. Sie lernen die SQL-Skriptsammlung als wichtiges Analysetool kennen, erfahren, wie Sie diese richtig interpretieren, tauchen ein in entscheidende Fakten zum Thema System Sizing und erhalten wertvolles Hintergrundwissen zur Datenbankwartung und zur Parametrisierung. Im Anschluss steigen Sie tief in das Thema Workload Management ein und erfahren, wie die HANA mit CPU-Ressourcen umgeht und wie sich daran zum Nutzen der Performance »schrauben« lässt. Ebenso eingehend wird das Thema der Tabellen-Partitionierung behandelt und wie Sie diese Vorgehensweise optimal einsetzen. Weitere Themen sind der HANA Optimizer, Hints und Indizes. Nicht fehlen dürfen ein Kapitel zum Thema Troubleshooting sowie eine ausführliche Darstellung weiterer Analysetools, die Ihnen zur Verfügung stehen.
Freuen Sie sich auf einen unterhaltsamen und spannenden Deepdive zum Thema SAP HANA!
- Optimales Zusammenspiel zwischen Systemressourcen und Applikationen
- HANA feinjustieren – für einen entspannten Admin-Alltag
- SQL-Skriptsammlung und weitere Analysetools: Bedienung und Interpretation
- Echte Praxisbeispiele – inklusive typischer Fallstricke
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 250
Veröffentlichungsjahr: 2025
Ähnliche
Jens GleichmannMatthias Sander
SAP HANA® Deepdive: Optimierung und Stabilität im Betrieb
Jens Gleichmann, Matthias SanderSAP HANA® Deepdive: Optimierung und Stabilität im Betrieb
ISBN:978-3-960124-18-4 (E-Book)
Lektorat:Bernhard Edlmann
Korrektorat:Sarah Trenca
Coverdesign:Philip Esch
Coverfoto:iStockphoto.com | piola666 No. 1159823433
Satz & Layout:Johann-Christian Hanke
1. Auflage 2025
© Espresso Tutorials GmbH, Gleichen 2025
URL:www.espresso-tutorials.de
Das vorliegende Werk ist in allen seinen Teilen urheberrechtlich geschützt. Alle Rechte sind 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 die 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: https://forum.espresso-tutorials.com/.
Eine Auswahl weiterer Bücher von Espresso Tutorials:
Andreas Schuster:
Praxishandbuch SAP
®
HANA – Administration
Manfred Sprenger:
Praxishandbuch SAP
®
-Basis – Troubleshooting in der Systemadministration
Manfred Sprenger:
Praxishandbuch SAP
®
-Berechtigungswesen
Manfred Sprenger:
Fortgeschrittene Techniken im SAP
®
-Berechtigungswesen inklusive Fiori und J2EE
Vorwort
Die HANA-Datenbank hat seit der Veröffentlichung im Jahr 2011 für viel Aufsehen gesorgt. Durch die Positionierung der neuen Produkte S/4 und BW/4 wurde eine große Veränderung für Administratoren eingeleitet. Datenbanken wurden bis dahin bei größeren Firmen in einem eigenen Team ausgegliedert. Bei HANA, der neuen Datenbank von SAP, verhielt sich das oftmals anders, denn alles, was von SAP als technisches Produkt in das Unternehmen kam, wurde von der SAP-Abteilung – meistens dem SAP-Basis-Team – übernommen. Damit erbte das Team auch erstmals eine Datenbank. Zu bereits komplexen Themengebieten kam nun ein weiteres, vollkommen neues Gebiet hinzu, in dem die meisten Mitarbeiter noch keine Erfahrung gesammelt hatten.
Ziel der meisten Firmen ist es, ein stabiles und performantes System zu betreiben. Dies kann aber nur mit genügend Zeit für Innovation und entsprechende Weiterbildung der internen Mitarbeiter funktionieren. Nur durch ausreichend Fokus wird man zum Experten in dem Bereich.
Nach Erscheinen zahlreicher Fachbücher, die uns beiden zu oberflächlich vorkamen und zu wenig Praxisbezug hatten, wurde die Idee geboren, unser eigenes Kapitel zur Fachliteratur beizusteuern.
Dieses Buch ist nicht als Einsteigerliteratur im Bereich HANA geeignet. Idealerweise sollten Sie entweder bereits einige Jahre Erfahrung vorzuweisen haben oder durch Fortbildungen und Bücher (HA*-Kurse der SAP, Bücher/Lernplattform Espresso Tutorials) für die nötige Basis sorgen. Ohne das nötige Basiswissen können einige Zusammenhänge nicht zu hundert Prozent verstanden werden. Sie sollten daher über die Grundlagen wie die Funktionsweise des Column Store oder Savepoints bereits genau Bescheid wissen.
Die HANA ist keine selbstoptimierende Datenbank, die keine Datenbankadministratoren mehr benötigt, sondern ein hochkomplexes Konstrukt aus mehreren HANA Engines. Wie bei anderen Datenbanken gilt: Diese müssen manchmal in die richtige Richtung gelenkt werden. In diesem umfangreichen Deepdive-Buch erklären wir Ihnen, wie Sie das Verständnis dieses Themas mit der Umsetzung in Einklang bringen. Viel Spaß beim Abtauchen in die Tiefen der HANA!
Gliederung
Im ersten Teil des Buches gehen wir auf die Systemstabilität ein. Darunter fallen Themenbereiche wie Sizing (Kapitel 2), Maintenance (Kapitel 3), Parametrisierung (Kapitel 4) und das umfangreiche Kapitel zu Workload Management (Kapitel 5), die Grundlage für die weiteren Kapitel sind.
In den weiteren Kapiteln stellen wir die einzelnen Aspekte dar, die zur Systemperformance beitragen. Hier finden Sie wichtige Informationen wie z.B. zum HANA Optimizer (Kapitel 6), zur Partitionierung (Kapitel 7), zu HANA Hints (Kapitel 8) oder auch zu HANA-Indizes (Kapitel 9).
Im letzten Teil des Buches geben wir Einblicke in das Thema Troubleshooting (Kapitel 10) und dazugehörige Lösungsansätze mit der SQL-Sammlung. Sie sind in jedem System replizierbar. Das letzte Kapitel widmet sich verschiedenen Tools (Kapitel 11), die zur Analysezwecken eingesetzt werden können. Es bildet damit die Klammer um die vorherigen Themenkomplexe.
Dank
Ein Buch zu schreiben bedeutet nicht nur, einen langen Weg auf sich zu nehmen – man benötigt auch viel Verständnis von Familie und Kollegen. Daher möchten wir die Gelegenheit wahrnehmen, uns hierfür zu bedanken. An erster Stelle sind zunächst unsere Familien zu nennen.
Jens möchte sich ganz besonders bei seiner Frau Lisa bedanken, die ihm stets den Rücken stärkte und ihm die nötige Unterstützung gab, auch wenn das Buchprojekt, das zusätzlich zur normalen Projektarbeit zu bewältigen war, die gemeinsame Zeit auf ein Minimum reduzierte. Lisa, ohne deine Hilfe wäre das Buch in dieser Form nie möglich gewesen.
Matthias dankt seiner Frau Eva für ihre Motivationskraft und ihr Verständnis während der letzten Monate. Ohne diesen Zuspruch und die Unterstützung wäre der Antrieb, dieses Buch zu schreiben, nicht derselbe gewesen. Vielen Dank, Eva!
Dann wollen wir uns bei Martin Frauendorfer bedanken. Er hat die SQL-Skriptsammlung des SAP-Hinweises 1969700 ins Leben gerufen. Vorher pflegte er bereits eine ähnliche Sammlung im Oracle-Umfeld. Diese SQL-Anweisungen ermöglichen detaillierte Prüfungen im Fehlerfall oder Empfehlungen für die Parametrisierung. Diese essenzielle Toolbox hat maßgeblich dazu beigetragen, dass Datenbankadministratoren heute einen stabilen Betrieb gewährleisten können.
Herzlichen Dank, Martin, für deine Energie und deinen unermüdlichen Einsatz und dafür, diese kostenfreie Skriptsammlung jedem zur Verfügung zu stellen! Ebenso bedanken wollen wir uns für Dein offenes Ohr und die Einarbeitung unserer Anforderungen an die Skripte.
Ein dickes Dankeschön geht auch an Lars Breddemann, Kuto Baran und Christian Braukmüller. Alle drei haben in der Vergangenheit viel für die SAP Community beigesteuert und dadurch für Aufklärung in vielen Themenbereichen gesorgt. Sie haben mit ihrem Feedback zu unserem Manuskript erheblich zur Qualitätssteigerung beigetragen.
Unsere XLC-Kollegen Dominik Fiedler und Michael Hermsen haben durch ihre Ideen und Korrekturen maßgeblich an den Inhalten mitgewirkt. Danke für Eure Mitgestaltung!
An dieser Stelle vielen Dank an unseren Lektor, der uns immer bei diesem Projekt unterstützt hat und uns wertvolle Tipps für fesselnden Lesestoff geliefert hat.
Jetzt wünschen wir Ihnen viel Spaß beim Abtauchen in die interessanten Themenkomplexe der HANA!
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.
Übungsaufgabe
Übungsaufgaben helfen Ihnen, Ihr Wissen zu festigen und zu vertiefen.
Die Form der Anrede
Um den Lesefluss nicht zu beeinträchtigen, verwenden wir im vorliegenden Buch bei personenbezogenen Substantiven und Pronomen zwar nur die gewohnte männliche Sprachform, meinen aber gleichermaßen Personen weiblichen und diversen Geschlechts.
1 SQL-Skriptsammlung
Die SQL-Skriptsammlung der SAP aus dem Hinweis 1969700 ist aus dem Alltag eines HANA-DBA kaum noch wegzudenken. Gleichermaßen ist sie die Grundlage für alle weiteren Kapitel dieses Buches. Unsere Bitte an Sie ist daher, sich damit vertraut zu machen, da es ohne diese Details schwer wird, die nötigen Informationen aus dem System auszulesen. Dieses Kapitel legt den Grundstock für das Verständnis dieser Skripte.
2024 feierte die Skriptsammlung ihr 10-jähriges Jubiläum und umfasst bereits über 400 Skripte. Lange Zeit fehlten echte Monitoringwerkzeuge, um die nötigen Analysedaten im Fehlerfall zu ermitteln. Ähnlich wie in der Oracle-Skriptsammlung (SAP-Hinweis 1438410), die ursprünglich auch aus der Feder von Martin Frauendorfer stammt, werden die Monitoring Views des Systems abgefragt und sinnvoll aus mehreren Quellen kombiniert. Diese Sammlung schließt also die Lücke, die bis heute kein Tooling schließen konnte: detaillierte Informationen mit einem hohen Grad an Individualisierung.
Nutzungshinweis
Alle SQLs in der Sammlung sind lediglich zum Auslesen von Daten bzw. Generieren von Kommandos gedacht und ändern niemals aktiv Daten oder Konfigurationen im System.
1.1 Import
Wie Sie die Sammlung importieren und benutzen, erfahren Sie in diesem Abschnitt.
Wir empfehlen zur Nutzung der SQL-Skriptsammlung das HANA Cockpit mit dem Database Explorer. Sollte Ihnen der Zugang zu einem HANA Cockpit nicht zur Verfügung stehen, raten wir bei einem ABAP-System, das DBACOCKPIT (via SQL Editor) zu nutzen. Als Alternative – für eine lokale Installation für jegliche HANA-Datenbank – empfehlen wir das Tool Visual Studio Code, das in Abschnitt 11.1.3 näher beschrieben wird.
FAQ zum HANA Cockpit
SAP-Hinweis 2222220 »FAQ: SAP HANA DBACOCKPIT«: https://me.sap.com/notes/2222220
Wir gehen im Folgenden von der Nutzung des HANA Cockpit aus.
Im Kontextmenü der Instanzen auf der linken Seite des Database Explorer können Sie auf die Skripte zugreifen und diese aktualisieren. Unter dem Punkt Show Statement Library, wie in Abbildung 1.1 zu sehen, öffnen Sie die Übersicht zu der Skriptsammlung. Wir empfehlen, diese monatlich zu aktualisieren, da fast jede Woche Änderungen an Parametern oder Verbesserungen veröffentlicht werden. Dies muss manuell via Import-Button durchgeführt werden. Die aktuellen SQL-Skripte sind dem Anhang des SAP-Hinweises 1969700 zu entnehmen und können direkt im *.zip-Format importiert werden. Um auf dem neuesten Stand zu bleiben, ist es ratsam, wichtige SAP-Hinweise wie diesen als Favorit zu markieren. Damit erhalten Sie bei Änderungen, soweit in den Mitteilungseinstellungen im »SAP for Me«-Portal aktiviert, eine Benachrichtigung.
Abbildung 1.1: HANA Cockpit: Öffnen der SQL-Sammlung im Database Explorer
Aktualisierung der SQL-Sammlung
Wir empfehlen die zyklische Aktualisierung der Skripte. Spätestens wenn Sie die HANA-Revision wechseln, sollte ein Update erfolgen, da gerade die neuen Parameter im Parameterskript absolut essenziell für die Stabilität des Systems sind.
1.2 Filtern und Suchen
Das Filtern und Suchen sollte für die meisten eine einfache Übung sein. Leider ist die Nutzung nicht intuitiv genug, daher erfahren Sie in diesem Abschnitt alles Wissenswerte rund um diese Funktionen.
Die meisten, die zum ersten Mal die Funktion der Statement Library verwenden, wollen das Suchfeld rechts oben in Abbildung 1.2 für die Suche nach dem passenden Skript verwenden. Damit suchen sie allerdings in den Skripten selbst und nicht nach den Namen der Skripte. Für das Auffinden eines bestimmten Skripts anhand des Namens empfehlen wir die Filterfunktion in der Ausgabeliste. Diese erreichen Sie mit einem Klick auf Name. Die Suchfunktion ist aus unserer Sicht lediglich dann hilfreich, wenn Sie nach bestimmten Monitoring Views oder Ausgabefeldern suchen.
Abbildung 1.2: Statement Library: Filtern und Suchen
1.3 Aufbau
Jedes der Skripte hat dieselbe Struktur und beginnt mit einem langen Kommentar (siehe Listing 1.1). Dieser ist wichtig, um zu verstehen, was von wo selektiert wird und wie es zu interpretieren ist. Worauf zu achten ist, erklärt Ihnen dieser Abschnitt.
[NAME] [DESCRIPTION] [SOURCE] [DETAILS AND RESTRICTIONS] [VALID FOR] [SQL COMMAND VERSION] [INVOLVED TABLES] [INPUT PARAMETERS] [OUTPUT PARAMETERS] [EXAMPLE OUTPUT]
Listing 1.1: Aufbau der Skripte
Einige Sektionen wie der Namen des Skripts, die Beschreibung, die Gültigkeit (in Bezug auf die HANA-Revision) und die Versionshistorie sind selbsterklärend. Wir wollen hier etwas tiefer auf die verbleibenden eingehen.
INVOLVED TABLES
– Dank der Kenntnis, welche Tabellen einbezogen werden, können Sie sich schnell eigene Skripte schreiben, um ein Monitoring zu ermöglichen.
INPUT PARAMETERS
– Durch die Eingabevariablen können Sie sowohl die Selektion als auch die Aggregation und Sortierung beeinflussen. Welche Möglichkeiten es hierbei gibt und wie Sie diese umsetzen, haben wir für Sie detailliert in
Abschnitt 1.4
zusammengefasst.
OUTPUT PARAMETERS
– In der Sektion der Ausgabeparameter wird jedes Feld für die Interpretation genau beschrieben. Hier finden Sie außerdem die Einheit jedes Ausgabefelds.
EXAMPLE OUTPUT
– Sollten Sie das Skript zum ersten Mal benutzen, empfehlen wir zuerst einen Blick in die Beispielausgabe. Damit erkennen Sie schnell, ob das Skript für Ihre Zwecke dienlich ist. Anhand des Namens des Ausgabefelds erkennen Sie die Einheit. Beispielsweise beschreibt MAX_FILE_GB die maximal Dateigröße in Gigabyte.
Einheit in der Ausgabe
Können Sie einmal die Einheit nicht zuordnen, empfehlen wir Ihnen zur Ermittlung die View M_MONITOR_COLUMNS zu nutzen. Im Beispielcoding (siehe Listing 1.2) suchen wir die Einheit des Felds INDEX_CREATE_DURATION.
Listing 1.2: Einheiten pro Monitoring View zuordnen
1.4 Modification Section
Um die im vorherigen Abschnitt erwähnten Eingabeparameter zu nutzen, benötigen Sie die sogenannte Modification Section. Wie Sie diese Sektion finden und benutzen, erfahren Sie in diesem Unterkapitel.
Hat das von Ihnen gewählte Skript im Kommentarbereich Eingabeparameter, besitzt es ebenso eine Sektion, die Sie mit der Suchfunktion finden. Dazu geben Sie in das Suchfeld Modification Section ein. Dort finden Sie alle Eingabeparameter, die beeinflusst werden können, in folgendem Format:
'Wert' Name der Variable
Oftmals finden Sie auch noch mögliche Werte im Kommentar. In unserem Beispiel aus dem Skript HANA_Configuration_MiniChecks_2.00.073+ (siehe Listing 1.3) sind dies die Werte für ORDER_BY, HOST oder CHECK.
(SELECT /* Modification section */ '%' HOST, ' ' ONLY_POTENTIALLY_CRITICAL_RESULTS, 'X' SKIP_LESS_RELEVANT_CHECKS_IN_SYSTEMDB, 'X' SKIP_OVERLAPPING_CHECKS_IN_SYSTEMDB, 60 MAX_VALUE_LENGTH, -1 CHECK_ID, '%' CHECK_GROUP, 'M' CHECK_ID_PREFIX, 1 SHORTTERM_DAYS, 7 MIDTERM_DAYS, 31 LONGTERM_DAYS, 'CHECK' ORDER_BY /* HOST, CHECK */
Listing 1.3: Skript HANA_Configuration_MiniChecks – Modification Section
SQL-Anweisungssammlungsreports für SAP HANA
Die Bookmark von SQL-Anweisungssammlungsreports in Reports der SQL-Skriptsammlung für SAP HANA finden Sie unter: https://me.sap.com/notes/3311408.
Es gibt zwei Besonderheiten zu beachten. Zum einen ist dies die Datenquelle (Eingabefeld: DATASOURCE, siehe Listing 1.4). Hier gibt es zwei Möglichkeiten:
CURRENT
: Daten aus M_*-Tabellen
HISTORY
: Daten aus HOST_*-Tabellen
CURRENT beinhaltet die gesammelten Daten von Threads aus den letzten 2 Stunden. Für viele weitere Monitoringdaten gilt meist der letzte Datenbankstart als ältester Wert. Wollen Sie aktuelle Daten analysieren, ist dies die richtige Wahl. In allen anderen Fällen empfehlen wir die Datenquellen HISTORY zu verwenden.
Die andere Besonderheit ist die SITE_ID (siehe Listing 1.4). Seit HANA 2.0 SPS06 werden auch Daten aus allen verbundenen Remotesystemen gesammelt, die in die HANA System Replication (HSR) eingebunden sind. Sollten Sie keine HSR nutzen, ignorieren Sie diese Einstellung. In allen anderen Fällen achten Sie auf den gesetzten Wert. Soll nur die aktive Seite verwendet werden, verwenden Sie den Wert via Variable CURRENT_SITE_ID(). Wird dies nicht beachtet, bekommen Sie die Daten beider Seiten in einem Report angezeigt. Das Mischen der Daten führt bei einer Analyse zu Verwirrungen und fehlerhaften Folgerungen.
CURRENT_SITE_ID() SITE_ID, 'HISTORY' DATA_SOURCE,
Listing 1.4: Besonderheiten bei Eingabeparametern
1.5 Ausführung
Die Ausführung kann von jedem unterstützen SQL-Client erfolgen. Dennoch gibt es gewisse Feinheiten zu beachten, um eine korrekte Ausgabe sicherzustellen. Die Details lesen Sie in diesem Abschnitt.
Viele Clients wie das HANA Studio in Eclipse oder auch der Database Explorer im HANA Cockpit haben voreingestellte Limitierungen für die Ausgabe. Diese umfassen die Anzahl und die Breite der Ausgabezeilen. Viele der Skripte geben mehr als 1000 Zeilen aus, daher empfehlen wir diesen Wert auf 10.000 anzuheben. Analysieren Sie oft SQL-Befehle, raten wir dazu, auch die Breite auf einen höheren Wert anzupassen.
Prüfen Sie vor jeder Ausführung auch die Eingabevariablen, da diese ab und an mit geänderten Werten ausgeliefert werden.
Anpassung der Limitierungen für die Ausgabe
Wir empfehlen die Anpassung der limitierenden Werte für die SQL Console im Database Explorer des HANA Cockpit wie in Abbildung 1.3:
Byte limit for Large Objects (LOBs):4.194.304 (4MB)Max number of rows to display:10.000Dies ist ebenso im SAP-Hinweis 3131569 erläutert.
Abbildung 1.3: HANA Cockpit – Einstellungen im Database Explorer
1.6 Ausgabeformat
Das Ausgabeformat orientiert sich an der Anzahl und Breite der Ausgabefelder. In vielen Skripten gibt es nicht viel zu beachten. In einigen wenigen, die als Bericht formatiert sind, ist es ratsam, das Ergebnis in einer Textdatei auszugeben. Dazu exportieren Sie das Ergebnis mit der Dateiendung ».txt«. Da die Ausgabe der Zahlen dem englischen Standard entspricht, gibt es zwei Varianten, die Daten in einem Tabellenauswertungstool lesbar zu importieren:
Suchen und Ersetzen von ».« durch »,«
Umstellung des Systemtrenners im Tool selbst
Umstellung in Excel
Mac: Einstellungen • Bearbeiten • Verwenden von SystemtrennerDezimaltrennzeichen ».«Tausendertrennzeichen »,«
Windows: Datei • Optionen • Erweitert • Trennzeichen vom Betriebssystem übernehmenDezimaltrennzeichen ».«Tausendertrennzeichen »,«
Die Darstellung der Einstellung können Sie Abbildung 1.4 und Abbildung 1.5 entnehmen.
Abbildung 1.4: Mac: Umstellung der Trennzeichen in Excel
Abbildung 1.5: Windows: Umstellung der Trennzeichen in Excel
Die wahrscheinlich bekanntesten SQL-Skripte, die als Bericht ausgegeben werden, sind:
HANA_SQL_StatementHash_DataCollector
HANA_Tables_DataCollector
HANA_Global_TimeFrameReport
HANA_Global_CurrentStateReport
2 HANA System Sizing
Allein zum Thema der korrekten Größe einer HANA-Instanz unter Berücksichtigung der Plattform könnten wir ein ganzes Buch füllen. Es ist ein iterativer Prozess, der oftmals nur eine Momentaufnahme darstellt. In diesem Abschnitt geht es also um das Messen und Auswerten der wichtigsten KPIs. Es geht nicht um die Zuweisung der Instanzgrößen unter Berücksichtigung der Limitierung pro Plattform.
Dabei gibt es mehrere Möglichkeiten, ein HANA-Sizing durchzuführen. Läuft Ihr SAP-System aktuell noch nicht auf HANA, empfehlen wir den ABAP Sizing Report. Für eine Verifizierung des HANA-Sizings eines bereits laufenden Systems gibt es mehrere Varianten:
Sizing Report
HANA Cockpit
SQL-Skriptsammlung
EWA-Dashboard
Lesetipps zum HANA-Sizing
Sollten Sie noch keinerlei Berührungspunkte mit dem Thema Sizing haben, empfehlen wir das Kapitel »Dimensionierung« im »Praxishandbuch SAP HANA – Administration« (Schuster, Espresso Tutorials, 2019: http://5265.espresso-tutorials.de) und die sehr ausführlichen Dokumente der SAP zu dem Thema, die auch Non-SAP-Ansätze beschreibt: https://es-tu.de/H1y9.
2.1 KPI: Hauptspeicher
Die wichtigste Kennzahl im Sizing ist der Hauptspeicher (RAM). Um diesen Wert richtig zu deuten, ist es essenziell zu wissen, wie die HANA den RAM verwendet. Hiermit beschäftigen sich die nächsten Seiten.
2.1.1 Verwendung des Hauptspeichers durch HANA
Als Trainer im HANA-Umfeld hören wir in unseren Schulungen und Workshops häufig Aussagen, die nicht ganz der Wahrheit entsprechen. Etwa diese: »HANA hält immer alle Daten vollständig im Hauptspeicher.« Richtig ist: HANA hält die wichtigsten Daten im Hauptspeicher und kann nach Load- und Unload-Kriterien (inklusive Behandlung besonderer Cache-Bereiche, wie LOB-Cache) jederzeit Daten auslagern. Das gilt erst recht seit dem Einsatz von Data-Tiering-Techniken wie NSE (Native Storage Extension). Mit diesem Feature können selektiv Daten ausgelagert werden und bei Bedarf (=Datenzugriff) in einen Puffer (NSE Buffer Cache) geladen werden, der einen limitierten Speicherbereich im RAM einnimmt. Das Ziel dabei ist, den Puffer überzubelegen, sodass mehr Daten ausgelagert werden. Das Delta zwischen ausgelagerten Daten und Puffer ist die erzielte Einsparung an Hauptspeicher.
NSE – Details
Zum Thema NSE existiert noch keine tiefergehende Literatur. Allerdings wurden bereits Blogs und etliche SAP-Hinweise verfasst.
»FAQ: SAP HANA Native Storage Extension (NSE)«: https://me.sap.com/notes/2799997[HANA] NSE part I – tech. details Q&A: https://es-tu.de/RqsTgBDetails Q&A: https://es-tu.de/tPvq»FAQ: SAP HANA LOBs«: https://me.sap.com/notes/2220627Oft hört man auch die Aussage: »Die Monitoringtools des Betriebssystems zeigen stetig einen hohen Hauptspeicherverbrauch an, und die HANA nimmt sich zu viel Speicher.« Richtig ist: Die HANA-Datenbank verwaltet den Speicher, den sie vom Betriebssystem anfordert, selbst und gibt ihn nur in bestimmten Situationen wieder zurück. Denn bereits allokierter und vordefinierter Speicher kann schnell wiederverwendet werden. Das spart Zeit, und meist laufen keine anderen nennenswerte Programme neben der HANA auf dem System. Daher empfehlen wir, sich nicht auf ein OS-Monitoring zu fokussieren und die richtigen KPIs in der HANA selbst zu monitoren.
Im HANA-Sprachgebrauch unterscheiden wir zwei RAM-Bereiche:
Working Space
oder auch
Dynamic RAM
Payload
(Nutzdaten) oder auch
Static RAM
Der Payload besteht aus den Tabellen (Column + Row Store) der Datenbank. Die Bezeichnung »Static« ist, wenn man das stetige Laden und Entladen der Tabellen betrachtet, nur bedingt zutreffend. Im Vergleich dazu ist die Begrifflichkeit »Dynamic« für den sogenannten Working Space mehr als zutreffend. Dabei handelt es sich um den Hauptspeicher, der nach Allokation von Betriebssystem, HANA Code & Stack und Nutzdaten übrig bleibt. In diesem per Definition sehr dynamischen Bereich werden alle SQL-Anfragen abgearbeitet. Operationen wie Sortieren und Gruppieren oder auch temporäre Ergebnismengen verwenden ebenso diesen fluktuierenden Teil des RAM, der in der Fachsprache auch als Heap bekannt ist. Als Heap wird alles in der HANA bezeichnet, was nicht dem »Shared Memory« zuzuordnen ist. All diese Details finden Sie in einem umfassenden Schaubild in Abbildung 2.1.
Abbildung 2.1: HANA Hauptspeicher Allokation
Von SAP wird eine 1:1-Verteilung auf die Bereiche Working Space (50%) und Payload (50%) empfohlen. Dies ist in den meisten Fällen sehr großzügig und erlaubt daher auch meistens einige Jahre an Wachstum. In der heutigen Zeit der Virtualisierung und des Cloud-Computings empfehlen wir aus Kostengründen, etwas restriktiver mit den Ressourcen umzugehen. Wenn der Workload bekannt ist und das Wachstum gut prognostiziert werden kann, tendieren wir zu einer Überallokation des Payload-Bereichs. Dies ist keine allgemeine Empfehlung, sondern abhängig vom jeweiligen Workload des Systems. In den meisten Szenarien ist eine Verteilung von 70% Nutzdaten zu 30% Working Space das Maximum im OLTP-Bereich, ohne die Stabilität zu gefährden.
Die grundlegende Frage ist: Wann sollte ein System neue Ressourcen erhalten? Auf der einen Seite darf auf keinen Fall die Stabilität gefährdet werden und ein Speicherengpass eintreten. Auf der anderen Seite stehen die Hardwarekosten. In letztlich nicht genutzte Ressourcen zu investieren, nur um für die nächsten fünf Jahre gerüstet zu sein, können wir aufgrund der schnellen Technologieentwicklung nicht empfehlen. Viel besser ist es, die richtigen Kennzahlen zu überwachen und frühzeitig Maßnahmen für ein Resizing zu ergreifen.
2.1.2 HANA-Resizing
Der Prozess eines Resizings ist in Abbildung 2.2 dargestellt.
Abbildung 2.2: HANA-Resizing
Sie erkennen die Aufteilung einer 2-TB-Zuweisung in 1 TB Nutzdaten und 1 TB Working Space. Nachdem der Payload den Schwellenwert von 65% erreicht hat, wurde ein Resizing auf 3 TB veranlasst. Das Wachstum von 300 GB auf 1,3 TB RAM hat bei einer 3-TB-Instanz zur Folge, dass die Tabellen nun 43% einnehmen. Die meisten Hoster oder Hyperscaler sind aber wie Modehändler: Sie bieten nur bestimmte »T-Shirt-Größen« an, sodass es immer zu einem größeren »Verschnitt« kommt. Versuchen Sie daher, falls möglich, in kleinen Schritten zu erweitern. Bedenken Sie bitte ebenfalls, dass die Summe aller Tabellen nicht immer das Nutzverhalten der Datenbank widerspiegelt. Wird bald ein großer Teil archiviert oder bringen Sie zusätzlich Features wie Native Storage Extension (NSE) mit ein, wird diese Methode des Peak Sizing nicht in der gewünschten Weise funktionieren. In der Herangehensweise der SAP sprechen wir von einem Peak Sizing, wenn vom schlimmsten Fall ausgegangen wird und alle Daten zu einem Zeitpunkt in den Hauptspeicher geladen und verarbeitet werden sollen. Dieses Szenario tritt nie ein und schützt lediglich vor einem zu klein dimensionierten System.
2.1.3 Wichtige Kennzahlen
Da das erwähnte Peak Sizing unter Umständen in die Irre führt, empfehlen wir eine effektivere Variante: die Kennzahlen für die Nutzung des Hauptspeichers mit dem Skript HANA_Memory_Components zu ermitteln (siehe Listing 2.1). Es zerlegt den Heap in die wichtigsten Bestandteile und zeigt die tatsächliche Allokation zu einem bestimmten Zeitpunkt an. Bitte beachten Sie, dass Sie sich mehrere Zeitpunkte ansehen sollten, um repräsentative Werte zu erhalten.
H_COL_GB: Heap memory consumed by component 'Column Store Tables' (GB) H_ROW_GB: Heap memory consumed by component 'Row Store Tables' (GB) H_SYS_GB: Heap memory consumed by component 'System' (GB), excluding NSE page cache (Pool/CS/BufferPage) H_NSE_GB: Heap memory consumped by NSE page cache (Pool/CS/BufferPage) H_STMT_GB: Heap memory consumed by component 'Statement Execution & Intermediate Results' (GB) H_CACHE_GB: Heap memory consumed by component 'Cache' (GB) H_MON_GB: Heap memory consumed by component 'Monitoring & Statistical Data' (GB)
Listing 2.1: Ausgabeparameter HANA_Memory_Components
Sehen wir uns die Ausgabeparameter im Einzelnen an:
H_COL_GB
beschreibt dabei alle CS(Column-Store)-Tabellen. Diese sollten mit Abstand den größten Anteil in Ihrem System einnehmen und können je nach Verwendung vollständig geladen sein.
H_ROW_GB
steht für die RS(Row-Store)-Tabellen; diese sind aufgrund ihres Designs immer zu 100% geladen, der Bereich kann nicht ausgelagert werden.
Die Komponente
H_SYS_GB
beschränkt sich auf alle Allokatoren des SYSTEM-Bereichs.
H_NSE_GB
stellt den Cache für den bereits am Anfang des Abschnitts 2.1.1 erwähnten Puffer dar.
H_CACHE_GB
steht für alle weiteren Caches.
Die Summe an allokiertem Speicher für alle im ausgewählten Zeitraum laufenden SQL-Abfragen spiegelt sich in der Komponente
H_STMT_GB
wider.
Zu guter Letzt finden Sie mit der KPI in
H_MON_GB
Ihre gesammelten Statistik- und Monitoringdaten dargestellt, die sich zu diesem Zeitpunkt im Speicher befinden.
Dank dieser gesammelten Kennzahlen können Sie Ihr HANA-System in kleinere Komponenten zerlegen und gezielt große Bereiche mit Housekeeping verkleinern oder mit Daten aus weiteren Skripten noch weiter auf Objektebene herunterbrechen.
Andere Varianten können ebenfalls als Indikator herangezogen werden. Dazu zählen:
Sizing Report
HANA Cockpit
EWA-Dashboard
Bitte hinterfragen Sie jedoch die daraus gewonnenen Kennzahlen und übernehmen Sie diese auf keinen Fall ungeprüft!
Ressourcenverschwendung
Durch falsche Deutung und Nutzung von Kennzahlen entstehen oftmals zu hohe Hardwarekosten im HANA-Umfeld. Wir empfehlen eine ausgiebige Prüfung der Kennzahlen, da auch ein Fehlverhalten der HANA bei zu hoher Allokation vorliegen kann. Diese möglicherweise einmalige Situation wird dann als Peak und Zielgröße angenommen.
Ermittlung und Überwachung der Kennzahlen
Wir empfehlen eine stetige Überwachung der KPIs aus Listing 2.1. Damit erhalten Sie einen Überblick über einen längeren Zeitraum und erkennen sehr gut abnorme Abweichungen.
2.2 KPI: CPU
Nach den Ausführungen in Bezug auf die Kennzahl des Hauptspeichers widmet sich dieses Unterkapitel den KPI der CPU.
Mit einer bestimmten RAM-Größe wird für die meisten Anwendungsfälle auch eine ausreichend große Anzahl an CPUs mitgeliefert. Durch die Sizingvorgaben und die zertifizierte Hardware der SAP ist es oftmals nicht notwendig, einen genaueren Blick auf die Rechenkapazität zu werfen. Allerdings gibt es Anwendungsfälle wie z.B. im SAP-Retail- oder IS-U-Umfeld oder auch in nativen Szenarien, die mehr als die zur Verfügung stehenden CPU-Ressourcen benötigen. In vielen Fällen führt eine Erhöhung der Rechenkapazität auch zur Vergrößerung des Hauptspeichers. Daher sollte auch diese Notwendigkeit hinterfragt werden. Wir empfehlen eine ausgiebige Prüfung des betroffenen Workloads. Sollte sich das System bereits auf HANA befinden und Sie möchten diese KPI verifizieren, raten wir dazu, das SQL-Skript HANA_LoadHistory_Services zu verwenden. Dieses trennt die CPU-Last der SYSTEM-CPU und des HANA-Indexservers. Mehr Details dazu finden Sie in Abschnitt 5.4.
Lesetipps zum Thema CPU und Parallelisierung
»Praxishandbuch SAP HANA – Administration« (Schuster, Espresso Tutorials, 2019: http://5265.espresso-tutorials.de), Abschnitt 2.4.2: »Prozessoren«»SAP HANA Administration« (Bremer/Breddemann, Galileo Press, 2014), Abschnitt »Concurrency and Parallelism«2.3 Sizing Report
Der HANA Sizing Report ist das Mittel der Wahl für eine Dimensionierung im Zusammenhang mit einem SAP-Update oder einer SAP-Migration. Ebenso kann er für ein bestehendes HANA-System und damit für ein mögliches Resizing benutzt werden. Dennoch gilt es einige wichtige Aspekte zu beachten, ohne die die Kennzahlen falsch gedeutet werden können. Worum es dabei geht, erfahren Sie in diesem Abschnitt.
Die HANA Sizing Reports werden über die SAP-Komponente ST-PI ausgeliefert. Vor der Ausführung sollte daher entweder das neueste Support Package oder der jeweilige neueste Hinweis eingespielt werden. Dabei gibt es für die gängigsten zwei Varianten je nach Systemtyp bzw. Workload unterschiedliche Reports:
für BW (BWoH und BW/4HANA): /SDF/HANA_BW_SIZING
für ERP (S/4HANA bzw. Suite on HANA): /SDF/HDB_SIZING
SAP-Hinweise für das HANA-Sizing
S/4HANA und Suite on HANA: 1872170 »ABAP on HANA sizing report (S/4HANA, Suite on HANA …)«: https://me.sap.com/notes/1872170BW on HANA und BW/4HANA: 2296290 »New Sizing Report for SAP BW/4HANA«: https://me.sap.com/notes/2296290Natürlich gibt es ebenso native Anwendungen oder andere Produkte wie z.B. Business One, die mit anderen Methoden vermessen werden können. Wie beschränken uns bei den Sizing Reports auf die beiden am weitesten verbreiteten Systemtypen.
2.3.1 BW Sizing Report
In diesem Abschnitt erhalten Sie Informationen zu den Kennzahlen des BW Sizing Report. Im Fokus stehen dabei die warmen Daten. Sie lernen, wie Sie diese einbinden und im Ergebnisreport erkennen.
Im Anhang zum zentralen SAP-Hinweis 2296290 finden Sie eine ausführliche Dokumentation zur Nutzung und Deutung aller Kennzahlen. Um die Hardwarekosten zu reduzieren, empfehlen wir dringend den Einsatz von Data-Tiering-Features wie Nearline Storage (NLS) und Native Storage Extension (NSE). Ersteres kann bereits unabhängig von HANA eingesetzt werden und reduziert vorab Kosten, da die Daten in eine effiziente SAP IQ ausgelagert werden und damit nicht länger Teil der eigentlichen Datenbank sind. NSE wird von SAP erst mit BW/4HANA unterstützt.
Ein Housekeeping der PSA(Persistent-Staging-Area)-, Changelog- sowie BW-Steuertabellen (Tabellennamen startend mit RS*) ist unerlässlich, um das Datenwachstum zu begrenzen. Alle genannten Möglichkeiten zur Reduzierung der Nutzdaten werden vom Sizing Report nicht automatisch abgedeckt! Es besteht lediglich die Möglichkeit, diverse Tabellen aus dem Sizing Report auszuschließen. Haben Sie sich bei einigen Objekten bereits entschieden, Data-Tiering-Features wie Extension Nodes (Scale-out Lösung für BW-Systeme – siehe SAP-Hinweis 2453736) oder NSE zu nutzen, besteht die Möglichkeit, diese unter dem Punkt »Multi Temperature Data« miteinzubeziehen. Wir empfehlen für größere Systeme ab 2 TB, auf jeden Fall NLS und NSE zu nutzen. Der Administrationsaufwand für Extension Nodes ist recht hoch, daher werden diese meist in extrem großen Systemen ab 10 TB eingesetzt.
SAP-Hinweis zum BW Sizing Report
Bitte spielen Sie vor der Ausführung des Reports immer die aktuelle Version im System ein:
2296290 »New Sizing Report for SAP BW/4HANA«:
https://me.sap.com/notes/2296290
Unterschiede zwischen BW on HANA und BW/4HANA
Es bestehen technische Unterschiede zwischen den beiden Reports für BW on HANA und BW/4HANA. Sie können beide Varianten über ein Kennzeichen ausführen und diese vergleichen. Manche Objekte werden unterschiedlich behandelt, was zu Abweichungen führt.
Details entnehmen Sie dem SAP-Hinweis 2610534: https://me.sap.com/notes/2610534.
Im Report gibt es zwei Kennzahlen, die oftmals für Verwirrung sorgen:
»Total memory (non-act.)«
»Total memory incl. tmp«
