SAP HANA – Early Unload – Speichernutzung

Noch einmal möchte ich mich mit dem Thema Speichernutzung auseinandersetzen. In anderen Blogartikeln wie „SAP HANA – kein Speicher mehr? Bewusster Early Unload!“ ist bereits die Relevanz der korrekten Einstellung der SAP-BW-Objekte für die vorgesehene Nutzung aufgezeigt worden. Zusammengefasst: Immer alles frühzeitig aus dem Speicher schieben, was nicht immer und sofort für Abfragen benötigt wird. Gesteuert wird dies über die „Early Unload Priority“, die in der HANA-Datenbank auf Tabellenebene gesetzt wird. Da diese Einstellungen nicht im ABAP-Transportwesen (CTS) enthalten sind, muss der Entwickler oder der Betrieb sicherstellen, dass diese Einstellung immer korrekt gesetzt ist. Ansonsten liegen nur für das Staging benötigte Daten aus dem „Data Acquisition Layer“ sehr performant im RAM, was unnötig teuer ist und das System belastet.

Unload Priority

Eine HANA-Datenbank lagert Tabellen anhand ihrer Priorität vom Hauptspeicher auf das physische Storage aus (genannt UNLOAD). Damit stehen die Daten zwar auch nicht mehr direkt für Abfragen zur Verfügung, für Staging-Tabellen kann dies jedoch vernachlässigt werden, da diese z. B. häufig nur in der Nacht benötigt werden, wenn eine Prozesskette läuft. Die Reihenfolge von Auslagerungen wird über die Priorität pro Tabelle eines Objekts gesteuert, die in der Transaktion RSHDBMON manuell gesetzt werden kann. Einige SAP-BW-Objekte wie PSA-Tabellen, Change Logs von normalen ADSOs oder schreiboptimierte ADSO-Objekte haben das Early-Unload-Flag auch im Standard bereits komplett oder in Teilen gesetzt, je nach der von SAP vorgesehenen Nutzung.

Für SAP-BW-Objekte kann nur die Priorität 5 (aktive Daten fürs Reporting) und 7 (Early Unload, inaktive Daten wie Change Logs …) gesetzt werden.

Transaktion RSHDBMON

Die SAP beschreibt dabei auch, dass die manuell in der RSHDBMON gesetzten Einstellungen erhalten bleiben, wenn man ADSOs ändert. Das ist aber nicht vollständig korrekt. Führt ein Transport dazu, dass eine Tabelle über DROP & CREATE neu erstellt wird, enthalten die aktuellen Support Packages von SAP BW 7.5 die Standardeinstellungen für Early Unload. Dies entspricht somit nicht mehr den notwendigen Einstellungen.

Wie man dieses Problem lösen kann: Da wir im SAP-HANA-Umfeld durch die fortschreitende Integration kompletten Zugriff auf die Verwaltungsfunktionen der Datenbank haben, kann analog zur Transaktion RSHDBMON ein natives SQL-Kommando genutzt werden, um die Early Unload Priority korrekt zu setzen. Am besten funktioniert dies, wenn ein sauberes Namenskonzept verfolgt und die Layer der LSA++ entsprechend benannt sind (z. B. P* für Propagation Layer, D* für Datamart Layer, …). Über dieses Prefix im Namen kann ein Programm die ADSOs ermitteln, die im P* Layer liegen, und die Early Unload Settings entsprechend korrigieren. Abrunden lässt sich das Prinzip noch über die Nutzung von Ausnahmetabellen, falls z. B. ein Reporting auf einem Objekt im Propagation Layer aufgesetzt wird. Die LSA++ erlaubt dies explizit.

Der Ablauf der Programmlogik wäre wie folgt:

1. Ermitteln aller zu prüfenden ADSOs über die Prefixes im Namen
2. Ermittlung der genutzten Tabellen über eine API (ABAP-OO-Klasse)
3. Prüfung der Early Unload Priority jeder Tabelle
4. Aktualisieren der Early Unload Priority über ein natives SQL-Kommando

Ausgeführt nach einem Release ist somit sichergestellt, dass alle Objekte die korrekten Einstellungen besitzen.

Für eine Implementierung wurde die hier genutzte AMDP-Klasse zum Bereinigen des Hauptspeichers um eine Funktion erweitert, die das Ändern der Early Unload Priority kapselt. Leider hat die SAP dafür keine API implementiert und programmiert dies aktuell einzeln aus. Zudem wurde zusätzlich zu der Klasse ein ABAP-Report implementiert, der diese aufruft und dem Entwickler oder Betrieb eine Maske bereitstellt, die auch eine Simulation der Änderungen ermöglicht.

Das Programm

Die Klasse ermittelt die zugehörigen Tabellen des übergebenen ADSOs und stellt diese korrekt ein. Zu Beginn werden die notwendigen Datentypen definiert, die Übergaben geprüft und die Datenbankinformationen des SAP-BW-Schemas auf der HANA-DB ermittelt.

Danach wird die eigentliche Programmlogik ausgeführt. Diese ermittelt die betroffenen ADSOs aus der SAP-BW-Tabelle „rsoadso“, die alle ADSOs enthält mit einem statischen Filter auf die Layer. Danach werden die Tabellen zu den ADSOs über eine API ermittelt. Und zuletzt werden die Tabellen entsprechend der Vorgabe über den Aufruf der privaten Methode _set_unload_priority auf Early Unload gestellt.

Die private Methode kapselt den SQL-Zugriff für das Setzen der Early Unload Priority. Damit ist sichergestellt, dass nicht zufällig fremde Tabellen gesetzt werden und die Funktion bei weiteren Erweiterungen der Klasse wiederverwendet werden kann. (Bitte dort besonders aufpassen, Änderungen lassen sich nicht einfach wiederherstellen!)

Quellcode zur Erstellung des Reports

Der Report ermöglicht über einen sehr einfachen Dialog die Steuerung der Klasse und auch die Simulation. Auswirkungen auf die Objekte können vorab geprüft werden. Zudem fällt auf, wenn ein Objekt falsch benannt wurde oder fälschlicherweise erkannt wird. Eine Ausnahmetabelle existiert hier nicht, die Funktionalität ist somit noch vielschichtig und beliebig erweiterbar.

Beim Aufruf des Reports können die Tabellen noch über SQL-Wildcards gefiltert werden, ansonsten greift mindestens der statische Filter auf die Tabellen-Prefixes aus dem Namenskonzept, was Fehler vermeidet.

Diese einfache Funktionalität stellt sicher, dass der Speicher der HANA-DB nicht unnötig belastet wird, und verringert auch die Aufwände bei einem Release bzw. vereinfacht die Prüfungen, ob alle Einstellungen noch den Erwartungen entsprechen. Manuelle Anpassungen entfallen und der Speicher der HANA-Datenbank wird optimal ausgenutzt.