In diesem Beitrag stellen wir die Integration einer SAP HANA Platform 2.0 in unsere Systemlandschaft vor und beleuchten speziell Aspekte des Multi-Tenancy Features und des Sicherungsmanagements.
In-Memory Datenbank
Die Installation der SAP HANA Platform 2.0 erfolgte in Vorbereitung der Conversion eines unserer SAP ERP-Systeme auf das Nachfolgeprodukt SAP S/4HANA. Im Gegensatz zum klassischen ERP, für das man die Wahl aus einem halben Dutzend Datenbanken hat, läuft S/4HANA ausschließlich auf der namensgebenden Datenbank SAP HANA. HANA steht für „High Performance Analytic Appliance“.
Die Bezeichnung als „Platform“ geht auf zusätzliche Integrations- und Entwicklungsfeatures zurück, welche die reine Datenbank-Funktionalität wesentlich erweitern. Da die Datenbank das Kernstück der Plattform bildet, ist der Einfachheit halber zumeist von SAP HANA die Rede. Prägendes Merkmal ist ihr hoher Arbeitsspeicher-Bedarf, woraus sich die Bezeichnung als In-Memory-Datenbank ableitet. Große Teile der Daten werden unmittelbar nach dem Hochfahren direkt in den Arbeitsspeicher geladen und vorbehandelt – die Performance wird also auf physischer wie logischer Ebene optimiert.
Multi-Tenancy Feature
In unserem Implementierungsbeispiel kommt maßgeblich das mit SAP HANA Version 2.0 eingeführte Multi-Tenancy Feature zum Tragen. Dieses erlaubt es – in Entwicklungs- und Testszenarien – zu unterschiedlichen Systemen gehörende Datenbanken als sog. Tenants (Mieter) in ein und demselben HANA System zu versammeln. Wie dies in der Praxis aussehen könnte bzw. ob es für unser konkretes Vorhaben praktikabel ist, war Ziel einer längeren und nicht sonderlich ergiebigen Recherche. Die einzig nennenswerte Voraussetzung bildet demnach ein entsprechender Datenbank-Eintrag in der Product Availability Matrix (PAM).
Im Resultat laufen auf dem HANA System derzeit fünf Datenbanken: die System-Datenbank und vier sog. Tenant-Datenbanken. Der erste Tenant gehört dem HANA System selbst und beherbergt mit der sog. XSEngine (Extended Application Services) die Daten eines optional zu installierenden Applikationsservers für die erweiterte Behandlung von HANA-Tabellen und -Ansichten. Der zweite Tenant gehört dem SAP HANA Cockpit und die zwei Übrigen einem GRC 12.0 System sowie dem S/4HANA. Alle Tenants lassen sich separat starten und administrieren.
Administration & Sicherungskonzept
Für die Administration kommen ein lokal installiertes SAP HANA Studio und das SAP HANA Cockpit, ein Browser-basierter Client mit eigenem HANA-Tenant, zum Einsatz. Das Studio dient uns vorrangig der Anpassung der Parameter, für SQL-Statements und der Prüfung des Sicherungskatalogs. Über das Cockpit werden die regelmäßigen Sicherungen und ihre automatisierte Bereinigung eingerichtet.
Der Bereinigung liegt die sog. „Retention Policy“ zugrunde, verfügbar seit SAP HANA 2.0 SP03 und SAP HANA Cockpit SP07. Mit ihrer Hilfe lässt sich definieren, wieviele Backup-Generationen aufgehoben werden bzw. wie lange diese zurückreichen sollen. Überschreiten Daten- und Log-Sicherungen diese Schwellenwerte, werden sie automatisch gelöscht, wobei zusätzlich festzulegen ist, ob dies nur den Sicherungskatalog betrifft oder auch physisch auf Filesystem-Ebene geschieht. Eine manuelle oder Skript-gestützte Bereinigung ist damit nicht mehr notwendig.
