Trace auf entfernten Systemen
Spezielles Performanceproblem analysieren
Wenn zwei Benutzer in einem Zeitraum jeweils 100 Transaktionsschritte Last ausgeführt haben, sind beide gleich aktiv gewesen. Das bedeutet aber noch nicht, dass sie beide die gleiche Last auf dem System erzeugt haben. Wenn z. B. der erste Benutzer Finanzbelege eingegeben hat und 100 Transaktionsschritte mit einer mittleren Antwortzeit von 500ms ausgeführt hat, hat er das System 50 Sekunden lang belastet. Ein zweiter Benutzer hat z. B. Controlling-Berichte erstellt und für seine Arbeit 100 Transaktionsschritte mit einer mittleren Antwortzeit von 5 Sekunden benötigt, also das System 500 Sekunden lang in Anspruch genommen. Offensichtlich hat der zweite Benutzer bei gleicher Aktivität eine zehnfach größere Last erzeugt. Wie man an diesem Beispiel erkennt, ist also das Produkt aus der Anzahl der Transaktionsschritte und der mittleren Antwortzeit ein Maß für die erzeugte Last. (Will man exakt sein, muss man von der Antwortzeit die Dispatcher-Wartezeit und die Roll-Wartezeit abziehen, denn während der Auftrag in der Dispatcher-Queue bzw. auf die Ausführung eines RFCs wartet, verursacht er keine Last auf dem System.) Die Belastung, die die unterschiedlichen Task-Typen auf der Datenbank erzeugen, lässt sich analog anhand der gesamten Datenbankzeit (Transaktionsschritte mal mittlere Datenbankzeit) vergleichen. Ebenso erfolgt der Vergleich der CPU-Belastung auf dem Applikationsserver. Die Verteilung der Zeiten (Datenbankzeit, CPU-Zeit etc.) spiegelt also die Lastverteilung auf dem System besser wider als die bloße Anzahl der Transaktionsschritte.
Um Statistiken und Traces zielgerichtet für eine Webtransaktion einzuschalten, bietet der End-to-End-Trace im SAP Solution Manager die geeignete Lösung. Dabei werden u. a. die bisher beschriebenen Traces sowie weitere Traces des Frontends zielgerichtet eingeschaltet und zentral ausgewertet. Zielgerichtet heißt an dieser Stelle, dass die Information, dass Statistiken und Traces geschrieben werden sollen, über die unterschiedlichen Komponenten des SAP NetWeaver AS und auch zwischen unterschiedlichen SAP-Systemen weitergereicht werden, sodass in der Tat auf allen beteiligten Komponenten Analysedaten gesammelt werden – und zwar exakt die Anfragen, die der überwachte Webbrowser sendet.
Notfallbenutzerkonzept in SAP - Funktionsweise und Vorgehen
Wenn die mittleren Datenbankzeiten (Mittlere DB-Zeit) für die verschiedenen Rechner sehr unterschiedlich sind, ist dies ein Indiz für ein Netzwerkproblem: Denn bei symmetrisch konfigurierten Applikationsservern und unter der Voraussetzung, dass die Benutzer auf den Applikationsservern im Mittel die gleichen Transaktionen ausführen, ist nicht einzusehen, warum die Datenbank den einen Applikationsserver langsamer bedienen sollte als den anderen, es sei denn, es besteht ein Problem beim Netzwerktransfer. Diese Analyse gilt natürlich nur für symmetrisch benutzte Rechner. Bei Hintergrund- oder Verbuchungsservern oder bei Servern, auf denen hauptsächlich Reporting läuft, wird die mittlere Datenbankzeit natürlich höher liegen als bei Dialogservern.
Um die Laufzeitanalyse durchführen zu können, benötigt das System die SAP-Profilparameter abap/atrapath und abap/atrasizequota. Diese Parameter werden bei der Installation des Systems gesetzt. Der Profilparameter abap/atrapath gibt an, in welches Verzeichnis die Trace-Dateien geschrieben werden. Die maximale Größe aller ABAP-Trace-Dateien wird über den Parameter abap/atrasizequota begrenzt. Nach 30 Tagen werden die Trace-Dateien gelöscht, sofern Sie das Löschdatum nicht ändern (Registerkarte Auswerten).
Einige fehlende SAP Basis Funktionen im Standard werden durch die PC-Anwendung "Shortcut for SAP Systems" nachgeliefert.
Einige nützliche Tipps aus der Praxis zum Thema SAP Basis finden Sie auch auf der Seite www.sap-corner.de.
Der ABAP-Teil der Workload-Analyse im SAP Solution Manager greift auf die Funktionen zurück, die auch sonst im AS ABAP zur Verfügung stehen.
Dieses Tool verfügt über die folgenden verschiedenen Funktionalitäten.