Aktive Benutzer
Migration der SAP DB-Systeme (zwischen unterschiedlichen Datenbanken)
Welche Argumente sprechen nun dafür, mehr oder weniger Workprozesse zu konfigurieren? Das Argument für eine hohe Workprozess-Anzahl ist klar: Wenn Benutzer auf Workprozesse in der Queue des SAP-Dispatchers warten müssen, ist die Versuchung groß, ihnen mehr Workprozesse zur Verfügung zu stellen und dann zu hoffen, dass mehr Benutzer gleichzeitig arbeiten können. Dies ist dann der Fall, wenn Workprozesse durch Wartesituationen blockiert werden, die keine CPU-Leistung kosten, z. B. wenn Workprozesse in den PRIV-Modus gehen oder häufig durch Sperrsituationen auf der Datenbank blockiert sind. Auf der anderen Seite ist das »Aufdrehen« der Anzahl der Workprozesse fragwürdig, denn offensichtlich ist es langfristig sinnvoller, das tatsächliche Performanceproblem zu lösen, nämlich die Wartesituationen zu beseitigen. Das Hinzufügen von Workprozessen kann also nur Symptome abmildern, in der Regel das Performanceproblem jedoch nicht wirklich lösen.
Am Ende eines Transaktionsschrittes verlässt ein Benutzer den Workprozess, damit ein anderer Benutzer mit diesem Workprozess weiterarbeiten kann. Dabei muss der Benutzerkontext aus dem Workprozess herausgerollt werden. Wird dem Benutzer beim nächsten Transaktionsschritt ein anderer Workprozess zugewiesen, wird der Benutzerkontext dem neuen Workprozess zur Verfügung gestellt. Der Benutzer kann auf diese Weise mit seinen alten Daten weiterarbeiten. Dieser Vorgang heißt Roll-in.
OAC0 Content-Repositories anzeigen
Für den Benutzer ist die mittlere Antwortzeit seiner Transaktionen die entscheidende Größe. Die mittleren Antwortzeiten der Kerntransaktionen, d. h. der Transaktionen, von deren Performance der Geschäftsablauf empfindlich abhängt, sollten Sie genau überwachen und sich eigene Richtwerte setzen. Folgende Fragen sollten Sie bei der Analyse des Transaktionsprofils beantworten: Sortieren Sie das Transaktionsprofil nach S DB-Zeit. Welche Transaktionen verursachen die höchste Datenbanklast? Sortieren Sie das Transaktionsprofil nach S CPU-Zeit. Welche Transaktionen verursachen die höchste CPU-Last? Fallen Ihnen Transaktionen auf, bei denen der Anteil der Datenbankzeit bzw. der Anteil der CPU-Zeit deutlich über 60 % der gesamten Antwortzeit liegt? Solche Transaktionen sollten mit dem SQL-Trace bzw. dem ABAP-Trace untersucht werden. Das weitere Vorgehen bei der Analyse einzelner Programme und Transaktionen wird in Kapitel 5, »Optimierung von ABAP-Programmen«, beschrieben. Fallen Ihnen kundeneigene Programme und Transaktionen auf, die eine hohe Last verursachen?
Das anschaulichste und intuitiv eingängigste Maß für die »Größe« einer SAP-Komponente ist die Benutzeranzahl. Leider ist dies auch die ungenaueste Angabe, da mit dem Begriff Benutzeranzahl je nach Kontext die Anzahl der Lizenzen, die Anzahl der Benutzerstammsätze und vieles mehr gemeint sein kann. In Komponenten, die im Wesentlichen durch Hintergrund- oder Schnittstellenlast gekennzeichnet sind, verliert die Benutzeranzahl als Maß für die Größe völlig ihren Sinn.
Mit "Shortcut for SAP Systems" werden Aufgaben im Bereich der SAP Basis vereinfacht und fehlende Funktionen des Standards ergänzt.
Auf www.sap-corner.de finden Sie ebenfalls viele nützliche Informationen zum Thema SAP Basis.
Dort legen Sie die für das Sizing notwendigen Daten ab.
So kann man einfach und schnell seine Transaktionen in verschiedenen Ordnern gruppieren.