In-Memory - Data Management - HANA Datenbank Teil III

Einführung:

Primär besagt in-Memory Computing dass die Datenverarbeitung zu einem großen Teil bzw vollständig im Hauptspeicher eines Computers durchgeführt wird. Nicht außer Acht zu lassen ist dabei natürlich auch, dass letztlich in der Regel auch eine persistente Speicherung der Daten notwendig ist. Es bei dieser Definition zu belassen würde die Merkmale des in-Memory Computings jedoch nicht ausreichend erfassen. Wie bei vielen Begriffen in der Informationstechnologie gibt es aber auch hier keine eindeutige Beschreibung.

Eines der wesentlichen Merkmale von Datenverarbeitungssoftware im Umfeld des In-Memory Computing s ist die in der Regel höhere Verarbeitungsgeschwindigkeit im Vergleich zu anderen Implementierungen. Einer der wesentlichen Gründe dafür ist, dass die zu verarbeitenden Daten im Primärspeicher , bzw. Dem Hauptspeicher für die der Datenverarbeitung zugrunde liegenden Daten im Primärspeicher, also dem Hauptspeicher , vorgehalten werden.

Die wichtigste Voraussetzung dafür, der Hauptspeicher, wurde in den letzten Jahren einerseits wesentlich günstiger und andererseits je Server in größeren Mengen verfügbar. Auch die Ausstattung der Server bezüglich des Hauptspeichers im Rechenzentren stieg - über einen längeren Zeitraum betrachtet - stark an.

Die In-Memory-Technologie darauf zu reduzieren reicht aber, wie eingangs erwähnt , nicht aus. Mit dem Performance-Gewinn durch die primäre Nutzung des Hauptspeichers gehen auch wesentliche andere Paradigmenwechsel einher. Beschäftigt man sich mit dem In-Memory Computing und legt wie wir einen speziellen Fokus auf SAP HANA, trifft man schnell auf dem Begriff Column-oriented Storage Layout, also die spaltenorientierte Speicherung von Daten. Im Gegensatz zu relationalen Datenbanken, die ihre Daten in Tabellen und zeilenweise organisieren und speichern, werden die Daten bei diesem Layout spaltenweise abgelegt. Grundsätzlich sind die Daten sowohl bei der Zeilen- als auch bei der spaltenorientierten Datenhaltung logisch in Tabellen organisiert.

Architektur

SAP HANA umfasst als Plattform zugleich eine In-Memory-Datenbank, eine Entwicklungsplattform und einen Applikationsserver.

SAP HANA hat den Anspruch, einen Großteil der Daten spaltenorientiert und im Arbeitsspeicher vorzuhalten, unter anderem, um sehr schnelle Lesezugriffe zu ermöglichen. Auf der anderen Seite gilt es, alle Eigenschaften eines verlässlichen Datenbanksystems zu erfüllen: die Atomarität einer Operation, die Konsistenzerhaltung des Datenbestands, die Isolation von Transaktionen sowie die Dauerhaftigkeit der Datenspeicherung auch nach einem Ausfall der Stromversorgung. Aus diesen vier unter dem Akronym ACID bekannten Eigenschaften ergeben sich besondere Anforderungen an die Architektur einer In-Memory-Datenbank. In einigen Bereichen werden Sie hier altbewährte Prinzipien der Datenbanktechnologie wiederfinden, andere Mechanismen wurden von Grund auf neu konzipiert.

Wir beginnen mit den wesentlichen Komponenten eines SAP-HANA-Systems und nähern uns schrittweise den darin laufenden Prozessen und Threads. Sie können diese Prozesse unterschiedlich auf die zur Verfügung stehende Hardware verteilen.

Besondere Anforderungen stellt eine In-Memory-Datenbank wie SAP HANA an die Persistenzsicherung.

---

System, Instanz, Host und Tenant

Bevor wir uns den Komponenten eines SAP-HANA-Systems widmen, wollen wir eine gemeinsame begriffliche Basis schaffen, indem wir die Begriffe System, Instanz, Host und Tenant definieren.

