SAP -Performanceoptimierung€¦ · Bonn Boston Thomas Schneider SAP®-Performanceoptimierung Analyse und Tuning von SAP-Systemen 2177.book Seite 3 Montag, 10. Juni 2013 11:30 11

Bonn � Boston

Thomas Schneider

SAP®-PerformanceoptimierungAnalyse und Tuning von SAP-Systemen

2177.book Seite 3 Montag, 10. Juni 2013 11:30 11

Auf einen Blick

1 Performancemanagement einer SAP-Lösung ........... 33

2 Analyse von Hardware, Datenbank und ABAP-Applikationsserver ........................................ 75

3 Workload-Analyse .................................................. 149

4 Identifizierung von Performanceproblemen in ABAP-Programmen ............................................. 189

5 Hardware-Sizing, System- und Lastverteilung .......... 239

6 Speicherkonfiguration ............................................. 281

7 Lastverteilung und Remote Function Calls ............... 317

8 SAP GUI und Internetanbindung ............................. 367

9 Sperren ................................................................... 403

10 Optimierung der Java Virtual Machine und von Java-Programmen ............................................. 431

11 Optimierung von SQL-Anweisungen ....................... 485

12 SAP-Pufferung ........................................................ 549

13 Optimierung von Anfragen an SAP NetWeaver Business Warehouse ............................................... 593

14 Optimierung von Suchanfragen mit TREX ................ 651

15 Optimierung von Datenbankanfragen mit SAP HANA ........................................................ 695


Inhalt

7

Inhalt

Vorwort und Danksagung ............................................................. 17Einleitung ..................................................................................... 19

1 Performancemanagement einer SAP-Lösung .......... 33

1.1 Die Architektur von SAP-Lösungen ............................. 341.1.1 SAP-Lösungen und -Komponenten ................ 341.1.2 Client-Server-Architektur ............................... 38

1.2 Das Überwachungs- und Optimierungskonzept für eine SAP-Lösung ................................................... 471.2.1 Anforderungen an ein Überwachungs-

und Optimierungskonzept .............................. 471.2.2 Service Level Management ............................. 511.2.3 Das Konzept für eine kontinuierliche

Performanceoptimierung ................................ 581.2.4 Werkzeuge und Methoden für das

Überwachungs- und Optimierungskonzept ..... 651.2.5 SAP Solution Manager ................................... 67

1.3 Zusammenfassung ...................................................... 72

2 Analyse von Hardware, Datenbank und ABAP-Applikationsserver ......................................... 75

2.1 Begriffsklärungen ........................................................ 762.2 Hardwareanalyse ........................................................ 77

2.2.1 Analyse eines Hardwareengpasses(CPU und Hauptspeicher) ............................... 79

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

2.2.3 Weitere Analysen auf Betriebssystemebene .... 872.3 Datenbankanalyse ...................................................... 89

2.3.1 Der Performancemonitor im DBA-Cockpit ...... 902.3.2 Analyse der Datenbankpuffer ......................... 922.3.3 Identifizierung teurer SQL-Anweisungen ........ 962.3.4 Identifizierung von

Schreib-/Lese-(I/O-)Problemen ...................... 1032.3.5 Weitere Analysen auf Datenbankebene .......... 105

2.4 Analyse der SAP-Speicherkonfiguration ...................... 1142.4.1 Analyse der SAP-Puffer .................................. 115


Inhalt

8

2.4.2 Analyse des SAP Extended Memorys, des SAP Heap Memorys und des SAP Roll Memorys ......................................... 117

2.4.3 Anzeige des allokierten Speichers .................. 1192.4.4 Weitere Monitore zur detaillierten Analyse ... 121

2.5 Analyse der SAP-Workprozesse .................................. 1232.5.1 Felder der Workprozess-Übersicht ................. 1242.5.2 Analyse der Workprozesse ............................. 1272.5.3 Globale Workprozess-Übersicht ..................... 1302.5.4 Überwachung der Dispatcher-Queue ............. 132

2.6 Analyse des Internet Communication Managers (ICM) ......................................................... 134

2.7 Kontinuierliche Überwachung mit dem CCMS ............ 1352.7.1 Mit dem Überwachungsmonitor arbeiten ...... 1372.7.2 Monitoring-Baum einrichten ......................... 1412.7.3 Automatische Alert-Benachrichtigung

einrichten ...................................................... 1442.7.4 Grafische Benutzeroberfläche im

SAP Solution Manager ................................... 1452.8 Zusammenfassung ...................................................... 146

3 Workload-Analyse .................................................... 149

3.1 Grundlagen der Workload-Analyse und der Laufzeitanalyse ........................................................... 150

3.2 Der Workload-Monitor .............................................. 1533.2.1 Mit dem Workload-Monitor arbeiten ............ 1533.2.2 Technische Einstellungen zum

Workload-Monitor ........................................ 1563.3 Workload-Analyse ..................................................... 157

3.3.1 Ablauf eines Transaktionsschrittes ................. 1573.3.2 Weitere Zeitkomponenten ............................ 1603.3.3 Interpretation der Antwortzeiten ................... 1613.3.4 Aktivität, Durchsatz und Last ......................... 163

3.4 Workload-Analyse durchführen .................................. 1653.4.1 Allgemeines Performanceproblem

analysieren .................................................... 1653.4.2 Spezielles Performanceproblem analysieren ... 173

3.5 End-to-End-Workload-Analyse .................................. 1763.5.1 Grundlagen der End-to-End-Workload-

Analyse ......................................................... 1773.5.2 Der zentrale Workload-Monitor .................... 178


Inhalt

9

3.5.3 Mit dem zentralen Workload-Monitor arbeiten ......................................................... 179

3.5.4 Der End-to-End-Workload-Monitor im SAP Solution Manager ............................... 183


4 Identifizierung von Performanceproblemen in ABAP-Programmen .................................................. 189

4.1 Einzelsatzstatistik ........................................................ 1894.2 Performance-Trace ...................................................... 194

4.2.1 Performance-Trace erstellen ........................... 1954.2.2 SQL-Trace auswerten ..................................... 1964.2.3 Weitere Funktionen im SQL-Trace ................. 2024.2.4 Puffer-Trace auswerten .................................. 2044.2.5 RFC-Trace auswerten ..................................... 2054.2.6 HTTP-Trace auswerten ................................... 2064.2.7 Enqueue-Trace auswerten .............................. 207

4.3 Performanceanalyse mit dem ABAP-Trace (Laufzeitanalyse) ......................................................... 2084.3.1 ABAP-Trace erstellen ..................................... 2094.3.2 ABAP-Trace auswerten ................................... 2114.3.3 Varianten verwenden ..................................... 2134.3.4 Ausblick: Einzeltransaktionsanalyse ................ 2154.3.5 Mit der Einzeltransaktionsanalyse arbeiten ..... 217

4.4 Analyse des Speicherverbrauchs mit dem ABAP Debugger und im Memory Inspector .......................... 218

4.5 Code Inspector ........................................................... 2254.6 Zentrale Einzelsatzstatistik .......................................... 2264.7 End-to-End-Laufzeitanalyse im

SAP Solution Manager ................................................ 2294.7.1 Laufzeitanalyse einschalten ............................ 2294.7.2 End-to-End-Laufzeitanalyse im

SAP Solution Manager anzeigen ..................... 2324.8 Zusammenfassung ...................................................... 234

5 Hardware-Sizing, System- und Lastverteilung ........ 239

5.1 Initiales Hardware-Sizing ............................................ 2415.1.1 Übersicht über das Projekt zum

initialen Sizing ................................................ 2425.1.2 Sizing-Projekt im Detail durchführen .............. 249


Inhalt

10

5.1.3 SAP Standard Application Benchmarks .......... 2535.2 Sizing bei Laststeigerung, Versionswechsel

oder Migration ........................................................... 2585.2.1 Übersicht über ein Sizing-Projekt im Umfeld

einer bereits produktiven Installation ............ 2585.2.2 Sizing im Umfeld produktiver Installationen

im Detail durchführen ................................... 2595.3 Systemlandschaft planen ............................................ 267

5.3.1 Verteilung von SAP-Applikationsinstanzen .... 2685.3.2 Hardwarekonsolidierung ................................ 2695.3.3 System- und Datenbankkonsolidierung .......... 271

5.4 Services des SAP NetWeaver Application Servers ....... 2735.5 Zusammenfassung ...................................................... 278

6 Speicherkonfiguration .............................................. 281

6.1 Grundlagen der Speicherkonfiguration ....................... 2826.1.1 Begriffsklärungen ........................................... 2826.1.2 SAP Role Memory, SAP Extended Memory,

SAP Heap Memory ........................................ 2846.1.3 SAP Extended Global Memory und

SAP Paging Memory ...................................... 2916.2 Besonderheiten der Betriebssysteme .......................... 293

6.2.1 Zero Administration Memory Management für Microsoft Windows .................................. 293

6.2.2 Memory Management für Linux .................... 2956.2.3 Memory Management für IBM i .................... 295

6.3 Speicherbereiche konfigurieren und überwachen ....... 2966.3.1 Auslagerungsspeicher überwachen ................ 2996.3.2 SAP-Speicherbereiche konfigurieren und

überwachen .................................................. 3016.3.3 Hilfe zur Fehlerbehebung .............................. 305


7 Lastverteilung und Remote Function Calls .............. 317

7.1 Lastverteilung innerhalb der ABAP-Instanzen ............. 3187.1.1 Message-, Enqueue- und ATP-Service

verteilen ........................................................ 3207.1.2 Dialog-, Hintergrund- und Spool-

Workprozesse verteilen ................................. 320


Inhalt

11

7.1.3 Benutzer und Workprozesse auf CPU-Ressourcen verteilen .............................. 321

7.1.4 Dynamische Benutzerverteilung: Anmeldegruppen konfigurieren ...................... 324

7.1.5 Ressourcen pro Benutzer beschränken ........... 3287.1.6 Betriebsarten ................................................. 3297.1.7 Dynamische Workprozesse konfigurieren ....... 3297.1.8 Verbuchung ................................................... 330

7.2 Remote Function Calls (RFC) ....................................... 3387.2.1 Grundlagen und Begriffe ................................ 3387.2.2 Ablauf eines RFCs .......................................... 3417.2.3 RFC-Verbindungen konfigurieren

und testen ..................................................... 3447.2.4 Eingehende und ausgehende Last

überwachen ................................................... 3487.2.5 Parallelisierung von Prozessen mit

asynchronen RFCs konfigurieren ..................... 3547.2.6 Datenübertragung mit transaktionalen

RFCs überwachen ........................................... 3557.2.7 Hintergrund-RFCs .......................................... 357

