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

Читать онлайн книгу.

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


Скачать книгу

      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.

Troubleshooting

      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.

Troubleshooting

      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).

Troubleshooting

      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 (
).

Troubleshooting

      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).

Troubleshooting

      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).

Troubleshooting

      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).

Troubleshooting

      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


Скачать книгу