vorheriger Artikel
Optimierte Hauptspeichernutzung bei SAP BW on HANA
Die Ausnutzung des Hauptspeichers ist bei SAP-HANA- und Data-Warehouse-Szenarien immer ein spannendes Thema im Vergleich zu ERP-Anwendungen bzw. Anwendungen mit einem sich gering verändernden Datenvolumen. Somit muss man eines im Hinterkopf behalten: Lasse niemals den freien Hauptspeicher ausgehen.
Sizing
Eine HANA-Datenbank bringt bei der Berechnung des Hauptspeichers einige interessante Eigenschaften gegenüber klassischen Datenbanksystemen mit sich. Einerseits ist der Hauptspeicher die zentrale Ablage der Daten (klassisch: Disk -> Hauptspeicher, HANA: Hauptspeicher -> Auslagerung auf Disk), und andererseits wird der Hauptspeicher auch für die Ausführung von Abfragen genutzt. Somit konkurriert der persistente Bereich mit dem dynamischen Bereich für Abfragen. Dies wird auch von der Berechnungsgrundlage der SAP für HANA-Datenbanken berücksichtigt. Vereinfacht setzt sich diese zusammen aus RAM = Data Footprint * 2 / 7. Zur Berechnung nimmt man die Byte-Breite der Spalten mal die Anzahl der zu erwartenden Zeilen. Diese werden mit dem Faktor 2 multipliziert, damit immer die Hälfte des Hauptspeichers für Abfragen zur Verfügung steht, und durch 7 dividiert, da von einem durchschnittlichen Kompressionsfaktor von 7 ausgegangen wird.
Aus der Erfahrung hat sich gezeigt, dass gerade breitere Faktentabellen aufgrund von Spalten mit niedriger Kardinalität (also wenig verschiedenen Werten) sich sehr gut komprimieren lassen, sodass dort teilweise Kompressionsraten von 30 auftreten. Tabellen mit hoher Kardinalität, wie z. B. hochzählende IDs, haben dabei jedoch einen geringeren zu erwartenden Kompressionsfaktor. Dieses Verhalten resultiert darin, dass Tabellen mit wenig Spalten plötzlich viel mehr Speicher belegen können als sehr breite Tabellen.
Um auch sehr große Datenmengen verarbeiten zu können, existieren innerhalb einer HANA-Infrastruktur viele Möglichkeiten, den Hauptspeicher der HANA-Datenbank zu entlasten. Möglichkeiten mit SAP BW on HANA: Auslagerung auf SSD und Einbindung von Archivservern (Nearline Storage). Die Daten bleiben im Zugriff, belasten jedoch den Hauptspeicher der HANA-Datenbank nicht mehr.
1: HOT à Daten im Hauptspeicher
2: Warm à Daten auf SSD in der HANA-DB – Early Unload oder Extended Tables (SAP HANA Dynamic Tiering)
3: Cold à Daten ausgelagert im NLS
Aber auch bei einer einfachen HANA-Instanz ohne Extended Storage (das Datenmodell wird klassisch auf Platte ausgelagert), Nearline Storage etc. lässt sich das Nutzungsverhalten des Hauptspeichers optimieren, sodass auch ein Data Warehouse mit mehreren Schichten (wie z. B. ein SAP BW mit LSA++) nicht unnötig Daten dort vorhält. Somit lassen sich auch Umgebungen mit 1-TB-Data-Footprint in eine 1-TB-HANA-Instanz laden. Der Trick ist die Nutzung und explizite Steuerung des Early Unload.
Early Unload – Staging-Tabellen raus aus dem Speicher!
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. Somit kann ein SAP BW on HANA gerne auch mehr Speicher belegen als in der von SAP angesprochenen Empfehlung und sauber funktionieren, da Daten im Hauptspeicher bei einem hohen „Memory Pressure“ automatisch ausgelagert werden. Die Reihenfolge von Auslagerungen wird über eine Priorität pro Tabelle eines Objekts in der Transaktion RSHDBMON gesteuert. 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 Steuerung des Unloads von der HANA-Datenbank selber klappt im Allgemeinen sehr gut und auch ohne große Auswirkung auf Abfragen, da nur schreibend auf den physischen Storage zugegriffen wird und die Abfragen aus dem Hauptspeicher bedient werden. Es gibt jedoch einen Punkt, an dem die automatische Handhabung des Unloads nicht optimal funktioniert, und zwar bei der Aktivierung von sehr großen Requests. Die Ursache ist, dass alle Tabellen der betroffenen Objekte in den Hauptspeicher geladen werden. Bei einem normalen ADSO sind dies z. B. die Eingangstabelle, die aktive Tabelle und das Change Log zum Teil. Des Weiteren wird der Hauptanteil der Datenbankoperationen in einer Transaktion ausgeführt und somit der Hauptspeicher stark belastet. Ein automatisch getriggerter Unload kann häufig nicht rechtzeitig durchgeführt werden, bis es zum Rollback kommt und die Aktivierung abbricht (siehe: SAP Hinweis 2399990 – How-To: Analyzing ABAP Short Dumps in SAP HANA Environments).
Mit zwei Vorgehensweisen kann die HANA-Datenbank aber bewusst unterstützt werden:
1. Die Beladung wird in kleineren Paketen über mehrere DTPs mit disjunkten Filtern ausgeteilt (kleinere Datenbanktransaktionen).
2. Alle nicht benötigten Tabellen werden proaktiv aus dem Speicher geladen (bewusster Early Unload).
Eine Beispielrechnung:
Eine HANA-DB würde somit den maximal verfügbaren Hauptspeicher für die physische Datenhaltung belegen: bei einer Größe von 512 Gbyte ca. 460 Gbyte aufgrund des Erreichens der Grenze, ab der ein Unload von Tabellen beginnt.
Die PSA, Data Acquisition Layer und EDWH Layer sind nur zum Teil geladen. Diese haben normalerweise das Early-Unload-Flag bereits gesetzt und wurden somit schnell aus dem Hauptspeicher entfernt. Der Zustand ist in der Transaktion DB02 in der Spalte „Loaded“ sichtbar.
Wollen wir nun den Hauptspeicher prophylaktisch um alle Tabellen bereinigen, die ein Early-Unload-Flag gesetzt haben, würden auch alle von der HANA-DB optional im Hauptspeicher gehaltenen Tabellen entladen werden. In unserem Beispiel hätten wir vereinfacht nur noch eine Belegung von 200 Gbyte und könnten mit dem gewonnenen Speicherplatz auch größere Aktivierungen in dem System durchführen. Auch kann mit diesem Vorgehen die Belastung tagsüber reduziert werden. Es ist dabei aber zu beachten, dass sich die Laufzeit von Prozessketten dadurch verlängern kann, denn in der Nacht müssen die Tabellen für das Staging ggf. wieder in den Hauptspeicher geladen werden.
Umsetzen lässt sich ein bewusster Early Unload sehr einfach mit einer ABAP Managed Stored Procedure und ist damit auch im normalen Transportwesen auf die Systeme verteilbar. Auch die Integration in Prozessketten oder Reports lässt sich durch die ABAP-Integration einfacher umsetzen.
Abschließend möchte ich jedoch noch festhalten, dass dieses Vorgehen nur in speziellen Fällen Anwendung finden sollte: um bei Fullloads eine besondere Behandlung in mehreren DTPs zu vermeiden oder um bei einem nicht erwarteten Datenwachstum die Systemstabilität sicherzustellen. Eine Dauerlösung ist es nicht, jedoch ein guter Weg, sich Zeit zu verschaffen, um eine Erweiterung der Infrastruktur oder eine zu Beginn beschriebene Archivierung von historischen Daten vorzubereiten.
