Spool Admin
Transaktionscode /$GUI_E2E_TRACE
Grundlagen des Sizings sind detaillierte Erfahrungswerte über den Ressourcenbedarf von Benutzern und Transaktionen. Diese Erfahrungswerte veralten schnell angesichts neuer Applikations- und Rechnergenerationen, daher fokussieren wir uns in diesem Kapitel auf die Prozesse und Werkzeuge. Bei einem Sizing-Projekt sind mehrere Parteien im Boot: Das Kundenprojekt stellt das Mengengerüst, sprich die Anforderungen an konkurrierende Benutzer, Durchsatz bestimmter Transaktionen und erwartetes Datenvolumen, zusammen. Die Experten des Hardwarepartners erstellen ein Hardwareangebot – wenn nötig, unter Rückgriff auf Experten der SAP. Schließlich benötigen Sie als Projektleiter oder -mitarbeiter das Wissen über den prinzipiellen Sizing-Prozess, um unterschiedliche Sizing-Angebote und Aussagen kompetent vergleichen und bewerten zu können, die Möglichkeiten, Risiken und Grenzen einer Sizing-Aussage zu verstehen und schließlich eine fundierte Entscheidung zwischen den Hardwareangeboten zu treffen.
Bei der Verwendung des Webbrowsers als GUI sollten Sie bei der Programmierung darauf achten, dass möglichst wenige Daten zwischen Präsentations- und Internetebene übertragen werden. Die Gefahr, dass durch die Generierung aufwendiger HTML-Seiten lange Netzwerklaufzeiten den Benutzer beeinträchtigen, ist deutlich größer als bei der Verwendung des klassischen SAP GUIs (das das SAP-eigene DIAG-Protokoll verwendet). Das Tuningpotenzial hängt stark vom verwendeten Programmiermodell ab. Wird die Internetebene als reine »Übersetzungsebene« zwischen Präsentations- und Applikationsebene verwendet (wie etwa beim SAP GUI for HTML), beschränkt sich das Optimierungspotenzial auf die Konfiguration. Je mehr Logik in die Internetebene verlagert wird (z. B. Feldprüfungen etc.), desto höher ist auch die Notwendigkeit der Programmanalyse auf der Internetebene.
Funktionsweise Java-Statistiken
Die Größe des beim Start der SAP-Instanz allokierten SAP Extended Memorys wird durch den SAP-Profilparameter em/initial_size_MB festgelegt. Intern ist der SAP Extended Memory in Blöcke der Größe em/blocksize_KB aufgeteilt. Die Blockgröße beträgt standardmäßig 4.096 kB. Der SAP-Profilparameter ztta/roll_extension legt die maximale Größe eines Benutzerkontextes im SAP Extended Memory fest. Diese Quote verhindert, dass ein einzelner Benutzer mit einer sehr speicherintensiven Transaktion den gesamten SAP Extended Memory belegt und keinen Speicher für die anderen Benutzer übrig lässt. Mit Basisversion 7.40 haben Sie die Möglichkeit, mit den Parametern ztta/roll_extension_dia und ztta/roll_extension_nondia die Quoten für Dialog- und NichtDialog-Workprozesse zu übersteuern. ztta/roll_extension zieht, wenn diese nicht gesetzt sind.
Site Reliability Engineering(SRE) ist in der Google-Welt das Äquivalent zur SAP Basis. Ben Treynor, der seit 2003 für Google tätig ist und als Pate von SRE gilt, beschreibt SRE als das „was passiert, wenn man einem Software Engineer Operations-Aufgaben überlasst“.
Einige fehlende Funktionen in der Basisadministration werden durch "Shortcut for SAP Systems" ergänzt.
Grundlage aller Empfehlungen ist die Annahme, dass ausreichend Auslagerungsspeicher (etwa drei- bis viermal RAM, mindestens aber 3,5 GB) zur Verfügung steht.
Die SAP-Basis ist das Fundament eines jeden SAP-Systems. Viele nützliche Informationen dazu finden Sie auf dieser Seite: www.sap-corner.de.
Die SAP SE bietet verschiedene Trainings und Zertifizierungen für SAP Basis-Administratoren und SAP Basis-Berater an.