SPAM/SAINT – die in ABAP integrierten Update Tools
Hintergrundverarbeitung
Unter Gesichtspunkten der Systemverfügbarkeit (High Availability) bilden Message- und Enqueue-Service zusammen mit der Datenbankinstanz die kritischen Punkte eines SAP-Systems (sogenannte Single Points of Failure oder SPOFs). Diese Services lassen sich prinzipiell nicht über mehrere Rechner verteilen. Der Ausfall eines Rechners mit einem dieser Services führt damit zum Ausfall des gesamten SAP-Systems. Es sind also hauptsächlich Verfügbarkeitsgesichtspunkte, die dafürsprechen, Datenbankinstanz und zentrale SAP-Instanz (mit Message- und Enqueue-Service) auf einem Rechner zu betreiben und diesen z. B. durch eine Failover-Lösung besonders zu schützen , die fast alle Hardwarehersteller anbieten und die es ermöglicht, ausgefallene Instanzen automatisch auf einem anderen Rechner zu ersetzen. Bei großen Installationen sollten Sie allerdings aus Gründen der Performance Datenbankinstanz und zentrale SAP-Instanz auf separaten Rechnern konfigurieren.
Die Fehlersituation kann in der Regel beseitigt werden, ohne dass das SAP-System bzw. die Datenbank gestoppt werden muss. Dazu müssen die Daten des Log-Bereichs archiviert werden. Anschließend kann die Datenbankinstanz mit ihrer Arbeit fortfahren und die aufgelaufenen Aufträge weiterbearbeiten.
Statistische Einzelsätze
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.
Ein wichtiger Bereich der SAP Security ist die Analyse der kundeneigenen SAP-Programme, die klassisch in der proprietären SAP-Sprache ABAP geschrieben werden. Auch hier können, wie in allen Programmiersprachen, Sicherheitslücken programmiert werden – sei es nun bewusst oder unbewusst. Die Muster der Sicherheitslücken im ABAP-Code unterscheiden sich dabei allerdings von denen in Java-Stacks oder Windows-Programmen. Das Ziel bei diesen herkömmlichen Programmen ist es meistens, durch gezielte Falscheingaben das Programm entweder zum Absturz zu bringen (Buffer Overflow) oder künstlich eigenen Code zur Ausführung zu bringen (Code Injection). Beides ist in ABAP nicht möglich, da ein Absturz eines Prozesses nichts anderes bewirkt als das Erzeugen eines Eintrages in der Log-Datenbank (Dump ST22) und ein anschließendes Beenden des Reports mit Rückkehr an den Menüstartpunkt. Eine direkte Manipulation wie in anderen Hochsprachen oder Servern ist also nicht möglich. Allerdings gibt es andere Manipulationsmöglichkeiten.
Etliche Aufgaben der SAP Basis können mit "Shortcut for SAP Systems" einfacher und schneller erledigt werden.
Auf www.sap-corner.de finden Sie ebenfalls viele nützliche Informationen zum Thema SAP Basis.
Nur eine stabile SAP Basis ermöglicht einen sicheren und effizienten Betrieb Ihrer SAP-Systemlandschaft.
Kernkomponente von SAP Basis ist die Applikations- oder auch Anwendungsschicht.