SF01 Logische Dateipfade und -namen (Mandantenabhängig)
Sicherstellung des reibungslosen Betriebes der SAP-Systeme (ERP, BW) und SAP-Datenbanken
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.
Der Performancekollektor läuft periodisch und sammelt Daten zur Performance. Dieses Programm steht oft bei der Gesamtantwortzeit weit oben in der Liste der teuren Programme. Allerdings erkennt man in den Spalten S CPUZeit und S DB-Zeit, dass dieses Programm nur sehr wenig CPU- und Datenbankzeit benötigt. Die meiste Zeit wartet es im Workprozess darauf, dass ihm Performancedaten gemeldet werden.
Service Level Management
Welche Argumente sprechen nun dafür, mehr oder weniger Workprozesse zu konfigurieren? Das Argument für eine hohe Workprozess-Anzahl ist klar: Wenn Benutzer auf Workprozesse in der Queue des SAP-Dispatchers warten müssen, ist die Versuchung groß, ihnen mehr Workprozesse zur Verfügung zu stellen und dann zu hoffen, dass mehr Benutzer gleichzeitig arbeiten können. Dies ist dann der Fall, wenn Workprozesse durch Wartesituationen blockiert werden, die keine CPU-Leistung kosten, z. B. wenn Workprozesse in den PRIV-Modus gehen oder häufig durch Sperrsituationen auf der Datenbank blockiert sind. Auf der anderen Seite ist das »Aufdrehen« der Anzahl der Workprozesse fragwürdig, denn offensichtlich ist es langfristig sinnvoller, das tatsächliche Performanceproblem zu lösen, nämlich die Wartesituationen zu beseitigen. Das Hinzufügen von Workprozessen kann also nur Symptome abmildern, in der Regel das Performanceproblem jedoch nicht wirklich lösen.
Wenn die identifizierten Objekte aus dem SAP-Standard stammen, gilt: In Einzelfällen kann es notwendig sein, SAP-Standardobjekte und deren Eigenschaften (z. B. den Pufferungsstatus) zu ändern. Bevor Sie eine Änderung vornehmen, suchen Sie im SAP Support Portal nach Hinweisen mit dem Programm-, Tabellen- oder Nummernkreisnamen, die Ihnen bestätigen, ob die entsprechenden Objekte modifiziert werden dürfen. Ein derartiger Hinweis entspricht der logischen Analyse des Entwicklers. Eigenmächtige Änderungen können sowohl zu unerwarteten Performanceproblemen als auch zu logischen Inkonsistenzen führen.
Mit "Shortcut for SAP Systems" steht ein Tool zur Verfügung, das einige Aufgaben im Bereich der SAP Basis erheblich erleichtert.
Dazu gehören unter anderem die Benutzer- und die Berechtigungsverwaltung sowie die Konfigurationen von Schnittstellen über RFC.
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.
Die Berechtigung zur Steuerung der Aufrufe durch das DBACOCKPIT werden ähnlich wie in der Transaktion SE16 / SE16N gehandhabt.