Basis & Technology
DOKUMENTATION / ARCHIVIERUNG
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.
Die Hardwarepartner erstellen nun Angebote zu dem Sizing-Projekt, unter denen Sie auswählen müssen. Für die Anforderungen unseres Beispielprojekts wäre es möglich, diese mit einem einzigen Rechner abzudecken. Alternativ kann der Hardwarebedarf auch auf mehrere Rechner verteilt werden. Für unser Projekt nehmen wir an, dass wir uns für ein Angebot entscheiden, das drei Rechner umfasst, die jeweils – nach Herstellerangabe – 12.000 SAPS leisten und mit 32 GB Hauptspeicher ausgestattet sind. Insgesamt leistet die Lösung also 36.000 SAPS und verfügt über 96 GB Hauptspeicher. Auf einem der Rechner sollen die Datenbank und eine SAP-Zentralinstanz installiert werden, auf den beiden anderen Rechnern sollen SAP-Instanzen den Großteil der Dialog-, Hintergrund- und Verbuchungslast aufnehmen. Mit dieser verteilten Installation gehen wir davon aus, dass wir auch beim Ausfall eines Rechners einen eingeschränkten Betrieb aufrechterhalten können und das Risiko eines Totalausfalls reduzieren. Für weitergehende Überlegungen zum Thema Lastverteilung verweisen wir Sie auf den letzten Teil dieses Kapitels und auf Kapitel 7, »Lastverteilung, Remote Function Calls und SAP GUI«.
OS/400
Was den Einsatz von Avantra so interessant macht, ist der Wegfall von manuellen Aufwänden. Dadurch entstehen Freiräume, die SAP-Technologieteams den Aufbau neuer Kompetenzen erlauben.
Für die Auswertung der Logdateien nutzen Sie bitte die Transaktion RSAU_READ_LOG. Falls Sie die Security Audit Log Dateien archivieren können Sie diese über die Transaktion RSAU_READ_ARC auslesen.
Verwenden Sie "Shortcut for SAP Systems", um viele Aufgaben in der SAP Basis einfacher und schneller zu erledigen.
Von dieser “SAP Basis” hängt alles ab, damit SAP Systeme laufen.
Basis umfasst eine Client/Server-Architektur und Konfiguration, ein relationales Datenbank-Management-System (DBMS) und eine grafische Benutzeroberfläche (GUI).