SQL-Monitor bei der SAP-HANA-Migration
Was muss ein SAP-Administrator können?
Auf wie viele Rechner und SAP-Instanzen soll die SAP-Applikationsebene verteilt werden? Grundsätzlich sollten Sie nicht unnötig viele Rechner und Instanzen einrichten, da mit jedem zusätzlichen Rechner und jeder zusätzlichen Instanz ein erhöhter Verwaltungs- und Überwachungsaufwand einhergeht. Folgende Argumente sprechen jedoch für die Einrichtung mehrerer Instanzen: Fällt ein Rechner bzw. eine Instanz aus, müssen die verbleibenden Rechner bzw. Instanzen die zusätzliche Last auffangen. Die Folgen sind dabei umso drastischer, je weniger Rechner bzw. Instanzen konfiguriert wurden. Anmeldegruppen (siehe Abschnitt 7.2.4, »Dynamische Benutzerverteilung: Anmeldegruppen konfigurieren«) sind ein wichtiges Mittel zur Lastverteilung. Diese können aber nur eingesetzt werden, wenn mehrere Instanzen konfiguriert sind. Bei sehr großen Instanzen können singuläre Ressourcen wie der Dispatcher, die Roll- oder die Pufferverwaltung zum Performanceengpass werden. Wann dieser Effekt jedoch auftritt, muss im Einzelfall geprüft werden. SAP gibt an, dass Sie Instanzen bis zu 512 GB Größe konfigurieren können.
Weitere Datenbankoperationen, die Sie im SQL-Trace finden, sind DECLARE, PREPARE und OPEN. Die DECLARE-Operation definiert einen sogenannten Cursor, der die Datenübergabe zwischen ABAP-Programmen und einer Datenbank regelt, und weist ihm eine Nummer zu. Über diese Cursor-ID erfolgt die Kommunikation zwischen SAP-Workprozess und Datenbanksystem.
SWI2_DIAG Einstieg in Workitem-Analyse (SWI2)
Eine SAP-Transaktion erstreckt sich in der Regel über mehrere Transaktionsschritte (Bildwechsel). Während dieser Schritte werden Daten wie Variablen, interne Tabellen und Bildschirmlisten aufgebaut und im Hauptspeicher des Applikationsservers gehalten. Diese Daten bezeichnet man als Benutzerkontext. In der Regel werden die Schritte einer Transaktion von unterschiedlichen Dialog-Workprozessen ausgeführt, d. h., der erste Transaktionsschritt wird vielleicht vom Workprozess Nr. 3 ausgeführt, der zweite Schritt vom Workprozess Nr. 4 etc. Zu Beginn eines Transaktionsschrittes muss daher der Benutzerkontext dem entsprechenden Workprozess zugänglich gemacht werden. Dieser Vorgang heißt Roll-in. Die technischen Vorgänge beim Roll-in (z. B. das Kopieren von Daten in den lokalen Speicher des Workprozesses) werden in Kapitel 6, »Speicherkonfiguration«, im Detail dargestellt. Analog zum Roll-in zu Beginn eines Transaktionsschrittes wird zum Ende eines Transaktionsschrittes ein Roll-out, also die Sicherung der aktuellen Benutzerdaten, durchgeführt. Die Länge des Roll-ins wird als Roll-in-Zeit, die Länge des Roll-outs als Roll-out-Zeit bezeichnet. Bitte beachten Sie, dass der Roll-out nicht zur Antwortzeit eines Transaktionsschrittes beiträgt. Beim Roll-out, d. h. beim Kopieren des Benutzerkontextes aus dem lokalen Speicher des Workprozesses in den Roll-Speicher, sind die Daten des Benutzers bereits vorher an den Präsentationsserver übertragen worden.
Es gibt verschiedene Sichten der Messergebnisse, die die Laufzeitanalyse als Listen oder Grafiken aufbereiten: Über die Schaltfläche Hitliste erhalten Sie eine Liste, die die Ausführungszeit für jede Anweisung anzeigt. Diese Liste ist standardmäßig absteigend nach Nettozeiten sortiert (siehe Abbildung 5.2). Über die Schaltfläche Hierarchie gelangen Sie zu einer Darstellung des chronologischen Ablaufs der aufgezeichneten Programmteile. Über weitere Schaltflächen erhalten Sie spezifische Auswertungen, die z. B. Datenbanktabellen oder Modularisierungseinheiten aufgliedern.
Das Tool "Shortcut for SAP Systems" eignet sich sehr gut, um viele Aufgaben in der SAP Basis einfacher und schneller zu erledigen.
Welche Transaktionen verursachen die höchste Datenbanklast? Sortieren Sie das Transaktionsprofil nach S CPU-Zeit.
Beachten Sie, daß der SAP Patch Manager die Konfiguration Ihres SAP-Systems berücksichtigt und nur solche Support Packages in die Queue aufnimmt, die in Ihr System eingespielt werden dürfen.