2 Analyse von Hardware, Datenbank und ABAP-Applikationsserver

Mit der Analyse der Hardwareressourcen, der Datenbank 

sowie der Workprozesse und Speicherbereiche des SAP NetWeaver 

AS ABAP steigen wir – bottom-up – in die Performanceanalyse 

ein. Verschaffen Sie sich einen ersten Überblick über die 

aktuelle Situation im System! 

2 Analyse von Hardware, Datenbank 

und ABAP-Applikationsserver 

Dieses Kapitel erläutert die Grundlagen von Performanceanalysen 

der Hardware, der Datenbank, der SAP-Speicherkonfiguration und 

der SAP-Workprozesse des SAP NetWeaver Application Servers 

ABAP. Am Ende eines jeden Abschnitts finden Sie Flussdiagramme, 

die die wichtigsten Analysepfade zusammenfassen und die Abhängigkeiten 

zwischen den Analysen verdeutlichen. Im letzten Abschnitt 

gehen wir auf den zentralen Überwachungsmonitor ein, der Performanceindikatoren 

aus allen Bereichen integriert. 

Zu diesen Analysen erhalten Sie sofort Optimierungsvorschläge, sofern 

dies ohne umfangreichere Erklärungen möglich ist. Um auch einem 

in der Performanceanalyse unerfahrenen Berater oder Administrator 

einen schnellen Einstieg zu ermöglichen, verzichten wir 

bewusst auf Hintergrundinformationen. So wird z. B. beschrieben, 

wie Sie das SAP Extended Memory überwachen und einstellen, ohne 

den Begriff SAP Extended Memory zu erklären. Umfassendere Informationen 

finden Sie anschließend in den Kapiteln 5 bis 15. Dieser 

Aufbau trägt unserer Erfahrung Rechnung, dass es möglich ist, viele 

Performanceprobleme im Bereich von Betriebssystem, Datenbank 

und SAP-Basis anhand einfacher Handlungsanweisungen zu lösen, 

ohne sich vorher eingehend mit den Details der Architektur zu beschäftigen. 

75

2 

Analyse von Hardware, Datenbank und ABAP-Applikationsserver 

Wann sollten Sie dieses Kapitel lesen? 

Dieses Kapitel sollten Sie lesen, wenn Sie die Performance des SAP- 

Systems, der Datenbank oder des Betriebssystems vom SAP-System 

aus technisch überwachen und optimieren wollen. 

2.1 Begriffsklärungen 

Die Begriffe Rechner, Server, Applikationsserver, SAP-Instanz, Datenbank, 

Datenbankserver und Datenbankinstanz werden in diesem Buch 

wie folgt verwendet: 

Rechner 

SAP-Applikationsinstanz 

Datenbank 

Ein Rechner (oder Computer) ist eine physische Maschine mit CPU, 

Hauptspeicher, IP-Adresse etc. 

Eine SAP-Applikationsinstanz, auch kurz als SAP-Instanz bezeichnet, 

ist eine administrative Einheit: Sie besteht aus einem Satz von SAP- 

Workprozessen, die von einem Dispatcher verwaltet werden, sowie 

aus einem Satz von SAP-Puffern im Shared Memory des Rechners, auf 

den die Workprozesse zugreifen. Eine SAP-Applikationsinstanz kann 

