Читать книгу: «Praxishandbuch SAP-Basis – Troubleshooting in der Systemadministration»
Manfred Sprenger
Praxishandbuch SAP®-Basis – Troubleshooting in der Systemadministration
Manfred Sprenger
Praxishandbuch SAP®-Basis – Troubleshooting in der Systemadministration
ISBN:978-3-96012-948-6 (E-Book)
Lektorat:Anja Achilles
Korrektorat: Die Korrekturstube
Coverdesign: Philip Esch
Coverfoto: © choness | # 485370481 – istockphoto.com
Satz & Layout: Johann-Christian Hanke
1. Auflage 2020
© Espresso Tutorials GmbH, Gleichen 2020
URL: www.espresso-tutorials.de
Das vorliegende Werk ist in allen seinen Teilen urheberrechtlich geschützt. Alle Rechte sind vorbehalten, insbesondere das Recht der Übersetzung, des Vortrags, der Reproduktion und der Vervielfältigung. Espresso Tutorials GmbH, Bahnhofstr. 2, 37130 Gleichen, Deutschland.
Ungeachtet der Sorgfalt, die auf die Erstellung von Text und Abbildungen verwendet wurde, können weder der Verlag noch die Autoren oder Herausgeber für mögliche Fehler und deren Folgen eine juristische Verantwortung oder Haftung übernehmen.
Feedback: Wir freuen uns über Fragen und Anmerkungen jeglicher Art. Bitte senden Sie diese an: info@espresso-tutorials.com.
Inhaltsverzeichnis
Cover
Titelseite
Copyright/Impressum
Vorwort
Zielgruppe
Über dieses Buch
1 System langsam bzw. ohne Reaktion
1.1 Dialogworkprozesse und Dialogschritte
1.2 Analyse mit dem Workprozess-Monitor
1.3 Verwaltung von Workprozessen
1.4 Alternativen zur Transaktion SM50
2 Abbruch oder verzögerte Ausführung von Jobs
2.1 Konzept der Hintergrundverarbeitung
2.2 Job-Monitor
2.3 Beispiele für Probleme in der Jobausführung bis hin zum Abbruch
2.4 Hilfsprogramme für die Jobverwaltung
2.5 Reorganisation von Job-Logs und Vermeidung trivialer Job-Logs
3 Verbuchungsabbrüche
3.1 Anforderungen an den Verbucher
3.2 Funktionsweise des Verbuchers
3.3 Verbuchungsworkprozesse
3.4 Verbuchungsabbrüche
3.5 Verbuchungsmonitor
3.6 Verbucheradministration
4 Sperrverwaltung
4.1 Das SAP-Sperrkonzept
4.2 Monitoring und Verwaltung von Sperren
4.3 Überlaufen der Sperrtabelle
4.4 Transaktion SMENQ
5 Probleme mit Nummernkreisen
5.1 Nummernkreisobjekte und Nummernkreisintervalle
5.2 Pufferung von Nummernkreisen
5.3 Monitoring von Nummernkreisintervallen
6 Programmabbrüche
6.1 Laufzeitfehler
6.2 Laufzeitfehler auswerten
7 Druckprobleme
7.1 Spool-Auftrag und Ausgabeauftrag
7.2 Aufbereitungsserver und Druckmethoden
7.3 Druckereigenschaften und Koppelarten
7.4 Monitoring und Steuerung von Spool- und Ausgabeaufträgen
7.5 Beispiele für Fehleranalyse
8 Berechtigungsprobleme
8.1 Grundlagen SAP-Berechtigungskonzept
8.2 Technische Durchführung einer Berechtigungsprüfung
8.3 Analyse von Berechtigungsfehlern
8.4 Berechtigungstrace
8.5 Berechtigungen: Typische Fehlerquellen
9 Fehleranalyse mithilfe des Debuggers
9.1 Debugger starten und stoppen
9.2 Debugger »exklusiv« und »nicht exklusiv«
9.3 Steuerung des Debuggers
9.4 Variableninhalte anzeigen und ändern
9.5 ABAP und Dynpro Stack
9.6 Debuggen für anderen Benutzer
9.7 Checkpoint-Gruppen
10 Kommunikation über RFC- und HTTP-Schnittstellen
10.1 RFC-Schnittstelle
10.2 RFC-Varianten
10.3 Internet Communication Manager
11 Wichtige Log- und Tracedateien
11.1 Systemlog
11.2 Anwendungslog
11.3 Workprozess-Traces
12 Wie findet man Tabellennamen?
12.1 Technische Info über die F1-Hilfe
12.2 Suche nach SELECT im Quelltext
12.3 Programmtrace mit SAT
12.4 Trace mit Transaktion ST12
12.5 Informationen zu Customizing-Tabellen
Fazit
Anhang
A Der Autor
B Disclaimer
Weitere Bücher von Espresso Tutorials
Mehr Wert für Ihr SAP®
Willkommen bei Espresso Tutorials!
Unser Ziel ist es, SAP-Wissen wie einen Espresso zu servieren: Auf das Wesentliche verdichtete Informationen anstelle langatmiger Kompendien – für ein effektives Lernen an konkreten Fallbeispielen. Viele unserer Bücher enthalten zusätzlich Videos, mit denen Sie Schritt für Schritt die vermittelten Inhalte nachvollziehen können. Besuchen Sie unseren YouTube-Kanal mit einer umfangreichen Auswahl frei zugänglicher Videos:
https://www.youtube.com/user/EspressoTutorials.
Kennen Sie schon unser Forum? Hier erhalten Sie stets aktuelle Informationen zu Entwicklungen der SAP-Software, Hilfe zu Ihren Fragen und die Gelegenheit, mit anderen Anwendern zu diskutieren:
http://www.fico-forum.de.
Eine Auswahl weiterer Bücher von Espresso Tutorials:
Julian Harfmann, Sabrina Heim, Andreas Dietrich: Compliant Identity Management mit SAP® IdM und GRC AC
Andreas Prieß:SAP®-Berechtigungen für Anwender und Einsteiger
Martin Metz & Sebastian Mayer:Schnelleinstieg in SAP® GRC Access Control
Bianca Folkerts:Praxishandbuch für die Risikoanalyse mit SAP® GRC Access Control
Andreas Schuster:Praxishandbuch SAP® HANA – Administration
Günter Dusch:Datenmigration mit SAP® LSMW: Einfach, schnell und kompakt
Vorwort
In den zurückliegenden Jahren gehörte es zu einer meiner häufigsten Aufgaben, in SAP-Systemen auftretende Probleme zu analysieren und nach Möglichkeit zu beseitigen. Dabei stellte sich immer wieder heraus, dass Fehler selten nur ein einziges Mal auftreten und die einmal bei der Analyse und Lösung gewonnenen Kenntnisse sehr hilfreich sind, wenn sich der Fehler wiederholt. So konnte ich im Laufe der Zeit ein umfassendes Wissen aufbauen, wie man ein SAP-Troubleshooting, also eine systematische Analyse von Fehlern, am zweckmäßigsten durchführt. Seitens meiner Kunden wurde ich immer häufiger gebeten, dieses Wissen an die Mitarbeiter weiterzugeben, die im Unternehmen mit der Fehleranalyse und -behebung betraut sind. So ist eine Reihe von Workshops zum Thema »SAP-Troubleshooting« entstanden, die ich in den letzten Jahren oft durchgeführt habe. Dieses Buch enthält quasi eine Auswahl, ein »Best-of« derjenigen Themen, die durchgängig bei allen Unternehmen relevant waren. Damit wird natürlich nur ein Bruchteil dessen abgedeckt, was in der täglichen SAP-Praxis an Problemen auftreten kann, doch sollten die im Verlauf des Buches vorgestellten Werkzeuge Ihnen dabei helfen, auch bei hier nicht angesprochenen Schwierigkeiten Licht ins Dunkel zu bringen.
Zielgruppe
Dieser Praxisleitfaden wendet sich zunächst einmal an alle Mitarbeiter des Supportteams, die mit dem SAP-Troubleshooting betraut sind. Aber auch Entwickler und technisch interessierte Key-User sollten genügend Hilfestellungen finden, um selbst in die Fehleranalyse einzusteigen. Mit den so gewonnenen Informationen sind Sie dann hoffentlich in der Lage, anhand von SAP-Hinweisen eigenständig Lösungen zu finden.
Über dieses Buch
In diesem Buch werden typische, in der täglichen SAP-Praxis auftretende Problemsituationen beschrieben. Zu Beginn eines jeden Kapitels erläutere ich zunächst die jeweils beteiligten technischen Komponenten. Dabei geht es mir nicht darum, jedes Detail und jede mögliche Variante einer Komponente zu schildern, schließlich liefert die SAP mit ihrer Onlinedokumentation praktisch zu allen Themen ausführliche Informationen. Ich beschränke mich jeweils auf die Vermittlung des aus meiner Sicht erforderlichen Wissens, um Fehlermeldungen zu verstehen und die für eine weitere Analyse zur Verfügung stehenden Werkzeuge einsetzen zu können. Die SAP-Basis-Profis unter den Lesern mögen mir die eine oder andere Vereinfachung der geschilderten Sachverhalte nachsehen.
Das für mich wichtigste Werkzeug, der ABAP-Debugger, wird mit der für die meisten Einsatzfälle notwendigen Tiefe in Kapitel 9 beschrieben. Der Debugger kommt eigentlich immer dann zum Einsatz, wenn es darum geht, ein Problem zu reproduzieren, um dabei detailliert den Ablauf einer Anwendung zu analysieren. Ist das Debugging aus technischen Gründen nicht möglich, weil z.B. die Berechtigungen dafür insbesondere in dem produktiven SAP-System nicht vorliegen oder das Problem nicht noch einmal erzeugt werden kann, bleibt oft nur noch die Auswertung von Log- und Tracedateien. Kapitel 11 zeigt Ihnen, welche Dateien hier helfen können und wie sie zu analysieren sind. Ergänzend zu den Log- und Tracedateien stehen u.U. auch ABAP-Dumps zur Verfügung, die Informationen zu Programmabbrüchen beinhalten. In Kapitel 6 erfahren Sie, wie Sie mithilfe der Transaktion ST22 die in den Dumps protokollierten Laufzeitfehler untersuchen können.
Immer wieder gilt es, zu klären, in welcher Tabelle eigentlich welche Daten abgelegt werden. Nur wer die Tabellennamen kennt, kann mit Werkzeugen wie den Transaktionen SE16 oder SM30 überprüfen, ob die erforderlichen Daten tatsächlich vorhanden sind. Kapitel 12 zeigt Ihnen, welche Tools zur Verfügung stehen, um Tabellennamen zu ermitteln.
Während die bisher genannten Kapitel eher universell Hilfestellungen für jedwede Art von Fehlern geben, befassen sich die im Folgenden aufgeführten Abschnitte mit speziellen Problemen:
Gleich das erste Kapitel habe ich den immer mal auftretenden Performanceproblemen gewidmet. Geklärt werden soll insbesondere die Frage, mit welchen Tools nachvollzogen werden kann, ob es sich dabei lediglich um den subjektiven Eindruck einzelner SAP-Anwender handelt oder ob die Probleme objektiv nachvollziehbar sind.
Kapitel 2 beschäftigt sich mit der SAP-Hintergrundverarbeitung und beschreibt, welche Ursachen für Jobabbrüche, Jobausfälle oder verzögerte Ausführungen verantwortlich sind.
In Kapitel 3 soll ein Verständnis dafür geweckt werden, warum das Monitoring des SAP-Verbuchers wichtig ist.
Die SAP-Sperrverwaltung ist Thema des Kapitels 4, während die eher selten auftretenden Probleme mit der Nummernkreisdefinition in Kapitel 5 geschildert werden.
Sind Sie an der Lösung von Problemen im Zusammenhang mit dem »Drucken« interessiert, sollten Sie Kapitel 7 konsultieren.
Eine Vielzahl der Meldungen, die ein Supportteam zu bearbeiten hat, betrifft das Thema »Berechtigungen«. Kapitel 8 zeigt Ihnen, wie Sie fehlende Berechtigungen ermitteln können, aber auch wie man zu viel vergebene Berechtigungen finden kann.
Da jedes SAP-System für gewöhnlich eine Vielzahl von Schnittstellen zu weiteren SAP-Systemen und auch Nicht-SAP-Systemen besitzt, ist es sicherlich hilfreich, sich mit Kapitel 10 zu befassen. Hier erfahren Sie, wie Sie Fehler im Zusammenhang mit der Kommunikation über RFC oder den Internet Communication Manager analysieren sollten.
In den Text sind Kästen eingefügt, um wichtige Informationen besonders hervorzuheben. Jeder Kasten ist zusätzlich mit einem Piktogramm versehen, das diesen genauer klassifiziert:
Hinweis
Hinweise bieten praktische Tipps zum Umgang mit dem jeweiligen Thema.
Beispiel
Beispiele dienen dazu, ein Thema besser zu illustrieren.
Achtung
Warnungen weisen auf mögliche Fehlerquellen oder Stolpersteine im Zusammenhang mit einem Thema hin.
Die Form der Anrede
Um den Lesefluss nicht zu beeinträchtigen, verwenden wir im vorliegenden Buch bei personenbezogenen Substantiven und Pronomen zwar nur die gewohnte männliche Sprachform, meinen aber gleichermaßen die weibliche.
Hinweis zum Urheberrecht
Zum Abschluss des Vorwortes noch ein Hinweis zum Urheberrecht: Sämtliche in diesem Buch abgedruckten Screenshots unterliegen dem Copyright der SAP SE sowie Adobe. Alle Rechte an den Screenshots hält die SAP SE. Der Einfachheit halber haben wir im Rest des Buches darauf verzichtet, dies unter jedem Screenshot gesondert auszuweisen.
1 System langsam bzw. ohne Reaktion
Immer wieder kommt es vor, dass sich Anwender im Dialogbetrieb über lange Antwortzeiten beschweren oder gar Meldungen einreichen, dass systemseitig gar keine Reaktion mehr erfolgt. Im Folgenden sollen Werkzeuge vorgestellt werden, mit deren Hilfe Sie u.a. prüfen können, ob nur einzelne Benutzer oder alle Anwender vom Problem betroffen sind.
Wir wollen uns in diesem Kapitel auf die für Anwender besonders wichtige Dialogverarbeitung konzentrieren; Informationen zu Problemen mit der Hintergrundverarbeitung finden Sie in Kapitel 2, zu Verbuchungsproblemen in Kapitel 3.
1.1 Dialogworkprozesse und Dialogschritte
Eine Dialoganwendung (SAP-Transaktion) besteht prinzipiell aus einer Folge von Masken (Dynpros), die für die Bearbeitung einer bestimmten Aufgabe durchlaufen werden müssen. Gestartet wird eine Dialoganwendung im Normalfall über einen Transaktionscode. Mit dem Start wird das erste der Transaktion zugeordnete Dynpro geöffnet. Abhängig von den Eingaben des Anwenders und der Ablauflogik des Dynpros wird anschließend das Folgedynpro geladen. Eine mögliche Dynprofolge zeigt Abbildung 1.1.
Jedem Dynpro sind zwei Verarbeitungsblöcke zugeordnet:
1. Process before Output, PBO wird im Applikationsserver ausgeführt, bevor das Dynpro zur Anzeige z.B. an die SAP GUI gesendet wird, und
2. Process after Input, PAI wird verarbeitet, wenn der Anwender die Eingabe von Daten durch Auslösen der gewünschten Folgeaktion abschließt.
Abbildung 1.1: Dynprofolge und Dialogschritt
Ein Dialogschritt umfasst sowohl den PAI-Block des aktuell bearbeiteten Dynpros als auch den PBO-Block des Folgedynpros. Für die Ausführung genau eines solchen Dialogschritts wird dem Anwender ein Dialogworkprozess zugeordnet. Ist der Dialogschritt beendet, gibt der Anwender den Workprozess wieder frei, und dieser kann von einem anderen Anwender für die Ausführung eines Dialogschritts eingesetzt werden. Prinzipiell spielt es dabei keine Rolle, wie lange ein Dialogschritt dauert. Wenn ein Anwender z.B. eine umfangreiche Liste erstellt, kann es durchaus vorkommen, dass die Bearbeitung des entsprechenden Dialogschritts mehrere Minuten (wenn nicht sogar Stunden) in Anspruch nimmt. Entsprechend lange ist dann der zugeordnete Dialogworkprozess für andere Anwender blockiert.
Da Workprozesse mitunter erhebliche Systemressourcen, insbesondere Hauptspeicher, binden können, steht nicht jedem angemeldeten Benutzer ein eigener Dialogworkprozess zur Bearbeitung zur Verfügung. Vielmehr verteilt der Dispatcher einer SAP-Instanz die zu verarbeitenden Dialogschritte nacheinander auf die vorhandenen Dialogworkprozesse.
Verhältnis von Anwender zu Dialogworkprozess
Typisch ist ein Verhältnis zwischen Anzahl angemeldeter Anwender und verfügbarer Dialogworkprozesse von etwa 10:1. Geht man z.B. davon aus, dass ein Anwender für die Eingabe der Daten in ein Dynpro zehn Sekunden benötigt, der Dialogschritt selbst etwa eine Sekunde läuft, kann man also im Mittel annehmen, dass, sofern nicht alle Anfragen gleichzeitig erfolgen, immer ein Dialogworkprozess zur Verfügung steht.
Probleme entstehen eigentlich immer dann, wenn im Dialogbetrieb Anwendungen gestartet werden, deren Dialogschritte weit über das übliche Maß hinaus Zeit und damit Dialogworkprozesse beanspruchen. Die Folge ist, dass die noch verfügbaren freien Workprozesse nicht mehr ausreichen, um die anstehenden Dialogschritte der übrigen Anwender mit angemessener Wartezeit zu bearbeiten. Im Extremfall kann das System, wenn gar keine freien Dialogprozesse mehr vorhanden sind, temporär zum Stillstand kommen.
In den folgenden Abschnitten wollen wir die Werkzeuge näher betrachten, die eine Überwachung der Workprozesse ermöglichen, um das Beschriebene zu verhindern.
1.2 Analyse mit dem Workprozess-Monitor
Eine Übersicht über die Workprozesse einer Instanz liefert die Transaktion SM50, während SM66 die Workprozesse aller Instanzen eines SAP-Systems zeigt. Wir beschränken uns in diesem Abschnitt auf die Transaktion SM50, weil diese umfangreichere Informationen und Verwaltungsfunktionen anbietet als SM66 (siehe Abbildung 1.2).
Abbildung 1.2: Workprozess – Übersicht
Es werden u.a. folgende Informationen ausgegeben:
Fortlaufende Nummer des Workprozesses (Nr): Die Nummer kann verwendet werden, um die für den Workprozess relevanten Tracedateien zu ermitteln (Details siehe Abschnitt 11.3)
Workprozess-Typ:
DIA = Dialogworkprozess
BTC = Batchworkprozess (siehe Abschnitt 2.1)
UPD/UPD2 = Verbuchungsworkprozess (siehe Abschnitt 3.3)
SPO = Spoolworkprozess (siehe Abschnitt 7.1)
Workprozess-Status (WP-Status) (siehe Tabelle 1.1)
Zusatzinformation zum Status »hält« (Info Hält)
Aktuelle Bearbeitungsdauer (B.-Dauer)
Programm, welches gerade vom WP ausgeführt wird
Benutzer-ID, dessen Auftrag ausgeführt wird
Aktuell im Workprozess ausgeführte Aktion
Die wohl wichtigste Angabe ist diejenige des »Status«. Tabelle 1.1 zeigt Ihnen mögliche Ausprägungen.
Tabelle 1.1: Die häufigsten Workprozess-Status
Es sollte schnell klar sein, dass die Dialogantwortzeiten des Systems ungünstig ausfallen können, wenn, wie in Abbildung 1.2 gezeigt, nur wenige Dialogprozesse im Status »wartet« zur Verfügung stehen und für die laufenden Prozesse eine Bearbeitungszeit von mehreren Sekunden angezeigt wird. Lediglich wenn ein Dialogworkprozess mit Status »wartet« vorhanden ist, kann ein Dialogschritt ohne Wartezeit vom Anwender bearbeitet werden. Andernfalls beginnt die Bearbeitung des Schritts erst mit dem Freiwerden eines Dialogworkprozesses.
Die Transaktion SM50 gibt Ihnen Auskunft über die Auslastung der Workprozesse aktuell und in den zurückliegenden 15 Minuten (siehe Abbildung 1.3).
Abbildung 1.3: Auslastung Workprozesse
Angezeigt werden verfügbare und freie Workprozesse () sowie die durchschnittliche Auslastung während der letzten Minute, der letzten fünf und der letzten 15 Minuten ().
Besonders kritisch ist es, wenn mehrere Dialogworkprozesse den Status »hält« für eine längere Zeit besitzen. Sie bleiben in diesem Fall über das Ende des Dialogschritts hinaus so lange reserviert, bis der Grund für diesen Status beseitigt ist. In dem in Abbildung 1.2 dargestellten Beispiel sind immerhin schon fast die Hälfte der Prozesse reserviert.
Die Spalte Info Hält gibt Ihnen Hinweise auf den Auslöser für den Status »hält«. Tabelle 1.2 führt hierzu einige Beispiele auf:
Tabelle 1.2: Beispiele für typische Auslöser in der Spalte »Info Hält«
Nachfolgend wollen wir uns für zwei der hier gezeigten Auslöser genauer ansehen, wie Sie darauf reagieren können.
1.2.1 Workprozess im Status »hält« mit Grund »RFC-Antwort«
Bekommt ein Workprozess den Status »hält« aufgrund einer »RFC-Antwort« zugewiesen, können Sie wie folgt ermitteln, welcher RFC-Aufruf über welche verwendete RFC-Destination den Status ausgelöst hat (siehe Abbildung 1.4).
Abbildung 1.4: Status »hält« mit Grund »RFC-Antwort«
Per Doppelklick auf einen Workprozess in der Übersicht (siehe Abbildung 1.2) erhalten Sie die zugehörigen Detailinformationen. Unter der Rubrik Wartegrund finden Sie im Feld Warteinfo () die sogenannte Conversation ID des RFC-Aufrufs. Starten Sie nun die Transaktion SM5A und geben Sie dort die Conversion ID in das betreffende Feld ein (). Im nachfolgenden Bild sehen Sie dann u.a., welche RFC-Destination für den Aufruf genutzt wurde und auf welcher Instanz (Server ) der gerufene Baustein ausgeführt wird. Starten Sie auf dieser Instanz nun die Transaktion SM50. Sie gibt Ihnen u.U. Hinweise darauf, ob die Instanz möglicherweise stark belastet ist und der RFC-Aufruf deshalb zu langen Antwortzeiten führt.
SAP-Hinweis 934109
SAP-Hinweis 934109 enthält detaillierte Informationen zu den Ursachen des Status »hält RFC« und zeichnet Lösungswege auf, wie Sie das Setzen des Status vermeiden.
1.2.2 Workprozess im Status »hält« mit Grund »PRIV-Modus«
Ein Workprozess wird mit dem Grund »PRIV« in den Status »hält« versetzt, wenn für die Ablage des Benutzerkontextes (Variableninhalte der gestarteten Anwendungen, Pufferung von Bildschirmlisten etc.) kein Extended Memory mehr verfügbar ist. Der betroffene Anwender wird auf diese Situation durch die Meldung »Speicher wird knapp. Vor Pausen Transaktion beenden!« hingewiesen.
Wir müssen zwei Ursachen für den Engpass an Extended Memory unterscheiden:
1. Für eine Dialoganwendung kann die maximal erlaubte Quote an Extended Memory erreicht sein.
2. Das für die gesamte Instanz zur Verfügung stehende Extended Memory ist ausgeschöpft.
Der zweite Fall ist besonders kritisch, denn jetzt werden Workprozesse auf den Status »hält« gesetzt, selbst wenn die im Prozess laufenden Anwendungen nur wenig Speicher verbrauchen. In der Folge befinden sich bereits nach kurzer Zeit alle Dialogworkprozesse im Status »hält«; einzig die Anwender, die einen Prozess reserviert haben, können noch Aktionen ausführen.
Die Transaktion ST02 hilft Ihnen dabei, einen solch globalen Engpass an »Extended Memory« zu erkennen (), mithilfe der Transaktion SM04 können Sie prüfen, welcher Anwender übermäßig viel Speicher benötigt () (siehe Abbildung 1.5).
Abbildung 1.5: Analyse des Speicherverbrauchs
Vermeidung »PRIV«
Bevor man sich entscheidet, das Extended Memory oder die für einen Anwender verfügbare Quote zu vergrößern, sollte geprüft werden, ob nicht sinnvolle Selektionskriterien beim Start der Anwendung oder ggf. eine Optimierung des Programmcodings dabei helfen können, eine häufige Workprozessreservierung zu vermeiden. Beachten Sie zusätzlich auch den SAP-Hinweis 2098461.
1.3 Verwaltung von Workprozessen
Bisweilen kann es notwendig sein, eine Anwendung vorzeitig zu stoppen, weil z.B. Selektionskriterien eingegeben wurden, die zu problematisch langen Laufzeiten führen können.
Für das Abbrechen stehen verschiedene Optionen zur Verfügung. Zunächst einmal kann der User, der die Anwendung gestartet hat, selbst versuchen, sie zu stoppen (siehe Abbildung 1.6). Zu diesem Zweck bietet die SAP GUI die Funktion Transaktion abbrechen (). Ist diese nicht erfolgreich oder läuft die Anwendung z.B. im Hintergrund, können Sie in der Transaktion SM50 Programm • abbrechen () wählen. Bei beiden Verfahren wird der Workprozess angewiesen, die laufende Anwendung zu beenden, der Workprozess selbst wird betriebssystemseitig aber nicht durchgestartet, sondern kann sofort die nächste Anfrage abarbeiten. In jedem Fall sollten Sie nach dem eingeleiteten Abbruch etwas Geduld haben. Wenn z.B. die Anwendung mitten in einer ändernden Datenbankoperation gestoppt wurde, kann das notwendige Rollback einige Zeit in Anspruch nehmen. Lässt sich die Anwendung über keinen der beschriebenen Wege beenden, sollten Sie den Workprozess durchstarten. Dazu wählen Sie Administration • Workprozess • abbrechen • ohne Core ().
Abbildung 1.6: Alternativen für den Abbruch einer Anwendung
Anwendungen in Dialogworkprozessen werden zudem automatisch gestoppt, wenn sie ein durch den Parameter rdisp/max_wprun_time vorgegebenes Zeitlimit überschritten haben. Beachten Sie, dass dieses Limit automatisch um ca. 60 Sekunden verlängert wird, wenn die Anwendung z.B. gerade ein SQL-Statement ausführt. Der Abbruch der Anwendung aufgrund einer Zeitüberschreitung führt zu einem Laufzeitfehler.
Bei aktuelleren SAP-Kernel kann das Limit in Abhängigkeit von Prioritäten differenziert werden. Es stehen folgende Parameter zur Verfügung:
rdisp/scheduler/prio_high/max_runtime
rdisp/scheduler/prio_normal/max_runtime
rdisp/scheduler/prio_low/max_runtime
Detaillierte Informationen zu den Parametern liefert die Transaktion RZ11.
Die Priorität einer im Workprozess zu bearbeitenden Anfrage kann wie in Tabelle 1.3 festgelegt sein:
| Priorität | Bedeutung |
|---|---|
| Hoch | Dialoganwendungen und systeminterne Vorgänge wie z.B. Puffersynchronisation, Batch-Scheduler |
| Normal | RFC-Aufrufe aus Dialoganwendungen |
| Niedrig | Ausführung von Job-Steps und RFC-Aufrufen aus Batch-Anwendungen |
Tabelle 1.3: Prioritäten für Workprozessaufträge
1.4 Alternativen zur Transaktion SM50
Die Transaktion SM50 kann selbst vom Systemadministrator nur dann genutzt werden, wenn mindestens ein Dialogworkprozess im Status »wartet« zur Verfügung steht. Was tun, wenn alle Prozesse blockiert sind?
Ein sehr rudimentäres Werkzeug für die Analyse und Verwaltung von Workprozessen bietet das Kommando dpmon, das auf Betriebssystemebene des Applikationsservers gestartet werden kann. Melden Sie sich dazu als SAP-Systemadministrator (<SID>adm) an. Wenn Sie in das Verzeichnis (DIR_PROFIL) wechseln, können Sie das Kommando z.B. wie folgt starten:
dpmon pf=TZ7_DVEBMGS00_saptz7
Für den Parameter pf muss der jeweilige Name des Instanzprofils angegeben werden.
Wählen Sie im Folgebild die Option m - menue. Daraufhin erhalten Sie eine Aufstellung über die zur Verfügung stehenden Kommandos. Das Kommando »l« zeigt Ihnen eine zur Transaktion SM50 analoge Auflistung der Workprozesse an. Diese bietet Funktionen z.B. zum Stoppen () eines Workprozesses (siehe Abbildung 1.7).
Abbildung 1.7: Workprozessübersicht mit »dpmon«
Komfortabler als dpmon ist sicherlich die SAP Management Console (SAP MMC). Sie kann z.B. mit der Portnummer »5<Instanz>13« per Browser geöffnet werden (sofern die Firewall-Einstellungen dies zulassen und der Browser Applets unterstützt).
Die Workprozessübersicht () steht Ihnen unter AS ABAP WP Table () zur Verfügung (siehe Abbildung 1.8).
Abbildung 1.8: Workprozess in SAP MMC
2 Abbruch oder verzögerte Ausführung von Jobs
Es gibt in jedem SAP-System eine Vielzahl wiederkehrender Aufgaben, die in regelmäßigen Abständen und zu bestimmten Zeiten auszuführen sind. Diese Aufgaben werden der SAP-Hintergrundverarbeitung übertragen. Diese bietet mit der zeitgesteuerten Ausführung zudem die Möglichkeit, lang laufende Anwendungen in Zeiten zu verlagern, in denen das System über ausreichende Ressourcen verfügt. Da bei der Hintergrundverarbeitung Fehler- oder Problemmeldungen nicht an Dialoganwender gesendet werden, ist ein Monitoring außerordentlich wichtig. In diesem Kapitel erläutere ich Ihnen zunächst die Funktionsweise der SAP-Hintergrundverarbeitung und zeige Ihnen anschließend, welche typischen Probleme auftreten können und wie man diese erkennt und beseitigt.
Die im Rahmen der SAP-Hintergrundverarbeitung ausgeführten Programme laufen in Hintergrundworkprozessen und nicht in Dialogworkprozessen. Daraus resultieren folgende Vorteile:
Für Hintergrundworkprozesse existiert, anders als für Dialogworkprozesse, keine Laufzeitbegrenzung, d.h. der Parameter rdisp/max_wprun ist irrelevant.
Hintergrundworkprozessen steht mehr Speicher zur Verfügung, d.h., es können darin größere Datenmengen verarbeitet werden.
Programme können zu lastarmen Zeiten gestartet werden.
Aber auch im Rahmen der Hintergrundverarbeitung können Probleme auftreten, wie etwa »Job wurde abgebrochen« oder »Job wird gar nicht oder stark verzögert gestartet«. Im Folgenden erhalten Sie zunächst nähere Informationen zur Funktionsweise der Hintergrundverarbeitung. Anschließend werden typische Fehlersituationen sowie die zur Fehleranalyse geeigneten Werkzeuge vorgestellt.
2.1 Konzept der Hintergrundverarbeitung
2.1.1 Job und Job-Step
Die SAP-Hintergrundverarbeitung führt Jobs aus, die aus einem oder mehreren Job-Steps bestehen. Die Job-Steps werden gemäß der im Job festgelegten Reihenfolge ausgeführt. Im Normalfall erfolgt die Verarbeitung synchron, d.h., erst wenn ein Step beendet wurde, wird der nächste gestartet. Bei Abbruch eines Steps bricht der gesamte Job ab.
Datenbankänderungen bei Jobabbrüchen
Beachten Sie, dass Änderungen, die von einem Step durchgeführt und mit COMMIT bestätigt wurden, durch den Abbruch nicht zurückgesetzt werden.
Ein Job-Step kann durch ein ausführbares ABAP-Programm, ein externes Kommando oder durch ein externes Programm realisiert werden. Daher erfahren Sie zunächst, was hinter diesen Begriffen steht, um dann zur Definition eines Jobs überzugehen.
Ausführbares ABAP-Programm
Hierbei handelt es sich um ein ABAP-Programm vom Typ 1 (siehe Abbildung 2.1).
Abbildung 2.1: Ausführbares Programm
Ungeeignete Programmtypen für Job-Steps
Dialogtransaktionen, d.h. Anwendungen, die auf ABAP-Programmen vom Typ M = Modulpool basieren, können – ebenso wenig wie Funktionsbausteine – nicht zur Definition eines Job-Steps verwendet werden.
Verfügt das für einen Job-Step infrage kommende ABAP-Programm über ein Selektionsdynpro, muss zumindest eine sogenannte Variante vorhanden sein. Diese beinhaltet die für den Startzeitpunkt des Job-Steps relevanten Werte für die Selektionsparameter des Programms. Bei der Definition des Job-Steps sind in diesem Fall der Name des Programms sowie der Variante anzugeben.
Externes Programm
Ein externes Programm ist eine ausführbare Datei auf Hostsystemen, auf die das SAP-System zugreifen kann. Zu diesen Systemen gehören insbesondere die Applikationsserver des SAP-Systems. Externe Programme werden, wenn sie Bestandteile eines Jobs sind, normalerweise vom Betriebssystembenutzer <SAP-Systemname>adm, also z.B. se1adm, ausgeführt. Beachten Sie, dass externe Programme betriebssystemabhängig benannt und parametrisiert sind. Um beispielsweise das Inhaltsverzeichnis eines Dateipfades abzurufen, müssen Sie bei Windows das Kommando dir, bei Linux das Kommando ls aufrufen.
Externes Kommando
Mit einem externen Kommando bietet die SAP die Möglichkeit, unter einem einheitlichen Kommandonamen für verschiedene Betriebssysteme das passende externe Programm zuzuordnen. Die Definition solcher externen Kommandos erfolgt mithilfe der Transaktion SM69. Abbildung 2.2 zeigt Beispiele für externe Kommandos.
Abbildung 2.2: Externe Kommandos
Definition von Jobs
Die Definition von Jobs erfolgt bevorzugt mithilfe der Transaktion SM36. In Abbildung 2.3 sehen Sie ein Beispiel für einen Job mit mehreren Steps.
Abbildung 2.3: Beispiel Job-Steps
Die Spalte Nr. zeigt an, in welcher Reihenfolge die Steps ausgeführt werden sollen. Zusätzlich finden Sie in der Abbildung folgende Informationen:
Name des ABAP-Programms bzw. des externen Kommandos
Programmtyp (ABAP oder externes Kommando)
Name der Variante (falls zur Ausführung erforderlich)
Benutzer, unter dessen Kennung der Step gestartet wird
Zu verwendende Anmeldesprache für die Ausführung
Einem auszuführenden Job muss eine Startbedingung zugeordnet werden (). Der wiederkehrende Start eines Jobs ist durch die Angabe eines Periodenwertes () möglich (siehe Abbildung 2.4).
Abbildung 2.4: Startbedingung für einen Job
2.1.2 Batch-Scheduler
Der Batch-Scheduler ist ein in regelmäßigen Abständen in einem SAP-System ablaufendes Systemprogramm, das für jeden zur Ausführung eingeplanten Job überprüft, ob die Startbedingung erfüllt ist. Wenn das Ergebnis positiv ausfällt, erhalten diese Jobs den Status »bereit«. Der zeitliche Abstand zwischen zwei Starts des Schedulers wird durch den Parameter rdisp/btctime festgelegt; der Standardwert beträgt 60 Sekunden.
Der Scheduler verteilt die zur Ausführung fertigen Jobs auf die zur Verfügung stehenden Hintergrundprozesse. Ein Hintergrundprozess führt einen Job immer in Gänze aus (sofern er nicht abbricht), d.h., der Prozess steht während einer Jobausführung nicht für andere Aufgaben zur Verfügung. In der Konsequenz können nicht mehr Jobs gleichzeitig ablaufen als Hintergrundprozesse vorhanden sind. Die in einer Instanz nutzbaren Hintergrundprozesse werden durch den Parameter rdisp/wp_no_btc festgelegt.
Betriebsarten
Mithilfe der Definition sogenannter Betriebsarten ist es möglich, die Anzahl der zur Verfügung stehenden Hintergrundprozesse flexibel zu gestalten (siehe Transaktion RZ04/SM63). So können z.B. für den Nachtbetrieb mehr Hintergrundprozesse als für den Tagesbetrieb bereitgestellt werden.
Haben zur Ausführungszeit des Schedulers mehr Jobs den Status »bereit« als Hintergrundprozesse vorhanden sind, können nicht alle Jobs wie geplant gestartet werden. In diesem Fall bietet sich eine Priorisierung dieser Jobs mithilfe der Jobklasse an, die einem Job bei der Definition zugewiesen wird () (siehe Abbildung 2.5). Bei gleicher Jobklasse werden zudem Jobs für die Startfreigabe bevorzugt, für die unter Ausführungsziel eine Instanz mit Hintergrundprozessen eingetragen ist (). Voraussetzung ist natürlich, dass genau die angegebene Instanz noch über freie Hintergrundprozesse verfügt.
Abbildung 2.5: Jobklasse (Priorität)
Für die Vergabe der Jobklasse gelten die in Tabelle 2.1 aufgelisteten Empfehlungen:
| Jobklasse | Empfehlung |
|---|---|
| A | Für den Betrieb unbedingt notwendige und zeitkritische Jobs. Beispiel: Job RDDIMPD für die Steuerung der Importe von Transportaufträgen. |
| B | Regelmäßig, mit kürzeren Wiederholungsperioden (z.B. stündlich) laufende Jobs, die nur mit geringer Verzögerung gestartet werden sollen. |
| C | Jobs, die keine erhöhte Priorität erfordern. Jobklasse »C« ist die Standardklasse. |
Tabelle 2.1: Jobklassen
Reservierung von Hintergrundprozessen für Klasse »A«
Bei der Definition von Betriebsarten (Transaktion RZ04) haben Sie die Möglichkeit, Hintergrundprozesse speziell für Jobs der Klasse »A« zu reservieren (siehe in Abbildung 2.6). Beachten Sie aber unbedingt: Wird in einem auf diese Weise reservierten Prozess ein Job der Klasse »A« gestartet und ist gleichzeitig ein weiterer Hintergrundprozess verfügbar, wird dieser sofort für einen anderen Klasse-A-Job reserviert, damit der nächste anstehende Job dieser Klasse nach Möglichkeit sofort starten kann.
Abbildung 2.6: Reservierung von Hintergrundprozessen für Klasse »A«
Schlechtes Beispiel für Klasse-A-Reservierung
Ihnen stehen vier Hintergrundprozesse zur Verfügung, von denen zwei für die Klasse »A« reserviert werden. Wenn nun zeitgleich zwei Klasse-A-Jobs laufen, ist eine Ausführung von Jobs der Klassen »B« und »C« nicht mehr möglich.
2.2 Job-Monitor
Eine Übersicht über Jobs und deren aktuellen Status liefert die Transaktion SM37, auch Job-Monitor genannt. Im Startbild der Transaktion (siehe Abbildung 2.7) können Sie die Ergebnisliste nach Jobname () und Kennung des Benutzers (), der den Job eingeplant hat, einschränken. Zusätzlich können Sie eine Eingrenzung nach der Jobstartbedingung () und nach dem Jobstatus () vornehmen.
Abbildung 2.7: Einfache Jobauswahl
Zusätzliche Selektionsbedingungen können Sie mit der Funktion 
einblenden. Alternativ starten Sie die erweiterte Jobauswahl mit der Transaktion SM37C.
Jobauswahl
Auf einem SAP-System laufen im Normalfall mehrere Tausend Jobs pro Tag. Nutzen Sie daher bei der Jobauswahl die Möglichkeiten der Einschränkung, insbesondere über den Jobstatus und -namen. Andernfalls dauert der Aufbau der Trefferliste sehr lang, und die Liste wird schnell unübersichtlich.
Die Jobübersicht zeigt alle Jobs gemäß den gewählten Selektionskriterien (siehe Abbildung 2.8).
Abbildung 2.8: Jobübersicht
Folgende Informationen werden per Default angezeigt:
Name des Jobs
Vorhandensein einer Spool-Liste (ein Icon in dieser Spalte deutet darauf hin, dass eine Liste (Spool-Auftrag) erzeugt worden ist. Mit Doppelklick auf das Icon rufen Sie die Spool-Liste auf)
Benutzerkennung des Job-Erstellers
Status des Jobs (Details siehe Tabelle 2.2)
Startzeitpunkt des Jobs (tatsächlicher Start)
Laufzeit des Jobs in Sekunden
Verzögerung des tatsächlichen Jobstarts relativ zum geplanten Starttermin. Da der Scheduler im Normalfall nur alle 60 Sekunden Jobs startet, sind Verzögerungen von bis zu 60 Sekunden absolut üblich.
Es fällt auf, dass der geplante Startzeitpunkt in der Liste nicht angezeigt wird. Sie können jedoch die dargestellten Informationen durch Veränderung der Anzeigevariante beeinflussen (siehe Abbildung 2.9).
Abbildung 2.9: Anzeigevariante für Jobübersicht
Beachten Sie, dass die zur Verfügung stehenden Felder vom SAP-Release abhängig sind. Das Feld Verzögerungsgrund fehlt z.B. in klassischen ERP-Systemen.
Das für das Monitoring wichtigste Feld stellt der Status dar. Mögliche Statuswerte und deren Bedeutung finden Sie in Tabelle 2.2.
Tabelle 2.2: Jobstatus
Für Jobs mit dem Status »abgebrochen« ist es wichtig, nähere Informationen zur Abbruchursache zu erhalten. Diese können Sie durch die Analyse des Job-Logs (Protokoll) ermitteln, dessen Aufruf Abbildung 2.10 zeigt. Wählen Sie dazu einen Job () und klicken Sie die Funktion Job-Log () an.
Abbildung 2.10: Anzeige Job-Log
In einigen Fällen liefert das erscheinende Job-Log bereits Hinweise zur weiteren Fehleranalyse, im konkreten Fall etwa »(siehe ST22)« im Nachrichtentext ().
Können Sie dem Job-Log keine ausreichenden Informationen entnehmen, sollten Sie wie folgt vorgehen:
Suchen Sie mithilfe der Transaktion ST22 nach Laufzeitfehlern, die zum Zeitpunkt der Jobausführung aufgetreten sind. Details zur Analyse von Laufzeitfehlern finden Sie in Abschnitt 6.2.
Werten Sie für den infrage kommenden Zeitraum das Anwendungslog aus (siehe Abschnitt 11.2).
Suchen Sie nach Einträgen im Systemlog (siehe Abschnitt 11.1).
Werten Sie die Workprozess-Tracedateien aus (siehe Abschnitt 11.3). Die zum Auffinden der richtigen Tracedatei notwendige Nummer des Hintergrundprozesses erhalten Sie z.B. durch Einblenden des Feldes Workprozess-Nummer in der Jobübersicht (siehe Abbildung 2.9). Alternativ wird sie Ihnen angezeigt, wenn Sie zu einem Eintrag in der Jobübersicht die Funktion Job-Details aufrufen.
Im Job-Log werden zu den eingetragenen Nachrichten auch die Klasse und die Nummer ausgegeben (siehe N-Klasse und N-Nummer in Abbildung 2.10). Suchen Sie mit diesen Angaben im SAP Support Portal nach Hinweisen.
Im folgenden Abschnitt wollen wir einige typische Abbruchsituationen näher untersuchen.
2.3 Beispiele für Probleme in der Jobausführung bis hin zum Abbruch
2.3.1 Ungültige oder fehlende Variante
Abbildung 2.11 zeigt das Job-Log zu einem regelmäßig abbrechenden Job.
Abbildung 2.11: Jobabbruch aufgrund fehlender Variante
Wie in Abschnitt 2.1.1 geschildert, muss jedem Job-Step, der durch ein ABAP-Programm mit Selektionsdynpro realisiert wird, eine Variante zugeordnet werden. Fehlt diese zum Zeitpunkt der Jobausführung, bricht der Job sofort ab. Varianten zu Reports, die Bestandteile eines Job-Steps sind, können von einem Anwender nicht einfach gelöscht werden. Doch manchmal verschwinden sie unvermutet und ganz ohne manuelles Zutun. Dazu ein Beispiel: Wird ein Job mit der Transaktion SA38 und der Funktion »Im Hintergrund ausführen« eingeplant, ist die Angabe einer explizit definierten Variante nicht erforderlich. Vielmehr generiert das System in diesem Fall automatisch eine Variante, die den aktuellen Inhalt des Selektionsbildes enthält. Sie erkennen solche Varianten an dem Und-Zeichen (»&«) zu Beginn des Namens. Sie sind nicht über die Transaktion SE38 änderbar und eigentlich nur zur einmaligen Nutzung für einen Job vorgesehen. Aber sie können eben verlorengehen, und zwar z.B. durch Mandantenkopien. Nähere Hinweise zu Problemen mit den Und-Varianten finden Sie im SAP-Supportsystem unter dem Stichwort »Variant does not exist«.
Um das Problem zu beseitigen, müssen Sie eine geeignete neue Variante definieren und diese in den Job-Step eintragen.
Wenn die Variante noch nicht gelöscht wurde, können Sie die Werte, die Sie in die neue Variante eintragen müssen, bestimmen, indem Sie sich zunächst die Step-Liste zum Job () und anschließend die Variante zum Step () anzeigen lassen. Die Werte für die Selektionskriterien finden Sie dann in der Variantendefinition () (siehe Abbildung 2.12).
Abbildung 2.12: Variante zu einem Step anzeigen
Jobs können auch abbrechen, weil eine Variante nicht mehr gültig ist. Dies kann z.B. dadurch passieren, dass das Selektionsdynpro des ABAP-Programms grundlegend geändert wurde, so etwa durch Hinzufügen weiterer obligatorischer Selektionsparameter. Werden daraufhin die bereits existierenden Varianten nicht angepasst, fehlen ihnen die notwendigen Informationen für die Pflichtparameter. Ein Job mit einer nicht aktualisierten Variante bricht daher ab. Abbildung 2.13 zeigt die im Jobfehler eingetragene Fehlermeldung.
Abbildung 2.13: Jobabbruch bei ungültiger Variante
2.3.2 Step-Benutzer gesperrt oder gelöscht
Bei der Definition eines Jobs müssen Sie für jeden Step die Kennung des Benutzers angeben, in dessen Kontext der Step ausgeführt werden soll.
Benutzerkontext
Im Benutzerkontext sind beispielsweise Informationen zu den Berechtigungen eines Benutzers wie auch Werte für »Benutzerparameter« und »Defaultdrucker« abgelegt (siehe Transaktion SU3).
Bei der Realisierung des Steps erfolgt ein implizites Login des Benutzers, d.h., der Step wird z.B. mit den Berechtigungen des Benutzers ausgeführt. Ist dessen Anmeldung nicht möglich, weil der Benutzer gesperrt ist oder zwischenzeitlich gelöscht wurde, ist der Step nicht ausführbar und der Job bricht ab. Dies trifft auch zu, wenn im Benutzerstammsatz ein abgelaufener Gültigkeitszeitraum vermerkt ist. Im Job-Log wird eine passende Meldung eingetragen (siehe Abbildung 2.14).
Abbildung 2.14: Jobabbruch bei gesperrtem/gelöschtem Benutzer
Jobs mit gelöschten Benutzern identifizieren
Mithilfe des Reports BTCAUX09 können Sie die Jobs bestimmen, die als Step-User einen gelöschten oder gesperrten Benutzer verwenden. Der Report erlaubt es Ihnen, für die gefundenen Jobs bei Bedarf die Einplanung zurückzunehmen. Dieser Report findet jedoch in der aktuellen Version keine Jobs, die einen ungesperrten Benutzer verwenden, für den der Gültigkeitszeitraum abgelaufen ist.
Benutzer vom Typ »System«
Verwenden Sie für die Ausführung von Job-Steps nach Möglichkeit Benutzer vom Typ »System«. Für sie gelten beispielsweise nicht die Regeln hinsichtlich der Gültigkeitsdauer eines Kennworts. Da mit einem solchen Benutzer eine Anmeldung im Dialog nicht möglich ist, besteht auch keine Gefahr, dass er z.B. durch wiederholte Falschanmeldungen gesperrt wird.
2.3.3 Spätester Starttermin überschritten
Einem Job kann zusätzlich zum geplanten Starttermin auch ein Spätester Starttermin zugeordnet werden. Auf diese Weise können Sie z.B. erreichen, dass ein Job – aufgrund von zum geplanten Startzeitpunkt nicht ausreichend verfügbaren Hintergrundprozessen – erst am Folgetag gestartet wird und dann u.U. auf die Daten des falschen Tages zugreift, weil etwa in der verwendeten Variante ein Selektionskriterium wie »Buchungsdatum = Aktuelles Datum« hinterlegt ist. Abbildung 2.15 zeigt das Beispiel eines Jobs mit einer Angabe im Feld Spätester Starttermin.
Abbildung 2.15: Job mit »Spätester Starttermin«
Im konkreten Fall sollte der Job um 05:00 Uhr gestartet werden. Aufgrund von Wartungsarbeiten wurde das System jedoch noch vor dem Starttermin gestoppt und erst nach dem spätesten Starttermin wieder gestartet. Das Überschreiten des spätesten Starttermins führte dazu, dass der Job vom Job-Scheduler nicht ausgeführt, sondern sein Status sofort auf »abgebrochen« gesetzt wurde. Abbildung 2.16 zeigt das zum Job gehörige Log.
Abbildung 2.16: Spätester Starttermin überschritten
2.3.4 Stark verzögerte Jobausführung
Wie bereits mehrfach erwähnt, können zu einem Zeitpunkt immer nur so viele Jobs gleichzeitig ausgeführt werden, wie Hintergrundprozesse zur Verfügung stehen. Solange die zu einem Zeitpunkt zu absolvierenden Jobs nur kurze Laufzeiten haben, werden nach deren Fertigstellung wieder Hintergrundprozesse bereitstehen – die Verzögerung für die wartenden Jobs sollte also gering sein.
Generell können Verzögerungen aber dadurch reduziert werden, dass Jobs gemäß ihrer zu erwartenden Laufzeit und der verfügbaren Anzahl an Hintergrundprozessen in geeigneter Weise zeitlich terminiert werden. In Abschnitt 2.1.2 wurde erläutert, wie durch die Zuweisung von Jobklassen und Prozessreservierungen Einfluss auf die Startreihenfolge von Jobs genommen werden kann.
Insbesondere für die Einplanung periodisch wiederkehrender Jobs ist es hilfreich zu wissen, wie häufig diese gestartet werden und wie lang ihre durchschnittliche Laufzeit sowie die bisher aufgetretene Startverzögerung sind. Gute Dienste leistet in diesem Zusammenhang der Report BTCAUX14. Im Startbild können Sie zunächst auf den zu untersuchenden Zeitraum und die währenddessen erforderliche Mindestanzahl an Starts eines Jobs eingrenzen. Zusätzlich ist eine Selektion nach Jobname möglich (siehe Abbildung 2.17).
Abbildung 2.17: Jobstatistik (Report BTCAUX14)
Die Ergebnisliste (siehe Abbildung 2.18) zeigt je Job u.a. die Wiederholungsperiode (), die durchschnittliche Joblaufzeit () und die durchschnittliche Verzögerung an ().
Abbildung 2.18: Übersicht Jobstatistik
Beachten Sie noch einmal, dass, bedingt durch die Startfrequenz des Job-Schedulers, Verzögerungen von bis zu 60 Sekunden normal sind.
Stellen Sie fest, dass die Verzögerung für einen bestimmten Job nicht tolerierbar ist, könnten Sie, sofern es überhaupt sinnvoll ist, diesen Job auf einen Zeitpunkt mit geringerer Hintergrundlast legen. Alternativ könnten Sie dafür sorgen, dass zum ursprünglich geplanten Startzeitpunkt nicht zu viele andere Jobs mit langer Laufzeit aktiv sind.
2.3.5 Fehlende Jobausführung
Bei einem Job mit periodischer Einplanung kann es vorkommen, dass dieser nicht zu allen erwarteten Zeitpunkten tatsächlich ausgeführt wurde. Betrachten wir dazu das folgende Beispiel:
Der Job DEMO_PERIODIC_15 soll alle 15 Minuten gestartet werden. Eine entsprechende Wiederholungsperiode wurde dem Job bei der Definition zugeordnet (siehe Abbildung 2.19).
Abbildung 2.19: Beispiel periodischer Job
Die Jobübersicht zeigt aber, dass der Job für den Zeitraum zwischen 15:15 Uhr und 16:30 Uhr nicht wie erwartet im 15-Minuten-Rhythmus ausgeführt wurde (siehe Abbildung 2.20).
Abbildung 2.20: Jobübersicht zu Job DEMO_PERIODIC_15
Ursache für die Verzögerung der für 15:45 Uhr geplanten Ausführung: Laut Systemlog ( Transaktion SM21) stand das System zwischen 15:40 Uhr und 16:20 Uhr nicht zur Verfügung.
Die für 15:45 Uhr () geplante Ausführung des Jobs wurde kurz nach dem Wiederanlaufen des Systems (16:20 Uhr) um 16:21 Uhr () mit einer Verzögerung von 2169 Sekunden () ausgeführt. Diese Verzögerung entspricht der Differenz zwischen geplantem Startzeitpunkt und tatsächlicher Ausführung. Wie das Job-Log allerdings zeigt, wurden die eigentlich für 16:00 Uhr und 16:15 Uhr zu erwartenden Starts nicht eingeplant, folglich wurden sie auch nicht verzögert ausgeführt. Mit dem Start des Jobs um 16:21 wurde der ursprünglich geplante Startrhythmus, beginnend mit 16:30, wiederhergestellt (siehe Abbildung 2.21).
Abbildung 2.21: Jobstart nach Systemausfall
Dieses Verhalten des Job-Schedulers ist genauso vorgesehen: Erst mit dem Vollzug eines Jobs erfolgt die Einplanung der nächsten Ausführung gemäß der gewählten Startperiode. Dies kann natürlich dazu führen, dass nicht alle notwendigen Läufe eines Jobs – wie im Beispiel oben illustriert – erfolgt sind. Wenn der Job zum Startzeitpunkt beispielsweise genau die in den zurückliegenden 15 Minuten erzeugten Daten auswerten soll, wäre das Ergebnis im beschriebenen Beispiel nicht mehr vollständig.
Ein möglicher Ausweg wäre z.B., nicht nur einen Job zur vollen Stunde und mit stündlicher Periode, sondern entsprechend viele Jobkopien (es wären 24 erforderlich!) jeweils zur vollen Stunde und mit täglicher Wiederholung einzuplanen. Bei einem mehrstündigen Systemausfall wäre in diesem Fall garantiert, dass die ausgefallenen Jobs zumindest verzögert erledigt würden.
2.4 Hilfsprogramme für die Jobverwaltung
Die SAP bietet für die Verwaltung und Analyse von Jobs eine Reihe von Reports an. Deren Name beginnt jeweils mit »BTCAUX« (siehe Tabelle 2.3).
Tabelle 2.3: Hilfsprogramme für die Jobverwaltung
Verfügbarkeit der Reports
Beachten Sie bitte, dass die SAP sukzessive weitere Reports für die Jobverwaltung entwickelt. In älteren SAP-Releases sind nicht unbedingt alle in der Tabelle aufgeführten Reports verfügbar.
Die Wirkungsweise der Reports BTCAUX09 und BTCAUX14 wurde bereits in den vorangehenden Abschnitten erläutert.
Leider sind diese Hilfsprogramme oft gar nicht oder nur rudimentär dokumentiert. Informationen zu den Reports erhalten Sie aber im SAP Support Portal, wenn Sie dort nach dem Namen des Reports suchen.
2.5 Reorganisation von Job-Logs und Vermeidung trivialer Job-Logs
Sie werden schnell feststellen, dass auf einem SAP-System in kürzester Zeit eine erhebliche Anzahl von Job-Logs entsteht, bedingt durch eine Vielzahl an Jobs mit kurzen Wiederholungsperioden. Zum einen wirkt sich dies negativ auf die Performance der Transaktion SM37 aus, der Aufbau der Jobübersicht ist sehr zeitintensiv. Zum anderen sollten Sie bedenken, dass für jeden Job auch ein Protokoll geschrieben wird. Dieses Protokoll wird – je nach SAP-Release und Kernel-Stand – in Dateien auf Betriebssystemebene (Pfad: DIR_GLOAL) oder in DB-Tabellen (TBTCJOBLOG4) geschrieben.
Speicherung von Job-Logs
Nähere Informationen zur Konfiguration der Speicherung von Job-Logs liefert der SAP-Hinweis 2360818.
Eine regelmäßige Reorganisation der Job-Logs ist unbedingt zu empfehlen, um nicht mehr benötigte Protokolle vom System zu entfernen. Diese Aufgabe können Sie mithilfe des Reports RSBTCDEL2 erledigen. In den meisten SAP-Systemen läuft infolge der Einplanung der sogenannten Standardjobs täglich ein Job mit dem Namen SAP_REORG_JOBS. Dieser Job verwendet im Step den genannten Report in Verbindung mit der Variante SAP&001, die für das Löschen aller Protokolle sorgt, die älter als 14 Tage sind. Dies reicht jedoch bei Weitem nicht aus.
Eine stärkere Reduktion der sich im System anhäufenden Job-Logs können Sie etwa dadurch erreichen, dass Sie den Report RSBTCDEL2 zusätzlich mit weiteren Varianten einplanen, um insbesondere Logs von Jobs mit sehr kurzer Wiederholungsperiode schneller zu löschen. Das Selektionsbild des Reports bietet Ihnen die Möglichkeit, z.B. über den Jobnamen oder den Jobstatus geeignete Varianten zu definieren. Der Report BTCAUX14 hilft Ihnen dabei, besonders häufig gestartete Jobs zu finden (siehe Abbildung 2.18).
Eine Vielzahl an Jobs erzeugt triviale Job-Logs. Dies sind Logs, in denen lediglich der Start, die Ausführung des Steps und das Ende des Jobs vermerkt sind. Triviale Logs können daher automatisch mit dem Job-Ende gelöscht werden, indem Sie den Parameter rdisp/del_triv_joblog auf »1« setzen.
Löschen trivialer Job-Logs
Detailliertere Informationen liefert Ihnen zu diesem Thema der SAP-Hinweis 1468596. Beachten Sie unbedingt die an dieser Stelle aufgeführten Voraussetzungen!
In der Praxis fällt weiterhin auf, dass recht viele Jobs zwar keine trivialen Logs erzeugen, im Log dann aber nur eine zusätzliche Meldung steht (z.B. »Es wurden keine Sätze verarbeitet«). Solche Logs sind eigentlich irrelevant, sie können (mit etwas Programmieraufwand) in triviale Logs umgewandelt werden, indem der im Step genutzte Report angepasst wird. Kandidaten für eine solche Überarbeitung entnehmen Sie dem Report BTCAUX21.
3 Verbuchungsabbrüche
Startet ein Anwender eine Transaktion, wird diese in einem Workprozess ausgeführt, innerhalb dessen die Benutzerkennung des Anwenders bekannt ist. Kommuniziert nun dieser Workprozess zum Lesen bzw. Ändern von Datensätzen mit der Datenbank, verwenden alle SAP-Workprozesse statt dieser Benutzerkennung eine einheitliche Login-Kennung für die Datenbank. Als Konsequenz folgt daraus: Die Datenbank sieht nicht, welcher SAP-Anwender gerade aktiv ist, und sie ist auch nicht in der Lage zu erkennen, welche Datenbankoperationen zu einer Datenbanktransaktion (Datenbank-LUW) gehören. Um hier Abhilfe zu schaffen, hat die SAP die Verbuchungstechnik (Verbucher) realisiert, die im Folgenden genauer beschrieben werden soll. Anschließend werden die Werkzeuge zum Monitoring und Administrieren des Verbuchers vorgestellt.
3.1 Anforderungen an den Verbucher
Wie eingangs erwähnt, verwendet die SAP eine einheitliche Datenbankkennung für die Kommunikation aller Workprozesse mit der Datenbank. Zusätzlich wird zum Ende eines Dialogschritts vom Workprozess immer ein DB-Commit an die Datenbank geschickt. Somit ist die Datenbank nicht in der Lage, Datenbankänderungen, die über mehrere Dialogschritte hinweg von einer Anwendung angestoßen werden, als eine Einheit zu behandeln, die als Datenbank-LUW (LUW = Logical Unit of Work) bezeichnet wird. Da dies aber aus Sicht der Anwendungsentwicklung grundsätzlich notwendig ist, hat die SAP mit dem Verbucher eine Lösung geschaffen (für die technische Realisierung siehe Abschnitt 3.2).
Der Verbucher übernimmt noch weitere Aufgaben: Bricht beispielsweise ein Workprozess hart ab oder kommt es sogar zu einem Ausfall der Datenbankprozesse, werden laufende Datenbank-LUWs unterbrochen; es wird so ein zunächst nicht mehr konsistenter Zustand der Datenbank erzeugt. Jedes Datenbanksystem ist beim Wiederanlaufen in der Lage, durch einen Rollback-Mechanismus unvollständige Datenbank-LUWs komplett zurückzusetzen. Jedoch ist es mit Datenbankmitteln nicht möglich, den vom Rollback betroffenen SAP-Benutzer zu ermitteln, da dieser der Datenbank nicht bekannt ist. Die notwendige Protokollierung, welcher SAP-Anwender welche Datenbankänderungen beauftragt hat, kann stattdessen der Verbucher übernehmen.
Eine weitere Zielsetzung bei der Entwicklung des Verbuchers war, die Dialogverarbeitung zu beschleunigen. Erfasst etwa ein Anwender über eine SAP-Transaktion einen umfangreichen Beleg und sichert diesen, könnte er seine Arbeit erst fortsetzen, wenn alle zum Sichern des Beleges erforderlichen Datenbankbefehle durchgeführt worden sind. Zusätzlich wäre der betreffende SAP-Workprozess in dieser Zeit auch für andere Anwender nicht verfügbar. Dieses Problem wird vom Verbucher mithilfe der Delegation von Datenbankänderungen an spezielle Workprozesse gelöst.
Zusammengefasst soll der Verbucher also folgende Anforderungen übernehmen:
Bündelung von Datenbankoperationen über mehrere Dialogschritte hinweg
Informationen zu betroffenen SAP-Anwendern und Transaktionen im Falle eines Prozessabbruchs bzw. eines Wiederanlaufens der Datenbank liefern
Verkürzung der Wartezeiten beim Sichern
3.2 Funktionsweise des Verbuchers
Grundsätzliche Voraussetzung zum Einsatz der Verbuchungstechnik ist es, dass alle ändernden Datenbankanweisungen, die eine Anwendung ausführen möchte, vom Entwickler in Funktionsbausteine ausgelagert werden. Diese Funktionsbausteine werden dann wiederum im Coding in der Form CALL FUNCTION …. IN UPDATE TASK an geeigneter Stelle aufgerufen. Der Zusatz IN UPDATE TASK bewirkt, dass die Bausteine nicht sofort ausgeführt, sondern nur für eine spätere Ausführung vorgemerkt werden. Sind im Programm alle notwendigen Vormerkungen erfolgt, kann die Ausführung der Funktionsbausteine mit der Anweisung COMMIT WORK gestartet werden. Ein eventuell im Programm abgesetztes ROLLBACK WORK würde die Vormerkungen stornieren. Die Bausteine selbst werden nicht in dem Workprozess ausgeführt, in dem die Anweisung COMMIT WORK erfolgt. Stattdessen werden die Bausteine an eigens dafür im Hintergrund aktive sogenannte Verbuchungsworkprozesse übergeben. Der eigentliche Workprozess setzt seine Verarbeitung nach dem COMMIT WORK umgehend fort und wartet nicht darauf, dass die Ausführung in den Verbuchungsworkprozessen abgeschlossen ist.
Bevor ich den genauen Ablauf einer Dialogverarbeitung mit Verbuchereinsatz beschreibe, gebe ich Ihnen zunächst einige Informationen, welche Voraussetzungen ein Funktionsbaustein erfüllen muss, um per Verbuchung ausgeführt werden zu können. Betrachten wollen wir dazu einfache Beispiele, die wir später zum Test des Verbuchungsablaufs einsetzen können.
Der Entwickler, der die Bausteine für die Verbuchungstechnik definiert, muss diese im Function Builder (Transaktion SE37) als Verbuchungsbaustein () kennzeichnen (siehe Abbildung 3.1).
Abbildung 3.1: Verbuchungsbaustein
Zudem muss er festlegen, mit welcher Priorität die Ausführung des Bausteins nach einem COMMIT WORK in einem der Verbuchungsworkprozesse erfolgen soll (). Die Auswahl legt fest, welche Nachbehandlung nach fehlerhafter Ausführung des Bausteins möglich ist (Tabelle 3.1).
Tabelle 3.1: Verbuchungspriorität
Bausteine mit der Option Start sofort werden unabhängig von ihrer Nachbuchbarkeit auch als V1-Komponenten bezeichnet, solche mit Start verzögert als V2-Komponenten und diejenigen mit Sammellauf als V3-Komponenten.
Funktionsbausteine, die zeitversetzt (asynchron) zum Aufruf mit CALL FUNCTION ... IN UPDATE TASK und außerdem in den eigens dafür vorgesehenen Verbuchungsprozessen ausgeführt werden, können keine Rückgabewerte an die Anwendung liefern, in der die Vormerkung erfolgte. Daher besitzen verbuchungsfähige Funktionsbausteine keine Export- oder Changing-Parameter.
Für die nachfolgende detaillierte Erläuterung und den anschließenden konkreten Test des Verbuchungsablaufs sollen die in Tabelle 3.2 ausgewiesenen Funktionsbausteine verwendet werden.
| Baustein | Priorität |
|---|---|
| TH_VB_TEST_01 | Start sofort |
| TH_VB_TEST_02 | Start verzögert |
| TH_VB_TEST_03 | Start sofort nicht nachbuchbar |
| TH_VB_TEST_04 | Sammellauf |
| TH_VB_TEST_06 | Sammellauf |
| TH_VB_TEST_07 | Sammellauf |
| TH_VB_TEST_08 | Sammellauf |
Tabelle 3.2: Musterbausteine für einen Verbuchungstest
Abbildung 3.2 zeigt (stark vereinfacht) das Coding einer Anwendung, die Datenbankänderungen über die in der Tabelle aufgeführten Verbuchungsbausteine durchführt.
Abbildung 3.2: Beispiel Verbuchungsauftrag (Teil 1)
Vormerkung der Verbuchungsbausteine
Mit dem Start der Anwendung beginnt eine neue Verarbeitungseinheit, die sogenannte SAP-LUW. Zunächst werden alle notwendigen Sperren gesetzt (), um konkurrierende Zugriffe auf Daten zu verhindern. Mit der ersten Verbuchungsvormerkung (CALL FUNCTION TH_VB_TEST_01) wird ein eindeutiger Schlüssel (VBKEY) für die Verbuchungseinheit gebildet und zusammen mit Informationen z.B. zur gestarteten Transaktion, dem SAP-Benutzer und dem Startzeitpunkt in die Tabelle VBHDR geschrieben (). Zusätzlich werden der Name des Funktionsbausteins in die Tabelle VBMOD () und die Übergabeparameter des Bausteins als binäre Zeichenfolge zusammengesetzt in die Tabelle VBDATA () übertragen. Beim Aufruf weiterer Verbuchungsbausteine werden die Schritte () bis () wiederholt.
Freigabe zur Verbuchung
Sind alle erforderlichen Bausteine für die Verbuchung vorgemerkt (und der Anwender führt eine Funktion wie beispielsweise »Sichern« aus), gibt die Anweisung COMMIT WORK () den Verbuchungsauftrag frei. Dabei wird die von der Anwendung gesetzte Sperre an den Verbucher vererbt; dieser ist somit der neue Sperreigentümer. Gleichzeitig beginnt mit dem COMMIT WORK eine neue SAP-LUW. Im Normalfall erhält der User nach dem COMMIT WORK von der Anwendung eine Meldung, die beispielsweise lauten könnte: »Daten wurden gesichert!« Diese Meldung ist eigentlich so nicht ganz korrekt, denn der Verbuchungsauftrag ist in diesem Moment nur zur Ausführung freigegeben.
Бесплатный фрагмент закончился.
