SARA-Schreibjob bricht ab, was jetzt? Restart-Logik für den SAP-Archivbetrieb

Automatische SAP-Archivierungsketten machen den Betrieb komfortabel, bis ein WRITE-Job mitten im Lauf abbricht. Wer dann nicht weiß, was als Nächstes zu tun ist, riskiert Datenverlust und Compliance-Verstöße. Eine systematische Restart-Logik gehört in jeden professionellen SAP-Archivbetrieb.

Wenn ein SARA-Schreibjob abbricht, hängt der korrekte Restart vom Status der nachfolgenden Jobs ab: Ist der STORE-Job noch nicht gelaufen, kann der WRITE-Job nach Behebung der Ursache neu gestartet werden. Ist der STORE-Job durch und der DEL-Job noch offen, müssen die Archivdateien auf Vollständigkeit geprüft werden. Ist der DEL-Job bereits gelaufen, ist eine vollständige Konsistenzprüfung der Archivdateien Pflicht. Beim Archivierungsobjekt CO_TRANS gilt zusätzlich: Der WRITE-Job darf grundsätzlich nicht unterbrochen werden (SAP-Hinweis 2906925).

SARA-Schreibjob bricht ab

Wie eine SARA-Archivierungskette technisch aufgebaut ist

Die Standard-Archivierungskette in SAP umfasst drei Phasen: WRITE, STORE und DEL. Im WRITE-Schritt werden die Daten aus der SAP HANA-Datenbank in eine Archivdatei geschrieben. Im STORE-Schritt wird diese Datei auf das angeschlossene Speichersystem (Content Server, SAP-Archivsystem, Cloud-Storage) übertragen. Im DEL-Schritt werden die archivierten Datensätze aus der produktiven Datenbank entfernt.

In automatisierten Setups werden diese Phasen über Jobketten oder Hintergrundjobs miteinander verknüpft. Der DEL-Job startet erst, wenn der STORE-Job erfolgreich war; der STORE-Job läuft erst, wenn der WRITE-Job durch ist. Solange die Kette glattläuft, ist das ein robustes Verfahren.

Kritisch wird es, wenn die Kette unterbrochen wird, durch einen Job-Abbruch, einen Systemausfall, Speicherprobleme oder einen Fehler im SAP-Archivierungs-Customizing. Genau dann beginnt die Restart-Logik.

Vier Abbruch-Szenarien und der korrekte Umgang

In der Praxis lassen sich die meisten Abbruch-Situationen einem von vier Szenarien zuordnen. Die folgende Tabelle zeigt das Vorgehen pro Szenario:

Warum CO_TRANS in SAP S/4HANA besondere Beachtung braucht

In SAP S/4HANA wurden viele Summentabellen aus der SAP ECC-Welt durch CDS-Views ersetzt. Für das Controlling bedeutet das: Die klassischen Summentabellen COSS und COSP werden nicht mehr direkt geschrieben, sondern über CDS-Views aus dem Universal Journal (ACDOCA) abgeleitet. Wenn der WRITE-Job für das Archivierungsobjekt CO_TRANS unterbrochen wird, können diese CDS-Views in einen inkonsistenten Zustand geraten, mit der Folge, dass anschließende Reports und Auswertungen fehlerhafte Werte liefern.

SAP hat das Verhalten im SAP-Hinweis 2906925 dokumentiert. Der Hinweis beschreibt die Restart-Logik im Detail und ist Pflichtlektüre für jeden, der CO_TRANS in einer produktiven SAP S/4HANA-Landschaft betreibt. In der Praxis kommt hinzu, dass die Wiederherstellung der Konsistenz nicht trivial ist, typischerweise erfordert sie Eingriffe der SAP-Basis und enge Abstimmung mit dem Controlling-Modul-Team.

Was Automatisierung nicht ersetzt: die Fehlerbehandlung

Die Stärke der automatisierten SAP-Archivierungsketten ist gleichzeitig ihre Schwäche: Sie laufen verlässlich, solange nichts schiefgeht. Sobald ein Job abbricht, müssen Menschen entscheiden, was als Nächstes zu tun ist. Diese Entscheidung erfordert drei Voraussetzungen, und genau hier liegt in vielen SAP-Landschaften die Lücke:

• Ein klar definierter Eskalationspfad. Wer wird informiert, wenn ein SAP-Archivierungs-Job abbricht? Wer hat Entscheidungsbefugnis für den Restart? Wer entscheidet bei kritischen CO_TRANS-Abbrüchen?

• Dokumentierte Restart-Verfahren. Pro Archivierungsobjekt sollte beschrieben sein, wie ein Abbruch zu behandeln ist, inklusive der Sondersituationen wie CO_TRANS, MM_MATBEL oder FI_DOCUMNT.

