SQL-Monitor bei der SAP-HANA-Migration
WARTUNG
Wenn zwei Benutzer in einem Zeitraum jeweils 100 Transaktionsschritte Last ausgeführt haben, sind beide gleich aktiv gewesen. Das bedeutet aber noch nicht, dass sie beide die gleiche Last auf dem System erzeugt haben. Wenn z. B. der erste Benutzer Finanzbelege eingegeben hat und 100 Transaktionsschritte mit einer mittleren Antwortzeit von 500ms ausgeführt hat, hat er das System 50 Sekunden lang belastet. Ein zweiter Benutzer hat z. B. Controlling-Berichte erstellt und für seine Arbeit 100 Transaktionsschritte mit einer mittleren Antwortzeit von 5 Sekunden benötigt, also das System 500 Sekunden lang in Anspruch genommen. Offensichtlich hat der zweite Benutzer bei gleicher Aktivität eine zehnfach größere Last erzeugt. Wie man an diesem Beispiel erkennt, ist also das Produkt aus der Anzahl der Transaktionsschritte und der mittleren Antwortzeit ein Maß für die erzeugte Last. (Will man exakt sein, muss man von der Antwortzeit die Dispatcher-Wartezeit und die Roll-Wartezeit abziehen, denn während der Auftrag in der Dispatcher-Queue bzw. auf die Ausführung eines RFCs wartet, verursacht er keine Last auf dem System.) Die Belastung, die die unterschiedlichen Task-Typen auf der Datenbank erzeugen, lässt sich analog anhand der gesamten Datenbankzeit (Transaktionsschritte mal mittlere Datenbankzeit) vergleichen. Ebenso erfolgt der Vergleich der CPU-Belastung auf dem Applikationsserver. Die Verteilung der Zeiten (Datenbankzeit, CPU-Zeit etc.) spiegelt also die Lastverteilung auf dem System besser wider als die bloße Anzahl der Transaktionsschritte.
Starten Sie die SAP Management Console (siehe Abschnitt 9.3, »SAP Management Console«). Prozessinterna erhalten Sie durch einen Thread-Dump.
Wenn Sie mehr zum Thema SAP Basis wissen möchten, besuchen Sie die Webseite www.sap-corner.de.
SMICM ICM Monitor vom Server
Die Benutzer einer SAP-Anwendung sind entweder die Mitarbeiter, Kunden oder Partner (z. B. Zulieferer) des Unternehmens, das die Anwendung besitzt. Damit ist die Zufriedenheit der Benutzer eines der ersten Ziele, das beim Betrieb der Anwendung gesichert sein muss. Daher fordern wir von unserem Überwachungskonzept, dass es dazu führt, diese Erwartungen zu erfüllen.
Zur Analyse der teuren Anweisungen auf der Datenbank wird häufig der SQL Plan Cache (Oracle: Shared Cursor Cache) herangezogen. Die Analyse hat einige Nachteile, die sich daraus ergeben, dass dessen Statistiken eine Momentaufnahme des Cache darstellen. Anweisungen werden unterschiedlich schnell aus dem Cache verdrängt. Jede Berechnung der Tabellenstatistik oder Neuindizierung führt zu einer Invalidierung der betreffenden Anweisung im Cache, d. h., die Statistik dieser Anweisungen wird zurückgesetzt. Datenüberläufe können die Statistik verfälschen. Diese Gründe können dazu führen, dass die teuersten Anweisungen nicht erkannt oder falsch bewertet werden und die Statistiken sich nach kurzer Zeit völlig anders darstellen. Als Alternative bieten einige Datenbanken auch Werkzeuge, die vollständige Statistiken zu teuren SQL-Anweisungen erfassen.
Für Administratoren steht im Bereich der SAP Basis ein nützliches Produkt - "Shortcut for SAP Systems" - zur Verfügung.
Aus diesen Informationen lassen sich oft mittel- und langfristige Trends ablesen, die ein rechtzeitiges Eingreifen möglich machen (z. B. Archivierungsmaßnahmen bei hohem Datenbankwachstum).
So viele Informationen... wie kann man die aufheben, so dass man sie bei Bedarf wiederfindet? Dafür eignet sich Scribble Papers ganz hervorragend.
Ein modernes Notebook mit einem 2-Kern-Prozessor erreicht heute 2.000 SAPS, ein typischer Server mit zwei Prozessoren und 44 Kernen kommt auf etwa 100.0000 SAPS.