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

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

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 (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 pfmuss 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 »513« 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

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.

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.

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.