SAP-Archivierung in S/4HANA: Datenvolumen dauerhaft senken

SAP-Datenarchivierung: Objekte und Ablauf

Die Datenarchivierung entfernt abgeschlossene Geschäftsvorfälle aus der Datenbank und schreibt sie in Archivdateien. Die Daten verschwinden dabei nur aus der Datenbank, nicht aus der Anwendung: Sie bleiben lesbar, lassen sich aber nicht mehr ändern.

Grundlage ist das Archivierungsobjekt. Es legt fest, welche Tabellen zu einem Geschäftsobjekt gehören und welche Programme sie verarbeiten. Buchhaltungsbelege archivieren Sie zum Beispiel mit FI_DOCUMNT, samt Änderungsbelegen und Texten, Verkaufsbelege mit SD_VBAK. Welche Tabellen ein Objekt umfasst, zeigt die Transaktion DB15. Die Archivierung ist anwendungsintegriert: Das Schreibprogramm prüft für jeden Beleg, ob er archiviert werden darf, etwa ob er abgeschlossen ist und seine Mindestlaufzeit erreicht hat.

Gesteuert wird alles in der Archivadministration (Transaktion SARA). Die Läufe sind Hintergrundjobs und arbeiten in getrennten Schritten:

1. Schreiben. Das Schreibprogramm schreibt die archivierbaren Objekte in neue Archivdateien und komprimiert sie dabei, laut SAP bis zum Faktor 5. Es löscht nichts.
2. Ablegen. Optional übergibt das System die Dateien über die Content Management Infrastructure (ArchiveLink) an ein Content-Repository in einem angeschlossenen Ablagesystem. Ob vor oder nach dem Löschen abgelegt wird, stellen Sie im Customizing des Archivierungsobjekts ein.
3. Löschen. Das Löschprogramm liest die Archivdatei und entfernt nur die Daten aus der Datenbank, die es dort wiederfindet. Für viele Objekte gibt es eine Testvariante.
4. Nacharbeiten. Je nach Objekt folgen ein Nachlaufprogramm und das Füllen der Archivindizes, damit die Daten später auffindbar sind.

Weil Schreiben und Löschen getrennt sind, lässt sich ein abgebrochener Lauf wieder aufsetzen, und gelöscht wird nur, was sicher im Archiv steht. Die größte Sicherheit bietet die Reihenfolge „erst ablegen, dann löschen“.

Zugriff auf archivierte Daten

Archivierte Daten bleiben über das System erreichbar: einzeln lesend, sequenziell für Auswertungen und, wo das Objekt es vorsieht, durch Zurückladen in die Datenbank. Für die gezielte Suche gibt es das Archivinformationssystem (Transaktion SARI). Es baut aus Feldkatalogen Archivinformationsstrukturen auf, eine Art Index über die Archivdateien.

Wie gut der Zugriff im Alltag funktioniert, hängt an diesen Strukturen. Ein Beispiel aus der Finanzbuchhaltung: Die Beleganzeige FB03 zeigt archivierte Belege nur, wenn eine aktive Infostruktur auf Basis der Feldkataloge SAP_FI_DOC_001 oder SAP_FI_DOC_002 existiert. Für Einzelpostenlisten regeln die Laufzeiten der Sekundärindizes, wie lange archivierte Belege dort direkt erscheinen. Klären Sie deshalb vor dem ersten Lauf mit dem Fachbereich, wer welche Daten auf welchem Weg noch sehen muss.

SAP ILM: Archivierung nach Regeln

SAP Information Lifecycle Management (ILM) baut auf der Datenarchivierung auf. Es ergänzt sie um Regeln für den Lebenszyklus produktiver und archivierter Daten:

• ILM-Regeln: Aufbewahrungsregeln bilden gesetzliche Vorgaben ab, Verweilregeln legen fest, wie lange Daten mindestens in der Datenbank bleiben. Gepflegt werden sie in ILM-Regelwerken (Transaktion IRMPOL).
• Rechtsfallbedingte Sperren: Daten, die für ein Verfahren gebraucht werden, lassen sich gegen vorzeitiges Vernichten sperren.
• Vernichtung: Daten ohne Sperre, deren Aufbewahrungsfrist abgelaufen ist, können vernichtet werden, im Archiv und in der Datenbank.
• ILM-Ablage: Archivierte Daten liegen in einer ILM-fähigen Ablage, die sie laut SAP vor Veränderung und vorfristigem Löschen schützt.