• Host: Ein Host bildet die Betriebsumgebung von SAP HANA. Dazu zählen wir die Harwareressourcen wie Arbeitsspeicher und CPUs und das installierte Betriebssystem. Der Festplattenspeicher muss nicht Teil eines Hosts sein, sondern kann z.B. zentral bereitgestellt werden. Im Falle verteilter Systeme muss dieser für alle Hosts erreichbar sein. Jeder Host erhält eine Storage Partition, über die er zur Laufzeit einer SAP-HANA-Instanz eindeutig identifizierbar ist.

• Instanz: Eine Instanz umfasst alle SAP-HANA-Systemkomponenten, die auf einem Host installiert sind. Ein System kann aus mehreren SAP-HANA-INstanzen bestehen, die über mehrere Hosts verteilt sind. Für ein SAP-HANA-System existiert immer genau eine Instanz pro Host. Beachten Sie, dass Instanzen nicht über die zweistellige Instanznummer identifiziert werden, da diese für das gesamte System gilt. Daher muss jede INstanz eines SAP-HANA-Systems dieselbe Instanznummer haben.

• System: ein System umfasst alle SAP-HANA-Instanzen mit derselben Nummer. Jedes SAP-HANA-System wird über eine System-ID (SID) und über eine Instanznummer eindeutig identifiziert . Die Begriffe SAP-HANA-System und SAP-HANA-Datenbank werden häufig synonym verwendet, wir zählen allerdings auch zusätzliche Serverkomponenten wie den SAP HANA Client zu den Komponenten eines SAP-HANA-Systems. Darüber hinaus referenzieren wir mit dem Begriff SAP-HANA-Datenbank nur eine von möglicherweise mehreren Tenant-Datenbanken, die innerhalb des SAP-HANA-Systems betrieben werden.

• Tenant-Datenbank: In SAP HANA 2.0 betreiben Sie mehrere, voneinander isolierte Datenbanken innerhalb eines Systems. Während der Installation erstellen Sie genau eine Systemdatenbank, die administrativen Zwecken dient, sowie eine Anzahl von Tenant-Datenbanken, die jeweils über eigene Datenbankkatologe und -Prozesse verfügen. Applikationen verbinden sich direkt mit einer Tenant-Datenbank.

---

Komponenten der SAP-HANA-Plattform

Wir nähern uns der Technologie von SAP HANA in den folgenden Abschnitten schrittweise von außen nach innen. Wir beginnen mit dem Versuch, SAP HANA in die aus dem SAP Umfeld bekannte dreistufige Client-Server-Architektur einzuordnen. In diesem Zusammenhang sprechen wir von einem Versuch , da insbesondere für die Applikations- und Datenbankebene eine zunehmende Verflechtung zu beobachten ist, die nicht zuletzt von SAP HANA selbst angetrieben wird.

Einordnung in die dreistufige Client-Server-Architektur

Neben dem wohl bekanntesten Bestandteil , der In-Memory-Datenbank, verfügt die SAP-HANA-Plattform auch über einen Webapplikationsserver und eine Entwicklungsplattform.

Der wesentliche Teil des Datenbankmanagementsystems (DBMS) wird in SAP HANA durch den Index Server bereitgestellt. Die bereits erwähnte Entwicklungsplattform sowie der integrierte Webserver sind Teil der SAP HANA Extended Application Services (XS).

Die dargestellten Elemente ermöglichen grundsätzlich die folgenden beiden Einsatzszenarien für SAP HANA:

. => SAP HANA als Datenbank

Im Rahmen eines SAP-NetWeaver-basierten SAP-Systems wie SAP Business Warehouse oder SAP Business Suite hält SAP HANA die Stamm- und Bewegungsdaten im Arbeitspeicher des Datenbankservers vor. Der Zugriff auf das System erfolgt durch Endanwender über das Client-Programm SAP GUI, wobei ein SAP NetWeaver Application Server die Daten aufbereitet. Dazu ist der ABAP-Code der SAP-Transaktionen für die Verwendung mit SAP HANA optimiert worden. SAP HANA ordnet sich hier auf der Datenbankebene in die klassische dreistufige Client-Server-Architektur ein.