eine ABAP-Applikationsinstanz (SAP NetWeaver Application Server 

ABAP, kurz AS ABAP oder eine Java-Applikationsinstanz (SAP Net- 

Weaver Application Server Java, kurz AS Java) sein. Es kann mehrere 

SAP-Instanzen auf einem Rechner geben. In diesem Fall existieren 

mehrere Dispatcher und mehrere Puffersätze. Ein Applikationsserver 

ist ein Rechner, auf dem mindestens eine SAP-Instanz läuft. 

Jedes SAP-System besitzt genau eine Datenbank. Als Datenbank 

bezeichnen wir die Datenbasis, die z. B. in Form von Dateien vorliegt. 

Die Datenbank ist der passive Teil des Datenbanksystems. 

Der aktive Teil des Datenbanksystems ist die Datenbankinstanz, eine 

administrative Einheit, die den Zugriff auf eine Datenbank erlaubt. 

Eine Datenbankinstanz besteht aus Datenbankprozessen und einem 

Satz von Datenbankpuffern im Shared Memory eines Rechners. Ein 

Datenbankserver ist ein Rechner, auf dem mindestens eine Datenbankinstanz 

läuft. Ein Rechner kann zugleich Datenbank- und Applikationsserver 

sein, wenn eine Datenbankinstanz und eine SAP-Instanz 

darauf laufen. 

In der Regel operiert im SAP-Umfeld auf einer Datenbank nur eine 

Datenbankinstanz. Beispiele für Datenbanksysteme, bei denen auf 

76

Hardwareanalyse 2.2 

eine Datenbank mehrere Datenbankinstanzen zugreifen, sind DB2 

und Oracle Parallel Server. Die Besonderheiten solcher parallelen 

Datenbanksysteme werden in diesem Buch nicht behandelt. 

Als SAP-Systeme bezeichnen wir Softwarekomponenten von SAP mit 

dem SAP NetWeaver AS als Grundlage. Im Einzelnen sind dies SAP 

ERP, SAP NetWeaver BW, SAP APO, SAP SRM und SAP NetWeaver 

Portal. 

SAP-System 

Im Sinne dieser Terminologie kann also z. B. ein SAP ERP-System aus 

ein oder zwei Systemen bestehen, je nachdem, ob der Java- und der 

ABAP-Teil auf einem gemeinsamen System mit einer Datenbank 

(»Double-Stack«) oder auf zwei Systemen mit getrennten Datenbanken 

betrieben werden – dieser Terminologie folgt im Übrigen auch 

der SAP Solution Manager. 

Der Begriff Server wird in der Dokumentation und der Literatur 

mehrdeutig verwendet. Er kann sowohl einen Rechner bezeichnen, 

z. B. im Begriff Datenbankserver, als auch einen logischen Service, z. B. 

in den Begriffen Message-Server und ATP-Server. So verwenden wir 

auch ABAP-Server bzw. Java-Server als Kurzformen für den SAP Net- 

Weaver Application Server (AS) ABAP bzw. Java. 

Server 

2.2 Hardwareanalyse 

Das Werkzeug zur Analyse von Hardwareengpässen und Betriebssystemproblemen 

ist der Betriebssystemmonitor. Um diesen Monitor 

für den Applikationsserver zu starten, auf dem Sie zurzeit angemeldet 

sind, wählen Sie: 

Betriebssystemmonitor 

Werkzeuge Administration Monitor Performance 

Betriebssystem Lokal Betriebssystemmonitor 

Alternativ können Sie den Transaktionscode ST06 verwenden. Sie 

gelangen auf den Hauptbildschirm des Betriebssystemmonitors. 

Zu Basis-Version 7.10 wurde der Betriebssystemmonitor überarbeitet. 

Nach dieser Überarbeitung führen die drei Transaktionscodes 

OS06, OS07 und ST06 auf einen Monitor, mit dem sowohl der lokale 

als auch entfernte Rechner überwacht werden können. Bei Versionen 

vor 7.10 stehen die neuen Transaktionen unter den Transaktionscodes 

OS06N, OS07N und ST06N zur Verfügung, mit den Transaktions- 

Aufruf und 

Verfügbarkeit 

77

2 


codes OS06, OS07 und ST06 erreichen Sie nach wie vor die älteren 

Transaktionen. Alle Informationen, die wir in diesem Buch besprechen, 

stehen Ihnen auch in den alten Transaktionen zur Verfügung. 

Die Detailanalysen finden Sie über die Navigation mit der Schaltfläche 

Detail Analysis Menu. 

Der Betriebssystemmonitor lässt sich auch aus der Serverübersicht 

heraus aufrufen: 

Werkzeuge Administration Monitor Systemüberwachung 

Server (Transaktionscode SM51) 

Positionieren Sie anschließend den Cursor auf dem gewünschten 

Applikationsserver, und wählen Sie im Menü Springen Monitore 

OS-Monitor. 

Aufbau 

Der Bildschirm des Betriebssystemmonitors teilt sich in drei Bereiche 

(siehe Abbildung 2.1). 

Abbildung 2.1 Hauptbildschirm des Betriebssystemmonitors 

78


Im linken oberen Fenster finden Sie die Auswahl der Rechner, die 

überwacht werden. Dort können Sie einen Rechner auswählen, den 

Sie analysieren wollen. Im linken unteren Fenster wählen Sie die 

Analysedaten aus. Die Daten zum ausgewählten Rechner und zur ausgewählten 

Analyse finden Sie im rechten Fenster. 

Standardmäßig finden Sie alle Rechner, auf denen SAP-ABAP-Instanzen 

installiert wurden, in der Auswahlliste. Grundsätzlich lässt sich 

aber jeder Rechner in den Remote-Betriebssystemmonitor einbinden, 

sofern dort ein Monitoring-Agent installiert ist. Dringend empfohlen 

wird dies für Rechner, auf denen eine Stand-alone-Datenbank, 

eine SAP-Java-Instanz oder ein TREX läuft. 

Beachten Sie, dass Sie diesen Monitor auch dann einrichten sollten, 

wenn Sie mit einem Werkzeug eines anderen Herstellers die Auslastung 

Ihrer Rechner überwachen. Sollten Sie Support von SAP benötigen, 

kann ein Experte von SAP nur über den SAP-eigenen Monitor 

die Rechner analysieren. 

SAP-Support 

2.2.1 Analyse eines Hardwareengpasses 

(CPU und Hauptspeicher) 

Eine Übersicht über die wichtigsten Betriebssystem- und Hardwaredaten 

finden Sie unter dem Punkt Snapshot in der Analyseauswahl 

des Betriebssystemmonitors (siehe Abbildung 2.1). Alle Daten des 

Betriebssystemmonitors werden vom Hilfsprogramm saposcol im 

Zehn-Sekunden-Rhythmus aufgefrischt. Ein Auffrischen der Daten 

mit der entsprechenden Drucktaste ergibt also nur dann neue Daten, 

wenn zehn Sekunden verstrichen sind. 

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 eine Minute, 

über fünf Minuten und über 15 Minuten angegeben. Die weiteren 

Werte im Abschnitt CPU sind für die Performanceanalyse weniger 

wichtig. Tabelle 2.1 gibt Ihnen einen Überblick über die Felder des 

Betriebssystemmonitors. 

CPU-Auslastung 

79

2 


Feld 

Benutzerauslastung 

Systemauslastung 

Leerlauf 

Anzahl der CPUs 

Mittlere Prozesswartezeit 

Physischer Speicher 

Bedeutung 

CPU-Auslastung durch Benutzerprozesse 

(SAP-System, Datenbank etc.) 

CPU-Auslastung durch das Betriebssystem 

Freie CPU-Kapazität. Dieser Wert sollte mindestens 

20 % betragen, optimalerweise aber 35 %. 

Anzahl der CPU-Threads 

Anzahl der Prozesse, die auf die CPUs warten, 

gemittelt über eine, fünf bzw. 15 Minuten 

physisch vorhandener Hauptspeicher (RAM) 

in KB 

Tabelle 2.1 Felder des Betriebssystemmonitors 

Prozessoren, Kerne (Cores) und Fäden (Threads) 

Als Beschreibung der Rechnerausstattung findet man z. B. folgende Angaben: 

»zwei Prozessoren, acht Cores, 16 Threads, Prozessor des Herstellers X mit 

2.93 GHz Taktfrequenz«. Was bedeuten die Angaben über die Anzahl der 

Prozessoren, Kerne (Cores) und Fäden (Threads) für das SAP-System? 

Der Begriff Prozessor bezeichnet bekanntlich die zentrale Verarbeitungseinheit 

(Central Processing Unit, CPU) eines Rechners, die in der Lage ist, Programme 

auszuführen. Dabei unterscheidet man zwischen Einkernprozessoren und 

Mehrkernprozessoren. Mehrkernprozessoren verfügen über mehrere vollständig 

ausgebaute Verarbeitungseinheiten (Kerne) auf einem Chip. Die einzelnen 

Kerne teilen sich lediglich den Bus, sind also als vollwertige CPUs anzusehen. 

Mehrfädige Prozessorkerne (Multi-Threaded-CPUs) verfügen über eine CPU, 

melden sich aber als mehrere CPUs am Betriebssystem an. Damit bilden sich 

für diese Kerne mehrere Warteschlangen, aus, zwischen denen der Kern hinund 

herschaltet. Um diesen Wechsel zu optimieren, besitzt jeder Thread einen 

eigenen Registersatz, einschließlich Stack Pointer und Program Counter, damit 

kann ohne zusätzliche Prozessorzyklen zwischen den Threads geschaltet werden. 

Diese hardwareseitigen Threads sollten Sie jedoch nicht mit den Threads 

verwechseln, die die Anwendungsprozesse erzeugen (User- oder Software- 

Threads). Innerhalb eines Prozesses der Datenbank, des ABAP-, Java- oder 

TREX-Servers können mehrere (Software-)Threads erzeugt werden, die vom 

Betriebssystem in Zeitscheiben ausgeführt werden. Den Wechsel zwischen 

den (Software-)Threads bezeichnet man als Kontextwechsel. Unter diesem 

Gesichtspunkt kann man also sagen, dass zusätzliche (Hardware-)Threads 

Kontextwechsel zwischen (Software-)Threads begünstigen und damit den vorhandenen 

Kern besser auslasten helfen, allerdings von der Leistungssteigerung 

nicht ganz an einen zusätzlichen Kern heranreichen. 

80


Der Abschnitt Memory enthält Informationen über den physisch vorhandenen 

Hauptspeicher (Feld Physischer Speicher) und Werte über 

das Betriebssystem-Paging. Unter Swap finden Sie den aktuell allokierten 

Auslagerungsspeicher (Swap-Space). Der Auslagerungsspeicher 

muss größer als die Summe des konfigurierten Speicherbereichs sein. 

Hauptspeicherauslastung 

Programmabbrüche durch Speicherknappheit 

Ist die Summe aus physischem Speicher und Auslagerungsspeicher kleiner 

als der vom SAP-System, von der Datenbank und anderen Programmen 

benötigte Speicher, kann es zu Speicherverwaltungsfehlern (d. h. zu Programmabbrüchen 

innerhalb des SAP-Systems), im schlimmsten Fall sogar 

zum Abbruch des Betriebssystems, kommen. Sie sollten also in jedem Fall 

den Auslagerungsspeicher ausreichend dimensionieren. 

Um einen Überblick über die CPU-Auslastung der letzten 24 Stunden 

zu erhalten, wählen Sie im Betriebssystemmonitor die Analyse 

Vorige Stunden CPU. Sie gelangen auf den Bildschirm Vorige 

Stunden CPU. Die Bedeutung der Felder ist dieselbe wie im Hauptbildschirm, 

nur sind die Werte über eine Stunde gemittelt. Einen 

ähnlichen Überblick gibt es auch für die Hauptspeicherbelegung 

(Vorige Stunden Speicher) und für den Auslagerungsspeicher etc. 

Historien: CPU und 

Hauptspeicher 

Wann liegt ein CPU- bzw. ein Hauptspeicherengpass vor? 

Im Stundenmittel sollte der freie CPU-Anteil Leerlauf mindestens 

20 % betragen, um auf kurze Lastspitzen reagieren zu können. 

Erwünscht sind sogar eher 35 % freie CPU-Kapazität. Für die Paging- 

Rate gelten folgende Richtwerte: 

Richtwerte 

 

 

Bei Rechnern, die eine Datenbank, eine Java-Instanz oder einen 

TREX beherbergen, sollten nur sehr geringe Paging-Raten zu beobachten 

sein, d. h., sie sollten so dimensioniert sein, dass der verfügbare 

Hauptspeicher den konfigurierten Speicherbereichen entspricht. 

Bei Rechnern, die ausschließlich ABAP-Instanzen tragen, können 

mäßige Paging-Raten von bis zu 20 % des physischen Hauptspeichers 

pro Stunde toleriert werden. 

Dabei ist für Betriebssysteme, die kontinuierlich Speicher auslagern 

(z. B. Microsoft Windows), die Paged-in-Rate entscheidend, für 

andere Betriebssysteme hingegen, die erst bei Bedarf auslagern (die 

81

2 


meisten UNIX-Derivate), die Paged-out-Rate. Umgekehrt bedeutet das 

Überschreiten dieser Richtwerte nicht automatisch, dass ein Hardwareengpass 

vorliegt. Vielmehr sollten Sie in diesem Fall mithilfe des 

Workload-Monitors prüfen, ob sich die CPU-Auslastung bzw. die 

Paging-Rate negativ auf die Antwortzeiten auswirkt. Entsprechende 

Analysen finden Sie in Abschnitt 3.4.1, »Allgemeines Performanceproblem 

analysieren«. 

Hauptspeicherengpass 

Wenn Sie in der Voranalyse hohe Paging-Raten auf mehreren Rechnern 

beobachten, sollten Sie den von den SAP-Instanzen und der Datenbank 

allokierten Hauptspeicher berechnen (siehe die Abschnitte 2.4.3, 

»Anzeige des allokierten Speichers«, und 2.3.2, »Analyse der Datenbankpuffer«). 

Vergleichen Sie diesen mit dem physisch vorhandenen 

Hauptspeicher. Erfahrungen zeigen, dass es in der Regel unkritisch ist, 

50 % mehr Speicher virtuell zu allokieren, als physisch vorhanden sind. 

Bei den Betriebssystemen Microsoft Windows und Oracle Solaris 

kann die Auswertung der Paging-Rate auf dem Datenbankserver zu 

Fehlinterpretationen führen, da dort Schreib-/Lese-Operationen (I/O) 

unter gewissen Umständen ebenfalls als Paging gezählt werden. Vergleichen 

Sie dazu die SAP-Hinweise 124199 (Solaris) und 689818 

(Windows). 

Ursache von Hardwareengpässen 

Ist nach den oben genannten Kriterien ein Hardwareengpass auf 

einem oder mehreren Rechnern des SAP-Systems erkennbar, sind folgende 

Ursachen möglich: 

 

Falsche Lastverteilung 

Wenn Sie in einem verteilten System mit mehreren Rechnern auf 

mindestens einem Rechner einen Hardwareengpass feststellen, 

während andere Rechner über ungenutzte Ressourcen verfügen, 

liegt vermutlich eine falsche Lastverteilung vor. In diesem Fall sollten 

Sie die SAP-Workprozesse und die Benutzer neu verteilen. 

Überaus wichtig ist es, dass der Datenbankserver über genügend 

Ressourcen verfügt. Ein CPU- oder Hauptspeicherengpass auf dem 

Datenbankserver führt dazu, dass die benötigten Daten aus der 

Datenbank nicht zügig bereitgestellt werden können, was sich wiederum 

negativ auf die Antwortzeiten innerhalb des gesamten Systems 

auswirkt. 

82


 

CPU-Auslastung einzelner Programme 

Wählen Sie im Betriebssystemmonitor (Transaktionscode ST06) 

die Analyse Snapshot Top CPU processes. Sie gelangen in die 

Übersicht der Betriebssystemprozesse. Diese gibt Ihnen einen 

Überblick über die derzeit aktiven Prozesse und deren Ressourcenauslastung. 

Abbildung 2.2 zeigt eine solche Übersicht für ein System, auf dem 

eine ABAP-Instanz und eine DB2-Datenbank installiert sind. Folgende 

Prozesse können Sie identifizieren: 

Übersicht der 

Betriebssystemprozesse 

 

 

dw_: SAP-Workprozess der SAP-ABAP-Instanz auf 

einem UNIX-Betriebssystem. Auf Windows-Betriebssystemen lautet 

die Bezeichnung disp+work. 

db2sysc: Datenbankprozess der DB2-Datenbank. Die Prozesse 

anderer Datenbanken führen in der Regel ihre Markenbezeichnung 

(z. B. Oracle) im Prozess- oder Benutzernamen. 

Abbildung 2.2 Analyse der Top-CPU-Prozesse im Betriebssystemmonitor 

83

2 


Betriebssystemprozesse, die Sie anhand der folgenden Namensbestandteile 

erkennen können, gehören außerdem zu SAP-Instanzen: 

 

 

 

 

jstart ...: Serverprozess der SAP-Java-Instanz 

TREX ...: TREX-Prozess, der Servertyp kann dem Prozessnamen 

entnommen werden, z. B. Index-Server, Präprozessor etc. 

icman ...: Prozess des Internet Communication Managers (ICM) 

saposcol ...: Hilfsprogramm, das u. a. die Daten für den Betriebssystemmonitor 

sammelt 

Analyse der CPU- 

Auslastung 

Beobachten Sie durch Auffrischen des Monitors, ob einzelne Prozesse 

über längere Zeit hinweg die CPU stark belasten (Spalte CPU (%)). 

Handelt es sich bei den Prozessen, die die CPU stark belasten, um Prozesse 

der SAP-Basis oder der Datenbank, finden Sie in den im Folgenden 

genannten Monitoren weitere Informationen über die Tätigkeiten 

der Prozesse. Starten Sie den Monitor in einem zweiten Modus, 

identifizieren Sie anhand der Prozess-ID, die Sie auch in den entsprechenden 

Basismonitoren finden, den Prozess mit der hohen CPU- 

Auslastung, und entnehmen Sie den Monitoren, welches Programm 

bzw. welche Tabelle, Anfrage etc. der Prozess gerade bearbeitet. 

 

 

 

 

 

SAP-Workprozesse der ABAP-Instanz 

Starten Sie in einem zweiten Modus die SAP-Workprozess-Übersicht 

(siehe Abschnitt 2.5, »Analyse der SAP-Workprozesse«). Der 

Workprozess-Übersicht entnehmen Sie u. a. den Namen des laufenden 

ABAP-Programms und des zugehörigen Benutzers. 

Serverprozess der Java-Instanz 

Starten Sie die SAP Management Console (siehe Abschnitt 10.3, 

»SAP Management Console«). Prozessinterna erhalten Sie durch 

einen Thread-Dump. 

TREX-Prozesse 

Starten Sie das TREX-Administrationswerkzeug (siehe Abschnitt 

14.2, »Performanceanalyse auf dem TREX durchführen«). Im 

Monitor Services finden Sie Details zu den TREX-Services. 

ICM 

Starten Sie den ICM-Monitor (siehe Abschnitt 2.6, »Analyse des 

Internet Communication Managers (ICM)«). 

Datenbankprozesse 

Starten Sie im DBA-Cockpit den Datenbankprozessmonitor (siehe 

Abschnitt 2.3.3, »Identifizierung teurer SQL-Anweisungen«), um 

84


die SQL-Anweisungen zu identifizieren, die aktuell von der Datenbank 

bearbeitet werden. 

Die Prozessübersicht auf Betriebssystemebene bietet Ihnen also 

zusammen mit den genannten Monitoren vergleichsweise bequem 

die Möglichkeit, Programme, Transaktionen bzw. SQL-Anweisungen 

oder TREX-Anfragen mit hoher CPU-Auslastung zu identifizieren. 

Ein CPU-Engpass kann durch externe Prozesse verursacht werden. Finden 

Sie in der Prozessübersicht externe Prozesse (d. h. Prozesse, die 

nicht direkt zum SAP-System gehören) mit einem hohen CPU-Konsum, 

die zu einem CPU-Engpass führen, sollten Sie prüfen, ob diese 

für den Betrieb Ihres Systems notwendig sind oder ob sie abgeschaltet 

oder auf einen anderen Rechner verlagert werden können. Beispiele 

für externe Prozesse sind: Verwaltungssoftware, Virenscanner, 

Backup, externe Systeme, Bildschirmschoner (!) etc. 

Externe Prozesse 

Identifizierung eines CPU-Engpasses 

Sie beobachten während Ihrer Hauptarbeitszeit einen CPU-Engpass. In der 

Prozessübersicht des Betriebssystemmonitors stellen Sie fest, dass ein SAP- 

Workprozess über Minuten hinweg eine CPU-Auslastung von 30 % zeigt. 

In der SAP-Workprozess-Übersicht identifizieren Sie ein lang laufendes 

Hintergrundprogramm. In diesem Fall sollten Sie prüfen, ob dieses Hintergrundprogramm 

zu Zeiten niedriger Dialoglast eingeplant werden kann. 

Analog dem Vorgehen bei einem CPU-Engpass können Sie sich bei 

einem Hauptspeicherengpass auf die Suche nach Programmen mit 

hohem Speicherbedarf machen. Vergleichen Sie dazu Kapitel 6, 

»Speicherkonfiguration«. 

Betriebssysteme verwalten in der Regel einen eigenen File System 

Cache. Dieser Cache konkurriert mit dem SAP-System und der Datenbank 

um die Nutzung des Hauptspeichers. Ist der Cache zu groß eingestellt, 

kommt es zu hohen Paging-Raten, obwohl mehr physischer 

Hauptspeicher verfügbar ist, als durch SAP-System und Datenbank 

allokiert wurden. Wir empfehlen Ihnen, diesen Cache auf 7 bis 10 % 

des physischen Speichers zu reduzieren. 

Die Betriebssystemparameter zur Einstellung des File System Caches 

sind z. B. dbc_max_pct bei HP-UX, ubc-maxpercent bei Digital UNIX 

und maxperm bei AIX. 

Speicherbedarf 

einzelner 

Programme 

File System Cache 

minimieren 

UNIX 

85

2 


Windows 

Um den Microsoft Windows File Cache zu minimieren, rufen Sie die 

Netzwerkeinstellung (Symbol: Network) im Control Panel Ihres 

Windows-Betriebssystems auf. Wählen Sie die Registerkarte Services, 

Service Server, Schaltfläche Properties. Wählen Sie in der folgenden 

Maske unter Optimization die Option Maximize Throughput 

for Network Applications aus, und bestätigen Sie mit OK. Um 

den so reduzierten File Cache zu aktivieren, muss der Rechner neu 

gestartet werden. 

Ein Hauptspeicherengpass kann zu einem erhöhten CPU-Konsum 

aufgrund starken Pagings und damit zum CPU-Engpass führen. Die 

Beseitigung des Hauptspeicherengpasses kann also unter Umständen 

ein Verschwinden des CPU-Engpasses mit sich bringen. 

2.2.2 Identifizierung von Schreib-/Lese-(I/O-)Problemen 

Im Betriebssystemmonitor (Transaktionscode ST06) finden Sie in der 

Analysesicht Snapshot Platte u. a. Informationen über die Auslastung 

der Festplatten und – sofern das Betriebssystem diese korrekt 

zur Verfügung stellt – über Warte- und Antwortzeiten der Platten. 

Festplattenmonitor 

Durch einen Doppelklick auf eine Zeile erhalten Sie für die ausgewählte 

Festplatte einen Überblick über die mittleren Antwortzeiten 

innerhalb der letzten 24 Stunden. Tabelle 2.2 listet die angezeigten 

Felder und ihre Bedeutung auf. 

Feld 

Disk 

Auslastung (%) 

Queue-Länge 

Wartezeit (ms) 

Servicezeit (ms) 

Übertragung (KB/s) 

Operationen (per Sec) 

Antwortzeit (ms) 

Bedeutung 

Name der Festplatte auf Betriebssystemebene 

Auslastung der Platte (in Prozent) 

Anzahl der Prozesse, die auf I/O-Operationen 

warten 

Wartezeit (in Millisekunden) 

Servicezeit (in Millisekunden) 

Übertragungsrate (in KB/Sekunde) 

Anzahl der I/O-Operationen (pro Sekunde) 

mittlere Antwortzeit der Festplatte (in Millisekunden) 

Tabelle 2.2 Felder des Festplattenmonitors 

86


Stellen Sie anhand dieser Monitore fest, dass einzelne Platten stark 

ausgelastet sind (Auslastung (%) > 50 %), liegt ein potenzieller I/O- 

Engpass vor. Aus dem SAP-System heraus ist allerdings nur eine sehr 

beschränkte Aussage über I/O-Probleme möglich. Eine detaillierte 

Analyse kann nur mit Mitteln des Hardwarepartners durchgeführt 

werden. 

I/O-Engpass 

Ein I/O-Engpass ist insbesondere dann kritisch, wenn auf dieser Festplatte 

der Auslagerungsspeicher des Betriebssystems liegt. Darüber 

hinaus ist der Betriebssystemmonitor für den Datenbankserver von 

besonderem Interesse. Zusammen mit dem Datenbankmonitor können 

mit dieser Anzeige Engpässe beim Lesen bzw. Schreiben auf die 

Festplatten eingegrenzt werden. Weitere Details zu diesem Problem 

finden Sie in Abschnitt 2.2.2, »Identifizierung von Schreib-/Lese-(I/O-) 

Problemen«. 

2.2.3 Weitere Analysen auf Betriebssystemebene 

Das SAP-System protokolliert für UNIX-Betriebssysteme alle Änderungen 

der Betriebssystemparameter. Das Änderungsprotokoll kann 

über den folgenden Pfad im Betriebssystemmonitor angezeigt werden: 

Weitere Funktionen Parameteränderungen. Positionieren 

Sie den Cursor auf dem Namen eines Servers, und wählen Sie die 

Schaltfläche History of File. Anhand des Änderungsprotokolls lässt 

sich feststellen, ob Performanceprobleme eventuell erst nach Parameteränderungen 

aufgetreten sind und damit in Zusammenhang gebracht 

werden können. 

Mit dem Werkzeug Weitere Funktionen LAN-Überprüfung mit 

Ping lässt sich ein grober Netzwerktest durchführen. Sie können 

beliebige Datenbank-, Applikations- oder Präsentationsserver auswählen 

und die Netzwerkverbindung (z. B. die Antwortzeiten und 

Datenverluste) testen. Auch wenn der Name der Analyse fälschlicherweise 

LAN-Überprüfung heißt, können auch Rechner im WAN angesprochen 

werden. Ein Beispiel für eine Analyse mit diesem Werkzeug 

finden Sie in Abschnitt 8.1.2, »Performance der GUI-Kommunikation 

analysieren und optimieren«. 

Parameteränderungen 

Netzwerk-Check 

87

2 


Zusammenfassung 

Die Gefahr eines Hardwareengpasses besteht, wenn: 

 

 

 

im Stundenmittel weniger als 20 % CPU-Kapazität frei sind 

mehr als 20 % des physischen Hauptspeichers pro Stunde ausgelagert 

(»gepaged«) werden 

einzelne Festplatten der Datenbank zu mehr als 50 % ausgelastet 

sind 

Insbesondere die Überlastung des Datenbankservers kann zu Performanceproblemen 

führen, die sich systemweit auswirken. Prüfen Sie 

mithilfe des Workload-Monitors, ob sich die hohe CPU-Auslastung 

bzw. die hohen Paging-Raten negativ auf die Antwortzeiten des SAP- 

Systems bzw. der Datenbank auswirken (siehe Abschnitt 3.4, »Workload-Analyse 

durchführen«). 

Hardwareengpass 

analysieren 

Abbildung 2.3 und Abbildung 2.4 zeigen den Analysepfad bei einem 

Hardwareengpass: Häufig kann ein Hardwareengpass durch die Neuverteilung 

der Last (z. B. durch das Verlagern von Workprozessen) 

behoben werden. Ursachen für einen CPU-Engpass sind z. B. ineffiziente 

Applikationen, die im Datenbankprozessmonitor und in der 

Workprozess-Übersicht identifiziert werden können, oder externe, 

nicht zu einer SAP-Instanz bzw. der Datenbankinstanz gehörende 

Prozesse. Daher muss immer eine vollständige Performanceanalyse 

durchgeführt werden, bevor endgültig entschieden werden kann, ob 

die vorhandene Hardware für die gegebenen Anforderungen an das 

SAP-System ausreicht oder nicht. 

Die Flussdiagramme in Abbildung 2.3 und Abbildung 2.4 zeigen 

Ihnen schematisch das Vorgehen bei einem Hardwareengpass. Sie 

verweisen auf später in diesem Buch beschriebene Monitore und 

Analysen. Sie werden ähnliche Diagramme an vielen Stellen dieses 

Buches finden. 

88

Datenbankanalyse 2.3 

Betriebssystemmonitor (Transaktionscode ST06) 

Hohe CPU-Auslastung (CPU idle im Stundenmittel < 35%) 

Ist noch CPU-Speicherkapazität auf anderen Rechnern des Systems frei? 

SAP-Workprozesse und Benutzer neu verteilen! 

Betriebssystemmonitor (Transaktionscode ST06): Top-CPU-Prozesse 

SAP-Workprozesse mit hoher CPU-Auslastung 

Workprozess-Übersicht (Transaktionscode SM50 oder SM66) 

Detailanalyse des ABAP-Programms (mit ABAP-Trace SE30) 

Datenbankprozesse mit hoher CPU-Auslastung? 

Datenbankprozessmonitor (DBA-Cockpit, z. B. DB2 Applications) 

Detailanalyse teurer SQL-Anweisungen 

Externe Prozesse mit hoher CPU-Auslastung? 

Abschalten, optimieren oder verlagern! 

Abbildung 2.3 Detailanalyse eines Hardwareengpasses (CPU) 

Betriebssystemmonitor (Transaktionscode ST06) 

Hohe Paging-Rate (Paging pro Stunde > 20 % des RAM)? 

Ist noch CPU- und Speicherkapazität auf anderen Rechnern des Systems frei? 

SAP-Workprozesse und Benutzer neu verteilen 

File System Cache > 10 % des RAM? 

File System Cache reduzieren 

SAP-Speicherkonfigurationsmonitor (Transaktionscode ST02): Modusliste 

Benutzer mit hohem Speicherverbrauch? 

Detailanalyse der Aktionen des Benutzers 

Abbildung 2.4 Detailanalyse eines Hardwareengpasses (Hauptspeicher) 

2.3 Datenbankanalyse 

Der SAP NetWeaver Application Server (AS) kann zurzeit mit acht 

verschiedenen relationalen Datenbanksystemen sowie mit der 

Hauptspeicherdatenbank SAP HANA betrieben werden. Auch wenn 

diese Datenbanksysteme alle eine unterschiedliche Architektur besit- 

89

Sperren auf Datenbanktabellen oder Geschäftsobjekten sind 

die Voraussetzung für konsistente Daten. Werden Sperren zu 

lange gehalten, kann es im System zu Performanceproblemen 

kommen, da Benutzer und Prozesse auf die Freigabe der Sperren 

warten müssen. Dieses Kapitel stellt detailliert die Sperrkonzepte 

und deren Überwachung dar. 

9 Sperren 

In einem SAP-System können viele Benutzer gleichzeitig Inhalte von 

Datenbanktabellen lesen. Bei Änderungen des Datenbestands ist es 

jedoch notwendig, sicherzustellen, dass zu einem bestimmten Zeitpunkt 

nur genau ein Benutzer einen bestimmten Tabelleninhalt 

ändern kann. Zu diesem Zweck werden Tabelleninhalte während der 

Änderung gesperrt. Die Sperrkonzepte von SAP-System und Datenbanksystem 

werden im ersten Abschnitt dieses Kapitels erklärt. 

Werden Sperren lange Zeit gehalten, kann es zu Wartesituationen 

kommen, die den Durchsatz des SAP-Systems beschränken. Mit allgemeinen 

Performanceaspekten von Sperren beschäftigt sich der zweite 

Abschnitt dieses Kapitels. 

Für die Verfügbarkeitsprüfung nach ATP-Logik (Available to Promise) 

und die Nummernvergabe für Dokumente verwendet das SAP-System 

spezielle Pufferungstechniken, die die Sperrzeit minimieren und 

den Durchsatz maximieren sollen. Diese Techniken werden im dritten 

und vierten Abschnitt diskutiert. 

Wann sollten Sie dieses Kapitel lesen? 

Dieses Kapitel sollten Sie lesen: 

 

 

um sich über Datenbanksperren und SAP-Sperren (SAP-Enqueues) 

zu informieren 

wenn Sie in Ihrem SAP-System Probleme mit Datenbanksperren 

oder SAP-Enqueues identifiziert haben und diese detaillierter analysieren 

wollen 

403

9 

Sperren 

Dieses Kapitel ist keine Anleitung zur Entwicklung von SAP-Transaktionen. 

Dazu verweisen wir Sie auf ABAP-Lehrbücher oder die SAP- 

Onlinehilfe. 

9.1 Sperrkonzepte von Datenbanksystem und 

SAP-System 

Datenkonsistenz 

Die Konsistenz der Daten in einem Datenbank- oder SAP-System wird 

durch Sperren realisiert. Das SAP-System und das Datenbanksystem 

bieten jeweils eigene Sperrkonzepte an, die zwar beide demselben 

Zweck dienen (nämlich die Datenkonsistenz zu gewährleisten), aber 

unterschiedliche technische Realisierungen und Einsatzbereiche 

haben. Sperren, die vom Datenbanksystem verwaltet werden, heißen 

Datenbanksperren (Database Locks), die vom SAP-System verwalteten 

Sperren heißen SAP-Enqueues. 

Bestellen eines Computers 

Beim Konfigurieren und Bestellen eines neuen Computers muss geprüft 

werden, ob alle gewünschten Komponenten zur Verfügung stehen, z. B. 

Gehäuse, CPU, Hauptspeicher, Festplatte etc. Dabei gilt der Grundsatz 

»ganz oder gar nicht«, d. h., wenn eine Komponente ausverkauft ist, kann 

die Verfügbarkeit des gesamten Rechners nicht bestätigt werden. Wird 

nun die Verfügbarkeit der unterschiedlichen Komponenten nacheinander 

geprüft, muss für diesen Prüfzeitraum sichergestellt werden, dass andere 

Benutzer nicht auf die einmal geprüften und bestätigten Komponenten zugreifen, 

bis die gesamte Bestellung endgültig bestätigt oder abgebrochen 

wurde. 

9.1.1 Datenbanksperren 

Datenbanksperren werden vom Lock Handler der Datenbankinstanz 

verwaltet. Die gesperrte Einheit ist eine Zeile einer Datenbanktabelle 

(spezielle Ausnahmen werden am Ende von Abschnitt 9.2.1, »Datenbanksperren« 

erläutert). Datenbanksperren werden bei allen ändernden 

SQL-Anweisungen (UPDATE, INSERT, DELETE) sowie bei der 

Anweisung SELECT FOR UPDATE gesetzt. Sie werden so lange gehalten, 

bis mit der SQL-Anweisung COMMIT (Datenbank-Commit) alle Änderungen 

auf der Datenbank für gültig erklärt und dann die Datenbanksperren 

gelöst werden. Den Zeitraum zwischen zwei Datenbank- 

404

Sperrkonzepte von Datenbanksystem und SAP-System 9.1 

Commits bezeichnet man als Datenbanktransaktion. Alternativ können 

alle ändernden SQL-Anweisungen mit der SQL-Anweisung 

ROLLBACK (Datenbank-Rollback) zurückgenommen werden. In diesem 

Fall werden die gehaltenen Datenbanksperren ebenfalls gelöst. 

Bestellen eines Computers (Fortsetzung) 

Das oben erläuterte Beispiel der Verfügbarkeitsprüfung beim Bestellen 

eines Computers mithilfe von Datenbanksperren realisieren Sie in der Programmierung 

mit der SQL-Anweisung SELECT FOR UPDATE: Mit dieser Anweisung 

wird gleichzeitig der Bestand einer Komponente gelesen und eine 

Sperre auf den entsprechenden Bestand gesetzt. Haben Sie diese Prüfung 

für alle Komponenten erfolgreich durchgeführt, ändern Sie anschließend 

den Bestand (mit einem UPDATE auf die entsprechenden Zeilen) und geben 

mit einem COMMIT alle Sperren frei. Während eine Sperre besteht, können 

andere Benutzer die Daten zwar lesen (ein einfaches SELECT ist möglich), 

nicht aber selbst die Zeile sperren. Es kann also weder ein UPDATE noch ein 

SELECT FOR UPDATE durchgeführt werden. Eine solche Sperre bezeichnet 

man als exklusiv. 

Am Ende eines Transaktionsschrittes löst der SAP-Workprozess automatisch 

einen Datenbank-Commit (oder einen Datenbank-Rollback) 

aus. Damit werden alle Datenbanksperren gelöst. Daraus ergibt sich, 

dass Datenbanksperren nicht über mehrere Transaktionsschritte 

(d. h. im SAP-System über mehrere Eingabebildschirme) hinweg 

gehalten werden können. 

9.1.2 SAP-Enqueues 

Um Sperren über mehrere Schritte einer SAP-Transaktion hinweg zu 

halten, verwenden Sie die SAP-eigene Enqueue-Verwaltung. Die SAP- 

Enqueues werden vom Enqueue-Workprozess in der Enqueue- 

Tabelle verwaltet, die sich im Hauptspeicher befindet. Damit SAP- 

Enqueues auch beim Stoppen der SAP-Instanz erhalten bleiben, werden 

diese zusätzlich in einer lokalen Datei auf dem Enqueue-Server 

gesichert. 

Durch einen SAP-Enqueue wird ein logisches Objekt gesperrt. So 

können z. B. Zeilen aus mehreren Datenbanktabellen gesperrt werden, 

die zusammen einen Beleg bilden. Ein SAP-Enqueue kann auch 

eine oder mehrere Tabellen sperren. SAP-Enqueue-Objekte werden 

im ABAP Dictionary (Abschnitt Sperrobjekte) angelegt und geändert. 

Sie hängen eng mit den Begriffen SAP-Transaktion und SAP Logical 

SAP-Enqueue- 

Objekte 

405

9 

Sperren 

Unit of Work (SAP LUW) zusammen. Zu beiden Begriffen finden Sie 

umfangreiche Dokumentationen in der ABAP-Literatur zur Dialogprogrammierung. 

Die Funktionsweise und Anwendung dieser Techniken 

innerhalb von ABAP-Programmen wird daher an dieser Stelle 

nicht erläutert. Es soll genügen, hier die für eine Performanceanalyse 

relevanten Aspekte darzustellen. Werden Performanceprobleme aufgrund 

eines fehlerhaften Einsatzes von SAP-Enqueues entdeckt, muss 

in jedem Fall der zuständige ABAP-Entwickler hinzugezogen werden. 

Ein SAP-Enqueue ist eine logische Sperre innerhalb des SAP-Systems. 

Eine direkt auf der Datenbank ausgeführte SQL-Anweisung oder ein 

kundeneigenes ABAP-Programm, das sich nicht an die SAP-Enqueue- 

Konventionen hält, kann eine Tabellenzeile in der Datenbank ändern, 

obwohl diese Zeile im SAP-System durch einen SAP-Enqueue 

gesperrt ist. SAP-Enqueues gelten also nur innerhalb des SAP-Systems. 

Datenbanksperren dagegen sind für alle Zugriffe wirksam. Sie 

sperren eine Tabellenzeile »hart« für alle Datenbankbenutzer, also 

auch für solche außerhalb des SAP-Systems. 

Funktionsbausteine 

Zu jedem aktivierten SAP-Enqueue-Objekt existieren zwei Funktionsbausteine: 

ein Enqueue-Baustein und ein Dequeue-Baustein. Ein SAP- 

Enqueue wird innerhalb eines ABAP-Programms explizit durch den 

Aufruf des zugehörigen Enqueue-Bausteins gesetzt und explizit durch 

den entsprechenden Dequeue-Baustein freigegeben. SAP-Enqueues 

können damit über mehrere Transaktionsschritte gehalten werden. 

Alle SAP-Enqueues werden allerdings automatisch bei Beendigung 

einer SAP-Transaktion freigegeben. 

Bestellen eines Computers (Fortsetzung) 

Anhand unseres Beispiels der Rechnerkonfiguration und -bestellung erläutern 

wir die Funktionsweise der SAP-Enqueue-Verwaltung: Zum Rechner 

gehören z. B. Gehäuse, CPU, Hauptspeicher und Festplatte. Die einzelnen 

Komponenten werden auf unterschiedlichen Eingabebildschirmen, d. h. 

mit mehreren Transaktionsschritten, bearbeitet und zur Bearbeitung durch 

SAP-Enqueues gesperrt. Nachdem sichergestellt ist, dass jede Komponente 

einzeln reserviert werden kann, wird die Bestellung des Computers 

bestätigt. Damit ist der Dialogteil der Transaktion abgeschlossen. 

Ein Verbuchungs-Workprozess führt anschließend unter dem Schutz der 

SAP-Enqueues die notwendigen Änderungen der Datenbanktabellen aus. 

Erst nachdem der Verbuchungs-Workprozess seine Arbeit beendet hat, ist 

die SAP LUW abgeschlossen, und die SAP-Enqueues werden wieder freigegeben. 

406

Überwachung von Sperren 9.2 

Zu einer SAP LUW gehören eventuell noch Bausteine, die in der V2- 

Verbuchung bearbeitet werden. Dieses erfolgt ohne SAP-Enqueues. 

In Bausteinen, die V2-verbuchbar sind, dürfen also nur Informationen 

bearbeitet werden, die nicht des Schutzes durch SAP-Enqueues 

bedürfen (siehe auch Abschnitt 7.1.8, »Verbuchung«). 

Die wichtigsten Eigenschaften von Datenbanksperren und SAP- 

Enqueues fasst Tabelle 9.1 zusammen. 

Gesperrtes 

Objekt 

Sperre 

wird 

gesetzt 

Sperre 

wird freigegeben 

Maximale 

Haltedauer 

Verhalten 

bei Sperrkonflikt 

Wartesituation (Exclusive 

Lockwait, siehe auch 

Abschnitt 9.2.1, »Datenbanksperren«) 

Überwachung 

DB-Sperren (Locks) 

 

einzelne Zeile einer 

Datenbanktabelle 

implizit durch ändernde 

SQL-Anweisungen (z. B. 

UPDATE) und SELECT FOR 

UPDATE 

 

 

 

implizit durch SQL- 

Anweisung COMMIT 

bzw. ROLLBACK 

grundsätzlich am Ende 

eines Transaktionsschrittes 

Länge eines Transaktionsschrittes 

Transaktionscode DB01, 

Exclusive Lockwaits 

SAP-Sperren (Enqueues) 

 

 

logisches Objekt (z. B. ein 

Beleg) 

definiert im ABAP 

Dictionary 

explizit durch Aufruf eines 

Enqueue-Bausteins im 

ABAP-Programm 

 

 

explizit durch Aufruf eines 

Dequeue-Bausteins 

grundsätzlich am Ende 

einer SAP-Transaktion 

über mehrere Transaktionsschritte 

hinweg 

programmabhängig, z. B. 

Fehlermeldung »Material X 

ist gesperrt« 

Transaktionscode SM12, 

Sperrverwaltung 

Tabelle 9.1 Eigenschaften von Datenbanksperren und SAP-Enqueues 

9.2 Überwachung von Sperren 

In diesem Abschnitt geben wir Ihnen Hinweise zur Überwachung 

von Datenbanksperren und SAP-Enqueues. 

407

9 

Sperren 

9.2.1 Datenbanksperren 

Exclusive 

Lockwaits 

Was geschieht bei einem Sperrkonflikt, d. h., wenn ein Workprozess 

ein Objekt sperren will, das bereits gesperrt ist? Bei Datenbanksperren 

wartet der zweite Prozess so lange, bis der Halter der Sperre diese 

wieder freigegeben hat. Diese Wartesituation bezeichnet man als 

Exclusive Lockwait. Bei den meisten Datenbanken gibt es keine zeitliche 

Beschränkung für diese Sperre. Wird die Sperre durch ein fehlerhaftes 

Verhalten des Programms nicht wieder freigegeben, kann die 

Wartesituation ad infinitum bestehen. 

Zu einer Eskalation kann es kommen, wenn ein Programm eine für das 

SAP-System »lebenswichtige« Sperre (z. B. auf die Nummernkreistabelle 

NRIV) hält und nicht wieder freigibt. In diesem Fall besteht die 

Gefahr, dass ein Workprozess nach dem anderen auf diese Sperre wartet. 

Sind schließlich alle Workprozesse belegt, besteht schließlich aus 

dem SAP-Systems heraus keine Möglichkeit des Eingreifens mehr. Es 

bleibt als letzte Alternative nur noch, mit Mitteln des Betriebssystems 

den fehlerhaften Prozess abzubrechen (sofern er dann noch ermittelt 

werden kann). 

Sperrwartesituation 

prüfen 

Die aktuellen Sperrwartesituationen werden im Datenbank-Sperrmonitor 

(Transaktionscode DB01) angezeigt, den Sie im DBA-Cockpit 

(Transaktionscode DBACOCKPIT) über Performance Wartesituationen 

auf Sperren und Deadlocks oder in der globalen Workprozess-Übersicht 

(Transaktionscode SM66) über Springen DB Locks 

starten können. 

Die Beschreibung dieses Monitors und Hinweise, wie Sie bei Sperrwartesituationen 

vorgehen können, finden Sie in Abschnitt 2.3.5, 

»Weitere Analysen auf Datenbankebene«. Sperrwartesituationen tragen 

zur Datenbankzeit bei und führen in den Statistiken des Workload-Monitors 

zu einer erhöhten Datenbankzeit. Von einigen Datenbanksystemen 

werden Sperrwartezeiten explizit aufgezeichnet und 

im Datenbankmonitor angezeigt. 

Sperrsituation auf der Datenbank 

Mit dem folgenden Beispielprogramm können Sie eine Sperrsituation auf 

der Datenbank provozieren: 

REPORT zts_lock. 

DATA: lv_text type natxt. 

SELECT SINGLE FOR UPDATE text FROM T100 INTO lv_text WHERE sprsl 

408


= 'DE' AND ARBGB = '00' AND msgnr = '001'. 

BREAK-POINT. 

Gehen Sie dazu wie folgt vor: 

1. Starten Sie das Programm in der ABAP Workbench (z. B. über Transaktionscode 

SE38). Nach wenigen Sekunden startet der Debugger, das 

Programm hält am Befehl BREAK-POINT an. Zuvor hat das Programm mit 

dem Befehl SELECT SINGLE FOR UPDATE eine Datenbanksperre gesetzt. 

Da das Programm im Debug-Modus wartet, wird diese Datenbanksperre 

nicht zurückgenommen. 

2. Starten Sie nun in einem zweiten Modus das Programm erneut. Im 

zweiten Modus wird Ihnen die Sanduhr angezeigt. 

3. Sie können das Programm erneut in einem dritten Modus starten, es 

wird Ihnen wiederum die Sanduhr angezeigt. 

4. Starten Sie in einem weiteren Modus den Datenbanksperrmonitor, wie 

zuvor beschrieben. Die Sperrsituation wird angezeigt, und Sie können 

erkennen, welcher Workprozess die Sperre hält und welcher wartet. 

Mithilfe der Workprozess-Übersicht (Transaktionscode SM50) und des 

Datenbankprozessmonitors können Sie nun analysieren, was der Prozess, 

der die Sperre hält, tut. In unserem Beispiel finden Sie als Status in 

der Prozessübersicht hält und als Grund Debug. 

5. Gehen Sie nun in den Debugger, und führen Sie dort die Ausführung des 

Programms im ersten Modus fort. Das Programm wird beendet, die 

Datenbanksperre wird durch ein implizites Commit oder Rollback der 

Datenbankschnittstelle abgeräumt, und damit kann das Programm im 

zweiten Modus, das bisher beim Befehl SELECT SINGLE FOR UPDATE wartete, 

fortfahren. Es wird also innerhalb kürzester Zeit ebenfalls den 

Befehl BREAK-POINT erreichen und den Debugger starten. 

6. Setzen Sie auch im zweiten und, falls Sie das Programm in weiteren 

Modi gestartet haben, auch in diesen das Programm im Debugger fort, 

um die Sperren freizugeben. 

Grundsätzlich müssen Sie in Programmen darauf achten, dass Sperren 

möglichst spät angefordert werden. Es ist also besser, zunächst 

alle benötigten Informationen von der Datenbank zu lesen und zu 

bearbeiten, bevor Änderungen in der Datenbank vorgenommen und 

Sperren gesetzt werden. In Abbildung 9.1 ist dies schematisch dargestellt: 

Im oberen Teil der Abbildung werden während einer Datenbanktransaktion 

mehrere Änderungen auf der Datenbank vorgenommen 

und damit Datenbanksperren unnötig lange gehalten. Der 

untere Teil der Abbildung zeigt die elegantere Art der Programmierung: 

Während der Datenbanktransaktion werden die Änderungen 

in einer internen Tabelle gesammelt und erst zum Ende der Transak- 

Typische Probleme 

409

9 

Sperren 

tion gebündelt in der Datenbank ausgeführt. Folglich verkürzt sich 

die Sperrzeit auf der Datenbank. 

A) 

