Archivierung mit Hindernissen

Die Archivierung nicht mehr verwendeter Daten in jedem EDV-System ist durchaus sinnvoll, muss aber wohl durchdacht sein. Man gewinnt wertvollen Plattenplatz, entschlackt den Datenbestand und kann dadurch auch eine gewisse Performance-Optimierung erreichen. Jedoch sollte man sich zuvor hinreichend Gedanken darüber machen, in welcher Beziehung die Daten, die man gerade archiviert, zu Daten stehen, die noch im System verweilen.

Sonst kann es zu interessanten Auswirkungen kommen, die im Tagesgeschäft eines SAP-Basis Administrators auf den ersten Blick nur schwer mit der Archivierung in Zusammenhang gebracht werden können. Hierzu ein Fall, der mir im letzten Monat begegnet ist: Wir überwachen für einen Kunden nicht nur die Lebenszeichen seiner SAP-Landschaft, sondern kontrollieren auch den Erfolg der nächtlichen Jobketten. Hierfür werden wir im Falle eines Jobabbruchs durch eine SMS auf das Handy informiert. Eine solche Alarmierung erreichte mich neulich um kurz nach 22:00 Uhr. Ein Abbruch der Massenaktivität FPRV. Aufschaltung auf das System und ein schneller Blick in die ST22 zeigen zügig den Grund für den Abbruch des Jobs auf. Es handelte sich um einen Speicher-Engpass.

Laut unserer internen Dokumentation zum Umgang mit den Jobabbrüchen des Kunden, ist diese Aktivität uneingeschränkt restart-fähig. Frei nach dem Motto „Neustart tut gut“ versuchte ich also die simpelste Variante der Fehlerbehebung und startete den Job manuell erneut. Der simple Ansatz sollte mir leider keinen Erfolg bescheren, nach einer gewissen Laufzeit ist der Job erneut mit ähnlicher Fehlermeldung abgebrochen. 

Mir war spätestens jetzt klar, dass ich hier nicht so „einfach“ davon kommen werde. Glücklicherweise darf der Job im Notfall übersprungen werden und eine Detailanalyse wird auf den nächsten Tag verschoben. Nach Rücksprache mit dem Applikations-Support stellt sich heraus, dass die eigentliche Datenverarbeitung des FPRV-Jobs korrekt und vollständig abgelaufen ist. Der Fehler muss also danach stattfinden.

Also ein detaillierter Blick auf die Abbruchstelle und die umliegenden Aufrufe:

Verfolgen wir den Ablauf, kommen wir über den Report RFKK_MA_SCHEDULER (Für das Einplanen der Job’s verantwortlich) über den dort inkludierten RFKK_MA_SCHEDULER_F02 zu folgender Stelle:

Hier wird das Anwendungslog der Massenaktivität vorbereitet… und so kommen wir zur eigentlichen Abbruchstelle. Beim APPEND einer internen Tabelle kommt es zum Speicherüberlauf.

Offenbar führt die Aufbereitung und Ablage des Anwendungslogs zu einem Speicherüberlauf. Hier stellt sich – wie so häufig – die Frage, wie ein Job, der vorher reibungslos gelaufen ist, nun mit einem Speicherengpass abbricht. Ein Blick auf die Änderungshistorien der beteiligten Programme bringt keine Erkenntnisse. Keine Programmanpassungen in der letzten Zeit. Auch die Konfigurationen im Job-Scheduling Tool zeigt keine Auffälligkeiten. Wenn sich an den Programmen nichts geändert hat, müsste das Problem in einem veränderten Datenbestand liegen.

Nach Rücksprache mit dem Fachbereich, ob denn auf einmal mehr Daten zur Verarbeitung anstehen würden, stellt sich heraus, dass sich der aktuelle Datenbestand nicht verändert hat. Das befriedigt meine Neugierde wenig und ich muss die Analyse eigenständig in der Transaktion FPRV fortführen. Auf zu dem bösen Anwendungslog, das den Speicherüberlauf herbeiführt.

Hm, ~4,3 Millionen Logeinträge. Davon ~4,2 Millionen Warnungen. Dann darf einem SAP-System auch mal der Speicher ausgehen. Aber wie kommt es dazu und seit wann ist das denn so? Die Historie verrät: Einen Monat zuvor wir tatsächlich schon fast 2 Millionen Log-Einträge. 

Ein Schema ist zu erkennen, aber was will und das System sagen?

Die Warnungen lauten alle "Kein entsprechender DFKKOP-Beleg zu Beleg XXXXXXX vorhanden". Die Menge der Meldungen in Verbindung mit dem Stichwort „DFKKOP“ sowie dem Zeitraum führt mich zur eigentlichen Ursache - der Archivierung. Ich hatte einen Zusammenhang zunächst aus logischen Gründen ausgeschlossen, da eine Archivierung ja in der Regel dazu führt, dass im System weniger Daten zur Verarbeitung anstehen. Die Archivierung als Grund für den Speicherüberlauf zu sehen, klang für mich anfangs nicht plausibel.

Im Rahmen eines Archivierungsprojekts werden seit längerem historische Einträge der Tabelle DFKKOP archiviert. Die Tabelle DFKKOP beinhaltet sämtliche Belegköpfe. Die abbrechende Aktivität FPRV bearbeitet Datensätze in der Tabelle DFKKCOLL, welche eine Referenz auf einen Datensatz in der DFKKOP enthält. In der DFKKCOLL stehen die Belege, die für die Inkasso-Abgabe relevant sind. Fehlt die Referenz in der DFKKOP, wird der entsprechende Eintrag im Anwendungslog generiert. Klingt nach einer Dateninkonsistenz.

Um die Situation aufzulösen und nicht nur die Verarbeitung, sondern auch die Protokollierung der FPRV zu gewährleisten, muss sowohl eine taktische (kurzfristige), als auch eine strategische Lösung verfolgt werden. Als Übergangslösung wird die Erweiterung des Quotas für die Nutzung des Extended Memory umgesetzt. Die Reserve des verfügbaren Speichers im System ist glücklicherweise ausreichend groß und kann über Anpassung des Profilparameters ztta/roll_extension genutzt werden. Mit dem Report RSMEMORY zur Laufzeit oder mittels Profilparameter permanent. Das verschafft Luft, um die Archivierung der DFKKCOLL in Betrieb zu nehmen.

Autor: Fabian HürtenWebsite: /index.php/prof/profile-fh