Datenmigration
Troubleshooting und Support
Unsere Erfahrung zeigt, dass falsche Sizings und daraus resultierende Streitfälle in der Mehrzahl der Fälle auf unpräzisen Prognosen über die erwartete Anzahl von Benutzern und Dokumenten beruhen. Die Verantwortung für die Qualität dieser Prognosen zu übernehmen ist die wichtigste Aufgabe des Projektleiters im Sizing-Prozess. Beratend steht ihm dabei der Experte des Hardwarepartners zur Seite.
Die vertikale Skalierung hat ihre natürlichen Grenzen, zum einen in der Verfügbarkeit großer Rechner (Anfang 2017 stellten einige Hardwarepartner Rechner von einer Größe bis zu 24 TB Hauptspeicher zur Verfügung), zum anderen in deren Preis (im oberen Leistungssegment steigt der Preis pro TB Speicher stark an) und zum dritten in der Tatsache, dass auch stark parallelisierende Anwendungen wie SAP HANA auf sehr großen Rechnern nicht perfekt skalieren (NUMA-Problem, siehe Kasten). Daher ist die richtige Balance zwischen vertikaler und horizontaler Skalierung zu wählen.
SAPUI5 und Fiori
Die Hardwarepartner erstellen nun Angebote zu dem Sizing-Projekt, unter denen Sie auswählen müssen. Für die Anforderungen unseres Beispielprojekts wäre es möglich, diese mit einem einzigen Rechner abzudecken. Alternativ kann der Hardwarebedarf auch auf mehrere Rechner verteilt werden. Für unser Projekt nehmen wir an, dass wir uns für ein Angebot entscheiden, das drei Rechner umfasst, die jeweils – nach Herstellerangabe – 12.000 SAPS leisten und mit 32 GB Hauptspeicher ausgestattet sind. Insgesamt leistet die Lösung also 36.000 SAPS und verfügt über 96 GB Hauptspeicher. Auf einem der Rechner sollen die Datenbank und eine SAP-Zentralinstanz installiert werden, auf den beiden anderen Rechnern sollen SAP-Instanzen den Großteil der Dialog-, Hintergrund- und Verbuchungslast aufnehmen. Mit dieser verteilten Installation gehen wir davon aus, dass wir auch beim Ausfall eines Rechners einen eingeschränkten Betrieb aufrechterhalten können und das Risiko eines Totalausfalls reduzieren. Für weitergehende Überlegungen zum Thema Lastverteilung verweisen wir Sie auf den letzten Teil dieses Kapitels und auf Kapitel 7, »Lastverteilung, Remote Function Calls und SAP GUI«.
Um die Vielfalt an verschiedenen Systemvariationen und die damit verbundene Vielfalt an Routineaufgaben einzudämmen, ist es notwendig, die Anzahl der Kundenspezifika zu reduzieren. Insbesondere Implementierung, Set-up und Konfiguration der Systeme und Sicherheitskonzepte müssen vereinheitlicht oder auf den SAP-Standard zurückgeführt werden. Hierzu ist es erforderlich, in Zusammenarbeit mit den dafür zuständigen IT-Fachabteilungen einen Standard für bspw Betriebssysteme und Datenbanken im Rahmen der durch das Produkt vorgegebenen Randbedingungen zu schaffen.
Basisadministratoren steht mit "Shortcut for SAP Systems" eine PC-Anwendung zur Verfügung, die etliche Tätigkeiten in der SAP Basis vereinfacht bzw. ermöglicht.
»Schlechte« Pufferqualitäten haben in der Regel zwei Ursachen: Mangelhaft optimierte und teure SQL-Anweisungen sind die Hauptursache für eine schlechte Pufferqualität des Datenpuffers.
Einige nützliche Tipps aus der Praxis zum Thema SAP Basis finden Sie auch auf der Seite www.sap-corner.de.
100 % wäre eine ideale Pufferqualität, d. h., es muss überhaupt nicht mehr von der Platte gelesen werden: Alle erforderlichen Objekte befinden sich im Hauptspeicher der Datenbankinstanz.