Der Workload-Monitor
TABELLENPROTOKOLLIERUNG UND TABELLENSCHUTZ
Wenn Sie einen Puffer optimieren wollen, müssen Sie verstehen, wie er sich gegenüber Änderungen und Verdrängung verhält. Wenn Daten, die gepuffert werden, geändert werden, muss der Puffer davon in Kenntnis gesetzt werden und die gepufferten Daten invalidieren. Werden die Daten gleichzeitig von einem zweiten Prozess verwendet, gibt es unterschiedliche Strategien, wie der Puffer darauf reagiert: Der Puffer kann eine Lesekonsistenz gewährleisten, d. h., solange sich der Prozess in einer Transaktion befindet, kann er noch auf die Daten vor der Änderung zugreifen, um ein konsistentes Bild der Daten zu bekommen. Alternativ gibt es auch Puffer, die diese Lesekonsistenz nicht gewährleisten, d. h., das Programm muss damit rechnen, dass sich Daten bei mehrfachem Lesen in einer Transaktion ändern. Sofern mehrere Instanzen des Puffers existieren, müssen Sie sich anschauen, wie die Synchronisation zwischen den Puffern abläuft, wenn Daten geändert werden.
Der Speicherbedarf der SAP-Puffer hängt entscheidend von den SAP-Modulen ab, die Sie auf der entsprechenden SAP-Instanz betreiben. Insgesamt ergibt sich für die SAP-Puffer ein typischer Speicherbedarf von 5 bis 15 GB, was u. a. davon abhängt, ob Unicode verwendet wird. Die größten Puffer sind der SAP-Programmpuffer mit einer Größe von 5 GB und größer und der SAP-Tabellenpuffer (für generische und für Einzelsatzpufferung) mit einer Größe von 1 GB und größer. Der Speicherbereich für die SAP-Puffer wird pro SAP-Instanz allokiert. Wird das SAP-System auf viele Instanzen mit jeweils wenigen Benutzern und Workprozessen verteilt, ist der Speicherbedarf des Gesamtsystems größer, als wenn das System auf relativ wenige Instanzen mit jeweils mehr Benutzern und Workprozessen pro Instanz aufgeteilt wird.
Report RSMEMORY
Ist die Summe aus physischem Speicher und Auslagerungsspeicher kleiner als der vom SAP-System, von der Datenbank und anderen Programmen benötigte Speicher, kann es zu Speicherverwaltungsfehlern (d. h. zu Programmabbrüchen innerhalb des SAP-Systems), im schlimmsten Fall sogar zum Abbruch des Betriebssystems, kommen. Sie sollten also in jedem Fall den Auslagerungsspeicher ausreichend dimensionieren.
Kann der SAP Extended Memory aufgrund der zuvor aufgeführten Beschränkungen nicht vergrößert werden und stellen Sie anhand der Modusliste fest, dass wenige Benutzer einen großen Teil des SAP Extended Memorys belegen, können Sie die Benutzerquote (ztta/roll_extension bzw. mit Basisversion 7.40 auch ztta/roll_extension_dia und ztta/roll_extension_nondia) reduzieren. Dies führt dazu, dass der einzelne Benutzermodus im SAP Extended Memory weniger Speicher belegt und stattdessen eher SAP Heap Memory verwendet. Dieses Vorgehen hat jedoch zwei Nachteile: Workprozesse gehen mit einer höheren Wahrscheinlichkeit in den PRIV-Modus. Daher muss eventuell die Anzahl der Dialog-Workprozesse erhöht werden. Dem einzelnen Benutzer steht insgesamt weniger Speicher zur Verfügung; dies kann im schlimmsten Fall zur Folge haben, dass Programme mit einem sehr hohen Speicherbedarf abbrechen.
"Shortcut for SAP Systems" ist eine PC-Anwendung, mit der viele Tätigkeiten in der SAP Basis vereinfacht bzw. auch überhaupt erst ermöglicht werden.
Abbildung 3.6 zeigt z. B. die statistischen Sätze von SD-Transaktionen eines Benutzers.
Die SAP-Basis ist das Fundament eines jeden SAP-Systems. Viele nützliche Informationen dazu finden Sie auf dieser Seite: www.sap-corner.de.
Der SAP-Profilparameter PHYS_MEMSIZE legt fest, wie viel vom gesamten physischen Hauptspeicher eines Rechners für die SAP-Instanz verwendet werden soll.