Implementierung Ihres Benutzer- und Sicherheitsmanagements
Neue Datenquellen mit SAP HANA erschließen
Grundlagen des Sizings sind detaillierte Erfahrungswerte über den Ressourcenbedarf von Benutzern und Transaktionen. Diese Erfahrungswerte veralten schnell angesichts neuer Applikations- und Rechnergenerationen, daher fokussieren wir uns in diesem Kapitel auf die Prozesse und Werkzeuge. Bei einem Sizing-Projekt sind mehrere Parteien im Boot: Das Kundenprojekt stellt das Mengengerüst, sprich die Anforderungen an konkurrierende Benutzer, Durchsatz bestimmter Transaktionen und erwartetes Datenvolumen, zusammen. Die Experten des Hardwarepartners erstellen ein Hardwareangebot – wenn nötig, unter Rückgriff auf Experten der SAP. Schließlich benötigen Sie als Projektleiter oder -mitarbeiter das Wissen über den prinzipiellen Sizing-Prozess, um unterschiedliche Sizing-Angebote und Aussagen kompetent vergleichen und bewerten zu können, die Möglichkeiten, Risiken und Grenzen einer Sizing-Aussage zu verstehen und schließlich eine fundierte Entscheidung zwischen den Hardwareangeboten zu treffen.
Sind noch nicht alle benötigten ABAP-Programme und Dynpros in den Puffern des Applikationsservers vorhanden, müssen diese geladen und eventuell generiert werden. Diese Zeit schlägt als Lade- und Generierungszeit (Mittlere Lade- & Generierungs-Zeit) zu Buche. Ein weiteres Indiz dafür, dass Programme geladen werden, sind Datenbankzugriffe auf die Tabellen, in denen die ABAP-Programme auf der Datenbank gespeichert werden, nämlich die Tabellen D010S, D010L etc..
SAP Basis Training
In den Einzelsatzstatistiken können Sie Probleme erkennen, die in den gemittelten Werten des Transaktionsprofils nicht ins Auge fallen. So können Sie anhand der Einzelsätze entscheiden, ob die Antwortzeiten für alle Transaktionsschritte gleichmäßig hoch oder ob sie generell niedrig sind und nur sporadisch extrem hohe Antwortzeiten auftreten, die zu einem erhöhten Mittelwert führen. Dabei lässt sich z. B. anhand der Spalte Fcod, die den Funktionscode innerhalb einer Transaktion anzeigt, feststellen, ob hohe Antwortzeiten immer nur für einen Bildschirm innerhalb einer Transaktion auftreten. Im Beispiel in Abbildung 3.6 fällt auf, dass die Antwortzeiten für die ersten Dialogschritte deutlich unter 1 Sekunde liegen, dass aber der letzte Transaktionsschritt im Dialog-Task (mit dem Funktionscode SICH) eine hohe Antwortzeit von 14,5 Sekunden aufweist. Diesen Satz sollten Sie also genauer untersuchen.
Neben der Auswertung der Antwortzeiten sollten Sie die folgende Analyse durchführen, die man als die »Suche nach der verlorenen Zeit« bezeichnen könnte. Wie oben bereits erwähnt, gibt es zwei unterschiedliche Quellen der Zeitmessung. Alle Zeiten, außer der CPU-Zeit, werden vom SAP-Workprozess gemessen, und nur die CPU-Zeit wird vom Betriebssystem ermittelt. Die folgende Analyse ist ein Plausibilitätscheck zur Überprüfung, ob die beiden Zeitmessungen miteinander vereinbar sind. Dazu subtrahiert man von der gesamten mittleren Antwortzeit alle Zeiten, in denen der SAP-Workprozess keine CPU-Zeit benötigt, nämlich die Dispatcher-Wartezeit, die Datenbankzeit, die Enqueue-Zeit und die Roll-Wartezeit. Während der Processing-Zeit werden im Wesentlichen Programme bearbeitet, und daher sollte in dieser Zeit CPU-Kapazität »verbraucht« werden. Daher sollten Processing-Zeit und CPU-Zeit in der gleichen Größenordnung liegen. Als Richtwert für die Praxis sollte die Differenz aus Processing- Zeit und CPU-Zeit nicht größer als 10 % sein. Größere »Fehlzeiten« deuten auf Performanceprobleme hin.
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.
Im letzten Abschnitt gehen wir auf den zentralen Überwachungsmonitor ein, der Performanceindikatoren aus allen Bereichen integriert.
Dies wird in diesem Artikel noch genauer erläutert.