VERÄNDERUNG DER WAHRNEHMUNG
SUGR Benutzergruppen pflegen
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.
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.
Beispiele für Benchmarks
In kleinen SAP-Installationen werden die Verbuchungs-Workprozesse zusammen mit Datenbankinstanz, Message- und Enqueue-Service auf einem Rechner konfiguriert. In mittelgroßen und großen SAP-Installationen sollte die Verbuchung nicht mehr zentral auf dem Datenbankserver konfiguriert werden. Es stellt sich die Frage, ob in diesem Fall ein zentraler Verbuchungsserver (also eine SAP-Instanz, die ausschließlich die Verbuchung übernimmt) eingerichtet oder die Verbuchung symmetrisch auf alle Applikationsserver verteilt werden sollte.
Als V1 sind damit solche Bausteine klassifiziert, die für den Betrieb absolut notwendig sind. Als V2 werden Bausteine gekennzeichnet, die auch in Zeiten mit etwas niedrigerer Last und ohne den Schutz von Enqueue-Sperren bearbeitet werden können (z. B. die Fortschreibung von Statistiken). Die Schnittstellen zur Versorgung von Statistiksystemen, wie etwa das SAP Logistics Information System (LIS), sind in der Regel über V2-Funktionsbausteine realisiert (genauer gesagt können Sie im Customizing zwischen V1, V2 und V3 wählen).
Basisadministratoren steht mit "Shortcut for SAP Systems" eine PC-Anwendung zur Verfügung, die etliche Tätigkeiten in der SAP Basis vereinfacht bzw. ermöglicht.
Wenn der zusätzliche Speicher im Erweiterten Speicherbereich für den Nutzerkontext immer noch nicht ausreicht, kann der optionale zweite Rollbereich dafür genutzt werden.
So viele Informationen... wie kann man die aufheben, so dass man sie bei Bedarf wiederfindet? Dafür eignet sich Scribble Papers ganz hervorragend.
Im linken oberen Bereich finden Sie Schaltflächen, um in die Systemkonfiguration zu navigieren und Datenbanken zum Monitoring auszuwählen, denn im DBA-Cockpit können mehrere Datenbanken administriert werden, z. B. die Datenbankinstanzen von ABAP- oder Java-Systemen, alleinstehende Datenbanken- oder SAP-liveCache-Instanzen.