=> SAP HANA als zentrale Datenbank und Applikationsplattform

SAP HANA dient als zentrale Plattform für Applikationen, die Daten direkt entweder über SQL oder über HTTP(S) konsumieren.

SAP-HANA-Komponenten im Überblick

Aus physischer Sicht besteht ein SAP-HANA-System aus einem oder mehreren Hosts, daran angebundenen Speichermedien und einem internen sowie externen Netzwerk. Aus logischer Sicht empfehlen wir die folgenden Komponenten , wobei nur die SAP-HANA-Datenbank zwingend erforderlich ist:

=> SAP HANA Datenbank (HANA DB)

Diese Komponente beinhaltet das eigentliche Datenbankmanagemtsystem. Sie umfasst alle ausführbaren Programme, die zum Betrieb der SAP-HANA-Prozesse notwendig sind. Jedes SAP-HANA-2.0-System verfügt über eine Systemdatenbank zu administrativen Zwecken sowie über eine beliebige Anzahl voneinander isolierter Tenant-Datenbanken, die die eigentlichen Datenquellen für ihre Applikationen repräsentieren.

SAP-HANA-Prozesse und -Threads

Eine der wesentlichen Komponenten von SAP HANA ist das Datenbankmanagementsystem selbst. Es umfasst, je nach Datenbanktyp, eine Reihe von Prozessen, denen wir uns auf den folgenden Seiten widmen.

HDB Daemon

Der Prozess hdbdaemon ist der Vaterprozess aller SAP-HANA-Prozesse. Demzufolge ist er in der Lage , die übrigen Prozesse zu überwachen und bei einem Ausfall neu zu starten. Sollten Sie das SAP-HANA-System also in bestehende Monitoring-Werkzeuge einbinden, die in definierten Situationen eingreifen, ist es ratsam , mindestens den HDB Daemon zu überwachen, der wiederum die übrigen Prozesse am Leben erhält.

Index Server

Der Prozess dbindexserver stellt die eigentliche Datenbank , bestehend aus Column Store und Row Store , bereit. Dazu zählen auch die unterschiedlichen Engines, mit denen die Daten verarbeitet werden. Zu den Aufgaben des Index Servers gehören neben der Verarbeitung von SQL- und MDX-Befehlen (Multidimensional Expression) die Kontrolle der Benutzerauthentifizierung, die Transaktionskontrolle und die Datenhaltung. Dazu zählt auch die Pflege der Topologie Ihrer Datenbankobjekte , d.h., der Index Server kennt z.B. den Speicherort von Tabellenpartitionen. Einzelne Unteraufgaben werden dabei ggf. An andere Prozesse wie den Compile Server oder den Script Server delegiert. Sämtliche Informationen zur System-Performance werden wiederum vom eingebetteten Statistics Service gesammelt und im Schema _SYS_STATISTICS gespeichert.

Index Server High-Level Architektur

Name Server

Der Prozess hdbnameserver hält sämtliche Informationen zur Topologie des SAP-HANA-Systems vor und existiert ausschließlich für die Systemdatenbank. In verteilten Systemen können Tenant-Datenbanken und weitere Systemkomponenten unterschiedlich auf die zur Verfügung stehenden Hosts verteilt werden. Der Name Server kennt dabei immer die aktuelle Position eines Prozesses sowie alle Hosts und deren Rollen. Die gesammelten Informationen können Sie in der Datei nameserver_topology_hdbzdb.json im Trace-Verzeichnis nachvollziehen. Alle Hosts eines Systems werden außerdem vom Name Server durch regelmäßige Pings überwacht, damit bei einem Ausfall der Failover-Prozess auf einen Stand-by-Host durch den Name Server initiiert werden kann. Darüber hinaus übernimmt der Name Server für die Systemdatenbank die Funktion eines Index Servers, darauf gehen wir in „Tenant-Datenbanken“, genauer ein.

Preprocessor