7.3 Neues Lastverteilungskonzept ..................................... 3577.4 SAP Virtual Machine Container ................................... 3607.5 Zusammenfassung ...................................................... 362

8 SAP GUI und Internetanbindung ............................. 367

8.1 SAP GUI ..................................................................... 3688.1.1 Interaktionsmodell und Performance-

messung ......................................................... 3688.1.2 Performance der GUI-Kommunikation

analysieren und optimieren ............................ 3718.2 SAP-Webanwendungen .............................................. 377

8.2.1 Einsatz von Web UI und SAP GUI planen ....... 3788.2.2 HTTP-Trace im Internet Communication

Manager ........................................................ 3808.3 Analysen auf dem Präsentationsserver ........................ 381

8.3.1 Präsentationsserver-Trace für Webanwendung ............................................. 383

8.3.2 Performancewerkzeuge des Betriebssystems ... 3868.3.3 Webanwendungen kontinuierlich

überwachen ................................................... 387


Inhalt

12

8.4 Business Server Pages (BSP), Web Dynpro ABAP und integrierter ITS .................................................... 3888.4.1 Grundlagen von Business Server Pages

und Web Dynpro ABAP ................................. 3888.4.2 Grundlagen des integrierten ITS .................... 3928.4.3 Grundlagen von ABAP-Webservices .............. 3948.4.4 Performanceanalyse von ABAP-

Webservices, BSPs, Web-Dynpro-ABAP- und ITS-Anwendungen durchführen .............. 394

8.4.5 Aufrufe von Webservices überwachen ........... 3978.5 Zusammenfassung ...................................................... 398

9 Sperren ..................................................................... 403

9.1 Sperrkonzepte von Datenbanksystem und SAP-System ............................................................... 4049.1.1 Datenbanksperren ......................................... 4049.1.2 SAP-Enqueues ............................................... 405

9.2 Überwachung von Sperren ......................................... 4079.2.1 Datenbanksperren ......................................... 4089.2.2 SAP-Enqueues ............................................... 412

9.3 Nummernkreispufferung ............................................ 4149.3.1 Grundlagen ................................................... 4149.3.2 Nummernkreispufferung einschalten ............. 4199.3.3 Nummernkreispufferung überwachen ............ 420

9.4 Sperren mit Menge und ATP-Server ........................... 4219.4.1 Grundlagen ................................................... 4229.4.2 ATP-Server konfigurieren ............................... 4249.4.3 ATP-Server überwachen ................................ 426


10 Optimierung der Java Virtual Machine und von Java-Programmen .............................................. 431

10.1 Garbage Collection .................................................... 43310.1.1 Aufbau des Java Heaps .................................. 43310.1.2 Garbage-Collection-Algorithmen ................... 43510.1.3 Auswahl des Kollektors ................................. 43610.1.4 Parametrisierung des Java Heaps und

der Garbage Collection .................................. 43810.1.5 Protokollierung von Garbage Collections ....... 439

10.2 Just-in-Time-Compiler ............................................... 440


Inhalt

13

10.3 SAP Management Console .......................................... 44110.4 SAP Java Virtual Machine Profiler ............................... 444

10.4.1 Architektur ..................................................... 44410.4.2 Verbindungsaufbau ........................................ 44510.4.3 Allocation Analysis ......................................... 44810.4.4 Performance Hotspot Analysis ........................ 45510.4.5 Method Parameter Analysis ........................... 45910.4.6 Synchronization Analysis ................................ 46110.4.7 File- und Network-I/O-Analysis ...................... 46410.4.8 Garbage Collection Analysis ........................... 46610.4.9 Klassenstatistik und Heap Dump .................... 469

10.5 Memory Analyzer ....................................................... 47110.5.1 HPROF-Dateien erstellen ............................... 47210.5.2 Analyse des Java Heaps mit dem

Memory Analyzer ........................................... 47210.6 Lokale Datenbankmonitore und SQL-Trace im

SAP NetWeaver AS Java ............................................. 47510.7 Java-Workload- und Laufzeitanalyse mit

CA Wily Introscope ..................................................... 47810.7.1 Funktionsweise von Introscope ...................... 47810.7.2 Mit dem WebView und der Workstation

von Introscope arbeiten ................................. 47910.7.3 Introscope Trace ............................................ 481


11 Optimierung von SQL-Anweisungen ....................... 485

11.1 Teure SQL-Anweisungen identifizieren und analysieren ................................................................. 48711.1.1 Identifizierung und Voranalyse ....................... 48711.1.2 Detaillierte Analyse ........................................ 490

11.2 SQL-Anweisungen durch Sekundärindizes optimieren .................................................................. 49411.2.1 Ein wenig Theorie .......................................... 49411.2.2 Indizes und Tabellenstatistiken

administrieren ................................................ 50411.2.3 Regeln zum Anlegen oder Ändern

von Sekundärindizes ...................................... 51111.3 SQL-Anweisungen im ABAP-Programm optimieren .... 521

11.3.1 Regeln für die performante SQL-Programmierung ............................................ 521


Inhalt

14

11.3.2 Beispiel für die Optimierung eines ABAP-Programms .......................................... 527

11.3.3 Vorbelegung von Feldern in Report-transaktionen ................................................ 537

11.4 Teure SQL-Anweisungen durch falsche Puffereinstellungen und Administrationswerkzeuge .... 542


12 SAP-Pufferung .......................................................... 549

12.1 Grundlagen der Tabellenpufferung ............................. 55112.1.1 Pufferungsarten ............................................. 55112.1.2 Pufferzugriffe ................................................. 55412.1.3 Puffersynchronisation .................................... 55612.1.4 Pufferung einschalten .................................... 55912.1.5 Welche Tabellen sollen gepuffert werden? .... 561

12.2 Tabellenpufferung auf dem ABAP-Server überwachen ............................................................... 56412.2.1 Tabellenzugriffsstatistik ................................. 56512.2.2 Analyse der gepufferten Tabellen ................... 56812.2.3 Analyse der bisher nicht gepufferten

Tabellen ........................................................ 57412.2.4 Detaillierte Tabellenanalyse ........................... 57612.2.5 Monitor zur Puffersynchronisation

(DDLOG-Einträge) ......................................... 57912.2.6 SQL-Statistik und SQL-Trace .......................... 579

12.3 Objektorientierte Anwendungspuffer überwachen ..... 58012.4 Tabellenpufferung auf dem SAP NetWeaver

AS Java überwachen .................................................. 58612.5 Zusammenfassung ...................................................... 589

13 Optimierung von Anfragen an SAP NetWeaver Business Warehouse ................................................ 593

13.1 Grundlagen des SAP NetWeaver Business Warehouse ................................................................ 59413.1.1 Übersicht über die wichtigsten Begriffe

in SAP NetWeaver BW .................................. 59513.1.2 InfoCube und erweitertes Star-Schema .......... 599


Inhalt

15

13.1.3 Möglichkeiten der Performance-optimierung im Überblick .............................. 608

13.1.4 BW-Administrationswerkzeuge im Überblick ....................................................... 611

13.2 Analyse teurer BW-Anfragen ....................................... 61313.3 Technische Optimierungsoptionen im Detail ............... 619

13.3.1 Indizierung administrieren .............................. 62113.3.2 Einstellungen zur Datenselektion ................... 62813.3.3 Komprimieren der Faktentabelle .................... 62913.3.4 OLAP-Cache überwachen ............................... 63013.3.5 Vorberechnung von Reports ........................... 63513.3.6 Aggregate ...................................................... 637


14 Optimierung von Suchanfragen mit TREX ............... 651

14.1 Grundlagen und Architektur des TREX unter Performancegesichtspunkten ...................................... 65214.1.1 TREX-Einsatzszenarien und Suchfunktionen ... 65314.1.2 Architektur des TREX ..................................... 65714.1.3 Besonderheiten des SAP NetWeaver BW

Accelerators ................................................... 66114.1.4 TREX-Administrationswerkzeuge

im Überblick .................................................. 66314.2 Performanceanalyse auf dem TREX durchführen ......... 665

14.2.1 Auslastung der TREX-Server überwachen ....... 66514.2.2 Python-Trace erstellen und auswerten ............ 67114.2.3 Performance-Trace erstellen und auswerten ... 672

14.3 Technische Optimierungsoptionen im Detail ............... 67314.3.1 Indizes teilen ................................................. 67414.3.2 TREX reorganisieren ....................................... 67514.3.3 Deltaindizes einsetzen .................................... 67614.3.4 Master- und Slave-Index-Server verwenden ... 67814.3.5 Queue-Server konfigurieren ........................... 68214.3.6 RFC-Verbindungen vom ABAP-System

zum TREX erhöhen ......................................... 68714.4 InfoCubes im BWA indizieren ..................................... 68714.5 Zusammenfassung ...................................................... 693


Inhalt

16

15 Optimierung von Datenbankanfragen mit SAP HANA .......................................................... 695

15.1 SAP HANA-Einsatzszenarien ...................................... 69715.2 Grundlagen der Hauptspeicherdaten in

SAP HANA und TREX ................................................. 70115.2.1 Spaltenorientierte Datenspeicherung ............. 70315.2.2 Datenkomprimierung .................................... 70515.2.3 Datenhaltung im Hauptspeicher .................... 70915.2.4 Partitionierung und Parallelisierung ............... 71215.2.5 Indizierung .................................................... 71315.2.6 Datenmodellierung aus Performancesicht ...... 716

15.3 SAP HANA-Architekturüberblick und Sizing ............... 71915.3.1 SAP HANA-Architekturüberblick ................... 71915.3.2 Sizing ............................................................ 72215.3.3 HANA-Administrationswerkzeuge

im Überblick .................................................. 72515.4 Technische Optimierungsoptionen im Detail .............. 728

15.4.1 Hauptspeicheranalyse .................................... 72815.4.2 Identifizierung und Analyse teurer

SQL-Anweisungen ......................................... 73615.4.3 Indizes anlegen (invertierter Index,

konkatenierter Index) .................................... 74515.4.4 Deltaindizes administrieren ........................... 74915.4.5 Lastverteilung, Parallelisierung und

Partitionierung .............................................. 75315.4.6 Optimierung von InfoCubes und

DataStore-Objekten für SAP HANA ............... 75615.5 Zusammenfassung ...................................................... 760

Anhang ........................................................................... 765

A Datenbankmonitore ............................................................. 767B Wichtige Transaktionscodes ................................................. 819C Fragen und Antworten ......................................................... 823D Glossar ................................................................................. 829E Informationsquellen ............................................................. 843F Der Autor ............................................................................. 858

Index .......................................................................................... 859


19

Einleitung

