SAP Basis Sehr gute IT-Kenntnisse - insbesondere von SAP-Lösungen - SAP Admin

Direkt zum Seiteninhalt
Sehr gute IT-Kenntnisse - insbesondere von SAP-Lösungen
Tools für SAP-Experten
Als Skalierbarkeit eines Programms bezeichnet man die Abhängigkeit der Laufzeit eines Programms von der Datenmenge. Viele Operationen sind linear von der Datenmenge abhängig (t = O(n)), d. h., die Laufzeit steigt linear mit der Datenmenge an. Beispiele dafür sind Datenbankselektionen in großen Tabellen ohne oder mit ungeeigneter Indexunterstützung und Schleifen über interne Tabellen im Programm. Lineare Skalierbarkeit ist für die Bearbeitung mittlerer Datenmengen akzeptabel. Wenn sie bei Programmen, die große Datenmengen bearbeiten sollen, nicht vermieden werden kann, muss über Parallelisierung nachgedacht werden. Besser als eine lineare Skalierbarkeit sind für die Performance natürlich konstante Laufzeiten (t = O(1)) oder eine logarithmische Abhängigkeit (t = O(log n)). Logarithmische Abhängigkeiten treten z. B. bei Datenbankselektionen in großen Tabellen mit optimaler Indexunterstützung oder bei Leseoperationen in internen Tabellen mit binärer Suche auf. Da die Logarithmusfunktion nur sehr langsam ansteigt, ist in der Praxis zwischen konstanten und logarithmisch ansteigenden Laufzeiten nicht zu unterscheiden. Inakzeptabel für die Bearbeitung mittlerer und großer Datenmengen sind quadratische Abhängigkeiten (t = O(n × n)) und alles, was darüber hinausgeht. Allerdings können Probleme mit quadratischer Abhängigkeit durch intelligente Programmierung in der Regel auf Abhängigkeiten der Art t = O(n × log n) zurückgeführt werden. Ein Beispiel ist das Vergleichen zweier Tabellen, die beide mit der Ordnung n wachsen. Ein Vergleich der unsortierten Tabellen würde zu einer quadratischen Abhängigkeit führen, ein Vergleich mit sortierten Tabellen zur Abhängigkeit t = O(n × log n). Da die Logarithmusfunktion nur sehr langsam ansteigt, ist in der Praxis zwischen einem Ansteigen t = O(n × log n) und einem linearen Ansteigen nicht zu unterscheiden.

Ein modernes Notebook mit einem 2-Kern-Prozessor erreicht heute 2.000 SAPS, ein typischer Server mit zwei Prozessoren und 44 Kernen kommt auf etwa 100.0000 SAPS. Server am oberen Ende des Leistungsspektrums bringen es auf über 500.000 SAPS. Bis zum Jahr 2005 konnte man ein stetiges Wachstum der CPU-Geschwindigkeit und damit der Leistungsfähigkeit von Prozessoren beobachten. Dieser Trend ist aber inzwischen gestoppt. Stattdessen beobachten wir die Entwicklung von Mehr-Kern-Technologien und damit ein Wachstum des parallelen Durchsatzes. Typische Rechner am oberen Leistungsspektrum verfügen über 256 und mehr Kerne.

Wenn Sie mehr zum Thema SAP Basis wissen möchten, besuchen Sie die Webseite www.sap-corner.de.
RSMEMORY: Dynamisches setzen von Speicherparametern
Die Einzelsatzstatistik schreibt für die fünf (änderbar über den Parameter stat/rfcrec) teuersten Funktionsbausteine eines Transaktionsschrittes die Funktionsbausteinnamen in den statistischen Satz. In diesen Profilen finden Sie die Last dieser jeweils fünf teuersten Funktionsbausteine. Diese Statistiken eignen sich insbesondere für einen Einstieg in die Anwendungsanalyse, da Sie in diesen Statistiken die Funktionen mit der höchsten Last identifizieren können.

Ist das Erreichen der Quoten ztta/roll_extension* und abap/ heap_area_(non)dia nicht die Ursache des Problems, untersuchen Sie mithilfe des SAP-Speicherkonfigurationsmonitors (ST02), ob zum Zeitpunkt des Abbruchs der Roll-Bereich, der SAP Extended Memory oder der SAP Heap Memory zu 100 % belegt waren. Ist dies der Fall, vergrößern Sie, wenn möglich, die entsprechenden Speicherbereiche. Die hier relevanten SAP-Profilparameter sind rdisp/ROLL_MAXFS, em/initial_size_MB und abap/heap_area_total.

Verwenden Sie "Shortcut for SAP Systems", um viele Aufgaben in der SAP Basis einfacher und schneller zu erledigen.

Die Importqueue bleibt sauber und übersichtlich.

So viele Informationen... wie kann man die aufheben, so dass man sie bei Bedarf wiederfindet? Dafür eignet sich Scribble Papers ganz hervorragend.


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.
Zurück zum Seiteninhalt