SOLUTION MANAGER
Der zentrale Workload-Monitor
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.
Ebenso sollten Projekterfolge dokumentiert und als Erfolgsgeschichten der SAP-Basis in Umlauf gebracht bzw. den Stakeholdern der SAP-Basis zur Verfügung gestellt werden, um den Stellenwert der SAP-Basis hervorzuheben. Diese Erfolgsgeschichten können bspw aus der Basis heraus oder von außen verbreitet werden. Beispielhaft wären hier Mitteilungen des CIOs oder Projektberichte zu nennen. NUTZEN & KONSEQUENZEN Mehrwerte der Umsetzung der beschriebenen Empfehlungen liegen in der gewährleisteten Betriebsstabilität und Betriebssicherheit. Auch erhält ein Unternehmen und insbesondere eine IT-Organisation mit einer starken SAP-Basis einen kompetenten und auskunftsfähigen Partner für SAP-Themen und -Technologien, der das SAP-Bild im Großen und Ganzen stets im Blick hat. Des Weiteren ist allen Geschäfts- und IT-Fachabteilungen die Rolle und das Aufgabengebiet der SAP-Basis bekannt. Somit kann diese als richtiger Ansprechpartner rechtzeitig kontaktiert werden. Die Gefahr, dass sich bestimmte Bereiche auf Grund von Intransparenz eine Schatten-IT mit Bezug auf SAP-Themen und -Technologien aufbauen, ist geringer.
Benutzer und Zugriffsrechte steuern
Durch das technische Tuning werden alle zum System gehörigen Komponenten so eingestellt, dass die durch die Benutzer erzeugte Last vom System optimal verarbeitet werden kann und sich keine Performanceengpässe bilden. Gegenstand des technischen Tunings sind Betriebssystem, Datenbank, SAP-Applikationsserver und Netzwerke.
Wird bei unserer Konfiguration der Datenbankprofilparameter auf 4 gesetzt, beansprucht die Datenbankinstanz alle Prozessoren für sich. Das Betriebssystem und die SAP-Instanz mit dem Enqueue-Workprozess würden dann unter einem CPU-Engpass leiden, was dazu führen kann, dass Enqueue-Anfragen aller SAP-Instanzen unnötig langsam bearbeitet werden.
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.
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).
Da SAP AMS oftmals für die eigentliche Anwendung (Ebene 3) und die Applikationsplattform (Ebene 2) verwendet wird, empfiehlt es sich im Service-/Leistungsschein zum SLA eine eindeutige Abgrenzung zu dokumentieren.