SM58 Transaktionaler RFC
Die Mandantensteuerung
Netzwerkprobleme zwischen Datenbank und Applikationsserver erkennt man am sichersten durch folgenden Trace-Vergleich: Führen Sie denselben SQL-Trace mindestens zweimal durch, zum einen auf dem Applikationsserver, der sich auf demselben Rechner befindet wie die Datenbank und direkt an die Datenbank konnektiert ist, und zum anderen auf einem Applikationsserver, der über das TCP/IP-Netz an die Datenbank angeschlossen ist. Vergleichen Sie beide SQL-Traces. Beobachten Sie deutlich höhere Antwortzeiten auf dem Applikationsserver, der über das Netz konnektiert ist (d. h. 50 % höhere Zeiten oder mehr), liegt ein Netzwerkproblem vor. Führen Sie diesen Test bei niedriger Systembelastung durch, und wiederholen Sie ihn zur Sicherheit mehrfach, um Laufzeitdifferenzen aufgrund von Pufferladevorgängen auf der Datenbank und auf den Applikationsservern auszuschließen. Dieser Test funktioniert natürlich nur, wenn Sie einen Applikationsserver installiert haben, der über IPC an die Datenbank angeschlossen ist.
Zur Identifizierung der teuren SQL-Anweisungen, die zum Zeitpunkt der Analyse ausgeführt werden, reicht häufig schon die Workprozess-Übersicht, welche die Tabelle und die ausgeführte Operation anzeigt und aus der Sie in den ABAP-Code und damit zur SQL-Anweisung navigieren können. Darüber hinaus verfügen alle Datenbanksysteme über einen Monitor zur Analyse der SQL-Anweisungen, die momentan auf der Datenbank prozessiert werden: den Datenbankprozessmonitor. Dieser Monitor zeigt Ihnen die derzeit aktiven Datenbankprozesse.
Nutzen für Ihr Unternehmen
Das Betriebssystem verwaltet zwei Typen von Speicher, den lokalen Speicher (Local Memoryoder Heap Memory) und den globalen Speicher (Shared Memory). Lokaler Speicher ist immer genau einem Betriebssystemprozess zugeordnet, d. h., nur dieser eine Prozess kann diesen Speicherbereich beschreiben bzw. von ihm lesen. Shared Memory ist dagegen mehreren Betriebssystemprozessen zugänglich. So liegen z. B. alle SAP-Puffer im Shared Memory, weil alle SAP-Workprozesse einer SAP-Instanz die SAPPuffer beschreiben und von ihnen lesen müssen. Daneben wird für jeden SAP-Workprozess lokaler Speicher angelegt. Zum lokalen Speicher eines SAP-Workprozesses gehören z. B. der SAP Cursor Cache und der Eingabe-/Ausgabe-Puffer für die Übertragung der Daten von der bzw. zu der Datenbank. Die Summe aus lokalem Speicher und Shared Memory ist der virtuell allokierte Speicher. Befinden sich mehrere SAP-Instanzen oder eine SAP-Instanz und eine Datenbankinstanz auf einem Rechner, können die Prozesse einer Instanz immer nur auf den Shared Memory »ihrer« Instanz zugreifen, nicht aber auf die globalen Objekte anderer Instanzen.
Der initiale Teil des Benutzerkontextes wird im lokalen SAP-Roll-Bereich des Workprozesses abgelegt. Da es sich bei diesem Speicherbereich um lokalen Speicher handelt, kann jeder SAP-Workprozess nur auf seinen eigenen RollBereich zugreifen. Beim Roll-out muss der Inhalt des von ihm benutzten lokalen Roll-Bereichs des Workprozesses gesichert werden. Dazu wird der lokale Roll-Bereich in den globalen SAP-Roll-Bereich kopiert. Der globale RollBereich ist entweder ein Speicherbereich im Shared Memory des Applikationsservers (der sogenannte SAP-Roll-Puffer) oder eine Datei auf einer Festplatte des Applikationsservers (die SAP-Roll-Datei) bzw. eine Kombination aus beidem. Der globale Roll-Bereich ist allen Workprozessen einer Instanz zugänglich. Beim Roll-in wird der Benutzerkontext aus dem globalen RollBereich in den lokalen Roll-Bereich des neuen Workprozesses kopiert. Der Benutzer kann auf diese Weise mit seinen alten Daten weiterarbeiten.
Mit "Shortcut for SAP Systems" steht ein Tool zur Verfügung, das einige Aufgaben im Bereich der SAP Basis erheblich erleichtert.
Die Webseite www.sap-corner.de bietet viele nützliche Informationen zum Thema SAP Basis.
Allerdings prüft es nicht die tatsächliche Lastverteilung.
SCHRITT 3: FESTLEGUNG DER ZIELE Im Rahmen der Festlegung der Ziele wird bestimmt, für welche Mission und Vision der Dienstleistungsanbieter steht.