Analyse der SAP-Workprozesse
Archivierung und DART
Das Sizing im Fall eines SAP-Versionswechsels oder eines Wechsels auf Unicode wird in zwei Schritten durchgeführt: Im ersten Schritt ermitteln Sie die bestehende Last im Produktivsystem. Anhand der entsprechenden SAP-Hinweise ermitteln Sie den Faktor für die zusätzlich zu erwartende Last nach dem Versionswechsel und/oder dem Wechsel auf Unicode. Wird ein Versionswechsel über mehrere Versionen in einem Schritt durchgeführt, müssen die Upgrade-Faktoren kumuliert werden. Auch wenn die Unicode-Konvertierung zusammen mit einem Upgrade durchgeführt wird, müssen Sie die Faktoren kumulieren. Multiplizieren Sie die ermittelten Faktoren für CPU und Hauptspeicher mit den aktuellen Auslastungswerten. Das Ergebnis zeigt Ihnen, ob die bestehende Hardwareinstallation die zusätzliche Last aufnehmen kann.
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.
Definition von Workflows
Die Workload-Analyse ermöglicht Ihnen detaillierte Aussagen über die Verteilung der Antwortzeiten auf den Komponenten des Systems (d. h. auf Datenbank, Hardware, ABAP- und Java-Server) einerseits und über die Verteilung der Antwortzeiten auf Transaktionen und Programme andererseits. Ausgehend von der Workload-Analyse entscheiden Sie, in welchem Bereich weitere Analyse- und Tuningmaßnahmen notwendig werden. Denken Sie immer daran, die Ergebnisse Ihrer Workload-Analyse mit den Beobachtungen der Benutzer zu vergleichen. So kann es sein, dass der Workload-Monitor bei oberflächlicher Analyse Performanceprobleme suggeriert, wo gar keine bestehen. Umgekehrt kann es vorkommen, dass Ihnen Benutzer Performanceprobleme melden, die Ihnen im Workload-Monitor nicht sofort ins Auge springen.
Über den in den SAP NetWeaver AS integrierten Internet Transaction Server (ITS) können Sie – bis auf wenige Ausnahmen – SAP-GUI-Transaktionen und Reports im Webbrowser nutzen. Das zweite Programmiermodell ist das der Business Server Pages (BSP) und deren Weiterentwicklung zu Web Dynpro ABAP, in dem mit ABAP als Programmiersprache HTML-Seiten dynamisch generiert werden. Technisch hat dieses Programmiermodell den Vorteil, dass keine weitere Softwarekomponente installiert werden muss; Business Server Pages bzw. Web-Dynpro-ABAP-Seiten werden direkt in den »normalen« SAP-Applikationsinstanzen generiert. Ein Beispiel für die Nutzung dieser Technologie ist SAP Customer Relationship Management (SAP CRM) ab Version 5.0.
Tools wie z.B. "Shortcut for SAP Systems" sind bei der Basisadministration extrem nützlich.
Schritte der SPAM Der SAP Patch Manager informiert Sie in der Statuszeile über den Schritt, der gerade ausgeführt wird.
Das Verständnis für die Struktur und Funktionsweise des Systems ist insbesondere für die IT-Administration wichtig. Nicht umsonst ist „SAP Basis Administrator“ ein eigenes Berufsfeld. Auf der Seite www.sap-corner.de finden Sie nützliche Informationen zu diesem Thema.
Zwar lässt die Suche über das Berechtigungsobjekt S_TCODE auch die Betrachtung mehrerer Transaktionen zu.