User- und Security-Management
SAP Jobsteuerung
Der CodeProfiler verhindert, dass qualitativ schlechter Code oder Programme mit Sicherheitslücken überhaupt in eine produktive SAP-Systemlandschaft gelangen. Deshalb ist es wichtig, den CodeProfiler über den gesamten Lebenszyklus einer Software einzusetzen. Bereits bei der Programmierung hilft der CodeProfiler dem Entwickler bei der Identifikation und Korrektur von Fehlern und Schwachstellen in der SAP-Landschaft. Der CodeProfiler sorgt automatisch dafür, dass nur „sauberer“ Code in das jeweils nächste Level (Entwicklungssystem -> Testsystem -> Qualitätssicherungssystem -> Produktivsystem) transportiert wird. Dabei kann der CodeProfiler auch für regelmäßige Review-Zyklen eingesetzt werden.
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.
Systemänderbarkeit und Mandantensteuerung in einem SAP-System
SAP stellt Support Packages bereit: im SAPNet - R/3 Frontend im SAPNet - Web Frontend auf Collection-CDs Voraussetzungen Das Change and Transport System ist korrekt eingerichtet. Es ist genügend Platz im Transportverzeichnis (UNIX: /usr/sap/trans) vorhanden. Sie müssen die nötigen Berechtigungen [Seite 7] für den SAP Patch Manager haben. Sie müssen im Mandanten 000 angemeldet sein. Sie müssen die Transaktion SPAM aufgerufen haben. Sie verwenden die neueste SPAM-Version. Vorgehensweise Support Packages aus dem SAPNet - R/3 Frontend laden Pflegen Sie vor dem Laden eines Support Package aus dem SAPNet - R/3 Frontend die Netzwerkparameter für die Anmeldung beim SAPNet - R/3 Frontend. Verwenden Sie dazu Transaktion OSSFordern Sie die gewünschten Support Packages im SAPNet - R/3 Frontend an. Laden Sie die angeforderten Support Packages vom SAPNet - R/3 Frontend in Ihr SAPSystem mit Support Package Herunterladen. Eine Liste von Support Packages wird angezeigt. Vor dem Laden können Sie die gewünschten Support Packages auswählen. Die Größe der unkomprimierten Support Packages wird in Byte angezeigt. Mit der Größe des Support Package können Sie die Zeit für das Laden abschätzen. Kontrollieren Sie mit der Statusanzeige, ob das Laden erfolgreich war. Um zum SPAM-Einstiegsbild zurückzukehren, wählen Sie Springen Zurück. Definieren Sie die Queue (Seite 17).
Die Sprache ist eine Quelle für Missverständnisse – dies gilt in extremem Maße für den Bereich der SAP-Speicherverwaltung: So werden dieselben Begriffe auf der Ebene des Betriebssystems und auf der Ebene des SAP-Systems für unterschiedliche Dinge verwendet: Wir unterscheiden Betriebssystem-Paging und SAP-Paging, Kontextwechsel auf Betriebssystemebene und Kontextwechsel auf SAP-Ebene etc. Auch der Begriff »Heap« wird doppelt verwendet: Auf Betriebssystemebene ist damit der lokale Speicher gemeint, der von einem Betriebssystemprozess allokiert wird. Auf SAP-Ebene bezeichnet er dagegen einen speziellen lokalen Speicherbereich, d. h., der SAP Heap Memory ist nur ein Teilbereich dessen, was auf Betriebssystemebene als »Heap« bezeichnet wird. Um die Verwirrung in Grenzen zu halten, kennzeichnen wir hier die SAP-Begriffe explizit mit dem Präfix SAP, wie z. B. SAP Heap Memory oder SAP Paging Memory, um sie von den Betriebssystembegriffen abzugrenzen. Wenn Sie Sekundärliteratur oder Hinweise im SAP Support Portal lesen, vergewissern Sie sich anhand des Kontextes, ob sich der Autor auf den SAP-Systembegriff oder den Betriebssystembegriff bezieht.
Etliche Aufgaben im Bereich der SAP Basis können mit "Shortcut for SAP Systems" wesentlich erleichtert werden.
Um die Workprozess-Übersicht für den aktuellen Applikationsserver aufzurufen (lokale Workprozess-Übersicht), wählen Sie: Werkzeuge > Administration > Monitor > Systemüberwachung > Prozessübersicht.
Im Anschluss werden die folgenden Ordner auf dem System komplett gelöscht: C:\Program Files (x86)\Common Files\SAP Shared\BW löschen C:\Program Files (x86)\SAP löschen C:\Program Files\SAP löschen Damit ist die Phase des CleanUps abgeschlossen.