Monatliche Reportings / Reviews
Migration in die Wolke: Azure, Amazon, Google, andere
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).
Dies ist das Herzstück des SAP-Systems. Im klassischen Drei-Schichten-Modell wäre dies die Logik- oder Steuerungsschicht. Ein oder mehrere Applikationsserver hosten auf dieser Ebene die nötigen Dienste für die unterschiedlichen Anwendungen. Diese Applikationsserver stellen alle Dienste bereit, die von den SAP-Anwendungen benötigt werden. In der Theorie könnte ein einziger Server diese Rolle ausfüllen. Praktisch sind diese Dienste in den meisten Fällen auf mehrere Server verteilt, die jeweils unterschiedlichen Anwendungen dienen.
EINLEITUNG
Der SAP Paging Memory besteht analog zum Roll-Bereich aus einem Speicherbereich im Shared Memory des Applikationsservers (dem SAP-Paging-Puffer) und einer SAP-Paging-Datei auf einer Festplatte des Applikationsservers. Die Größe des SAP Paging Memorys und des SAP-Paging-Puffers wird durch die SAP-Profilparameter rdisp/PG_MAXFS und rdisp/PG_SHM eingestellt. Der SAP Paging Memory ist im Vergleich zu anderen Speicherbereichen weniger performancekritisch. rdisp/PG_MAXFS sollte allerdings ausreichend groß gewählt werden, um Programmabbrüche mit den Fehlern TSV_TNEW_PG_CREATE_FAILED oder SYSTEM_NO_MORE_PAGING zu verhindern. Der vorgeschlagene Wert von 32.000 (entsprechend 256 MB) sollte für alle normalen Anforderungen ausreichen. Steht der SAP-Profilparameter auf 32.000 und kommt es trotzdem zu Abbrüchen, liegt mit hoher Wahrscheinlichkeit ein Fehler im Programm vor (siehe entsprechende Hinweise im SAP Support Portal).
Ein oft genutzter Trick von Administratoren ist, Zeitpuffer einzukalkulieren, bevor der nachfolgende Job gestartet wird. Die Pufferzeiten sind nötig, weil man nicht genau vorhersagen kann, wie lange ein Job bis zur Fertigstellung benötigt, da die Dauer von vielen unkalkulierbaren Parametern abhängt. Da es wenig sinnvoll ist, Sicherungen und SAP Jobs gleichzeitig durchzuführen, werden diese Aufgaben meistens nacheinander und nicht parallel erledigt. In komplexeren Umgebungen summieren sich die Datensicherungsdauern, Zeitpuffer und Joblaufzeiten so weit auf, dass die zur Verfügung stehende Zeit nicht mehr ausreicht, alle Aktivitäten im zur Verfügung stehenden Zeitkorridor durchzuführen. Hier können Werkzeuge helfen, die mit Statusabhängigkeiten arbeiten und dann automatisch den nächsten Job starten, wenn sein Vorgängerjob fehlerfrei abgearbeitet wurde.
Tools wie "Shortcut for SAP Systems" ergänzen fehlende Funktionen im Bereich der SAP Basis.
Diese Grenze ergibt sich aus den physischen Beschränkungen der Hardware.
Auf www.sap-corner.de finden Sie ebenfalls viele nützliche Informationen zum Thema SAP Basis.
Ab Basisversion 6.10 sind maximal 16 Modi möglich, bei älteren Versionen sechs.