ABAP 


Einzelne Updates 

Datenbanksperren 

COMMIT 

B) 

ABAP 

APPEND TO 

SORT 

UPDATE FROM 

 

COMMIT 


Datenbanksperren 

DB LUW 

Abbildung 9.1 Sperren sollen möglichst spät gesetzt werden. 

Ursachen 

Eine Ursache von Sperrproblemen, die in SAP-Systemen immer wieder 

beobachtet wird, sind Kundenmodifikationen von Verbuchungsbausteinen. 

Die Trennung von Dialog- und Verbuchungsverarbeitung 

bringt den Vorteil mit sich, dass im Dialogteil einer Transaktion nur 

wenige Änderungen auf der Datenbank vorgenommen und damit 

auch nur wenige Sperren gesetzt werden. Vielmehr werden diese im 

Verbuchungsteil der Transaktion konzentriert. Mitunter werden Verbuchungsbausteine 

modifiziert, um z. B. eine kundeneigene Schnittstelle 

mit Daten zu versorgen. Wird diese Modifikation durchlaufen, 

nachdem bereits Sperren gesetzt wurden, und ist diese Modifikation 

inperformant, weil sie z. B. eine lang laufende SQL-Anweisung enthält, 

kommt es zu massiven Sperrproblemen in der Verbuchungsverarbeitung. 