Technisch nutzt ILM die vorhandenen Archivierungsobjekte. Sind die Business Functions für ILM aktiv, bietet das Schreibprogramm zusätzliche ILM-Aktionen an, etwa eine Archivierung, die die hinterlegten Aufbewahrungsfristen auswertet, oder eine Datenvernichtung. Welche Archivierungsobjekte zu welchem ILM-Objekt gehören, listet SAP-Hinweis 2122906. Als eigenständiges Retention Warehouse nimmt ILM außerdem Daten stillgelegter Altsysteme auf. Kurz gesagt: ILM ersetzt die Archivierung nicht, es steuert sie nach Regeln.

Keine Rechtsberatung. Welche Fristen für Ihre Daten gelten, ist eine rechtliche Frage. Klären Sie sie mit Rechtsabteilung, Steuerberatung und Datenschutz, bevor Sie Regeln im System hinterlegen.

Data Aging und NSE: weniger RAM, gleiche Datenbank

Zwei verwandte Verfahren senken den Hauptspeicherbedarf, ohne Daten aus der Datenbank zu entfernen.

Data Aging verschiebt Daten innerhalb der Datenbank aus dem aktuellen in einen historischen Bereich, um Arbeitsspeicher zu gewinnen. Für Buchhaltungsbelege gibt es dafür das Aging-Objekt FI_DOCUMENT. SAP nennt es ausdrücklich als Alternative zur Archivierung mit FI_DOCUMNT. Auch hier ist Abstimmung nötig: Die CDS-basierten Berichte im Meldewesen von SAP Document and Reporting Compliance etwa lesen laut SAP nur den aktuellen Bereich.

Native Storage Extension (NSE) ist ein Warm-Speicher in SAP HANA. Selten genutzte Tabellen, Partitionen oder Spalten werden als „page loadable“ gekennzeichnet und nur seitenweise bei Bedarf über einen Buffer Cache in den Hauptspeicher geladen. Die Kapazität der Datenbank ist dann der heiße Teil im Speicher plus der warme Teil auf Platte. Einsatz und Einschränkungen in S/4HANA beschreibt SAP-Hinweis 2816823.

Entscheidend für die Abgrenzung: Bei beiden Verfahren bleiben die Daten Teil der Datenbank. Warme NSE-Daten nehmen laut SAP an Backup und Systemreplikation teil. Sie stecken also weiter in jedem Backup und in jeder Vollkopie.

Was sich bei Protokollen, IDocs und anderen technischen Daten löschen lässt, zeigt der Artikel Technische Tabellen aufräumen.

Was Archivierung in S/4HANA bringt und wo sie endet

Neben dem Löschen ist Archivierung das einzige dieser Verfahren, das die Datenbank selbst verkleinert. Das wirkt an mehreren Stellen:

• Hauptspeicher: Weniger Daten in SAP HANA bedeuten weniger RAM, und der ist gerade teuer: Was die RAM-Preise für S/4HANA bedeuten.
• Backups: Eine kleinere Datenbank bedeutet kleinere Backups und kürzere Sicherungs- und Restore-Zeiten.
• Laufzeiten: SAP nennt den zurückgewonnenen Speicherplatz ausdrücklich als Hebel für die Performance der Anwendungsprogramme.
• Kopien: Jede System- oder Mandantenkopie aus der Produktion wird kleiner und schneller. Warum die Datenmenge die Laufzeit einer Mandantenkopie bestimmt, steht im Grundlagenartikel.

Eine S/4HANA-Besonderheit zeigt, warum Sie den Effekt je Objekt planen sollten: Laut SAP-Dokumentation archiviert FI_DOCUMNT zwar die Einträge im Universal Journal (Tabelle ACDOCA), löscht sie aber nicht, weil die Tabelle auch Salden liefert. Wie viel Platz dort frei wird, hängt vom Zusammenspiel mit den Archivierungsobjekten für die Verkehrszahlen ab.

Die Grenzen liegen weniger in der Technik als in der Organisation:

