Individuelle Entwicklungen nimmt gerne unser SAP Development Team vor
Analyse des Datenbankhauptspeichers
Hierbei lässt sich nur ein Transaktionscode sinnvoll eintragen, da ansonsten stets eine einzige Rolle gesucht werden würde, die alle gesuchten Transaktionen beinhaltet und dem entsprechenden Nutzer zugeordnet ist. Da die Transaktionen dem Nutzer jedoch auch über verschiedene Rollen zugeordnet sein können, wäre dies nicht zielführend. Bei Nutzung der o.g. Eingabevariante werden zudem lediglich Transaktionen betrachtet, die im Menü der Rolle gepflegt worden sind. Ist nicht sicher, ob die Transaktion im Menü oder im Berechtigungsobjekt S_TCODE der Rolle eingetragen wurde, können auch bis zu vier Transaktionen mittels der Suche über das genannte Berechtigungsobjekt S_TCODE überprüft werden. Wichtig ist hierbei die Beachtung und entsprechende Nutzung der UND-/ODER-Beziehung. Nach dem Ausführen der Anfrage werden nun die Rollen angezeigt, welche die angefragte Transaktion beinhalten und dem Nutzer zugeordnet sind. Bei Nutzung der Suche über das Berechtigungsobjekts S_TCODE wird folgende Ergebnisseite angezeigt. Bei Betrachtung des Ergebnisses wird neben der Beschränkung der Anzahl an Transaktionen, die eingegeben werden können, ein weiterer Nachteil dieser Variante deutlich: Zwar werden beide zugeordnete Rollen angezeigt, auf den ersten Blick ist allerdings nicht zu erkennen, welche Transaktion in welcher Rolle enthalten ist. Hierfür müssten die Rollen nochmals einzeln betrachtet werden. Sollen gleichzeitig mehr Transaktionen mit Nutzerzuordnung ermittelt und direkt die Rollenzuordnung ersichtlich werden, bietet sich die Nutzung der Transaktion SE16N an.
Aus dem Service Level Management und dem Feedback aus der kontinuierlichen Überwachung lässt sich das Optimierungspotenzial ableiten. Die Maßnahmen der Performanceoptimierung lassen sich in zwei Kategorien einteilen.
Einige nützliche Tipps aus der Praxis zum Thema SAP Basis finden Sie auch auf der Seite www.sap-corner.de.
Der Workload-Monitor
Die Last, die durch Hintergrundprogramme entsteht, ist erfahrungsgemäß zeitlich starken Schwankungen unterworfen (z. B. durch Hintergrundprogramme, die an bestimmten Tagen oder zum Monatsabschluss laufen). Dies kann dazu führen, dass es zu einem temporären CPU-Engpass auf dem Datenbankserver kommt, wenn mehrere Hintergrundprogramme gleichzeitig gestartet werden. Bei einer Verteilung der Hintergrund-Workprozesse auf die Applikationsserver können diese Lastspitzen leichter abgefangen werden.
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.
Einige fehlende Funktionen in der Basisadministration werden durch "Shortcut for SAP Systems" ergänzt.
Alle Zeiten, außer der CPU-Zeit, werden vom SAP-Workprozess gemessen, und nur die CPU-Zeit wird vom Betriebssystem ermittelt.
Um die vielen Informationen zum Thema SAP - und auch anderen - in einer Wissensdatenbank zu speichern, eignet sich Scribble Papers.
Steht zu diesem Zeitpunkt nicht ausreichend Shared Memory zur Verfügung, kann das System den Programmpuffer nicht anlegen.