Praxishandbuch SAP-Basis – Troubleshooting in der Systemadministration

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:

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:

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