Information über Messgenauigkeit
Was hat der TREX mit dem SAP Solution Manager zu tun?
Nachdem Ihr Nutzer die benötigten Rechte für den SQL-Editor besitzt, gehen Sie wie folgt vor: Rufen Sie die Transaktion "DBACOCKPIT" auf. Öffnen Sie die folgende Ordnerstruktur in der Datenbankadministration: Performance -> Additional Functions -> SQL Command Editor Geben Sie Ihre erste Query in die Eingabeabfrage ein. Anschließend klicken Sie auf Ausführen oder drücken alternativ auf F8 Ansicht des DBA Cockpits Aufruf der Eingabeabfrage und Absetzen der ersten SQL Abfrage Ansicht der Ergebnisse einer Query zur Abfrage der Nutzer eines Systems.
Die Analyse der SQL-Statistik ist ein mächtiges Mittel zur Performanceanalyse. Allerdings erfordert die Beurteilung, welche der teuren SQL-Anweisungen optimierbar sind, eine gewisse Erfahrung. Um die teuersten SQLAnweisungen zu identifizieren, vergleichen Sie die Lesezugriffe, die für eine Anweisung aufgewendet wurden, mit denen der gesamten Datenbank. Sortieren Sie die SQL-Statistik nach der Spalte Gesamte DB-Zeit. Gibt es wenige teure SQL-Anweisungen, d. h. Anweisungen, die mehr als 5% der gesamten Zeit ausmachen? Wenn dies der Fall ist, können Sie durch Tuning dieser Anweisung(en) die Datenbankperformance in der Regel drastisch steigern. Da der SQL-Monitor den Einstiegspunkt, d. h. Transaktionscode oder Reportname, mit darstellt, können Sie die Analyse auch nach der Priorität Ihrer Geschäftsprozesse steuern. Beginnen Sie also mit der Analyse der SQL-Anweisungen, die zu den wichtigsten Transaktionen und Reports gehören. Über die Schaltfläche SQL-Trace aktivieren/deaktivieren können Sie einen SQL-Trace gezielt einschalten: Selektieren Sie einen Eintrag im SQL-Monitor, und wählen Sie SQL-Trace aktivieren/deaktivieren. Das System öffnet das Dialogfenster zum Aktivieren des SQL-Trace und füllt die Parameter wie Aufrufstelle, Einstiegspunkt, Tabelle vor, sodass Sie den SQL-Trace gezielt für diese SQL-Anweisung einschalten können.
Migration in die Cloud-Plattformen
Jeder einzelne Prozess kann nicht mehr Speicher allokieren als den maximal adressierbaren Speicherbereich (Adressraum oder Address Space), den das Betriebssystem zulässt. Diese logische Grenze ist in der Architektur der Betriebssysteme begründet. Für SAP-Systeme werden heute durchweg Betriebssysteme mit 64-Bit-Architektur eingesetzt. Die Beschränkung durch den Adressraum stellt bei diesen keine praktisch relevante Grenze mehr dar. Der Adressraum liegt für die früher verwendete 32-Bit-Architektur bei theoretisch 4 GB (232); der praktisch adressierbare Speicher liegt weiter darunter. Für die praktische Konfiguration stellt diese Grenze ernsthafte Herausforderungen dar.
Einige nützliche Tipps aus der Praxis zum Thema SAP Basis finden Sie auch auf der Seite www.sap-corner.de.
So viele Informationen... wie kann man die aufheben, so dass man sie bei Bedarf wiederfindet? Dafür eignet sich Scribble Papers ganz hervorragend.
Datenbanksperren sind zur Wahrung der Datenkonsistenz auf der Datenbank absolut notwendig. Kurzzeitig auftretende Wartesituationen auf Datenbanksperren sind daher nicht als Performanceproblem zu werten. Kritisch wird die Situation erst dann, wenn sich Wartesituationen aufgrund von Sperren über längere Zeit hinweg nicht auflösen und es zu Serialisierungseffekten kommt, wenn also immer mehr Benutzer aufgrund von Sperren warten müssen. Detailliertere Informationen zu Datenbanksperren finden Sie in Kapitel 10, »Sperren«.
Mit "Shortcut for SAP Systems" steht ein Tool zur Verfügung, das einige Aufgaben im Bereich der SAP Basis erheblich erleichtert.
Die Datenbankschicht verwaltet alle Daten des SAP-Systems in einer Datenbank, die auf dem Datenbankserver liegt und über ein Datenbank-Management-System (DBMS) verwaltet wird.
Die Muster der Sicherheitslücken im ABAP-Code unterscheiden sich dabei allerdings von denen in Java-Stacks oder Windows-Programmen.