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:
| Priorität | Bedeutung |
|---|---|
| Hoch | Dialoganwendungen und systeminterne Vorgänge wie z.B. Puffersynchronisation, Batch-Scheduler |
| Normal | RFC-Aufrufe aus Dialoganwendungen |
| Niedrig | Ausführung von Job-Steps und RFC-Aufrufen aus Batch-Anwendungen |
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 (
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 (
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
Ein Job-Step kann durch ein ausführbares ABAP-Programm, ein externes Kommando oder durch ein externes
