Unser Werkzeugkasten …
Liegt ein Hardwareengpass auf einem Rechner vor?
In kleinen SAP-Installationen werden die Verbuchungs-Workprozesse zusammen mit Datenbankinstanz, Message- und Enqueue-Service auf einem Rechner konfiguriert. In mittelgroßen und großen SAP-Installationen sollte die Verbuchung nicht mehr zentral auf dem Datenbankserver konfiguriert werden. Es stellt sich die Frage, ob in diesem Fall ein zentraler Verbuchungsserver (also eine SAP-Instanz, die ausschließlich die Verbuchung übernimmt) eingerichtet oder die Verbuchung symmetrisch auf alle Applikationsserver verteilt werden sollte.
Diese Variante bietet sich an, wenn mehrere Transaktionen gleichzeitig auf ihre bestehende Zuordnung zu einem bestimmten Nutzer hin geprüft werden sollen. Bei dieser Variante müssen zunächst sämtliche Rollen ermittelt werden, die dem betreffenden Nutzer bereits zugeordnet wurden. Dies erfolgt in der Transaktion SE16N über Eingabe der Tabelle AGR_USERS. Außerdem lässt sich in diesem Bild die Begrenzung der maximalen Trefferzahl aufheben. Hier muss nun der betreffende Nutzer eingetragen werden. Außerdem sollte die Ausgabe lediglich auf die Rollen beschränkt werden. Nach dem Ausführen der Anfrage werden nun sämtliche Rollen, die dem vorher eingegebenen Nutzer zugeordnet sind, angezeigt. Diese werden nun komplett markiert und kopiert. Anschließend wird in der Transaktion SE16N wieder ein Schritt zurück gegangen und diesmal die Tabelle AGR_1251 gewählt. Hier werden nun sämtliche Rollen, die zuvor kopiert wurden, eingefügt. Zusätzlich wird nach dem Objekt S_TCODE und den Transaktionen, nach deren Zuordnung gesucht werden soll, gefiltert. Achtung: Bei der Eingabe der Transaktionscodes ist auf Groß- und Kleinschreibung zu achten! An dieser Stelle kann außerdem die Ausgabe auf die Rollen und Objektwerte (das sind in diesem Fall die Transaktionen) beschränkt werden. Nach dem Ausführen der Anfrage werden von den eingegebenen Transaktionen nun diejenigen angezeigt, die der Nutzer bereits ausführen kann. Zusätzlich ist ersichtlich, durch welche Rolle die Transaktion zugeordnet wurde. Abschließend ist festzustellen, dass sich die SUIM zur Ermittlung bestimmter Transaktionen mit Nutzerzuordnung nur bedingt eignet. Zwar lässt die Suche über das Berechtigungsobjekt S_TCODE auch die Betrachtung mehrerer Transaktionen zu. Da im Ergebnis allerdings die Zuordnung von betrachteten Transaktionen zu Rollen fehlt, lässt sich die Transaktion SUIM nur dafür sinnvoll nutzen, eine einzige Transaktion auf ihre bestehende Zuordnung zu einem bestimmten Nutzer hin zu überprüfen.
OAC2 Dokumentarten ändern
Gerade nach Sicherheitsvorfällen kann es notwendig sein herauszufinden, welche (technischen) User sich zu welchem Zeitpunkt eingeloggt haben. Einen ersten Einstiegspunkt bietet dafür die Tabelle USR02. In der Spalte TRDAT können Sie für den gewünschten User das letzte Anmeldedatum finden. Eine Historie über die vorherigen Anmeldungen ist in dieser Tabelle jedoch nicht zu finden. In solchen Fällen hilft der Security Auditlog oder kurz SAL. Vorbereitung Damit Sie auf die gewünschten Daten zugreifen können, müssen diese zuvor auch gespeichert worden sein. Im Security Auditlog können Sie über verschiedene Filter bestimmen, für welche User auf welchen Mandanten welche Informationen geloggt werden. Der Security Auditlog speichert, je nach Konfiguration, Anmeldungen, RFC-Aufrufe und weitere Aktionen für bestimmte User. Diese Einstellungen können Sie in der Transaktion SM19 vornehmen. Hinweis: Das Loggen von Useraktivitäten muss den betroffenen Usern bewusst sein! Konfigurieren Sie die SAL daher nur für technische User oder in Absprache mit Usern / Betriebsrat / etc. Es lässt sich dort ua einsehen, wann der SAL aktiviert und zuletzt bearbeitet wurde (1). Sie können hier außerdem die verschiedenen Filter auswählen (2), die Filter einzeln aktivieren (3), Mandanten und Benutzer bestimmen (4) sowie festlegen, welche Aktivitäten geloggt werden (5). Statische Konfiguration in der SM19 Unter der Dynamischen Konfiguration lässt sich außerdem einsehen, ob SAL aktuell für das System aktiv ist. Status des SAL ermitteln Auswertung des SAL Wenn der Security Auditlog aktiv ist, wechseln Sie in die SM20 Auswertung des Security Auditlog. Wählen sie die gewünschten User und den Mandanten aus sowie das passende Zeitfenster. Für die Anmeldungen reicht die Option Dialoganmeldungen aus. Starten Sie anschließend die Analyse über AuditLog neu einlesen. Auswertung starten Sie erhalten eine Übersicht der Anmeldungen des Users an den gewählten Mandanten des Systems.
Eine große Zahl von SAP-Workprozessen erlaubt es, dass viele Benutzeraufträge zur gleichen Zeit bearbeitet werden. Ist die Anzahl der Prozesse, die Sie gleichzeitig abarbeiten wollen, deutlich größer als die Anzahl der Prozessoren, kommt es zu Wartesituationen in der Queue des Betriebssystems. Da die Workprozesse von der CPU gleichzeitig (d. h. in Zeitscheiben) bearbeitet werden, erhöht sich mit der Anzahl der Prozesse auch die Anzahl der Kontextwechsel auf Betriebssystemebene. Achtung: Gemeint ist hier mit Kontextwechseln auf der Betriebssystemebene das Hin- und Herschalten der Prozessoren zwischen den SAP-Workprozessen. Verwechseln Sie dies nicht mit den SAP-Kontextwechseln, d. h. dem Roll-in und Roll-out der Benutzerkontexte zwischen den SAP-Workprozessen. Jeder Kontextwechsel ist mit einem zusätzlichen Aufwand für das Betriebssystem verbunden. Das Warten auf eine freie CPU beansprucht somit die knappen CPU-Ressourcen zusätzlich. Das Warten in der SAP-Dispatcher-Queue kostet dagegen keine CPU-Ressourcen.
Tools wie "Shortcut for SAP Systems" ergänzen fehlende Funktionen im Bereich der SAP Basis.
Die Auswertung der statistischen Einzelsätze ermöglicht es Ihnen, einzugrenzen, in welchen Bereichen Performanceprobleme bei einzelnen Programmen auftreten: Probleme durch ineffiziente Tabellenpufferung / Probleme durch teure SQL-Anweisungen / Probleme durch hohen CPU-Verbrauch von ABAP-Anweisungen.
Neue Anfragen werden strikt nach dem Prinzip der Priorität bearbeitet.