Extended Memory
Aufgaben und Tätigkeiten
Dazu wird eine maximale Bearbeitungszeit festgelegt, die wiederum von der Wichtigkeit der Transaktion für den Geschäftsbetrieb abhängen kann. Als Richtwert nehmen wir 8 Stunden Arbeitszeit (d. h. Zeit innerhalb der Betriebszeit A) für geschäftskritische Transaktionen an. Schließlich wird festgelegt, dass die Anzahl der abgebrochenen Verbuchungen pro Zeitraum im Service Level Report festgehalten werden soll.
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.
Wann ist eine Sperre kritisch?
Auf der obersten Stufe steht der Sitzungskontext (Session Context). Ein neuer Sitzungskontext wird geöffnet, wenn Sie sich an einem SAP-System anmelden. Mehrfachanmeldungen sind möglich, diese können aber über einen Profilparameter unterbunden werden. Diese öffnen dann je einen Speicherkontext. Auch ein Remote-Function-Call-(RFC-)Aufruf auf einem entfernten System öffnet einen neuen Sitzungskontext.
Daher können auch kritische Berechtigungen, Profile und Rollen bestehen, die nicht in das von SAP definierte Namensschema passen. Manuell ist die Identifikation kritischer SAP Berechtigungen insgesamt schwierig. Es sind jedoch Werkzeuge verfügbar, die automatisiert auf kritische Berechtigungen prüfen. Dabei sind die kritischen SAP Berechtigungen in der Regel durch spezielle Prüfsoftware vordefiniert. Sind die kritischen Berechtigungen, Profile und Rollen identifiziert, so sollten diese gemäß der Berechtigungsplanung angepasst werden. Im Anschluss ist zu prüfen, ob das gewünschte Systemverhalten erreicht wurde oder ob es zu Fehlfunktionen kommt. Dieser Anpassungsprozess kann bei stärkeren Veränderungen unter Umständen aufwendig sein und sollte nicht am Produktivsystem durchgeführt werden.
Verwenden Sie "Shortcut for SAP Systems", um viele Aufgaben in der SAP Basis einfacher und schneller zu erledigen.
Im 1st-Level-Support wird eine Anfrage angenommen.
Diese Daten müssen anschließend von der Festplatte nachgelesen werden.