Praxishandbuch SAP-Basis – Troubleshooting in der Systemadministration

2.3.2 Step-Benutzer gesperrt oder gelöscht

Bei der Definition eines Jobs müssen Sie für jeden Step die Kennung des Benutzers angeben, in dessen Kontext der Step ausgeführt werden soll.

Benutzerkontext

Im Benutzerkontext sind beispielsweise Informationen zu den Berechtigungen eines Benutzers wie auch Werte für »Benutzerparameter« und »Defaultdrucker« abgelegt (siehe Transaktion SU3).

Bei der Realisierung des Steps erfolgt ein implizites Login des Benutzers, d.h., der Step wird z.B. mit den Berechtigungen des Benutzers ausgeführt. Ist dessen Anmeldung nicht möglich, weil der Benutzer gesperrt ist oder zwischenzeitlich gelöscht wurde, ist der Step nicht ausführbar und der Job bricht ab. Dies trifft auch zu, wenn im Benutzerstammsatz ein abgelaufener Gültigkeitszeitraum vermerkt ist. Im Job-Log wird eine passende Meldung eingetragen (siehe Abbildung 2.14).

Abbildung 2.14: Jobabbruch bei gesperrtem/gelöschtem Benutzer

Jobs mit gelöschten Benutzern identifizieren

Mithilfe des Reports BTCAUX09 können Sie die Jobs bestimmen, die als Step-User einen gelöschten oder gesperrten Benutzer verwenden. Der Report erlaubt es Ihnen, für die gefundenen Jobs bei Bedarf die Einplanung zurückzunehmen. Dieser Report findet jedoch in der aktuellen Version keine Jobs, die einen ungesperrten Benutzer verwenden, für den der Gültigkeitszeitraum abgelaufen ist.

Benutzer vom Typ »System«

Verwenden Sie für die Ausführung von Job-Steps nach Möglichkeit Benutzer vom Typ »System«. Für sie gelten beispielsweise nicht die Regeln hinsichtlich der Gültigkeitsdauer eines Kennworts. Da mit einem solchen Benutzer eine Anmeldung im Dialog nicht möglich ist, besteht auch keine Gefahr, dass er z.B. durch wiederholte Falschanmeldungen gesperrt wird.

2.3.3 Spätester Starttermin überschritten

Einem Job kann zusätzlich zum geplanten Starttermin auch ein Spätester Starttermin zugeordnet werden. Auf diese Weise können Sie z.B. erreichen, dass ein Job – aufgrund von zum geplanten Startzeitpunkt nicht ausreichend verfügbaren Hintergrundprozessen – erst am Folgetag gestartet wird und dann u.U. auf die Daten des falschen Tages zugreift, weil etwa in der verwendeten Variante ein Selektionskriterium wie »Buchungsdatum = Aktuelles Datum« hinterlegt ist. Abbildung 2.15 zeigt das Beispiel eines Jobs mit einer Angabe im Feld Spätester Starttermin.

Abbildung 2.15: Job mit »Spätester Starttermin«

Im konkreten Fall sollte der Job um 05:00 Uhr gestartet werden. Aufgrund von Wartungsarbeiten wurde das System jedoch noch vor dem Starttermin gestoppt und erst nach dem spätesten Starttermin wieder gestartet. Das Überschreiten des spätesten Starttermins führte dazu, dass der Job vom Job-Scheduler nicht ausgeführt, sondern sein Status sofort auf »abgebrochen« gesetzt wurde. Abbildung 2.16 zeigt das zum Job gehörige Log.

Abbildung 2.16: Spätester Starttermin überschritten

2.3.4 Stark verzögerte Jobausführung

Wie bereits mehrfach erwähnt, können zu einem Zeitpunkt immer nur so viele Jobs gleichzeitig ausgeführt werden, wie Hintergrundprozesse zur Verfügung stehen. Solange die zu einem Zeitpunkt zu absolvierenden Jobs nur kurze Laufzeiten haben, werden nach deren Fertigstellung wieder Hintergrundprozesse bereitstehen – die Verzögerung für die wartenden Jobs sollte also gering sein.

Generell können Verzögerungen aber dadurch reduziert werden, dass Jobs gemäß ihrer zu erwartenden Laufzeit und der verfügbaren Anzahl an Hintergrundprozessen in geeigneter Weise zeitlich terminiert werden. In Abschnitt 2.1.2 wurde erläutert, wie durch die Zuweisung von Jobklassen und Prozessreservierungen Einfluss auf die Startreihenfolge von Jobs genommen werden kann.

