Detailanalyse im RFC-Trace
Queue definieren
Unsere Erfahrung zeigt, dass falsche Sizings und daraus resultierende Streitfälle in der Mehrzahl der Fälle auf unpräzisen Prognosen über die erwartete Anzahl von Benutzern und Dokumenten beruhen. Die Verantwortung für die Qualität dieser Prognosen zu übernehmen ist die wichtigste Aufgabe des Projektleiters im Sizing-Prozess. Beratend steht ihm dabei der Experte des Hardwarepartners zur Seite.
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.
Einplanung von Hintergrund-Jobs, Job-Überwachung, Job-Löschung, etc
Es ist von großer Wichtigkeit, das Wissen von SAP Basis Experten im Unternehmen transparent zu halten. Eine Möglichkeit ist natürlich das “über die Schulter schauen” oder den Experten direkt zu fragen. Das ist jedoch sehr zeitintensiv und beansprucht den Experten auch selber.
Nachdem Sie die Methoden der Lastverteilung und des Hardware-Sizings kennengelernt haben, beschäftigen wir uns abschließend mit der Frage, wie viele Systeme, Datenbanken, Applikationsinstanzen und Server man benötigt, um die anfallende Last zu bewältigen. Insbesondere bei der Einführung der SAP Business Suite stehen die Projektteams vor der anspruchsvollen Aufgabe, den Aufwand für die Wartung und Administration von Hardware, Datenbanken, SAP-Instanzen und weiterer Software nicht explodieren zu lassen. Vor diesem Hintergrund wird in vielen Projekten eine Konsolidierung angestrebt, d. h. eine Reduzierung der Softwareinstanzen auf wenige leistungsfähige Rechner. Hardwarepartner unterstützen dies durch innovative Technologie- und Vermarktungskonzepte.
"Shortcut for SAP Systems" ist eine PC-Anwendung, mit der viele Tätigkeiten in der SAP Basis vereinfacht bzw. auch überhaupt erst ermöglicht werden.
Diesem Thema ist Kapitel 12, »SAP-Pufferung«, gewidmet.
Sie können sich diese Aufträge mit dem folgenden tp-Kommando anzeigen lassen: tp SHOWBUFFER -D SOURCESYSTEMS= TAG=SPAM Sie können die Bearbeitung der Queue erst fortsetzen, wenn diese Aufträge vollständig abgearbeitet bzw. aus dem tp-Puffer gelöscht wurden.