Eine zweite Quelle von Sperrproblemen sind Hintergrundprogramme, 

die eine Sperre anfordern und dann mehrere Stunden arbeiten, 

ohne ein Datenbank-Commit auszulösen. Sollen die gesperrten 

Objekte ebenfalls von Dialogtransaktionen bearbeitet werden, müssen 

diese warten, bis das Hintergrundprogramm beendet ist oder ein 

Commit auslöst. Eine Lösung für dieses Problem kann es sein, das 

410


Hintergrundprogramm in regelmäßigen Abständen ein Commit auslösen 

zu lassen (wenn dies vom Standpunkt der Datenkonsistenz 

möglich ist) oder es nur zu Zeiten einzuplanen, in denen es den Dialogbetrieb 

nicht stört. Ähnliche Probleme treten bei der Parallelisierung 

von Hintergrundläufen auf, d. h., wenn dasselbe Programm 

mehrfach parallel gestartet wird. Diese Parallelisierung macht jedoch 

nur dann Sinn, wenn die Selektionsbedingungen so gewählt werden, 

dass sich die parallel laufenden Programme nicht gegenseitig die 

Daten sperren. 

Deadlocks 

Während Sie sich im ABAP Debugger befinden, wird in der Regel kein Datenbank-Commit 

ausgelöst, d. h., alle Datenbanksperren bleiben bestehen, 

