SWELS Ereignis-Trace ein-/ausschalten
Reduzierung der Softwareinstanzen
Im weiteren Verlauf des Projekts holen Sie ein oder mehrere Angebote von Hardwarepartnern ein. Die Hardwarepartner erstellen das Hardware-Sizing, da nur sie die Leistungsfähigkeit ihrer Hardware bewerten können. Sofern nötig, greifen die Hardwarepartner über ihre SAP Competence Center auf die entsprechenden Sizing-Experten der SAP zurück. Um den Sizing-Prozess zu vereinfachen, hat SAP folgendes Standardverfahren definiert: Legen Sie zu Ihrem Einführungsprojekt ein Sizing-Projekt im Quick Sizer im SAP Support Portal an. Dort legen Sie die für das Sizing notwendigen Daten ab. Unterstützt der Quick Sizer das Sizing für die ausgewählten Prozesse nicht, verwenden Sie die entsprechenden Sizing-Guidelines. Anschließend gewähren Sie den Hardwarepartnern, von denen Sie ein Sizing-Angebot wünschen, Zugriff auf dieses Sizing-Projekt im SAP Support Portal, indem Sie ihnen das Kennwort für das entsprechende Projekt mitteilen. Die Links zu den jeweiligen Internetseiten der Hardwarepartner finden Sie ebenfalls im Quick Sizer. Die Hardwarepartner erstellen nun aufgrund der von Ihnen hinterlegten Daten ein konkretes Hardwareangebot.
Stellen Sie anhand dieser Monitore fest, dass einzelne Platten stark ausgelastet sind (Auslastung (%) > 50 %), liegt ein potenzieller I/O-Engpass vor. Aus dem SAP-System heraus ist allerdings nur eine sehr beschränkte Aussage über I/O-Probleme möglich. Eine detaillierte Analyse kann nur mit Mitteln des Hardwarepartners durchgeführt werden.
Anzeige des Einspielstatus
Um eine optimale Performance zu erreichen, sollte das Kopieren der Daten beim Kontextwechsel auf ein Minimum beschränkt bleiben, mit anderen Worten, es soll möglichst wenig SAP Roll Memory benutzt werden. Daher wird für alle Betriebssysteme empfohlen, ztta/roll_first = 1 zu setzen. Was passiert nun, wenn der SAP Extended Memory voll belegt ist? In diesem Fall sind zwei Szenarien möglich, die beide nicht performanceoptimal sind: Da der SAP Extended Memory voll belegt ist, werden Benutzerkontexte bis zu einer Größe von ztta/roll_area im lokalen Roll-Bereich abgelegt. Bei jedem Kontextwechsel müssen damit unter Umständen mehrmals Daten in der Größe von mehreren Megabyte kopiert (gerollt) werden; dies führt typischerweise zu Wartesituationen in der Roll-Verwaltung, insbesondere wenn der Roll-Puffer voll ist und Daten in die Roll-Datei geschrieben werden müssen. Erfahrungen zeigen, dass bei großen Applikationsservern mit mehr als 100 Benutzern die Performance in diesen Fällen schlagartig und drastisch einbricht. Um in dieser Situation Abhilfe zu schaffen, kann man den lokalen RollBereich (ztta/roll_area) reduzieren. Wenn der SAP Extended Memory voll belegt ist, wird nur noch wenig Roll Memory verwendet, und die Menge der beim Kontextwechsel zu kopierenden Daten reduziert sich. Stattdessen werden die Kontextdaten im SAP Heap Memory abgelegt – dies hat zur Folge, dass die Workprozesse gar nicht mehr rollen, sondern in den PRIV-Modus gehen, d. h. einem Benutzer zwischen den Transaktionsschritten exklusiv zugeordnet bleiben. Befinden sich zu viele Workprozesse gleichzeitig im PRIV-Modus, stehen dem Dispatcher nicht genügend freie Workprozesse zur Verfügung. Es kann daher zu hohen Dispatcher-Wartezeiten und damit ebenfalls zum Einbruch der Performance kommen.
Transportaufträge von einer Systemlinie in eine andere zu transportieren oder Transportaufträge von Drittanbietern in das SAP-System zu importieren gehört auch zu den gelegentlichen Aufgaben eines SAP-Basis-Administrators. Wie schon in meinem letzten Blogbeitrag zur Systemänderbarkeit möchte ich Ihnen hier eine Möglichkeit bieten, dieses Thema schnell abrufbar darzubieten. Somit finden Sie am Ende wieder eine Schritt-für-Schritt Anleitung, welche Sie befolgen können, wenn Sie das Thema schon inhaltlich verstanden haben, aber nur die Schritte benötigen. Was sind die Voraussetzungen? Zu Transportaufträgen gehören zwei Dateien, welche als "data" und "cofiles" betitelt sind. Diese Dateien bestehen aus einer sechsstelligen alphanumerischen Kombination und einer Dateiendung, welche häufig das System darstellt, aus welchem die Dateien exportiert wurden. Hierbei ist das erste Zeichen immer ein K (die cofiles-Datei) oder ein R (die data-Datei). Für unser Beispiel nennen wir die Dateien einmal K12345_DEV und R12345_DEV. Diese Dateien werden natürlich für einen Import in das eigene SAP-System benötigt. Weiterhin benötigen Sie Zugang zu dem Filesystem bzw. den SAP-Verzeichnissen, da sie die oben genannten Dateien dort manuell einfügen müssen. Zusätzlich dazu wird die Transaktion STMS im SAP-System benötigt, da sie dort die Transportaufträge an die Importqueue anhängen. Wenn Sie dies nun alles zur Verfügung haben, können wir mit dem Import starten: Wie ist das Vorgehen? Vorbereitung auf Betriebssystemebene. Im ersten Schritt müssen die Dateien in das Transportverzeichnis des SAP-System kopiert werden. Dieses liegt normalerweise unter /usr/sap/trans, kann aber je nach System auch individuell geändert werden. Falls Sie sichergehen wollen, dass Sie im richtigen Verzeichnis arbeiten, können Sie in der Transaktion AL11 nachschauen, welches Verzeichnis unter "DIR_TRANS" angegeben ist. Dies ist das richtige Verzeichnis in dem wir arbeiten wollen. Hier werden nun die vorhandenen Dateien hineinkopiert und zwar die cofiles-Datei (K12345_DEV) in den cofiles-Ordner (/usr/sap/trans/cofiles) und die data-Datei (R12345_DEV) in den data-Ordner (/usr/sap/trans/data). Hinweis: Gerade bei Unternehmen mit mehreren Systemen auf mehreren Servern müssen in diesem Fall noch die Zugriffsberechtigungen und der Datei-Owner geändert werden, sodass der Import im Zielsystem keine Probleme macht.
Tools wie "Shortcut for SAP Systems" ergänzen fehlende Funktionen im Bereich der SAP Basis.
Verständliche Erklärung der Rollen Oftmals haben Rollen keine sprechenden Namen und für den Entscheider ist nicht klar erkennbar, welche konkreten Berechtigungen hinter einer Rolle stecken.
Dies muss gemeinschaftlich evaluiert und entschieden werden.