SU53 Berechtigungsdaten anzeigen
Das Basis-System umfasst insgesamt drei Schichten (Abbildung 1):
Wenn zwei Benutzer in einem Zeitraum jeweils 100 Transaktionsschritte Last ausgeführt haben, sind beide gleich aktiv gewesen. Das bedeutet aber noch nicht, dass sie beide die gleiche Last auf dem System erzeugt haben. Wenn z. B. der erste Benutzer Finanzbelege eingegeben hat und 100 Transaktionsschritte mit einer mittleren Antwortzeit von 500ms ausgeführt hat, hat er das System 50 Sekunden lang belastet. Ein zweiter Benutzer hat z. B. Controlling-Berichte erstellt und für seine Arbeit 100 Transaktionsschritte mit einer mittleren Antwortzeit von 5 Sekunden benötigt, also das System 500 Sekunden lang in Anspruch genommen. Offensichtlich hat der zweite Benutzer bei gleicher Aktivität eine zehnfach größere Last erzeugt. Wie man an diesem Beispiel erkennt, ist also das Produkt aus der Anzahl der Transaktionsschritte und der mittleren Antwortzeit ein Maß für die erzeugte Last. (Will man exakt sein, muss man von der Antwortzeit die Dispatcher-Wartezeit und die Roll-Wartezeit abziehen, denn während der Auftrag in der Dispatcher-Queue bzw. auf die Ausführung eines RFCs wartet, verursacht er keine Last auf dem System.) Die Belastung, die die unterschiedlichen Task-Typen auf der Datenbank erzeugen, lässt sich analog anhand der gesamten Datenbankzeit (Transaktionsschritte mal mittlere Datenbankzeit) vergleichen. Ebenso erfolgt der Vergleich der CPU-Belastung auf dem Applikationsserver. Die Verteilung der Zeiten (Datenbankzeit, CPU-Zeit etc.) spiegelt also die Lastverteilung auf dem System besser wider als die bloße Anzahl der Transaktionsschritte.
Über SPAM/SAINT-Updates (kurz SPAM-Update) erhalten Sie Aktualisierungen und Verbesserungen des SAP Patch Manager und des SAP Add-On Installation Tool. Es gibt immer einen SPAM-Update pro Korrekturstand, der im Laufe der Zeit entsprechend aktualisiert wird. Die Version finden Sie in der Kurzbeschreibung, zB: SPAM/SAINT update - version 4.6A/0001 Ein SPAM-Update taucht im SAPNet - R/3 Frontend in der Liste der Support Packages immer an erster Stelle, d.h. vor den anderen Support Packages, auf. Wir empfehlen, stets die neueste Version eines SPAM-Update einzuspielen, bevor Sie Support Packages einspielen. Voraussetzungen Sie können einen SPAM-Update nur dann erfolgreich einspielen, wenn keine abgebrochenen Support Packages im System sind. Wenn es abgebrochene Support Packages gibt, weist Sie ein Dialogfenster darauf hin. Sie haben dann zwei Möglichkeiten: Sie spielen zuerst die Queue vollständig ein und danach den SPAM-Update. Sie setzen den Status der Queue zurück, spielen zuerst den SPAM-Update und danach die Queue ein. Den Status der Queue können Sie mit Zusätze Status zurücksetzen Queue zurücksetzen. Beachten Sie, daß Ihr System inkonsistent ist, wenn Sie die Queue zurücksetzen, nachdem schon Objekte importiert wurden (zB nach einem Fehler im Schritt DDIC_IMPORT und folgenden). Von daher sollten Sie die Queue nur zurücksetzen, wenn vor dem Schritt DDIC_IMPORT abgebrochen wurde. Weitere Informationen finden Sie unter Schritte der SPAM [Seite 26]. Beachten Sie, daß ab SPAM/SAINT-Version 11 das Zurücksetzen der Queue nach dem Schritt DDIC_IMPORT und folgenden nicht mehr möglich ist. Vorgehensweise Überprüfen Sie, ob der angebotene SPAM-Update neuer ist als der in Ihrem System eingespielte. Die aktuelle SPAM-Version wird in der Titelleiste des SPAM-Fensters angezeigt. Um den neuesten SPAM-Update einzuspielen, wählen Sie Support Package SPAMUpdate einspielen. SPAM-Updates werden nach erfolgreichem Einspielen automatisch bestätigt. Support Package laden Verwendung Bevor Sie Support Packages einspielen können, müssen Sie zuerst die entsprechenden Support Packages laden.
sap basis
Die HANA-Datenbank (In-Memory-Datenbank) ist eine Eigenentwicklung von SAP und bringt zahlreiche Neuerungen mit sich. So wird sie zum Beispiel vom System automatisch überwacht. Zudem speichert sie nicht nur operative (vom Anwender generierte) Daten, sondern auch Systemdaten für die Steuerung von Applikationsinhalten sowie Konfigurationstabellen.
Auf jedem Applikationsserver existieren Ressourcen, die nur einmalig zur Verfügung stehen. Diese Ressourcen können nur von einem Workprozess und nicht von mehreren zugleich verwendet werden. Wenn ein Prozess diese Ressource verwenden möchte, setzt er ein Semaphor. Wenn andere Prozesse diese ebenfalls benötigen, müssen sie so lange warten, bis der das Semaphor haltende Prozess seine Aktion beendet hat. So muss z. B. immer, wenn ein Eintrag in einem SAP-Puffer geändert werden soll, ein Semaphor gesetzt werden, da nur ein einziger Prozess eine Änderung im Puffer vornehmen kann. Warten mehrere Prozesse auf ein Semaphor, bezeichnet man dies als Serialisierung. Eine weitere Operation, bei der ein Semaphor gesetzt wird, ist das Roll-in bzw. Roll-out. Dies bedeutet, dass immer nur ein Prozess nach dem anderen ein Roll-in bzw. Roll-out durchführen kann. Eine vollständige Liste der SAP-Semaphore erhalten Sie mit der Werthilfe (F1) zum Feld Gesperrte Semaphore.
Für Administratoren steht im Bereich der SAP Basis ein nützliches Produkt - "Shortcut for SAP Systems" - zur Verfügung.
Aus diesem Grund stellen verschiedene Anbieter Lösungen bereit, mittels Toolunterstützung die Überprüfung des Berechtigungswesens in Hinblick auf kritische Berechtigungen und Segregation of Duties zu automatisieren.
Die Webseite www.sap-corner.de bietet viele nützliche Informationen zum Thema SAP Basis.
Sie lesen viele Datenblöcke in den Datenpuffer des Datenbankservers und verdrängen dadurch die Daten, die von anderen SQL-Anweisungen benötigt werden.