Praxishandbuch SAP-Basis – Troubleshooting in der Systemadministration

Tekst
Loe katkendit
Märgi loetuks
Kuidas lugeda raamatut pärast ostmist
Praxishandbuch SAP-Basis – Troubleshooting in der Systemadministration
Šrift:Väiksem АаSuurem Aa

Manfred Sprenger

Praxishandbuch SAP®-Basis – Troubleshooting in der Systemadministration


Manfred Sprenger

Praxishandbuch SAP®-Basis – Troubleshooting in der Systemadministration

ISBN:978-3-96012-948-6 (E-Book)

Lektorat:Anja Achilles

Korrektorat: Die Korrekturstube

Coverdesign: Philip Esch

Coverfoto: © choness | # 485370481 – istockphoto.com

Satz & Layout: Johann-Christian Hanke

1. Auflage 2020

© Espresso Tutorials GmbH, Gleichen 2020

URL: www.espresso-tutorials.de

Das vorliegende Werk ist in allen seinen Teilen urheberrechtlich geschützt. Alle Rechte sind vorbehalten, insbesondere das Recht der Übersetzung, des Vortrags, der Reproduktion und der Vervielfältigung. Espresso Tutorials GmbH, Bahnhofstr. 2, 37130 Gleichen, Deutschland.

Ungeachtet der Sorgfalt, die auf die Erstellung von Text und Abbildungen verwendet wurde, können weder der Verlag noch die Autoren oder Herausgeber für mögliche Fehler und deren Folgen eine juristische Verantwortung oder Haftung übernehmen.

Feedback: Wir freuen uns über Fragen und Anmerkungen jeglicher Art. Bitte senden Sie diese an: info@espresso-tutorials.com.

Inhaltsverzeichnis

Cover

Titelseite

Copyright/Impressum

Vorwort

Zielgruppe

Über dieses Buch

1 System langsam bzw. ohne Reaktion

1.1 Dialogworkprozesse und Dialogschritte

1.2 Analyse mit dem Workprozess-Monitor

1.3 Verwaltung von Workprozessen

1.4 Alternativen zur Transaktion SM50

2 Abbruch oder verzögerte Ausführung von Jobs

2.1 Konzept der Hintergrundverarbeitung

2.2 Job-Monitor

2.3 Beispiele für Probleme in der Jobausführung bis hin zum Abbruch

2.4 Hilfsprogramme für die Jobverwaltung

2.5 Reorganisation von Job-Logs und Vermeidung trivialer Job-Logs

3 Verbuchungsabbrüche

3.1 Anforderungen an den Verbucher

3.2 Funktionsweise des Verbuchers

3.3 Verbuchungsworkprozesse

3.4 Verbuchungsabbrüche

3.5 Verbuchungsmonitor

3.6 Verbucheradministration

4 Sperrverwaltung

4.1 Das SAP-Sperrkonzept

4.2 Monitoring und Verwaltung von Sperren

4.3 Überlaufen der Sperrtabelle

4.4 Transaktion SMENQ

5 Probleme mit Nummernkreisen

5.1 Nummernkreisobjekte und Nummernkreisintervalle

5.2 Pufferung von Nummernkreisen

5.3 Monitoring von Nummernkreisintervallen

6 Programmabbrüche

6.1 Laufzeitfehler

6.2 Laufzeitfehler auswerten

7 Druckprobleme

7.1 Spool-Auftrag und Ausgabeauftrag

7.2 Aufbereitungsserver und Druckmethoden

7.3 Druckereigenschaften und Koppelarten

7.4 Monitoring und Steuerung von Spool- und Ausgabeaufträgen

7.5 Beispiele für Fehleranalyse

8 Berechtigungsprobleme

8.1 Grundlagen SAP-Berechtigungskonzept

8.2 Technische Durchführung einer Berechtigungsprüfung

8.3 Analyse von Berechtigungsfehlern

8.4 Berechtigungstrace

8.5 Berechtigungen: Typische Fehlerquellen

9 Fehleranalyse mithilfe des Debuggers

9.1 Debugger starten und stoppen

9.2 Debugger »exklusiv« und »nicht exklusiv«

9.3 Steuerung des Debuggers

9.4 Variableninhalte anzeigen und ändern

9.5 ABAP und Dynpro Stack

9.6 Debuggen für anderen Benutzer

9.7 Checkpoint-Gruppen

10 Kommunikation über RFC- und HTTP-Schnittstellen

10.1 RFC-Schnittstelle

10.2 RFC-Varianten

10.3 Internet Communication Manager