PerformanceWarum ist die Performance Ihrer betriebswirtschaftlichen IT-Anwen-dung wichtig? Nur bei guten Antwortzeiten können Benutzer moti-viert und effizient mit der Anwendung arbeiten. Ein langsames Sys-tem führt zu Ausfallzeiten und Frustration. Eskaliert die Situation,wird im schlimmsten Fall der zur Bewältigung der Geschäftsprozesseerforderliche Durchsatz nicht mehr erreicht. Mehrarbeit, Produk-tionsverzögerungen und finanzielle Verluste sind die Folge. Umge-kehrt steigert eine systematische, proaktive Performanceoptimierungmaßgeblich den Nutzen Ihrer betriebswirtschaftlichen Anwendung.

Die Performance eines Datenverarbeitungssystems ist als die Fähig-keit definiert, gegebene Anforderungen an Antwortzeiten und Daten-durchsatz zu erfüllen. Solche Anforderungen können z. B. sein, dassinnerhalb einer Stunde ein Durchsatz von 10.000 gedruckten Rech-nungen erreicht werden muss oder dass die Antwortzeit für das Erfas-sen eines Kundenauftrags unter einer Sekunde liegen soll. Eine gutePerformance ist keine absolute Eigenschaft einer betriebswirtschaft-lichen Anwendung, sondern immer relativ zu den Anforderungen andiese zu sehen.

Proaktives Performancemanagement

Performance-optimierung

Unter Performanceoptimierung verstehen wir in diesem Buch einenProzess, der immer fünf Phasen umfasst: Die ersten beiden Phasensind, zu einem Verständnis der Geschäftsprozesse zu kommen sowiePerformanceziele festzulegen und zu quantifizieren. Diese Schrittebeziehen alle Beteiligten mit ein, d. h. Techniker und Anwendungs-fachleute. Nur auf der Basis dieser Voraussetzungen kann eine Opti-mierung erfolgreich sein. Die Phasen drei bis fünf umfassen dann diesystematische Überwachung, Identifizierung und Analyse von Proble-men, die Umsetzung von Optimierungsmaßnahmen und die erneuteAnalyse zur Verifizierung des Erfolgs der eingeleiteten Maßnahmen(siehe Abbildung 1). Vor unreflektiertem »Herumschrauben« an Kon-figurationsparametern und vergleichbaren »Tuningschnellschüssen«


20

Einleitung

müssen wir warnen! Ziel dieses Buches ist es vielmehr, Ihnen dieMöglichkeiten zu eröffnen, Performanceprobleme zu identifizierenund zu analysieren, um diese dann gezielt beheben zu können.

TechnischeOptimierung

Eine betriebswirtschaftliche IT-Anwendung besteht, technisch gese-hen, aus zahlreichen Komponenten: aus logischen Komponenten,Prozessen wie Services, Threads oder Workprozessen und Speicher-bereichen wie Puffern und Benutzerkontexten sowie physischenKomponenten wie Prozessoren (CPU), Hauptspeicher (RAM), Fest-platten und Netzwerksegmenten. Diese Komponenten erlaubenjeweils einen maximalen Durchsatz und eine optimale Antwortzeit.Ist das Zusammenspiel der Komponenten nicht ideal abgestimmtoder wird die Leistungsgrenze einzelner Komponenten erreicht, ent-stehen Wartesituationen, die sich negativ auf Durchsatz und Ant-wortzeit auswirken. Die Identifizierung, Analyse und Lösung solcherProbleme durch das Abstimmen der Komponenten aufeinander unddie Verteilung der im System anfallenden Last sind die Aufgaben, diewir in diesem Buch als technische Optimierung bezeichnen.

Optimierung vonApplikationen

Der zweite wichtige Bereich der Performanceoptimierung ist die Ver-meidung unnötiger Last. Die Performance kann ebenso von ineffizi-enten Programmen oder dem ineffizienten Einsatz von Programmennegativ beeinflusst werden. Die Optimierung einzelner Programmebezeichnen wir als Applikationsoptimierung.

Ziel der Optimierung ist, zunächst die Systemeinstellung und dieApplikationen derart zu verbessern, dass auf der Basis der bereits vor-handenen Hardwareressourcen die gewünschte Performance erreicht

Abbildung 1 Performanceoptimierung in fünf Phasen

Verständnis der Geschäftsprozesse

Definition der Performanceziele

Überwachung und Analyse

Optimierung

Verifikation und Reporting der Ergebnisse


21

Proaktives Performancemanagement

wird. Genügt dies nicht, müssen die Ressourcen entsprechend dengewonnenen Erkenntnissen erweitert werden.

Wie viel Tuningist nötig?

Wie viel Aufwand ist für Performanceanalyse und Tuning einer SAP-Lösung nötig? Die Antwort auf diese Frage hängt stark von der Sys-temgröße ab. Für eine kleine oder mittelgroße Installation ohne Modi-fikationen am SAP-Standard und ohne Eigenentwicklungen genügtin der Regel eine Performanceoptimierung kurz vor und kurz nachdem Produktivstart sowie nach größeren Veränderungen, z. B. durchUpgrades, Produktionsstarts neuer SAP-Lösungen, die Erhöhung derBenutzerzahl, größere Datenübernahmen oder Mandantentransporte.Darüber hinaus muss man natürlich nach Bedarf eingreifen, wennakute Performanceprobleme vorliegen. Das Tuningpotenzial unddamit auch der notwendige Analyse- und Optimierungsaufwandwachsen mit der Systemgröße an. Die Praxis zeigt, dass insbesonderekundeneigene Entwicklungen und Modifikationen am SAP-Standardzu Performanceengpässen führen. Ursache dafür sind meist unge-nügende Tests, aber auch Zeitdruck und mangelnde Erfahrung derEntwickler. Den Extremfall bildet eine ständig weiterentwickelteGroßinstallation mit vielen hundert Benutzern, komplizierten Pro-zessketten, einem Dutzend oder mehr Entwicklern (die oft verschie-denen Beratungsfirmen angehören und zu unterschiedlichen Zeitenund an unterschiedlichen Orten am System arbeiten) und einem aus-gelagerten Systemmanagement. In einer solchen Systemumgebung istes unumgänglich, dass eine kleine Gruppe von Administratoren undEntwicklern die Übersicht über das Gesamtsystem behält und die Per-formance nicht aus den Augen lässt.

Hilfe bei Performanceanalyse und Tuning bieten die Remote-Servicesder SAP. Namentlich sind dies der GoingLive Check, der Ihnen denProduktivstart Ihres Systems erleichtert, und der EarlyWatch Service,der Ihr produktives System überwacht und Ihnen weitere Optimie-rungen vorschlägt.

Proaktives Performance-management

Wie trägt ein proaktives Performancemanagement dazu bei, Ihr Ziel zuerreichen, eine betriebswirtschaftliche Anwendung erfolgreich zubetreiben? Wenn Sie dieses Ziel erreichen wollen, müssen Sie zweiEinflussfaktoren im Blick halten: die Zufriedenheit der Benutzer unddie Kosten für den Betrieb der betriebswirtschaftlichen Anwendung.Die Kosten für den Betrieb ergeben sich zum einen aus den Kostenfür Hardware (Infrastruktur, CPU, Hauptspeicher, Festplatten und


22

Einleitung

Netzwerke) und Betriebspersonal (Administration, Wartung, Fehler-analyse). Nicht vernachlässigen dürfen Sie aber die Kosten, die entste-hen, wenn eine Anwendung nicht zur Verfügung steht oder nicht diegeforderte Performance erreicht – der Schaden übersteigt in diesemFall innerhalb weniger Stunden oder Tage den Betrag, der im Mittelin einem Jahr für die proaktive Performanceoptimierung investiertwird. Diese Risikokosten müssen ebenfalls den Kosten für ein proak-tives Performancemanagement gegenübergestellt werden. Tabelle 1führt Ihnen anhand zweier konkreter Beispiele den Nutzen des pro-aktiven Performancemanagements vor Augen.

Aktuelle Entwicklungen

Herausfor-derungen durch

das Internet undmobile Geräte

Mit dem Aufstieg des Internets, der Smartphones und Tablet-Compu-ter vollzieht sich ein Paradigmenwechsel in der Welt der betriebs-wirtschaftlichen Software: Nicht mehr auf den hoch spezialisiertenAngestellten an seinem PC zielt die Software ab, sondern auf Benut-zer des Internets (extern oder firmenintern als Intranet) oder den

Proaktive Maßnahme

Effekt im System

Sofortiger Nut-zen durch höhere Benutzerzufrie-denheit

Sofortiger Nut-zen durch gerin-gere Betriebs-kosten

Verminder-tes Eskala-tionsrisiko

Optimierung von SQL-Anweisungen

Reduktion der Datenbanklast

schnellere Ant-wortzeiten bei bestimmten Transaktionen

Hardwareinves-titionen (Daten-bankserver, Speichersystem) können gestreckt werden.

Überlastung des Daten-banksystems wird vermie-den.

proaktives Datenmanage-ment (Daten-vermeidung, Archivierung, Reorganisa-tion)

� Reduktion des Datenbank-wachstums

� kürzere Zeiten für Wartungs-arbeiten an der Datenbank (Backup/Reco-very, Upgrade, Migration, Sys-temkopie)

� schnellere Ant-wortzeiten bei bestimmten Transaktionen

� kürzere Down-time bei Wartungs-arbeiten

� Hardwareinves-titionen können gestreckt wer-den.

� geringerer Per-sonalbedarf bei Wartungsarbei-ten

Datenbank-größe bleibt »beherrsch-bar«.

Tabelle 1 Beispiele für den Nutzen eines proaktiven Performancemanagements


23

Aktuelle Entwicklungen

Benutzer eines mobilen Gerätes. Der klassische Ansatz einer Prozess-automatisierung mit SAP R/3 basiert auf hoch spezialisierten Anwen-dern, die von festen Arbeitsplätzen über installierte SAP GUIs auf ihrERP-System (Enterprise Resource Planning) zugreifen. Die Rolle die-ses spezialisierten Vermittlers, der ausgebildet sein muss, um Soft-ware zu bedienen, wird allerdings an vielen Stellen zunehmend über-flüssig. Stattdessen erhält der Endbenutzer durch Internet undMobilgerät direkten Zugriff auf die ERP-Systeme der Unternehmen.Heute können z. B. in vielen Unternehmen die Mitarbeiter über dasIntranet ihre Arbeits- und Fehlzeiten, Reisekostenabrechnungen etc.selbst in das System eingeben, wo dies früher über zentrale Benutzergeschah. Kunden bestellen heute vermehrt ihre Produkte direkt überdas Internet und nicht mehr über den Umweg eines Briefes, Faxesoder Telefonanrufs bei einem Vertriebscenter.