bis Sie den Debugger wieder verlassen. Vermeiden Sie es daher, in 

einem produktiven SAP-System mit dem Debugger zu arbeiten. 

Im Folgenden beschreiben wir ein Beispiel für eine Situation, die man als 

Deadlock bezeichnet. Nehmen wir an, die Workprozesse 1 und 2 wollen 

jeweils eine Liste von Materialien sperren. Workprozess 1 sperrt Material 

A und Workprozess 2 Material B. Anschließend fordert Workprozess 1 eine 

Sperre auf Material B an, Workprozess 2 eine Sperre auf Material A. Beide 

Workprozesse können die angeforderten Sperren nicht bekommen, da 

diese vom jeweils anderen gehalten werden. Es entsteht also eine Situation, 

in der sich beide Prozesse gegenseitig blockieren. Solche Deadlocks 

werden von der Datenbankinstanz automatisch erkannt und aufgelöst, 

indem einem der beiden Workprozesse eine Fehlermeldung zurückgegeben 

wird. Diese führt dann zum Abbruch des ABAP-Programms und wird 

im SAP-Syslog protokolliert. 

Deadlocks können durch geschickte Programmierung leicht vermieden 

werden. Wird in unserem Beispiel das Programm so geändert, dass die Materialliste 

vor dem Sperren sortiert wird, wird immer zuerst Material A gesperrt 