11 Wichtige Log- und Tracedateien

11.1 Systemlog

11.2 Anwendungslog

11.3 Workprozess-Traces

12 Wie findet man Tabellennamen?

12.1 Technische Info über die F1-Hilfe

12.2 Suche nach SELECT im Quelltext

12.3 Programmtrace mit SAT

12.4 Trace mit Transaktion ST12

12.5 Informationen zu Customizing-Tabellen

Fazit

Anhang

A Der Autor

B Disclaimer

Weitere Bücher von Espresso Tutorials

 

Mehr Wert für Ihr SAP®

Willkommen bei Espresso Tutorials!

Unser Ziel ist es, SAP-Wissen wie einen Espresso zu servieren: Auf das Wesentliche verdichtete Informationen anstelle langatmiger Kompendien – für ein effektives Lernen an konkreten Fallbeispielen. Viele unserer Bücher enthalten zusätzlich Videos, mit denen Sie Schritt für Schritt die vermittelten Inhalte nachvollziehen können. Besuchen Sie unseren YouTube-Kanal mit einer umfangreichen Auswahl frei zugänglicher Videos:

https://www.youtube.com/user/EspressoTutorials.

Kennen Sie schon unser Forum? Hier erhalten Sie stets aktuelle Informationen zu Entwicklungen der SAP-Software, Hilfe zu Ihren Fragen und die Gelegenheit, mit anderen Anwendern zu diskutieren:

http://www.fico-forum.de.

Eine Auswahl weiterer Bücher von Espresso Tutorials:

 Julian Harfmann, Sabrina Heim, Andreas Dietrich: Compliant Identity Management mit SAP® IdM und GRC AC

 Andreas Prieß:SAP®-Berechtigungen für Anwender und Einsteiger

 Martin Metz & Sebastian Mayer:Schnelleinstieg in SAP® GRC Access Control

 Bianca Folkerts:Praxishandbuch für die Risikoanalyse mit SAP® GRC Access Control

 Andreas Schuster:Praxishandbuch SAP® HANA – Administration

 Günter Dusch:Datenmigration mit SAP® LSMW: Einfach, schnell und kompakt


Vorwort

In den zurückliegenden Jahren gehörte es zu einer meiner häufigsten Aufgaben, in SAP-Systemen auftretende Probleme zu analysieren und nach Möglichkeit zu beseitigen. Dabei stellte sich immer wieder heraus, dass Fehler selten nur ein einziges Mal auftreten und die einmal bei der Analyse und Lösung gewonnenen Kenntnisse sehr hilfreich sind, wenn sich der Fehler wiederholt. So konnte ich im Laufe der Zeit ein umfassendes Wissen aufbauen, wie man ein SAP-Troubleshooting, also eine systematische Analyse von Fehlern, am zweckmäßigsten durchführt. Seitens meiner Kunden wurde ich immer häufiger gebeten, dieses Wissen an die Mitarbeiter weiterzugeben, die im Unternehmen mit der Fehleranalyse und -behebung betraut sind. So ist eine Reihe von Workshops zum Thema »SAP-Troubleshooting« entstanden, die ich in den letzten Jahren oft durchgeführt habe. Dieses Buch enthält quasi eine Auswahl, ein »Best-of« derjenigen Themen, die durchgängig bei allen Unternehmen relevant waren. Damit wird natürlich nur ein Bruchteil dessen abgedeckt, was in der täglichen SAP-Praxis an Problemen auftreten kann, doch sollten die im Verlauf des Buches vorgestellten Werkzeuge Ihnen dabei helfen, auch bei hier nicht angesprochenen Schwierigkeiten Licht ins Dunkel zu bringen.

Zielgruppe

Dieser Praxisleitfaden wendet sich zunächst einmal an alle Mitarbeiter des Supportteams, die mit dem SAP-Troubleshooting betraut sind. Aber auch Entwickler und technisch interessierte Key-User sollten genügend Hilfestellungen finden, um selbst in die Fehleranalyse einzusteigen. Mit den so gewonnenen Informationen sind Sie dann hoffentlich in der Lage, anhand von SAP-Hinweisen eigenständig Lösungen zu finden.

Über dieses Buch

