Praxishandbuch SAP-Basis – Troubleshooting in der Systemadministration. Manfred Sprenger
Чтение книги онлайн.

Читать онлайн книгу Praxishandbuch SAP-Basis – Troubleshooting in der Systemadministration - Manfred Sprenger страница 4

Название: Praxishandbuch SAP-Basis – Troubleshooting in der Systemadministration

Автор: Manfred Sprenger

Издательство: Автор

Жанр: Программы

Серия:

isbn: 9783960129486

isbn:

СКАЧАТЬ Form der Anrede

      Um den Lesefluss nicht zu beeinträchtigen, verwenden wir im vorliegenden Buch bei personenbezogenen Substantiven und Pronomen zwar nur die gewohnte männliche Sprachform, meinen aber gleichermaßen die weibliche.

      Hinweis zum Urheberrecht

      Zum Abschluss des Vorwortes noch ein Hinweis zum Urheberrecht: Sämtliche in diesem Buch abgedruckten Screenshots unterliegen dem Copyright der SAP SE sowie Adobe. Alle Rechte an den Screenshots hält die SAP SE. Der Einfachheit halber haben wir im Rest des Buches darauf verzichtet, dies unter jedem Screenshot gesondert auszuweisen.

      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.

      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.

      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

      

СКАЧАТЬ