SARA vs. TJC ASC: Warum die SAP-Transaktion SARA keine vollständige Archivierungsautomatisierung liefern kann

Autor: Thierry Julien, CEO, TJC Group

Sie müssen FI_DOCUMNT archivieren. Sie öffnen die Transaktion SARA, geben den Objektnamen ein und drücken Enter. Der Bildschirm lädt. Und jetzt? Sie sehen eine Reihe von Buttons: Schreiben, Löschen, Speichern, Lesen sowie einen Link zu Customizing. Ab hier liegt alles bei Ihnen: welche Buchungskreise, welche Geschäftsjahre, welche Variante, wann geplant werden soll, was zu tun ist, wenn etwas schiefgeht. SARA hat Ihnen die Werkzeuge gegeben. Einen Plan hat es Ihnen nicht gegeben. Dieser Artikel erklärt, warum dieser Unterschied wichtig ist – und wie vollständige Archivierungsautomatisierung tatsächlich aussieht.

Das Szenario: Sie müssen Finanzbelege archivieren

Beginnen wir dort, wo jede Archivierungsinitiative beginnt: mit einem echten Problem.

Ihr SAP-System läuft seit einigen Jahren. Die ACDOCA-Tabellen sind auf Hunderte Millionen Datensätze angewachsen. Die Systemperformance verschlechtert sich so stark, dass Sie nicht sicher sind, ob der Jahresabschluss nächstes Jahr noch möglich sein wird, und Sie glauben nicht, dass Budget für zusätzlichen Speicher oder einen Wechsel auf eine größere T-Shirt-Größe vorhanden ist. Ihr Basis-Team sagt Ihnen, die Datenbank braucht Entlastung.

Die Antwort, darin sind sich alle einig, sobald Aging und Tiering als irreführende Lösungen erkannt wurden, lautet Datenarchivierung. Sie werden FI_DOCUMNT archivieren, das Archivierungsobjekt für Finanzbuchhaltungsbelege. Es umfasst Tabellen wie BKPF, BSEG, BSAD, BSAK, BSAS und (in S/4HANA) ACDOCA. Es ist eines der volumenstärksten Archivierungsobjekte in jedem SAP-System und typischerweise einer der ersten Kandidaten in jedem Archivierungsprogramm.

Sie melden sich also in SAP an, geben SARA in das Befehlsfeld ein, tragen FI_DOCUMNT als Archivierungsobjekt ein und drücken Enter. Der Bildschirm „Archive Administration“ erscheint. Sie sind bereit zu beginnen. Aber womit genau?

Was SARA Ihnen tatsächlich zeigt

SARA, SAP Archive Administration, ist ein gut strukturiertes Bildschirmbild. Für FI_DOCUMNT zeigt es Ihnen Folgendes:

Die Aktions-Buttons

Schreiben: Hier erstellen und planen Sie den Schreib-Job. Das Schreibprogramm (FI_DOCUMNT_WRI) liest Finanzbelege aus der Datenbank und schreibt sie in Archivdateien. Bevor Sie es ausführen können, benötigen Sie eine Schreibvariante – also eine Auswahlkriterienmenge, die dem Programm sagt, welche Belege zu selektieren sind. Bei FI_DOCUMNT sind die wichtigsten Selektionsfelder Buchungskreis und Geschäftsjahr/-periode. Sie können außerdem nach Belegart, Buchungsdatum und weiteren Kriterien filtern.

Löschen: Sobald der Schreib-Job gestartet ist und die erste Archivdatei erstellt hat, entfernt das Löschprogramm (FI_DOCUMNT_DEL) die entsprechenden Datensätze aus der Datenbank. Dieser Schritt gibt tatsächlich Speicher frei. Der Lösch-Job akzeptiert keine eigenen Selektionskriterien. Er arbeitet mit der Archivierungssitzungsnummer, die während der Schreibphase erzeugt wurde.