• Kompetenz im Bereitschaftsdienst. SARA-Restart ist kein Standard-Helpdesk-Thema. Wer entscheidet, ob eine Archivdatei verworfen oder fortgeführt wird, braucht SAP-Archivierungs-Spezialwissen, und Erfahrung aus mehreren realen Abbruch-Situationen.

Drei Praxis-Tipps aus dem laufenden SAP-Archivbetrieb

1. Eine konkrete Eskalationskette pro Archivierungsobjekt

Statt einer allgemeinen Eskalations-Mailingliste hat es sich bewährt, pro kritischem Archivierungsobjekt eine eigene Eskalationskette mit Reaktionszeiten zu definieren. Ein typisches Muster aus der AMS-Praxis sieht so aus:

Eine solche Kette steht in der Verfahrensdokumentation, ist allen Beteiligten bekannt und wird bei der jährlichen Datenschutz- oder GoBD-Prüfung mit vorgelegt. Was sie nicht ersetzt: die tatsächliche Bereitschaft. Aber sie verhindert das improvisierte "Wer macht jetzt was?" am Donnerstagabend um 17:30 Uhr.

2. Konkretes Monitoring statt Mail-Flut

Pro Job-Abbruch eine E-Mail an den SAP-Verteiler ist die häufigste, aber schwächste Form von Monitoring. Wenn die Verteilerliste 40 Personen umfasst und täglich drei Job-Status-Mails verschickt, wird das wichtige im Rauschen untergehen. In der Praxis bewährt:

• Zentrale Monitoring-Sicht. Job-Statusübersicht über alle Archivierungsketten in einem einzigen Dashboard (z.B. SAP Solution Manager, BW-basiertes Monitoring oder Drittanbieter-Tools). Pro Job: Status, Laufzeit, Datenmenge, Trend gegenüber Vorlauf.

• Alerting nur bei Ausnahmen. Push-Benachrichtigung (E-Mail, Teams, SMS) ausschließlich bei Abbruch oder Schwellwert-überschreitung. Erfolgreiche Läufe werden im Dashboard sichtbar gemacht, nicht aktiv vermeldet.

• Wöchentliches Review. Einmal pro Woche 30 Minuten Sichtung im SAP AMS-Reporting: Welche Jobs sind langsamer geworden? Welche Datenmengen wachsen schneller als erwartet? Welche Schwellwerte müssen angepasst werden?

3. Verfahrensdokumentation als lebendes Dokument, nicht als PDF im Ordner

Die GoBD verlangt eine Verfahrensdokumentation. In vielen Unternehmen ist das ein PDF, das vor drei Jahren erstellt und seitdem nicht mehr angefasst wurde. Bei einer Steuerprüfung wird das schnell unangenehm. Eine bewährte Alternative aus der AMS-Praxis:

• Pro Archivierungsobjekt ein Datenblatt. Ein Seite, ein Archivierungsobjekt: Selektionskriterien, Aufbewahrungsfristen, Eskalationskette (siehe Tipp 1), Restart-Verfahren, letzte Änderungen.

• Versionsführung mit Datum und Verantwortlichem. Jede Änderung am Archivierungs-Customizing oder an den Selektionsparametern führt zu einem neuen Datenblatt-Versionsstand. Wer hat was wann warum geändert?

• Prüfungsfähig auf Knopfdruck. Bei einer GoBD- oder DSGVO-Prüfung kann die komplette Verfahrensdokumentation in wenigen Minuten zusammengestellt werden. Idealerweise als PDF-Export aus dem führenden Dokumentations-Tool.

Diese drei Bausteine, konkrete Eskalation, sinnvolles Monitoring, lebende Verfahrensdokumentation, sind keine Theorie. Sie sind das Ergebnis aus AMS-Projekten, in denen genau die fehlenden Strukturen der Auslöser für die Beauftragung waren.

SAP Archive Managed Service: SARA-Restart als Teil des Betriebsvertrags

Mit einem SAP Archive Managed Service ist der Umgang mit SARA-Job-Abbrüchen kein Improvisationsthema mehr. Die drei oben beschriebenen Bausteine sind Teil des Vertrags: dokumentierte Eskalationskette pro Archivierungsobjekt, definierte Reaktionszeiten, zentrales Monitoring und eine laufend gepflegte Verfahrensdokumentation.