• Projekt mit Fachbereichen: Was archiviert wird, entscheiden Finanzen, Logistik, Revision und Datenschutz mit, nicht die Basis allein.
• Residenzzeiten: Daten bleiben eine Mindestzeit in der Datenbank, festgelegt im Customizing der Anwendung, in FI etwa über Kontoarten- und Belegartenlaufzeiten, mit ILM über Verweilregeln.
• Abhängigkeiten: Manche Objekte lassen sich erst archivieren, wenn ihre Vorgänger archiviert sind. Die Archivadministration zeigt das in einer Netzgrafik.
• Aufbewahrung: Archivdateien müssen über die gesamte Aufbewahrungsfrist lesbar bleiben. Vernichten dürfen Sie erst danach.
• Nicht alles ist archivierbar: Offene Vorgänge und alles, was Betrieb, Reporting und Prüfungen laufend brauchen, bleiben in der Datenbank. Eigene Z-Tabellen brauchen ein eigenes Archivierungsobjekt.

Vorgehen im Archivierungsprojekt

1. Analysieren. Die größten Tabellen und ihr Wachstum ermitteln, etwa mit der Speicheranalyse in DB02. Die Tabellenanalyse TAANA zeigt, wie sich die Einträge auf Organisationseinheiten und Zeiträume verteilen, und hilft bei der Wahl von Archivierungsobjekt und Selektion.
2. Priorisieren. Technische Daten zuerst bereinigen, dann fachliche Objekte mit großem Volumen und klaren Regeln angehen.
3. Abstimmen. Residenzzeiten, Zugriffswege und Aufbewahrungsfristen mit Fachbereichen, Revision und Datenschutz festlegen und in einem Archivierungskonzept dokumentieren.
4. Einrichten. Logische Dateinamen und Pfade (Transaktion FILE), Content-Repository, Archivinfostrukturen und gegebenenfalls ILM konfigurieren.
5. Testen. Den ersten Lauf in einem produktionsnahen Testsystem durchspielen: Schreiben, Löschen im Testmodus, dann echt löschen und den Zugriff aus Sicht der Anwender prüfen.
6. Regelbetrieb. Archivierungsläufe regelmäßig einplanen und überwachen. Archivierung ist kein einmaliges Projekt.

Im Regelbetrieb gehören die Läufe zum Tagesgeschäft, wie Backups und Housekeeping. Wie wir dabei unterstützen, zeigt die Seite SAP Basis, AMS und Managed Services.

Archivierung und Testsysteme

Archivierung verkleinert die Produktion und damit jede Vollkopie. Sie endet aber dort, wo Daten fachlich oder rechtlich online bleiben müssen, und das sind oft mehrere Geschäftsjahre. Eine Vollkopie bringt diese Jahre in QS, Test und Sandbox, obwohl dort meist die letzten Monate reichen.

Hier setzen Zeitscheiben an. Der Data Refresh Operator kopiert einen Zeitraum, zum Beispiel die letzten 90 Tage, und ergänzt alle abhängigen Objekte aus älteren Jahren, aufgelöst bis zum Fixpunkt. Nachweisbar fehlt nichts, und die Produktion bleibt unverändert. Archivierung und Zeitscheibe ergänzen sich: Die eine verkleinert die Quelle, die andere den Teil, der davon in Non-Prod landet.

–75 %

HANA-RAM in Non-Prod

–60 %

Storage & Backup

Richtwerte aus Referenzszenarien. Die tatsächlichen Effekte hängen von Systemgröße, Historie und Refresh-Zyklen ab.

DRO läuft ab SAP S/4HANA 2023 und ersetzt die Mandantenkopie, nicht die Systemkopie. Was das für den Speicher Ihrer Landschaft heißt, zeigt die Seite HANA-Speicher in QS, Test und Sandbox senken.

Quellen

• SAP-Hilfe (SAP S/4HANA): Eigenschaften und Leistungsmerkmale der Datenarchivierung
• SAP-Hilfe (SAP S/4HANA 2025): Finanzbuchhaltungsbelege (FI-GL, FI-AR, FI-AP) mit FI_DOCUMNT archivieren
• SAP-Hilfe (SAP S/4HANA 2025): Archivierte Buchhaltungsbelege (FI) anzeigen
• SAP-Hilfe (SAP S/4HANA 2025): SAP Information Lifecycle Management
• SAP-Hilfe (SAP S/4HANA 2025): Data Aging für Buchhaltungsbelege
• SAP-Hilfe (SAP HANA 2.0 SPS 08): SAP HANA Native Storage Extension