Data Aging

Data Aging ist ein Verfahren in SAP HANA (der In-Memory-Datenbank von SAP, die Daten im schnellen Arbeitsspeicher hält), das selten genutzte Bewegungsdaten aus dem teuren Arbeitsspeicher auf günstigeren Festplatten-Speicher verlagert. Die Daten bleiben Teil der Datenbank und werden über dieselben SAP-Anwendungen erreicht, liegen aber in einer historischen Partition (einem eigenen, ausgelagerten Datenbereich) außerhalb des Arbeitsspeichers. Standardabfragen sehen nur den aktiven Teil; auf die ausgelagerten Datensätze greift die Anwendung nur mit einem gezielten Hinweis (Data-Temperature-Hint) zu.

Was ist Data Aging?

Data Aging ist ein Konzept aus dem klassischen SAP Business Suite on HANA und aus S/4HANA (dem aktuellen SAP-Kernsystem) bis Release 1909. SAP hat es eingeführt, um den Bedarf an teurem Arbeitsspeicher in der HANA-Datenbank zu senken, in einer Phase, in der dieser Speicher als knappe und teure Ressource galt. Die Weiterentwicklung für S/4HANA hat SAP mit späteren Releases eingestellt; Bestandssysteme mit aktiver Data-Aging-Konfiguration laufen weiter, für neue Landschaften positioniert SAP stattdessen Native Storage Extension (NSE) und Data-Tiering-Konzepte in der Business Data Cloud und in SAP Datasphere.

Fachlich wird Data Aging über Aging-Objekte gesteuert. Ein Aging-Objekt bündelt eine oder mehrere Tabellen einer betriebswirtschaftlichen Kategorie (etwa Finanzbuchhaltungsbelege, Materialbelege, IDocs oder Application Logs) und legt fest, welches Feld als Aging-Datum dient und wie lange ein Datensatz im heißen Bereich verbleibt. Diese Residenzzeit wird pro Aging-Objekt konfiguriert und pro Aging-Lauf ausgewertet. Datensätze, deren Aging-Datum älter als die Residenzzeit ist, wandern beim Aging-Run in die historische Partition der jeweiligen Tabelle. Die historische Partition liegt physisch außerhalb des Hauptspeichers und wird beim Systemstart nicht geladen.

Auf der Anwendungsebene bleibt der Zugriff transparent: ABAP-Programme, Fiori-Apps und Reports lesen die Tabelle über dieselben Views wie zuvor. Standardabfragen liefern nur den heißen Teil zurück und profitieren vom kleineren Datenvolumen. Für den Zugriff auf historische Datensätze setzt die Anwendung einen Data-Temperature-Hint (WITH RANGE_RESTRICTION), der die historische Partition in die Abfrage einbezieht. Ohne diesen Hint sieht der ABAP-Kontext die kalten Datensätze zunächst nicht. Diese Trennung wirkt technisch als Performance-Grenze, sie ersetzt keine Berechtigungsregel.

Abgrenzung: Data Tiering, Archivierung, NSE und Multi-Temperature Data Management

Data Aging wird häufig mit angrenzenden Konzepten im SAP-Umfeld und in modernen Datenplattformen verwechselt. Die Unterschiede liegen in Steuerungsebene, Persistenz und Zugriffsweg.

Beispiel: Finanzbelege mit dreijähriger Residenzzeit

Ein S/4HANA-System aus einem älteren Release hat für das Aging-Objekt FI_DOCUMNT (Finanzbelege) eine Residenzzeit von drei Jahren konfiguriert. Beim monatlichen Aging-Lauf verschiebt das System alle Positionen in BKPF und BSEG, deren Buchungsdatum älter als drei Jahre ist, in die historische Partition der jeweiligen Tabelle. Die historische Partition liegt auf Disk-Storage außerhalb des HANA-Hauptspeichers.

Ein Fiori-Bericht für offene Posten liest ohne Data-Temperature-Hint gegen die Tabellen und sieht nur die aktiven Belege der letzten drei Jahre. Der Report läuft schneller, weil sowohl die Datenmenge im Column Store als auch der Scan-Bereich im Query kleiner geworden ist. Für die Jahresabschlussprüfung setzt ein Auditor-Report auf einer eigenen SELECT-Klausel einen Range-Restriction-Hint und greift auf die historische Partition zu. Die Antwortzeit ist höher, weil die Daten aus dem Disk-Layer gelesen werden müssen, ein separater Nachladeprozess aus einem Archiv entfällt aber. Betriebswirtschaftlich stehen die Belege weiterhin unter der Datenhoheit des SAP-Systems.