Der Prozess hdbpreprocessor unterstützt den Index Server bei der Textsuche und Textanalyse. Dazu extrahiert er z.B. Suchbegriffe aus Textspalten und hält somit Volltex-Indizes aktuell. Er übernimmt in diesem Sinne eine Vorverarbeitung (Preprocessing) sowohl strukturierter als auch unstrukturierter Daten. Der Preprocessor läuft in der Systemdatenbank und bedient alle Tenant-Datenbanken.

Compile Server

Der Prozess hdbcompileserver läuft auf jedem Host eines SAP-HANA-Systems und dient der Kompilierung von Stored Procedures und SQLScript-Prozeduren. Der Compile Server läuft in der Systemdatenbank und bedient alle Tenant-Datenbanken.

SAP Web Dispatcher

Der Prozess hdbwebdispatcher leitet eingehende HTTP(S)-Verbindungen zu XS-Classic-Applikationen weiter. Der SAP Web Dispatcher wird außerdem zu Realisierung des Plattform-Routers von XS Advanced genutzt.

Weitere optionale Prozesse

Je nach Nutzungsszenario sind weitere Komponenten optional erhältlich, von denen einige einer zusätzlichen Lizenzierung unterliegen können. Wenn Sie z.B. die SAP HANA Application Function Library (AFL) nutzen, benötigen Sie den Prozess script-server. Zur Speicherung und Verarbeitung von JSON-Dokumenten bietet SAP HANA den Document Store Server, der den Prozess hdbdocstore betreibt. Nutzen Sie XS Advanced, ist der SAP HANA Deployment von Entwicklungsobjekten benötigen. Für SAP HANA Smart Data Integration kommt der Data Provisioning Server zum Einsatz, dessen Prozess hdbspserver Adapter für verschiedene Datenquellen bereithält und eine Datenprovisionierung ermöglicht. Diese und weitere optionale Komponenten sind standardmäßig deaktiviert und müssen manuell gestartet werden, d.h., sie werden auch nicht vom HDB Daemon überwacht.

Die genannten Prozesse kommunizieren intern über das TCP/IP-Protokoll miteinander. Einige der Prozesse sind zusätzlich von außerhalb erreichbar. Dazu zählen im Regelfall der Index Server und die XS Services , sodass Anwender über SQL oder über eine Webandwendung auf die Datenbank zugreifen können. Um dabei mehrere SAP-HANA-Installationen innerhalb desselben Netzwerks unterscheiden zu können, beinhalten die systemspezifischen Ports immer die jeweilige Instanznummer des Systems. SQL-Clients stellen z.B, eine Verbindung zum Index Server der initialen Tenant-Datenbank eines SAP-HANA-Systems mit der Instanznummer 10 über den Port 31015 her.

Systemaufbau

Der am wenigsten komplexe Systemtyp umfasst einen einzigen Host, auf dem sämtliche SAP-HANA-Prozesse laufen, ist also ein Single-Host-System. Da die Skalierbarkeit eines solchen Systems auf die Hardwarekomponenten des gewählten Hosts limitiert ist, wird in diesem Fall auch von einem Scale-up-System gesprochen.

Die SAP-HANA-Plattform und ihre Shared-Nothing-Architektur wurden insbesondere im Hinblick auf den Betrieb verteilte Systeme konzipiert. Daher ist es ebenso möglich, die genannten Prozesse auf mehrere Hosts zu verteilen. Ein solches Multiple-Host-System bietet durch Hinzufügen weiterer Hosts die Möglichkeit der horizontalen Skalierung , sodass verteilte Systeme auch als Scale-out-Systeme bezeichnet werden.

Multiple-Host-Systeme bieten neben der Lastverteilung die Möglichkeit, Stand-by-Hosts in das System zu integrieren, um Anforderungen im Bereich der Hochverfügbarkeit zu erfüllen.

Tenant-Datenbanken

In SAP HANA können Sie mehrere voneinander isolierte Datenbanken innerhalb eines Systems betreiben, um die Effizienz gemeinsam verwendeter Ressourcen mit der Datensicherheit separater Datenbankkatakoge zu kombinieren. SAP HANA 2.0 schafft damit wichtige Voraussetzungen für die Anforderungen des Cloud-Geschäfts. Die voneinander isolierten Datenbanken heißen Tenant-Datenbanken (kurz: Tenant) und das zugehörige System wird folglich als Multi-Tenant-Database-Container-System (MDC-System) bezeichnet . aus diesem obligatorischen Konzept leiten sich im Vergleich zu klassischen Datenbanken architektonische Besonderheiten ab, die wir im folgenden kurz behandeln.

