Praxishandbuch SAP-Basis – Troubleshooting in der Systemadministration. Manfred Sprenger
Чтение книги онлайн.

Читать онлайн книгу Praxishandbuch SAP-Basis – Troubleshooting in der Systemadministration - Manfred Sprenger страница 9

Название: Praxishandbuch SAP-Basis – Troubleshooting in der Systemadministration

Автор: Manfred Sprenger

Издательство: Автор

Жанр: Программы

Серия:

isbn: 9783960129486

isbn:

СКАЧАТЬ href="#ulink_7a5d92ff-ed5e-5156-a884-b8203eabd944">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.1 Ungültige oder fehlende Variante

      Abbildung 2.11 zeigt das Job-Log zu einem regelmäßig abbrechenden Job.

Troubleshooting

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

Troubleshooting

      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.

Troubleshooting

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

Troubleshooting

      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.

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 СКАЧАТЬ