Konfiguration sowie Wartung, Upgrades und Backup & Recovery
SAP Basis Plug-In
Wie aus dem bisher Gesagten hervorgeht, gibt es zahlreiche Gründe, weswegen alle Workprozesse eines Typs belegt sein können. Wenn Sie allerdings die bisher diskutierten Probleme ausschließen können und trotzdem ein Problem im Bereich der Workprozesse beobachten, kann es sein, dass Sie zu wenige Workprozesse konfiguriert haben. In diesem Fall sollten Sie die Anzahl der Workprozesse vergrößern. Vorher sollten Sie allerdings überprüfen, ob der Rechner über ausreichend Reserven an CPU und Hauptspeicher verfügt. Wenn die CPU schon zu 80 % ausgelastet ist, wird die Erhöhung der Anzahl der Workprozesse eher zu einer Performanceverschlechterung führen.
Einen CPU- oder Hauptspeicherengpass können Sie nach folgenden Kriterien diagnostizieren: Beobachten Sie eine hohe CPU-Auslastung oder hohe Paging-Raten im Stundenmittel? Als grobe Richtwerte geben wir an, dass die Gefahr eines Hardwareengpasses besteht, wenn die mittlere freie CPU-Kapazität (CPU idle) im Stundenmittel unter 20 % sinkt bzw. die Paging-Rate pro Stunde auf über 20 % des physischen Hauptspeichers ansteigt. Vergleichen Sie dazu auch Abschnitt 2.2.1, »Analyse eines Hardwareengpasses (CPU und Hauptspeicher)«. Prüfen Sie in einem zweiten Schritt, ob die hohe CPU-Auslastung bzw. die hohe Paging-Rate tatsächlich negativen Einfluss auf die Antwortzeit des SAP-Systems hat. Besteht der Verdacht eines Hardwareengpasses auf einem Applikationsserver, ist dies am sichersten anhand der Processing-Zeit festzustellen: Ist diese deutlich größer als die CPU-Zeit (als Richtwert Processing-Zeit > 2 × CPU-Zeit), ist dies ein Indiz dafür, dass die Workprozesse auf die CPU warten müssen. (Beachten Sie aber, dass eine erhöhte Processing- Zeit auch andere Ursachen haben kann, siehe auch Abschnitt 3.3, »Workload-Analyse«.) Zudem können erhöhte Lade-, Roll- und Dispatcher- Wartezeiten auftreten. Vermuten Sie, dass ein Hardwareengpass auf dem Datenbankserver auftritt, analysieren Sie die Datenbankzeit: Ist sie erhöht? Vergleichen Sie dazu z. B. die Datenbankzeiten im Tagesprofil zu Zeiten hoher und niedriger Last. Besteht der Verdacht auf einen Hauptspeicherengpass, vergleichen Sie, ob der virtuell allokierte Speicher deutlich größer als der physisch vorhandene Hauptspeicher ist. Sofern der virtuell allokierte Speicher kleiner ist als 1,5 × der physische Hauptspeicher, sollte ein Hauptspeicherengpass kein Thema sein (siehe auch Abschnitt 2.4.3, »Anzeige des allokierten Speichers«).
Nutzdaten
Der dritte Speicherbereich, in dem Benutzerkontexte abgelegt werden können, ist der SAP Heap Memory. Während der Roll-Bereich als lokaler Speicher von einem Workprozess bereits beim Start fest allokiert wird, wird der SAP Heap Memory als variabler lokaler Speicher bei Bedarf allokiert, d. h., wenn der Benutzerkontext eine gewisse Größe überschreitet. Es wird wieder freigegeben, nachdem die Transaktion beendet wurde.
Hier liegen alle Daten des Systems. Diese setzen sich aus dem tatsächlichen Datenbestand und dem DBMS zusammen, dem „Datenbank-Managementsystem“. Die Datenbank stammte hier in früheren Versionen von unterschiedlichen Herstellern. Beispielsweise Microsoft SQL oder Oracle. Seit SAP HANA hat sich für die IT vieles an dieser Datenschicht verändert. Denn die Datenbank stammt von SAP selbst und wird automatisch vom System überwacht. In dieser Datenbankschicht befindet sich mehr als die Arbeitsdaten. Wichtige Elemente wie die Konfigurationstabellen und Systemdaten für Steuerung und Anwendungsinhalte sind ebenfalls hier abgelegt. Dies sind die Repository-Daten, die von Anwendungen genutzt werden.
Verwenden Sie "Shortcut for SAP Systems", um viele Aufgaben in der SAP Basis einfacher und schneller zu erledigen.
Alternativ können Sie auch den Transaktionscode ST03G nutzen.
Die derzeit aktive Variante finden Sie im Eingangsbildschirm der Laufzeitanalyse im Bildschirmabschnitt Messung.