(Last Updated On: 3. Juli 2017)

Mit SAP HANA 2.0 ändern sich viele Rahmenbedingungen in der SAP Basis Administration. Dieser Beitrag listet die wichtigsten Neuerungen für HANA-Administratoren in den verschiedenen Bereichen und bietet somit eine Übersicht zur Implementierung der einzelnen Neuerungen in der eigenen Systemlandschaft.

Neuerungen in der Administration

Die Delivery Unit des „SAP DB Control Centers“ wird mit SAP HANA 2.0 obsolet. Sollten Sie das SAP DBCC unter SAP HANA 1.0 installiert haben, sollten sie es vor einem Upgrade auf HANA 2.0 entfernen. Die Prozedur ist in SAP Note 2385193 beschrieben.

Mit SAP HANA 2.0 wird eine neue Version des SAP HANA Cockpit ausgerollt. Hierfür gibt es eine zentrale SAP Note – 2380291. Darin sind beispielsweise Anleitungen zum Upgrade des SAP HANA Cockpits beschrieben. Desweiteren ist das SAP HANA Cockpit nun eine extra installierbare Softwarekomponente, die auf einem externen Knoten mit der SAP HANA Express Edition gehostet werden kann. Die SAP HANA Cockpit Instanz können Sie dann mit den eigentlichen in Ihrer Betriebslandschaft genutzten SAP HANA-Instanzen verbinden und diese dann vom zentralen SAP HANA Cockpit aus administrieren. Dadurch haben Sie nur noch einen zentralen Administrationsknoten für all Ihre SAP HANA Datenbanken. Ein weiterer Vorteil ist, dass Sie das SAP HANA Cockpit nun auch zur Steuerung von HANA Instanzen nutzen können, die gerade gestoppt sind. Somit können Sie ab sofort beispielsweise Backup-Recoverys über das SAP HANA Cockpit fahren. Das war früher nicht möglich, weil das SAP HANA Cockpit früher auf der HANA Instanz lief, die recovered wurde und daher nicht verfügbar war, um den Recovery zu überwachen und zu kontrollieren.

Ein wichtiges Feature für die Workload Administration unter SAP HANA 2.0 ist nun, dass Sie Limits für die Nutzung von Ressourcen wie etwa CPU- und RAM-Nutzung setzen können. Dieses Limit ist das Maximum, welches von den HANA-Prozessen zusammengenommen genutzt werden darf. Dies verhindert, dass das System durch zu starke Auslastung nicht mehr reagiert. Dazu müssen Sie in der HANA Konfiguration die Parameter enable_tracking und memory_tracking auf „on“ stellen und den Parameter „admission_control:enable“ auf true. Danach können Sie in den Parametern queue_cpu_threshold, queue_memory_threshold, reject_cpu_threshold und reject_memory_threshold die einzelnen Grenzwerte konfigurieren.

Sie können nun außerdem in der SAP HANA Web-based Development Workbench (SAP Web IDE for SAP HANA) einen SQL Code mit einer SQL Performance Analyse ausführen. Schreiben Sie Ihren SQL-Code und drücken Sie den Hotkey F9.  Drücken Sie nun auf den Button „Plan Analysis“. Sie können nun genau den Ausführungsplan sowie die Laufzeiten des SQL-Statements analysieren. Die Funktionalität ist ähnlich wie beim bekannten Plan Visualizer unter dem SAP HANA Studio.

Im SAP HANA Cockpit können Sie nun unbeaufsichtigte Workload Analysen im Tile „Performance Management“ aufsetzen. So können Sie eine Workload Analyse beispielsweise zeitbasiert einplanen und festlegen, wann der Trace automatisch beendet werden soll. Am nächsten Morgen können Sie dann beispielsweise das Workload-Replay ansehen und analysieren.

Download and Extract Components

Softwarekomponenten, die Sie unter SAP HANA als „Delivery Unit“ installiert haben, können Sie nun im SAP HANA Cockpit von einer HANA Installation exportieren und in eine andere importieren. Somit sparen Sie sich beispielsweise den Aufwand, eine Delivery Unit auf einem Verzeichnis-Share vorrätig halten oder diese wiederholt in einer unter Umständen neueren Version herunter laden zu müssen.

