Inspiricon-Persistence-Layers-SAP-HANA

Die 5 W’s des Persistence Layers in SAP HANA

Stelle dir folgendes Szenario vor: du setzt dich mit einer frischen Tasse Kaffee gemütlich vor deine brandneue HANA Datenbank, die bisher alle Ergebnisse rekordverdächtig schnell lieferte – was deine Anwender gleichermaßen mit großer Zufriedenheit als auch Beunruhigung beobachten…

Dann plötzlich, du wolltest gerade den nächsten herrlichen Schluck Kaffee genießen, passiert das Unsagbare! Die Katastrophe schlägt zu! Licht aus! Strom aus! Ein Absturz! Die HANA In-Memory Daten verschwinden mitten in der Bearbeitung… Wie konnte das passieren?!

Und was noch wichtiger ist: wie kommst du jetzt wieder an die ganzen Daten und wie kannst du sie wieder in den gewünschten Zustand zurückholen?

Um auf diesen Fall der Fälle vorbereitet zu sein und um Im-Memory Datenverlust sowie erhebliche Anstrengungen zur Datenwiederherstellung im Nachgang zu vermeiden, setzt SAP HANA das sogenannte „Persistence Layer“ ein.

Jetzt fragst du dich vielleicht „was soll das ganze Gerede über Persistence“? Soll SAP HANA nicht gerade deshalb so viel schneller sein, da es NICHT persistent ist, sondern auf der In-Memory Technologie basiert?

Nun ja, es ist tatsächlich so, dass SAP HANA auch von Datenpersistenz abhängig ist. Hier folgt ein kurzer Überblick über das integrierte SAP HANA Persistence Layer.

Die 5 W’s: Wer-Was-Wo-Wann-Warum?

Wer?

SAP HANA Entwickler und Consultants sind die Zielgruppe für diesen grundlegenden Überblick des Persistence Layers in der SAP HANA Datenbank Architektur.

Was?

Fakt ist: das Persistence Layer ist in der HANA Datenbank eingebaut. Es ist wichtig, dieses Persistence Layer nicht mit der Option Anlegung von persistenten HANA Views zu verwechseln – die man als Entwickler has, um persistente HANA Views anzulegen – aber darüber sprechen wir ein anderes Mal in einem anderen Blogartikel!

Die Datenspeicherung auf der Festplatte wird „persistent“ genannt, also „erhaltend“. Dies steht im Gegensatz zu Daten, die zeitweise in RAM liegen, also die sogenannten „In-Memory Daten“, die mit einer erheblich schnelleren Antwortzeit zugänglich sind – was auch die Basis der SAP HANA In-Memory Technologie ist!

Das Persistence Layer wird genutzt, um Daten physisch in Form von sogenannten „Savepoints“ in regelmäßigen Intervallen von X Minuten zu speichern (Standardeinstellung = 5 Minuten).

Diese Savepoints enthalten die letzten Transaktionen, die die persistente oder dauerhafte Speicherung auf Datenvolumen in der HANA Datenbank gespeichert hat. Zusätzlich speichert SAP HANA Protokolle von laufenden Datentransaktionen. Im Falle eines In-Memory Datenverlustes werden der neueste Savepoint und die protokollierten Transaktionen, die seit diesem Savepoint gelaufen sind, genutzt, um den Datenbestand auf den letzten aufgezeichneten Stand zu „rekonstruieren“ oder wiederherzustellen.

Wo?

Das Persistence Layer ist im Index Server in der SAP HANA Datenbank angesiedelt. Man kann es am besten im Kontext der In-Memory Computing Engine (IMCE) sehen:

In Memory Computing Engine

Wann?

Das Persistence Layer wird vom SAP Basis Team während der Installation und dem Setup der SAP HANA Datenbank konfiguriert. Die notwendigen Parameter werden in der global.ini Datei gespeichert. Auf diese kann man direkt zugreifen oder über das SAP HANA Cockpit im Persistence-Abschnitt. Diese Paramater können jederzeit angepasst werden, um Daten wiederherzustellen oder die System Performance zu optimieren.  So wird beispielsweise die Häufigkeit des Savepoints vom Konfigurationsparamter savepoint_interval_s bestimmt. Dessen Standardeinstellung von 5 Sekunden kann ganz einfach geändert werden. Da der Savepoint Daten auf eine Disk speichert, sollte man dafür entsprechend eine Kosten/Nutzen Abwägung machen.

Warum?

