SAP System-Monitoring
Status eines Support Package zurücksetzen
Dieser Schritt hat für die SAP-Basis eine wesentliche Bedeutung. Es geht sowohl um die in der Handlungsempfehlung Marketing & Selbstverständnis beschriebene, nach innen ausgerichtete Wahrnehmung als auch um die nach außen gerichtete Wahrnehmung in Form einer Mission und Vision.
Wenn an der Bearbeitung einer Benutzeranfrage mehrere SAP-Komponenten beteiligt sind, schreibt jede dieser Komponenten einen Datensatz. Im Kommunikationsstrom zwischen den Komponenten wird ein eindeutiger Identifikator (ein auch als Reisepass bezeichneter Globally Unique Identifier, GUID) mitgeführt und in den Einzelsätzen gespeichert, sodass später die Einzelsätze über Komponenten hinweg zusammengeführt werden können. Die erste Komponente eines Transaktionsschrittes erzeugt diesen Reisepass, d. h. technisch gesehen eine GUID, mit der der Transaktionsschritt eindeutig identifiziert werden kann, und gibt diesen an die nächste Komponente, die an dem Transaktionsschritt beteiligt ist, weiter. Aus Performancegründen werden während eines Transaktionsschrittes nur die Daten des Reisepasses im Kommunikationsstrom weitergegeben, die eigentlichen Statistikdaten werden zunächst lokal von der jeweiligen Komponente gesichert und dann asynchron an das zentrale Monitoring- System oder den SAP Solution Manager übertragen. Anhand ihres Reisepasses werden die zu einem Transaktionsschritt gehörigen Statistiksätze identifiziert und angezeigt. In der SAP-Hilfe finden Sie diese Technologie unter der Bezeichnung verteilte Statistiksätze (Distributed Statistics Records, DSR).
Bereitschaft, sich weiterzubilden
Das Transaktionsprofil sollten Sie in regelmäßigen Abständen überwachen und sichern. So stellen Sie fest, ob die Antwortzeiten einzelner Transaktionen mit der Zeit kontinuierlich wachsen oder sich plötzlich eine Laufzeitverschlechterung nach einer Programmmodifikation einstellt. Indem Sie solche Trends im Transaktionsprofil frühzeitig erkennen, können Sie eine detaillierte Programmanalyse veranlassen, noch bevor ein Programm zum Flaschenhals für eine Prozesskette wird oder gar durch hohe CPU- oder Datenbankbelastung die Performance des gesamten SAP-Systems in Mitleidenschaft zieht.
Als Eingaben für das durchsatzbasierte Sizing dienen Angaben über das sogenannte Mengengerüst. Dies sind Angaben über die Anzahl der Geschäftsprozesse, die in bestimmten Zeitfenstern bearbeitet werden sollen. Dies können z. B. Angaben über die Anzahl von Kundenaufträgen, Lieferungen und Produktionsaufträgen oder gedruckte Dokumente sein. Dieser Ansatz hat den Vorteil, dass auch die Datenübernahme in Hintergrundprozessen (z. B. durch Batch-Input oder Application Link Enabling, ALE), die tageszeitliche Verteilung des Belegdurchsatzes und ein Sizing für Spitzenlastzeiten berücksichtigt werden. Der durchsatzbasierte Ansatz muss zwingend immer dann gewählt werden, wenn eine maßgebliche Last durch Hintergrundprozesse oder Schnittstellen erfolgt. Beispiele dafür sind SAP-for-Retail-Lösungen (Übernahme von Verkaufsdaten im Point-of-Sales Inbound-Processing) oder Banking-, Utilities- oder Telekommunikationslösungen. In der Praxis wird normalerweise eine Kombination beider Formen des Sizings gewählt. Beim durchsatzbasierten Sizing wird im Quick Sizer mit einer CPU-Zielauslastung von 65 % gerechnet.
Mit "Shortcut for SAP Systems" werden Aufgaben im Bereich der SAP Basis vereinfacht und fehlende Funktionen des Standards ergänzt.
Diese Konfiguration erlaubt es dem System, auf Lastanforderungen adaptiver zu reagieren, als etwa die Betriebsartenumschaltung es vermag.
Wenn Sie mehr zum Thema SAP Basis wissen möchten, besuchen Sie die Webseite www.sap-corner.de.
Dies stellen wir in diesem Abschnitt speziell für SAP HANA dar, aber auch andere Datenbankensysteme bieten diese Option an.