Performance-Trace
Grundlagen der Workload-Analyse und der Laufzeitanalyse
SAP Basis ist als klassisches Drei-Schichten-Modell aufgebaut. Es enthält die folgenden Komponenten: Datenbankschicht (relationales Datenbank-Management-System) / Applikationsschicht (Applikationsserver und Message-Server) / Präsentationsschicht (grafische Benutzeroberfläche).
Ergänzend ist für alle o. g. Managed Services zu sagen, dass die Supportlevel und deren Umfang meist kundenindividuell festgelegt werden, je nachdem welchen Grad an Mitwirkung sich der Kunde wünscht. Üblich ist eine Einteilung von Supportlevel 1-3 (gelegentlich werden auch 4 genannt).
Rezertifizierung leicht gemacht mit EasyReCert
Der SAP Paging Memory besteht analog zum Roll-Bereich aus einem Speicherbereich im Shared Memory des Applikationsservers (dem SAP-Paging-Puffer) und einer SAP-Paging-Datei auf einer Festplatte des Applikationsservers. Die Größe des SAP Paging Memorys und des SAP-Paging-Puffers wird durch die SAP-Profilparameter rdisp/PG_MAXFS und rdisp/PG_SHM eingestellt. Der SAP Paging Memory ist im Vergleich zu anderen Speicherbereichen weniger performancekritisch. rdisp/PG_MAXFS sollte allerdings ausreichend groß gewählt werden, um Programmabbrüche mit den Fehlern TSV_TNEW_PG_CREATE_FAILED oder SYSTEM_NO_MORE_PAGING zu verhindern. Der vorgeschlagene Wert von 32.000 (entsprechend 256 MB) sollte für alle normalen Anforderungen ausreichen. Steht der SAP-Profilparameter auf 32.000 und kommt es trotzdem zu Abbrüchen, liegt mit hoher Wahrscheinlichkeit ein Fehler im Programm vor (siehe entsprechende Hinweise im SAP Support Portal).
Das Verständnis für die Struktur und Funktionsweise des Systems ist insbesondere für die IT-Administration wichtig. Nicht umsonst ist „SAP Basis Administrator“ ein eigenes Berufsfeld. Auf der Seite www.sap-corner.de finden Sie nützliche Informationen zu diesem Thema.
Bei Windows-Betriebssystemen wird nur ein Teil des SAP Extended Memorys vom Workprozess adressiert. Dieser Teil wird durch den Parameter em/address_space_MB konfiguriert. Diese Implementierung hat den Vorteil, dass der gesamte SAP Extended Memory damit größer sein kann als der Adressraum des Workprozesses. Die gesamte Größe des SAP Extended Memorys wird also nur durch die Größe des Auslagerungsspeichers begrenzt. Beachten Sie, dass jeder Workprozess im Prinzip auf alle Objekte, die im SAP Extended Memory abgelegt werden, zugreifen kann, während eines Transaktionsschrittes jedoch nur auf einen Bereich der Größe em/address_space_MB. Der Parameter em/address_space_MB muss so groß konfiguriert sein, dass er die maximale Größe eines Benutzerkontextes (insbesondere ztta/roll_extension*) und den SAP EG Memory umfassen kann. Die Windows-spezifische Implementierung des SAP Memory Managements wird über den Systemparameter es/implementation eingestellt, der bei Windows auf dem Wert view steht und der nicht verändert werden darf. Der SAP Heap Memory ist unter Windows weniger wichtig, da Nicht-DialogWorkprozesse ebenso wie Dialog-Workprozesse zunächst SAP Extended Memory allokieren und diesen »unbegrenzt« zur Verfügung steht. Die SAPProfilparameter abap/heap_area* sind daher überflüssig.
Einige fehlende SAP Basis Funktionen im Standard werden durch die PC-Anwendung "Shortcut for SAP Systems" nachgeliefert.
Folgende Punkte sollten Sie beachten: Sind auf jeder SAP-Instanz ausreichend freie (Status: wartet) Workprozesse jeden Typs vorhanden? Gibt es Programme, die einen Workprozess sehr lange belegen (Feld Dauer)? In diesem Fall sollten Sie die Benutzer auf dieses Programm ansprechen und klären, ob das Programm fehlerfrei arbeitet.
Um die vielen Informationen zum Thema SAP - und auch anderen - in einer Wissensdatenbank zu speichern, eignet sich Scribble Papers.
Beachten Sie, dass es sich auch hier nur um Erfahrungswerte handelt, die in speziellen SAP-Lösungen abweichen können.