TRANSPORTMANAGEMENT
Migration der SAP-Systeme in HANA DB
Während Dialog-Workprozesse im Wesentlichen den globalen SAP Extended Memory nutzen (wie vorher beschrieben), ist für Nicht-Dialog-Workprozesse primär die Nutzung von lokalem SAP Heap Memory vorgesehen. Die Reihenfolge der Speicherbelegung von Dialog- und Nicht-Dialog-Workprozessen, die zusammenfasst, ist also gerade komplementär zueinander. Der Grund für die unterschiedliche Implementierung ist, dass Nicht-Dialog-Workprozesse ihre Benutzerkontexte nicht austauschen müssen, da Hintergrund-, Verbuchungs- und Spoolaufträge immer vollständig von einem Workprozess ausgeführt werden – es findet in Nicht-Dialog-Workprozessen also kein Benutzerwechsel statt. Daher ist vorgesehen, dass Nicht-Dialog-Workprozesse im Wesentlichen lokalen SAP Heap Memory nutzen, um den globalen SAP Extended Memory für Dialog-Workprozesse zu reservieren.
SAP HANA kann genutzt werden, um Suite Accelerator genannte Anwendungen zu betreiben. Bei dieser Art von Anwendungen wird SAP HANA als sekundäre Datenbank neben der SAP Business Suite betrieben. Als Beispiel für diese Klasse von Anwendungen sei der CO-PA Accelerator genannt. Daten, die der Accelerator benötigt, werden in die HANA Datenbank repliziert. Der Benutzer arbeitet weiter mit der gewohnten Benutzeroberfläche im SAP-Business-Suite-System, die SAP-Business-Suite-Anwendung delegiert den Datenbankzugriff auf die SAP-HANA Datenbank. Das heißt, der Benutzer profitiert von der Performanceoptimierung durch die SAP-HANA-Datenbank, ohne dass sich seine gewohnte Benutzeroberfläche für ihn ändert. Dieses Szenario ist dazu gedacht, SAP-Kunden einen schnellen, punktuellen Nutzen von SAP HANA zu bieten. Es ist aber als Zwischenlösung zu sehen und in Abbildung 1.4 auch nicht aufgeführt.
SKILLS & ROLLEN
Schließlich bleibt noch die Möglichkeit, dass der SAP-Kernel beim Betriebssystem Speicher anfordert, das Betriebssystem diesen jedoch nicht zur Verfügung stellen kann. Im Protokoll des Fehlers STORAGE_PARAMETERS_WRONG_SET finden Sie z. B. den Eintrag »Das Programm hatte bereits 109.890.288 Byte vom Betriebssystem über 'malloc' angefordert, als das Betriebssystem bei einer erneuten Speicheranforderung meldete, dass kein Speicher mehr zur Verfügung steht.« Ursachen können falsche Einstellungen der Betriebssystemparameter, Grenzen aufgrund der Architektur des Betriebssystems oder ein zu kleiner Auslagerungsspeicher sein. Beschränkungen der Betriebssysteme führen auch dazu, dass die SAP-Instanz bei falsch gewählten SAP-Profilparametern nicht startet.
Wenn Sie mehr zum Thema SAP Basis wissen möchten, besuchen Sie die Webseite www.sap-corner.de.
Benutzerkontexte werden zum Großteil im SAP Extended Memory gespeichert. Der SAP Extended Memory wird als Shared Memory allokiert: Somit können alle SAP-Workprozesse einer SAP-Instanz die dort abgelegten Benutzerkontexte direkt bearbeiten. Beim Roll-in wird daher nicht der gesamte Benutzerkontext in den lokalen Speicher der Workprozesse kopiert, sondern es werden nur noch die Adressen kopiert, unter denen Benutzerkontext im SAP Extended Memory zu finden ist, also die sogenannten Pointer. Der Umfang der beim Roll-in bzw. beim Roll-out kopierten Daten wird durch die Verwendung des SAP Extended Memorys um ein Vielfaches reduziert, was zu einer drastischen Beschleunigung des Roll-Vorgangs führt. In der Regel wird das SAP-System so konfiguriert, dass der Großteil der Benutzerkontextdaten im SAP Extended Memory gespeichert wird.
Mit "Shortcut for SAP Systems" werden Aufgaben im Bereich der SAP Basis vereinfacht und fehlende Funktionen des Standards ergänzt.
ABAP-/Dynpro-Generierung durchführen Mit dieser Option legen Sie fest, ob die mit den Support Packages ausgelieferten Programme und Dynpros während des Einspielens generiert werden sollen.
So viele Informationen... wie kann man die aufheben, so dass man sie bei Bedarf wiederfindet? Dafür eignet sich Scribble Papers ganz hervorragend.
Abhilfe schafft hier das Reduzieren der Quote abap/heap_area_(non)dia (siehe auch SAP-Hinweise 193529 und 1147109).