Alle Tenant-Datenbanken eines Systems teilen dieselbe Installation, d.h., es existieren nach wie vor nur eine System-ID (SID) und eine Instanznummer pro SAP-HANA-System. Die Tenant-Datenbanken werden über die Kombination aus der SID des Systems und ihrem individuellen Datenbanknamen identifiziert. Zu jeder Tenant-Daten-bank existieren ein eigener Index Server und ggf. Weitere Prozesse, sodass separate Datenbankkataloge (inklusive Datenbankbenutzer) sowie separate Persistenzebenen (inklusive Backup) und Trace-Dateien erstellt werden.

Neben den Tenant-Datenbanken ist in jedem MDC-System eine Systemdatenbank mit dem Namen SYSTEMDB vorhanden. Die Systemdatenbank fungiert als eine Art Administrationszugang für das Gesamtsystem. Darin nehmen Sie systemweite Konfigurationen vor, die von den Tenant-Datenbanken geerbt werden. Zugleich können Sie von hier aus Tenant-Datenbanken konfigurieren , erstellen oder löschen.

Verzeichnisstruktur

SAP empfiehlt eine Standardverzeichnisstruktur für jedes SAP-HANA-System. Das Wissen über die Dateisysteme hilft Ihnen einerseits dabei, den Aufbau von SAP-HANA-Systemen zu verstehen. Andererseits können Sie sich auf diese Weise gezielt auf der Betriebssystemebene der jeweiligen Hosts bewegen.

Zu jedem SAP-HANA-System existieren mindestens die folgenden Betriebssystembenutzer:

• “Root“ Der root-Benutzer muss auf allen Hosts Ihres SAP-HANA-Systems denselben Namen und dasselbe Passwort besitzen. Er muss allerdings nicht zwangsläufig root heißen, andere Bezeichnungen können bei der Installation von SAP HANA definiert werden.

• “<sid>adm“ Der Benutzer <sid>adm wird für administrative Aufgaben - etwa zum Starten und Stoppen des Systems - verwendet und ist Besitzer aller zum System gehörenden Dateien und Verzeichnisse . Dessen Name, ID und Gruppen-ID müssen auf allen Hosts Ihres Systems identisch sein. Je nach Datenbankisolierungsgrad ist es zusätzlich möglich, für jede Tenant-Datenbank eigene administrative Betriebssystembenutzer und -Gruppen zu erstellen. In diesem Fall ist dem Benutzer <sid>adm die Administration der Systemdatenbank vorbehalten. Auf Betriebssystemebene werden die Linux-Standardmechanismen für die Benutzerverwaltung und Zugriffskontrolle angewandt, um die Datendateien der Tenants voneinander zu isolieren

• “sapadm“ Unter diesem Benutzer läuft der SAP Host Agent. Falls bei der Installation kein SAP Host Agent auf ihrem System gefunden wird, wird er inklusive des zugehörigen Benutzers sapadm installiert. Sollten sie den SAP Host Agent bereits installiert haben, werden dessen Benutzer und sein Passwort nicht verändert.

Die gemeinsamen Verzeichnisse hana/shared, hana/data und hana/log müssen von allen Hosts erreichbar sein, während das Verzeichnis user/sap ausschließlich der lokalen Instanz eines Host zugehörig ist. Die gemeinsamen Verzeichnisse müssen vor der Installation manuell erstellt und jedem Host gemountet werden.

Im Folgenden zählen wir die für Sie als Datenbankadministrator wichtigsten Verzeichnisse auf und erwähnen darin enthaltene , relevante Dateien.

