REDUKTION UND VERMEIDUNG VON ORGANISATORISCHEN REIBUNGSPUNKTEN
Sicherheitsupdates
Die Definition, organisatorische Gliederung wie auch die Namensgebung der SAP-Basis ist durch vorangegangene SAP-Software-Versionen und Komponenten historisch bedingt. Hieraus resultiert auch die Wahrnehmung der SAP-Basis und der damit in Verbindung stehende Arbeitsschwerpunkt des SAP-NetWeaver und des ABAP-Systemkerns, der heute immer noch weit verbreitet ist. Jedoch hat sich das Tätigkeitsfeld hinsichtlich Aufgaben- und Technologieumfang stark verändert und wird sich, betrachtet man die perspektivische Ausrichtung und Produktstrategie von SAP und die sich veränderten Rollen der IT, weiter verändern. Um dieser Veränderung gerecht zu werden und die Wahrnehmung sowohl im Gesamtkontext des SAP-Ökosystems als auch innerhalb des eigenen Unternehmens zu verändern, muss die SAP-Basis ein neues Selbstverständnis entwickeln und ein Marketing zur Publikation der eigenen Leistungsfähigkeit etablieren. Die zugrunde liegenden Informationen finden sich in der Masterarbeit in den Kapiteln 7.4 und 9.2 wieder.
Mit der Basisversion 7.40 (Kernel 7.40) treten folgende Neuerungen in Kraft: Der Roll-Memory ist komplett in den Extended Memory integriert worden, die entsprechenden Parameter, die das Verhalten des RollBereichs definieren, sind obsolet (SAP-Hinweis 2085980). Der Tabellenpuffer liegt nun im SAP EG Memory. Durch die Umverteilung dieser Speicherbereiche steht damit netto weniger SAP Extended Memory für die Benutzerkontexte zur Verfügung, obwohl sich in der Summe der Speicherbedarf nicht geändert hat. Durch eine zu knappe Einstellung von SAP Extended Memory (em/initial_size_MB) und SAP EG Memory (em/global_area_MB) kann das damit zu logischen Speicherengpässen führen. Diese Parameter müssen also entsprechend vergrößert werden (siehe SAP-Hinweis 2148571). Alternativ sollten Sie erwägen, mit Version 7.40 auch auf UNIX-Plattformen auf das Zero Administration Memory Management umzusteigen und sich erst einmal auf dessen Einstellungsvorschläge zu verlassen.
Leistungsfähigkeit (SAPS) von aktuellen Rechnertypen
Für die Performance und die Performanceanalyse ist es primär nicht von Bedeutung, über welches Entwicklungsszenario eine Datenbankanwendung auf eine SAP-HANA-Datenbank gelangt ist. Sie kann mit denselben Methoden analysiert und im Problemfall hoffentlich optimiert werden.
Neben der Auswertung der Antwortzeiten sollten Sie die folgende Analyse durchführen, die man als die »Suche nach der verlorenen Zeit« bezeichnen könnte. Wie oben bereits erwähnt, gibt es zwei unterschiedliche Quellen der Zeitmessung. Alle Zeiten, außer der CPU-Zeit, werden vom SAP-Workprozess gemessen, und nur die CPU-Zeit wird vom Betriebssystem ermittelt. Die folgende Analyse ist ein Plausibilitätscheck zur Überprüfung, ob die beiden Zeitmessungen miteinander vereinbar sind. Dazu subtrahiert man von der gesamten mittleren Antwortzeit alle Zeiten, in denen der SAP-Workprozess keine CPU-Zeit benötigt, nämlich die Dispatcher-Wartezeit, die Datenbankzeit, die Enqueue-Zeit und die Roll-Wartezeit. Während der Processing-Zeit werden im Wesentlichen Programme bearbeitet, und daher sollte in dieser Zeit CPU-Kapazität »verbraucht« werden. Daher sollten Processing-Zeit und CPU-Zeit in der gleichen Größenordnung liegen. Als Richtwert für die Praxis sollte die Differenz aus Processing- Zeit und CPU-Zeit nicht größer als 10 % sein. Größere »Fehlzeiten« deuten auf Performanceprobleme hin.
Das Tool "Shortcut for SAP Systems" eignet sich sehr gut, um viele Aufgaben in der SAP Basis einfacher und schneller zu erledigen.
Auf www.sap-corner.de finden Sie ebenfalls viele nützliche Informationen zum Thema SAP Basis.
Eine Vergrößerung des zu kleinen Extended Memorys (Parameter em/initial_ size_MB) oder eine Analyse der Programme mit hohem Speicherbedarf schafft in diesem Fall Abhilfe.
Anschließend gewähren Sie den Hardwarepartnern, von denen Sie ein Sizing-Angebot wünschen, Zugriff auf dieses Sizing-Projekt im SAP Support Portal, indem Sie ihnen das Kennwort für das entsprechende Projekt mitteilen.