Parametrisierung des Betriebssystems, der Datenbanken und des SAP-Systems zur Sicherstellung eines performanten und störungsfreien Betriebs
PERFORMANCE TUNING
Da die Datenbankzeit vom Applikationsserver gemessen wird, umfasst diese nicht nur die Zeit, die die Datenbank zum Bereitstellen der Daten benötigt, sondern auch die Zeit des Netzwerktransfers. Ein Netzwerkproblem zwischen Datenbank- und Applikationsserver schlägt sich also in einer erhöhten Datenbankzeit nieder. Darüber hinaus zählt zur Datenbankzeit auch die Zeit für das Bereitstellen der Daten im ABAP-Server. Dies lässt sich in folgender Formel konkretisieren: Datenbankzeit (ST03) = Datenbankserverzeit + Netzwerklaufzeit + Zeit für die Datenübertragung (Client-Server-Kommunikation) Auf dem ABAP-Server werden zusätzlich die Datenbankzeiten für direktes Lesen, sequenzielles Lesen und Änderungen (inklusive Commits) ermittelt. Auf der Datenbankseite stehen je nach Datenbanksystem detaillierte Statistiken über die Bestandteile der Datenbankserverzeit zur Verfügung, wie Sie in Abschnitt 2.3, »Datenbankanalyse«, gesehen haben.
Um ein Sizing durchführen zu können, reicht es nicht aus, die Leistungsfähigkeit der Rechner miteinander vergleichen zu können, es werden auch Faktoren für den Vergleich der unterschiedlichen Szenarien untereinander benötigt. Die konkreten Zahlen variieren leicht zwischen den SAP-Versionen.
Vergrößerung der Last bei geändertem Applikationsprofil
Neben internen Sicherheitsvorgaben erfordern teilweise auch nationale und internationale Richtlinien alle audit- und sicherheitsrelevanten Benutzeraktionen zu erfassen. Mit dem Security Audit Log (SAL) haben Sie die Möglichkeit, jegliche Änderungen bspw bei Benutzern, Benutzerstammsätzen, aber auch Rollen und Gruppen zu protokollieren.
Benutzerkontextdaten werden von Dialog-Workprozessen in folgender Reihenfolge abgelegt: Beim Start einer Transaktion wird der Benutzerkontext bis zu einer Größe von ztta/roll_first im lokalen Roll-Bereich des Workprozesses gespeichert. ztta/roll_first soll auf 1 (Byte) gesetzt werden. Dies bedeutet, dass zunächst überhaupt kein SAP Roll Memory belegt werden soll. Aus technischen Gründen werden allerdings immer administrative Daten in der Größenordnung von bis zu 100 kB im lokalen Roll-Bereich des Workprozesses abgelegt, auch wenn ztta/roll_first = 1 ist. Wächst die Größe des Benutzerkontextes über den Wert ztta/roll_first hinaus, werden die Daten im SAP Extended Memory abgelegt. Ist der SAP Extended Memory erschöpft oder erreicht der Benutzerkontext die Quote von ztta/roll_extension*, wird der verbleibende Rest des lokalen Roll-Bereichs bis zu einer Größe von ztta/roll_area genutzt. Wächst der Kontext weiter an und übersteigt der Speicherbedarf auch diesen Wert, allokiert der Workprozess SAP Heap Memory nach Bedarf. Die Verwendung von SAP Heap Memory hat den Nachteil, dass dieser Speicher lokal ist und auch nicht mehr – wie beim SAP Roll Memory – in einen globalen Speicherbereich kopiert (gerollt) werden kann. Wenn ein Prozess SAP Heap Memory allokiert, kann der Kontext nicht mehr zu einem anderen Workprozess übertragen werden. Der Workprozess bleibt einem Benutzer exklusiv zugeordnet. Diesen Zustand bezeichnet man als PRIV-Modus (Private Mode). In der Workprozess-Übersicht wird dieser Zustand in den Spalten Status und Grund durch die Werte hält bzw. PRIV dokumentiert.
Einige fehlende Funktionen in der Basisadministration werden durch "Shortcut for SAP Systems" ergänzt.
Bei der Einführung und beim Betrieb neuer Anwendungen bieten sich verschiedene Möglichkeiten.
Wenn sie nicht erzeugt wurde, dann stellen Sie sicher, daß in den SPAM-Einstellungen [Seite 10] Datenfile neu erzeugen eingeschaltet ist.