Konkret bedeutet das: Erstreaktion innerhalb der vereinbarten SLA-Zeit, Spezialisten-Verfügbarkeit für CO_TRANS, FI-Belege und Materialbewegungen, Ad-hoc-Konsistenzprüfung der Archivdateien, Beratung bei Sonderfällen, dokumentierte Übergabe an die Modul-Verantwortlichen. Single Point of Contact für alle SAP-Archivierungs-Fragen, planbare monatliche Kosten.

Was sich aus Sicht des SAP-Teams beim Kunden ändert: Der Bereitschaftsdienst muss SARA-Restart-Logik nicht mehr selbst beherrschen. Das macht den Unterschied an einem Donnerstagabend, wenn ein WRITE-Job für CO_TRANS um 17:30 Uhr in den Status "abgebrochen" geht.

Unsere Empfehlung

Wer SAP-Datenarchivierung produktiv betreibt, sollte das Thema Job-Abbrüche aktiv adressieren, bevor der erste Ernstfall eintritt. Die Frage ist nicht, ob ein WRITE-Job mal abbricht, sondern wann. Eine systematische Restart-Logik, die in der Verfahrensdokumentation verankert ist und mit konkreten Eskalationsketten arbeitet, schützt vor Datenverlust, Compliance-Verstößen und improvisierten Eingriffen.

Als SAP Partner unterstützen wir Unternehmen mit dem SAP Archive Managed Service genau an dieser Stelle. Vom Customizing über das Monitoring bis zur dokumentierten Restart-Logik, der gesamte SAP-Archivbetrieb aus einer Hand, mit definierten SLAs und planbaren Kosten.

Häufig gestellte Fragen

Was passiert, wenn ein SARA-Schreibjob abbricht?

Der korrekte Umgang hängt vom Status der nachfolgenden Jobs (STORE und DEL) ab. Im einfachsten Fall, STORE noch nicht gelaufen, kann der WRITE-Job nach Behebung der Ursache neu gestartet werden. Wenn STORE oder DEL bereits aktiv waren, müssen die Archivdateien auf Vollständigkeit geprüft werden. Im kritischsten Fall (DEL bereits gelaufen) ist eine vollständige Konsistenzprüfung Pflicht.

Warum ist CO_TRANS ein Sonderfall?

In SAP S/4HANA werden die Summentabellen COSS und COSP nicht mehr direkt geschrieben, sondern über CDS-Views aus dem Universal Journal (ACDOCA) abgeleitet. Ein unterbrochener WRITE-Job für CO_TRANS kann diese CDS-Views in einen inkonsistenten Zustand bringen. Deshalb gilt: WRITE-Job für CO_TRANS grundsätzlich nicht unterbrechen. Details im SAP-Hinweis 2906925.

Wie konkret muss eine Eskalationskette für SARA-Abbrüche aussehen?

Pro kritischem Archivierungsobjekt sollten drei Eskalationsstufen mit Rollen und Reaktionszeiten definiert sein: Stufe 1 SAP-Basis-Bereitschaft (30 Min), Stufe 2 SAP-Archivierungs-Spezialist (2 h), Stufe 3 Modul-Verantwortlicher bei Datenintegritäts-Risiko. Diese Kette gehört in die Verfahrensdokumentation und wird allen Beteiligten kommuniziert.

Reichen automatische Job-Ketten für einen sicheren SAP-Archivbetrieb?

Automatische Ketten machen den Betrieb komfortabel, ersetzen aber nicht die Fehlerbehandlung. Ein professioneller SAP-Archivbetrieb braucht zusätzlich zentrales Monitoring, dokumentierte Restart-Verfahren und verfügbares Spezialwissen für die kritischen Archivierungsobjekte.

Wie unterstützt ein SAP Archive Managed Service beim SARA-Restart?

Im SAP Archive Managed Service sind Restart-Verfahren, Spezialwissen und Monitoring vertraglich gebündelt. Definierte Reaktionszeiten, dokumentierte Restart-Pfade pro Archivierungsobjekt, Konsistenzprüfungen, Beratung bei Sonderfällen wie CO_TRANS und laufende Pflege der Verfahrensdokumentation gehören zum Service.

Über entplexit

Die entplexit GmbH ist SAP Partner mit Schwerpunkt auf SAP-Archivierung, SAP Information Lifecycle Management (ILM) und SAP Archive Managed Service. Mit dem SAP Archive Managed Service übernehmen wir den vollständigen Archivbetrieb für mittelständische und große SAP-Anwender, On-Premise, in der Hyperscaler-Cloud und ergänzend zu RISE with SAP.

Kontakt: information@entplexit.com | +49 (0) 6196 97344 - 00 | www.entplexit.com

Wenn diese Themen für Sie aktuell sind: Sprechen Sie uns an — wir unterstützen Sie gerne.