So transportieren Sie abgelehnte Transportaufträge im SAP-System
GUI- und Enqueue-Zeit
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.
Bei SAP HANA kann die Datenbank horizontal skaliert werden, d. h., Daten können auf unterschiedliche Server verteilt werden. In diesem Szenario operieren also mehrere Datenbankinstanzen, die auch als Knoten bezeichnet werden.
Betriebssystemgrenzen erreicht
Die Erfahrung zeigt, dass die Performance drastisch einbricht, wenn der SAP Extended Memory erschöpft ist. Ein produktives Arbeiten mit Instanzen ist in einer derartigen Situation in der Regel nicht mehr möglich. Die Überwachung des SAP Extended Memorys muss daher höchste Priorität haben. Grundsätzlich sollten Sie Extended Memory eher verschwenderisch allokieren. Nicht verwendeter Extended Memory wird vom Betriebssystem ausgelagert. Als grobe Faustregel gilt: Mindestens 6 bis 10 MB Extended Memory sollten pro Benutzer allokiert werden. Etwa 70 bis 120 % des physischen Hauptspeichers des Rechners können als Extended Memory allokiert werden. Diese Faustregeln sind natürlich stark release- und applikationsabhängig. Sie müssen allerdings dafür sorgen, dass der vorhandene Auslagerungsspeicher des Betriebssystems (Swap Space) groß genug ist und das Betriebssystem die gewünschte Größe an Speicher überhaupt verwalten kann. Weitere Informationen dazu finden Sie in Kapitel 6, »Speicherkonfiguration«.
SAP-Basis bezieht sich auf die Verwaltung des SAP-Systems, die Aktivitäten wie Installation und Konfiguration, Lastausgleich und Leistung von SAP-Anwendungen, die auf dem Java-Stack und SAP ABAP laufen, umfasst. Dazu gehört auch die Wartung verschiedener Dienste in Bezug auf Datenbank, Betriebssystem, Anwendungs- und Webserver in der SAP-Systemlandschaft sowie das Stoppen und Starten des Systems. Hier finden Sie einige nützliche Informationen zu dem Thema SAP Basis: www.sap-corner.de.
Im Rahmen eines zu schaffenden Innovations-Teams oder Testlaboratoriums ist es notwendig, Ideen außerhalb der SAP-Basis zuzulassen bzw. bewusst andere Ideenquellen innerhalb und außerhalb des Unternehmens in Anspruch zu nehmen. Dies können bspw Geschäftsbereiche, externe Dienstleister, Hochschulen oder auch Vortragsreihen zu bestimmten Themengebieten sein.
Verwenden Sie "Shortcut for SAP Systems", um viele Aufgaben in der SAP Basis einfacher und schneller zu erledigen.
AMDPs dagegen sind spezifisch für SAP HANA.
Wenn Sie bereits eine Queue definiert haben, diese Queue aber nicht ihren Erfordernissen entspricht bzw. Fehler aufgetreten sind, dann können Sie diese Queue wieder löschen.
Ein Zettelkasten, in dem schnell Daten aller Art abgelegt und wiedergefunden werden können. Das verspricht Scribble Papers. Anfangs sieht das Programm sehr spartanisch aus. Aber wenn erst einmal eine kleine Struktur vorhanden ist, erkennt man die große Flexibilität dieses kleinen Helfers.