Kenntnissen oder Erfahrungen in den Bereichen SAP-NetWeaver-Technologien (bspw. AS-Java, AS-ABAP, S/4HANA SAP PI, SAP BI, SAP Gateway oder SAP-Foldersmanagement)
Backup Konzepte
Das Sizing im Fall eines SAP-Versionswechsels oder eines Wechsels auf Unicode wird in zwei Schritten durchgeführt: Im ersten Schritt ermitteln Sie die bestehende Last im Produktivsystem. Anhand der entsprechenden SAP-Hinweise ermitteln Sie den Faktor für die zusätzlich zu erwartende Last nach dem Versionswechsel und/oder dem Wechsel auf Unicode. Wird ein Versionswechsel über mehrere Versionen in einem Schritt durchgeführt, müssen die Upgrade-Faktoren kumuliert werden. Auch wenn die Unicode-Konvertierung zusammen mit einem Upgrade durchgeführt wird, müssen Sie die Faktoren kumulieren. Multiplizieren Sie die ermittelten Faktoren für CPU und Hauptspeicher mit den aktuellen Auslastungswerten. Das Ergebnis zeigt Ihnen, ob die bestehende Hardwareinstallation die zusätzliche Last aufnehmen kann.
Die Einsatzfähigkeit der Datenbank aufrechtzuerhalten ist weniger eine Frage der Performanceoptimierung – vielmehr ist dies Aufgabe der Datenbankadministration; sie wird daher in diesem Buch nicht explizit behandelt. Literatur dazu finden Sie in den Handbüchern zur Datenbankadministration. Erstellen Sie aufgrund dieser Literatur einen auf Ihr Unternehmen abgestimmten Eskalationsplan, der z. B. folgende Fragen umfasst: Welche Maßnahmen stellen sicher, dass ein potenzieller Überlauf der Log-Bereiche und des Dateisystems rechtzeitig erkannt wird? Wie können Sie analysieren, welcher Datenbankfehler aufgetreten ist, wenn das SAP-System steht? Wo befindet sich die Datenbankfehlerprotokolldatei Ihrer Datenbank? Wie heißen die entscheidenden Fehlermeldungen? Was muss getan werden, wenn die Fehlersituation eingetreten ist? Muss das SAP-System bzw. die Datenbank neu gestartet werden? Kann eine solche Fehlersituation auf einem Testsystem simuliert werden?
Anlegen von Mandanten, Kopieren von Mandanten, Löschen von Mandanten, etc.
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.
Hierdurch wird der technische User zum Dialog-User und eine Anmeldung im SAP System ist uneingeschränkt möglich. Also meldet sich Johannes mit dem bekannten Passwort des RFC Users im Produktivsystem an. Dank sehr weitreichender Berechtigungen hat er fortan Zugriff auf allerlei kritische Tabellen, Transaktionen und Programme in Produktion. Mit der Identität des RFC Users beginnt Johannes mit der technischen Kompromittierung des Produktivsystems… RFC Sicherheit: Alles nur erfunden – oder alltägliche Bedrohung? Ob nun eine simple Verkleidung, veränderte biometrische Eigenschaften oder ein gekaperter, technischer User im SAP System: die Grundlage der Kompromittierung ist dieselbe. Eine Person nutzt eine andere Identität, um Zugang und Berechtigungen zu geschützten Bereichen zu bekommen. Außerdem hätte das Übel in allen drei Geschichten durch Pro-Aktivität verhindert werden können. Wann haben Sie sich das letzte Mal Gedanken über die Sicherheit Ihrer RFC Schnittstellen gemacht? Können Sie mit Sicherheit sagen, dass alle Ihre technischen RFC User nur die Berechtigungen besitzen, die sie auch tatsächlich benötigen? Und wissen Sie eigentlich wer genau die Passwörter dieser User kennt? Können Sie zu 100% ausschließen, dass nicht jetzt in diesem Moment ein SAP User mit falscher Identität Ihre Produktivsysteme infiltriert? Change now: Es geht um Pro-Aktivität! Doch bevor Sie jetzt beginnen und sich auf die Suche nach dem „Identitäten-Wandler“ begeben (was ich wirklich nicht empfehlen möchte!), schlage ich vor, dass Sie die Wurzel des Übels fassen und Ihre RFC Sicherheit proaktiv stärken. Wenn Sie also mehr erfahren möchten, habe ich hier folgende 3 Tipps für Sie: 1) Unser E-Book über SAP RFC-Schnittstellen 2) Unser kostenloses Webinar zum Thema RFC-Schnittstellen bereinigen 3) Blogbeitrag über unser Vorgehen zur Optimierung von RFC Schnittstellen Wie immer freue ich mich auf Ihr Feedback und Ihre Kommentare direkt unterhalb dieser Zeilen!
Etliche Aufgaben im Bereich der SAP Basis können mit "Shortcut for SAP Systems" wesentlich erleichtert werden.
Dadurch stellen Sie sicher, daß in Zukunft weitere Support Packages eingespielt werden können.
Diese Möglichkeit ist insbesondere dann vorteilhaft, wenn es sich um ein neues Thema handelt und im Unternehmen noch kein großes Know-How vorhanden ist.