SAP Basis Analyse der SAP-Puffer

Direkt zum Seiteninhalt
Analyse der SAP-Puffer
Unterstützung oder Vertretung Ihrer Mitarbeiter
SAP on Azure bzw. on Amazon Web Services (AWS) ist eine skalierbare, zuverlässige Plattform für Ihre aktuellen und künftigen Anforderungen an SAP HANA. Erzielen Sie durch die Migration auf Azure oder AWS eine optimale Leistung für Ihr gesamtes System. Nutzen Sie das beste aus zwei Welten!

Ist die Verbindung zwischen Sender- und Empfänger-Workprozess aufgebaut, werden die zur Ausführung des RFCs nötigen Daten übertragen. In der Workprozess-Übersicht wird nun sowohl beim Sender- als auch beim Empfänger-Workprozess der Status hält mit Grund CPIC und Aktion/Wartegrund CMSEND angezeigt. Hinter dem Eintrag CMSEND befindet sich eine Nummer, die sogenannte Kommunikations-ID.
Speicherbereiche der SAP-Instanz
Parallel zur Suche nach Applikationsfehlern sollten Sie untersuchen, ob das Programm an Grenzen gestoßen ist, die durch die SAP-Profilparameter festgelegt sind. Der für einen Benutzerkontext zur Verfügung stehende Speicher ergibt sich aus der Summe von ztta/roll_extension (bzw. mit Basisversion 7.40 auch ztta/roll_extension_dia und ztta/roll_extension_nondia, Quoten im SAP Extended Memory) und abap/heap_area_dia bzw. abap/heap_area_nondia (Quoten im SAP Heap Memory). Hinzu kommt noch der SAP Roll Memory mit einer Größe von weniger als 10 MB pro Kontext (ztta/roll_area) und das ab Version 7.40 obsolet ist. In dem oben angeführten Beispiel bricht das Programm ab, weil diese Quoten erreicht werden. Die Parameter betragen in diesem Beispiel ztta/roll_extension = 4.000.000.000 (Byte) bzw. abap/heap_area_dia = 2.000.000.000 (Byte). Der Vergleich mit den Werten »erweiterter Speicherbereich (EM)« und »fest allokierter Speicher (HEAP)« aus dem Protokoll zum Abbruch zeigt, dass das Programm abgebrochen wurde, weil es seine Quoten an SAP Extended Memory und SAP Heap Memory erreicht hat. In diesem Fall sollten Sie diese SAP-Profilparameter erhöhen.

Auf jedem Applikationsserver existieren Ressourcen, die nur einmalig zur Verfügung stehen. Diese Ressourcen können nur von einem Workprozess und nicht von mehreren zugleich verwendet werden. Wenn ein Prozess diese Ressource verwenden möchte, setzt er ein Semaphor. Wenn andere Prozesse diese ebenfalls benötigen, müssen sie so lange warten, bis der das Semaphor haltende Prozess seine Aktion beendet hat. So muss z. B. immer, wenn ein Eintrag in einem SAP-Puffer geändert werden soll, ein Semaphor gesetzt werden, da nur ein einziger Prozess eine Änderung im Puffer vornehmen kann. Warten mehrere Prozesse auf ein Semaphor, bezeichnet man dies als Serialisierung. Eine weitere Operation, bei der ein Semaphor gesetzt wird, ist das Roll-in bzw. Roll-out. Dies bedeutet, dass immer nur ein Prozess nach dem anderen ein Roll-in bzw. Roll-out durchführen kann. Eine vollständige Liste der SAP-Semaphore erhalten Sie mit der Werthilfe (F1) zum Feld Gesperrte Semaphore.

Etliche Aufgaben im Bereich der SAP Basis können mit "Shortcut for SAP Systems" wesentlich erleichtert werden.

Dialog-, Hintergrund- und Spool-Services werden bei einem verteilten SAP-System auf die Applikationsserver verteilt.

Um die vielen Informationen zum Thema SAP - und auch anderen - in einer Wissensdatenbank zu speichern, eignet sich Scribble Papers.

Seit SAP-Basis 4.0 ist für SAP-Systeme unter Windows das Zero Administration Memory Management aktiv.
Zurück zum Seiteninhalt