Speichern: Der Speicher-Job überträgt die Archivdateien optional in ein Content-Repository oder einen externen Speicher. Je nach Ihrem Customizing kann dies automatisch nach der Schreibphase laufen oder manuell angestoßen werden.

Nachbearbeitung: Das Nachbearbeitungsprogramm (FI_DOCUMNT_PST) bereinigt Sekundärindextabellen (BSAK, BSAS, BSIS), indem es Datensätze entfernt, die während der Löschphase markiert wurden. Es sollte direkt nach dem Löschen laufen.

Der Customizing-Link

Über Customizing konfigurieren Sie objektspezifische Einstellungen: den logischen Dateinamen für Archivdateien, die maximale Dateigröße, ob Lösch- und Speicher-Jobs automatisch oder manuell laufen, sowie das Archivierungsszenario (Löschen vor Speichern oder Speichern vor Löschen). Außerdem pflegen Sie eine Mindestverweildauer, um Daten zu schützen, die nicht archiviert werden sollen.

Was SARA gut macht

Wo es angebracht ist: SARA bietet Ihnen eine vollständige, transparente Sicht auf die Archivierungsinfrastruktur für jedes Objekt. Sie sehen die Programme, das Customizing, die Protokolle früherer Sitzungen und den Status aktueller Läufe. Für eine einzelne Archivierungssitzung auf einem einzelnen Objekt liefert es alles, was Sie benötigen, um den Prozess korrekt auszuführen.

Das ist wirklich nützlich. SARA ist eine zuverlässige, gut dokumentierte Oberfläche, die SAP-Kunden seit Jahrzehnten dient. Das Problem ist nicht, was SARA Ihnen zeigt. Das Problem ist alles, was es von Ihnen erwartet, als Nächstes zu tun – allein, manuell, jedes einzelne Mal.

Die Lücke: SARA ist ein Startpunkt, kein Motor

SARA zeigt Ihnen die Programme. Es gibt Ihnen Zugriff auf die Buttons. Aber es liefert keine Logik, um sie sicher, in der richtigen Reihenfolge, in großem Maßstab und wiederkehrend auszuführen. Hier werden die Lücken sichtbar – und sie wachsen schnell, sobald Sie von der Archivierung eines einzelnen Objekts zur Durchführung eines unternehmensweiten Archivierungsprogramms übergehen.

Sie müssen jede Variante manuell erstellen und pflegen

Um FI_DOCUMNT für Buchungskreis 1000 und die Geschäftsjahre 2015–2018 zu archivieren, erstellen Sie eine Schreibvariante mit diesen Selektionskriterien. Für Buchungskreis 2000 erstellen Sie eine weitere. Für Buchungskreis 3000 noch eine. Wenn Sie 40 Buchungskreise haben und für jeden sechs Geschäftsjahre archivieren möchten, sprechen wir von Dutzenden Varianten – jede einzeln erstellt, benannt und manuell gepflegt. Das klingt nach nur ein paar Dutzend Jobs, aber ein vollständiges Archivierungsprogramm endet bei Zehntausenden Jobs. Da es sich um einen nicht umkehrbaren Datenarchivierungsprozess handelt, ist ein manueller Lauf nicht gerade das, was das Top-Management erwartet, sobald es sich des Prozesses bewusst ist.

SAP bietet zwar Variantenvariablen, die Daten dynamisch berechnen können, doch diese Funktionalität stößt schnell an Grenzen. Die Archivierung von Finanzbelegen wird typischerweise durch Geschäftsperiode und Verweildauer gesteuert – nicht durch das Kalenderdatum. Variantenvariablen verwenden das aktuelle Systemdatum als Referenzpunkt, was bedeutet, dass sie die Selektionskriterien für einen verzögerten Archivierungslauf, der eigentlich vor Jahren hätte laufen sollen, nicht korrekt erzeugen können. Die Variante muss dann vor der Nutzung manuell angepasst werden – ein mühsamer, fehleranfälliger Schritt, der den Zweck jeder eingerichteten Planung zunichtemacht.

Sie haben keine Kontrolle darüber, was nach dem Schreib-Job passiert

