Daten im Statistiksatz
SAP Basis Training
Für die Verteilung der Applikationsebene auf Instanzen gilt also die Regel, dass so viele Instanzen wie nötig, aber so wenige wie möglich installiert werden sollten. Grundsätzlich unterscheiden sich die Ziele der horizontalen Skalierbarkeit der Applikationsebene nicht wesentlich von denen der horizontalen Skalierbarkeit der Datenbankebene. Es gibt allerdings einen entscheidenden Unterschied: Bei der Skalierbarkeit von Anwendungsservern entscheidet das Logon-Balancing darüber, welcher Anwendungsserver die Anfrage eines Benutzers bearbeitet. Dort liegt auch der Speicher des Benutzers (Benutzerkontext). Ein Umziehen von Speicherkontexten findet auf der Applikationsebene nicht statt (außer bei expliziter Parallelisierung, z. B. über RFC-Aufrufe). Bei SAP HANA dagegen wird der Knoten für die Prozessierung der Anfragen durch die Verteilung der Daten festgelegt.
Einmal hat man das Geld Person A gesendet und einmal Person B. Welcher Miner hat nun Recht? Die Lösung dazu ist, dass man den Konsensus in Zeitblöcke unterteilt, in welcher jeweils per Zufall ein Miner ausgewählt wird, der dann bestimmen kann, welche Transaktion er während dieses Blocks als Konsensus ausgewählt hat. Die Transaktionen werden in Blöcken der Kette gespeichert. In jeden Block passen nur eine begrenzte Anzahl an Transaktionen. Der Miner, der die letzte Transaktion eines Blocks löst, bevor ein neuer generiert wird, bekommt als Belohnung zusätzlich noch einen Bitcoin.
Konfiguration
Der SAP Paging Memory besteht analog zum Roll-Bereich aus einem Speicherbereich im Shared Memory des Applikationsservers (dem SAP-Paging-Puffer) und einer SAP-Paging-Datei auf einer Festplatte des Applikationsservers. Die Größe des SAP Paging Memorys und des SAP-Paging-Puffers wird durch die SAP-Profilparameter rdisp/PG_MAXFS und rdisp/PG_SHM eingestellt. Der SAP Paging Memory ist im Vergleich zu anderen Speicherbereichen weniger performancekritisch. rdisp/PG_MAXFS sollte allerdings ausreichend groß gewählt werden, um Programmabbrüche mit den Fehlern TSV_TNEW_PG_CREATE_FAILED oder SYSTEM_NO_MORE_PAGING zu verhindern. Der vorgeschlagene Wert von 32.000 (entsprechend 256 MB) sollte für alle normalen Anforderungen ausreichen. Steht der SAP-Profilparameter auf 32.000 und kommt es trotzdem zu Abbrüchen, liegt mit hoher Wahrscheinlichkeit ein Fehler im Programm vor (siehe entsprechende Hinweise im SAP Support Portal).
Die Workload-Analyse ermöglicht Ihnen detaillierte Aussagen über die Verteilung der Antwortzeiten auf den Komponenten des Systems (d. h. auf Datenbank, Hardware, ABAP- und Java-Server) einerseits und über die Verteilung der Antwortzeiten auf Transaktionen und Programme andererseits. Ausgehend von der Workload-Analyse entscheiden Sie, in welchem Bereich weitere Analyse- und Tuningmaßnahmen notwendig werden. Denken Sie immer daran, die Ergebnisse Ihrer Workload-Analyse mit den Beobachtungen der Benutzer zu vergleichen. So kann es sein, dass der Workload-Monitor bei oberflächlicher Analyse Performanceprobleme suggeriert, wo gar keine bestehen. Umgekehrt kann es vorkommen, dass Ihnen Benutzer Performanceprobleme melden, die Ihnen im Workload-Monitor nicht sofort ins Auge springen.
Mit "Shortcut for SAP Systems" werden Aufgaben im Bereich der SAP Basis vereinfacht und fehlende Funktionen des Standards ergänzt.
Sie können Ihre individuellen Einstellungen als eigene Variante speichern.
Das Verständnis für die Struktur und Funktionsweise des Systems ist insbesondere für die IT-Administration wichtig. Nicht umsonst ist „SAP Basis Administrator“ ein eigenes Berufsfeld. Auf der Seite www.sap-corner.de finden Sie nützliche Informationen zu diesem Thema.
Ausgeführt werden ABAP-Programme auf einem SAP-NetWeaver-Applikationsserver, für dessen Betrieb wiederum die SAP Basis-Mitarbeiter zuständig sind.