Analyse der SAP-Puffer
Speicherbedarf einzelner Programme
Jede Datenbank verfügt über unterschiedliche Puffer, in denen Benutzerdaten (Tabelleninhalte) und Verwaltungsinformationen (sogenannte Metadaten) der Datenbank im Hauptspeicher gehalten werden, um die Anzahl der Festplattenzugriffe zu reduzieren. Der Zugriff auf Objekte im Hauptspeicher geht etwa zehn- bis hundertmal schneller vor sich als ein Zugriff auf die Festplatten. Sind die Puffer zu klein eingestellt, kann das erforderliche Datenvolumen nicht im Puffer gehalten werden. Daten werden aus dem Puffer verdrängt und müssen wiederholt von der Festplatte gelesen (geladen) werden. Daher ist das Überwachen der Puffer ein wichtiges Element der Performanceanalyse. Die zur Überwachung der Puffer notwendigen Informationen finden Sie daher in den Monitoren aller Datenbanken.
Nachdem Sie die Methoden der Lastverteilung und des Hardware-Sizings kennengelernt haben, beschäftigen wir uns abschließend mit der Frage, wie viele Systeme, Datenbanken, Applikationsinstanzen und Server man benötigt, um die anfallende Last zu bewältigen. Insbesondere bei der Einführung der SAP Business Suite stehen die Projektteams vor der anspruchsvollen Aufgabe, den Aufwand für die Wartung und Administration von Hardware, Datenbanken, SAP-Instanzen und weiterer Software nicht explodieren zu lassen. Vor diesem Hintergrund wird in vielen Projekten eine Konsolidierung angestrebt, d. h. eine Reduzierung der Softwareinstanzen auf wenige leistungsfähige Rechner. Hardwarepartner unterstützen dies durch innovative Technologie- und Vermarktungskonzepte.
Was ist SAP Basis?
Alle Performancemonitore der SAP verfügen über offene Schnittstellen, die es den SAP-Partnern ermöglichen, Performancedaten über SAP-Systeme abzurufen. Dies bedeutet, dass Sie, wenn Sie eine externe System-Management-Software zur Systemüberwachung verwenden, auf die Performancedaten der SAP zugreifen und somit Ihre SAP-Lösung systemseitig überwachen können. Beispiele für Überwachungswerkzeuge, die auf SAP Performancedaten zugreifen, sind OpenView (HP), Tivoli (IBM) oder Patrol (BMC Software). Einschränkend möchten wir Sie jedoch darauf hinweisen, dass mit diesen Produkten nur eine systemseitige Überwachung möglich ist (Outside-in-Ansatz). Eine Anwendungsüberwachung ist mit diesen Produkten nicht möglich.
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.
Einige fehlende Funktionen in der Basisadministration werden durch "Shortcut for SAP Systems" ergänzt.
SYSTEM_NO_ROLL: Der SAP NetWeaver Application Server (AS) begrenzt die Menge an Speicher, die mit einem einzelnen Aufruf allokiert werden kann, durch den Profilparameter ztta/max_memreq_MB.
Die Webseite www.sap-corner.de bietet viele nützliche Informationen zum Thema SAP Basis.
SCHEDULE_RDDIMPDP In diesem Schritt wird der Transportdämon (Programm RDDIMPDP) eingeplant.