Ermittlung der bestehenden Last im Produktivsystem
Ermitteln Engpässe
Das Sizing im Fall eines SAP-Versionswechsels oder eines Wechsels auf Unicode wird in zwei Schritten durchgeführt: Im ersten Schritt ermitteln Sie die bestehende Last im Produktivsystem. Anhand der entsprechenden SAP-Hinweise ermitteln Sie den Faktor für die zusätzlich zu erwartende Last nach dem Versionswechsel und/oder dem Wechsel auf Unicode. Wird ein Versionswechsel über mehrere Versionen in einem Schritt durchgeführt, müssen die Upgrade-Faktoren kumuliert werden. Auch wenn die Unicode-Konvertierung zusammen mit einem Upgrade durchgeführt wird, müssen Sie die Faktoren kumulieren. Multiplizieren Sie die ermittelten Faktoren für CPU und Hauptspeicher mit den aktuellen Auslastungswerten. Das Ergebnis zeigt Ihnen, ob die bestehende Hardwareinstallation die zusätzliche Last aufnehmen kann.
Die Zeitangaben aus Abbildung 1.6 stellen die Richtwerte für »kleine« Datenmengen dar. Wenn große Datenmengen bearbeitet werden, z. B. ein großes Dokument vom Anwendungsserver zum Rechner eines Endbenutzers übertragen wird, werden zusätzlich die Durchsatzzahlen für die bestimmte Kommunikation relevant, d. h. in diesem Fall die Netzwerkbandbreite des WANs zwischen Server und Rechner des Endbenutzers.
SE80 ABAP Workbench
Um eine optimale Datenbankperformance zu gewährleisten, sollten die Festplatten der Datenbank möglichst gleichmäßig belastet (d. h. beschrieben bzw. gelesen) werden, sogenannte Hotspots sollten Sie vermeiden. Im Betriebssystemmonitor des Datenbankservers (Transaktionscode ST06) in der Analyse Snapshot > Platten finden Sie u. a. Informationen über die Auslastung der Festplatten sowie Warte- und Antwortzeiten von I/O-Operationen dieser Platten. Die Gefahr eines I/O-Engpasses besteht, wenn einzelne Platten stark ausgelastet sind (Util.>50 % im Stundendurchschnitt), wenn auf diesen Platten Datendateien liegen, die stark beschrieben werden, oder wenn beim Zugriff auf diese Dateien Wartesituationen auftreten. Einen I/O-Engpass können Sie durch eine bessere Verteilung der Tabellen auf das Dateisystem beseitigen. Sie sollten insbesondere sicherstellen, dass sich auf den ausgelasteten Platten keine anderen stark beschriebenen Dateien befinden. Die in Tabelle 2.5 aufgeführten Komponenten gehören zu den am stärksten beschriebenen Elementen einer Datenbank. Sie sollten grundsätzlich weder auf einer gemeinsamen Festplatte mit den Datendateien der Datenbank liegen noch auf einem Festplatten-Array (z. B. auf einem Raid-5-System).
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.
Mit "Shortcut for SAP Systems" werden Aufgaben im Bereich der SAP Basis vereinfacht und fehlende Funktionen des Standards ergänzt.
Aufwand für Monitoring und Alarmierung, regelmäßige Routinearbeiten und Wartung aber auch das fortwährend notwendige Training für eigene Administratoren entfällt zum überwiegenden Teil.
Dabei sind die kritischen SAP Berechtigungen in der Regel durch spezielle Prüfsoftware vordefiniert.