Vertikale und horizontale Skalierung
Allokierter und physischer Speicher
Haben Sie sich schon einmal gefragt, wofür es eigentlich einen Reiter Personalisierung bei der Rollenpflege in der PFCG bzw. bei der Benutzerdatenpflege in der SU01 gibt? Diese Frage beantworte ich für Sie in diesem Blog-Beitrag. Wofür brauchen wir den Reiter Personalisierung? Durch diesen Reiter haben Sie Zugriff auf die zentrale Ablage für Personalisierungsdaten. Der Sinn und Zweck dieser Ablage ist es, eine Speicherungsmöglichkeit für benutzer- und rollenspezifische Daten zu schaffen, ohne dass zusätzliche Datenbanktabellen angelegt werden müssen. Diese Daten sollen dann bei sämtlichen Manipulationen an Benutzern und Rollen berücksichtigt werden. Die Funktionalität umfasst zunächst eine generische Ablage für benutzer- und rollenspezifische Daten und den zentralen Zugriff auf diese Daten durch die Benutzer- bzw. Rollenpflege. Außerdem wird die Möglichkeit geboten, über eine festgelegte Schnittstelle bereits existierende Tabellen mit benutzerspezifischen Daten an den zentralen Zugriff anzukoppeln. Um Personalisierungsdaten in der zentralen Ablage abzulegen, muss für die Daten ein Schlüssel vergeben werden: Dies erfolgt über die Registrierungstransaktion PERSREG. Die angelegten Personalisierungsdaten werden in der generischen Ablagetabelle gespeichert. Der Zugang zu dieser wird durch die Klassenmethoden der Klasse CL_PERS_ADMIN bereitgestellt. Verschiedene Personalisierungsebenen Die Daten können entweder zum Benutzer, zu Rollen oder zum System abgelegt werden. Zu einem Benutzer können dann alle ihm zugewiesenen Daten (über Rolle oder eigene Einstellungen) auf einmal ausgelesen werden.
Zu erwähnen ist an dieser Stelle, dass es lediglich Sinn ergibt, lesend mittels SELECT-Statement auf die Tabellen zuzugreifen, um eine schnelle Ansicht der Ergebnisse zu erhalten. Mittels des DBACOCKPITs ist es nicht möglich, ganze Tabellenstrukturen mittels Create Table zu erstellen. Für solche Anwendungszwecke stellt SAP andere, bessere Möglichkeiten zur Verfügung. Ein weiterer wichtiger Punkt ist, dass sobald ein Nutzer die notwendigen Berechtigungen zur Nutzung der Transaktion DBACOCKPIT besitzt, dieser potentiell (bei entsprechenden Berechtigungen auf die Tabellen) lesend auf das gesamte SAP-System zugreifen kann. So kann mit einer Query beispielsweise die gesamte Nutzertabelle ausgelesen werden. Daher ist die Transaktion grundsätzlich mit Vorsicht zu genießen und ausschließlich an Administratoren zu vergeben. Die Berechtigung zur Steuerung der Aufrufe durch das DBACOCKPIT werden ähnlich wie in der Transaktion SE16 / SE16N gehandhabt. Beim Aufruf der Tabelle wird das Berechtigungsobjekt S_TABU_DIS bzw. S_TABU_NAM mit einer bestimmten Aktivität geprüft. So kann lediglich auf die Tabellen bzw. Tabellenberechtigungsgruppen zuegegriffen werden, für die entsprechende Werte in den genannten Berechtigungsobjekten zugewiesen sind. Genaueres zur Vergabe von Berechtigungen auf einzelne Tabellen können Sie hier nachlesen. Darüber hinaus besteht die Möglichkeit, einmal ausgeführte SQL Statements zu speichern und so jederzeit erneut auszuführen, um Änderungen in der Ergebnismenge zu erkennen, ohne jedes Mal das SQL-Statement neu formulieren zu müssen. Der Editor bietet Ihnen zudem die Möglichkeit, die Abfrage der SQL Statements im Hintergrund zu starten. Das Ergebnis erhalten Sie durch den Aufruf der Transaktion SM37, in der Ihnen das Ergebnis in einem Spool-File ausgegeben wird.
SAP Interactive Forms by Adobe
Für die Verteilung der Applikationsebene auf Instanzen gilt also die Regel, dass so viele Instanzen wie nötig, aber so wenige wie möglich installiert werden sollten. Grundsätzlich unterscheiden sich die Ziele der horizontalen Skalierbarkeit der Applikationsebene nicht wesentlich von denen der horizontalen Skalierbarkeit der Datenbankebene. Es gibt allerdings einen entscheidenden Unterschied: Bei der Skalierbarkeit von Anwendungsservern entscheidet das Logon-Balancing darüber, welcher Anwendungsserver die Anfrage eines Benutzers bearbeitet. Dort liegt auch der Speicher des Benutzers (Benutzerkontext). Ein Umziehen von Speicherkontexten findet auf der Applikationsebene nicht statt (außer bei expliziter Parallelisierung, z. B. über RFC-Aufrufe). Bei SAP HANA dagegen wird der Knoten für die Prozessierung der Anfragen durch die Verteilung der Daten festgelegt.
Ein weiterer großer Themenschwerpunkt ist die Migration von SAP-Systemen, sowohl örtlich von einem Rechenzentrum in ein anderes als auch von einem Betriebssystem auf ein anderes oder von einem Datenbank-Typ auf einen anderen. Hierbei kommt in der Regel erneut das Tool SWPM zum Einsatz.
Einige fehlende Funktionen in der Basisadministration werden durch "Shortcut for SAP Systems" ergänzt.
Noch vor zehn Jahren gab es für SAP Basis-Experten nicht viel mehr als den SAP Solution Manager.
Auffällig ist die Tabelle LT_MEM mit einer Größe von 494MB.