Angezeigte statistische Sätze
Web Dispatcher
Ein BW-System spielt häufig in größeren Unternehmen eine sehr zentrale Rolle. Hier werden die Daten von den verschiedenen angebundenen Quellsystemen zentral ausgewertet und reportet. Ein früherer Kunde von mir hatte ein BW-System, an welches insgesamt über 20 andere SAPProduktivsysteme angeschlossen waren. Bei so einer großen und meist lebendigen System- Landschaft ist es normal, dass von Zeit zu Zeit einzelne Systeme zurückgebaut werden. Gerade bei großen SAP-Landschaften gibt es allerdings strenge Regelungen betreffend Berechtigungen von technischen RFC-Nutzern. Aus diesem Grund wird das einfache "Rechtsklick --> Löschen" eines Quellsystems in der RSA1 häufig nicht zum Ziel führen, sondern in eine gescheiterte Berechtigungsprüfung. Mit diesem Blogbeitrag zeige ich Ihnen einen Workaround, wie sie ein Quellsystem sauber von einem BW-System trennen können mit Hilfe der Funktionsbausteine RSAR_LOGICAL_SYSTEM_DELETE und RSAP_BIW_DISCONNECT.
In komplexeren Systemumgebungen können am Tag tausende, wenn nicht gar mehrere zehntausende SAP Jobs laufen. Durch deren Abhängigkeiten entsteht hohe Komplexität. Will man als Administrator oder als Admin-Team die Übersicht behalten, ist man auf ein aussagekräftiges Monitoring angewiesen. Es muss jederzeit klar sein, welche Jobs gelaufen und welche nicht gelaufen sind, um den ordnungsgemäßen SAP Betrieb sicherzustellen. Im Idealfall wird man bei kritischen Fehlern per E-Mail oder SMS informiert. Der Trend der Internationalisierung, des Outsourcings und des Mischbetriebs mit On-Premise und On-Demand Systemen führen dazu, dass SAP Landschaften oftmals weit verteilt sind. Dadurch wird das Monitoring schwieriger und gleichzeitig muss die Übersichtlichkeit gewahrt werden. Eine Integration des SAP Jobmanagements und der Job Beantragungen in ein zentrales System, wie beispielsweise den SAP Solution Manager ist daher sinnvoll und nützlich, um IT Service Prozesse sinnvoll zu ergänzen und die Prozessabläufe zu beschleunigen.
Von der Workload-Übersicht zum konkreten Problem
Der Speicherbedarf der SAP-Puffer hängt entscheidend von den SAP-Modulen ab, die Sie auf der entsprechenden SAP-Instanz betreiben. Insgesamt ergibt sich für die SAP-Puffer ein typischer Speicherbedarf von 5 bis 15 GB, was u. a. davon abhängt, ob Unicode verwendet wird. Die größten Puffer sind der SAP-Programmpuffer mit einer Größe von 5 GB und größer und der SAP-Tabellenpuffer (für generische und für Einzelsatzpufferung) mit einer Größe von 1 GB und größer. Der Speicherbereich für die SAP-Puffer wird pro SAP-Instanz allokiert. Wird das SAP-System auf viele Instanzen mit jeweils wenigen Benutzern und Workprozessen verteilt, ist der Speicherbedarf des Gesamtsystems größer, als wenn das System auf relativ wenige Instanzen mit jeweils mehr Benutzern und Workprozessen pro Instanz aufgeteilt wird.
Heute ist mit „SAP Basis“ häufig nicht (nur) die Software-Architektur gemeint. Stattdessen ist der Begriff nicht selten eine Aufgabenbeschreibung. Diese bezieht sich auf die grundlegende Administration des Systems: Installation und Konfiguration, Ressourcenmanagement, Wartung und Monitoring der SAP-Setups eines Unternehmens. Dazu können die Nutzerverwaltung, das Patch-Management und die Systemüberwachung gehören. Die Backup-Politik, Rechtemanagement und tägliche Maintenance-Tasks sind ebenfalls Aufgaben der Basis-Admins.
Tools wie z.B. "Shortcut for SAP Systems" sind bei der Basisadministration extrem nützlich.
Dieses Szenario umfasst auch die Unterstützung für SAP-Business-Objects-Anwendungen.
Lösen Sie in diesem Fall erst das andere Performanceproblem, und untersuchen Sie anschließend, ob sich die Datenbanksperren dann schneller auflösen.