Implementierung einer hochverfügbaren HANA-Datenlösung
NUTZUNG DES SECURITY AUDIT LOG
Im Abschnitt CPU finden Sie die Felder Benutzerauslastung, Systemauslastung und Leerlauf. Diese Werte zeigen an, wie viel Prozent der CPU-Kapazität augenblicklich von Benutzerprozessen (d. h. vom SAP-System, der Datenbank und weiteren Prozessen) und vom Betriebssystem selbst genutzt werden und wie viel Prozent derzeit frei sind. Das Feld Anzahl CPUs gibt die Anzahl der CPU-Fäden (Threads) an. Mittlere Prozesswartezeit ist die Anzahl der Prozesse, die auf einen freien Prozessor warten. Dieser Wert wird im Mittel über 1 Minute, über 5 Minuten und über 15 Minuten angegeben. Die weiteren Werte im Abschnitt CPU sind für die Performanceanalyse weniger wichtig.
Hinzu kommt, dass der Geschäftsprozessinhaber die Zufriedenheit der Endbenutzer bei optimal niedrigen Kosten (Cost of Ownership) erreichen möchte. Ein Service Level Management sollte also – neben der Überwachung von Verfügbarkeit, Performance, Korrektheit und Sicherheit – auch die Kosten, z. B. für Hardware und Personal, transparent machen. Die – in der Praxis oft schwierige – Kommunikation zwischen den Geschäftsprozessinhabern und den Serviceprovidern in den Griff zu bekommen ist eine weitere Anforderung an ein Service Level Management. Abbildung 1.8 zeigt beispielhaft die beteiligten Personen und Teams im Umfeld von Service Level Management, Alert Monitoring und kontinuierlicher Systemüberwachung sowie deren Beziehungen.
ENTSCHEIDUNG FÜR EIGENERSTELLUNG ODER
Die SAP-Basis benötigt eine Trennschicht zu vor- und nachgelagerten IT-Fachabteilungen, die klar definiert ist. In Richtung der Infrastruktur bspw kann dies die Oberkante des Betriebssystems sein. Ebenso muss diese Abgrenzung in Richtung Anwendungsentwicklung getroffen werden. Hier gibt es diverse Services, die heute von der SAP-Basis angeboten werden, die eher anwendungsnah sind, bspw Steuerung der Hintergrundverarbeitung, Transportwesen oder auch die Automation bestimmter Tätigkeiten. Prinzipiell gilt es zu prüfen, welche Aufgaben auf Grund der Anforderungen weiterhin in der SAP-Basis ausgeübt und welche in dafür vorgesehene Experteneinheiten gegeben werden können.
Die wichtigsten Kennzahlen zur Bewertung der Datenbankpuffer für unterschiedliche Datenbanksysteme im SAP-Umfeld sind in Anhang A, »Datenbankmonitore«, zusammengefasst. »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. Identifizieren Sie solche Probleme, müssen diese vordringlich behandelt werden. Weitere Informationen dazu finden Sie in Kapitel 11, »Optimierung von SQL-Anweisungen«. Abbildung 11.1 zeigt das Flussdiagramm der Analyse. Die andere Ursache kann ein zu kleiner Datenbankpuffer sein. Sofern Ihr Datenbankserver noch über ausreichend Hauptspeicherreserven verfügt, vergrößern Sie den entsprechenden Puffer (z. B. um 10 bis 20 %). Beobachten Sie, ob sich anschließend die entsprechende Qualität signifikant verbessert. Ist dies der Fall, können Sie den Puffer eventuell erneut vergrößern. Zeigt die erste Vergrößerung des Puffers dagegen keine Wirkung, suchen Sie die Ursache an einer anderen Stelle. Bei einigen Datenbanken besteht auch die Möglichkeit, Tabellen, die als Hauptverursacherfür eine schlechte Pufferqualität identifiziert werden können, in eigene Puffer zu legen, um zu einer besseren Pufferqualität für die verbleibenden zu kommen.
"Shortcut for SAP Systems" ist eine PC-Anwendung, mit der viele Tätigkeiten in der SAP Basis vereinfacht bzw. auch überhaupt erst ermöglicht werden.
Wenn Sie mehr zum Thema SAP Basis wissen möchten, besuchen Sie die Webseite www.sap-corner.de.
Bei Anmeldungen über den Webbrowser wird jede Anfrage neu verteilt.
Lösen Sie in diesem Fall erst das andere Performanceproblem, und untersuchen Sie anschließend, ob sich die Datenbanksperren dann schneller auflösen.