Performance-Hinweise
Die Performance von ABAP-Anwendungsprogrammen wird im wesentlichen von Datenbank-Zugriffen bestimmt. Es lohnt sich daher die SQL-Anweisungen einer genaueren Analyse zu unterziehen. Behilflich dabei sind die Werkzeuge Performance Trace und Laufzeitanalyse der ABAP Workbench im Menu Test. Insbesondere zeigt der SQL Trace im Performance Trace, wo welche Teile von Open SQL-Anweisungen in welcher Zeit verarbeitet werden.
Um den Einfluss von SQL-Anweisungen auf die Laufzeit von ABAP-Programmen zu verstehen, muss die zugrunde liegende Architektur betrachtet werden. Die Workprozesse eines Applikationsservers sind für die gesamte Laufzeit des SAP-Systems als Benutzer (Clients) an das Datenbanksystem (Server) angemeldet. Die Verbindung zwischen Client und Daten bildet das Datenbank-Management-System (DBMS).
DBMS-Architektur
Der Aufbau eines DBMS ist im allgemeinen:
· Ein Datenbank-Workprozess bietet einen Service an, den die Datenbank-Clients aufrufen können.
· Es gibt verschiedene Datenbank Services für unterschiedliche Zwecke, wie z.B. Aufbau der Verbindung, Ändern von Datenbanktabellen, Sperrmechanismus, Archivierung, etc.
· Es gibt einen großen Shared Memory-Bereich der den DBMS-Cache und andere Ressourcen wie Statement Cache, Redo Information, etc enthält.
· Die Datenbankdateien liegen auf einem Plattenspeicher und werden vom Dateisystem verwaltet.
In dieser Architektur sind vier Punkte für Performance-Betrachtungen wichtig:
· Der Physische Input/Output (I/O).
Das Lesen und Schreiben auf Datenbank Files stellt den größten Engpaß dar. Ein gut konfiguriertes System wird ausschließlich von der I/O- Zugriffsgeschwindigkeit bestimmt.
· Der Speicherverbrauch des Datenbank Caches.
· Der CPU-Verbrauch auf dem Rechner, auf dem die Datenbank installiert ist.
Bei Symmetrischen Multi-Prozessoren ist dies nicht von Belang.
· Netzwerk-Kommunikation.
Unkritisch für kleinere Datenvolumen, aber ein Engpaß, wenn große Datenmengen transferiert werden sollen.
Der Optimizer
Jedes Datenbanksystem verfügt über einen Optimizer. Die Aufgabe des Optimizers ist es, den Ausführungsplan für ein SQL-Statement zu erstellen (z.B. festlegen, ob ein Index- oder Table Scan durchgeführt wird). Es gibt zwei Ausprägungen von Optimizern:
Rule-based
Ein Rule-Based Optimizer analysiert die Struktur einer SQL-Anweisung (hauptsächlich SELECT und die WHERE-Klausel ohne Werte) und den Index der Tabelle(n). Über einen Bewertungsmechanismus entscheidet der Optimizer welches Vorgehen er anwendet, um den Befehl auszuführen.
Cost-based
Ein Cost-Based Optimizer betrachtet zusätzlich einige Werte in der WHERE-Klausel und die Statistiken der Tabellen. Die Statistiken enthalten Low- und High Values der Felder oder sogar ein Histogramm, das die Verteilung der Daten in der Tabelle enthält. Der Cost-Based Optimizer nutzt mehr Informationen über die Tabellen und führt daher meistens zu einem schnelleren Zugriff. Ein Nachteil beim Cost-Based Optimizer ist, dass die Statistiken periodisch auf den neuesten Stand gebracht werden müssen.
Verwendung
ORACLE setzt bis Rel 7.1 den Rule-based Optimizer ein. Ab Rel. 7.2 den Cost-based Optimizer (R/3 Release 4.0A). Alle anderen Datenbanksysteme haben einen Cost-based Optimizer.
Regeln für die performante Open SQl-Programmierung
Mit Blick auf oben dargestellte Architektur, ergeben sich fünf Regeln, die möglichst unabhängig vom verwendeten Datenbanksystem zu einer performanten Ausrührung von ABAP-Programmen mit Datenbankzugriffen führen. Die folgenden Regeln gelten insbesondere für folgende Datenbanksysteme:
· ORACLE
· INFORMIX
· ADABAS
· DB2/400 (verwendet EBCDIC Code Page).
· Microsoft SQL Server
Für folgende Datenbanksysteme treffen sie nicht oder nur teilweise zu:
· DB2/6000
· DB2/MVS
· ORACLE Parallel Server (OPS)
Die folgenden Abschnitte erläutern die fünf Regeln.
Übertragene Datenmenge klein halten
Zahl der Zugriffe klein halten