und erst, wenn dies erfolgreich war, Material B. Damit ist ein Deadlock 

ausgeschlossen. 

Deadlock-Situationen sollten die absolute Ausnahme sein. Treten diese 

vermehrt auf, deutet dies auf einen Fehler im Programm oder in der Konfiguration 

der Datenbankinstanz hin. 

Von einigen Datenbanksystemen (z. B. DB2 und SAP MaxDB) werden 

in gewissen seltenen Fällen Einzelsatzsperren automatisch zu Tabellensperren 

zusammengefasst, wenn die Anzahl der gesperrten Zeilen 

einer Tabelle eine gewisse Quote im Verhältnis zur Gesamtzahl von 

Zeilen in der Tabelle (z. B. 10 %) überschreitet. In diesem Fall entscheiden 

diese Datenbankensysteme, dass es günstiger ist, die 

Tabellensperren 

411

9 

Sperren 

gesamte Tabelle für einen Workprozess zu sperren, anstatt viele Sperren 

auf einzelne Zeilen zu verwalten. Praktische Konsequenzen hat 

dieses Verhalten z. B. für die Parallelisierung von Programmen, die 

eine gesamte Tabelle ändern sollen. Es ist nicht möglich, Hintergrundjobs 

so einzuplanen, dass z. B. der eine die erste Hälfte der 

