Nutzdaten
CLOUDABILITY, OUTSOURCING UND OUTTASKING
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.
Diesen Umstand illustriert folgendes Beispiel: Auf der Applikationsebene werden z. B. Programme, Tabellen- und Felddefinitionen und Inhalte von Konfigurationstabellen in den Puffern vorgehalten. Die richtige Einstellung dieser Puffer gewährleistet, dass weniger Daten vom Datenbankserver gelesen werden müssen. Das Lesen über den Tabellenpuffer der SAPApplikationsinstanz ist etwa um den Faktor 10 bis 100 schneller als das Lesen über den Datenbankserver.
Troubleshooting und Support bei auftretenden Problemen
Der Abschnitt Memory enthält Informationen über den physisch vorhandenen Hauptspeicher (Feld Physischer Speicher) und Werte über das Betriebssystem-Paging. Unter Swap finden Sie den aktuell allokierten Auslagerungsspeicher (Swap-Space). Der Auslagerungsspeicher muss größer als die Summe des konfigurierten Speicherbereichs sein.
Wenn Sie die Umsetzung Ihres Systems auf Unicode noch vor sich haben, müssen Sie ebenfalls einen höheren Ressourcenbedarf einplanen, der sich aus der Tatsache ergibt, dass Datenstrukturen für Zeichentypvariablen mehr Hauptspeicher benötigen und auch für das Rechnen mit diesen breiteren Variablen mehr CPU-Leistung benötigt wird. SAP-Hinweis 1139642 gibt den Mehrbedarf zwischen 10 und 30 % für die CPU und 40 bis 50 % für den Hauptspeicher an. Bitte berücksichtigen Sie, dass es sich bei den Angaben um Durchschnittswerte handelt, die in konkreten Installationen auch unter- oder überschritten werden können. Auch der Speicherplatz der Datenbank verändert sich abhängig vom verwendeten Code. Die Datenbankgröße kann dabei anwachsen, sich in bestimmten Fällen aber auch verringern. Detaillierte Informationen dazu finden Sie im SAP Support Portal unter http://service.sap.com/unicode und in SAP-Hinweis 790099. Eine Verifizierung über den GoingLive Functional Upgrade Service wird dringend empfohlen.
Einige fehlende Funktionen in der Basisadministration werden durch "Shortcut for SAP Systems" ergänzt.
TEST_IMPORT In diesem Schritt wird geprüft, ob es noch Objekte gibt, die sich in noch nicht freigegebenen Aufgaben befinden und während des Einspielens überschrieben werden.
Beides wird benötigt, um die Lösungsdokumentation im Zusammenspiel mit anderen Komponenten nutzen zu können.