Neuerungen in der SAP HANA Security

Unter SAP HANA 1.0 konnten Sie nur die Datendateien (Data Volumes) der Datenbank verschlüsseln, nicht jedoch die Informationen in den Online Redo Logs. Unter SAP HANA 2.0 können Sie nun die Online Redo Logs verschlüsseln und gewinnen somit einen zusätzlichen Security Layer im Schutz Ihrer beweglichen Daten.

die Root Keys, die für die Verschlüsselung der Data Volumes, Redo Logs und der internen Applikation verwendet werden, können unter SAP HANA 2.0 nun ganz einfach per SQL-Statement verändert werden. Die Berechtigung zur Änderung dieser Schlüssel wird unter SAP HANA 2.0 mit einem neuen System Privilege „ENCRYPTION ROOT KEY ADMIN“ geschützt. Im Gegensatz zu SAP HANA 1.0, kann ein User mit dem Privileg „RESOURCE ADMIN“ die Schlüssel nicht mehr ändern. Zudem ist es nun sehr einfach, eine passwortgeschützte Sicherung der Root Keys auf einen externen Datenträger zu erstellen.

Sie können nun über die Anbindung einer LDAP-Ressource User auf Ihrer SAP HANA 2.0 Datenbank anlegen, bearbeiten und löschen. Dies beinhaltet die Zuweisung zur Mitgliedschaft von Gruppen. Sie können somit beispielsweise SAP IDM, Microsoft Active Directory oder OpenLDAP als Single Point of Truth für Ihren SAP HANA-Benutzerdatenstamm verwenden.

Neuerungen in der SAP HANA System Replication

Da Sie nun eine zentrale SAP HANA Cockpit-instanz zur Steuerung sämtlicher HANA-Instanzen in Ihrer Systemlandschaft installieren können, können Sie im SAP HANA Cockpit beide Knoten einer SAP HANA System Replication steuern und die SAP HANA System Replication ohne Einsatz der HANA Kommandozeilentools (hdbnsutil) aufsetzen, sondern ausschließlich über das SAP HANA Cockpit (das gilt zumindest für die Schritte auf Datenbank-Ebene. Vorbereitungen auf Betriebssystemebene sind freilich weiterhin notwendig).

Bislang können Sie mit dem Secondary Node einer SAP HANA System Replication sehr wenig anfangen, da es Ihnen nicht erlaubt war, die Daten aus dem Secondary Node zu lesen. Damit konnten Sie auch nicht den Status der System Replication auf dem Secondary überwachen, sondern mussten immer auf dem Primary schauen.

Mit SAP HANA 2 wird sich das ändern. Der Secondary Node einer System Replication wird dann als read-only Datenbank verfügbar sein, was wiederum bedeutet, dass Sie den Status der System Replication nun auch auf dem Secondary beispielsweise über das SAP HANA Cockpit verfolgen können.

Nicht nur das: in Zukunft können Sie den Secondary entsprechend auch für die Abfrage von Daten für Analysen benutzen, um den Primary zu schonen. Somit ist in gewissem Maße ein gewisser Lastausgleich beim Bearbeiten von Schreib- und Lesezugriffen möglich. Für mehr Infos über die SAP HANA System Replication lesen Sie meinen Blog-Beitrag.

Neuerungen in Backup und Recovery

Früher war es unter SAP HANA 1.0 nicht möglich, das Datenbank-Backup einer Single Container Datenbank in den Tenant einer Multitenant Database Containers Umgebung einzuspielen. Dies ist nun möglich. Ebenfalls können Sie unter SAP HANA 2.0 nun den Kopier- oder Verschiebevorgang einer Tenant Datenbank innerhalb einer Multitenant Database Container-Umgebung optional auch ohne interne Verschlüsselung durchführen. Früher mussten Sie dazu zwingend eine Zertifikats-Konfiguration durchführen, da eine Verschlüsselung für diesen Prozess ein Muss war. Sie können den Verschlüsselungszwang nun umgehen, wenn die beiden Datenbanken nicht mit dem „High Isolation“ Profil konfiguriert wurden, indem Sie den Parameter enforce_database_replication auf „Off“ stellen. Außerdem können Sie nun einen Performance Trace für Multiple Tenant Datenbanken aktivieren um etwa die Performance von Cross-Database-Queries zu messen. Dies ist freilich nur möglich, wenn die einzelnen Tenants nicht im High Isolation Profil voneinander abgeschottet sind.