Eine Archivierungssitzung besteht aus mehreren Jobs, und einige davon (der Speicher-Job und der Lösch-Job) sind zu Beginn der Sitzung noch nicht bekannt. Sie wissen nicht einmal, wie viele Lösch-Jobs laufen sollen. Deren Ausführung hängt vom Ergebnis des Schreib-Jobs ab. In SARA haben Sie zwei Möglichkeiten: diese Jobs so konfigurieren, dass sie automatisch über ADK starten, oder sie nach Abschluss des Schreib-Jobs manuell planen.

Wenn Sie den automatischen Start wählen, verlieren Sie die Kontrolle darüber, wie viele Jobs gleichzeitig laufen. Diese Lösch-Jobs, parallel ausgeführt, können die Datenbank überlasten und während der Spitzenzeiten Performance-Probleme verursachen. Wenn Sie den manuellen Start wählen, sind Sie wieder beim Beobachten und Warten: prüfen, ob der Schreib-Job fertig ist, und dann die nächste Phase manuell anstoßen. Keine der beiden Optionen ist zufriedenstellend. Was Sie tatsächlich brauchen, ist eine gesteuerte Ausführung: Jobs, die nach definierten Regeln, in definierten Zeitfenstern und mit Grenzen für parallele Verarbeitung gestartet werden. Das bietet SARA nicht.

Die Sequenzierung über Objekte hinweg liegt vollständig in Ihrer Verantwortung

FI_DOCUMNT wird selten isoliert archiviert. Ein typisches Archivierungsprogramm umfasst MM_MATBEL (Materialbelege), SD_VBAK (Kundenaufträge), IDOC (Intermediate Documents) und potenziell Dutzende weiterer Objekte. Einige dieser Objekte – inzwischen auch FI_DOCUMNT – haben Abhängigkeiten. Bestimmte ILM-Objekte müssen in einer definierten Reihenfolge verarbeitet werden, wobei die Sitzung für Objekt A erst starten darf, nachdem die Sitzung für Objekt B erfolgreich abgeschlossen wurde.

SARA hat keinen Mechanismus, um diese Abhängigkeiten zu verwalten. Jedes Objekt wird unabhängig administriert. Wenn Objekt B fehlschlägt und Sie es nicht bemerken, wird Objekt A entweder mit veralteten Daten laufen oder beim geplanten Start ebenfalls fehlschlagen. Die Koordination der Reihenfolge über 20 oder 30 Objekte hinweg, über mehrere Buchungskreise, ist eine manuelle Orchestrierungsaufgabe, die ständige Aufmerksamkeit erfordert. Wenn der Archivierungs-/ILM-Consultant das Unternehmen verlässt oder im Urlaub ist, steht alles still – und startet meist nie wieder.

Fehlerbehebung ist manuell

Archivierungssitzungen schlagen fehl. Ein Beleg ist durch einen anderen Prozess gesperrt. Ein Batch-Job läuft in ein Timeout. Das System startet während eines Wartungsfensters neu. Wenn das in SARA passiert, bleibt die Sitzung hängen. Der Administrator muss den Fehler bemerken (durch Prüfen von Logs oder Jobstatus), die Ursache diagnostizieren, sie beheben und die unterbrochene Phase manuell neu starten.

SAP hat im Laufe der Jahre OSS-Hinweise veröffentlicht, um dies zu verbessern (Hinweis 2520094 gibt Hinweise zum Fortsetzen unterbrochener Sitzungen, Hinweis 2586921 warnt vor nicht abgeschlossenen vorherigen Läufen), aber das sind Informationshilfen – keine automatisierten Wiederherstellungsmechanismen. Der Mensch bleibt der Fehlerbehandler. Diese manuellen Fallstricke gehören zu den Hauptgründen, warum SAP-Datenarchivierungsprojekte scheitern können.

Es gibt kein Bewusstsein dafür, wann Archivierung laufen sollte – oder nicht

