TUNING
SAP Basis als Managed Service?
Sie können mehrere Anwendungen in einer SAP-HANA-Instanz auf einem Rechner betreiben und die Anwendungsdaten über Datenbankschemata voneinander trennen (Multiple Components, One Database: MCOD, siehe SAP-Hinweis 1661202). Die Systeme teilen sich neben der Hardware auch Betriebssystem und Datenbank, die Isolierung ist relativ schwach. Diese Option ist nur für spezielle Anwendungskombinationen freigegeben.
Bei der horizontalen Skalierung wird die Verteilung der Daten auf die Knoten explizit festgelegt. Wenn Sie Tabellenreplikation nicht explizit einschalten, werden Daten nicht redundant, also auf unterschiedlichen Rechnern gleichzeitig gehalten. Eine Neuverteilung kann über Administrationswerkzeuge durchgeführt werden. Ist einmal festgelegt, welche Tabelle bzw. Partition einer Tabelle auf einem bestimmten Knoten liegt, legt dies auch fest, auf welchem Knoten die Anfrage bearbeitet wird. Damit ist im Falle der horizontalen Skalierung eine gute Datenlokalität entscheidend für eine gute Performance, denn beim Transport zwischen Knoten entstehen signifikante Mehrkosten. Es ist der Trend zu beobachten, dass horizontale Skalierung bei reinen OLAP-Systemen (SAP Business Warehouse on SAP HANA) bereits weit verbreitet ist, während sich diese Entwicklung bei OLTP-Systemen erst am Anfang befindet.
JAVA
Regelmäßige Wartungsaufgaben bzw. die Standard-Prozeduren müssen beschrieben und definiert werden, um darauf basierende Checklisten aufzubauen und die Einhaltung dieses Standards zu kontrollieren. Unterstützen kann hierbei auch der SAPSolution- Manager als Werkzeug von SAP bspw durch die Guided Procedures. In diesem Zusammenhang ist es ebenso notwendig, die Funktionalität, die eine zugrunde liegende Anwendung besitzt, zu dokumentieren und dadurch festzulegen, welche Test- und Überwachungsaktivitäten notwendig sind. Dies ist ein Abstimmungsprozess zwischen der SAP-Basis, anderen IT-Fachabteilungen und ggf auch mit den betroffenen Geschäftsbereichen. Der festgelegte Standard und die IST-Situation des Systems müssen ausführlich dokumentiert sein und regelmäßig auf Einhaltung überprüft werden. Dies kann durch automatisierte Überwachung, Validierung anhand von Werkzeugen wie SAP-LVM (Landscape-Virtualization-Management) oder den SAP-Solution-Manager wie auch durch manuelle Checklisten geschehen. Nur die regelmäßige Überprüfung der Standards garantiert deren Einhaltung. Unterstützen kann auch die regelmäßige Verwendung von SAP-Services wie bspw Go-live Checks oder Early Watch. Beispiele für ein Standardisieren von Prozeduren sind hier aufgeführt: • Namensgebung von Systeminstanzen und logischen Hosts bzw. mindestens eine zentrale Registrierung in einem Verzeichnisdienst oder auch LVM oder SAP-Kundenportal • Zentrales Starten und Stoppen von Systemen bspw über den LVM • Kategorisierung von SAP-Instanzen nach T-Shirt-Größen, um Profil-Standards definieren zu können und diese mit Kosten zu versehen.
Weitere Möglichkeiten, Datenbanklast zu vermindern, sind die richtige Verwendung der SAP-Puffer sowie die Definition geeigneter Datenbankindizes (Sekundärindizes), die die Datenbanklast bei Leseoperationen stark reduzieren können (siehe auch Kapitel 12, »SAP-Pufferung«). Tabellenpufferung und Indizes sind bei der Installation der SAP-Komponente bereits eingestellt. Zur Laufzeitoptimierung einzelner Programme kann es jedoch nötig sein, diese Voreinstellungen zu ändern. Für kundeneigene Tabellen müssen diese Einstellungen in jedem Fall vom Entwickler selbst vorgenommen werden.
Etliche Aufgaben im Bereich der SAP Basis können mit "Shortcut for SAP Systems" wesentlich erleichtert werden.
Eine Modifikation ist umso schwerwiegender, je aufwändiger sich die Wartung inkl. dem Testen zB im Fall von Upgrades gestaltet.
Weitere Informationen dazu finden Sie in Kapitel 6, »Speicherkonfiguration«.