Warum brauchen wir ein Persistence Layer in SAP HANA? Genau aus den Gründen, die wir in unserem obigen Szenario angesprochen haben: um In-Memory Daten zu sichern – oder zu „erhalten“ – im Falle eines Netzausfalls oder eines anderen Systemcrashs.

Außerdem trägt das SAP HANA Persistence Layer dazu bei, folgende Eigenschaften für eine Datenbank zu erfüllen: Atomarität – Beständigkeit – Isolation – Dauerhaftigkeit (englisch: ACID, Atomicity – Consistency – Isolation – Durability. Das Persistence Layer gewährleistet, dass die Datenbank-Transaktionen ACID bleiben. Und zwar dadurch, dass sichergestellt wird, dass jede Transaktion entweder komplett ausgeführt oder komplett zurückgefahren wird (atomicity und consistency) und dadurch, dass die Daten im letzten gespeicherten Zustand wiederhergestellt wird nach einem Neustart (durability).

Wie?

Das ist die alles entscheidende Frage: Wie funktioniert das?

Die technischen Details sind in vielen Internetquellen gut dokumentiert, aber die grundlegenden Schritte können wie folgt zusammengefasst werden:

SAP HANA Persistence Layer

  • Die SAP In-Memory Datenbank speichert den Großteil ihrer Daten In-Memory – für eine maximale Performance und gleichzeitig wird das Schreiben von Daten auf eine Festplatte minimiert.
  • SAP HANA ist dabei aber immer noch abhängig von dauerhafter Speicherung, um eine Art Sicherheitsnetz zu bereitzustellen, falls der Strom ausfällt oder es zu einer anderen Art von Systemcrash kommt.
  • Das HANA System nutzt eine Kombination aus „write-ahead“ oder „redo Transaktions-Logs“ und dem letzten Savepoint, um den letzten aktuellen Stand der HANA Datenbank nach einem plötzlichen Herunterfahren wiederherstellen zu können.
  • Wenn eine Datenbank-Transaktion „In-Memory“ folgt, werden die geänderten Memory-Seiten von den redo Logs erfasst, bevor diese Änderungen tatsächlich auf der physischen Datenbank erfasst werden. Diese „write-ahaed“ Logs können sowohl für „redo“ und „undo“ Ausführungen genutzt werden. So stellen sie komplette Rollforward- und auch Rollback-Optionen für individuelle Transaktionen sicher.
  • Die In-Memory Daten und die transaktionellen Loginformationen werden in regelmäßigen Savepoint-Intervallen automatisch auf der Festplatte gespeichert.
  • Die In-Memory Seiten, die Daten enthalten, werden auf das Datenvolumen geschrieben, um sie zu erhalten.
  • Die redo Logeinträge werden auf die transaktionellen Logvolumina geschrieben – und zwar für alle Änderungen der persistenten Daten, die In-Memory vorgenommen wurden seit dem letzten Savepoint.
  • Daten, die zu einem Savepoint gehören, sind der letzte konsistente Zustand von Daten, die auf einer Festplatte gespeichert sind. Sie bleiben dort, bis der nächste Savepoint vollständig ist.
  • Falls ein Neustart notwendig ist, können Daten vom letzten Savepoint vom Datenvolumen gelesen werden. Dabei kommen die redo Logeinträge ins Spiel, sodass die letzten eingegebenen Datenänderungen „vorwärts“ geschrieben werden können und so der Zustand vor dem Neustart wiederhergestellt werden kann.

Kurz gesagt:

Das Persistence Layer in der SAP HANA Datenbank kann dir die Qualen eines In-Memory Datenverlustes nach einem unerwarteten Ausfall ersparen. Und es spielt eine große Rolle dabei, den ausfallsicheren Betrieb deiner SAP HANA Datenbank zu gewährleisten!

Du hast Fragen oder brauchst Hilfe bei der Implementierung deines SAP BW on HANA oder SAP BW/4HANA Systems in deinem Unternehmen? Wir bei Inspiricon freuen uns auf deine Kontaktaufnahme!

SAVE THE DATE: Erfahre mehr über dieses und andere verwandte SAP HANA Themen in unserem kommenden Webinar „Ihr Weg zu BW/4HANA“ am 05. Juli 2018 um 10 Uhr. Sichere dir heut deinen Platz unter diesem Link.

Bildquellen:

  1. https://sapstudent.com/hana/sap-hana-architecture-part-3/2
  2. https://www.tutorialspoint.com/Persistence-layer-in-SAP-HANA
Autor dieses Beitrags
Andrea Taylor Senior Consultant SAP BI
Tel.: +49 (0) 7031 714 660 0
E-Mail: info@inspiricon.de