• “/hana/shared“ Das Verzeichnis /Hana/shared wird auch sapmnt genannt und durch den gleichnamigen Parameter bei der Installation defineirt. In diesem Verzeichnis wird das eigentliche DBMS installiert, daher muss das Verzeichnis wird das eigentliche DBMS installiert , daher muss das Verzeichnis von allen Hosts des SAP-HANA-Systems erreichbar sein. Das Verzeichnis /Hana/shared/<SID> enthält ausführbare Kernel-Programme (exe und HDB<Instanz>), Instanzprofile (profile), globale Daten wie Konfigurationsdateien und (De)installationsdateien (hdblcm).Je nach Einsatzszenario werden darin weitere Unterverzeichnisse angelegt, die systemweit verfügbar sein müssen. Außerdem sind die folgenden Unterverzeichnisse relevant:

=> <SID>/hdbclient: Installationspfad des SAP HANA Clients

=> <SID>/hdbstudio: Installationspfad des SAP HANA Studios

=> <SID>/hdbstudio_update: Installationspfad des SAP HANA Studio Repositorys. Dieses wird bei einem Update der lokalen SAP-HANA-Studio-Installation verwendet.

=> <SID>/xs: Installationspfad von SAP HANA XS Advanced. Darin existieren u.a. Unterverzeichnisse für den XS UAA Server udn den XS Platform Router. Außerdem wird ein Unterverzeichnis app_working angelegt, das als Arbeitsverzeichnis für XS-Applikationen dient. Letzteres können Sie, etwa aus Gründen der Performance, über den Parameter basepath_xsa_appworkspace in der Datei global.ini ändern. Anschließend ist ein Neustart der XS-Advance—Services über den Befehl XSA restart erforderlich.

=> <SID>/global/hdb/custom/config: In diesem Verzeichnis befindet sich der Teil Ihrer Konfiguraitonsdateien, der systemweit gültig ist. Zu jeder Tenant-Datenbank finden Sie darin Unterverzeichnisse für deren spezifische Konfigurationen, die nach dem Schema DB_<Tenant-Datenbank> benannt sind.

=> <SID>/HDB<Instanz>/<host>: Darin befinden sich die jeweils host-spezifischen Konfigurationsdateien.

=><SID>/HDB<Instanz>/exe/config: Dieses Verzeichnis enthält Standardwerte für alle Konfigurationsparameter. Nehmen Sie in diesem Verzeichnis keine Änderungen vor, sondern folgen Sie derbeschriebenen Vorgehensweise.

=> <SID>/HDB<Instanz>/<host>/trace: In diesem Trace-Verzeichnis protokollieren die

Persistenz und Speicherverwaltung

Datenhaltung in SAP HANA

Während die Zugriffszeiten klassischer Festplatten häufig im Bereich weniger Millisekunden liegen, kann auf Arbeitsspeicher innerhalb von Nanosekunden zugegriffen werden. Daher hält SAP HANA häufig verwendete Daten dauerhaft im Arbeisspeicher. Dabei handelt es sich allerdings in der Regel um ein flüchtiges Speichermedium, sodass darauf gespeicherte Daten bei einem Neustart oder im Falle eines Stromausfalls verloren gehen. Damit SAP HANA trotzdem in der Lage ist, den Zustand. Vor dem Ausfall wiederherzustellen, müssen die Daten während des Betriebs zusätzlich auf einem nichtflüchtigen Medium gespeichert, also persistiert werden. Diese Operation legt einen sogenannten Savepoint an und wird von SAP-HANA Prozessen standardmäßig alle fünf Minuten durchgeführt. Dabei legt der jeweilige Prozess ein

konsistentes Abbild der Datenbank auf einem sogenannten Data Volume ab.

Datenänderungen, die nach einem Savepoint eintreffen, fließen erst in den nächsten Savepoint ein. Sie müssen also in der Zwischenzeit ebenfalls persistiert werden . Aus diesem Grund werden zu jeder Transaktion die Daten verändert oder löscht, Log-Informationen erfasst und synchron in ein Log Volume geschrieben, das sich ebenfalls auf einem nicht-flüchtigen Speichermedium befindet. Mithilfe eines Savepoints und der seitdem gespeicherten Log-Informationen lässt sich ein konsistenter Stand der Datenbank wiederherstellen, ohne Informationen im flüchtigen Arbeitsspeicher angewiesen zu sein.

