Report RSMEMORY
SE95 Modification Browser
Richtzeiten für einen optimalen Array-Fetch liegen bei unter 10 ms pro selektiertem Satz. Die konkrete Laufzeit ist allerdings stark von der WHEREBedingung, dem verwendeten Index und der Art und Weise abhängig, wie effektiv die Daten gespeichert sind.
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.
Ein neues SAP-System entsteht…
Für die Performanceoptimierung ist allerdings wichtig zu verstehen, auf welcher Technologie die zu optimierenden Anwendungen betrieben werden. Die beiden folgenden Abbildungen (Abbildung 1.2 und Abbildung 1.3) stellen die traditionelle und die zukünftige Technologieplattform der SAP schematisch dar. Bei Markteinführung von SAP R/3 baute die SAP-Software auf einer einzi- SAP NetWeaver gen Technologiekomponente – der SAP-Basis – auf. Die SAP Business Suite ist dagegen auf einer Reihe von Technologiekomponenten implementiert, die Abbildung 1.2 im Einzelnen zeigt.
Das Verbuchungs-Dispatching ist die Standardlösung für praktisch alle Anwendungen. Nur in Spezialfällen (und nur auf ausdrückliche Empfehlung der SAP hin) sollten Sie von den Methoden der lokalen Verbuchung oder dem Verbuchungs-Multiplexing Gebrauch machen.
Basisadministratoren steht mit "Shortcut for SAP Systems" eine PC-Anwendung zur Verfügung, die etliche Tätigkeiten in der SAP Basis vereinfacht bzw. ermöglicht.
SAP-Basis bezieht sich auf die Verwaltung des SAP-Systems, die Aktivitäten wie Installation und Konfiguration, Lastausgleich und Leistung von SAP-Anwendungen, die auf dem Java-Stack und SAP ABAP laufen, umfasst. Dazu gehört auch die Wartung verschiedener Dienste in Bezug auf Datenbank, Betriebssystem, Anwendungs- und Webserver in der SAP-Systemlandschaft sowie das Stoppen und Starten des Systems. Hier finden Sie einige nützliche Informationen zu dem Thema SAP Basis: www.sap-corner.de.
Um die Enterprise Search (auch Embedded Search) in diesem Fall nutzen zu können, benötigen Sie das TREX-Admin-Tool.
Gemeinsames Überwachungswerkzeug CCMS (Computing Centre Management System) zur Überwachung von Alerts des R/3-Systems von einem Ort aus.