SAP Solution Manager zur Analyse
Umzug Ihres SAP-Systems
Sind für die Bearbeitung einer Benutzeranfrage Daten notwendig, die sich Datenbanktuning noch nicht im Hauptspeicher des Applikationsservers befinden, werden diese vom Datenbankserver gelesen. Beim Tuning der Datenbank unterscheidet man drei Bereiche. Zunächst einmal ist dies die richtige Einstellung der Datenbankpuffer und anderer Datenbankparameter. Der zweite Bereich ist die Optimierung des Festplattenlayouts der Datenbank, um die Last möglichst gleichmäßig auf die Festplatten zu verteilen und so Wartesituationen beim Schreiben auf die Festplatte bzw. beim Lesen von der Festplatte zu vermeiden. Der dritte Aspekt beim Datenbanktuning ist die Optimierung langlaufender, »teurer« SQL-Anweisungen.
Um eine optimale Performance zu erreichen, sollte das Kopieren der Daten beim Kontextwechsel auf ein Minimum beschränkt bleiben, mit anderen Worten, es soll möglichst wenig SAP Roll Memory benutzt werden. Daher wird für alle Betriebssysteme empfohlen, ztta/roll_first = 1 zu setzen. Was passiert nun, wenn der SAP Extended Memory voll belegt ist? In diesem Fall sind zwei Szenarien möglich, die beide nicht performanceoptimal sind: Da der SAP Extended Memory voll belegt ist, werden Benutzerkontexte bis zu einer Größe von ztta/roll_area im lokalen Roll-Bereich abgelegt. Bei jedem Kontextwechsel müssen damit unter Umständen mehrmals Daten in der Größe von mehreren Megabyte kopiert (gerollt) werden; dies führt typischerweise zu Wartesituationen in der Roll-Verwaltung, insbesondere wenn der Roll-Puffer voll ist und Daten in die Roll-Datei geschrieben werden müssen. Erfahrungen zeigen, dass bei großen Applikationsservern mit mehr als 100 Benutzern die Performance in diesen Fällen schlagartig und drastisch einbricht. Um in dieser Situation Abhilfe zu schaffen, kann man den lokalen RollBereich (ztta/roll_area) reduzieren. Wenn der SAP Extended Memory voll belegt ist, wird nur noch wenig Roll Memory verwendet, und die Menge der beim Kontextwechsel zu kopierenden Daten reduziert sich. Stattdessen werden die Kontextdaten im SAP Heap Memory abgelegt – dies hat zur Folge, dass die Workprozesse gar nicht mehr rollen, sondern in den PRIV-Modus gehen, d. h. einem Benutzer zwischen den Transaktionsschritten exklusiv zugeordnet bleiben. Befinden sich zu viele Workprozesse gleichzeitig im PRIV-Modus, stehen dem Dispatcher nicht genügend freie Workprozesse zur Verfügung. Es kann daher zu hohen Dispatcher-Wartezeiten und damit ebenfalls zum Einbruch der Performance kommen.
Dynamische Verteilung der Dialogbenutzer
Ein erster wichtiger Schritt war die Einführung von Playbooks, um unsere Arbeit zu professionalisieren. Damals waren SAP-Installationshandbücher echte Wälzer mit hunderten von Seiten, die sich oft im Kreis drehten und alles andere als leicht verständlich waren.
Die Webseite www.sap-corner.de bietet viele nützliche Informationen zum Thema SAP Basis.
So viele Informationen... wie kann man die aufheben, so dass man sie bei Bedarf wiederfindet? Dafür eignet sich Scribble Papers ganz hervorragend.
Jedes SAP-Basis System muss von einem Administrator kontrolliert und gesteuert werden. Der Verantwortliche sorgt für einen reibungslosen Betrieb des Systems. Dies kann ein interner Administrator sein, oder an externe Dienstleister abgegeben werden.
Etliche Aufgaben im Bereich der SAP Basis können mit "Shortcut for SAP Systems" wesentlich erleichtert werden.
Sofern Sie dies organisiert haben, rufen Sie im 000-Mandanten die Transaktion SE06 auf und klicken Sie auf den Button "Systemänderbarkeit".
Zum lokalen Speicher eines SAP-Workprozesses gehören z. B. der SAP Cursor Cache und der Eingabe-/Ausgabe-Puffer für die Übertragung der Daten von der bzw. zu der Datenbank.