SAP HANA, stellt wie jede andere geschäftskritischer Datenbank, Backup-Mechanismen bereit, um die persistierten Daten in den Log und Data Volumes auf zusätzlichen Speichermedien zu sichern. Die Wiederherstellung einer Datenbank aus einem bestehenden Backup erfordert allerdings eine Downtime.

---

Persistenter Speicher

Mit SAP HANA 2.0 SPS03 wurde die Unterstützung von nicht-flüchtigem Arbeitsspeicher eingeführt. Dieser wird auch als Non-Volatile Random-Access Memory (NVRAM oder als Storage Class Memory) bezeichnet. Dieses Speichermedium ist jedoch noch wenig verbreitet und erforder, dass das Dateisystem direkt auf die Daten im NVRAM zugreift (Direct Access, kurz DAX), ohne Kopien im Page Cache des Kernels vorzuhalten. Diese Funktion wird aktuell von SLES 12 sP3 sowie RHEL 7.4 angeboten.

---

Tabellen im Arbeitsspeicher werden außerdem in zwei Bereiche unterteilt: den zeilenorientierten Row Store und den spaltenoreintierten Column Store. Während Datenbank-Objekte generell zur Socherstellung der Ausfallsicherheit sowohl im Arbeitsspeicher als auch auf Data Volumes gespeichert sind, werden Tabellen immer entweder im Row Store oder im Column Store vorgehalten.

Um das beschriebene Prinzip aus regelmäßigen Savepoints und fortschreibenden Log-Informationen sicherstellen zu können, pflegt jeder Prozess, der Datenbankobjekte in SAP HANA modifiziert, auf seinem jeweiligen Host ein eigenes Data Volume sowie ein eigenes Log Volume. Dieser Ansatz wird als Shared-Nothing-Architektur bezeichnet, da kein zentrales Volume existiert, das von allen Prozessen geteilt wird. Auf die persistierenden Prozesse und ihre Volumes gehen wir im folgenden Abschnitt ein.

Prozesse und Volumes

Prozesse , die Daten in SAP HANA manipulieren können, werden als persistierende Prozesse bezeichnet. Sie schreiben also in eigene Data und Log Volumes.

​Prozess	Anmerkung
​Index Server	​auf allen aktiven Hosts persistierend
​Name Server	Nur auf Master Host persistierend
SAP HANA XS	persistierend auf jeden Host, auf dem dieser Prozess läuft
Script Server	Persistierend auf jedem Host, auf dem dieser Prozess läuft.

In Datendateien schreiben

Als In-Memory-Datenbank löst SAP HANA nicht bei jeder Datenmanipulation einen Schreibvorgang auf dem Data Volume aus. Änderungen werden stattdessen in Log-Segmenten festgehalten und können bei einem Neustart auf eine bestehende Datenbasis appliziert werden. Diese Datenbasis appliziert werden. Diese Datembassies heißt Savepoint, wobei der Begriff häufig sowohl den jeweiligen Datenbestand, den Zeitpunkt der Erstellung als auch den Erstellvorgang selbst meint. Während einer Savepoint-Operation werden alle Daten, die sich seit dem letzten Savepoint verändert haben, persistiert, d.h., die Datendatei des Prozesses, der den Savepoint ausgelöst hat, wird mit den veränderten Pages aus dem Arbeitsspeicher aktualisiert. Auf diese Weise repräsentieren die Daten, die zu einem Savepoint gehören, einen konsistenten Stand. Grundsätzlich unterscheiden wir zwischen Screibvorgängen, die während eines

Savepoints entstehen, und solchen, die zwischen zwei Savepoints durchgeführt werden. Auf beide Szenarien gehen wir in diesem Abschnitt ein.

Basisvorgänge

Systemstart und -stopp

Es existieren verschiedene Möglichkeiten, die Prozesse von SAP HANA zu starten und zu stoppen. Wir beschränken uns in diesem Fall auf die Kommandozeile und das Administrationswerkzeug SAP HANA Cockpit. In jedem Fall benötigen Sie Zugang zum Betriebssystembenutzer <SID>adm