Insbesondere für die Einplanung periodisch wiederkehrender Jobs ist es hilfreich zu wissen, wie häufig diese gestartet werden und wie lang ihre durchschnittliche Laufzeit sowie die bisher aufgetretene Startverzögerung sind. Gute Dienste leistet in diesem Zusammenhang der Report BTCAUX14. Im Startbild können Sie zunächst auf den zu untersuchenden Zeitraum und die währenddessen erforderliche Mindestanzahl an Starts eines Jobs eingrenzen. Zusätzlich ist eine Selektion nach Jobname möglich (siehe Abbildung 2.17).

Abbildung 2.17: Jobstatistik (Report BTCAUX14)

Die Ergebnisliste (siehe Abbildung 2.18) zeigt je Job u.a. die Wiederholungsperiode (), die durchschnittliche Joblaufzeit () und die durchschnittliche Verzögerung an ().

Abbildung 2.18: Übersicht Jobstatistik

Beachten Sie noch einmal, dass, bedingt durch die Startfrequenz des Job-Schedulers, Verzögerungen von bis zu 60 Sekunden normal sind.

Stellen Sie fest, dass die Verzögerung für einen bestimmten Job nicht tolerierbar ist, könnten Sie, sofern es überhaupt sinnvoll ist, diesen Job auf einen Zeitpunkt mit geringerer Hintergrundlast legen. Alternativ könnten Sie dafür sorgen, dass zum ursprünglich geplanten Startzeitpunkt nicht zu viele andere Jobs mit langer Laufzeit aktiv sind.

2.3.5 Fehlende Jobausführung

Bei einem Job mit periodischer Einplanung kann es vorkommen, dass dieser nicht zu allen erwarteten Zeitpunkten tatsächlich ausgeführt wurde. Betrachten wir dazu das folgende Beispiel:

Der Job DEMO_PERIODIC_15 soll alle 15 Minuten gestartet werden. Eine entsprechende Wiederholungsperiode wurde dem Job bei der Definition zugeordnet (siehe Abbildung 2.19).

Abbildung 2.19: Beispiel periodischer Job

Die Jobübersicht zeigt aber, dass der Job für den Zeitraum zwischen 15:15 Uhr und 16:30 Uhr nicht wie erwartet im 15-Minuten-Rhythmus ausgeführt wurde (siehe Abbildung 2.20).

Abbildung 2.20: Jobübersicht zu Job DEMO_PERIODIC_15

Ursache für die Verzögerung der für 15:45 Uhr geplanten Ausführung: Laut Systemlog ( Transaktion SM21) stand das System zwischen 15:40 Uhr und 16:20 Uhr nicht zur Verfügung.

Die für 15:45 Uhr () geplante Ausführung des Jobs wurde kurz nach dem Wiederanlaufen des Systems (16:20 Uhr) um 16:21 Uhr () mit einer Verzögerung von 2169 Sekunden () ausgeführt. Diese Verzögerung entspricht der Differenz zwischen geplantem Startzeitpunkt und tatsächlicher Ausführung. Wie das Job-Log allerdings zeigt, wurden die eigentlich für 16:00 Uhr und 16:15 Uhr zu erwartenden Starts nicht eingeplant, folglich wurden sie auch nicht verzögert ausgeführt. Mit dem Start des Jobs um 16:21 wurde der ursprünglich geplante Startrhythmus, beginnend mit 16:30, wiederhergestellt (siehe Abbildung 2.21).

Abbildung 2.21: Jobstart nach Systemausfall

Dieses Verhalten des Job-Schedulers ist genauso vorgesehen: Erst mit dem Vollzug eines Jobs erfolgt die Einplanung der nächsten Ausführung gemäß der gewählten Startperiode. Dies kann natürlich dazu führen, dass nicht alle notwendigen Läufe eines Jobs – wie im Beispiel oben illustriert – erfolgt sind. Wenn der Job zum Startzeitpunkt beispielsweise genau die in den zurückliegenden 15 Minuten erzeugten Daten auswerten soll, wäre das Ergebnis im beschriebenen Beispiel nicht mehr vollständig.

Ein möglicher Ausweg wäre z.B., nicht nur einen Job zur vollen Stunde und mit stündlicher Periode, sondern entsprechend viele Jobkopien (es wären 24 erforderlich!) jeweils zur vollen Stunde und mit täglicher Wiederholung einzuplanen. Bei einem mehrstündigen Systemausfall wäre in diesem Fall garantiert, dass die ausgefallenen Jobs zumindest verzögert erledigt würden.

