SAP Jobsteuerung
SMT1 Trusted – Trusting Verbindungen
Richtzeiten für einen optimalen Array-Fetch liegen bei unter 10 ms pro selektiertem Satz. Die konkrete Laufzeit ist allerdings stark von der WHEREBedingung, dem verwendeten Index und der Art und Weise abhängig, wie effektiv die Daten gespeichert sind.
Für die Performance und die Performanceanalyse ist es primär nicht von Bedeutung, über welches Entwicklungsszenario eine Datenbankanwendung auf eine SAP-HANA-Datenbank gelangt ist. Sie kann mit denselben Methoden analysiert und im Problemfall hoffentlich optimiert werden.
SAP Basis ist einfacher
Ein zweiter Zugriff in Abbildung 5.1 erfolgt auf die Tabelle VBAP. Bei diesem Zugriff sind nicht alle Schlüsselfelder in der WHERE-Bedingung eindeutig spezifiziert. Es können also mehrere Sätze übertragen werden. In unserem Beispiel werden allerdings fünf Sätze übertragen (Rec = 5). Die Datensätze werden in einem oder mehreren Fetches in Paketen zum Applikationsserver übertragen (Array Fetch). Ein Array-Fetch trägt im Vergleich zur Übertragung einzelner Sätze in einer Client-Server-Umgebung dazu bei, die Performance einer Anwendung zu verbessern. Der zweite Zugriff erfolgt über einen effizienten Index, daher bleibt die Dauer der Ausführung ebenfalls deutlich unter 10 ms. Der dritte Zugriff (wieder auf die Tabelle VBAK) erfolgt über ein Feld, zu dem es keinen effizienten Index gibt. Daher ist die Dauer dieser Anweisung deutlich größer als die der vorherigen.
Eine Performanceanalyse mit dem Debugger nehmen Sie wie folgt vor: Starten Sie das zu untersuchende Programm in einem zweiten Modus in der Workprozess-Übersicht (Transaktion SM50). Aus der WorkprozessÜbersicht gelangen Sie mit der Funktion Debugging in den Debugger. Indem Sie mehrfach hintereinander in den Debugger springen, können Sie die Coding-Stellen im Programm mit hohem CPU-Bedarf identifizieren. Oft sind dies LOOP ... ENDLOOP-Schleifen über große interne Tabellen. Den aktuellen Hauptspeicherbedarf erhalten Sie (im »klassischen« Debugger) mit der Funktion Springen > Weitere Bilder > Speicherverbrauch. Prüfen Sie, ob ein Programmfehler oder eine Fehlbedienung des Programms vorliegt, sodass übermäßig viel Speicher angefordert wird. Als Richtwert mag Ihnen dienen, dass ein Programm, das im Dialogbetrieb von mehreren Benutzern ausgeführt wird, nicht mehr als 100MB allokieren sollte. Zur Erstellung einer Liste der im Speicher gehaltenen Objekte des Programms navigieren Sie im »klassischen« Debugger ab SAP NetWeaver AS ABAP 6.20 mit Springen > Zustandsanzeigen > Speicherverbrauch. Auf der Registerkarte Speicherverbrauch > Ranglisten finden Sie eine Liste von Objekten und deren Speicherverbrauch. In den Versionen AS ABAP 4.6 und 6.10 gelangen Sie zu einer Speicherverbrauchsliste über den Pfad Springen > System > Systembereiche. Geben Sie im Feld Bereich »ITAB-TOP25« ein. Sie erhalten so eine Liste der 25 größten internen Tabellen. Im »neuen« Debugger blenden Sie zunächst das Speicheranalyse-Werkzeug ein, indem Sie auf die Schaltfläche für ein neues Werkzeug klicken und dann unter den angebotenen Werkzeugen im Ordner Speicherverwaltung die Speicheranalyse auswählen. Auf dem Eingangsbildschirm wird daraufhin angezeigt, wie viel Speicher vom analysierten internen Modus allokiert bzw. verwendet wird. Auf der Registerkarte Speicherobjekte finden Sie eine Liste der größten Speicherobjekte – das können interne Tabellen, Objekte, anonyme Datenobjekte oder Strings sein.
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.
Detaillierte Informationen dazu finden Sie im SAP Support Portal unter http://service.sap.com/unicode und in SAP-Hinweis 790099.
Die Erfahrung zeigt, dass Performanceprobleme in großen SAP-ERP-Installationen mit mehr als zehn Applikationsservern meist durch Engpässe auf dem Datenbankserver hervorgerufen werden.