Code Inspector
Funktionsweise Java-Statistiken
Dispatching-Methoden verteilen die eingehende Last auf die zur Verfügung stehenden Prozesse. Sie sollen garantieren, dass die Last optimal auf das System verteilt wird. Für das Dispatching sind der SAP Web Dispatcher (für Webanfragen) und der Message-Server (für Dialog-, Hintergrund- und Verbuchungsanfragen) sowie die Dispatcher-Prozesse der jeweiligen ABAP-Applikationsinstanzen zuständig.
Von diesem Moment an sind keine ändernden Datenbankoperationen mehr möglich. Diese Situation heißt im Umfeld von DB2 for LUW und Oracle Archiver Stuck. Die Datenbankinstanz schreibt eine Fehlermeldung in die Datenbankfehlerprotokolldatei (für DB2 for LUW z. B. db2-diag.log: »SQL0964C The transaction log for the database is full«, bei Oracle z. B. den Eintrag »All online log files need archiving«).
Update des SAP-Systems auf neuere Versionen
Eine SAP-Transaktion erstreckt sich in der Regel über mehrere Transaktionsschritte (Bildwechsel). Während dieser Schritte werden Daten wie Variablen, interne Tabellen und Bildschirmlisten aufgebaut und im Hauptspeicher des Applikationsservers gehalten. Diese Daten bezeichnet man als Benutzerkontext. In der Regel werden die Schritte einer Transaktion von unterschiedlichen Dialog-Workprozessen ausgeführt, d. h., der erste Transaktionsschritt wird vielleicht vom Workprozess Nr. 3 ausgeführt, der zweite Schritt vom Workprozess Nr. 4 etc. Zu Beginn eines Transaktionsschrittes muss daher der Benutzerkontext dem entsprechenden Workprozess zugänglich gemacht werden. Dieser Vorgang heißt Roll-in. Die technischen Vorgänge beim Roll-in (z. B. das Kopieren von Daten in den lokalen Speicher des Workprozesses) werden in Kapitel 6, »Speicherkonfiguration«, im Detail dargestellt. Analog zum Roll-in zu Beginn eines Transaktionsschrittes wird zum Ende eines Transaktionsschrittes ein Roll-out, also die Sicherung der aktuellen Benutzerdaten, durchgeführt. Die Länge des Roll-ins wird als Roll-in-Zeit, die Länge des Roll-outs als Roll-out-Zeit bezeichnet. Bitte beachten Sie, dass der Roll-out nicht zur Antwortzeit eines Transaktionsschrittes beiträgt. Beim Roll-out, d. h. beim Kopieren des Benutzerkontextes aus dem lokalen Speicher des Workprozesses in den Roll-Speicher, sind die Daten des Benutzers bereits vorher an den Präsentationsserver übertragen worden.
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.
Basisadministratoren steht mit "Shortcut for SAP Systems" eine PC-Anwendung zur Verfügung, die etliche Tätigkeiten in der SAP Basis vereinfacht bzw. ermöglicht.
Wenn Sie Transaktion ST03 das nächste Mal aufrufen, zeigt das System automatisch die gespeicherte Sicht an.
Wenn Sie mehr zum Thema SAP Basis wissen möchten, besuchen Sie die Webseite www.sap-corner.de.
Abhängig vom Ergebnis dieser Untersuchung sollten Sie die Größe bzw. die maximal erlaubten Einträge des betroffenen Puffers um 10 bis 50 % erhöhen.