Sequential Read
CPU-Auslastung
Ein wichtiger Bereich der SAP Security ist die Analyse der kundeneigenen SAP-Programme, die klassisch in der proprietären SAP-Sprache ABAP geschrieben werden. Auch hier können, wie in allen Programmiersprachen, Sicherheitslücken programmiert werden – sei es nun bewusst oder unbewusst. Die Muster der Sicherheitslücken im ABAP-Code unterscheiden sich dabei allerdings von denen in Java-Stacks oder Windows-Programmen. Das Ziel bei diesen herkömmlichen Programmen ist es meistens, durch gezielte Falscheingaben das Programm entweder zum Absturz zu bringen (Buffer Overflow) oder künstlich eigenen Code zur Ausführung zu bringen (Code Injection). Beides ist in ABAP nicht möglich, da ein Absturz eines Prozesses nichts anderes bewirkt als das Erzeugen eines Eintrages in der Log-Datenbank (Dump ST22) und ein anschließendes Beenden des Reports mit Rückkehr an den Menüstartpunkt. Eine direkte Manipulation wie in anderen Hochsprachen oder Servern ist also nicht möglich. Allerdings gibt es andere Manipulationsmöglichkeiten.
Der Performancekollektor läuft periodisch und sammelt Daten zur Performance. Dieses Programm steht oft bei der Gesamtantwortzeit weit oben in der Liste der teuren Programme. Allerdings erkennt man in den Spalten S CPUZeit und S DB-Zeit, dass dieses Programm nur sehr wenig CPU- und Datenbankzeit benötigt. Die meiste Zeit wartet es im Workprozess darauf, dass ihm Performancedaten gemeldet werden.
SU56 Eingetragene Berechtigungen im Puffer
Beim anschließenden PREPARE wird die Zugriffsstrategie für die Anweisung Prepare-Operation vom Datenbankprozess ermittelt. Dabei ist im Feld Statement die Anweisung mit einer Variablen (INSTANCE =:A0, in Abbildung 5.1 nicht gezeigt) zu sehen. Um die Anzahl der relativ laufzeitintensiven PREPARE-Operationen so klein wie möglich zu halten, hält jeder Workprozess eines Anwendungsservers eine bestimmte Anzahl von bereits übersetzten SQL-Anweisungen in einem eigens dafür vorgesehenen Puffer (SAP Cursor Cache). Jeder SAP-Workprozess puffert die Operationen DECLARE, PREPARE, OPEN und EXEC in seinem SAP Cursor Cache. Sobald der Workprozess einmal einen Cursor für eine DECLARE-Operation geöffnet hat, kann er diesen Cursor immer wieder verwenden (bis der Cursor nach einer gewissen Zeit aufgrund der begrenzten Größe der SAP Cursor Caches verdrängt wird).
Bei der Bewertung der Hardware stellt sich die Frage, inwieweit Datenbanksystem, Betriebssystem und SAP-Version eine Rolle spielen. Zu den ersten beiden Einflussfaktoren macht SAP keine Aussagen, d. h., die eingesetzten Datenbank- und Betriebssysteme sollten sich in ihrer Leistungsfähigkeit nicht unterscheiden. Für die SAP-Version dagegen gibt es Angaben, wenn sich der Hardwarebedarf zwischen Versionen ändert. Das heißt, Sie können Differenzen berücksichtigen, wenn die SAP-Version, mit der Sie produktiv gehen wollen, nicht mit der übereinstimmt, für die der Benchmark durchgeführt wurde.
Einige fehlende Funktionen in der Basisadministration werden durch "Shortcut for SAP Systems" ergänzt.
Damit Sie überhaupt die Möglichkeit haben, die Registerkartenkonfiguration zu nutzen, müssen Sie diese daher vorerst aktivieren.
Markieren Sie einen Applikationsserver, und klicken Sie auf die Schaltfläche History of file.