WE21 Ports in der IDoc-Verarbeitung
Werkzeuge zur Überwachung
Erst beim OPEN werden der Datenbank die konkreten Werte für die WHERE-Bedingung übergeben (MANDT = 100 etc.). Ein PREPARE ist nur bei der ersten Ausführung einer Anweisung nötig, sofern sie nicht aus dem SAP Cursor Cache verdrängt wird. Anschließend kann die Anweisung, die einmal präpariert (geparst) wurde, immer wieder mit einem OPEN oder REOPEN geöffnet werden. Da die DECLARE- und PREPARE-Operationen beim ersten Durchlauf ausgeführt wurden, ist in unserem Beispiel nur die OPEN-Operation zu beobachten.
Nehmen Sie zu jeder ABAP-Eigenentwicklung einen SQL-Trace vor, und zwar entweder auf dem Produktivsystem oder einem System mit einem repräsentativen Testdatenbestand. Erstellen Sie aus der Trace-Grundliste heraus eine verdichtete Zusammenfassung, um die SQL-Anweisungen mit den längsten Laufzeiten zu ermitteln: Traceliste > Trace nach SQL-Anweisungen verdichten Erstellen Sie eine Liste identischer Zugriffe, um SQL-Anweisungen zu ermitteln, die mehrfach identisch ausgeführt werden: Traceliste > Identische Selects anzeigen Entscheiden Sie anhand dieser Listen, ob das Programm abgenommen werden kann oder ob es vom zuständigen ABAP-Entwickler nachgebessert werden muss. Sichern Sie diese Daten zusammen mit der Programmdokumentation. Sollte sich später die Performance des Programms verschlechtern (sei es aufgrund einer Modifikation oder aufgrund des wachsenden Datenbestands), können Sie durch einen erneuten SQL-Trace die Ursachen für die Performanceverschlechterung aufspüren. Nehmen Sie diese Performanceüberwachung nach jeder größeren Modifikation des Programms vor.
Prepare-Operation
Wenn der zusätzliche Speicher im Erweiterten Speicherbereich für den Nutzerkontext immer noch nicht ausreicht, kann der optionale zweite Rollbereich dafür genutzt werden. Die Größe des zweiten Rollbereichs wird durch die Differenz aus den Parametern ztta/roll_first und ztta/roll_area bestimmt. Der Rollbereich wurde im Kernel-Release 7.4 abgeschafft, weshalb diese Parameter von da an obsolet sind. Stattdessen wird der Nutzerkontext heute direkt im Erweiterten Speicher abgelegt.
Beim anschließenden PREPARE wird die Zugriffsstrategie für die Anweisung Prepare-Operation vom Datenbankprozess ermittelt. Dabei ist im Feld Statement die Anweisung mit einer Variablen (INSTANCE =:A0, in Abbildung 5.1 nicht gezeigt) zu sehen. Um die Anzahl der relativ laufzeitintensiven PREPARE-Operationen so klein wie möglich zu halten, hält jeder Workprozess eines Anwendungsservers eine bestimmte Anzahl von bereits übersetzten SQL-Anweisungen in einem eigens dafür vorgesehenen Puffer (SAP Cursor Cache). Jeder SAP-Workprozess puffert die Operationen DECLARE, PREPARE, OPEN und EXEC in seinem SAP Cursor Cache. Sobald der Workprozess einmal einen Cursor für eine DECLARE-Operation geöffnet hat, kann er diesen Cursor immer wieder verwenden (bis der Cursor nach einer gewissen Zeit aufgrund der begrenzten Größe der SAP Cursor Caches verdrängt wird).
Tools wie z.B. "Shortcut for SAP Systems" sind bei der Basisadministration extrem nützlich.
In diesem Szenario operieren also mehrere Datenbankinstanzen, die auch als Knoten bezeichnet werden.
Einige nützliche Tipps aus der Praxis zum Thema SAP Basis finden Sie auch auf der Seite www.sap-corner.de.
Dies ermöglicht im Ganzen eine leichtere Umsetzung der Roadmap.