Verwendung
WLF_IDOC IDoc-Monitor
Stellen Sie anhand dieser Monitore fest, dass einzelne Platten stark ausgelastet sind (Auslastung (%) > 50 %), liegt ein potenzieller I/O-Engpass vor. Aus dem SAP-System heraus ist allerdings nur eine sehr beschränkte Aussage über I/O-Probleme möglich. Eine detaillierte Analyse kann nur mit Mitteln des Hardwarepartners durchgeführt werden.
Sind für die Bearbeitung einer Benutzeranfrage Daten notwendig, die sich Datenbanktuning noch nicht im Hauptspeicher des Applikationsservers befinden, werden diese vom Datenbankserver gelesen. Beim Tuning der Datenbank unterscheidet man drei Bereiche. Zunächst einmal ist dies die richtige Einstellung der Datenbankpuffer und anderer Datenbankparameter. Der zweite Bereich ist die Optimierung des Festplattenlayouts der Datenbank, um die Last möglichst gleichmäßig auf die Festplatten zu verteilen und so Wartesituationen beim Schreiben auf die Festplatte bzw. beim Lesen von der Festplatte zu vermeiden. Der dritte Aspekt beim Datenbanktuning ist die Optimierung langlaufender, »teurer« SQL-Anweisungen.
Enqueue-Trace auswerten
Benutzerkontexte werden im SAP Extended Memory, im SAP Roll Memory und im SAP Heap Memory abgelegt. Dem Austausch von Daten zwischen den Kontexten eines Benutzers dienen der SAP Paging Memory und der SAP Extended Global (EG) Memory. Den zweiten wichtigen Speicherbereich bilden die SAP-Puffer. Diese halten benutzerübergreifende Daten auf dem Applikationsserver vor, auf die häufig zugegriffen wird und die wenig geändert werden. Wichtige Puffer sind der SAP-Programmpuffer, der die ABAP-Programme enthält, die DDIC-Puffer, die Metadaten der Tabellen enthalten, und der SAP-Tabellenpuffer für generische und für Einzelsatzpufferung. Die lokalen Speicherbereiche der konfigurierten Workprozesse bilden den dritten Speicherbereich. Der Speicher der SAP-Instanz wird durch den physischen Hauptspeicher (RAM), den Auslagerungsspeicher oder weitere Dateien, wie die Roll-Datei und die Paging-Datei.
Bei Windows-Betriebssystemen wird nur ein Teil des SAP Extended Memorys vom Workprozess adressiert. Dieser Teil wird durch den Parameter em/address_space_MB konfiguriert. Diese Implementierung hat den Vorteil, dass der gesamte SAP Extended Memory damit größer sein kann als der Adressraum des Workprozesses. Die gesamte Größe des SAP Extended Memorys wird also nur durch die Größe des Auslagerungsspeichers begrenzt. Beachten Sie, dass jeder Workprozess im Prinzip auf alle Objekte, die im SAP Extended Memory abgelegt werden, zugreifen kann, während eines Transaktionsschrittes jedoch nur auf einen Bereich der Größe em/address_space_MB. Der Parameter em/address_space_MB muss so groß konfiguriert sein, dass er die maximale Größe eines Benutzerkontextes (insbesondere ztta/roll_extension*) und den SAP EG Memory umfassen kann. Die Windows-spezifische Implementierung des SAP Memory Managements wird über den Systemparameter es/implementation eingestellt, der bei Windows auf dem Wert view steht und der nicht verändert werden darf. Der SAP Heap Memory ist unter Windows weniger wichtig, da Nicht-DialogWorkprozesse ebenso wie Dialog-Workprozesse zunächst SAP Extended Memory allokieren und diesen »unbegrenzt« zur Verfügung steht. Die SAPProfilparameter abap/heap_area* sind daher überflüssig.
Tools wie "Shortcut for SAP Systems" ergänzen fehlende Funktionen im Bereich der SAP Basis.
Eine Betreuungsleistung der SAP-Basis muss bei der Konzeption abgesprochen und geregelt werden.
Die Admins können deshalb auch in die Planung und Entwicklung des Systems involviert sein.