In diesem Buch werden typische, in der täglichen SAP-Praxis auftretende Problemsituationen beschrieben. Zu Beginn eines jeden Kapitels erläutere ich zunächst die jeweils beteiligten technischen Komponenten. Dabei geht es mir nicht darum, jedes Detail und jede mögliche Variante einer Komponente zu schildern, schließlich liefert die SAP mit ihrer Onlinedokumentation praktisch zu allen Themen ausführliche Informationen. Ich beschränke mich jeweils auf die Vermittlung des aus meiner Sicht erforderlichen Wissens, um Fehlermeldungen zu verstehen und die für eine weitere Analyse zur Verfügung stehenden Werkzeuge einsetzen zu können. Die SAP-Basis-Profis unter den Lesern mögen mir die eine oder andere Vereinfachung der geschilderten Sachverhalte nachsehen.

Das für mich wichtigste Werkzeug, der ABAP-Debugger, wird mit der für die meisten Einsatzfälle notwendigen Tiefe in Kapitel 9 beschrieben. Der Debugger kommt eigentlich immer dann zum Einsatz, wenn es darum geht, ein Problem zu reproduzieren, um dabei detailliert den Ablauf einer Anwendung zu analysieren. Ist das Debugging aus technischen Gründen nicht möglich, weil z.B. die Berechtigungen dafür insbesondere in dem produktiven SAP-System nicht vorliegen oder das Problem nicht noch einmal erzeugt werden kann, bleibt oft nur noch die Auswertung von Log- und Tracedateien. Kapitel 11 zeigt Ihnen, welche Dateien hier helfen können und wie sie zu analysieren sind. Ergänzend zu den Log- und Tracedateien stehen u.U. auch ABAP-Dumps zur Verfügung, die Informationen zu Programmabbrüchen beinhalten. In Kapitel 6 erfahren Sie, wie Sie mithilfe der Transaktion ST22 die in den Dumps protokollierten Laufzeitfehler untersuchen können.

Immer wieder gilt es, zu klären, in welcher Tabelle eigentlich welche Daten abgelegt werden. Nur wer die Tabellennamen kennt, kann mit Werkzeugen wie den Transaktionen SE16 oder SM30 überprüfen, ob die erforderlichen Daten tatsächlich vorhanden sind. Kapitel 12 zeigt Ihnen, welche Tools zur Verfügung stehen, um Tabellennamen zu ermitteln.

Während die bisher genannten Kapitel eher universell Hilfestellungen für jedwede Art von Fehlern geben, befassen sich die im Folgenden aufgeführten Abschnitte mit speziellen Problemen:

Gleich das erste Kapitel habe ich den immer mal auftretenden Performanceproblemen gewidmet. Geklärt werden soll insbesondere die Frage, mit welchen Tools nachvollzogen werden kann, ob es sich dabei lediglich um den subjektiven Eindruck einzelner SAP-Anwender handelt oder ob die Probleme objektiv nachvollziehbar sind.

Kapitel 2 beschäftigt sich mit der SAP-Hintergrundverarbeitung und beschreibt, welche Ursachen für Jobabbrüche, Jobausfälle oder verzögerte Ausführungen verantwortlich sind.

In Kapitel 3 soll ein Verständnis dafür geweckt werden, warum das Monitoring des SAP-Verbuchers wichtig ist.

Die SAP-Sperrverwaltung ist Thema des Kapitels 4, während die eher selten auftretenden Probleme mit der Nummernkreisdefinition in Kapitel 5 geschildert werden.

Sind Sie an der Lösung von Problemen im Zusammenhang mit dem »Drucken« interessiert, sollten Sie Kapitel 7 konsultieren.

Eine Vielzahl der Meldungen, die ein Supportteam zu bearbeiten hat, betrifft das Thema »Berechtigungen«. Kapitel 8 zeigt Ihnen, wie Sie fehlende Berechtigungen ermitteln können, aber auch wie man zu viel vergebene Berechtigungen finden kann.

Da jedes SAP-System für gewöhnlich eine Vielzahl von Schnittstellen zu weiteren SAP-Systemen und auch Nicht-SAP-Systemen besitzt, ist es sicherlich hilfreich, sich mit Kapitel 10 zu befassen. Hier erfahren Sie, wie Sie Fehler im Zusammenhang mit der Kommunikation über RFC oder den Internet Communication Manager analysieren sollten.

In den Text sind Kästen eingefügt, um wichtige Informationen besonders hervorzuheben. Jeder Kasten ist zusätzlich mit einem Piktogramm versehen, das diesen genauer klassifiziert:

Hinweis

Hinweise bieten praktische Tipps zum Umgang mit dem jeweiligen Thema.

Beispiel

Beispiele dienen dazu, ein Thema besser zu illustrieren.

Achtung

Warnungen weisen auf mögliche Fehlerquellen oder Stolpersteine im Zusammenhang mit einem Thema hin.

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

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.