Buch lesen: «Praxishandbuch SAP-Basis – Troubleshooting in der Systemadministration»

1 System langsam bzw. ohne Reaktion

Immer wieder kommt es vor, dass sich Anwender im Dialogbetrieb über lange Antwortzeiten beschweren oder gar Meldungen einreichen, dass systemseitig gar keine Reaktion mehr erfolgt. Im Folgenden sollen Werkzeuge vorgestellt werden, mit deren Hilfe Sie u.a. prüfen können, ob nur einzelne Benutzer oder alle Anwender vom Problem betroffen sind.

Wir wollen uns in diesem Kapitel auf die für Anwender besonders wichtige Dialogverarbeitung konzentrieren; Informationen zu Problemen mit der Hintergrundverarbeitung finden Sie in Kapitel 2, zu Verbuchungsproblemen in Kapitel 3.

1.1 Dialogworkprozesse und Dialogschritte

Eine Dialoganwendung (SAP-Transaktion) besteht prinzipiell aus einer Folge von Masken (Dynpros), die für die Bearbeitung einer bestimmten Aufgabe durchlaufen werden müssen. Gestartet wird eine Dialoganwendung im Normalfall über einen Transaktionscode. Mit dem Start wird das erste der Transaktion zugeordnete Dynpro geöffnet. Abhängig von den Eingaben des Anwenders und der Ablauflogik des Dynpros wird anschließend das Folgedynpro geladen. Eine mögliche Dynprofolge zeigt Abbildung 1.1.

Jedem Dynpro sind zwei Verarbeitungsblöcke zugeordnet:

1. Process before Output, PBO wird im Applikationsserver ausgeführt, bevor das Dynpro zur Anzeige z.B. an die SAP GUI gesendet wird, und

2. Process after Input, PAI wird verarbeitet, wenn der Anwender die Eingabe von Daten durch Auslösen der gewünschten Folgeaktion abschließt.

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

Abbildung 1.4: Status »hält« mit Grund »RFC-Antwort«

Per Doppelklick auf einen Workprozess in der Übersicht (siehe Abbildung 1.2) erhalten Sie die zugehörigen Detailinformationen. Unter der Rubrik Wartegrund finden Sie im Feld Warteinfo () die sogenannte Conversation ID des RFC-Aufrufs. Starten Sie nun die Transaktion SM5A und geben Sie dort die Conversion ID in das betreffende Feld ein (). Im nachfolgenden Bild sehen Sie dann u.a., welche RFC-Destination für den Aufruf genutzt wurde und auf welcher Instanz (Server ) der gerufene Baustein ausgeführt wird. Starten Sie auf dieser Instanz nun die Transaktion SM50. Sie gibt Ihnen u.U. Hinweise darauf, ob die Instanz möglicherweise stark belastet ist und der RFC-Aufruf deshalb zu langen Antwortzeiten führt.

SAP-Hinweis 934109

SAP-Hinweis 934109 enthält detaillierte Informationen zu den Ursachen des Status »hält RFC« und zeichnet Lösungswege auf, wie Sie das Setzen des Status vermeiden.