Die Erwartungen, die der Anwender einer Internet- oder mobilenAnwendung an die Bedienbarkeit und Performance hat, sind un-gleich höher als die des klassischen Angestellten an sein ERP-System.Der Angestellte ist auf »sein« ERP-System angewiesen, und wenn esihm normalerweise dabei hilft, seine tägliche Arbeit zu vereinfachen,wird er es akzeptieren und auch kleinere Fehler oder Performance-schwächen in Kauf nehmen. Ganz anders der Internetbenutzer: Funk-tionieren die Anwendungen, die ihm im Internet angeboten werden,nicht einfach und performant, kann er sofort zur Konkurrenzfirmawechseln und dort z. B. seine Einkäufe tätigen (»Die Konkurrenz istnur einen Mausklick entfernt.«). Hinzu kommt: Das Internet machtnicht um 17 Uhr Feierabend – von einer E-Business-Lösung im Inter-net werden Verfügbarkeit und Performance an 365 Tagen 24 Stundenlang gefordert. Nutzer von mobilen Anwendungen legen die Maß-stäbe in Bezug auf Bedienbarkeit und Performance an eine SAP-An-wendung an, die sie auch von anderen Mobile Apps gewohnt sind.

SAP HANAMit SAP HANA ist es SAP gelungen, ein Produkt auf den Markt zubringen, das Analysten bereits heute als die wichtigste Innovationseit Jahren im Bereich von Business Software bezeichnen. Kern derInnovation ist eine Hauptspeicherdatenbank, um die sich weitere Ser-vices, z. B. ein als XS-Engine bezeichneter Applikationsserver, grup-pieren. In diesem Buch gehen wir ausschließlich auf die HANA-Datenbankplattform ein, da zu den weiteren Services die Felderfah-rungen noch fehlen.


24

Einleitung

Das wichtigste Argument für die Einführung von SAP HANA ist Per-formance! SAP HANA macht sich die Verfügbarkeit von riesigenHauptspeichern und massiv parallelen Prozessorarchitekturen zuNutze und setzt diese konsequent durch modernste Softwarearchitek-tur in Performance um. Vielleicht werden Sie sich fragen: Brauche ichüberhaupt noch ein Buch über Performance, wenn ich HANA habe?Oder löst HANA alle Performanceprobleme? Die Antwort auf diezweite Frage ist – nach der festen Überzeugung des Autors – ein dop-peltes Nein: Zum einen kann auch SAP HANA keine Wunder voll-bringen, wenn Ihr Programm ganze Datenbanktabellen in den Appli-kationsserver liest und – schlimmer noch – die Daten weiter zumWebbrowser des Anwenders schickt. Der Löwenanteil der Laufzeitentfällt dann auf den Applikationsserver, das Netzwerk und denBrowser. Die grundlegenden Regeln zur performanten Programmie-rung sind auch bei SAP HANA nicht außer Kraft gesetzt! Ein zweitesNein ergibt sich aus der Tatsache, dass jeder technischen Innovation»Begehrlichkeiten« oder, anders formuliert, Herausforderungen ent-gegenstehen. Eine dieser Herausforderungen heißt Big Data.

Big Data Als Big Data bezeichnet man das Phänomen, dass immer mehr Datenentstehen, die für Unternehmen von Interesse sind, diese Daten aberbisher nicht oder nur unzureichend ausgewertet und nutzbargemacht werden können. Beispiele für solche Daten sind Beiträge insozialen Netzwerken, Protokolle von Webzugriffen, Bewegungsdatenvon Personen (z. B. über Mobilfunkortungen oder Posts mit Lokati-onsdaten in sozialen Netzwerken) und Produkten (die z. B. überRFID-Chips erfasst werden), Daten von Kameras, Mikrofonen undsonstigen Sensoren, Finanztransaktionen und Börsendaten sowieVerbrauchsdaten im Energiesektor. Unternehmen sind interessiertdaran, diese Daten zu erfassen, zu verknüpfen, auszuwerten und soüber ihre Kunden, Märkte und Produkte wertvolle Einsichten zugewinnen. Als Beispiel sei ein Produktionsplaner in der Konsum-güterindustrie genannt. Um vorausschauender planen zu können,werden ihm in Zukunft nicht nur die Produktionszahlen der Vergan-genheit und aktuelle Bestellungen als Grundlage dienen, sondernauch die aktuellen Trends der sozialen Netzwerke.

Kleine »Fehler« –große Wirkung

All diesen Datenquellen ist gemein, dass ihre Menge die traditionel-ler betriebswirtschaftlicher Daten (sogenannte Stamm- und Bewe-gungsdaten) um ein Vielfaches übersteigt. Übertragen auf unsere Per-formancefrage heißt das: Ein nicht performanceoptimiertes System


25

Zu diesem Buch

oder Programm hat einen viel höheren Effekt als in einem »traditio-nellen« SAP Business Suite-System – als Konsequenz folgern wir:Auch in Zukunft wird Performance-Know-how ein wertvolles Gutsein.

IT-ServicesDie Anforderungen an eine offene, flexible Softwarearchitekturerfordern spezialisierte, für sich autark operierende Softwarekompo-nenten, die über Schnittstellen miteinander verknüpft sind. Diesbedeutet, dass ein Geschäftsprozess mehrere Softwarekomponenteninvolviert. Die stetig wachsende Anzahl von Lösungen und Kompo-nenten ist eine Herausforderung für die Administration in denRechenzentren – die Anzahl hat sich von dem »überschaubaren« SAPR/3 (mit SAP-Instanzen, Datenbank, Hardware/Betriebssystem) zueiner ständig wachsenden Technologiepalette entwickelt – Produkteeingeschlossen, die SAP nicht selbst produziert, sondern für die sieals Reseller auftritt.

Konsequenterweise steuern die Betreiber von Geschäftsprozessendiesem Trend entgegen, indem sie immer mehr Servicepartner in denBetrieb des Geschäftsprozesses integrieren. Dabei kann diesesOutsourcing nur die Hardware (Rechnerleistung, Festplattenspeicher,Netzwerkressourcen etc.) oder auch die Applikation selbst (Applica-tion Service Providing, ASP) betreffen; z. B. kann man die Dienstleis-tung eines Internetproduktkatalogs komplett an einen Serviceanbie-ter vergeben, anstatt die Katalogsoftware selbst zu betreiben. Dasbedeutet, dass nicht nur über Hardware- und Softwarekomponenten,sondern sogar über Firmen- und Kompetenzgrenzen hinweg Über-wachung geleistet werden muss.

Insgesamt ergeben sich also völlig neue Anforderungen an die Admi-nistration und Überwachung von SAP-Lösungen, die mit herkömm-lichen Konzepten nicht zu bewältigen sind.

Zu diesem Buch

Grundlagendes Buches

Die in diesem Buch dargestellten Methoden der Performanceanalyseund -optimierung entsprechen den Verfahren, die ursprünglich vonden Experten des EarlyWatch Services und des GoingLive Checks ver-wendet und in den SAP-Basis-Trainings Workload Analysis und Opti-mierung von ABAP-Programmen vermittelt werden. Mit jeder neuenAuflage dieses Buches – mittlerweile der siebten – wird die Chance


26

Einleitung

genutzt, aktuelle Trends der Produktentwicklung bei SAP und – so-weit relevant – Entwicklungen der IT-Welt allgemein adäquat zu be-handeln.

In dieser Auflage sind die Java-Themen praktisch komplett neugeschrieben und in einem Kapitel gebündelt worden. Der wichtigstenNeuerung bei SAP seit vielen Jahren – SAP HANA – ist ein weiteresneues Kapitel gewidmet, das sich zunächst auf die HANA-Datenbank-plattform fokussiert. Weitere HANA-Services werden aufgrund derfehlenden Felderfahrung noch nicht behandelt. Alle weiteren Kapitelsind für diese Auflage überarbeitet und aktualisiert worden, z. B. wirddas neue ABAP-Lastverteilungskonzept (neu zu SAP NetWeaver 7.40)beschrieben, und das Thema Background-RFCs wurde aufgenom-men. In Anhang A, »Datenbankmonitore«, ist ein Abschnitt zurDatenbank Sybase ASE hinzugekommen.

Abbildung 2 Die Kapitel dieses Buches

Verständnis der Geschäftsprozesse

Definition des Service Level Managements

Überwachung und Analyse

Kapitel 2: Systemüberwachung

Detailanalyse und Optimierung

Kapitel 1: Performancemanagement

Kapitel 4: Programmanalyse

AS ABAP DB AS ABAP DB AS ABAP DB

Applikationsserver Datenbank

AS ABAP

AS ABAP

AS Java

Kapitel 12: Pufferung

AS ABAP AS Java DB

Kapitel 13: SAP BW

AS ABAP DB

Kapitel 14: TREX

Kapitel 15: HANA

Kapitel 9: Sperren

AS ABAP DB

AS ABAP AS Java DB

AS ABAP

Kapitel 5: Sizing, Lastverteilung

Kapitel 6: Speicher-konfiguration

Kapitel 7: Lastverteilung,Remote Function Calls

Kapitel 8: SAP GUI undInternetanbindung

Kapitel 10: SAP JVMund Java-Programme

Kapitel 11: SQL-Anweisungen

Kapitel 3: Workload-Analyse


27

Zu diesem Buch

AufbauAbbildung 2 stellt die Kapitel dieses Buches orientiert an den fünfPhasen der Performanceoptimierung im Überblick dar. Kapitel 1,»Performancemanagement einer SAP-Lösung«, wendet sich sowohlan SAP-Administratoren und SAP-Berater als auch an Anwendungs-entwickler und SAP-Projektleiter. Es behandelt auf einem nicht tech-nischen Niveau die folgenden grundlegenden Fragen zur Perfor-manceanalyse:

� Welche Vorkehrungen müssen getroffen werden, um eine opti-male Performance einer SAP-Lösung zu gewährleisten?

� Welche Maßnahmen zum Performancetuning kommen in Betracht?

� Welche Personen sind in den Tuningprozess involviert?

Hinter der dem Benutzer angebotenen Leistung verbirgt sich in derPraxis oft ein Netz von Partnern, die jeweils Teilleistungen erbringen.Viele Teile werden von unterschiedlichen, manchmal externen Servi-ceprovidern erbracht. Um diese Komplexität in den Griff zu bekom-men, führen die meisten Leistungsanbieter und Kunden ein Service Le-vel Management (SLM) ein. Als SLM bezeichnet man eine strukturierteproaktive Methode, die das Ziel hat, den Benutzern einer IT-Anwen-dung ein adäquates Serviceniveau zu garantieren – in Übereinstim-mung mit den betriebswirtschaftlichen Zielen des Auftraggebers undbei optimalen Kosten. Wir zeigen in diesem Buch, mit welchen Werk-zeugen und Methoden Sie ein SLM für eine SAP-Lösung einführen.