Tabelle aktualisiert und der zweite gleichzeitig die andere Hälfte, da 

die Datenbank nach kurzer Zeit die Tabelle exklusiv für einen der 

Jobs sperren wird. Betroffen von dieser Einschränkung ist z. B. der 

Periodenverschieber in der Materialwirtschaft. 

Tabellensperren 

Durch Datenbankparameter können Sie beeinflussen, wann Einzelsatzsperren 

automatisch zu Tabellensperren zusammengefasst werden. 

Ganze Tabellen werden auch aus administrativen Gründen gesperrt, z. B. 

beim Anlegen von Indizes und bei bestimmten Tabellen- oder Indexanalysen 

der Datenbank (z. B. VALIDATE STRUCTURE bei Oracle). Werden diese 

Operationen im produktiven Betrieb durchgeführt, können daraus massive 

Performanceprobleme resultieren. 

9.2.2 SAP-Enqueues 

Die SAP-Enqueues werden in der Enqueue-Tabelle verwaltet, die sich 

im globalen Hauptspeicher des Enqueue-Servers befindet. Die Workprozesse 

des Enqueue-Servers greifen direkt auf die Enqueue-Tabelle 

zu, Workprozesse anderer Applikationsserver lassen ihre Sperroperationen 

vom Enqueue-Workprozess durchführen, wobei sie über den 

