Systemaktualisierungen
OPEN INNOVATION ALS INNOVATIONSLEITBILD
Das SAP Basis Plug-In ist abwärts kompatibel und folgt der Release- und Wartungsstrategie des SAP R/3 Plug-In. SAP liefert es zusammen mit dem SAP R/3 Plug-In aus.
Anhand der Workload-Analyse diagnostizieren Sie ein allgemeines Performanceproblem. Anhand des Vergleichs der Workload-Daten für unterschiedliche Tage grenzen Sie das Problem auf einen bestimmten Zeitraum ein. Auffällig sind in diesem Zeitraum hohe Datenbankzeiten, insbesondere für logische Änderungen. Bei näherer Analyse der Fehlerprotokolldatei der Datenbank stellt sich heraus, dass nachts ein Archiver Stuck aufgetreten ist. Ein Archiver Stuck tritt bei einer Oracle-Datenbank auf, wenn das Archive-Verzeichnis für Redo-Log-Dateien voll ist. Somit kann keine Redo- Information mehr geschrieben werden; die Datenbank und damit auch die SAP-Instanzen bleiben stehen. Nachdem das Problem behoben worden ist, setzen Datenbank und SAP-Instanzen ihre Arbeit ohne Fehler fort. Morgens wird das Problem vom Datenbankadministrator behoben. Im Tagesmittel führt der Archiver Stuck an diesem Tag zu erhöhten Datenbankzeiten (insbesondere für logische Änderungen). Diese suggerieren bei der Analyse des Workload-Monitors eine schlechte Datenbankperformance, obwohl diese in Wirklichkeit gut ist, nachdem das Problem behoben wurde.
WE19 Testwerkzeug für die IDoc-Verarbeitung
Der Erweiterte Speicher enthält also vor allem Nutzerkontexte von verschiedenen Workprozessen, falls diese nicht vollständig in den Rollbereich geladen werden können. Da der Speicherbereich für alle Workprozesse erreichbar ist, können die Workprozesse also auch auf fremde Nutzerkontexte, die hier liegen zugreifen. Außerdem enthält der Erweiterte Speicher einen Globalen Bereich in dem Daten unabhängig von Nutzerkontexten abgelegt werden können. Die Größe des erweiterten Speichers wird bestimmt durch die Werte von em/initial_size_MB und em/global_area_MB. Hierbei bestimmt der erste Parameter die Größe des Speicherbereichs in dem Nutzerkontexte abgelegt werden können und der zweite die Größe des globalen Bereichs. Parameter für den Privaten Speicher Zu guter Letzt gibt es noch den privaten Speicher, welcher nur dann genutzt wird, wenn der Nutzerkontext eines Workprozesses alle anderen ihm zur Verfügung stehenden Speicherbereiche aufgebraucht hat, also seinen Anteil des erweiterten Speichers und seinen Rollbereich. In diesem Fall geht der Workprozess in den PRIV modus. Ein Workprozess im privaten Modus ist an seinen aktuellen Nutzerkontext gebunden und wird erst dann wieder frei für andere Aufgaben, wenn die aktuelle Anfrage abgeschlossen ist. Falls er dabei den ihm zugewiesenen privaten Speicher vollständig aufgebraucht hat, wird der Workprozess anschließend neu gestartet und der Speicher wieder freigegeben. Dieses verhalten wird mit dem Parameter abap/heaplimit kontrolliert. Zeitweise kann der Nutzerkontext der Wert von abap/heaplimit dabei auch überschreiten. Die Parameter abap/heap_area_total, abap/heap_area_dia und abap/heap_area_nondia bestimmen eine obere Grenze für den privaten Speicher. Der Parameter abap/heap_area_total definiert wie viel privaten Speicher alle Workprozesse insgesamt nutzen können. Die Parameter abap/heap_area_dia und abap/heap_area_nondia hingegen bestimmen, wie viel privaten Speicher ein einzelner (Nicht-)Dialog-Workprozess nutzen darf.
Diese Variante bietet sich an, wenn mehrere Transaktionen gleichzeitig auf ihre bestehende Zuordnung zu einem bestimmten Nutzer hin geprüft werden sollen. Bei dieser Variante müssen zunächst sämtliche Rollen ermittelt werden, die dem betreffenden Nutzer bereits zugeordnet wurden. Dies erfolgt in der Transaktion SE16N über Eingabe der Tabelle AGR_USERS. Außerdem lässt sich in diesem Bild die Begrenzung der maximalen Trefferzahl aufheben. Hier muss nun der betreffende Nutzer eingetragen werden. Außerdem sollte die Ausgabe lediglich auf die Rollen beschränkt werden. Nach dem Ausführen der Anfrage werden nun sämtliche Rollen, die dem vorher eingegebenen Nutzer zugeordnet sind, angezeigt. Diese werden nun komplett markiert und kopiert. Anschließend wird in der Transaktion SE16N wieder ein Schritt zurück gegangen und diesmal die Tabelle AGR_1251 gewählt. Hier werden nun sämtliche Rollen, die zuvor kopiert wurden, eingefügt. Zusätzlich wird nach dem Objekt S_TCODE und den Transaktionen, nach deren Zuordnung gesucht werden soll, gefiltert. Achtung: Bei der Eingabe der Transaktionscodes ist auf Groß- und Kleinschreibung zu achten! An dieser Stelle kann außerdem die Ausgabe auf die Rollen und Objektwerte (das sind in diesem Fall die Transaktionen) beschränkt werden. Nach dem Ausführen der Anfrage werden von den eingegebenen Transaktionen nun diejenigen angezeigt, die der Nutzer bereits ausführen kann. Zusätzlich ist ersichtlich, durch welche Rolle die Transaktion zugeordnet wurde. Abschließend ist festzustellen, dass sich die SUIM zur Ermittlung bestimmter Transaktionen mit Nutzerzuordnung nur bedingt eignet. Zwar lässt die Suche über das Berechtigungsobjekt S_TCODE auch die Betrachtung mehrerer Transaktionen zu. Da im Ergebnis allerdings die Zuordnung von betrachteten Transaktionen zu Rollen fehlt, lässt sich die Transaktion SUIM nur dafür sinnvoll nutzen, eine einzige Transaktion auf ihre bestehende Zuordnung zu einem bestimmten Nutzer hin zu überprüfen.
Etliche Aufgaben der SAP Basis können mit "Shortcut for SAP Systems" einfacher und schneller erledigt werden.
Er/sie pflegt und überwacht SAP-Anwendungen und ist auch für deren Entwicklung verantwortlich.
Auf www.sap-corner.de finden Sie ebenfalls viele nützliche Informationen zum Thema SAP Basis.
Damit bilden sich für diese Kerne mehrere Warteschlangen, aus, zwischen denen der Kern hin- und herschaltet.