Auf Betriebssystemebene können Sie zum Starten bzw. Stoppen einer lokalen SAP-HANA-INstanz auf einem Host das Programm HDB verwenden, das sich im Verzeichnis /hana/shared/<SID>/HDB <Instanznr.> befindet und Ihnen unter anderem die folgenden Befehle bereitstellt:

HDB start | stop | restart | kill [-<Signal>] <Prozess>

Letztere Option ermöglicht es, einzelne SAP-HANA-Prozesse gezielt zu beenden, sollte aber niemals in produktiven Systemen verwendet werden. Wenn Sie ein Single-Host-System einsetzen, werden diese Befehle höchstwahrscheinlich ausreichen. In Multiple-Host-Systemen führen diese

Befehle hingegen nur zum Start bzw. Stopp lokaler Instanzbestandteile des jeweiligen Hosts. Verwenden Sie daher die Befehle um das gesamte System, bestehend aus allen Prozessen auf allen Hosts, zu starten und anschließend für jeden Host den Status zu kontrollieren.

Etwas komfortabler ist der Weg über das SAP HANA Cockpit. Hier können Sie in der App System Overview im Bereich Overall Database Status auf Start System bzw. Stop System klicken. Zur Durchführung einer dieser Operationen werden Sie aufgefordert, sich als <sid>adm zu authentifizieren.

Zum Stoppen des Systems werden die folgenden beiden Modi unterschieden, die Sie auch dem Dialog entnehmen können:

• Soft Shutdown: Ein Soft Shutdown wartet auf den Abschluss laufender Transaktionen. Anschließend wird eine Savepoint-Operation durchgeführt, um den nächsten Startvorgang zu beschleunigen. Wenn der Soft Shutdown nicht zum Stoppen des Systems führt, wird das Herunterfahren von SAP HANA nach Ablauf einer definierten Zeitspanne erzwungen, die Sie , individuell auswählen können.

• Hard Shutdown (Immediately): Entscheiden Sie sich für einen Hard Shutdown, wenn Sie laufende Transaktionen abbrechen und zurückrollen möchten. Hier wird keine Savepoint-Operation ausgelöst, sodass beim nächsten Systemstart die seit dem letzten Savepoint generierten Log-Segmente appliziert werden müssen. Die Dauer des Startvorgangs wird daher abhängig von der Datenänderungsrate Ihres Systems verzögert.

Der HDB Daemon sorgt allerdings als Vaterprozess dafür , dass ein gestoppter Prozess sofort wieder neu gestartet wird, sodass der Befehl einem Serviceneustart gleichkommt. Ein Stoppen des Daemon-Prozesses selbst ist auf diesem Wege nicht möglich. Zum Stoppen einzelner Prozesse benötigen Sie das System Privilege SERVICE ADMIN. Sollte der HDB Daemon nicht reagieren, können Sie in der App Manage Services über den Button Start Missing Services fehlende Prozesse manuell starten. Starten und Stoppen des Systems sowie das Starten fehlender Services sind ausschließlich über die Administration der Systemdatenbank im SAP HANA Cockpit möglich.

Für das Starten und Stoppen von Tenant-Datenbanken bietet das SAP HANA Cockpit ebenfalls eine Option. Klicken Sie dazu im Resource Directory unterhalb der Systemdatenbank auf Manage Databases . Diese App zeigt Ihnen Informationen zur Systemdatenbank sowie zu allen Tenant-Datenbanken. Letztere können Sie über die Spalte Action starten und stoppen.

Es gäbe noch viel über die HANA Datenbank zu schreiben und ich werde es auch noch tun , aber jetzt werde ich einmal hier enden und im nächsten Post über S/4HANA schreiben auch hier werde ich wieder über die SAP HANA Datenbank schreiben.

Zugehöriger Post:

Teil I

https://einsiedlerkreps.blogspot.com/2023/05/in-memory-data-management-teil-i.html

Teil II

https://www.lagerfeuer.online/post/in-memory-datenbank-theorie-und-algorithmen-teil-ii