Die Statistiken des ABAP-Servers
Online, Offline, Delta Backups
Im Hauptspeicherkonfigurationsmonitor (Transaktionscode ST02) finden Sie eine Auflistung aller Speicherbereiche, die vom ABAP-Server allokiert werden – inklusive der Nutzungshistorien. Als Faustregel können Sie ein Drittel abziehen, da eine mäßige Überallokation durch den ABAP-Server in der Regel unkritisch ist. Diese Analyse ist zum einen nützlich als Konsistenzcheck zu den Daten, die der Betriebssystemmonitor liefert. Dazu addieren Sie die Hauptspeicherbedarfe und vergleichen das Ergebnis mit den Werten, die Sie auf dem Betriebssystem ermitteln. Weichen die Werte stark voneinander ab, müssen Sie analysieren, ob es Prozesse gibt, die nicht direkt zum SAP-System gehören. Zum anderen können Sie z. B. auf einem Datenbankserver ermitteln, wie viel Hauptspeicher die Datenbankinstanz und wie viel die SAPInstanz benötigt.
Was den Einsatz von Avantra so interessant macht, ist der Wegfall von manuellen Aufwänden. Dadurch entstehen Freiräume, die SAP-Technologieteams den Aufbau neuer Kompetenzen erlauben.
REIHENFOLGE DER OPTIMIERUNG EINHALTEN
Die Aufgaben der Performanceüberwachung und -optimierung werden von sehr unterschiedlichen Personen übernommen. Mitarbeiter, die die Fehlerüberwachung durchführen und das Service Level Reporting erstellen, verfügen in der Regel über ein solides Grundverständnis der Technologie und der Anwendung, meistens aber nicht über Spezialkenntnisse. Diese Forderung ergibt sich aus der Tatsache, dass eine Systemüberwachung 7 × 24 Stunden aufrechterhalten werden muss und für diese Aufgabe nicht Spezialisten aus allen Bereichen verfügbar sein können. Im Rahmen der Überwachung oder der Erstellung des Service Level Reportings muss ein Help-Desk-Mitarbeiter oder Manager in der Lage sein zu entscheiden, ob er einen Spezialisten hinzuziehen muss. Mit anderen Worten: Man darf keinen Datenbankexperten benötigen, um zu entscheiden, ob man einen Datenbankexperten benötigt.
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.
Für Administratoren steht im Bereich der SAP Basis ein nützliches Produkt - "Shortcut for SAP Systems" - zur Verfügung.
Beim Ausführen des ABAP-Trace stehen Ihnen Varianten zur Verfügung, mit denen Sie die Aufzeichnung des Trace einstellen können.
Einige nützliche Tipps aus der Praxis zum Thema SAP Basis finden Sie auch auf der Seite www.sap-corner.de.
Wenn Sie die Funktionalitäten von Open SQL und Open CDS ausreizen, müssen Sie (mit realistischen Datenmengen) vermessen, ob die gewünschte Performance erreicht wird.