In den Kapiteln 2 bis 4 finden Sie die Darstellung der Performance-analyse anhand des SAP NetWeaver Application Servers (AS) ABAP.Nach Lektüre dieser Kapitel sind Sie in der Lage, eine systematischePerformanceanalyse für den AS ABAP inklusive Datenbank undBetriebssystem durchzuführen.

In diesem Buch folgen wir zunächst der Strategie der Bottom-up-Ana-lyse und beginnen in Kapitel 2, »Analyse von Hardware, Datenbankund ABAP-Applikationsserver«, mit den Untersuchungen der Teilsys-teme Betriebssystem, Datenbank, SAP-Speicherkonfiguration undSAP-Workprozesse. Gleichzeitig werden Lösungsvorschläge angebo-ten, die den Administrator oder Berater befähigen sollen, die wich-tigsten Performanceprobleme zu lösen. Für kleine und mittelgroßeInstallationen wird diese Stufe des Tunings in vielen Fällen bereitsausreichen.


28

Einleitung

Anschließend wird in Kapitel 3, »Workload-Analyse«, die komplexereWorkload-Analyse als Top-down-Analyse diskutiert. In Kapitel 4,»Identifizierung von Performanceproblemen in ABAP-Programmen«,finden Sie die Methoden zur Analyse einzelner Programme, u. a. mitden Hilfsmitteln Einzelsatzstatistik, SQL-Trace und ABAP-Laufzeit-analyse.

Die weiteren Kapitel 5 bis 15 vermitteln Wissen, das für eine umfas-sende Performanceanalyse notwendig ist. Sie wenden sich an SAP-Betreuer, die für das performante Funktionieren großer Systeme ver-antwortlich sind und die das Tuningpotenzial ihrer Systeme voll aus-schöpfen wollen und müssen. Kapitel 5 bis 15 sind weitgehend eigen-ständige Einheiten und können mit Kenntnis der ersten vier Kapitelin beliebiger Reihenfolge gelesen werden. Eventuelle Abhängigkei-ten sind am Anfang jedes Kapitels vermerkt.

Behandelt werden in den Kapiteln 5 bis 10 die Themen, die sich aufden Applikationsserver und den Präsentationsserver beziehen:

� Kapitel 5, »Hardware-Sizing, System- und Lastverteilung«: Eine op-timal ausgelegte Hardware ist Voraussetzung dafür, dass auf der ei-nen Seite keine Hardwareengpässe entstehen, dass aber auf der an-deren Seite nicht zu hohe Kosten durch unnötig vorgehalteneHardware anfallen. Serverkonsolidierung – d. h. die Konzentrationaller Services auf wenigen, sehr leistungsfähigen Rechnern – istzweifellos ein wichtiger Trend auf dem IT-Markt der letzten Jahre.Wir stellen dar, was Sie beachten sollten, wenn Sie diese Techno-logien effizient nutzen wollen.

� Kapitel 6, »Speicherkonfiguration« (Memory Management): DieKonfiguration der von der SAP-Komponente allokierten Speicher-bereiche hat wesentlichen Einfluss auf die Performance.

� Kapitel 7, »Lastverteilung und Remote Function Calls«: Eine opti-male Lastverteilung von Webanfragen, Dialog-, Verbuchungs- undHintergrundaufträgen hilft dabei, Hardware optimal zu nutzenund Engpässe aufgrund falscher Konfiguration zu vermeiden. DiePerformance von Schnittstellen zwischen Softwarekomponententrägt ebenfalls maßgeblich zur Performance der gesamten Lösungbei. Bereits in der Vergangenheit waren E-Business-Lösungen, dieaus nur einem monolithischen R/3-System bestanden, eine Selten-


29

Zu diesem Buch

heit – die Regel sind offene, über Schnittstellen verbundene Lösun-gen aus mehreren Komponenten.

� Kapitel 8, »SAP GUI und Internetanbindung«: Analysen und Kon-figurationsvorschläge zeigen das Optimierungspotenzial bei derAnbindung der GUIs (klassisches SAP GUI oder Webbrowser) andie Applikation auf. Im Detail werden hier die Performanceaspektevon SAP GUI Controls, des Internet Transaction Servers (ITS), vonBusiness Server Pages und von Web Dynpro für ABAP behandelt.

� Kapitel 9, »Sperren«: Datenbank- und SAP-Sperren gewährleistendie Datenkonsistenz. Durch eine optimierte Verwaltung von Sper-ren (z. B. durch den ATP-Server oder die Pufferung von Nummern-kreisen) werden Durchsatzengpässe vermieden.

� Kapitel 10, »Optimierung der Java Virtual Machine und von Java-Programmen«: In diesem Kapitel finden Sie die Beschreibung derWerkzeuge, mit denen Sie die Performanceanalyse der Java Vir-tual Machine (SAP JVM) und von Java-Programmen durchführenkönnen.

Kapitel 11 eröffnet die Reihe der Kapitel mit Datenbankthemen undist Voraussetzung für die folgenden Kapitel 12 bis 15:

� Kapitel 11, »Optimierung von SQL-Anweisungen«: IneffektiveSQL-Anweisungen beanspruchen die Datenbank übermäßig undwerden daher zum Problem für die Performance der gesamtenAnwendung. In diesem Kapitel stellen wir die Detailanalyse für»teure« SQL-Anweisungen sowie Optimierungsmöglichkeitendurch Datenbankindizes und durch Programmoptimierung (»fünfgoldene Regeln«) dar.

� Kapitel 12, »SAP-Pufferung«: Die Pufferung von Tabellen auf denApplikationsservern beschleunigt den Zugriff auf oft geleseneDaten und dient der Entlastung der Datenbank.

� Kapitel 13, »Optimierung von Anfragen an SAP NetWeaver Busi-ness Warehouse«: Business-Warehouse-Anfragen sind spezielleSQL-Anweisungen, die in der Regel große Datenmengen bearbei-ten – für diese Art von Anfragen existieren spezielle Optimierungs-möglichkeiten.

� Kapitel 14, »Optimierung von Suchanfragen mit TREX«: TREXwird zur Optimierung von text- und attributbasierten Suchanfra-


30

Einleitung

gen sowie von Business-Warehouse-Anfragen (»BW Accelerator«)genutzt – als Alternative zu herkömmlichen Datenbankindizes undAggregationstabellen.

� Kapitel 15, »Optimierung von Datenbankanfragen mit SAPHANA«: Dem neuen »Wunderkind« von SAP ist ein eigenes Kapitelgewidmet, das in die Grundlagen, Werkzeuge und Methoden zurPerformanceanalyse und -optimierung einführt.

Zielgruppen Kenntnisse in der Performanceoptimierung von SAP-Systemen und-Anwendungen sind für SAP-Administratoren, SAP-Anwendungsbe-treuer, SAP-Entwickler und SAP-Projektleiter von größtem Nutzen –an diese Zielgruppen richtet sich dieses Buch. Jedem Kapitel ist amEnde der Einleitung ein kurzer Abschnitt mit dem Titel »Wann soll-ten Sie dieses Kapitel lesen« vorangestellt. Aus diesem ergibt sich diegenaue Zielgruppe des jeweiligen Kapitels.

Voraussetzungen Dieses Buch setzt an den Stellen, an denen es um die konkrete Umset-zung von Empfehlungen geht, Kenntnisse in der Administration vonSAP-Komponenten in Theorie und Praxis voraus. Insbesondere dieBedienung des Computer Center Management Systems (CCMS) sollteIhnen vertraut sein. Als gute Vorbereitung kann z. B. der Band »SAPNetWeaver Application Server ABAP – Systemadministration« dienen(siehe Anhang E, »Informationsquellen«). Teile dieses Buches, z. B.die Kapitel 4, 9, 11 und 12, setzen außerdem Wissen über die Pro-grammiersprache ABAP und die Funktionsweise von relationalenDatenbanken und SQL voraus.

Grenzendes Buches

In den folgenden Bereichen stößt das Buch an seine Grenzen:

� Hardware- und NetzwerktuningEin Engpass bei CPU, Hauptspeicher, I/O oder Netzwerk lässt sichzwar aus dem SAP-System heraus mit großer Wahrscheinlichkeitidentifizieren, für eine detaillierte Analyse werden jedoch dieWerkzeuge der Hardware- bzw. Netzwerkanbieter benötigt. Ange-sichts der unübersehbaren Anzahl der angebotenen Produkte mussdieser Bereich (insbesondere das Tuning der Festplatten) ausge-klammert bleiben.

� DatenbankenSAP bietet im Computer Center Management System (CCMS)Werkzeuge an, die die Administration und Analyse der verschiede-


31

Zu diesem Buch

nen Datenbankensysteme so weit wie möglich vereinheitlichen.Wer jedoch tiefer in das Datenbanktuning einsteigt, kommt nichtdaran vorbei, sich mit den unterschiedlichen Architekturen derDatenbanksysteme zu beschäftigen. Dabei ist es unmöglich, dieFeinheiten aller mit SAP-Lösungen eingesetzten Datenbanksys-teme in diesem Buch in der gebührenden Tiefe zu behandeln.Allerdings ist dies auch nicht notwendig, da zu allen Datenbank-systemen Literatur zum Tuning vorhanden ist. Dieses Buch kannund will diese Literatur nicht ersetzen. Sein Schwerpunkt liegt viel-mehr im SAP-spezifischen Kontext des Datenbanktunings und inder Vermittlung datenbanksystemübergreifender Konzepte. Diekonkreten Beispiele betreffen immer einzelne Datenbanksysteme.Im Anhang finden Sie eine Übersicht über die wichtigsten Moni-tore zur Datenbankanalyse für alle Datenbanksysteme.

� ApplikationstuningViele Performanceprobleme lassen sich nur mit detailliertemAnwendungswissen und Kenntnis der einzelnen SAP-Lösungenlösen. Oft ist es eine Änderung im Customizing, die die Lösung desProblems bringt. Know-how zum Tuning einzelner SAP-Lösungenist nicht Teil dieses Buches. Allerdings vermittelt es Ihnen Analy-sestrategien, sodass Sie Performanceprobleme auf bestimmteApplikationen eingrenzen und somit an den richtigen Entwickleroder Berater adressieren können.

Release-abhängigkeit