Archivierungsjobs verbrauchen Systemressourcen. Einen großen FI_DOCUMNT-Schreib-Job während der Spitzenzeiten auszuführen, verschlechtert die Antwortzeiten für Online-Nutzer. Ihn während des Monatsabschlusses laufen zu lassen, ist noch schlimmer. Die Jobplanung in SARA ist rudimentär: Sie wählen Startdatum und -zeit. Es kennt keine Geschäftskalender, Wartungsfenster oder Sperrzeiten. Archivierungsläufe an diese Rahmenbedingungen anzupassen, ist eine manuelle Abstimmungsaufgabe zwischen Archivierungsteam, Basis-Team und Fachbereich.

Ohne Wiederholung verpuffen die Gewinne

Das ist die folgenreichste Lücke. Ein initiales Archivierungsprojekt für FI_DOCUMNT kann sechs Jahre historischer Belege entfernen, und die anschließende ACDOCA-Komprimierung kann die relevanten Tabellen um 30 % oder mehr reduzieren. Beeindruckende Ergebnisse. Aber SAP-Datenbanken wachsen typischerweise um 15–20 % pro Jahr. Ohne regelmäßige, wiederkehrende Archivierungssitzungen werden diese Gewinne innerhalb von 18 Monaten wieder aufgezehrt.

SARA bietet keinen Mechanismus, um sicherzustellen, dass die Archivierung weiterläuft, nachdem das Projektteam weitergezogen ist. Es gibt keine Wiederholungs-Engine, kein geplantes Sitzungsprogramm und keine Alarmierung, wenn die Archivierung über einen definierten Zeitraum nicht gelaufen ist. Deshalb starten so viele Organisationen alle paar Jahre Archivierungsprojekte von Grund auf neu – ein kostspieliger, frustrierender Zyklus, den die TJC Group in mehr als 25 Jahren SAP-Datenmanagement-Engagements immer wieder erlebt hat. Von Anfang an die richtigen Archivierungsstrategien zu wählen – einschließlich Planung für Automatisierung und Wiederholung – ist entscheidend, um diesen Zyklus zu durchbrechen.

Die wichtigsten Erkenntnisse

SARA ist ein Startpunkt, kein Motor. Es zeigt Ihnen die Archivierungsprogramme, das Customizing und die Protokolle. Es plant Ihre Sitzungen nicht, generiert Ihre Varianten nicht, sequenziert Ihre Objekte nicht, stellt sich nicht nach Fehlern wieder her und stellt nicht sicher, dass die Archivierung nächsten Monat läuft. Alles, was über das Drücken der Buttons hinausgeht, liegt in Ihrer Verantwortung.

Die eigentliche Herausforderung ist nicht, eine Sitzung auszuführen. Es ist, ein Archivierungsprogramm dauerhaft aufrechtzuerhalten. Ein einzelner FI_DOCUMNT-Lauf in SARA ist unkompliziert. 30 Objekte über 40 Buchungskreise hinweg jeden Monat, über Jahre, ohne Lücken oder Fehler zu betreiben, ist ein grundlegend anderes Problem. Dieses Problem erfordert Automatisierung.

Archivierungsgewinne sind ohne automatisierte Wiederholung nur temporär. Datenbanken wachsen um 15–20 % pro Jahr. Ein initiales Archivierungsprojekt verschafft Zeit; automatisierte Wiederholung über ASC macht die Reduktion dauerhaft.

Wenn Sie SAP-Datenarchivierung ausschließlich über SARA verwalten – Varianten manuell erstellen, Jobs manuell planen, Logs manuell prüfen –, setzen Sie qualifizierte Ressourcen für Arbeit ein, die automatisiert werden sollte. Die TJC Group hat mit über 25 Jahren Expertise im SAP-Datenvolumenmanagement das Archiving Sessions Cockpit entwickelt, um genau dieses Problem zu lösen. Kontaktieren Sie uns, um zu sehen, wie vollständige Archivierungsautomatisierung in Ihrer Landschaft aussehen kann.