Releasewechsel
SCC8 Mandantenexport
Im Zeitalter der Digitalisierung muss das Rad nicht neu erfunden werden. Bestimmte Funktionen werden nur noch konsumiert oder durch Plattformen genutzt, ohne die hierzu notwendige Infrastruktur vollumfänglich selbst vorzuhalten. Um im Vergleich zu Mitbewerbern hiervon zu partizipieren, ist es notwendig, diese Technologien einzuführen, zu nutzen und deren Möglichkeiten kennenzulernen. Beispiele hierfür sind die Nutzung von Cloud-Services oder Anwendungen im IoT und Big-Data-Umfeld.
Beim Sizing von Internetanwendungen entsteht das Problem, dass sich Benutzeranzahl und Durchsatz zu Spitzenlastzeiten nur schwer im Voraus ermitteln lassen. Sind Ihre Anwendungen zu diesen Zeiten nicht verfügbar und performant, drohen massive Schäden: Ein zum Teil beträchtlicher finanzieller Schaden, denn viele Interessenten werden ihren erfolglosen Zugriff später nicht noch einmal wiederholen. Ein Imageschaden, denn viele erfolglose Interessenten werden den Anbieter der Seite möglicherweise als inkompetent und die Anwendung als unsicher empfinden. Möglicherweise ein juristischer Schaden: Insbesondere in den Anfangszeiten des Onlinebankings waren Banken nicht in der Lage, ausreichend Kapazitäten in Callcentern und beim Internetzugriff zur Verfügung zu stellen, um die Anfragen ihrer Kunden zu bearbeiten. Die Bundesbehörden in Deutschland haben daraufhin Banken öffentlich und massiv gewarnt und klargestellt, dass sie dazu verpflichtet seien, ihren Kunden einen angemessenen Zugriff zu ermöglichen, wenn sie Onlinebanking anbieten. In allen beschriebenen Fällen wird zu den Spitzenlastzeiten mit mehreren tausend Benutzern gerechnet. Da Benchmark-Ergebnisse vorliegen, kann in diesen Fällen ein Hardware-Sizing durch kompetente Mitarbeiter der Hardwarepartner vorgenommen werden. Ein Problem, das sich aus der Natur der Sache ergibt, ist, dass die Hardware, die für die Spitzenlastzeiten benötigt wird, eventuell an 350 Tagen im Jahr ungenutzt »herumsteht«. Es wird in Zukunft immer mehr derartige Geschäftsszenarien geben, in denen ein aktives Kapazitätsmanagement gefragt ist.
Monitore zur Detailanalyse
Die Leistungsfähigkeit der CPU ergibt sich aus ihrer Geschwindigkeit und ihrem Durchsatz. Eine CPU mit niedriger Geschwindigkeit und hohem Durchsatz kann also die gleiche Leistung erbringen wie eine CPU mit hoher Geschwindigkeit und niedrigem Durchsatz. Die Antwortzeit der Anwendung kann jedoch bei gleicher SAPS-Leistung sehr unterschiedlich sein. Die SAP hat daher in das Sizing die sogenannte SCU-Klasse (Single Computing Unit Performance) für CPUs eingeführt, die auch der Quick Sizer angibt (siehe Tabelle 4.2). Die Klassen sind A, AA und AAA. Eine Klasse AAA gibt an, dass Sie bei der Auswahl der Hardware stark auf die Geschwindigkeit der CPU achten sollten. Weitere Erläuterungen finden Sie in SAP-Hinweis 150170.
Wie sich ein Problem mit der SAP-Speicherverwaltung in den Performancemonitoren manifestieren kann, sehen Sie in Abbildung 2.7 und in Abbildung 2.10, die gleichzeitig auf einem Kundensystem aufgenommen wurden. Am deutlichsten wird das Problem in der Workprozess-Übersicht (siehe Abbildung 2.10). Dieser Übersicht entnehmen Sie, dass sich praktisch alle Workprozesse im Zustand PRIV befinden. Abbildung 2.7 zeigt darüber hinaus, dass die Ursache für diese Wartezustände ein völlig erschöpftes SAP Extended Memory und ein erschöpfter Roll-Puffer sind. Eine Vergrößerung des zu kleinen Extended Memorys (Parameter em/initial_ size_MB) oder eine Analyse der Programme mit hohem Speicherbedarf schafft in diesem Fall Abhilfe.
Etliche Aufgaben im Bereich der SAP Basis können mit "Shortcut for SAP Systems" wesentlich erleichtert werden.
In einem isolierten SAP-System besteht ein Transaktionsschritt im einfachsten Fall aus einer Aktion in einem System.
Einige nützliche Tipps aus der Praxis zum Thema SAP Basis finden Sie auch auf der Seite www.sap-corner.de.
Auf dem Datenbankserver befindet sich neben der Datenbankinstanz die zentrale SAP-Instanz mit Enqueue- und Dialog-Workprozessen.