Eine Frage, die bereits vor Erscheinen des Buches heftig diskutiertwurde, ist, inwieweit release- und zeitabhängige InformationenInhalt des Buches sein können; dies betrifft z. B. Menüpfade, Empfeh-lungen für Konfigurationsparameter und Richtwerte für Perfor-mancekennzahlen. Eine neue Version, ein Patch (der SAP-Kom-ponente, der Datenbank oder des Betriebssystems), eine neueRechnergeneration – diese und andere Faktoren können mit einemSchlag alte Informationen wertlos machen; im schlimmsten Fall kön-nen sich veraltete Empfehlungen sogar kontraproduktiv auf die Per-formance auswirken. Dieses Risiko ist uns bewusst. Dennoch habenwir uns dafür entschieden, zeitabhängige Informationen und Regelnin das Buch aufzunehmen. Nur so kann Ihnen dieses Buch als Nach-schlagwerk für die tägliche Arbeit in der SAP-Administration dienen.Auf der anderen Seite ist klar: Dieses Buch ist kein Gesetzbuch, undwer Performanceoptimierung nur als stures Befolgen von Regeln


32

Einleitung

betreibt, handelt fahrlässig. Die direkte Auseinandersetzung mit derLösung, der SAP-Onlinehilfe und aktuellen SAP-Hinweisen im SAPService Marketplace kann dieses Buch nicht ersetzen, sondern nurfördern.

SAP NetWeaver7.30

Alle Angaben zu Menüpfaden, Bezeichnungen in den Bildschirmender Performancemonitore und Richtwerten für Performancekenn-zahlen beziehen sich – sofern nicht anders vermerkt – auf SAP Net-Weaver 7.30. An einigen Stellen geben wir bereits einen Ausblick aufSAP NetWeaver 7.40.

Hinweise zurLektüre

In diesem Buch finden Sie mehrere Orientierungshilfen, die Ihnendie Arbeit mit dem Buch erleichtern sollen.

In hervorgehobenen Informationskästen sind Inhalte zu finden, diewissenswert und hilfreich sind, aber etwas außerhalb der eigentli-chen Erläuterung stehen. Damit Sie die Informationen in den Kästensofort einordnen können, haben wir die Kästen mit Symbolengekennzeichnet:

Die mit diesem Symbol gekennzeichneten Tipps geben Ihnen spezi-elle Empfehlungen, die Ihnen die Arbeit erleichtern können.

In Kästen, die mit diesem Symbol gekennzeichnet sind, finden SieInformationen zu weiterführenden Themen oder wichtigen Inhalten,die Sie sich merken sollten.

Dieses Symbol weist Sie auf Besonderheiten hin, die Sie beachten soll-ten. Es warnt Sie außerdem vor häufig gemachten Fehlern oder Pro-blemen, die auftreten können.

Beispiele, durch dieses Symbol kenntlich gemacht, weisen auf Szena-rien aus der Praxis hin und veranschaulichen die dargestellten Funk-tionen.

www.sap-press.de Wie schon für die früheren Auflagen werden wir Aktualisierungenund ggf. Korrekturen zum Buch auf der Verlagswebsite (www.sap-press.de) bereitstellen.


75

Mit der Analyse der Hardwareressourcen, der Datenbank sowie der Workprozesse und Speicherbereiche des SAP NetWea-ver AS ABAP steigen wir – bottom-up – in die Performance-analyse 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 Performanceanalysender Hardware, der Datenbank, der SAP-Speicherkonfiguration undder SAP-Workprozesse des SAP NetWeaver Application ServersABAP. Am Ende eines jeden Abschnitts finden Sie Flussdiagramme,die die wichtigsten Analysepfade zusammenfassen und die Abhängig-keiten zwischen den Analysen verdeutlichen. Im letzten Abschnittgehen wir auf den zentralen Überwachungsmonitor ein, der Perfor-manceindikatoren aus allen Bereichen integriert.

Zu diesen Analysen erhalten Sie sofort Optimierungsvorschläge, so-fern dies ohne umfangreichere Erklärungen möglich ist. Um auch ei-nem in der Performanceanalyse unerfahrenen Berater oder Adminis-trator einen schnellen Einstieg zu ermöglichen, verzichten wirbewusst auf Hintergrundinformationen. So wird z. B. beschrieben,wie Sie das SAP Extended Memory überwachen und einstellen, ohneden Begriff SAP Extended Memory zu erklären. Umfassendere Infor-mationen finden Sie anschließend in den Kapiteln 5 bis 15. DieserAufbau trägt unserer Erfahrung Rechnung, dass es möglich ist, vielePerformanceprobleme im Bereich von Betriebssystem, Datenbankund SAP-Basis anhand einfacher Handlungsanweisungen zu lösen,ohne sich vorher eingehend mit den Details der Architektur zu be-schäftigen.


76

Analyse von Hardware, Datenbank und ABAP-Applikationsserver2

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-Systemaus technisch überwachen und optimieren wollen.

2.1 Begriffsklärungen

Die Begriffe Rechner, Server, Applikationsserver, SAP-Instanz, Daten-bank, Datenbankserver und Datenbankinstanz werden in diesem Buchwie folgt verwendet:

Rechner Ein Rechner (oder Computer) ist eine physische Maschine mit CPU,Hauptspeicher, IP-Adresse etc.