2.4 Hilfsprogramme für die Jobverwaltung

Die SAP bietet für die Verwaltung und Analyse von Jobs eine Reihe von Reports an. Deren Name beginnt jeweils mit »BTCAUX« (siehe Tabelle 2.3).

Tabelle 2.3: Hilfsprogramme für die Jobverwaltung

Verfügbarkeit der Reports

Beachten Sie bitte, dass die SAP sukzessive weitere Reports für die Jobverwaltung entwickelt. In älteren SAP-Releases sind nicht unbedingt alle in der Tabelle aufgeführten Reports verfügbar.

Die Wirkungsweise der Reports BTCAUX09 und BTCAUX14 wurde bereits in den vorangehenden Abschnitten erläutert.

Leider sind diese Hilfsprogramme oft gar nicht oder nur rudimentär dokumentiert. Informationen zu den Reports erhalten Sie aber im SAP Support Portal, wenn Sie dort nach dem Namen des Reports suchen.

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

Sie werden schnell feststellen, dass auf einem SAP-System in kürzester Zeit eine erhebliche Anzahl von Job-Logs entsteht, bedingt durch eine Vielzahl an Jobs mit kurzen Wiederholungsperioden. Zum einen wirkt sich dies negativ auf die Performance der Transaktion SM37 aus, der Aufbau der Jobübersicht ist sehr zeitintensiv. Zum anderen sollten Sie bedenken, dass für jeden Job auch ein Protokoll geschrieben wird. Dieses Protokoll wird – je nach SAP-Release und Kernel-Stand – in Dateien auf Betriebssystemebene (Pfad: DIR_GLOAL) oder in DB-Tabellen (TBTCJOBLOG4) geschrieben.

Speicherung von Job-Logs

Nähere Informationen zur Konfiguration der Speicherung von Job-Logs liefert der SAP-Hinweis 2360818.

Eine regelmäßige Reorganisation der Job-Logs ist unbedingt zu empfehlen, um nicht mehr benötigte Protokolle vom System zu entfernen. Diese Aufgabe können Sie mithilfe des Reports RSBTCDEL2 erledigen. In den meisten SAP-Systemen läuft infolge der Einplanung der sogenannten Standardjobs täglich ein Job mit dem Namen SAP_REORG_JOBS. Dieser Job verwendet im Step den genannten Report in Verbindung mit der Variante SAP&001, die für das Löschen aller Protokolle sorgt, die älter als 14 Tage sind. Dies reicht jedoch bei Weitem nicht aus.

Eine stärkere Reduktion der sich im System anhäufenden Job-Logs können Sie etwa dadurch erreichen, dass Sie den Report RSBTCDEL2 zusätzlich mit weiteren Varianten einplanen, um insbesondere Logs von Jobs mit sehr kurzer Wiederholungsperiode schneller zu löschen. Das Selektionsbild des Reports bietet Ihnen die Möglichkeit, z.B. über den Jobnamen oder den Jobstatus geeignete Varianten zu definieren. Der Report BTCAUX14 hilft Ihnen dabei, besonders häufig gestartete Jobs zu finden (siehe Abbildung 2.18).

Eine Vielzahl an Jobs erzeugt triviale Job-Logs. Dies sind Logs, in denen lediglich der Start, die Ausführung des Steps und das Ende des Jobs vermerkt sind. Triviale Logs können daher automatisch mit dem Job-Ende gelöscht werden, indem Sie den Parameter rdisp/del_triv_joblog auf »1« setzen.

Löschen trivialer Job-Logs

Detailliertere Informationen liefert Ihnen zu diesem Thema der SAP-Hinweis 1468596. Beachten Sie unbedingt die an dieser Stelle aufgeführten Voraussetzungen!

In der Praxis fällt weiterhin auf, dass recht viele Jobs zwar keine trivialen Logs erzeugen, im Log dann aber nur eine zusätzliche Meldung steht (z.B. »Es wurden keine Sätze verarbeitet«). Solche Logs sind eigentlich irrelevant, sie können (mit etwas Programmieraufwand) in triviale Logs umgewandelt werden, indem der im Step genutzte Report angepasst wird. Kandidaten für eine solche Überarbeitung entnehmen Sie dem Report BTCAUX21.

3 Verbuchungsabbrüche

