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

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

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

Автор: Manfred Sprenger

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

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

Серия:

isbn: 9783960129486

isbn:

СКАЧАТЬ 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

      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 (

) 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 »5<Instanz>13« 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.

      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

      

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 СКАЧАТЬ