SAP-Applika-tionsinstanz

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, sowieaus einem Satz von SAP-Puffern im Shared Memory des Rechners, aufden die Workprozesse zugreifen. Eine SAP-Applikationsinstanz kanneine ABAP-Applikationsinstanz (SAP NetWeaver Application ServerABAP, kurz AS ABAP oder eine Java-Applikationsinstanz (SAP Net-Weaver Application Server Java, kurz AS Java) sein. Es kann mehrereSAP-Instanzen auf einem Rechner geben. In diesem Fall existierenmehrere Dispatcher und mehrere Puffersätze. Ein Applikationsserverist ein Rechner, auf dem mindestens eine SAP-Instanz läuft.

Datenbank Jedes SAP-System besitzt genau eine Datenbank. Als Datenbankbezeichnen 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, eineadministrative Einheit, die den Zugriff auf eine Datenbank erlaubt.Eine Datenbankinstanz besteht aus Datenbankprozessen und einemSatz von Datenbankpuffern im Shared Memory eines Rechners. EinDatenbankserver ist ein Rechner, auf dem mindestens eine Datenbank-instanz läuft. Ein Rechner kann zugleich Datenbank- und Applikati-onsserver sein, wenn eine Datenbankinstanz und eine SAP-Instanzdarauf laufen.

In der Regel operiert im SAP-Umfeld auf einer Datenbank nur eineDatenbankinstanz. Beispiele für Datenbanksysteme, bei denen auf


77

Hardwareanalyse 2.2

eine Datenbank mehrere Datenbankinstanzen zugreifen, sind DB2und Oracle Parallel Server. Die Besonderheiten solcher parallelenDatenbanksysteme werden in diesem Buch nicht behandelt.

SAP-SystemAls SAP-Systeme bezeichnen wir Softwarekomponenten von SAP mitdem SAP NetWeaver AS als Grundlage. Im Einzelnen sind dies SAPERP, SAP NetWeaver BW, SAP APO, SAP SRM und SAP NetWeaverPortal.

Im Sinne dieser Terminologie kann also z. B. ein SAP ERP-System ausein oder zwei Systemen bestehen, je nachdem, ob der Java- und derABAP-Teil auf einem gemeinsamen System mit einer Datenbank(»Double-Stack«) oder auf zwei Systemen mit getrennten Datenban-ken betrieben werden – dieser Terminologie folgt im Übrigen auchder SAP Solution Manager.

ServerDer Begriff Server wird in der Dokumentation und der Literaturmehrdeutig 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 wirauch ABAP-Server bzw. Java-Server als Kurzformen für den SAP Net-Weaver Application Server (AS) ABAP bzw. Java.

2.2 Hardwareanalyse

Betriebs-systemmonitor

Das Werkzeug zur Analyse von Hardwareengpässen und Betriebssys-temproblemen ist der Betriebssystemmonitor. Um diesen Monitorfür den Applikationsserver zu starten, auf dem Sie zurzeit angemeldetsind, wählen Sie:

Werkzeuge � Administration � Monitor � Performance � Betriebssystem � Lokal � Betriebssystemmonitor

Alternativ können Sie den Transaktionscode ST06 verwenden. Siegelangen auf den Hauptbildschirm des Betriebssystemmonitors.

Aufruf und Verfügbarkeit

Zu Basis-Version 7.10 wurde der Betriebssystemmonitor überarbei-tet. Nach dieser Überarbeitung führen die drei TransaktionscodesOS06, OS07 und ST06 auf einen Monitor, mit dem sowohl der lokaleals auch entfernte Rechner überwacht werden können. Bei Versionenvor 7.10 stehen die neuen Transaktionen unter den TransaktionscodesOS06N, OS07N und ST06N zur Verfügung, mit den Transaktions-


78


codes OS06, OS07 und ST06 erreichen Sie nach wie vor die älterenTransaktionen. Alle Informationen, die wir in diesem Buch bespre-chen, stehen Ihnen auch in den alten Transaktionen zur Verfügung.Die Detailanalysen finden Sie über die Navigation mit der Schalt-fläche Detail Analysis Menu.

Der Betriebssystemmonitor lässt sich auch aus der Serverübersichtheraus aufrufen:

Werkzeuge � Administration � Monitor � Systemüberwachung �Server (Transaktionscode SM51)

Positionieren Sie anschließend den Cursor auf dem gewünschtenApplikationsserver, 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


79

Hardwareanalyse 2.2

Im linken oberen Fenster finden Sie die Auswahl der Rechner, dieüberwacht werden. Dort können Sie einen Rechner auswählen, denSie analysieren wollen. Im linken unteren Fenster wählen Sie dieAnalysedaten aus. Die Daten zum ausgewählten Rechner und zur aus-gewählten Analyse finden Sie im rechten Fenster.

Standardmäßig finden Sie alle Rechner, auf denen SAP-ABAP-Instan-zen installiert wurden, in der Auswahlliste. Grundsätzlich lässt sichaber jeder Rechner in den Remote-Betriebssystemmonitor einbin-den, sofern dort ein Monitoring-Agent installiert ist. Dringend emp-fohlen wird dies für Rechner, auf denen eine Stand-alone-Datenbank,eine SAP-Java-Instanz oder ein TREX läuft.

SAP-SupportBeachten Sie, dass Sie diesen Monitor auch dann einrichten sollten,wenn Sie mit einem Werkzeug eines anderen Herstellers die Auslas-tung Ihrer Rechner überwachen. Sollten Sie Support von SAP benöti-gen, kann ein Experte von SAP nur über den SAP-eigenen Monitordie Rechner analysieren.

2.2.1 Analyse eines Hardwareengpasses(CPU und Hauptspeicher)

Eine Übersicht über die wichtigsten Betriebssystem- und Hardware-daten finden Sie unter dem Punkt Snapshot in der Analyseauswahldes Betriebssystemmonitors (siehe Abbildung 2.1). Alle Daten desBetriebssystemmonitors werden vom Hilfsprogramm saposcol imZehn-Sekunden-Rhythmus aufgefrischt. Ein Auffrischen der Datenmit der entsprechenden Drucktaste ergibt also nur dann neue Daten,wenn zehn Sekunden verstrichen sind.

CPU-AuslastungIm Abschnitt CPU finden Sie die Felder Benutzerauslastung, System-auslastung und Leerlauf. Diese Werte zeigen an, wie viel Prozent derCPU-Kapazität augenblicklich von Benutzerprozessen (d.h. vom SAP-System, der Datenbank und weiteren Prozessen) und vom Betriebssys-tem selbst genutzt werden und wie viel Prozent derzeit frei sind. DasFeld Anzahl CPUs gibt die Anzahl der CPU-Fäden (»Threads«) an.Mittlere Prozesswartezeit ist die Anzahl der Prozesse, die auf einenfreien Prozessor warten. Dieser Wert wird im Mittel über eine Minute,über fünf Minuten und über 15 Minuten angegeben. Die weiterenWerte im Abschnitt CPU sind für die Performanceanalyse wenigerwichtig. Tabelle 2.1 gibt Ihnen einen Überblick über die Felder desBetriebssystemmonitors.


80


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 mit2.93 GHz Taktfrequenz«. Was bedeuten die Angaben über die Anzahl derProzessoren, 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, Programmeauszuführen. Dabei unterscheidet man zwischen Einkernprozessoren undMehrkernprozessoren. Mehrkernprozessoren verfügen über mehrere vollstän-dig ausgebaute Verarbeitungseinheiten (Kerne) auf einem Chip. Die einzelnenKerne 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 sichfür diese Kerne mehrere Warteschlangen, aus, zwischen denen der Kern hin-und herschaltet. Um diesen Wechsel zu optimieren, besitzt jeder Thread eineneigenen Registersatz, einschließlich Stack Pointer und Program Counter, damitkann ohne zusätzliche Prozessorzyklen zwischen den Threads geschaltet wer-den. Diese hardwareseitigen Threads sollten Sie jedoch nicht mit den Threadsverwechseln, die die Anwendungsprozesse erzeugen (User- oder Software-Threads). Innerhalb eines Prozesses der Datenbank, des ABAP-, Java- oderTREX-Servers können mehrere (Software-)Threads erzeugt werden, die vomBetriebssystem in Zeitscheiben ausgeführt werden. Den Wechsel zwischenden (Software-)Threads bezeichnet man als Kontextwechsel. Unter diesemGesichtspunkt kann man also sagen, dass zusätzliche (Hardware-)ThreadsKontextwechsel zwischen (Software-)Threads begünstigen und damit den vor-handenen Kern besser auslasten helfen, allerdings von der Leistungssteigerungnicht ganz an einen zusätzlichen Kern heranreichen.

Feld Bedeutung

Benutzerauslastung CPU-Auslastung durch Benutzerprozesse (SAP-System, Datenbank etc.)

Systemauslastung CPU-Auslastung durch das Betriebssystem

Leerlauf Freie CPU-Kapazität. Dieser Wert sollte mindes-tens 20 % betragen, optimalerweise aber 35 %.

Anzahl der CPUs Anzahl der CPU-Threads

Mittlere Prozess-wartezeit

Anzahl der Prozesse, die auf die CPUs warten, gemittelt über eine, fünf bzw. 15 Minuten

Physischer Speicher physisch vorhandener Hauptspeicher (RAM) in KB

Tabelle 2.1 Felder des Betriebssystemmonitors


81

Hardwareanalyse 2.2

Hauptspeicher-auslastung

Der Abschnitt Memory enthält Informationen über den physisch vor-handenen Hauptspeicher (Feld Physischer Speicher) und Werte überdas Betriebssystem-Paging. Unter Swap finden Sie den aktuell allo-kierten Auslagerungsspeicher (Swap-Space). Der Auslagerungsspeichermuss größer als die Summe des konfigurierten Speicherbereichs sein.

Programmabbrüche durch Speicherknappheit

Ist die Summe aus physischem Speicher und Auslagerungsspeicher kleinerals der vom SAP-System, von der Datenbank und anderen Programmenbenötigte Speicher, kann es zu Speicherverwaltungsfehlern (d. h. zu Pro-grammabbrüchen innerhalb des SAP-Systems), im schlimmsten Fall sogarzum Abbruch des Betriebssystems, kommen. Sie sollten also in jedem Fallden Auslagerungsspeicher ausreichend dimensionieren.

Historien: CPU und Hauptspeicher

Um einen Überblick über die CPU-Auslastung der letzten 24 Stundenzu erhalten, wählen Sie im Betriebssystemmonitor die AnalyseVorige Stunden � CPU. Sie gelangen auf den Bildschirm VorigeStunden CPU. Die Bedeutung der Felder ist dieselbe wie im Haupt-bildschirm, 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.

Wann liegt ein CPU- bzw. ein Hauptspeicherengpass vor?

RichtwerteIm Stundenmittel sollte der freie CPU-Anteil Leerlauf mindestens20 % 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:

� Bei Rechnern, die eine Datenbank, eine Java-Instanz oder einenTREX beherbergen, sollten nur sehr geringe Paging-Raten zu beob-achten sein, d. h., sie sollten so dimensioniert sein, dass der verfüg-bare Hauptspeicher den konfigurierten Speicherbereichen ent-spricht.

� Bei Rechnern, die ausschließlich ABAP-Instanzen tragen, könnenmäßige Paging-Raten von bis zu 20 % des physischen Hauptspei-chers pro Stunde toleriert werden.

Dabei ist für Betriebssysteme, die kontinuierlich Speicher auslagern(z. B. Microsoft Windows), die Paged-in-Rate entscheidend, fürandere Betriebssysteme hingegen, die erst bei Bedarf auslagern (die


82


meisten UNIX-Derivate), die Paged-out-Rate. Umgekehrt bedeutet dasÜberschreiten dieser Richtwerte nicht automatisch, dass ein Hard-wareengpass vorliegt. Vielmehr sollten Sie in diesem Fall mithilfe desWorkload-Monitors prüfen, ob sich die CPU-Auslastung bzw. diePaging-Rate negativ auf die Antwortzeiten auswirkt. EntsprechendeAnalysen finden Sie in Abschnitt 3.4.1, »Allgemeines Performance-problem analysieren«.

Haupt-speicher-engpass

Wenn Sie in der Voranalyse hohe Paging-Raten auf mehreren Rechnernbeobachten, sollten Sie den von den SAP-Instanzen und der Datenbankallokierten Hauptspeicher berechnen (siehe die Abschnitte 2.4.3,»Anzeige des allokierten Speichers«, und 2.3.2, »Analyse der Daten-bankpuffer«). Vergleichen Sie diesen mit dem physisch vorhandenenHauptspeicher. 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 Solariskann die Auswertung der Paging-Rate auf dem Datenbankserver zuFehlinterpretationen führen, da dort Schreib-/Lese-Operationen (I/O)unter gewissen Umständen ebenfalls als Paging gezählt werden. Ver-gleichen Sie dazu die SAP-Hinweise 124199 (Solaris) und 689818(Windows).

Ursache von Hardwareengpässen

Ist nach den oben genannten Kriterien ein Hardwareengpass aufeinem oder mehreren Rechnern des SAP-Systems erkennbar, sind fol-gende Ursachen möglich:

� Falsche LastverteilungWenn Sie in einem verteilten System mit mehreren Rechnern aufmindestens einem Rechner einen Hardwareengpass feststellen,während andere Rechner über ungenutzte Ressourcen verfügen,liegt vermutlich eine falsche Lastverteilung vor. In diesem Fall soll-ten Sie die SAP-Workprozesse und die Benutzer neu verteilen.

Überaus wichtig ist es, dass der Datenbankserver über genügendRessourcen verfügt. Ein CPU- oder Hauptspeicherengpass auf demDatenbankserver führt dazu, dass die benötigten Daten aus derDatenbank nicht zügig bereitgestellt werden können, was sich wie-derum negativ auf die Antwortzeiten innerhalb des gesamten Sys-tems auswirkt.


83

Hardwareanalyse 2.2

� CPU-Auslastung einzelner ProgrammeWä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 Ressourcen-auslastung.

Übersicht der Betriebssystem-prozesse

Abbildung 2.2 zeigt eine solche Übersicht für ein System, auf demeine ABAP-Instanz und eine DB2-Datenbank installiert sind. Fol-gende Prozesse können Sie identifizieren:

� dw_: SAP-Workprozess der SAP-ABAP-Instanz aufeinem UNIX-Betriebssystem. Auf Windows-Betriebssystemen lau-tet die Bezeichnung disp+work.

� db2sysc: Datenbankprozess der DB2-Datenbank. Die Prozesseanderer Datenbanken führen in der Regel ihre Markenbezeich-nung (z. B. Oracle) im Prozess- oder Benutzernamen.

Abbildung 2.2 Analyse der Top-CPU-Prozesse im Betriebssystemmonitor


84


Betriebssystemprozesse, die Sie anhand der folgenden Namensbe-standteile erkennen können, gehören außerdem zu SAP-Instanzen:

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

� TREX ...: TREX-Prozess, der Servertyp kann dem Prozessnamenentnommen 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 Betriebs-systemmonitor 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 Pro-zesse der SAP-Basis oder der Datenbank, finden Sie in den im Folgen-den genannten Monitoren weitere Informationen über die Tätigkei-ten der Prozesse. Starten Sie den Monitor in einem zweiten Modus,identifizieren Sie anhand der Prozess-ID, die Sie auch in den entspre-chenden Basismonitoren finden, den Prozess mit der hohen CPU-Auslastung, und entnehmen Sie den Monitoren, welches Programmbzw. welche Tabelle, Anfrage etc. der Prozess gerade bearbeitet.

� SAP-Workprozesse der ABAP-InstanzStarten Sie in einem zweiten Modus die SAP-Workprozess-Über-sicht (siehe Abschnitt 2.5, »Analyse der SAP-Workprozesse«). DerWorkprozess-Übersicht entnehmen Sie u. a. den Namen des lau-fenden ABAP-Programms und des zugehörigen Benutzers.

� Serverprozess der Java-InstanzStarten Sie die SAP Management Console (siehe Abschnitt 10.3,»SAP Management Console«). Prozessinterna erhalten Sie durcheinen Thread-Dump.

� TREX-ProzesseStarten Sie das TREX-Administrationswerkzeug (siehe Abschnitt14.2, »Performanceanalyse auf dem TREX durchführen«). ImMonitor Services finden Sie Details zu den TREX-Services.

� ICMStarten Sie den ICM-Monitor (siehe Abschnitt 2.6, »Analyse desInternet Communication Managers (ICM)«).

� DatenbankprozesseStarten Sie im DBA-Cockpit den Datenbankprozessmonitor (sieheAbschnitt 2.3.3, »Identifizierung teurer SQL-Anweisungen«), um


85

Hardwareanalyse 2.2

die SQL-Anweisungen zu identifizieren, die aktuell von der Daten-bank bearbeitet werden.

Die Prozessübersicht auf Betriebssystemebene bietet Ihnen alsozusammen mit den genannten Monitoren vergleichsweise bequemdie Möglichkeit, Programme, Transaktionen bzw. SQL-Anweisungenoder TREX-Anfragen mit hoher CPU-Auslastung zu identifizieren.

Externe ProzesseEin CPU-Engpass kann durch externe Prozesse verursacht werden. Fin-den Sie in der Prozessübersicht externe Prozesse (d. h. Prozesse, dienicht direkt zum SAP-System gehören) mit einem hohen CPU-Kon-sum, die zu einem CPU-Engpass führen, sollten Sie prüfen, ob diesefür den Betrieb Ihres Systems notwendig sind oder ob sie abgeschal-tet oder auf einen anderen Rechner verlagert werden können. Bei-spiele für externe Prozesse sind: Verwaltungssoftware, Virenscanner,Backup, externe Systeme, Bildschirmschoner (!) etc.

Identifizierung eines CPU-Engpasses

Sie beobachten während Ihrer Hauptarbeitszeit einen CPU-Engpass. In derProzessü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 laufendesHintergrundprogramm. In diesem Fall sollten Sie prüfen, ob dieses Hinter-grundprogramm zu Zeiten niedriger Dialoglast eingeplant werden kann.

Speicherbedarf einzelner Programme

Analog dem Vorgehen bei einem CPU-Engpass können Sie sich beieinem Hauptspeicherengpass auf die Suche nach Programmen mithohem Speicherbedarf machen. Vergleichen Sie dazu Kapitel 6,»Speicherkonfiguration«.

File System Cache minimieren

Betriebssysteme verwalten in der Regel einen eigenen File SystemCache. Dieser Cache konkurriert mit dem SAP-System und der Daten-bank um die Nutzung des Hauptspeichers. Ist der Cache zu groß ein-gestellt, kommt es zu hohen Paging-Raten, obwohl mehr physischerHauptspeicher verfügbar ist, als durch SAP-System und Datenbankallokiert wurden. Wir empfehlen Ihnen, diesen Cache auf 7 bis 10 %des physischen Speichers zu reduzieren.

UNIXDie Betriebssystemparameter zur Einstellung des File System Cachessind z. B. dbc_max_pct bei HP-UX, ubc-maxpercent bei Digital UNIXund maxperm bei AIX.


86


Windows Um den Microsoft Windows File Cache zu minimieren, rufen Sie dieNetzwerkeinstellung (Symbol: Network) im Control Panel IhresWindows-Betriebssystems auf. Wählen Sie die Registerkarte Ser-vices, Service Server, Schaltfläche Properties. Wählen Sie in der fol-genden Maske unter Optimization die Option Maximize Through-put for Network Applications aus, und bestätigen Sie mit OK. Umden so reduzierten File Cache zu aktivieren, muss der Rechner neugestartet werden.

Ein Hauptspeicherengpass kann zu einem erhöhten CPU-Konsumaufgrund starken Pagings und damit zum CPU-Engpass führen. DieBeseitigung des Hauptspeicherengpasses kann also unter Umständenein Verschwinden des CPU-Engpasses mit sich bringen.

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

Im Betriebssystemmonitor (Transaktionscode ST06) finden Sie in derAnalysesicht Snapshot � Platte u. a. Informationen über die Auslas-tung der Festplatten und – sofern das Betriebssystem diese korrektzur Verfügung stellt – über Warte- und Antwortzeiten der Platten.

Festplattenmonitor Durch einen Doppelklick auf eine Zeile erhalten Sie für die ausge-wählte Festplatte einen Überblick über die mittleren Antwortzeiteninnerhalb der letzten 24 Stunden. Tabelle 2.2 listet die angezeigtenFelder und ihre Bedeutung auf.

Feld Bedeutung

Disk Name der Festplatte auf Betriebssystemebene

Auslastung (%) Auslastung der Platte (in Prozent)

Queue-Länge Anzahl der Prozesse, die auf I/O-Operationen warten

Wartezeit (ms) Wartezeit (in Millisekunden)

Servicezeit (ms) Servicezeit (in Millisekunden)

Übertragung (KB/s) Übertragungsrate (in KB/Sekunde)

Operationen (per Sec) Anzahl der I/O-Operationen (pro Sekunde)

Antwortzeit (ms) mittlere Antwortzeit der Festplatte (in Milli-sekunden)

Tabelle 2.2 Felder des Festplattenmonitors


87

Hardwareanalyse 2.2

I/O-EngpassStellen Sie anhand dieser Monitore fest, dass einzelne Platten starkausgelastet sind (Auslastung (%) > 50 %), liegt ein potenzieller I/O-Engpass vor. Aus dem SAP-System heraus ist allerdings nur eine sehrbeschränkte Aussage über I/O-Probleme möglich. Eine detaillierteAnalyse kann nur mit Mitteln des Hardwarepartners durchgeführtwerden.

Ein I/O-Engpass ist insbesondere dann kritisch, wenn auf dieser Fest-platte der Auslagerungsspeicher des Betriebssystems liegt. Darüberhinaus ist der Betriebssystemmonitor für den Datenbankserver vonbesonderem Interesse. Zusammen mit dem Datenbankmonitor kön-nen mit dieser Anzeige Engpässe beim Lesen bzw. Schreiben auf dieFestplatten eingegrenzt werden. Weitere Details zu diesem Problemfinden Sie in Abschnitt 2.2.2, »Identifizierung von Schreib-/Lese-(I/O-)Problemen«.

2.2.3 Weitere Analysen auf Betriebssystemebene

Parameter-änderungen

Das SAP-System protokolliert für UNIX-Betriebssysteme alle Ände-rungen der Betriebssystemparameter. Das Änderungsprotokoll kannüber den folgenden Pfad im Betriebssystemmonitor angezeigt wer-den: Weitere Funktionen � Parameteränderungen. PositionierenSie den Cursor auf dem Namen eines Servers, und wählen Sie dieSchaltfläche History of File. Anhand des Änderungsprotokolls lässtsich feststellen, ob Performanceprobleme eventuell erst nach Para-meteränderungen aufgetreten sind und damit in Zusammenhang ge-bracht werden können.

Netzwerk-CheckMit dem Werkzeug Weitere Funktionen � LAN-Überprüfung mitPing lässt sich ein grober Netzwerktest durchführen. Sie könnenbeliebige Datenbank-, Applikations- oder Präsentationsserver aus-wählen und die Netzwerkverbindung (z. B. die Antwortzeiten undDatenverluste) testen. Auch wenn der Name der Analyse fälschlicher-weise LAN-Überprüfung heißt, können auch Rechner im WAN ange-sprochen werden. Ein Beispiel für eine Analyse mit diesem Werkzeugfinden Sie in Abschnitt 8.1.2, »Performance der GUI-Kommunikationanalysieren und optimieren«.


88


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 ausgela-gert (»gepaged«) werden

� einzelne Festplatten der Datenbank zu mehr als 50 % ausgelastetsind

Insbesondere die Überlastung des Datenbankservers kann zu Perfor-manceproblemen führen, die sich systemweit auswirken. Prüfen Siemithilfe des Workload-Monitors, ob sich die hohe CPU-Auslastungbzw. die hohen Paging-Raten negativ auf die Antwortzeiten des SAP-Systems bzw. der Datenbank auswirken (siehe Abschnitt 3.4, »Work-load-Analyse durchführen«).

Hardwareengpassanalysieren

Abbildung 2.3 und Abbildung 2.4 zeigen den Analysepfad bei einemHardwareengpass: Häufig kann ein Hardwareengpass durch die Neu-verteilung der Last (z. B. durch das Verlagern von Workprozessen)behoben werden. Ursachen für einen CPU-Engpass sind z. B. ineffizi-ente Applikationen, die im Datenbankprozessmonitor und in derWorkprozess-Übersicht identifiziert werden können, oder externe,nicht zu einer SAP-Instanz bzw. der Datenbankinstanz gehörendeProzesse. Daher muss immer eine vollständige Performanceanalysedurchgeführt werden, bevor endgültig entschieden werden kann, obdie vorhandene Hardware für die gegebenen Anforderungen an dasSAP-System ausreicht oder nicht.

Die Flussdiagramme in Abbildung 2.3 und Abbildung 2.4 zeigenIhnen schematisch das Vorgehen bei einem Hardwareengpass. Sieverweisen auf später in diesem Buch beschriebene Monitore undAnalysen. Sie werden ähnliche Diagramme an vielen Stellen diesesBuches finden.


89

Datenbankanalyse 2.3

2.3 Datenbankanalyse

Der SAP NetWeaver Application Server (AS) kann zurzeit mit achtverschiedenen relationalen Datenbanksystemen sowie mit derHauptspeicherdatenbank SAP HANA betrieben werden. Auch wenndiese Datenbanksysteme alle eine unterschiedliche Architektur besit-

Abbildung 2.3 Detailanalyse eines Hardwareengpasses (CPU)

Abbildung 2.4 Detailanalyse eines Hardwareengpasses (Hauptspeicher)

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!

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


403

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 Sper-ren warten müssen. Dieses Kapitel stellt detailliert die Sperr-konzepte und deren Überwachung dar.

9 Sperren

In einem SAP-System können viele Benutzer gleichzeitig Inhalte vonDatenbanktabellen lesen. Bei Änderungen des Datenbestands ist esjedoch notwendig, sicherzustellen, dass zu einem bestimmten Zeit-punkt 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 Daten-banksystem werden im ersten Abschnitt dieses Kapitels erklärt.

Werden Sperren lange Zeit gehalten, kann es zu Wartesituationenkommen, die den Durchsatz des SAP-S

Documents

SAP -Performanceoptimierung€¦ · Bonn Boston Thomas Schneider SAP®-Performanceoptimierung Analyse und Tuning von SAP-Systemen 2177.book Seite 3 Montag, 10. Juni 2013 11:30 11