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.
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.
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.
Ausgeführt nach einem Release ist somit sichergestellt, dass alle Objekte die korrekten Einstellungen besitzen.
Für eine Implementierung wurde die 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.
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.
Du willst den IoT Core durch eine Multi-Cloud-Lösung ersetzen und die Vorteile weiterer IoT-Services von Azure oder Amazon Web Services nutzen? Dann melde Dich bei uns und wir unterstützen Dich bei der Umsetzung mit unserer Expertise und dem b.telligent Partnernetzwerk.
Domain Lead Data Platform & Data Management
Domain Lead Data Platform & Data Management
Exasol ist ein führender Hersteller von analytischen Datenbanksystemen. Das Kernprodukt ist eine auf In-Memory-Technologie basierende Software für die professionelle, parallele und schnelle Datenanalyse. Normalerweise werden SQL-Statements in einem SQL-Skript sequenziell abgearbeitet. Wie können aber mehrere Statements gleichzeitig ausgeführt werden? Dies zeigen wir anhand eines einfachen Skripts in diesem Blogbeitrag.
Viele Unternehmen mit SAP-Quellsystemen kennen diese Herausforderung: Sie wollen ihre Daten in einen Azure Data Lake integrieren, um sie dort mit Daten aus anderen Quellsystemen und Applikationen für Reporting und Advanced Analytics weiterzuverarbeiten. Auch die neuen SAP-Informationen zur Nutzung des SAP-ODP-Frameworks führten bei b.telligent Kunden zu Fragen. In diesem Blogbeitrag stellen wir drei gute Ansätze zur Datenintegration (in die Microsoft Azure Cloud) vor, die wir bei b.telligent empfehlen und die von der SAP unterstützt werden.
In Teil 1 fassen wir die Anforderungen der Kunden zusammen.
Viele Unternehmen entscheiden sich im Rahmen ihrer aktuellen Modernisierung- und Digitalisierungsinitiativen, ihr Datawarehouse (DWH) oder auch ihre Datenplattform in die Cloud zu heben. Dieser Beitrag diskutiert aus fachlicher/organisatorischer Sicht, welche Aspekte dafür besonders wichtig sind und welche Strategien dabei helfen, etwaige Risiken zu minimieren. Eine Migration sollte nicht als rein technische Übung verstanden werden. "Weiche" Faktoren und Fachlichkeit haben einen deutlich höheren Einfluss.
Kein vorheriger Beitrag
Kein nächster Beitrag
