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

      Abbildung 1.1: Dynprofolge und Dialogschritt

      Ein Dialogschritt umfasst sowohl den PAI-Block des aktuell bearbeiteten Dynpros als auch den PBO-Block des Folgedynpros. Für die Ausführung genau eines solchen Dialogschritts wird dem Anwender ein Dialogworkprozess zugeordnet. Ist der Dialogschritt beendet, gibt der Anwender den Workprozess wieder frei, und dieser kann von einem anderen Anwender für die Ausführung eines Dialogschritts eingesetzt werden. Prinzipiell spielt es dabei keine Rolle, wie lange ein Dialogschritt dauert. Wenn ein Anwender z.B. eine umfangreiche Liste erstellt, kann es durchaus vorkommen, dass die Bearbeitung des entsprechenden Dialogschritts mehrere Minuten (wenn nicht sogar Stunden) in Anspruch nimmt. Entsprechend lange ist dann der zugeordnete Dialogworkprozess für andere Anwender blockiert.

      Da Workprozesse mitunter erhebliche Systemressourcen, insbesondere Hauptspeicher, binden können, steht nicht jedem angemeldeten Benutzer ein eigener Dialogworkprozess zur Bearbeitung zur Verfügung. Vielmehr verteilt der Dispatcher einer SAP-Instanz die zu verarbeitenden Dialogschritte nacheinander auf die vorhandenen Dialogworkprozesse.

      Verhältnis von Anwender zu Dialogworkprozess

      

Typisch ist ein Verhältnis zwischen Anzahl angemeldeter Anwender und verfügbarer Dialogworkprozesse von etwa 10:1. Geht man z.B. davon aus, dass ein Anwender für die Eingabe der Daten in ein Dynpro zehn Sekunden benötigt, der Dialogschritt selbst etwa eine Sekunde läuft, kann man also im Mittel annehmen, dass, sofern nicht alle Anfragen gleichzeitig erfolgen, immer ein Dialogworkprozess zur Verfügung steht.

      Probleme entstehen eigentlich immer dann, wenn im Dialogbetrieb Anwendungen gestartet werden, deren Dialogschritte weit über das übliche Maß hinaus Zeit und damit Dialogworkprozesse beanspruchen. Die Folge ist, dass die noch verfügbaren freien Workprozesse nicht mehr ausreichen, um die anstehenden Dialogschritte der übrigen Anwender mit angemessener Wartezeit zu bearbeiten. Im Extremfall kann das System, wenn gar keine freien Dialogprozesse mehr vorhanden sind, temporär zum Stillstand kommen.

      In den folgenden Abschnitten wollen wir die Werkzeuge näher betrachten, die eine Überwachung der Workprozesse ermöglichen, um das Beschriebene zu verhindern.

1.2 Analyse mit dem Workprozess-Monitor

      Eine Übersicht über die Workprozesse einer Instanz liefert die Transaktion SM50, während SM66 die Workprozesse aller Instanzen eines SAP-Systems zeigt. Wir beschränken uns in diesem Abschnitt auf die Transaktion SM50, weil diese umfangreichere Informationen und Verwaltungsfunktionen anbietet als SM66 (siehe Abbildung 1.2).

      Abbildung 1.2: Workprozess – Übersicht

      Es werden u.a. folgende Informationen ausgegeben:

      

Fortlaufende Nummer des Workprozesses (Nr): Die Nummer kann verwendet werden, um die für den Workprozess relevanten Tracedateien zu ermitteln (Details siehe Abschnitt 11.3)

      

Workprozess-Typ:

       DIA = Dialogworkprozess

       BTC = Batchworkprozess (siehe Abschnitt 2.1)

       UPD/UPD2 = Verbuchungsworkprozess (siehe Abschnitt 3.3)

       SPO = Spoolworkprozess (siehe Abschnitt 7.1)

      

Workprozess-Status (WP-Status) (siehe Tabelle 1.1)

      

Zusatzinformation zum Status »hält« (Info Hält)

      

Aktuelle Bearbeitungsdauer (B.-Dauer)

      

Programm, welches gerade vom WP ausgeführt wird

      

Benutzer-ID, dessen Auftrag ausgeführt wird

      

Aktuell im Workprozess ausgeführte Aktion

      Die wohl wichtigste Angabe ist diejenige des »Status«. Tabelle 1.1 zeigt Ihnen mögliche Ausprägungen.

      Tabelle 1.1: Die häufigsten Workprozess-Status

      Es sollte schnell klar sein, dass die Dialogantwortzeiten des Systems ungünstig ausfallen können, wenn, wie in Abbildung 1.2 gezeigt, nur wenige Dialogprozesse im Status »wartet« zur Verfügung stehen und für die laufenden Prozesse eine Bearbeitungszeit von mehreren Sekunden angezeigt wird. Lediglich wenn ein Dialogworkprozess mit Status »wartet« vorhanden ist, kann ein Dialogschritt ohne Wartezeit vom Anwender bearbeitet werden. Andernfalls beginnt die Bearbeitung des Schritts erst mit dem Freiwerden eines Dialogworkprozesses.

      Die Transaktion SM50 gibt Ihnen Auskunft über die Auslastung der Workprozesse aktuell und in den zurückliegenden 15 Minuten (siehe Abbildung 1.3).

      Abbildung 1.3: Auslastung Workprozesse

      Angezeigt werden verfügbare und freie Workprozesse (

) sowie die durchschnittliche Auslastung während der letzten Minute, der letzten fünf und der letzten 15 Minuten (

).

      Besonders kritisch ist es, wenn mehrere Dialogworkprozesse den Status »hält« für eine längere Zeit besitzen. Sie bleiben in diesem Fall über das Ende des Dialogschritts hinaus so lange reserviert, bis der Grund für diesen Status beseitigt ist. In dem in Abbildung 1.2 dargestellten Beispiel sind immerhin schon fast die Hälfte der Prozesse reserviert.

      Die Spalte Info Hält gibt Ihnen Hinweise auf den Auslöser für den Status »hält«. Tabelle 1.2 führt hierzu einige Beispiele auf:

      Tabelle 1.2: Beispiele für typische Auslöser in der Spalte »Info Hält«

      Nachfolgend wollen wir uns für zwei der hier gezeigten Auslöser genauer ansehen, wie Sie darauf reagieren können.

      1.2.1 Workprozess im Status »hält« mit Grund »RFC-Antwort«

      Bekommt ein Workprozess den Status »hält« aufgrund einer »RFC-Antwort« zugewiesen, können Sie wie folgt ermitteln, welcher RFC-Aufruf über welche verwendete RFC-Destination den Status ausgelöst hat (siehe Abbildung 1.4).