Unabhängig davon, ob Sie SAP ECC, S/4HANA On-Premise oder die Private Cloud Edition nutzen: Ein proaktives Management des HANA-Memory-Footprints ist entscheidend, um das Datenwachstum langfristig zu kontrollieren. Besonders im Vorfeld einer Cloud-Migration ist eine tiefgreifende Analyse, Reorganisation und Archivierung von Daten wichtig. So beschleunigen Sie den Migrationsprozess und vermeiden unnötige Infrastrukturkosten beim Hyperscaler. Nachfolgend stelle ich Ihnen bewährte Maßnahmen vor, mit denen wir in Kundenprojekten bereits signifikante Einsparungen realisiert haben.
Maßnahmen
Inverted Individual Index
Eine einfache Maßnahme ist die Umstellung von schwergewichtigen Primary- oder Unique-Indizes mit vielen Columns auf schlanke Inverted Individual Indizes. Sie können potenzielle Kandidaten mit dem SQL-Statement "HANA*Indexes_Overview" (ONLY_PK_AND_UNIQUE = 'X', ORDER_BY = 'SIZE') aus dem SAP-Hinweis 1969700 ermitteln. Hierbei wird Ihnen die Größe der Einsparung sowie die möglichen Performance-Nachteile in Form von "Kosten" dargestellt. Im SAP-Hinweis 2600076 (Punkt 6) finden Sie eine Einstufung der Kosten. Tabellen mit einer sehr selektiven Spalte im Primärschlüssel (z.B.: CDPOS und CDHDR) können in der Regel ohne messbare Auswirkung umgestellt werden. Allein mit dieser Maßnahme konnten wir in einem Kundenprojekt *1,5 TB Memory* in einem großen HANA-Data-Warehouse-System einsparen.
Hybrid LOB
Columns mit großen Werten (z. B. Anhänge, Spool-Listen oder ABAP-Quelltexte) werden auf der SAP-HANA-Seite typischerweise in (Hybrid)LOB-Feldern gespeichert (siehe SAP-Hinweis 2220627). Dies kann den Hauptspeicherbedarf erheblich reduzieren, da Disk-LOBs nicht in den Row-Store oder Column-Store geladen werden, sondern stattdessen auf der Festplatte verbleiben.
Allerdings wird erst ab SAP_BASIS 7.53 standardmäßig der VARBINARY Datentyp auf Hybrid LOB umgesetzt – und auch da nur bei neuen Tabellen oder expliziten Tabellen-Conversions (Upgrades, S4-Conversion etc.). Damit Sie sofort von dem reduzierten Memory-Verbrauch profitieren, sind manuelle Tätigkeiten notwendig. Über die Transaktion SE14 kann diese Konvertierung gezielt durchgeführt werden (dokumentiert in SAP-Hinweis 2375917). Genau wie bei den Inverted Indizes empfehlen wir hier eine vorherige Analyse. Dies ermöglicht es, das Einsparungspotenzial bereits vor der Umsetzung realistisch zu bewerten und die Maßnahmen gezielt zu priorisieren.
NSE
Die gezielte Auslagerung von Tabellen, Columns oder Partitionen vom Hot (Memory) in den Warm (Disk) Bereich ermöglicht es, den kostspieligen HANA-Memory effizienter zu nutzen. Die Daten werden dann nur bei Zugriff, seitenweise, in den NSE-Buffer geladen. Daten, die keine oder wenig Verwendung im Daily Business finden (wenig SELECTS), können in der Regel auf NSE-aktiviert gesetzt. Das kann sowohl historische Geschäftsdaten als auch technische Logging- und Auditing-Daten umfassen. NSE kann auch als Vorstufe zur Archivierung implementiert werden – es ersetzt diese jedoch nicht. Jedenfalls sollten weiterhin nicht benötigte und obsolete Daten aus der HANA-DB entfernt bzw. archiviert werden. Auch mögliche Löschpflichten im Rahmen der DSGVO sollten im Blick behalten werden und können mit NSE nicht umgesetzt werden. Wir empfehlen die Implementierung von NSE in zwei Phasen:
-
Phase: unkritische technische Tabellen (Logging, Audit, IDOC-Storage etc.) und erste Erfolge verbuchen
-
Phase: Geschäftstabellen mit historischen Daten.
Jedenfalls muss mit der Implementierung von NSE eine genaue Evaluierung der kundenindividuellen Situation einhergehen. Dies bedeutet, die Performance genau zu prüfen, um negative Auswirkungen auf den Geschäftsbetrieb zu vermeiden. Hierfür können Werkzeuge wie der SQL-Monitor (SQLM), HANA SQL-Cache oder HANA Capture & Replay eingesetzt werden.
Die Partitionierung ist eng verknüpft mit NSE und muss jedenfalls bei der Konzeptionierung mitbetrachtet werden.
Proaktives Datenmanagement
-
Datenwachstum einschränken: Die besten Daten sind jene, die gar nicht erst gespeichert werden – zumindest wenn es um die Kosten bei der Speicherung geht. Oft ist eine tiefgehende Analyse notwendig, um die Verursacher großer Mengen an Application Logs, Änderungsbelegen oder anderen technischen Daten zu finden.
-
Reorganisation: Neben den üblichen Verdächtigen wie
BALDAT,EDID4undCDPOS, schlummern im System oftmals auch weitere ungenutzte historische Daten, welche ohne Reorg-Konzept im System verbleiben. Weniger bekannte Beispiele sind MRP-Listen, MRP-Forecast-Daten, Job-Massenläufe. Um dieser technischen Tabellen Herr zu werden, ist ein ganzheitliches Reorg-Konzept nötig: Top-Verursacher identifizieren, Reorg Jobs mit den entsprechenden Varianten implementieren, regelmäßige Prüfung und Monitoring. -
Archivierung: Ohne ein Archivierungskonzept verbleiben historische Geschäftsdaten in der teuren HANA-Datenbank. Stetiges Wachstum sowie permanente Investitionskosten für Hardware oder größere Instanzen (T-Shirt-Sizes) in der Cloud sind die Folge. Zudem steigen die Backup- & Recovery-Zeiten (mit Auswirkungen auf SLA und RTO) an und die Performance verschlechtert sich. Ohne Archivierung bzw. ILM (Information Lifecycle Management) können Sie zudem die Anforderungen der DSGVO nicht oder nur unzureichend erfüllen.
Fazit
Eine frühzeitige Implementierung dieser beispielhaften Maßnahmen spart Infrastrukturkosten, erhöht die Performance und verkürzt Backup- sowie Recovery-Zeiten. Insbesondere im Kontext von RISE/Private Cloud ist es wichtig, das System schon vor einer Migration zu verschlanken. Ein späteres VM-Downsizing ist oft nicht mehr möglich oder mit erheblichem Aufwand verbunden. Die angepriesene flexible Skalierung der Private-Cloud funktioniert in der Praxis leider oft nur in eine Richtung: nach oben.
Profitieren Sie von unserer langjährigen Erfahrung aus zahlreichen Kundenprojekten. Wir helfen Ihnen bei der Analyse Ihrer Einsparungspotenziale, identifizieren Quick Wins, erstellen Konzepte für NSE sowie Partitionierung und unterstützen Sie bei der technischen Implementierung.
Wir freuen uns auf Ihre Anfrage unter [email protected].
Referenzen
2799997 - FAQ: SAP HANA Native Storage Extension (NSE)
2600076 - FAQ: SAP HANA Inverted Individual Indexes
3693075 - Managing Memory Growth in Technical Tables via Inverted Individual Indexes
2375917 - How-To: Converting SAP HANA VARBINARY columns to LOB