Startet ein Anwender eine Transaktion, wird diese in einem Workprozess ausgeführt, innerhalb dessen die Benutzerkennung des Anwenders bekannt ist. Kommuniziert nun dieser Workprozess zum Lesen bzw. Ändern von Datensätzen mit der Datenbank, verwenden alle SAP-Workprozesse statt dieser Benutzerkennung eine einheitliche Login-Kennung für die Datenbank. Als Konsequenz folgt daraus: Die Datenbank sieht nicht, welcher SAP-Anwender gerade aktiv ist, und sie ist auch nicht in der Lage zu erkennen, welche Datenbankoperationen zu einer Datenbanktransaktion (Datenbank-LUW) gehören. Um hier Abhilfe zu schaffen, hat die SAP die Verbuchungstechnik (Verbucher) realisiert, die im Folgenden genauer beschrieben werden soll. Anschließend werden die Werkzeuge zum Monitoring und Administrieren des Verbuchers vorgestellt.

3.1 Anforderungen an den Verbucher

Wie eingangs erwähnt, verwendet die SAP eine einheitliche Datenbankkennung für die Kommunikation aller Workprozesse mit der Datenbank. Zusätzlich wird zum Ende eines Dialogschritts vom Workprozess immer ein DB-Commit an die Datenbank geschickt. Somit ist die Datenbank nicht in der Lage, Datenbankänderungen, die über mehrere Dialogschritte hinweg von einer Anwendung angestoßen werden, als eine Einheit zu behandeln, die als Datenbank-LUW (LUW = Logical Unit of Work) bezeichnet wird. Da dies aber aus Sicht der Anwendungsentwicklung grundsätzlich notwendig ist, hat die SAP mit dem Verbucher eine Lösung geschaffen (für die technische Realisierung siehe Abschnitt 3.2).

Der Verbucher übernimmt noch weitere Aufgaben: Bricht beispielsweise ein Workprozess hart ab oder kommt es sogar zu einem Ausfall der Datenbankprozesse, werden laufende Datenbank-LUWs unterbrochen; es wird so ein zunächst nicht mehr konsistenter Zustand der Datenbank erzeugt. Jedes Datenbanksystem ist beim Wiederanlaufen in der Lage, durch einen Rollback-Mechanismus unvollständige Datenbank-LUWs komplett zurückzusetzen. Jedoch ist es mit Datenbankmitteln nicht möglich, den vom Rollback betroffenen SAP-Benutzer zu ermitteln, da dieser der Datenbank nicht bekannt ist. Die notwendige Protokollierung, welcher SAP-Anwender welche Datenbankänderungen beauftragt hat, kann stattdessen der Verbucher übernehmen.

Eine weitere Zielsetzung bei der Entwicklung des Verbuchers war, die Dialogverarbeitung zu beschleunigen. Erfasst etwa ein Anwender über eine SAP-Transaktion einen umfangreichen Beleg und sichert diesen, könnte er seine Arbeit erst fortsetzen, wenn alle zum Sichern des Beleges erforderlichen Datenbankbefehle durchgeführt worden sind. Zusätzlich wäre der betreffende SAP-Workprozess in dieser Zeit auch für andere Anwender nicht verfügbar. Dieses Problem wird vom Verbucher mithilfe der Delegation von Datenbankänderungen an spezielle Workprozesse gelöst.

Zusammengefasst soll der Verbucher also folgende Anforderungen übernehmen:

 Bündelung von Datenbankoperationen über mehrere Dialogschritte hinweg

 Informationen zu betroffenen SAP-Anwendern und Transaktionen im Falle eines Prozessabbruchs bzw. eines Wiederanlaufens der Datenbank liefern

 Verkürzung der Wartezeiten beim Sichern

3.2 Funktionsweise des Verbuchers

Grundsätzliche Voraussetzung zum Einsatz der Verbuchungstechnik ist es, dass alle ändernden Datenbankanweisungen, die eine Anwendung ausführen möchte, vom Entwickler in Funktionsbausteine ausgelagert werden. Diese Funktionsbausteine werden dann wiederum im Coding in der Form CALL FUNCTION …. IN UPDATE TASK an geeigneter Stelle aufgerufen. Der Zusatz IN UPDATE TASK bewirkt, dass die Bausteine nicht sofort ausgeführt, sondern nur für eine spätere Ausführung vorgemerkt werden. Sind im Programm alle notwendigen Vormerkungen erfolgt, kann die Ausführung der Funktionsbausteine mit der Anweisung COMMIT WORK gestartet werden. Ein eventuell im Programm abgesetztes ROLLBACK WORK würde die Vormerkungen stornieren. Die Bausteine selbst werden nicht in dem Workprozess ausgeführt, in dem die Anweisung COMMIT WORK erfolgt. Stattdessen werden die Bausteine an eigens dafür im Hintergrund aktive sogenannte Verbuchungsworkprozesse übergeben. Der eigentliche Workprozess setzt seine Verarbeitung nach dem COMMIT WORK umgehend fort und wartet nicht darauf, dass die Ausführung in den Verbuchungsworkprozessen abgeschlossen ist.