Desweiteren können Sie nun, da Sie die Möglichkeit haben, ein zentrales SAP HANA Cockpit zu betreiben, über das HANA Cockpit eine SAP HANA Datenbank recovern.

Sie können nun in Ihrem Recovery-Statement zur Recovery einer SAP HANA Datenbank angeben, wo der Backup Catalog liegt. Dieser ist notwendig, um alle Online Redo Log Files zu finden, die für den Recovery-Prozess notwendig sind, oder ein einzelnes Backup-File anhand einer Backup-ID zu finden.

Es ist nun möglich, die Online Log Backups mehrerer Prozesse in eine einzige Datei zusammen zu fassen, so dass ein Log Backup nur noch aus einer einzigen Datei besteht. Desweiteren ist es nun möglich, ein Log Backup nach dem Eintreten bestimmter Events anzustoßen. Zuvor unter SAP HANA 1.0 wurden Log Backups nur gemacht, wenn das Log Segment entweder voll war oder eine gewisse Zeitspanne vergangen ist. Nun können Sie etwa mit dem Paramter max_log_backup_size eine Größe angeben, ab welcher ein Logsegment automatisch gebackupt werden soll, selbst wenn das Logsegment selbst noch eine höhere Kapazität her geben würde.

SAP HANA Dynamic Tiering

Unter SAP HANA 2.0 ändert sich auch einiges im Bereich des Dynamic Tiering. So können Sie nun auch unter SAP HANA 2.0 über die „Data Aging“-Funktionalität Daten ab einem gewissen Alter vom Default Store (dem Hauptspeicher) in den Extended Store (dem Sekundärspeicher) verschieben.

Mit SAP HANA 2.0 ist es nun auch möglich, einen Standard SAP HANA Host und einen SAP HANA Dynamic Tiering Host auf einer einzigen Betriebssystem-Installation zu betreiben (Same-Host Deployment). Somit müssen Sie die beiden Instanzen nicht mehr auf zwei unterschiedliche Server bzw. virtuelle Maschinen aufteilen. Jedoch bedeutet dies für Sie, dass Sie die Hauptspeicherbereiche, die der SAP HANA Host und der SAP HANA Dynamic Tiering Host nutzen dürfen, aufteilen müssen.

Unter SAP HANA 1.0 konnten Sie für den SAP HANA Dynamic Tiering Host keine inkrementellen Backups ausführen. Dies ist unter SAP HANA 2.0 nun möglich.

Desweiteren können Sie nun auch die Daten eines SAP HANA Dynamic Tiering Host von einem Host auf den anderen über die SAP HANA System Replication Technologie replizieren, was unter SAP HANA 1.0 noch nicht möglich war.

Als letztes Feature kann nun auch der Extended Storage auf dem SAP HANA Dynamic Tiering Host verschlüsselt werden. Für mehr Infos über SAP HANA Dynamic Tiering lesen Sie meinen entsprechenden Beitrag.

Dateisystem GPFS

Bereits in HANA 1 drängt die SAP die Kunden immer mehr von der alten Empfehlung XFS weg zu gehen und auf GPFS zu migrieren, gerade bei Scale-Out Szenarien. Denn GPFS implementiert ein automatisches Fencing auf Dateisystemebene, welches bei einem Host Auto-Failover Verbund mehrerer Scale-Out HANA Knoten sehr wichtig ist, um Probleme in einem Split-brain Szenario zu vermeiden. Ohne ein eingebautes Fencing auf Dateisystemebene muss sich der Administrator selbst um dieses Problem kümmern. Unter HANA 2 soll GPFS nun eine zentrale Empfehlung werden.

Wenn dir dieser Post gefallen hat, teile ihn doch auf Social Media, abonniere und verfolge mich per E-Mail, RSS-Feed, Social Media oder registriere dich auf meiner Seite. Wenn du registriert bist, like den Post bitte, wenn er dir gefallen hat!