Manfred Sprenger - Praxishandbuch SAP-Basis – Troubleshooting in der Systemadministration

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.2wurde 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.

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.

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.

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.