Bevor ich den genauen Ablauf einer Dialogverarbeitung mit Verbuchereinsatz beschreibe, gebe ich Ihnen zunächst einige Informationen, welche Voraussetzungen ein Funktionsbaustein erfüllen muss, um per Verbuchung ausgeführt werden zu können. Betrachten wollen wir dazu einfache Beispiele, die wir später zum Test des Verbuchungsablaufs einsetzen können.

Der Entwickler, der die Bausteine für die Verbuchungstechnik definiert, muss diese im Function Builder (Transaktion SE37) als Verbuchungsbaustein () kennzeichnen (siehe Abbildung 3.1).

Abbildung 3.1: Verbuchungsbaustein

Zudem muss er festlegen, mit welcher Priorität die Ausführung des Bausteins nach einem COMMIT WORK in einem der Verbuchungsworkprozesse erfolgen soll (). Die Auswahl legt fest, welche Nachbehandlung nach fehlerhafter Ausführung des Bausteins möglich ist (Tabelle 3.1).

Tabelle 3.1: Verbuchungspriorität

Bausteine mit der Option Start sofort werden unabhängig von ihrer Nachbuchbarkeit auch als V1-Komponenten bezeichnet, solche mit Start verzögert als V2-Komponenten und diejenigen mit Sammellauf als V3-Komponenten.

Funktionsbausteine, die zeitversetzt (asynchron) zum Aufruf mit CALL FUNCTION ... IN UPDATE TASK und außerdem in den eigens dafür vorgesehenen Verbuchungsprozessen ausgeführt werden, können keine Rückgabewerte an die Anwendung liefern, in der die Vormerkung erfolgte. Daher besitzen verbuchungsfähige Funktionsbausteine keine Export- oder Changing-Parameter.

Für die nachfolgende detaillierte Erläuterung und den anschließenden konkreten Test des Verbuchungsablaufs sollen die in Tabelle 3.2 ausgewiesenen Funktionsbausteine verwendet werden.

Tabelle 3.2: Musterbausteine für einen Verbuchungstest

Abbildung 3.2 zeigt (stark vereinfacht) das Coding einer Anwendung, die Datenbankänderungen über die in der Tabelle aufgeführten Verbuchungsbausteine durchführt.

Abbildung 3.2: Beispiel Verbuchungsauftrag (Teil 1)

Vormerkung der Verbuchungsbausteine

Mit dem Start der Anwendung beginnt eine neue Verarbeitungseinheit, die sogenannte SAP-LUW. Zunächst werden alle notwendigen Sperren gesetzt (), um konkurrierende Zugriffe auf Daten zu verhindern. Mit der ersten Verbuchungsvormerkung (CALL FUNCTION TH_VB_TEST_01) wird ein eindeutiger Schlüssel (VBKEY) für die Verbuchungseinheit gebildet und zusammen mit Informationen z.B. zur gestarteten Transaktion, dem SAP-Benutzer und dem Startzeitpunkt in die Tabelle VBHDR geschrieben (). Zusätzlich werden der Name des Funktionsbausteins in die Tabelle VBMOD () und die Übergabeparameter des Bausteins als binäre Zeichenfolge zusammengesetzt in die Tabelle VBDATA () übertragen. Beim Aufruf weiterer Verbuchungsbausteine werden die Schritte () bis () wiederholt.

Freigabe zur Verbuchung

Sind alle erforderlichen Bausteine für die Verbuchung vorgemerkt (und der Anwender führt eine Funktion wie beispielsweise »Sichern« aus), gibt die Anweisung COMMIT WORK () den Verbuchungsauftrag frei. Dabei wird die von der Anwendung gesetzte Sperre an den Verbucher vererbt; dieser ist somit der neue Sperreigentümer. Gleichzeitig beginnt mit dem COMMIT WORK eine neue SAP-LUW. Im Normalfall erhält der User nach dem COMMIT WORK von der Anwendung eine Meldung, die beispielsweise lauten könnte: »Daten wurden gesichert!« Diese Meldung ist eigentlich so nicht ganz korrekt, denn der Verbuchungsauftrag ist in diesem Moment nur zur Ausführung freigegeben.