Konfiguration und Operation des SAP Solution Managers
Planung der SAP-Milieus
Als Skalierbarkeit eines Programms bezeichnet man die Abhängigkeit der Laufzeit eines Programms von der Datenmenge. Viele Operationen sind linear von der Datenmenge abhängig (t = O(n)), d. h., die Laufzeit steigt linear mit der Datenmenge an. Beispiele dafür sind Datenbankselektionen in großen Tabellen ohne oder mit ungeeigneter Indexunterstützung und Schleifen über interne Tabellen im Programm. Lineare Skalierbarkeit ist für die Bearbeitung mittlerer Datenmengen akzeptabel. Wenn sie bei Programmen, die große Datenmengen bearbeiten sollen, nicht vermieden werden kann, muss über Parallelisierung nachgedacht werden. Besser als eine lineare Skalierbarkeit sind für die Performance natürlich konstante Laufzeiten (t = O(1)) oder eine logarithmische Abhängigkeit (t = O(log n)). Logarithmische Abhängigkeiten treten z. B. bei Datenbankselektionen in großen Tabellen mit optimaler Indexunterstützung oder bei Leseoperationen in internen Tabellen mit binärer Suche auf. Da die Logarithmusfunktion nur sehr langsam ansteigt, ist in der Praxis zwischen konstanten und logarithmisch ansteigenden Laufzeiten nicht zu unterscheiden. Inakzeptabel für die Bearbeitung mittlerer und großer Datenmengen sind quadratische Abhängigkeiten (t = O(n × n)) und alles, was darüber hinausgeht. Allerdings können Probleme mit quadratischer Abhängigkeit durch intelligente Programmierung in der Regel auf Abhängigkeiten der Art t = O(n × log n) zurückgeführt werden. Ein Beispiel ist das Vergleichen zweier Tabellen, die beide mit der Ordnung n wachsen. Ein Vergleich der unsortierten Tabellen würde zu einer quadratischen Abhängigkeit führen, ein Vergleich mit sortierten Tabellen zur Abhängigkeit t = O(n × log n). Da die Logarithmusfunktion nur sehr langsam ansteigt, ist in der Praxis zwischen einem Ansteigen t = O(n × log n) und einem linearen Ansteigen nicht zu unterscheiden.
Wir machten uns daran, detaillierte Playbooks für alle gängigen Szenarien – Installationen, Portale, Upgrades und Migrationen – und Plattformen zu erstellen. Heute kommt kaum noch ein Beratungshaus ohne aus, in meiner Anfangszeit verschafften sie uns jedoch einen entscheidenden Vorsprung vor der Konkurrenz und brachten uns viele zufriedene Kunden ein.
PROLOGUE
Basis umfasst eine Client/Server-Architektur und Konfiguration, ein relationales Datenbank-Management-System (DBMS) und eine grafische Benutzeroberfläche (GUI). Neben den Schnittstellen zwischen Systemelementen, umfasst Basis eine Entwicklungsumgebung für R/3-Anwendungen, ein Datenverzeichnis sowie Benutzer- und System-Administrations- beziehungsweise Monitoring-Tools.
Während Dialog-Workprozesse im Wesentlichen den globalen SAP Extended Memory nutzen (wie vorher beschrieben), ist für Nicht-Dialog-Workprozesse primär die Nutzung von lokalem SAP Heap Memory vorgesehen. Die Reihenfolge der Speicherbelegung von Dialog- und Nicht-Dialog-Workprozessen, die zusammenfasst, ist also gerade komplementär zueinander. Der Grund für die unterschiedliche Implementierung ist, dass Nicht-Dialog-Workprozesse ihre Benutzerkontexte nicht austauschen müssen, da Hintergrund-, Verbuchungs- und Spoolaufträge immer vollständig von einem Workprozess ausgeführt werden – es findet in Nicht-Dialog-Workprozessen also kein Benutzerwechsel statt. Daher ist vorgesehen, dass Nicht-Dialog-Workprozesse im Wesentlichen lokalen SAP Heap Memory nutzen, um den globalen SAP Extended Memory für Dialog-Workprozesse zu reservieren.
Mit "Shortcut for SAP Systems" steht ein Tool zur Verfügung, das einige Aufgaben im Bereich der SAP Basis erheblich erleichtert.
Beim Roll-in wird der Benutzerkontext aus dem globalen RollBereich in den lokalen Roll-Bereich des neuen Workprozesses kopiert.
Die SAP-Basis ist das Fundament eines jeden SAP-Systems. Viele nützliche Informationen dazu finden Sie auf dieser Seite: www.sap-corner.de.
Eine zusätzliche Anforderung in der Zukunft wird das unternehmenspolitische Verständnis sein.