Systemreplikation ist besser
SE11 ABAP Dictionary
Auf wie viele Rechner und SAP-Instanzen soll die SAP-Applikationsebene verteilt werden? Grundsätzlich sollten Sie nicht unnötig viele Rechner und Instanzen einrichten, da mit jedem zusätzlichen Rechner und jeder zusätzlichen Instanz ein erhöhter Verwaltungs- und Überwachungsaufwand einhergeht. Folgende Argumente sprechen jedoch für die Einrichtung mehrerer Instanzen: Fällt ein Rechner bzw. eine Instanz aus, müssen die verbleibenden Rechner bzw. Instanzen die zusätzliche Last auffangen. Die Folgen sind dabei umso drastischer, je weniger Rechner bzw. Instanzen konfiguriert wurden. Anmeldegruppen (siehe Abschnitt 7.2.4, »Dynamische Benutzerverteilung: Anmeldegruppen konfigurieren«) sind ein wichtiges Mittel zur Lastverteilung. Diese können aber nur eingesetzt werden, wenn mehrere Instanzen konfiguriert sind. Bei sehr großen Instanzen können singuläre Ressourcen wie der Dispatcher, die Roll- oder die Pufferverwaltung zum Performanceengpass werden. Wann dieser Effekt jedoch auftritt, muss im Einzelfall geprüft werden. SAP gibt an, dass Sie Instanzen bis zu 512 GB Größe konfigurieren können.
Ein Performanceproblem aufgrund falscher Lastverteilung diagnostizieren Sie zum einen durch einen Vergleich der CPU-Auslastung und der Paging- Raten für die verschiedenen Rechner (im Betriebssystemmonitor). Zusätzlich sollten Sie zum anderen im Workload-Monitor die Antwortzeiten für die verschiedenen Rechner vergleichen.
Anmeldegruppen nach Sprachen, Ländern oder Unternehmenseinheiten
Im Berechtigungsumfeld gibt es neben der Berechtigungsvergabe für SAP-Benutzer eine Reihe wichtiger SAP-Basis-Einstellungen, die Sie regelmäßig prüfen sollten, um einen vollumfänglichen Schutz Ihres SAP-Systems nach innen und außen sicherstellen zu können. Beispielsweise ist besonders im Rahmen einer Revision darauf zu achten, dass Änderungen am SAP-System stets nachvollziehbar bleiben. Wie Sie dies am besten umsetzen können und worauf zu achten ist, möchte ich Ihnen in diesem Blog aufzeigen.
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.
Das Tool "Shortcut for SAP Systems" eignet sich sehr gut, um viele Aufgaben in der SAP Basis einfacher und schneller zu erledigen.
Wenn eine Rolle für einen oder mehrere Kataloge im Launchpad berechtigt wurde, werden beim Starten des Launchpads die entsprechenden Kataloge und Gruppen im App-Finder nur für die berechtigten User angezeigt.
Die Webseite www.sap-corner.de bietet viele nützliche Informationen zum Thema SAP Basis.
Will man mit Ansible einfache Automatisierungen – zum Beispiel das Starten und Stoppen von SAP-Umgebungen – realisieren, muss man einen hohen manuellen Aufwand und komplizierte Skripte in Kauf nehmen.