Message-Service miteinander kommunizieren (1, 2 in Abbildung 

9.2). In Abbildung 9.2 werden folgende Abkürzungen verwendet: 

DIA: Dialog-Workprozess; ENQ: Enqueue-Workprozess; ENQ-Tab: 

Enqueue-Tabelle. 

Instanz A (Enqueue-Server) 

Instanz B 

Message-Server 

Dispatcher 

Dispatcher 

DIA 

DIA 

DIA 

ENQ 

DIA 

DIA 

DIA 

ENQ-Tab 

Abbildung 9.2 Kommunikation beim Setzen und Freigeben von SAP-Enqueues 

412


Das Setzen und Freigeben von Sperren dauert bei Workprozessen des 

Enqueue-Servers weniger als eine Millisekunde, bei Workprozessen 

anderer Applikationsserver weniger als 100 Millisekunden. 

Wird ein SAP-Enqueue angefordert, der schon von einem anderen 

Benutzer gehalten wird, wird der Versuch, die Sperre zu setzen, 

zurückgewiesen und die Kontrolle mit einer entsprechenden Fehlermeldung 

an das ABAP-Programm zurückgegeben. Es steht nun dem 

Anwendungsentwickler frei, diese Fehlermeldung im Programm zu 

behandeln. Bei Programmen im Dialogbetrieb wird in der Regel die 

entsprechende Fehlermeldung an den Benutzer weitergereicht, z. B. 

mit der Nachricht »Material X gesperrt durch Benutzer Y«. In Hintergrundprogrammen 

wird dann zu einem späteren Zeitpunkt erneut 

versucht, die Sperre zu setzen. Nach einer gewissen Anzahl erfolgloser 

Versuche wird eine entsprechende Fehlermeldung in das Protokoll 

des Programms geschrieben. 

Performanceprobleme 

mit 

SAP-Enqueues 

Performanceprobleme aufgrund von (zu) lang gehaltenen SAP- 

Enqueues ergeben sich aus der Tatsache, dass der Benutzer nach 

einem erfolglosen Versuch seine Eingabe wiederholen wird. Nehmen 

wir z. B. an, dass er eine Materialliste bearbeiten und dazu 100 SAP- 

Enqueues setzen müsse. Schlägt der Versuch beim 99. Enqueue fehl 

und bricht das Programm mit der Meldung »Material Nummer 99 ist 

gesperrt« ab, war die gesamte zuvor vom System geleistete Arbeit 

vergebens und muss wiederholt werden. Fehlgeschlagene Anforderungen 

von Enqueues führen also zu erhöhter Last auf dem System 

und begrenzen den Durchsatz von Transaktionen. 

Eine Übersicht über alle zurzeit aktiven SAP-Enqueues gibt Ihnen 

Transaktion SM12 über den Pfad: 

Werkzeuge Administration Monitor Sperreinträge 

Zur Fehlerdiagnose starten Sie die folgenden Testprogramme: 

Zusätze Diagnose bzw. Zusätze Diagnose in VB 

Werden Fehler gemeldet, suchen Sie im SAP Service Marketplace der 

SAP nach Hinweisen oder wenden sich direkt an SAP. 

Über die Menüoption Zusätze Statistik gelangen Sie in eine Statistik 

zur Aktivität des Enqueue-Services. Die ersten drei Werte zeigen 

die Anzahl der Enqueue-Anforderungen, die Anzahl der erfolglosen 

Anforderungen (erfolglos, weil der angeforderte Enqueue bereits 

Enqueue-Statistik 

413

9 

Sperren 

anderweitig gehalten wurde) und die Anzahl der Fehler bei Enqueue- 

Anforderungen. Dabei sollte der Anteil der erfolglosen Anforderungen 

nicht mehr als 1 % der gesamten Anforderungen ausmachen. 

Fehler sollten überhaupt nicht auftreten. 

9.3 Nummernkreispufferung 

Bei vielen Datenstrukturen ist es erforderlich, auf die einzelnen 

Datenbanksätze gezielt zugreifen zu können. Dies wird mit eindeutigen 

Schlüsseln realisiert. Nummernkreise dienen dazu, einzelnen 

Datensätzen zu einem betriebswirtschaftlichen Objekt Nummern zur 

Vervollständigung des Schlüssels zuzuweisen. Solche Nummern sind 

z. B. Auftragsnummern oder Materialstammnummern. Mit der SAP- 

Nummernkreisverwaltung wird der Nummernstand überwacht, 

sodass bereits vergebene Nummern nicht erneut verteilt werden. 

9.3.1 Grundlagen 

Ein betriebswirtschaftliches Objekt, für das über die Nummernkreise 

Teilschlüssel gebildet werden sollen, wird als Nummernkreisobjekt im 

SAP-System definiert. Ein Nummernkreis enthält ein Nummernkreisintervall 

mit definiertem Zeichenvorrat. Das Nummernkreisintervall 

besteht aus Zahlen oder alphanumerischen Zeichen und 

wird begrenzt durch die Felder Von-Nummer und Bis-Nummer. Einem 

Nummernkreis werden ein oder mehrere Intervalle zugeordnet. 

Technische 

Realisierung 

Der aktuelle Nummernkreisstand eines Nummernkreises, d. h. die 

Nummer, die als nächste vergeben wird, wird in der Datenbanktabelle 

NRIV verwaltet. Benötigt ein Programm eine Nummer (z. B. 

aus dem Nummernkreis MATBELEG), führt es die folgenden Schritte 

durch: 

1. Das Programm liest den aktuellen Nummernkreisstand von der 

Tabelle NRIV und sperrt gleichzeitig den Nummernkreis MATBELEG. 

Dazu setzt es eine Datenbanksperre mit der SQL-Anweisung 

SELECT FOR UPDATE auf die Zeile der Tabelle NRIV, die den Nummernkreis 

MATBELEG verwaltet. 

414

2 Analyse von Hardware, Datenbank und ABAP-Applikationsserver

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?