Praxishandbuch SAP-Basis – Troubleshooting in der Systemadministration. Manfred Sprenger
Jobs mit gelöschten Benutzern identifizieren
Benutzer vom Typ »System«
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 (
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 (
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