Oracle-Datenbankadministration für SAP · 2018. 3. 26. · Michael Höding, André Faustmann,...

Michael Höding, André Faustmann,Gunnar Klein, Ronny Zimmermann

Oracle®-Datenbankadministration für SAP®

Bonn � Boston

831-6.book Seite 3 Freitag, 8. Juni 2007 4:29 16

Auf einen Blick

1 Einleitung ................................................................ 15

2 Grundwissen SAP .................................................... 27

3 Grundwissen Oracle ................................................ 69

4 SAP und Oracle ....................................................... 161

5 Planung der Systemlandschaft ............................... 261

6 SAP Änderungs- und Transportmanagement ......... 299

7 Systemlebenszyklus ................................................ 369

8 Performance ............................................................ 439

9 Systembetrieb und Monitoring .............................. 535

10 Backup, Restore und Recovery ............................... 591

11 Administration des Java-Stacks ............................. 729

12 SAP NetWeaver BI und Oracle ............................... 787

13 Nachwort und Ausblick .......................................... 853

A Flugdatenmodell ..................................................... 857

B Allgemeine Optionen der BR*Tools ........................ 859

C Literatur .................................................................. 865

D Die Autoren ............................................................. 867


7

Inhalt

1 Einleitung ............................................................................. 15

1.1 Gründe, dieses Buch zu besitzen .............................................. 161.2 Aufgaben der SAP-Basis ........................................................... 181.3 Gliederung dieses Buches ........................................................ 191.4 Konventionen und weitere Informationen ............................... 241.5 Danksagung ............................................................................. 25

2 Grundwissen SAP ................................................................. 27

2.1 SAP-Software im Überblick ...................................................... 272.1.1 Standardsoftware versus Individualsoftware ................ 282.1.2 Integration .................................................................. 282.1.3 Entwicklung von SAP R/3 ............................................ 292.1.4 Begriffswelt von SAP ................................................... 32

2.2 Architektur und Skalierbarkeit ................................................. 362.3 Applikationsserver ................................................................... 39

2.3.1 Prozesse des SAP-Applikationsservers im Überblick ..... 392.3.2 Speicherstrukturen ...................................................... 412.3.3 Dispatcher .................................................................. 422.3.4 Dialog-Workprozess (DIA) .......................................... 442.3.5 Batch-Workprozess (BTC) ............................................ 482.3.6 Verbucher-Prozess (UPD) ............................................ 492.3.7 Sperrverwaltung mit dem Enqueue-Prozess (ENQ) ...... 512.3.8 Message-Server-Prozess .............................................. 522.3.9 Gateway-Prozess ......................................................... 522.3.10 Ausprägung einer Instanz ............................................ 52

2.4 SAP-Administration ................................................................. 532.4.1 Profildateien und Start des Systems ............................. 532.4.2 Softwarepflege ............................................................ 552.4.3 Administration der Datenbank .................................... 562.4.4 Datensicherung ........................................................... 572.4.5 Performanceoptimierung ............................................. 59

2.5 SAP und Softwareentwicklung ................................................. 602.5.1 ABAP-Framework ....................................................... 602.5.2 Java im SAP-Kern ........................................................ 642.5.3 Internet Transaction Server ......................................... 652.5.4 Remote Function Call (RFC) ........................................ 66

2.6 Zusammenfassung ................................................................... 67


Inhalt

8

3 Grundwissen Oracle ............................................................. 69

3.1 Grundlagen der Datenbanktechnologie .................................... 693.1.1 Motivation und Geschichte ......................................... 693.1.2 Relationales Datenmodell und SQL ............................. 763.1.3 Kurzer Überblick über SQL .......................................... 803.1.4 Implementierungstechniken für DBMS ........................ 85

3.2 Entwicklung von Oracle ........................................................... 883.3 Werkzeuge für den Oracle-Administrator ................................. 91

3.3.1 sqlplus ........................................................................ 913.3.2 isqlplus ....................................................................... 933.3.3 Oracle Enterprise Manager .......................................... 94

3.4 Oracle-Kern ............................................................................. 963.4.1 Oracle-Prozesse .......................................................... 973.4.2 Oracle-Hauptspeicherstrukturen ................................. 1013.4.3 Oracle-Dateisystem ..................................................... 1043.4.4 Tablespace-Konzept von Oracle .................................. 1063.4.5 Weitere wichtige Dateien ........................................... 1183.4.6 Zusammenspiel von Prozessen und

Speicherstrukturen ...................................................... 1253.4.7 Zugriff auf Oracle mit Oracle Net ................................ 1293.4.8 Anfrageoptimierung .................................................... 1363.4.9 Datensicherung und Wiederherstellung ....................... 1443.4.10 Benutzer und Berechtigungen ..................................... 1533.4.11 Monitoring einer Oracle-Instanz mit dem Enterprise

Manager ..................................................................... 1583.5 Zusammenfassung ................................................................... 159

4 SAP und Oracle .................................................................... 161

4.1 Prozesse von SAP und Oracle .................................................. 1624.1.1 Systemstart ................................................................. 1644.1.2 Beziehungen zwischen den Prozessen ......................... 1744.1.3 Kommunikation zwischen SAP-Instanzen und

Oracle-Prozessen ........................................................ 1764.1.4 Log- und Trace-Dateien .............................................. 1784.1.5 Systemstopp ............................................................... 184

4.2 Voraussetzungen auf Betriebssystemebene .............................. 1864.2.1 Benutzer, Gruppen und Umgebungsvariablen (UNIX) .. 1914.2.2 Oracle-Client .............................................................. 1944.2.3 SAP-Kernel ................................................................. 200


Inhalt

9

4.3 Authentifizierung zwischen SAP und Oracle ............................. 2054.3.1 Datenbankbenutzer .................................................... 2054.3.2 Anmeldeverfahren ...................................................... 2074.3.3 Berechtigungen in der Datenbank ............................... 2134.3.4 Sicherheitsaspekte ...................................................... 214

4.4 SAP-Tablespaces ...................................................................... 2184.4.1 Tablespace-Layout ...................................................... 2184.4.2 Tablespace-Typen ....................................................... 2244.4.3 Objektzuordnung und Objektparameter ...................... 2254.4.4 Reorganisation von Tabellen und Tablespaces ............. 227

4.5 Administration von Oracle mit den BR*Tools ........................... 2334.5.1 Entwicklung und Inhalt ............................................... 2344.5.2 Umgebung, Optionen und Log-Dateien ...................... 2364.5.3 BRTOOLS und BRGUI ................................................. 2414.5.4 BRCONNECT .............................................................. 2454.5.5 BRSPACE .................................................................... 2494.5.6 Parameterpflege für Oracle ......................................... 253


5 Planung der Systemlandschaft ............................................. 261

5.1 Vom Produkt zur Lösungslandschaft ........................................ 2615.2 Planungskriterien im Überblick ................................................ 263

5.2.1 Bauliche Infrastruktur .................................................. 2645.2.2 Servertechnologie und -plattformen ............................ 2695.2.3 Storage und SAN-Infrastruktur .................................... 2735.2.4 Backup ........................................................................ 2775.2.5 Frontend ..................................................................... 279

5.3 Hochverfügbarkeit ................................................................... 2845.4 IT- und Systemsicherheit ......................................................... 2895.5 Erweiterung einer bestehenden Landschaft .............................. 2965.6 Zusammenfassung ................................................................... 298

6 SAP Änderungs- und Transportmanagement ...................... 299

6.1 Standardsoftware und Änderungen am Standard ..................... 3006.2 Grundlagen der Softwarelogistik .............................................. 303

6.2.1 Daten im SAP-System ................................................. 3036.2.2 Systemlandschaft ........................................................ 3086.2.3 Change and Transport System (CTS) ............................ 3126.2.4 Aufzeichnung von Änderungen ................................... 3156.2.5 Änderungsaufträge (Change Requests) ........................ 317


Inhalt

10

6.2.6 Transport Management System ................................... 3216.2.7 Transportwege und Transportschichten ....................... 327

6.3 Änderungsmanagement für Customizing-Einstellungen ............ 3346.4 Änderungsmanagement für Entwicklungen .............................. 3396.5 Transportmanagement ............................................................. 344

6.5.1 Transport Organizer Tools ........................................... 3446.5.2 Transportstrategie ....................................................... 3456.5.3 Importqueue und Importpuffer ................................... 3536.5.4 Transporte zwischen Transportgruppen ....................... 3556.5.5 Transporte zwischen Transportdomänen ..................... 3576.5.6 Bedienung des Transportsteuerungsprogramms tp ...... 3616.5.7 Protokollierung der Transporte .................................... 3646.5.8 Transporte zwischen Unicode- und Nicht-Unicode-

Systemen .................................................................... 3666.6 Tipps und Tricks ...................................................................... 3676.7 Zusammenfassung ................................................................... 368

7 Systemlebenszyklus ............................................................. 369

7.1 Installation .............................................................................. 3697.1.1 Installationswerkzeuge ................................................ 3697.1.2 Phasen ........................................................................ 3737.1.3 Unattended Installation .............................................. 385

7.2 Systempflege ........................................................................... 3877.2.1 Mandantenwerkzeuge ................................................. 3877.2.2 SAP Support Packages, Patches und Korrekturen ........ 3947.2.3 Wartung der Oracle-Datenbank .................................. 4097.2.4 Wartung des Betriebssystems ...................................... 416

7.3 Upgrades ................................................................................. 4187.3.1 SAP-Upgrade .............................................................. 4187.3.2 Oracle-Upgrade .......................................................... 436


8 Performance ......................................................................... 439

8.1 Administrative und programmatische Probleme ....................... 4418.2 Analyse administrativer Performanceprobleme ......................... 443

8.2.1 Analyse von Hardware und Betriebssystem .................. 4448.2.2 Analyse der Datenbank ............................................... 4518.2.3 Analyse des SAP-Systems ............................................ 496

8.3 Analyse programmatischer Performanceprobleme: SQL-Optimierung .................................................................... 513


Inhalt

11

8.3.1 Duale Ziele: Funktional und performant ...................... 5138.3.2 Auswirkungen ............................................................. 5158.3.3 Werkzeuge zur Problemanalyse ................................... 5178.3.4 Detaillierte Analyse von SQL-Anweisungen ................. 5208.3.5 Königsweg Prävention ................................................ 5258.3.6 Indexe für schnellen Zugriff ......................................... 528


9 Systembetrieb und Monitoring ............................................ 535

9.1 Monitoring im SAP-Umfeld: Motivation und Umfang .............. 5359.1.1 Bereiche des Monitorings ............................................ 5369.1.2 Monitoring-Probleme ................................................. 5409.1.3 Lösungen für ein SAP-Monitoring ............................... 541

9.2 Parameter für die Überwachung eines SAP-Systems auf Oracle-Basis ............................................................................. 5439.2.1 Überwachung der Oracle-Datenbank .......................... 5449.2.2 Überwachung des SAP-Systems ................................... 5609.2.3 Überwachung von Hardware und Betriebssystem ........ 577

9.3 Hintergrundjobs im Umfeld des Monitorings ........................... 5829.3.1 SAP-Standardjobs ....................................................... 5839.3.2 Oracle-Jobs ................................................................. 588


10 Backup, Restore und Recovery ............................................. 591

10.1 Was muss gesichert werden? ................................................... 59310.1.1 Zusammenspiel der Oracle-Prozesse und

-Datenbankobjekte ..................................................... 59510.1.2 Betriebsmodi der Oracle-Datenbank ........................... 60010.1.3 Archiver Stuck ............................................................. 603

10.2 Datensicherungsmethoden ...................................................... 60810.2.1 Datenexport ................................................................ 60910.2.2 Offline-Datensicherung ............................................... 61010.2.3 Online-Datensicherung ............................................... 612

10.3 Wiederherstellungsmethoden .................................................. 61710.3.1 Wiederherstellung aus einer Offline-Datensicherung ... 62110.3.2 Wiederherstellung aus einer Online-Datensicherung ... 62210.3.3 Fehlerszenario: Verlust eines normalen Tablespace ...... 62310.3.4 Partial Restore and Complete Recovery ....................... 62410.3.5 Database Reset ........................................................... 62510.3.6 Point-in-Time Recovery ............................................... 62610.3.7 Full Restore and Complete Recovery ........................... 628


Inhalt

12

10.4 BR*Tools für Backup, Restore und Recovery ............................. 62910.4.1 Datensicherung mit BRBACKUP .................................. 63210.4.2 Sicherung der Redo-Log-Dateien mit BRARCHIVE ....... 64310.4.3 Wiederherstellung mit BRRESTORE ............................. 65410.4.4 Recovery der Datenbank mit BRRECOVER .................. 66010.4.5 Nacharbeiten bei einem unvollständigen Recovery ...... 66610.4.6 BR*Tools und temporäre Tablespaces .......................... 66810.4.7 Disaster Recovery mit den BR*Tools ............................ 66910.4.8 BR*Tools in Windows-Umgebungen ............................ 67210.4.9 Backup-Medien und Volume Management ................. 672

10.5 Oracle Recovery Manager (RMAN) .......................................... 67810.5.1 Sicherungen ohne Sicherungsbibliothek ...................... 68410.5.2 Sicherungen mit der SAP-Sicherungsbibliothek ........... 68510.5.3 Sicherungen mit einer externen Sicherungsbibliothek .. 686

10.6 Weitere Fehlerszenarien .......................................................... 68710.6.1 Verlust einer Control-Datei ......................................... 68710.6.2 Verlust aller Control-Dateien und des System-

und/oder Rollback-Tablespace .................................... 68810.6.3 Verlust des System- und/oder Rollback-Tablespace ..... 69410.6.4 Verlust einer Datendatei eines temporären

Tablespace .................................................................. 69610.6.5 Verlust einer Online-Redo-Log-Datei .......................... 69810.6.6 Verlust einer Online-Redo-Log-Gruppe ....................... 70010.6.7 Verlust aller Online-Redo-Log-Dateien ....................... 70410.6.8 Verlust von Offline-Redo-Log-Dateien ........................ 70510.6.9 Zusammenbruch der Datenbank während einer

Online-Sicherung ........................................................ 70610.7 Backup-Strategien ................................................................... 709

10.7.1 Partielle Sicherungen .................................................. 71510.7.2 Zwei-Phasen-Datensicherung ...................................... 71710.7.3 Standby-Datenbanken ................................................. 71810.7.4 Split-Mirror-Datenbanken ........................................... 721

10.8 Tipps und Tricks ...................................................................... 72610.9 Zusammenfassung ................................................................... 728

11 Administration des Java-Stacks ........................................... 729

11.1 Verwendung von Java in SAP-Systemen ................................... 73011.2 Architektur der J2EE Engine ..................................................... 733

11.2.1 Interner Aufbau .......................................................... 73911.2.2 Zusammenspiel des Java-Stacks mit der Datenbank ..... 74711.2.3 Monitoring ................................................................. 757


Inhalt

13

11.3 Java-Softwarelogistik ............................................................... 76811.3.1 SAP NetWeaver Development Infrastructure ............... 76811.3.2 SAP-Komponentenmodell ........................................... 77111.3.3 Patchen von Java-Instanzen und -Applikationen ......... 773

11.4 Tipps ....................................................................................... 77911.4.1 Profilparameter für die J2EE Engine ............................. 77911.4.2 Parameter des Property-Files ....................................... 78211.4.3 Minimalkonfiguration der Datei instance.properties .... 784


12 SAP NetWeaver BI und Oracle ............................................. 787

12.1 Grundlagen und Konzepte des Data Warehousing ................... 78712.1.1 OLAP und OLTP .......................................................... 78712.1.2 Data-Warehouse-Architektur ...................................... 78912.1.3 Extraktion, Transformation, Laden ............................... 79012.1.4 Datenstrukturen und Entwurf eines Data Warehouse .. 79312.1.5 Operationen zur Datenanalyse .................................... 79612.1.6 Data Mining ................................................................ 79712.1.7 Nutzen ........................................................................ 798

12.2 Data Warehousing mit Oracle .................................................. 79812.2.1 Technologie und Architektur ....................................... 79912.2.2 Konzepte und Spracherweiterungen in Oracle ............. 80412.2.3 Werkzeuge .................................................................. 806

12.3 SAP NetWeaver BI: Ein Überblick ............................................ 80812.3.1 Business Content ........................................................ 81012.3.2 Datenmodellierung ..................................................... 81112.3.3 Modellierung von Business-Intelligence-Objekten ....... 81612.3.4 Grundlagen der Datenbeschaffung .............................. 82012.3.5 Laden von Stamm- und Bewegungsdaten .................... 82312.3.6 Delta-Extraktion aus Quellsystemen ............................ 82612.3.7 Reporting .................................................................... 828

12.4 SAP NetWeaver BI auf Oracle .................................................. 83312.4.1 BI-Tabellen und -Indexe in der Oracle-Datenbank ....... 83512.4.2 Konfiguration der Oracle-Datenbank ........................... 83912.4.3 PGA und temporärer Tablespace ................................. 84212.4.4 Statistiken für BI-Tabellen ........................................... 84712.4.5 Sonstiges .................................................................... 848


13 Nachwort und Ausblick ........................................................ 853


Inhalt

14

Anhang........................................................................................ 855

A Flugdatenmodell ................................................................................ 857A.1 SQL-Skript zum Anlegen der Datenbank .................................. 857A.2 Perl-Skript zum Erzeugen des Datenbankinhalts ....................... 858

B Allgemeine Optionen der BR*Tools .................................................... 859C Literatur ............................................................................................. 865D Die Autoren ....................................................................................... 867

Index ......................................................................................................... 869


439

Performance ist nicht alles, aber ohne Performance ist alles nichts, denn das Warten ist die größte Qual des Benutzers.

8 Performance

Die Performance oder Leistung in der Informatik ist die Fähigkeit eines Sys-tems, eine Aufgabe in einer bestimmten Zeit zu erledigen. Die Einheit fürPerformance ist daher immer Aufgabe pro Zeit, zum Beispiel FLOPS (Float-ing-Point Operations Per Second) oder SAPS (SAP Application PerformanceStandard). 100 SAPS sind definiert als 2.000 vollständig bearbeitete Auftrags-positionen pro Stunde, das heißt, technisch 6.000 Dialogschritte und 2.000Verbuchungen.

Am häufigsten besteht die Aufgabe allerdings darin, eine Menge an Daten zuübertragen, sodass die Einheit dann als Menge pro Zeit beschrieben werdenkann. Die Standardisierung der Einheiten ist nötig, um die verschiedenenSysteme respektive deren Performance miteinander vergleichen zu können.Dieses Vergleichen anhand von definierten und reproduzierbaren Leistun-gen nennt man Benchmarking.

In der wirklichen Welt aber entscheidet der Benutzer, ob die Performanceeines Systems gut oder schlecht ist, sie wird also subjektiv wahrgenommen.Ein Benutzer erkennt nicht zwangsläufig den Umfang einer Aufgabe, die einSystem abarbeiten muss. Eine gute Performance ist daher einerseits eineabsolute Eigenschaft im Vergleich zwischen Systemen, anderseits aber immerrelativ zu den Anforderungen zu sehen. In diesem Bereich spielen auch sozi-ologische Faktoren eine Rolle: Für den Anwender im Unternehmen sind fünfSekunden Wartezeit bei einer Data-Warehouse-Anfrage kein Problem,wohingegen der Kunde im Webshop diese Geduld eventuell nicht aufbringt.

Ziel des Systemadministrators muss es daher sein, die unterschiedlichenAnforderungen an die Performance zu erfüllen, damit die Anwender ein Sys-tem effizient nutzen können.

Performanceoptimierung ist ein Teil des Lebenszyklus jedes Systems und fin-det sich in den Schritten Implementierung, Betrieb und Revision wieder. InAbbildung 8.1 sehen Sie einen Lebenszyklus mit seinen Phasen.


Performance8

440

Abbildung 8.1 Systemlebenszyklus und Optimierungszyklen

Die Optimierung selbst unterteilt sich wiederum in die Phasen Analyse,Umsetzung und Verifizierung. Im Grunde gibt es jedoch zwei unterschiedli-che Optimierungskreisläufe. Der erste, »kleine« Kreislauf findet komplett inder Lebenszyklusphase Betrieb statt. Hier werden Performanceoptimierun-gen vorgenommen, die die Verfügbarkeit des Systems nicht oder nur kurz-zeitig beeinflussen. Beispiele hierfür sind zum einen SAP-Kernel-Parameterfür Speicherbereiche oder Workprozesse und zum anderen die Parameterder Oracle-Datenbank, die sich zum Teil sogar dynamisch zur Laufzeitändern lassen.

Der »große« Kreislauf erstreckt sich über die Lebenszyklusphasen Implemen-tierung, Betrieb und Revision. Optimierungen, die einen größeren Zeitauf-wand erfordern, weil sie zum Beispiel Tests beinhalten oder den Systembe-trieb stark beeinflussen, sind in diesem größeren Kontext vorzunehmen.Änderungen am Code von Anwendungen oder umfangreiche Datenbankre-organisationen fallen ebenfalls in diesen Bereich.

In diesem Kapitel beschreiben wir die Phasen Analyse, Umsetzung und Verifi-zierung: Welche Analysen können bei einer Kombination von SAP mit einerOracle-Datenbank ausgeführt werden, und wie fließen die entsprechendenKonsequenzen in eine Umsetzung ein? Dazu werden wir die Probleme zuerstkategorisieren.

Planung

Implementierung

Betrieb

Revision

Umsetzung

Analyse Verifizierung

Umsetzung

Verifizierung

Analyse

„großer“ Optimierungskreislauf

„kleiner“ Optimierungskreislauf

Systemlebenszyklus


Administrative und programmatische Probleme 8.1

441

8.1 Administrative und programmatische Probleme

Für Performanceprobleme gibt es drei Quellen: programmatische, adminis-trative und benutzerspezifische.

Liegt der Grund für Performanceprobleme im Code einer Anwendung, sospricht man von einer programmatischen Ursache. Beispiele für schlecht pro-grammierte Software findet man leider nur zu oft, denn es gibt ein ganzeReihe von Fehlertypen bei der Programmierung – Memory Leaks oder inef-fiziente Algorithmen, um nur einige zu nennen. Kommt zusätzlich noch eineDatenbank ins Spiel, erweitert sich der Fehlerbereich um die SQL-State-ments, die zur Interaktion benötigt werden. Mit dem Bereich der program-matischen Performanceprobleme befassen wir uns in Abschnitt 8.3, Analyseprogrammatischer Performanceprobleme.

Von administrativen Performanceproblemen spricht man, wenn die Ursa-chen in der Konfiguration von Hardware und Software liegen. Das entspre-chende Feld ist weit und reicht von falschem Disk-Layout über ungenügendeSpeicherparameter der Datenbank und des SAP-Systems bis hin zur Vergabevon inkorrekten Berechtigungen. Die Wege zur Analyse und Behebung die-ser Probleme werden in Abschnitt 8.2, Analyse administrativer Performance-probleme, behandelt.

Die dritte mögliche Quelle für ein Performanceproblem ist das Benutzerver-halten, es handelt sich also um benutzerspezifische Ursachen. Hier stellt sichdie problematische Frage: Wer ist schuld? Der Benutzer, der beispielsweiseungewöhnlich aufwendige Anfragen stellt und damit die Performance desSystems verschlechtert, oder der Programmierer beziehungsweise Administ-rator, der verschiedene Arten von »Extremnutzung« nicht unterbindet,indem er zum Beispiel Eingabefeder wertebeschränkt oder auf Plausibilitätprüft? In diesem Buch werden wir nicht weiter auf benutzerspezifische Per-formanceprobleme eingehen. Die Lösung für derartige Probleme liegt nichtin der Administration von SAP und Oracle-Datenbank, sondern in derAnwendungsentwicklung beziehungsweise in der Verwaltung der Benutzer-rechte.

Neben den Problemursachen ist die Problemlokalität der zweite Baustein zurProblemanalyse. Lokalität heißt: Wo tritt das Performanceproblem auf? Umdies zu spezifizieren, bedarf es zunächst der Zerlegung eines Systems in seineKomponenten. Ein SAP-System besteht aus Sicht einer Performanceanalyseaus folgenden Komponenten:


Performance8

442

1. Hardware

2. Betriebssystem

3. Datenbank

4. SAP-Basis (das heißt, SAP-Kernel + SAP-Basis = SAP NetWeaver Applica-tion Server)

5. SAP-Anwendung

Aus der Kombination von Ursache und Lokalität ergibt sich die Übersicht ausTabelle 8.1 für die Zuordnung von Performanceproblemen. In diesem Kapi-tel konzentrieren wir uns jedoch nur auf die für den Leser relevanten Pro-blempunkte bei Oracle und SAP.

Wir setzen dieses Kapitel in zwei Teilen fort. Zuerst gehen wir in Abschnitt8.2, Analyse administrativer Performanceprobleme, auf eben diese ein undzwar für alle Bereiche, also Hardware, Betriebssystem, Oracle-Datenbankund SAP-System, dem Fokus des Buches entsprechend natürlich mit größe-rem Augenmerk auf Oracle und SAP-System. Anschließend befassen wir unsin Abschnitt 8.3, Analyse programmatischer Performanceprobleme, näher mit

Ursache\Lokalität Programmatisch Administrativ

Hardware Fehler in der Firmware Auswahl ungeeigneter Kompo-nenten, zum Beispiel langsame Festplatten oder Speicher

Betriebssystem � Ineffiziente Speicherverwal-tung durch Betriebssystem-Kernel

� Nicht optimierte Gerätetrei-ber

� Inkorrekte Parametrisierung des Betriebssystem-Kernels

� Disk-Layout nicht geeignet für massive I/O-Operationen

Datenbank � Nutzung von »expensive« SQL-Statements

� Schlechte Indizierung

� Unzureichende Parametrisie-rung

� Ineffiziente Tablespace-Struk-turen, zum Beispiel durch zu viele Extents

SAP-Basis Fehler im ABAP-Code für Basis-funktionen wie zum Beispiel in Kommunikationsbausteinen

� Ineffiziente Puffergrößen

� Falsche Parameter für den SAP-Kernel

Anwendung � Fehlerhafte Nutzung von SAP-Standardfunktionen bei Eigen-entwicklungen

� Bugs im SAP-Standard

keine

Tabelle 8.1 Übersicht mit Beispielen für Probleme der Performanceoptimierung


Analyse administrativer Performanceprobleme 8.2

443

den programmatischen Themen, folglich zum Beispiel mit teuren SQL-State-ments, mit der Indizierung und (ein wenig) mit der ABAP-Programmierung.

8.2 Analyse administrativer Performanceprobleme

Für die Analyse von Performanceproblemen eignen sich zwei Einstiegs-punkte, die allgemeine Analyse des Systemzustandes beziehungsweise derKomponenten und die Workload-Analyse. Die Analyse der Komponenten,oder auch Systemanalyse, bezieht sich auf den Zustand, das heißt, die Konfi-guration und die Auslastung der Systemkomponenten Hardware, Betriebs-system, Datenbank und SAP-Basis. Die wichtigsten Kennzahlen bei dieserAnalyse sind Füllstände, Trefferraten (Hitratio), Statistiken über Fehler etc.Entsprechend werden in diesem Abschnitt die Möglichkeiten zur Untersu-chung der Komponenten aufgezeigt und Hinweise zur Behebung sowie Ori-entierungswerte für die Konfiguration gegeben.

Die SAP-Workload-Analyse arbeitet mit den im System gesammelten Zeitenfür die einzelnen Verarbeitungsabschnitte eines Dialogschrittes (Roll-in/-out,Datenbankzeit, CPU-Zeit etc.). Mit ihr werden demnach nicht die Kompo-nenten des Systems, sondern deren Zusammenarbeit untersucht. Die ent-scheidende Kennzahl ist hier natülich immer die Zeit.

Erfahrungsgemäß eignet sich der Einstieg über die Workload-Analyse immerdann, wenn einzelne Benutzer über Performanceprobleme klagen oder dasProblem nur zu bestimmten Zeitpunkten auftritt. Ist die Performance allge-mein schlecht oder wird eine regelmäßige Systemanalyse durchgeführt, istder Start über die allgemeine Komponentenanalyse vorzuziehen. Zur voll-ständigen Analyse der Performance eines Systems sind natürlich beideAnsätze in Kombination erforderlich.

Die SAP-Workload-Analyse werden wir hier nicht behandeln, da dies zumeinen den Rahmen dieses Kapitels sprengen würde, und es zum anderenbereits hervorragende Literatur hierzu gibt, zum Beispiel: SAP-Performanceop-timierung von Thomas Schneider (SAP PRESS 2005).

Im Bereich der Oracle-Datenbank gibt es eine artverwandte Analysemöglich-keit: die Wait-Event-Analyse. Auch hier wird, wie der Name schon sagt, überdie verschiedenen Wartezeiten einer Transaktion innerhalb der Datenbankder Ablauf eben jener Transaktion analysiert. Mehr zur Wait-Event-Analysefinden Sie in Abschnitt 8.2.2, Analyse der Datenbank.


Performance8

444

8.2.1 Analyse von Hardware und Betriebssystem

Bei der Analyse der Komponenten Hardware und Betriebssystem kann manaus Sicht des SAP-Basis-Administrators keine »saubere« Trennung vollzie-hen, da die Möglichkeiten der SAP-Basis dies nicht zulassen. Eine solcheTrennung ist allerdings auch nicht notwendig, da Hardware und Betriebssys-tem gemeinsam die Grundlage für SAP-System und Datenbank sind unddaher zusammen betrachtet werden können. Wird ein Performanceproblembei der Hardware oder im Betriebssystem entdeckt, ist der Systemadminist-rator oder der Hardwarepartner häufig an der Lösung beteiligt, da der SAP-Administrator in der Regel keinen Zugriff auf Betriebssystemebene hat oderihm die entsprechend detaillierten Kenntnisse fehlen.

Alle Daten, die im SAP-System zur Analyse von Hardware und Betriebssys-tem vorliegen, werden vom SAP OS Collector (SAPOSCOL) gesammelt, der einevon Hardware und Betriebssystem abhängige Komponente des SAP-Kernelsist. Ein Hintergrundjob (SAP_COLLECTOR_FOR_PERFORMANCE) liest die Datenaus und schreibt sie in die Performancedatenbank des SAP-Systems (TabelleMONI).

Der Einstieg in die Analyse erfolgt über den Betriebssystemmonitor, der mitden Informationen aus der Performancedatenbank arbeitet oder den SAPOS-COL direkt abfragt. Die Transaktion ST06 startet den OS-Monitor für dielokale Instanz des Systems. Bei einem System mit mehreren Instanzen aufverschiedenen Servern wird über die Transaktion OS07 auf den entspre-chenden Betriebssystemmonitor einer auf einem anderen Server installier-ten Instanz verzweigt.

Grundsätzlich gibt es vier Schwerpunkte für die Performanceuntersuchun-gen von Hardware und Betriebssystem: CPU, Speicherbedarf, I/O-Last undNetzwerk. Alle Daten für diese Komponenten werden vom SAP OS Collectorgesammelt und mithilfe eines Batch-Jobs in der SAP-Datenbank gespeichert.Damit ist sowohl der Zugriff auf aktuelle Daten als auch auf eine Historiemöglich. Abbildung 8.2 zeigt den Betriebssystemmonitor einer SAP-Instanz.

Tabelle 8.2 gibt Aufschluss über die Bedeutung der wichtigsten Kennzahlenim Betriebssystemmonitor und nennt, wenn möglich beziehungsweise sinn-voll, kritische Grenzwerte für die Performance.



445

Abbildung 8.2 Betriebssystemmonitor (ST06 oder OS07)

Feld Bedeutung Kritischer Wert

Utilization user CPU-Last durch Benutzerpro-zesse inklusive SAP-System und Datenbank

Σ > 80% (Ø pro h)

Utilization system CPU-Last durch den Betriebs-system-Kernel

Utilization idle CPU-Leerlauf < 20% (Ø pro h)

Utilization i/o wait CPU-Last durch Warten auf I/O-Operationen

> 40% (Ø pro h)

Count Anzahl der CPUs –

Load average Anzahl der Prozesse, die auf eine CPU warten

> 3,0 (bestimmte OS, zum Beispiel Solaris, zählen auch die aktiven Pro-zesse, dann > 3 + Anzahl der CPUs)

Phy. mem avail Gesamter Hauptspeicher des Servers

–

Tabelle 8.2 Überblick über Betriebssystemmonitor


Performance8

446

Die kritischen Werte sind nicht als absolut anzusehen, sondern dienen alsIndikatoren für Probleme. Wird einer dieser Werte übertroffen beziehungs-weise unterschritten, so sollten Sie weiter nachforschen. 1

8.2.1.1 Richtwerte für die Hardwarekomponenten

Bei einer CPU-Auslastung von mehr als 80% im Stundenmittel (also idle + i/owait < 20%) spricht man von einem CPU-Engpass. Von vielen Hardwarepart-nern wird allerdings für Produktivsysteme eine maximale Auslastung von 60bis 70% empfohlen, um genügend Reserven für Lastspitzen zu haben. Aller-dings muss man beachten, dass die CPU-Werte in der Transaktion ST06 überalle CPUs des Servers gemittelt sind, das heißt, eine Zwei-CPU-Maschine mit

Phy. mem free Freier Hauptspeicher des Ser-vers

< 3% Phy. mem avail (außer AIX, dort wird das freie RAM als Datei-Cache genutzt)

Pages in/out Anzahl der ein- und ausgela-gerten Speicherseiten zwi-schen RAM und Swap

Windows: Kb-in × 3600 > 20% RAM

UNIX: Kb-out × 3600 > 5% RAM1

Kb in/out Größe der ein- und ausgela-gerten Speicherseiten zwi-schen RAM und Swap

–

Swap-space (Free, Maximum, Actual)

Anzeige ist betriebssystem-abhängig (SAP-Hinweis 63906)

–

Disk Festplatte mit der aktuell höchsten Response-Zeit (bes-ser Button Detail analyses menu � Disk

Utilization > 50% (Ø pro h)

Packets in/out Anzahl der gesendeten und empfangenen Netzwerkpa-kete (Σ aller Netz-Interfaces)

–

Errors in/out Fehler beim Senden und Emp-fangen von Netzwerkpaketen (Σ aller Netz-Interfaces)

Sollten beim Stand der Technik eigentlich nie mehr auftreten, daher im Fall von > 0 zu überprüfen

Collision Kollisionen im Netzwerk

1 5% können auch schon schlecht sein, wenn das RAM > 8 GB oder die I/O zum Swap-Spei-cher langsam ist, zum Beispiel durch ein Software-RAID.

Feld Bedeutung Kritischer Wert

Tabelle 8.2 Überblick über Betriebssystemmonitor (Forts.)



447

70% Auslastung hat absolut gesehen weniger Reserven als eine Acht-CPU-Maschine mit 80% Auslastung (bei gleicher CPU-Leistung).

Für die Größe des Swap-Speichers gibt es verschiedene Angaben. SAP emp-fiehlt dreimal so viel Swap-Speicher wie physikalischen Hauptspeicher, abermindestens 3,5 GB. Unrealistisch wird diese Empfehlung bei Systemen miteinem großen Hauptspeicher von mehr als 64 GB. Hier wird es schwierig,die entsprechende Menge an Swap-Speicher auf den lokalen Platten unterzu-bringen. Allerdings bieten die Betriebssysteme meist eine entsprechendeLösung an, wie beispielsweise die Nutzung von Pseudo-Swap bei HP-UX.

Das Paging, also das Auslagern von Speicherseiten aus dem Hauptspeicher indie Swap-Partition oder die Swap-Datei auf der Festplatte, ist grundsätzlichkritisch zu betrachten. Der Swap-Speicher ist schlicht eine Nothilfe desBetriebssystems, um erstens mehr Prozesse starten zu können, als dafürHauptspeicher vorhanden ist, und zweitens, um zu verhindern, dass bei star-ker Speicherbelastung ein Prozess abbricht. Man muss sich beim Pagingimmer vor Augen halten, dass der Faktor für den Unterschied bei derZugriffsgeschwindigkeit zwischen Festplatte und RAM theoretisch bei ca.500.000 liegt (acht Millisekunden Positionierung des Festplattenkopfs – 15Nanosekunden Latenzzeit für den Speicherzugriff). Dies sind zwar theoreti-sche Werte, die sich durch verschiedene Hardwaretechniken wie Festplat-ten-Arrays oder parallelen Speicherzugriff stark ändern lassen, allerdingsbleibt ein Unterschied in nicht zu vernachlässigenden Größenordungen.

Die allgemeine Empfehlung ist, dass im höchsten Fall nicht mehr als fünfProzent des Hauptspeichers in einer Stunde ausgelagert werden sollten. Ambesten ist es jedoch, Paging komplett zu vermeiden und den Hauptspeicherentsprechend zu dimensionieren. Grundsätzlich sollten Sie bei der Planungder Hardwareressourcen als Letztes beim Hauptspeicher sparen.

Die dritte Komponente ist die I/O-Last. Im Betriebssystemmonitor sehen Sienach einem Doppelklick auf die aktuelle Disk with highest response timeeine Liste aller Festplatten des Systems mit deren aktuellem Status. Wenneine Festplatte hier mit Utilization 100% auftaucht, muss noch nicht zwangs-läufig ein Engpass vorliegen. Vielmehr sollte im Stundenmittel keine Utiliza-tion von mehr als 50% vorliegen. Die Historie der I/O-Last der einzelnenFestplatten findet sich unter Detail Analyse Menu � Disk.

Das Netzwerk lässt sich aus dem SAP-System heraus mit einem einfachenPing-Test prüfen. Ein Problem ist, dass dieser LAN-Test der Präsentationsser-ver (SAP GUI) nur funktioniert, wenn diese nicht über einen SAProuter auf


Performance8

448

das System zugreifen. Eine zweite und deutlich bessere Möglichkeit zurUntersuchung des Netzwerkes ist die Nutzung des Programms niping, dasSie aus der Transaktion SM49 heraus als externes Betriebssystemkommandoaufrufen können. Eine genaue Anleitung zum Einsatz von niping finden Siein SAP-Hinweis 500235.

Der Betriebssystemmonitor zeigt die Anzahl der empfangenen Netzwerkpa-kete pro Sekunde an und fasst diese in einer stundenbasierten Historiezusammen. Kritische Punkte sind die gesendeten Fehler und Kollisionen imZeitraum von einer Stunde. Bei den heutigen modernen Netzwerkstrukturenim LAN ist hier alles größer 0 verdächtig und sollte gemeinsam mit demNetzwerkadministrator untersucht werden (lassen Sie sich nicht abwim-meln!).

8.2.1.2 Identifizierung der Ursachen bei den Hardwarekomponenten

Ist ein Engpass bei CPU, Hauptspeicher oder I/O festgestellt, folgt im zweitenSchritt die Ermittlung des Verursachers.

Für die CPU-Auslastung sind natürlich die Prozesse auf der Ebene desBetriebssystems zuständig. In der Transaktion ST06 finden sich unter DetailAnalyse Menu � Top CPU die aktuellen Prozesse des Servers in der Reihen-folge ihrer CPU-Nutzung. Die angezeigte prozentuale CPU-Auslastung einesProzesses bezieht sich immer auf eine CPU des Systems, das heißt, bei einemMehrprozessorsystem (n CPUs) ist die maximale Auslastung n × 100%.Wenn es möglich ist, können natürlich auch analog die Bordmittel desBetriebssystems genutzt werden, zum Beispiel »top« unter den verschiede-nen UNIX-Derivaten.

Das weitere Vorgehen hängt nun von den als CPU-Verbraucher identifiziertenProzessen ab. SAP-Workprozesse erkennt man am Benutzer <SID>adm undam Prozessnamen dw.sap<instance> (UNIX) beziehungsweise Disp+Work(Windows). Sind dies die Prozesse, die die CPU-Last erzeugen, so ist dernächste Schritt deren Analyse über die SAP-Prozessübersicht (TransaktionSM50, siehe Abschnitt 8.2.3, Analyse des SAP-Systems). Die Identifizierungeinzelner Prozesse erfolgt über die Prozess-ID (PID), die sowohl im Betriebs-systemmonitor als auch bei der SAP-Prozessübersicht angezeigt wird.

Die Oracle-Prozesse laufen in der Regel unter dem Benutzer ora<SID>(UNIX) beziehungsweise SAPService<SID> (Windows) und tragen dieBezeichnung oracle<SID> (Shadow-Prozesse) oder ora_<Prozess>_<SID>(Oracle-Systemprozess). Verbraucht einer der Oracle-Prozesse unverhältnis-



449

mäßig viel CPU-Kapazität, so erfolgt die weitere Analyse über den Daten-bankprozessmonitor (Transaktion ST04N, siehe Abschnitt 8.2.2, Analyse derDatenbank). Ein hoher CPU-Verbrauch durch die Oracle-Prozesse kann ver-schiedene Ursachen haben – beachten Sie dazu den SAP-Hinweis 712624.

Verursacht ein externer Prozess die CPU-Last, so ist dieser in Zusammenar-beit mit dem Betriebssystemadministrator zu analysieren und der Engpass zubeseitigen.

Die Analyse des Hauptspeicherverbrauchs durch die Prozesse ist deutlichkomplizierter als die der CPU-Auslastung. Der Grund liegt zum einen in denverschiedenen Arten, wie der Hauptspeicher genutzt wird, zum Beispiel alslokaler Prozessspeicher oder als Shared Memory, und zum anderen amunterschiedlichen Memory Management der einzelnen Betriebssysteme.

Bei der Verwaltung von Swap und Hauptspeicher gibt es bedeutende Unter-schiede nicht nur zwischen der Windows- und der UNIX-Welt, sondern auchzwischen den verschiedenen UNIX-Derivaten. Grundsätzlich ist für einegenaue Analyse eine tief gehende Kenntnis des Betriebssystems nötig.

Mit den Mitteln des Betriebssystems ist erst einmal festzustellen, ob derHauptspeicherverbrauch durch das SAP-System beziehungsweise die Oracle-Datenbank oder durch andere Prozesse verursacht wird. Beliebtes Beispiel füreinen hohen externen, folglich nicht von SAP oder Oracle verursachten Spei-cherverbrauch ist der File System Cache, der einen bestimmten Prozentsatzdes Hauptspeichers als Puffer für den Dateizugriff reserviert. Die maximal zuempfehlende Größe hängt davon ab, ob auf dem Server auch die Oracle-Instanz oder nur eine SAP-Instanz installiert ist. Oracle empfiehlt grundsätz-lich die Deaktivierung jeglicher I/O-Puffer für den Zugriff auf die Datenbank-dateien, da der Zugriff auf die Datenbankblöcke dann nicht doppelt vom FileSystem Cache und vom SGA-Speicher gepuffert wird. Stattdessen sollte derSpeicher komplett dem auf Oracle optimierten SGA-Puffer spendiert werden.Bei der Verwendung von Raw Devices entfällt der File System Cache. Beieinem Server mit SAP-Instanz sollte der Cache nicht größer als acht bis zehnProzent des Hauptspeichers sein, maximal jedoch ein Gigabyte. Eine Aus-

Wichtiger Hinweis

Dieses Buch bezieht sich hauptsächlich auf den Application Server der SAP-Releases 6.40 und 7.00. Die Transaktion ST04N, die im Folgenden noch oftgenannt wird, existiert im kommenden Release 7.10 nicht mehr. Dort heißt siewieder ST04! Außerdem gibt es ab Release 7.00 die Transaktion DBACOCKPIT fürOracle.


Performance8

450

nahme bildet hier, wie in Tabelle 8.2 angedeutet, das Betriebssystem AIX,denn hier wird der Einsatz des Hauptspeichers als File System Cache explizitempfohlen (siehe SAP-Hinweis 973227). Weitere Informationen zu den ver-schiedenen I/O-Arten finden Sie in Abschnitt 8.2.2.

Liegt der Speicherverbrauch »innerhalb« des SAP-Systems, also bei den SAP-Workprozessen, folgt eine weitere Analyse der SAP-Speicherbereiche, wobeinatürlich festzuhalten ist, dass das SAP-System den Hauptspeicher nur ent-sprechend den relevanten Instanzparametern allokieren kann (sieheAbschnitt 8.2.3). Analog ist der Speicherverbrauch der Oracle-Datenbank zuanalysieren (siehe Abschnitt 8.2.2).

Für eine hohe I/O-Last gibt es drei mögliche Ursachen: massives Paging imSwap-Bereich, hohe Belastung der Datenbank oder ein externes Programm.Wenn Sie im Betriebssystemmonitor eine hohe Paging-Rate feststellen, kannmit der Disk-Analyse (ST06 � Detail Analyse Menu � Disk) verifiziert werden,ob die Festplatte, auf der sich der Swap-Bereich befindet, stark belastet ist.Ist das der Fall, löst sich mit der Behebung des Paging-Problems auch dasProblem der I/O-Last. Da der Swap-Bereich jedoch niemals auf derselbenFestplatte wie die Datenbank liegt, treten in der Regel bei einem durchPaging verursachten I/O-Problem keine Rückkopplungen auf die I/O-Perfor-mance der Datenbank auf.

Tritt die hohe Disk-Belastung dort auf, wo die Datenbank installiert ist, sosind entsprechend weitergehende Analyseschritte nötig (siehe Abschnitt8.2.2).

Probleme mit der Kommunikationshardware können theoretisch bei dreiVerbindungen auftreten:

� SAP-Instanz – SAP GUI

� SAP-Instanz – Oracle-Datenbankserver

� SAP-Instanz – angebundene Systeme

Besonders bandbreitenintensiv ist die Verbindung zum Datenbankserverund eventuell zum angebundenen Fremdsystem, zum Beispiel als Daten-quelle in SAP NetWeaver BI. Hier gibt es von SAP eine Installationsvorgabe,die besagt, dass sich SAP-Instanz und Datenbankserver zusammen in einem100-MBit-LAN befinden müssen. Wenn eine Überlastung des Netzwerks auf-tritt, so ist dies im SAP-System nur durch Indizien wie Kollisionen und langeLaufzeiten im LAN sichtbar. Der SAP-Systemadministrator kann mithilfe vonniping weitere Untersuchungen durchführen. Für eine genaue Analyse und



451

die Identifizierung eines Verursachers sind externe Netzwerk-Tools und dieentsprechenden Kenntnisse eines Netzwerkadministrators erforderlich.

8.2.2 Analyse der Datenbank

Die Datenbank ist das Herzstück des SAP-Systems, daher ist die Performanceder Datenbank entscheidend für die Performance des gesamten Systems.

Die Analyse erstreckt sich über folgende Teilbereiche, die alle performan-cerelevant sind:

� PufferDie Pufferbereiche der Oracle-Datenbank speichern Informationen, dieöfter benötigt werden, im Hauptspeicher des Servers ab, um einenwesentlich schnelleren Zugriff als über den Festplattenspeicher zu gewäh-ren.

� Wait EventDie Analyse von Wait Events zeigt auf, wann und vor allem worauf dieDatenbank bei der Abarbeitung eines Requests warten muss. Hieraus las-sen sich relativ einfach Engpässe der Datenbank erkennen.

� Allgemeine ParametrisierungAußer den Pufferparametern gibt es noch viele weitere Oracle-Parameter,die performancerelevant sind. Auch diese müssen in eine vollständigeAnalyse einbezogen werden.

� StatistikenDer Oracle Cost-Based Optimizer (CBO) berechnet die Kosten für die mög-lichen Zugriffspfade (zum Beispiel Full Scan, Index Range Scan), um denschnellstmöglichen Zugriffsweg zu bestimmen.

� I/ODas Einlesen und Schreiben von Datenblöcken ist die Aufgabe einerDatenbank, daher ist ein möglichst optimaler I/O unerlässlich für die Per-formance eines SAP-Systems.

� SQL-AnalyseDie Qualität von SQL-Abfragen hat erheblichen Einfluss auf die Geschwin-digkeit der Datenbank. Daher stellt die Identifizierung und Verbesserungvon schlechten SQL-Abfragen eine wichtige Aufgabe der Performanceop-timierung dar.

Wann macht eine Analyse der Datenbank Sinn? Der beste Indikator ist derAnteil an der Gesamtantwortzeit eines SAP-Systems, der auf die Datenbank


Performance8

452

entfällt. Dieser wird in der Regel mit einer Workload-Analyse ermittelt undsollte in der Regel 40% nicht überschreiten. Ein weiterer Hinweis ergibt sichaus dem Verhältnis von Busy wait time zu CPU time (Transaktion ST04N, sieheauch Abbildung 8.4), das bei ca. 60:40 liegen sollte. Liegt die Busy wait timedeutlich höher, eröffnet sich die Möglichkeit einer Wait-Event-Analyse (sieheAbschnitt 8.2.2.2, Analyse von Wait Events), wohingegen eine erhöhte CPUtime auf einen Ressourcenengpass bei der CPU hinweist. Noch einen Hinweisezur Busy wait time: Unter Umständen bezieht ST04 auch Idle Wait Events indie Busy wait time mit ein. Deshalb sollten Sie die Korrektheit der Busy waittime am besten durch die Daten aus View V$SYSTEM_EVENT überprüfen.

Grundlegende Voraussetzung der Analyse der Oracle-Performancedaten ist,dass der Parameter TIMED_STATISTICS auf TRUE gesetzt ist. Dies ist nach einerSAP-Standardinstallation allerdings bereits der Fall. Anderenfalls können Siediesen Parameter als Datenbankbenutzer SYS (Anmeldung über sysdba)dynamisch setzen:

f05:oram05 1>sqlplus "/as sysdba"SQL> alter system set TIMED_STATISTICS = TRUE;

8.2.2.1 Analyse der Datenbankpuffer

Zwei Faktoren bestimmen die Qualität eines Puffers. Zum einen die logi-schen Zugriffe (Logical Read), unter denen man alle Zugriffe auf einen Blockversteht, und zum anderen die physikalischen Zugriffe, die alle Zugriffe aufeinen Block auf der Festplatte ausdrücken (Physical Read). Abbildung 8.3 ver-anschaulicht den Zusammenhang.

Aus diesen Faktoren ergibt sich die Qualität des Puffers über folgende For-mel:

Qualität (Hitratio) = Anzahl der Treffer/Anzahl der Abfragen × 100%

Grundsätzlich ist für alle Puffer zu beachten, dass sie nach einem Systemstartneu initialisiert werden und somit ohne Aussagekraft sind. Für eine Analysevon Puffern ist es daher notwendig, dass sich das System in einem einge-schwungenen Zustand befindet. In der Regel kann man davon ausgehen, dassdies nach ein bis zwei Tagen im operativen Betrieb der Fall ist. Als weitererRichtwert für einen eingeschwungenen Zustand gilt die Anzahl der LogicalReads auf den Buffer Cache der Datenbank. Dieser sollte größer als50.000.000 sein.



453

Abbildung 8.3 Zugriffe auf Puffer und Datenbank

Die Datenbankpuffer der Oracle-Datenbank befinden sich in der System Glo-bal Area (SGA). Eine detaillierte Beschreibung der einzelnen Pufferbereicheund ihrer Aufgaben finden Sie in Kapitel 3, Grundwissen Oracle.

Die wichtigsten Puffer in der SGA der Oracle-Datenbank finden Sie noch ein-mal zur Übersicht in der folgenden Tabelle 8.3:

SGA-Puffer Bedeutung

Data Buffer Enthält die gepufferten Datenblöcke aus den Datendateien der Fest-platte. Parameter: DB_CACHE_SIZE

Shared Pool Die zwei wichtigsten Sub-Caches Data Dictionary Cache und Library Cache. Parameter: SHARED_POOL_SIZE

Java Pool Wird von der Oracle JVM genutzt, aber nicht von SAP. Parameter: JAVA_POOL_SIZE

Large Pool Puffer für spezielle Daten (zum Beispiel als Message-Puffer für Prozesse, die parallele Abfragen ausführen). Er ist sehr klein und wird unter SAP kaum verwendet. Parameter: LARGE_POOL_SIZE

Tabelle 8.3 Überblick über SGA-Puffer

Datenbankinstanz (Schattenprozess) buffer hit

buffer get

Datenbank-Interface im SAP-

Workprozess

SGAData Buffer

Datendateien

Logi

cal R

ead

Phy

sica

l Rea

d


Performance8

454

Seit der Oracle-Version 9i können die wichtigsten Parameter (DB_CACHE_SIZEund SHARED_POOL_SIZE) der SGA zur Laufzeit der Oracle-Instanz vom Admi-nistrator geändert werden. Dieses Feature wird als dynamische SGA bezeich-net und darf nicht mit dem Automatic Shared Memory Management (ASMM)verwechselt werden. Die alten Parameter aus Oracle 8.1.x für den Data Buf-fer (DB_BLOCK_BUFFERS) dürfen dann nicht mehr genutzt werden. Der Einsatzder dynamischen SGA ist von SAP grundsätzlich freigegeben, und bei SAP-Installationen mit der SAP-Basis 6.40 wird sie per Default aktiviert.

Ab Oracle 10g gibt es die Möglichkeit, die Verwaltung der SGA komplett zuautomatisieren. Die einzelnen Bereiche DB_CACHE_SIZE, SHARED_POOL_SIZE,JAVA_POOL_SIZE, LARGE_POOL_SIZE und STREAMS_POOL_SIZE werden dannvon Oracle an die aktuellen Bedürfnisse angepasst. Der Parameter SGA_TAR-GET gibt die Gesamtgröße der SGA vor und aktiviert das Automatic SharedMemory Management (ASMM). Sind die Parameter DB_CACHE_SIZE undSHARED_POOL_SIZE dann noch gesetzt, geben sie die Untergrenzen für denjeweiligen Pufferbereich vor. Aufgrund der geringen Erfahrung mit ASMMwird der Einsatz bei einem SAP-System bisher nicht empfohlen. Dennochbietet es sich an, diesen Parameter in nicht produktiven Umgebungen zunutzen, um den Administrationsaufwand zu minimieren, allerdings natür-lich nur, wenn das System nicht als Abbild des Produktivsystems für Testsvorgesehen ist.

Der Zugriff auf die Analyseinformationen im SAP-System erfolgt über denOracle-Datenbankmonitor (Transaktion ST04N). Hier finden Sie alle Infor-mationen zur Oracle-Datenbank, die vom SAP-System aus zugänglich sind.Die Informationen des Datenbankmonitors kommen aus der Oracle-Daten-bank selbst, das heißt, aus den V$-Views. Abbildung 8.4 zeigt die Einstiegs-seite des Datenbankmonitors.

Tabelle 8.4 gibt Aufschluss über die Bedeutung der wichtigsten Kennzahlenim Oracle-Datenbankmonitor und nennt Empfehlungen für deren optimalenZustand nach der Einschwingphase der Datenbank.

Streams Pool Neuer Pufferbereich in Oracle 10g für Oracle Stream, der Daten und Events in verteilten Umgebungen verwaltet – wird vom SAP-System nicht genutzt. Parameter: STREAMS_POOL_SIZE

Redo Buffer Puffer für die Redo-Log-Daten. Parameter: LOG_BUFFER

SGA-Puffer Bedeutung

Tabelle 8.3 Überblick über SGA-Puffer (Forts.)



455

Abbildung 8.4 Oracle-Datenbankmonitor – Main View

Puffer/Merkmal

Bedeutung Empfeh-lung

Data Buffer Hauptdatenbankpuffer für die Datenblöcke (Achtung: Die Empfehlung ist sehr pauschal, denn hier gibt es Extremfälle in beide Richtungen, das heißt, es gibt Systeme, die mit 80% gut laufen und Systeme, die mit 98% große Probleme haben.)

> 94%

DD-Cache Data Dictionary Buffer enthält Metadaten über die Datenbank (Strukturen, Benutzer, Berechtigungen)

> 80%

SQL-Area Get Ratio

SQL-Cache speichert den Parse-Tree und Ausführungsplan von gelaufenen SQL-StatementsGet Ratio = Σ (Treffer)/Σ (Anfrage) x 100

> 95%

Tabelle 8.4 Bedeutung der wichtigsten Merkmale des Oracle-Datenbankmonitors


Performance8

456

Grundsätzlich sind die Empfehlungen für die einzelnen Puffer und Merk-male nur Richtwerte. Die Werte können unter Umständen deutlich abwei-chen, ohne dass das SAP-System inperformant ist. Ein Schulungssystem bei-spielsweise hat bei Weitem nicht die Benutzerlast wie ein Produktivsystem,sodass hier im System die Last, die durch die administrativen Aufgabenerzeugt wird, deutlich überwiegt. Da diese Aktivitäten, wie zum Beispiel dieSAP-Standard-Hintergrundjobs und die Erstellung der Datenbankstatistiken,deutlich andere Lastschwerpunkte setzen, verschieben sich die einzelnenPerformancemerkmale deutlich. Ein Verhältnis User calls/Recursive calls< 0,5 ist hier zum Beispiel nicht ungewöhnlich.

Im Folgenden wollen wir die im SAP-Umfeld relevanten Oracle-Puffer hin-sichtlich der Performance näher betrachten.

Der Data Buffer für die eigentlichen Datenblöcke der Datenbank hat ohneZweifel den größten Einfluss auf die Performance, da er die Masse an physi-kalischen Plattenzugriffen verhindern kann.

Die Logical Reads sind alle lesenden Anfragen an die Datenbank. Für alleAnfragen, die nicht als Direct Path deklariert sind, das heißt, nicht explizitdirekt auf die Datenbank zugreifen, findet ein Buffer Get statt, das heißt, eswird versucht, den entsprechenden Datenblock aus dem Data Buffer zulesen. Gelingt dies, spricht man von einem Buffer Hit, wohingegen ein Fehl-

SQL-Area Pin ratio

Gibt an, wie viel Prozent aller Anfragen alle benötigten Objekte zur Ausführung noch im Memory vorfinden:Pin ratio = Σ (Ausführungen = Pin hits)/Σ (Anfragen zur Aus-führung = Pins) x 100

> 99%

Reloads/Pin Verhältnis von Neuladen eines SQL-Statements (zum Beispiel invalidierter Eintrag aufgrund des Alters) zu Ausführungsan-fragen

< 0,04

User/Recur-sive calls

Verhältnis von Benutzeranfragen an die Datenbank zu den Anfragen, die die Datenbank zusätzlich zu den Benutzeranfra-gen ausführen muss (zum Beispiel aufgrund eines fehlenden Dictionary-Cache-Eintrages)

> 2

Busy wait time

Summe aller Wartezeiten der Datenbank in Sekunden, ohne Idle Events (siehe Abschnitt 8.2.2.2, Analyse von Wait Events)

Verhältnis ca. 60:40

CPU time Summe der verbrauchten CPU-Zeit durch alle Oracle Sessions

Puffer/Merkmal

Bedeutung Empfeh-lung

Tabelle 8.4 Bedeutung der wichtigsten Merkmale des Oracle-Datenbankmonitors (Forts.)



457

schlag zu einem Physical Read führt, und der Block dann aus den Datenda-teien von der Festplatte gelesen wird (siehe Abbildung 8.4).

Die Hitratio für den Data Buffer berechnet sich wie folgt:

Qualität (Hitratio) = (Logical Reads – Physical Reads)/Logical Read × 100%

Für eine gute Datenbankperformance sollten mindestens 94% aller Blockzu-griffe (außer Direct-Path-Operationen) auf die Datenbank durch den Pufferbefriedigt werden. Wird dieser Wert unterschritten, sind die folgenden mög-lichen Ursachen zu untersuchen:

� zu klein dimensionierter Data Buffer

� viele Direct-Path-Operationen, die auf Datenblöcke unter Umgehung desData Buffers zugreifen (Hinweis: Direct-Path-Operationen werden bei derAnzeige in ST04N schon aus der Hitratio herausgerechnet, nicht aber beiST04! Daher kann es hier Unterschiede geben.)

� teure SQL-Statements (siehe Abschnitt 8.3).

Zu den Direct-Path-Operationen gehören die folgenden Wait Events:

� direct path read und direct path write

� direct path read (lob) und direct path write (lob) (Oracle 9i)

� direct path read temp und direct path write temp (Oracle 10g)

Die Anzahl von direct path-Operationen finden Sie in Transaktion ST04Nunter Additional Function � Display V$ � V$SYSTEM_EVENT (siehe Abbil-dung 8.5). Deren Anzahl sollte vor allem im Vergleich mit den regulärenZugriffen auf Datenblöcke über den Data Buffer (db file sequential read)sehr klein sein, das heißt < 0,5%. Der Ausnahmefall sind hier SAP NetWea-ver BI-Systeme, bei denen deutlich höhere Werte akzeptabel sind (sieheKapitel 12, SAP NetWeaver BI und Oracle). Direct-Path-Operationen werdenzum Beispiel beim Zugriff auf den Tablespace PSAPTEMP benutzt. Um dieseZugriffe auf den temporären Tablespace für zum Beispiel JOIN- oder SORT-Operationen zu verringern, hilft unter Umständen die Vergrößerung desPGA-Speichers der einzelnen Datenbank-Workprozesse. Abbildung 8.5 zeigteinen Ausschnitt des Views V$SYSTEM_EVENT. Noch ein Hinweis zu die-sem View: Dort sind nur die Wait Events zu finden, die nach dem letztenDatenbankstart aufgetreten sind. Wundern Sie sich also nicht, wenn ein hiererwähnter Wait Event dort nicht angezeigt wird.


Performance8

458

Abbildung 8.5 Direct-Path-Operationen in V$SYSTEM_EVENT

Sind teure SQL-Statements und direct path-Operationen als Grund für eineschlechte Hitratio ausgeschlossen, dann sollte, wenn möglich, der Data Buf-fer vergrößert werden, um zu testen, ob dies eine Verbesserung bringt. Istdie Vergrößerung nur durch einen Hardwareausbau zu realisieren, so solltenallerdings vor einer entsprechenden Investition alle anderen möglichenUrsachen für eine schlechte Performance ausgeschlossen werden.

Die Startkonfiguration des Data Buffers hängt völlig vom Einsatzzweck undvon der Belastung Ihres Systems ab. In der Praxis gibt es produktive SAP-Sys-teme, die mit mehr als 100 GB großen Data Buffern arbeiten. Daher kanneine generelle Empfehlung an dieser Stelle nicht gegeben werden. Vielmehrsei hier auf die Möglichkeit verwiesen, von SAP-Experten Sizing Sessionsdurchführen zu lassen.

Mit der Einführung der dynamischen SGA ab Oracle 9i gibt es für den Ora-cle-Administrator eine einfache und komfortable Möglichkeit zu überprü-fen, wie sich Änderungen am Data Buffer auswirken. Über den View V$DB_CACHE_ADVICE lässt sich erkennen, wie sich eine Änderung der Puffer-größe auf die Anzahl der Physical Reads auswirkt. Über den Faktor, um densich die physischen Datenbankzugriffe gegenüber dem Ist-Zustand ändern,lässt sich ablesen, um wie viele MB sich der Puffer verkleinern lässt, ohnedass signifikante Performanceverschlechterungen eintreten, oder um wieviele MB der Puffer sinnvoll vergrößert werden kann, um die Physical Readsweiter zu minimieren. Vorraussetzung ist natürlich, dass die dynamischeSGA aktiviert ist und der Oracle-Parameter DB_CACHE_ADVICE auf ON steht.

Neben dem eigentlichen Data Buffer gibt es noch den Keep Pool und denRecycling Pool, die auch Datenblöcke puffern. Diese beiden Pools sind bei derVerwendung der dynamischen SGA (Oracle 9i) nicht mehr Teil des Data Buf-fers, sondern liegen separat in der SGA. Der Keep Pool dient für Tabellen



459

beziehungsweise Blöcke, die nicht wieder aus dem Data Buffer verdrängtwerden sollen. Der Recycling Pool hingegen wird für Tabellen verwendet,die keine anderen Blöcke aus dem Data Buffer verdrängen sollen und derenBlöcke sofort wieder verdrängt werden können. Die SAP-Standardeinstellun-gen verwenden diese Pools nicht, allerdings ist der Einsatz unter bestimmtenUmständen empfohlen (siehe SAP-Hinweis 762808).

Die nach dem Data Buffer wichtigsten Puffer der Oracle-Datenbank liegen imShared Pool und heißen: SQL-Cache und Dictionary Cache.

Der SQL-Cache (früher auch Shared Cursor Cache) liegt im Library Cache undspeichert alle Oracle-internen Informationen, die zum Aufruf eines SQL-Statements gehören, wie zum Beispiel den Parse-Tree und den Ausführungs-plan, um diese gegebenenfalls wiederzuverwenden.

Als weitere Kennzahl kommt für den SQL-Cache im Shared Pool die Pinratiohinzu. Diese errechnet sich wie folgt:

Pinratio = (pinhits/pin) × 100%

Bei der Abarbeitung eines SQL-Statements wird dieses von Oracle in ver-schiedene Teile zerlegt. Ein Pin ist nun genau die Anfrage zur Wiederbenut-zung einer dieser Teile aus der SQL-Zerlegung und ein Pinhit entsteht ent-sprechend, wenn die Wiederbenutzung gelingt. Dies ist jedoch nicht immerder Fall, da beispielsweise Cache-Einträge durch Timeout invalidieren kön-nen oder eventuell durch andere verdrängt werden. Scheitert die beschrie-bene Wiederverwendung, so muss das entsprechende SQL-Kommando mitseinen Teilen neu geladen werden, was als Reload bezeichnet wird. Aus die-sem Zusammenhang zwischen Anfragen (Pins) und Neuladungen (Reload)ergibt sich die Kennziffer »Reloads per pin« (siehe Abbildung 8.4 und Tabelle8.4 weiter vorne).

Ein Puffer-Hit beim SQL-Cache bedeutet also nur, dass das abgefragte SQL-Statement bereits einmal geparst wurde. Die Pinratio hingegen sagt aus, wieoft bei einem gefundenen Cache-Eintrag die Wiederverwendung gelingt.Scheitert diese Wiederverwendung, kommt es zum Reload des entsprechen-den Teils.

Im Oracle Library Cache befinden sich noch weitere Sub-Caches für PL-/SQL-Packages sowie für Kontrollstrukturen wie Sperren und Library Cache Hand-les. Diese spielen für die Performance allerdings nur eine untergeordneteRolle.


Performance8

460

Der Dictionary Cache puffert Blöcke aus dem Dictionary der Oracle-Daten-bank, also Informationen über Strukturen von Tabellen, Berechtigungen etc.Diese Metainformationen der Datenbank werden regelmäßig bei der Abar-beitung von Benutzeranfragen benötigt.

Die minimale Größe des Shared Pools liegt laut SAP-Empfehlung bei 400MB. Liegen die Hitratio-Werte permanent unterhalb der weiter vorne inTabelle 8.3 beschriebenen Werte, so kann eine Vergrößerung des Parame-ters SHARED_POOL_SIZE sinnvoll sein. Achten Sie aber darauf, dass zum Bei-spiel der Aufbau der Datenbankstatistiken die Trefferrate im Shared Poolvorübergehend stark senken kann.

Unter Umständen ist es auch möglich, den Shared Pool wieder zu verklei-nern, wenn die Performancewerte (siehe Tabelle 8.4) alle im grünen Bereichsind und permanent ein größerer Teilbereich des Shared Pools frei bleibt(> 50 MB). Den Freibereich im Shared Pool finden Sie in der TabelleV$SGASTAT � free memory oder mit folgendem SQL-Kommando:

Select bytes from V$SGASTATwhere pool = ’shared pool’ AND name = ’free memory’;

Außerdem können Sie über den View V$SHARED_POOL_ADVICE erken-nen, wie sich eine Änderung an der Größe des Shared Pools auf die CacheHits auswirkt und den Pool entsprechend vergrößern bzw. verkleinern.

Ab Oracle 10g kann der historische Verlauf der Auslastung des Shared Poolsbetrachtet werden. Über den View DBA_HIST_SGASTAT können Sie denVerlauf der Freiplatzentwickung betrachten.

Die Program Global Area (PGA) ist der Teil des Oracle-Speichers, der lokaleinem Serverprozess (Schattenprozess oder auch Hintergrundprozess) zuge-ordnet ist. Der gesamte PGA-Speicher einer Oracle-Instanz errechnet sich ausder Summe der PGAs aller Datenbankprozesse. Den derzeit insgesamt allo-kierten PGA-Speicher finden Sie in ST04N unter Additional Function � Dis-play V$/GV$ Views and Values � V$PGASTAT � total PGA allocated oderdurch den folgenden SQL-Aufruf:

SelectVALUE from V$PGASTATwhere name = ’total PGA allocated’;

Die PGA eines Prozesses enthält nur die Daten und Informationen, die vondieser benötigt oder bearbeitet werden. Besonders bei speicherintensivenSortier- und Hash-Operationen kommt der Größe der PGA eine entschei-



461

dende Bedeutung zu. Demzufolge sollte der Administrator auf die optimaleKonfiguration dieses Speichers besonderen Wert legen, insbesondere imSAP NetWeaver BI-Umfeld (siehe Kapitel 12).

Die Konfiguration der PGA hat sich allerdings seit dem Release Oracle 9i deut-lich vereinfacht. Während der Administrator bei älteren Oracle-Versionen diePGA-Bereiche für einzelne Operationen (zum Beispiel SORT_AREA_SIZE undHASH_AREA_SIZE) festlegen musste, gibt es nun die Möglichkeit der automati-schen PGA-Verwaltung. Ähnlich wie beim ASMM für die SGA passt Oracle diePGA-Bereiche aller Serverprozesse automatisch an. Besonders wichtig zuerwähnen ist, dass nicht mehr benötigter PGA-Speicher wieder freigegebenwird, denn dies war vor der automatischen PGA-Verwaltung nicht der Fall.Insgesamt wird die PGA über den Parameter PGA_AGGREGATE_TARGET in ihrerGröße limitiert. Der Einsatz der automatischen PGA-Verwaltung ist ab Oracle9i möglich (laut SAP-Hinweis 619876 sogar empfohlen) und wird bei jederSAP-Installation mit SAP-Basis > = 6.40 automatisch aktiviert.

Für das Verständnis des PGA-Tunings sind einige Begriffe notwendig, die hierkurz erläutert werden sollen. Der Oracle-Prozess, der gerade eine Operationdurchführt, benötigt dafür lokalen Speicher, eine sogenannte Workarea.Genügt der PGA-Speicher, der dem Prozess zur Verfügung steht, für diesekomplette Workarea, spricht man von der Optimal Work Area Size und diedazugehörige Operation wird als Optimal Execution bezeichnet. Genügt diePGA jedoch nicht, so wird für die Operation auf den temporären Festspeicher(PSAPTEMP) zurückgegriffen. Die dadurch entstehenden I/O-Aktivitäten(Direct-Path-Operationen ohne Pufferung) wirken sich allerdings deutlichnegativ auf die Performance aus. Ist für eine erfolgreiche Operation ein ein-facher Durchlauf (erster Rekursionslevel) des PSAPTEMP erforderlich, sprichtman von einer One-Pass-Operation. Von einer Multi-Pass-Operation sprichtman, wenn der PSAPTEMP sogar für mehrere Durchläufe benötigt wird.

Ob der PGA-Speicher zu klein konfiguriert ist, kann man an verschiedenenIndikatoren erkennen. Zuerst sollte man folgende Werte im View V$PGAS-TAT überprüfen (gültig für die automatische PGA-Verwaltung, siehe Abbil-dung 8.6):

� over allocation countGibt an, wie oft der PGA-Speicher nicht ausreichend war. Dieser Wertsollte bei 0 liegen, anderenfalls ist die PGA zu vergrößern.

� cache hit percentageGibt an, wie oft die Optimal Work Area Size getroffen wurde. Im Idealfallvon 100% gibt es keine One- oder Multi-Pass-Operationen. Dieser Wert


Performance8

462

sollte bei einem normalen ERP-System bei > 70% und bei einem BI-Sys-tem bei > 90% liegen.

Wie sich eine Veränderung des Parameters PGA_AGGREGATE_TARGET auf diePGA-Qualität (over allocation count und cache hit percentage) auswirkt, istim View V$PGA_TARGET_ADVICE zu erkennen.

Im View V$SQL_WORKAREA_HISTOGRAM können Sie erkennen, wie oftwie viel PGA-Speicher von einem Prozess benötigt wurde, und Sie könnenentsprechend sehen, wann eine Optimal-, One- oder Multi-Pass-Operationausgeführt wurde. Das Ziel bei der Größenfestlegung der PGA ist es, Multi-Pass-Operationen komplett zu vermeiden. Der Prozentsatz von Optimal-Operationen sollte je nach Systemtyp (ERP oder BI) bei > 70% beziehungs-weise > 90% liegen.

Abbildung 8.6 Merkmale der PGA

8.2.2.2 Analyse von Wait Events

Für eine zuverlässige Aussage über die Oracle-Performance sind die Qualitä-ten der einzelnen Pufferspeicher (Data Buffer, Shared SQL etc.) nicht ausrei-chend. Wenn zum Beispiel ein Hit, also ein Treffer bei einer Abfrage, einge-treten ist, sagt das noch nichts über die Geschwindigkeit aus, mit der dieAnfrage und die Ergebnisrückgabe abgearbeitet wurden. Hier kommen die



463

Oracle Wait Events ins Spiel. Die Antwortzeit der Datenbank setzt sich auszwei Komponenten zusammen:

� CPU-Zeit: die Zeit, in der die Oracle Session die CPU nutzt.

� Wait Event: die Zeiten, in denen die Oracle Session auf ein Ereignis, wiezum Beispiel das Lesen eines Blocks vom Festspeicher, wartet.

Ein Wait Event ist, wie der Name schon sagt, eine Situation, in der eine Ora-cle Session auf ein Ereignis wartet. Dieses Ereignis kann aus den verschie-densten Bereichen der Datenbank kommen, zum Beispiel zeigt der WaitEvent log buffer space an, dass die Session auf einen freien Platz im Redo-Log-Puffer warten musste. Alle Wait Events werden nach dem Datenbank-start in X$-Tabellen gesammelt und können über verschiedene V$-Viewsabgefragt werden. Die wichtigsten Views sind:

� V$SYSTEM_EVENTEnthält alle seit dem Start aufgetretenen Waits mit ihrer Häufigkeit undder durchschnittlichen Länge.

� V$SESSION_EVENTEnthält alle seit dem Start aufgetretenen Waits mit ihrer Häufigkeit sowieder durchschnittlichen und maximalen Länge für jede Oracle Session.

� V$SESSION_WAITEnthält zu jeder Oracle Session die aktuellen Waits beziehungsweise dieInformation, dass momentan CPU verbraucht wird.

Bei einem Oracle-Datenbank-Release 9i und kleiner sind nach einem Neu-start der Datenbank alle Monitoring-Daten über die Wait Events gelöscht.Bei Oracle 10g gibt es jedoch einige History-Tabellen beziehungsweise-Views, die historische Informationen speichern. Die Historie der WaitEvents finden Sie im View DBA_HIST_SYSTEM_EVENT.

Aus der Betrachtung der Waits lässt sich genau bestimmen, was eine OracleSession gerade tut beziehungsweise worauf sie gerade wartet. Dies macht esfür den Administrator einfacher, ein eventuelles Problem zu spezifizieren.Außerdem gibt die Analyse der systemweit gesammelten Waits Hinweise aufvorhandene Optimierungspotenziale in der Datenbank.

Ein Wait Event besteht immer aus dem Event-Namen und optional bis zudrei Parametern, die den Event genauer spezifizieren können, wie im folgen-den Beispiel:

� Event: direct path read: Warten auf das Lesen eines Datenblocks vonPlatte unter Umgehung des Data Buffers


Performance8

464

� Parameter 1: file number: Dateinummer der zu lesenden Datei

� Parameter 2: first dba: erster zu lesender Block der Datei

� Parameter 3: block count: Anzahl der zu lesenden Blöcke

Mit folgendem SQL-Kommando können Sie den Dateinamen zur Dateinum-mer und den entsprechenden Tablespace ermitteln:

Select tablespace_name, file_nameFrom dba_data_filesWhere file_id = ’ID’;

In Release Oracle 10g gibt es über 850 Wait Events (in Oracle 9i ca. 400), unddiese werden zur besseren Einordnung in die Klassen aus Tabelle 8.5 grup-piert (ab Oracle 10g).

Zu welcher Klasse ein Wait Event gehört, lässt sich mit folgendem SQL-State-ment ermitteln:

Select WAIT_CLASS from dba_hist_event_name where EVENT_NAME=‘Name’;

Wichtig zu wissen ist, dass es Wait Events gibt, die keinerlei Einfluss auf dieAntwortzeit der Datenbank haben und daher für die Performanceanalyse

Wait-Event-Klasse Anzahl der Wait Events in der Klasse

Administrative 46

Idle 62

Application 12

Network 26

Cluster 47

Scheduler 1

System I/O 24

Commit 1

User I/O 17

Concurrency 24

Other 591

Configuration 23

Tabelle 8.5 Wait-Event-Klassen (Anzahl der Wait Events)



465

uninteressant sind. Zum einen sind da alle Events der Klasse Idle, die gemel-det werden, wenn ein Oracle-Prozess nichts tut. Der bekannteste und häu-figste dieser Idle Events ist SQL*Net message from client, der auftritt, wennein Oracle-Schattenprozess auf eine neue Anfrage wartet. Zum anderen gibtes Wait Events, die speziell im Zusammenhang mit SAP keine Relevanz fürdie Datenbankzeit haben. Ein Grund hierfür kann sein, dass die Zeit diesesEvents bereits in anderen Events enthalten ist, so ist zum Beispiel log fileparallel write durch log file sync abgedeckt. Des Weiteren sind viele(nicht alle) Events, die in den Oracle-Schattenprozessen (DBWR, PMON, SMONetc.) vorkommen, erst in zweiter Linie von Interesse, da die entsprechendenOperationen asynchron zu den Oracle-Workprozessen erfolgen.

In der folgenden Aufzählung finden Sie die am häufigsten auftretenden WaitEvents, die aus SAP-Sicht in der Regel nicht relevant sind.

Grundsätzlich ist ein erster Indikator, wie in Tabelle 8.4 bereits beschrieben,das Verhältnis von Busy wait time zu CPU time, das optimalerweise ca.60:40 ist.

Zu Begin der allgemeinen Wait-Event-Analyse ist es sinnvoll, eine Liste mitden Top-Wait-Events zu erstellen, das heißt, eine Liste mit den aufsummier-ten Wartezeiten in absteigender Reihenfolge. Diese lässt sich in der Transak-tion ST04N (siehe Abbildung 8.6) über den View V$SYSTEM_EVENT odermit folgendem SQL-Kommando erstellen:

select EVENT, TIME_WAITED, AVERAGE_WAITfrom V$SYSTEM_EVENTorder by TIME_WAITED desc;

Aus SAP-Sicht irrelevante Oracle Wait Events

� db file parallel write

� log file sequential read

� smon timer

� SQL*Net message from client

� Log archive I/O

� ARCH wait on SENDREG

� rdbms ipc message

� jobq slave wait

� log file parallel write

� pmon timer

� Streams AQ: <action>


Performance8

466

Die Spalte AVERAGE_WAIT ist unter Oracle 9i anders formatiert als unter 10g.Sie wird bis 9i in 1/100-Sekunden ohne Nachkommastellen angegeben und istdaher für eine ernsthafte Performanceanalyse nicht ausreichend. Alternativbietet sich hier die Spalte TIME_WAITED_MICRO an, die die Gesamtwartezeitin Mikrosekunden enthält. Die genaue durchschnittliche Wartezeit errechnetsich dann aus TIME_WAITED_MICRO durch TOTAL_WAITS.

Tabelle 8.6 gibt Aufschluss über die Bedeutung der einzelnen Spalten desViews V$SYSTEM_EVENT.

Abbildung 8.7 Liste der Wait Events im View V$SYSTEM_EVENT

Spalte Bedeutung

TOTAL_WAITS Anzahl aller Auftritte des Wait Events seit dem letzten Start der Oracle-Datenbank

TOTAL_TIMEOUTS Anzahl der Waits, bei denen der entsprechende Event nicht aufgetreten ist

TIME_WAITED Gesamtwartezeit auf den Wait Event in Hunderstelsekun-den

Tabelle 8.6 Spalten des Views V$SYSTEM_EVENT



467

Ist die entsprechende Liste erstellt, wird sie von oben nach unten abgearbei-tet, um kritische Wait Events zu finden, dabei werden die Idle Wait Eventsignoriert.

Weitere wichtige Informationen liefert der View V$SESSION_WAIT (sieheAbbildung 8.8). Dieser zeigt die aktuellen oder zuletzt aktiven Wait Eventsaller Oracle-Prozesse an.

Abbildung 8.8 View V$SESSION_WAIT

Tabelle 8.7 gibt Aufschluss über die Bedeutung der einzelnen Spalten desViews V$SESSION_WAIT.

AVERAGE_WAIT Durchschnittliche Wartezeit auf den Event in Hunderstel-sekunden (AVERAGE_WAIT = TIME_WAITED / TOTAL_WAITS)

TIME_WAITED_MICRO (letzte Spalte in Abbildung 8.7)

Gesamtwartezeit auf den Wait Event in Mikrosekunden

Spalte Bedeutung

SID Session-ID des Oracle-Prozesses

P1TEXT, P2TEXT, P3TEXT

Beschreibung/Einheit des jeweiligen Parameters

P1, P2, P3 Werte der Parameter des Wait Events

Tabelle 8.7 Spalten des Views V$SESSION_WAIT

Spalte Bedeutung

Tabelle 8.6 Spalten des Views V$SYSTEM_EVENT (Forts.)


Performance8

468

Des Weiteren ist es häufig notwendig oder sinnvoll, die SAP-Workprozessedem jeweiligen Oracle-Workprozess oder umgekehrt zuzuordnen. Am ein-fachsten ist dies über den Oracle Session Monitor möglich. Dort findet sichfür jeden Eintrag eines Oracle-Workprozesses in der Spalte Clnt proc die Pro-zess-ID des verbundenen SAP-Workprozesses. Diese Client-PID korrespon-diert mit der Spalte Pid des SAP-Prozessmonitors (Transaktion SM50).

Im Folgenden sollen die wichtigsten Wait Events benannt und deren Hinter-gründe beleuchtet werden. Sie finden immer eine Tabelle mit den wichtigs-ten Informationen und anschließend einen Textabschnitt mit Erläuterungenzum Wait Event.

WAIT TIME Die auf den Wait Event gewartete Zeit (in Hunderstelsekunden), wenn der Wait Event vorbei ist. Ist der Wait Event hingegen aktiv, ist der Wert = 0. Außerdem gibt es noch zwei Sonderwerte: Wert = –1, wenn die Laufzeit des Events unterhalb der Messgenauigkeit war, und Wert = –2, wenn TIMED_STATISTICS nicht aktiv ist.

STATE Status der Wait Events – möglich sind:

� WAITING: wartet/aktiv (WAIT TIME = 0)

� WAITED KNOWN TIME: ist abgelaufen und dauerte länger als 1/100s (WAIT TIME > 0)

� WAITED UNKNOWN TIME: ist abgelaufen und dauerte weniger als 1/100s (WAIT TIME = -1)

� TIME STATISTICS OFF: ist abgelaufen, aber Statistiken werden nicht erfasst (WAIT TIME = -2)

Achtung

Eine hohe Anzahl der verschiedensten Wait Events kann auch durch einen CPU-Engpass ausgelöst werden. Ist die CPU-Last sehr hoch, werden möglicherweiseOracle-Prozesse verdrängt, die gerade eine Sperre halten. Warten weitere Prozesseauf diese Sperre, so können sich verschiedene Wait-Zeiten dramatisch erhöhen.Überprüfen Sie daher zuerst, ob die CPU-Ressourcen ausreichend sind.

Anmerkung

Wie bereits erwähnt, wurden die Wait Events in Oracle 10g gegenüber dem Vor-gänger Oracle 9i stark ausgebaut. Dies spiegelt sich zum Beispiel im Aufsplittenvon Wait Events zur genaueren Ursachenspezifizierung wider. Wir werden haupt-sächlich die Wait Events aus Oracle 10g nutzen und nur vereinzelt auf die Unter-schiede zu Oracle 9i eingehen.

Spalte Bedeutung

Tabelle 8.7 Spalten des Views V$SESSION_WAIT (Forts.)



469

Treten problematische Werte bei der durchschnittlichen Wartezeit auf, sodeutet dies in erster Linie auf einen I/O-Performanceengpass hin. Für dieAnalyse von I/O-Problemen lesen Sie bitte Abschnitt 8.2.2.3, Analyse desDatenbank-I/O. Ein zweiter wichtiger Aspekt neben der Wartezeit ist dieHäufigkeit des Auftretens von db file sequential read. Ist diese sehr hoch,tritt der Wait Event in der Regel im Zusammenhang mit einer schlechten Hit-ratio des Data Buffers auf. In diesem Fall gibt es zwei Lösungsszenarien: dasTuning von eventuell vorhandenen schlechten SQL-Statements (sieheAbschnitt 8.3) oder die Vergrößerung des Data Buffers.

Das Lesen von mehreren Blöcken hintereinander tritt in der Regel nur beieinem Full table scan oder Index fast full scan auf. Diese Zugriffsartengehen deutlich zu Lasten der Performance und sind daher so weit wie mög-lich zu vermeiden. Eine Ausnahme bildet hier wieder das SAP NetWeaver BI-Umfeld (siehe Kapitel 12). Liegt das Auftreten von db file scattered read

Name db file sequential read/db file parallel read

Parameter 1 Dateinummer(n)

Parameter 2 Blocknummer(n)

Parameter 3 1 beziehungsweise Anzahl der parallelen Reads

Bedeutung Diese Events stehen für das Warten auf einen oder mehrere parallel zu lesende Blöcke von der Festplatte. Parallel heißt in diesem Fall nicht mehrere Blöcke hintereinander, sondern gleichzeitig auf verschiedene nicht aufeinanderfolgende Blöcke.

Bewertung Average Wait Time sollte kleiner als 2 sein, also 2/100s = 20 ms.

Tabelle 8.8 db file sequential read/db file parallel read

Name db file scattered read

Parameter 1 Dateinummer

Parameter 2 Blocknummer

Parameter 3 Anzahl der Blöcke

Bedeutung Tritt dieser Event auf, so wartet eine Oracle Session auf das Lesen meh-rerer Blöcke hintereinander von der Festplatte.

Bewertung Maximal 10% der WAIT_TIME von db file sequential read (Aus-nahme: Bei SAP NetWeaver BI können höhere Anteile akzeptiert wer-den).

Tabelle 8.9 db file scattered read


Performance8

470

über den in Tabelle 8.9 genannten Werten, sollten Sie die verursachendenSQL-Kommandos finden. Hinweise auf diese Kommandos finden Sie mit derFunktion SQL Request in der Transaktion ST04N � Ressource Consumption �SQL Request. Richten Sie Ihr Augenmerk auf SQL-Statements mit hohen DiskReads. Noch besser ist allerdings eine Eingrenzung auf Kommandos, inderen Aufführungsplan tatsächlich ein Full Scan vorkommt.

In SAP-Hinweis 619188 finden Sie ein SQL-Kommando, das ab Oracle 9ifunktioniert. Mit diesem Kommando finden Sie die 20 SQL-Statements, diedie meisten Disk Reads aufgrund von Full Scans erzeugen. Diese Komman-dos sollten Sie auf Tuning-Möglichkeiten hin überprüfen. Achtung: WennSie im Rahmen der Performanceanalyse intensiv mit den Oracle-Transaktio-nen im SAP-System arbeiten (zum Beispiel ST04N), kann sich das in denErgebnissen widerspiegeln. Sie finden dann in den Top 20 der SQL-State-ments teilweise Abfragen zu Oracle-Spezifika oder Oracle-Monitoring-Daten, die nichts mit den normalen betriebswirtschaftlichen SQL-Anfragenzu tun haben. Ignorieren Sie diese SQL-Statements bei Ihrer Analyse.

Liegt das Problem in einer zu hohen durchschnittlichen Wartezeit, so liegtauch hier wahrscheinlich ein I/O-Engpass vor. Gehen Sie dann wie inAbschnitt 8.2.1.2, Identifizierung der Ursachen bei den Hardwarekomponenten,beschrieben vor.

Name direct path read/direct path read tempdirect path write/direct path write temp



Parameter 3 Anzahl der Blöcke

Bedeutung Dieser Wait Event wird registriert, wenn unter Umgehung des Data Buffers auf Datenblöcke zugegriffen wird. Ab Oracle 10g unterscheidet man die Waits nach Zugriffen auf »normale« Blöcke beziehungsweise auf temporäre Blöcke aus dem PSAPTEMP-Tablespace (temp).

Bewertung Alle Events sollten nicht unter den ersten zehn in der Wait-Event-Liste sein (absteigend nach summierter Wartezeit, siehe Abbildung 8.7). Außerdem gilt für die Average Wait Time wie bei db file sequential read ein maximaler Wert von 2, also 2/100s = 20 ms.

Tabelle 8.10 direct path [read|write|temp]



471

Werden die direct path-Operationen zu oft durchgeführt und landen des-halb in der Liste weit oben, so muss für das weitere Vorgehen nach den Ursa-chen für diese Operationen unterschieden werden.

Für die Oracle-Datenbank gibt es drei Gründe direct path-Operationendurchzuführen:

1. PSAPTEMP-Zugriffe

2. Parallele Querys

3. Zugriffe auf LOB-Daten (Large Object)

Bei vielen Operationen auf dem PSAPTEMP-Tablespace, zu erkennen amWait Event direct path read/write temp, bietet sich eine Vergrößerung desPGA-Speichers an (siehe Abschnitt 8.2.2.1, Analyse der Datenbankpuffer), umdas Problem zu beheben. Operationen aus dem zweiten und dritten Grundsind unter Oracle 10g nicht zu unterscheiden. Im Gegensatz dazu erzeugenZugriffe auf ungepufferte LOB-Daten unter Oracle 9i einen eigenen WaitEvent: direct path read/write (lob). LOB-Daten, also große unstruktu-rierte Daten in Tabellenspalten, werden von SAP vor allem für die Tabellenmit ABAP-Code genutzt. Aufgrund ihrer Größe (bis zu vier Gigabyte) werdendiese LOBs nicht mehr im Data Buffer gepuffert, und dadurch entstehen diedirect path-Operationen. Bei Problemen ist hier eventuell eine Pufferungspezieller LOB-Daten angebracht (siehe SAP-Hinweis 563359).

Parallele Querys, das heißt, die parallele Ausführung spezieller Aktionen wiezum Beispiel eines Full Table Scans, werden in der Regel von SAP nichtgenutzt. Nur bei SAP NetWeaver BI-Systemen kommen sie zum Einsatz. DieGründe liegen in verschiedenen Nachteilen in Zusammenhang mit dem CBOund der entstehenden Ressourcenallokation (siehe SAP-Hinweis 651060).

Name log file sync/log buffer space/log file parallel write

Parameter 1 Pufferanzahl / - / Dateinummer

Parameter 2 - / - / Anzahl der Blöcke

Parameter 3 - / - / Anzahl I/O-Requests

Tabelle 8.11 log file [sync|parallel] und log buffer space


Performance8

472

Alle drei genannten Wait Events hängen in der Regel direkt von der I/O-Per-formance beim Schreiben der Redo-Log-Dateien ab. Daher ist zuerst zu ana-lysieren, ob es I/O-Probleme gibt und ob hier Optimierungen vorgenommenwerden können (siehe Abschnitt 8.2.1.2, Identifizierung der Ursachen bei denHardwarekomponenten, und 8.2.2.3, Analyse des Datenbank-I/O). Die Redo-Log-Dateien sind der I/O-intensivste Bereich einer Oracle-Datenbank undunterliegen daher auch speziellen Anforderungen an Speicherort und Para-metrisierung. Lesen die dazu Abschnitt 5.2.3, Storage und SAN-Infrastruktur.

Unter bestimmten Umständen ist es sinnvoll, beim Einspielen oder Ändernvon großen Datenmengen komplett auf das Logging zu verzichten. Diesgeschieht zum Beispiel beim initialen Load des SAP-Systems in die Datenbank.Allerdings sind nach dem Abschalten des Loggings ein Restore und ein Reco-very nur bis zum Abschaltzeitpunkt möglich. Sie müssen also nach der Reak-tivierung des Loggings ein neues komplettes Backup des Systems erstellen.

Ein weiterer Punkt ist die Größe des Redo Buffers. Ist dieser mit weniger alseinem Megabyte konfiguriert (SAP-Empfehlung), so kann auch dies zu LogBuffer Space Wait Events führen. Ändern Sie dann den Parameter LOG_BUF-FER entsprechend auf die Größe von einem Megabyte (offline). Noch einigeandere Gründe können zum Wait Event log file sync führen, zum BeispielEnqueue-Wartesituationen (siehe SAP-Hinweis 745639, Abschnitt 12).

Bedeutung � log file syncSteht für das Warten auf die vollständige Synchronisation der Log-Dateien mit dem Redo Buffer durch den LGWR (zum Beispiel nach einem COMMIT).

� log buffer spaceSteht für das Warten auf einen freien Block im Redo Buffer.

� log file parallel writeTritt ein, wenn auf das Scheiben von Blöcken in die Redo-Log-Dateien gewartet wird.

Bewertung Bei allen drei Wait Events gilt für die Average Wait Time ein maximaler Wert von 4, also 4/100s = 40 ms. Aktuelle Hardware sollte jedoch deutlich darunter bleiben und Werte von ≤ 15ms ermöglichen.

Name log file sync/log buffer space/log file parallel write

Tabelle 8.11 log file [sync|parallel] und log buffer space (Forts.)



473

Der Begriff Log File Switch ist eigentlich ein Oberbegriff für mehrere WaitEvents, die im Zusammenhang mit dem Umschalten auf die nächste Redo-Log-Datei auftreten:

� log file switch (archiving needed)Tritt auf, wenn der Log-Switch nicht durchgeführt werden kann, weil dienächste Redo-Log-Datei noch nicht archiviert wurde

� log file switch (checkpoint incomplete)Steht für das Warten auf den Abschluss des Checkpoints des folgendenRedo-Logs vor dem Log-Switch

� log file switch completion Steht für das Warten auf den Abschluss des Log-Switches

� log file switch (private strand flush incomplete)Tritt auf, wenn der LGWR darauf wartet, dass der DBWR den In-Memory-UNDO-Puffer (IMU) komplett in den Log Buffer geschrieben hat

Ein »archiving needed« hat immer eine Average Wait Time von 98–100, dadie schreibenden Oracle-Prozesse (LGWR, DBWR etc.) bei einem ArchiverStuck immer genau eine Sekunde warten, bevor ein erneuter Schreibversuchunternommen wird. Ein Archvier Stuck darf in einem produktiven SAP-Sys-tem nicht vorkommen, weil das System dann »steht«. Höchstens in nichtproduktiven Systemen kann bei Hochlastsituationen, wie zum Beispiel Man-dantenkopien oder nächtlichem Daten-Load, ein kurzer Archiver Stuck unter

Name log file switch completion/(archiving needed)/(checkpoint incomplete)/(private strand flush incomplete)

Parameter –

Bedeutung Diese Wait Events werden gemeldet, wenn aus verschiedenen Gründen auf einen Log File Switch (Log-Datei-Switch) gewartet werden muss (siehe unten).

Bewertung � archiving neededsollte nie auftreten

� checkpoint incompletesollte nie auftreten (spezieller SAP-Hinweis 79341)

� completionauf keinen Fall unter den Top 10 der Wait-Event-Liste, maximal ein Log-Switch pro Minute

� private strand flush incompletesollte nie auftreten

Tabelle 8.12 log file switch completion


Performance8

474

Umständen akzeptabel sein. Um diesen Stillstand der Oracle-Datenbank zuvermeiden, müssen Sie mit Ihrer Backup-Strategie dafür sorgen, dass dasFestplattenvolumen, auf dem die Offline-Redo-Logs gespeichert werden (inder Regel Verzeichnis oraarch), immer gesichert und geleert wird, damit fürneue Offline-Redo-Logs nach einem Log-Switch ausreichend Platz vorhan-den ist. Definieren Sie durch den Parameter LOG_ARCHIVE_DEST auch andereArchiver-Destinationen, müssen diese natürlich beim Backup berücksichtigtwerden.

Im Falle des Wait Events log file switch (checkpoint incomplete) ist derFehler »checkpoint not complete« aufgetreten und im Oracle-Alert-Log ver-zeichnet. Checkpoints werden im Wesentlichen bei jedem Log-Switch durch-geführt. Mehrere Checkpoints können gleichzeitig aktiv sein. »checkpointnot complete« tritt auf, wenn im Rahmen eines Log-Switches auf ein Redo-Log gewechselt werden soll, dessen Checkpoint noch nicht beendet ist.

Prinzipiell gibt es die folgenden vier möglichen Ursachen für ein gehäuftesAuftreten des Wait Events beziehungsweise der Situation »checkpoint notcomplete«:

1. zahlreiche Redo-Logs werden geschrieben

2. DBWR-Performanceengpass

3. zu wenige Redo-Logs

4. zu kleine Redo-Logs

Wenn die Oracle-Datenbank viele Redo-Logs schreibt, sollten Sie zuerstüberprüfen, ob es sich um operative Last handelt, das heißt, ob das Redo-Log-Aufkommen durch die normale Systemnutzung erklärbar ist. Findensich anwendungsseitig keine Anhaltspunkte für eine hohe Redo-Log-Fre-quenz, so kommen verschiedene andere Erklärungen wie Fehlkonfiguratio-nen und Oracle-Bugs in Frage. Bitte überprüfen Sie die in SAP-Hinweis584548 beschriebenen Ursachen.

In der Regel gibt es natürlich eine Erklärung für die Erzeugung von vielenRedo-Logs aus dem operativen Betrieb heraus. Zuerst sollten Sie darauf ach-ten, dass maximal ein Redo-Log-Switch pro Minute vorkommt. Ist dies nichtder Fall, sollten Sie die Größe Ihrer Redo-Log-Dateien erhöhen. Gehen Siewie folgt vor:

1. Melden Sie sich an der Datenbank als sysdba an:sqlplus "/ as sysdba"

2. Löschen Sie eine Log-Dateigruppe:



475

ALTER DATABASE DROP LOGFILE GROUP 11;

Erhalten Sie den Fehler ORA-01623, wechseln Sie auf eine neue Redo-Log-Datei durch folgendes Kommando, und warten Sie ein paar Sekun-den, bevor Sie den DROP-Befehl wiederholen:ALTER SYSTEM SWITCH LOGFILE;

Im Falle des Fehlers ORA-01624 ist der aktuelle Checkpoint noch nichtabgeschlossen. Warten Sie ein paar Sekunden, und wiederholen Sie denDROP-Befehl.

3. Löschen Sie die zugehörigen Betriebssystemdateien im Redo-Log-Ver-zeichnis.

4. Legen Sie die Log-Dateigruppe 11 mit einer neuen größeren Größe(<neue_größe> in MB) an:

ALTER DATABASE ADD LOGFILE GROUP 11('/oracle/<sid>/origlogA/log_g11_m1.dbf','/oracle/<sid>/mirrlogA/log_g11_m2.dbf')SIZE <neue_größe>M;

5. Wiederholen Sie die Schritte 2 bis 4 für alle vorhandenen Redo-Log-Gruppen.

Nach der SAP-Standardinstallation sind die Redo-Log-Dateien der vier Grup-pen je 50 MB groß. Vergrößern Sie die Dateien schrittweise und verifizierenSie dann, dass das Problem gelöst ist. Der Umfang der Vergrößerung hängtdavon ab, wie viele Redo-Logs pro Minute geschrieben werden. Wenn mit50 MB beispielsweise fünf Log-Switches pro Minute durchgeführt werden,braucht man nicht erst auf 100 MB zu gehen, sondern kann gleich auf zumBeispiel 300 MB wechseln.

Tritt der Wait Event log file switch (private strand flush incomplete) aufoder haben Sie andere Hinweise auf einen Engpass beim DBWR-Prozess,zum Beispiel aus den Wait Events free buffer waits (siehe weiter unten), sokönnen Sie die Anzahl der DBWR-Prozesse erhöhen, um die Schreibperfor-mance zu verbessern. Dies geschieht durch das Setzen des Parameters DB_WRITER_PROCESSES mit folgendem Kommando (Voraussetzung: Parameter-verwaltung mit SPFILE):

alter system set db_writer_processes=X scope=spfile;

Achtung: Die Anzahl der DBWR-Prozesse sollte die Anzahl der vorhandenenCPUs nicht überschreiten.


Performance8

476

Ein weitere Möglichkeit zur Steigerung der Schreibperformance ist natürlichdas Tuning der Oracle-Umgebung, also aller I/O-relevanten Komponenten.Bitte lesen Sie hierzu Abschnitt 8.2.2.3.

Der Wait Event log file switch completion tritt auf, wenn ein Oracle-Schat-tenprozess auf die Beendigung eines Log-Switches warten muss. Kritisch fürdie Datenbankperformance wird es, wenn, wie bereits beschrieben, die Redo-Log-Switches im operativen Betrieb zu häufig (mehr als einmal pro Minute)auftreten. Ist dies jedoch der Fall, gehen Sie wie oben beschrieben vor.

Unter Oracle 9i befanden sich beide Events unter der Bezeichnung bufferbusy wait. Hier beschrieb der Parameterwert 3 die Ursache: Die IDs began-nen mit 1 oder 2 und hatten noch weitere Stellen in Abhängigkeit von dergenauen Ursache. Beginnt die ID mit 1 (ID=1xx), so geht es um das Leseneines Blocks. Fängt sie hingegen mit 2 an (ID=2xx), so liegt die Ursache fürden Wait Event beim Schreiben beziehungsweise Ändern eines Blocks. AbOracle 10g wird bereits im Namen des Wait Events nach der Hauptursache(Lesen oder Schreiben) unterschieden. Die Detailursachen finden sich dannwieder in den Parametern.

Da alle Daten, die aus der Datenbank gelesen oder dort gespeichert werden,»durch« den Data Buffer gehen (mit Ausnahme der bereits erwähnten Direct-Path-Zugriffe), entstehen bei großer I/O-Last immer buffer busy waits.Grundsätzlich besteht zuerst einmal die Möglichkeit, die I/O-Last zu senken,um die Waits auf dem Data Buffer zu verringern. Dies geschieht entwederorganisatorisch, zum Beispiel durch die Umverteilung von Daten-Loads,oder durch das Tuning von SQL-Anweisungen, damit weniger Datenblocksgelesen werden müssen (siehe Abschnitt 8.3).

Name read by other session/buffer busy wait



Parameter 3 ID

Bedeutung Diese Wait Events beschreiben das Warten auf einen Block im Data Buffer, weil dieser gerade gelesen (read by other session) oder geän-dert (buffer busy wait) wird.

Bewertung Die Average Wait Time sollte unter dem Wert von 2, also 2/100s = 20 ms liegen.

Tabelle 8.13 read by other session/buffer busy wait



477

Das zweite Kriterium neben der I/O-Last ist die Verwaltung der Datenblöckeselbst. Und gerade hier hat sich mit der Version Oracle 9i viel getan, denndas Automatic Segment Space Management (ASSM) wurde eingeführt. Vorherwurden die einzelnen Blöcke eines Tablespace beziehungsweise eines Seg-ments durch die Parameter PCTUSED, PCTFREE, FREELISTS und FREELIST-GROUPS verwaltet. Damit wurde zum Beispiel der Füllstand eines Blocks(PCTUSED) definiert, bei dessen Unterschreitung der Block neue Daten akzep-tiert. Einzig der Parameter PCTFREE wurde in seiner Funktion in das ASSMübernommen und gilt daher auch weiterhin.

Der Datenbankadministrator musste oder konnte ohne ASSM im Prinzip fürjede Tabelle entscheiden, wie die einzelnen Blöcke der Segmente genutztwurden und dabei in Abhängigkeit der Änderungshäufigkeit abwägen zwi-schen Performance und effizienter Platznutzung. Dies wird ihm allerdingsdurch das ASSM abgenommen. Der Einsatz von ASSM ist SAP-seitig ab Ver-sion 9.2.0.5 freigegeben, und ab Installationen mit der SAP-Basis 6.40 sindper Default alle Daten-Tablespaces auf ASSM eingestellt. Bei Problemen mitbuffer busy waits besteht daher die Möglichkeit, auf das ASSM umzustellen,um Probleme in Zusammenhang mit der Segmentverwaltung zu beseitigen.Der Umstellprozess ist bei Oracle 9i mit einer Downtime verbunden, ab 10gjedoch online möglich. Eine Schritt-für-Schritt-Anleitung für den Umstiegfinden Sie in SAP-Hinweis 620803.

Treten die bezeichneten Wait Events zu oft auf, liegt dies entweder an einemzu kleinen Data Buffer oder an mangelnder Performance des DBWR-Prozes-ses. Erhöhen Sie daher, wenn möglich, den Parameter DB_CACHE_SIZEund/oder tunen Sie die I/O-Performance (Abschnitt 8.2.2.3). Außerdem kön-

Name write complete waits/free buffer waits



Parameter 3 ID

Bedeutung Diese Wait Events treten auf, wenn ein Oracle-Prozess darauf warten muss, dass der DBWR-Prozess einen Block in die entsprechende Daten-datei geschrieben hat.

Bewertung Beide Wait Events dürfen sich nicht unter den ersten zehn in der Wait-Event-Liste befinden.

Tabelle 8.14 write complete waits/free buffer waits


Performance8

478

nen Sie die Anzahl der DBWR-Prozesse, wie im vorhergehenden Abschnittbeschrieben, erhöhen.

Das Auftreten des Wait Events rdbms ipc reply ist grundsätzlich kein Pro-blem, denn es gibt durchaus Gründe, weshalb auf einen Hintergrundprozessgewartet werden muss. Entscheidend ist daher, wie lange auf den Hinter-grundprozess gewartet wird. Hauptgrund für den Event sind Wartesituatio-nen bei den Operationen BEGIN BACKUP, TRUNCATE und DROP, da dort derCKPT-Prozess einen Checkpoint durchführen muss. Verstärkend kommtunter Oracle kleiner gleich 9i eine Designschwäche hinzu, die dazu führt,dass bei einer DROP- oder TRUNCATE-Operation der gesamte Data Buffer nachbetroffenen Blöcken durchsucht wird, und dies kann bei entsprechenderGröße sehr lange dauern. Dieses Problem ist unter Oracle 10g behoben.

Allgemein ist die Dauer von rdbms ipc reply Wait Events sehr kurz, dahersollte die Average Wait Time nicht größer als 10 sein, sonst gibt es einigedeutlich zu lange Warteperioden, die den Durchschnitt erhöhen. In einemsolchen Fall ist es ratsam, sich den beziehungsweise die Enqueue-Wait-Events anzusehen, denn diese hängen teilweise stark mit demrdbms ipc reply Wait Event zusammen. Bitte beachten Sie dazu den SAP-Hinweis 745639.

Vermuten Sie bei diesem Wait Event ein Problem, so können Sie über denOracle Session Monitor (ST04N � Resource Consumption � Oracle Session)und den View V$SESSION_WAIT herausfinden, welcher Oracle-Workpro-zess auf welchen Hintergrundprozess wartet. In V$SESSION_WAIT findenSie die SID des auf den Wait Event »rdbms ipc replay« wartenden Prozessesund im Parameter 1 (Spalte P1) die PID des Hintergrundprozesses, auf dengewartet wird. Anschließend können Sie über den Session Monitor feststel-len, was der Hintergrundprozess gerade tut. Zur tiefer gehenden Analyse der

Name rdbms ipc reply

Parameter 1 PID des Hintergrundprozesses

Parameter 2 Timeout in Sekunden

Parameter 3 –

Bedeutung Der Wait Event tritt auf, wenn ein Oracle-Schattenprozess auf einen Hintergrundprozess warten muss.

Bewertung Darf auf keinen Fall in den Top 10 der Wait-Event-List zu finden sein.

Tabelle 8.15 rdbms ipc reply



479

Arbeit von Oracle-Prozessen sollten Sie die Möglichkeit des ORADEBUG-Trace nutzen. Die Vorgehensweise finden Sie in SAP-Hinweis 613872.

Ein Latch ist ein Sperrmechanismus für die Speicherstrukturen der SGA aufsehr niedriger Ebene. Ein Latch wird, im Gegensatz zu einem Lock, immernur sehr kurz gehalten. Deshalb werden Latch-Anfragen nicht in einerQueue gespeichert, sondern die anfragenden Prozesse versuchen permanentden Latch aufzunehmen. Dieses sogenannte Spinning läuft so oft, wie imParameter _SPIN_COUNT festgelegt. Wird ein Latch von einem Prozessgehalten und will ein anderer Prozess auf den entsprechenden Speicherbe-reich zugreifen und schafft dies nicht in der Spin-Phase, dann wird ein Latch-<latch_name>-Wait-Event aktiviert. Unter Oracle 10g gibt es 27 Latch WaitEvents, die durch ihren Namen den Ort beziehungsweise die Speicherstruk-tur, in der der Latch eingesetzt wird, spezifizieren. Alle »unwichtigeren« Lat-ches werden unter »latch free« subsumiert.

Bei älteren Oracle-Releases (< 10g) werden alle Waits unter dem Begriff»latch free« akkumuliert. Die Analyse der verschiedenen Latch Wait Eventswürde dieses Kapitel bei Weitem sprengen, daher verweisen wir auf denumfangreichen SAP-Hinweis 767414.

Name latch free/latch: <latch_name>/wait list latch free

Parameter 1 Latch-Adresse

Parameter 2 Latch-Nummer

Parameter 3 Anzahl von Sleeps

Bedeutung Der Wait Event entsteht, wenn auf die Freigabe eines Latches gewartet wird.

Bewertung Die Bewertung hängt stark vom jeweils spezifischen Latch Wait Event ab. Grundsätzlich sollte kein Latch Wait Event in den Top 10 der Wait-Event-Liste auftauchen.

Tabelle 8.16 Latch Wait Events

Name enqueue (9i)/enq: <Typ> - <Beschreibung> (10g)

Parameter 1 Typ

Parameter 2 ID1 (9i)/Detailinformationen in Klartext (10g)

Parameter 3 ID2 (9i)/Detailinformationen in Klartext (10g)

Tabelle 8.17 Enqueue Wait Events


Performance8

480

Last but not least wollen wir kurz einen weiteren wichtigen Oracle WaitEvent vorstellen, der in Zusammenhang mit den Oracle-Datenbanksperren(Enqueues oder auch Locks) steht. Die Bedeutung lässt sich an der Entwick-lung zwischen 9i und 10g erkennen. Noch unter Oracle 9i wurden alleEnqueue-Waits auf einen Event akkumuliert, was eine Analyse umständlichmachte, wohingegen mit 10g genau 184 verschiedene Enqueue-Wait-Eventseingeführt wurden, die sich wiederum in verschiedene Klassen unterteilen(siehe Abschnitt 8.2.2.4, Weitere performancerelevante Aspekte der Oracle-Datenbank; dort beschäftigen wir uns genauer mit den Datenbank-Locks).

8.2.2.3 Analyse des Datenbank-I/O

Wenn Sie in einer der vorangegangenen Analysen einen Hinweis auf Pro-bleme im I/O-Bereich gefunden haben, zum Beispiel durch die Auffälligkeiteines entsprechenden Wait Events, gelangen Sie zwangsläufig zur I/O-Ana-lyse. Unglücklicherweise ist die Untersuchung eines I/O-Systems aus derSicht des SAP-Administrators nur eingeschränkt möglich. Hinzu kommt, dassdie Behebung eines I/O-Engpasses, wenn er von der Hardware oder der Ver-teilung der Daten herrührt, in der Regel nicht während des Betriebes durch-geführt werden kann.

Bedeutung Ein Event dieses Typs entsteht, wenn auf die Freigabe eines Oracle Locks gewartet wird.

Bewertung Die Average Wait Time (von allen Enqueue-Events) sollte unter dem Wert von 10, also 10/100s = 100 ms liegen. Da unter 9i alle möglichen Lock-Situationen unter einem Event gesammelt werden, ist eine untere Top-10-Platzierung in der Redegl unproblematisch. Bei Oracle 10g soll-ten die einzelnen Enqueue-Waits jedoch nicht in den Top 10 auftau-chen, außer TX-»row lock contention«.

Begriffsklärung

Bevor wir in die Analyse einsteigen, soll hier der Begriff Festplatte geklärt werden.Bitte beachten Sie dazu auch Abbildung 8.11. Im Bereich von Serversystemen fürunternehmenskritische Anwendungen, in dem wir uns in der Welt von SAP undOracle bewegen, ist die Festplatte ein Begriff mit zwei Bedeutungen:

� physikalisch: magnetischer Speicher, der Hardwareteil

� virtuell: Ressource des Betriebssystems (Device), der Softwareteil

Name enqueue (9i)/enq: <Typ> - <Beschreibung> (10g)

Tabelle 8.17 Enqueue Wait Events (Forts.)



481

Die folgenden sind die kritischsten Punkte in der Struktur einer Oracle-Datenbank: Die I/O-intensivsten Bereiche sind ohne Zweifel die Redo-Log-Dateien und danach die Datendateien. Von diesen kann man noch einmalspeziell den Undo- (beziehungsweise Rollback-) und den PSAPTEMP-Table-space hervorheben, die immer (Undo) oder speziell im OLAP-Umfeld(PSAPTEMP) erhöhte Zugriffsraten aufweisen. Weniger wichtig sind dieBereiche für die Offline-Redo-Logs und die Oracle-Executables. Bitte lesenSie Abschnitt 5.2.3, Storage und SAN-Infrastruktur, um mehr über die opti-male Verteilung der Oracle-Dateien zu erfahren.

Der erste Punkt für die Analyse wurde bereits in Abschnitt 8.2 angeschnit-ten. Im Betriebssystemmonitor (ST06) haben Sie die Möglichkeit, unterDetail Analysis Menu über den Button Disk die aktuelle Auslastung allerFestplatten des Betriebssystems zu betrachten (siehe Abbildung 8.9).

Abbildung 8.9 Übersicht der Festplatten im Betriebssystemmonitor

Wird hier im Folgenden von Festplatte gesprochen, ist immer die zweite Bedeutungunterlegt, denn das SAP-System beziehungsweise die Datenbank sieht nur dasBetriebssystem mit den entsprechend zur Verfügung gestellten Ressourcen alsunterliegende Schicht. Gleichgültig, ob als Festplatte mit Dateisystem oder als RawDevice sichtbar, verbirgt sich in modernen IT-Infrastrukturen hinter der virtuellen»Festplatte« weit mehr als eine physikalische »Festplatte«. Hinter der Abstraktions-schicht Betriebssystem steckt vielmehr eine komplexe Storage-Architektur mit vie-len verschiedenen Komponenten. All diese Teile eines Storage-Systems, zum Bei-spiel Interface-Karten zu einem SAN, Storage-Switche oder Array-Controller, kön-nen bei I/O-Problemen eine Rolle spielen. Leider haben Sie als SAP-beziehungsweise Oracle-Administrator hier keine Chance, Probleme zu identifizie-ren und zu beheben, sondern sind auf die Hilfe von Spezialisten des Hardwarepart-ners angewiesen. Bitte behalten Sie diese Begriffsdefinition im Hinterkopf und den-ken Sie an den entsprechen Stellen an die »verschleierte« Komplexität des Begriffes.


Performance8

482

Mit einem Doppelklick auf eine der angezeigten Disks erhalten Sie die Aus-lastung der ausgewählten Platte über die letzten 24 Stunden, wobei die wich-tigste Kenngröße Utilization einen Mittelwert über den Zeitraum von einerStunde abbildet (siehe Abbildung 8.10).

Abbildung 8.10 Historie einer einzelnen Festplatte

Wenn Sie über die I/O-Auslastung ein Problem mit einer Festplatte feststel-len, so müssen Sie natürlich identifizieren, welche Teile der Oracle- und SAP-Installation sich dort befinden. Leider lässt sich in der Regel eine direkteZuordnung von Dateien oder Raw Devices zu den Festplatten aus dem SAP-System heraus nicht nachvollziehen. Der Grund liegt in der bereits obenerwähnten Ressource der »virtuellen« Festplatte, die im Betriebssystemmo-nitor angezeigt wird. Zwischen der »virtuellen« Festplatte und den eigentli-chen Dateien befindet sich bei Serversystemen eine weitere Virtualisierungs-schicht wie zum Beispiel der klassische Logical Volume Manager (LVM) beiUNIX-Betriebssystemen. Abbildung 8.11 veranschaulicht den Zusammen-hang der einzelnen Komponenten.

Wenn Sie also die Verbindung zwischen Festplatte und den Oracle-Datenda-teien beziehungsweise Raw Devices herstellen wollen, müssen Sie dafürBordwerkzeuge des Betriebssystems nutzen.

Grundsätzlich haben Sie zwei Möglichkeiten, die I/O-Performance zu erhö-hen: Sie können die Performance der Festplatte(n) erhöhen oder versuchen,die I/O-Last zu reduzieren.



483

Abbildung 8.11 Übersicht eines UNIX-Systems mit Logical Volume Manager

Befassen wir uns zuerst mit den Möglichkeiten, die Festplattenperformancezu steigern. Als Erstes sollten Sie überprüfen, ob Sie alle Möglichkeiten desBetriebssystems für eine optimale Performance genutzt haben:

1. Entspricht das Layout der Struktur Ihrer Oracle-Dateien den Empfehlun-gen, besonders hinsichtlich der Trennung von lastintensiven Dateien(siehe Kapitel 5, Planung der Systemlandschaft)?

2. Haben Sie alle möglichen Optionen der I/O-Verarbeitung genutzt?

3. Sind die aktuellen Treiber für die I/O-Subsysteme installiert?

Ein besonderes Augenmerk sollten Sie auf die Möglichkeiten der I/O-Verar-beitung legen. Prinzipiell stellen alle Betriebssysteme zwei Funktionen fürI/O-Operationen zur Verfügung: zum einen das sogenannte File SystemCaching und zum anderen File-Lock-Mechanismen. Das File System Cachingfunktioniert ähnlich wie der Oracle Data Buffer (nur einfacher) als Zwischen-speicher für den Zugriff von Anwendungen auf die I/O-Systeme. Die FileLocks dienen als Schreibsperre, damit Daten beziehungsweise Dateien nichtparallel von zwei Prozessen geändert werden können. Entscheidend für dieOptionen der I/O-Verarbeitung ist nun der Umgang mit den genannten

interne Fest-

platten

Treiber Treiber

Devices z.B./dev/dsk/c12t0d3

Volume Group

z.B.vg00Volume Group

Logical Volume z.B./dev/vg00/lvol1

Dateisystem z.B. VxFS

Disk Array

Interface- Karte

Anwendungz.B. SAP

Anwendungz.B. Oracle

Raw-

Devic

e-Zu

griff

Dateisystem z.B. HFS

Dateien des Betriebssystems z.B. Root-Verzeichnis (/)

Swap Space

Hardware

Kernel des Betriebssystems

Logical Volume Manager

Anwendungen und Daten

Raw-Device- Zugriff

Storage Network


Performance8

484

Betriebssystemfunktionen. In Tabelle 8.18 finden Sie eine Liste aller Optio-nen in der Reihenfolge ihrer Performance (absteigend).

Neben den genannten I/O-Modi gibt es noch zwei weitere von diesen unab-hängigen Optionen: Synchronous I/O und Asynchronous I/O. Bei der synchro-nen Ein- oder Ausgabe durch einen Prozess muss dieser warten, bis die Ope-ration abgeschlossen ist und kann erst dann weiterarbeiten oder die nächsteEin- oder Ausgabe durchführen. Bei der asynchronen I/O ist dies nicht derFall, sodass der Prozess parallel zur I/O-Operation weiterarbeiten kann.Grundsätzlich sollte möglichst Asynchronous I/O eingesetzt werden.

In SAP-Hinweis 834343 finden Sie eine Tabelle mit den aktuell unterstütztenKombinationen von Betriebssystem, Dateisystem und I/O-Optionen.

Noch eine Bemerkung zu Raw I/O: Im Allgemeinen kann man davon ausge-hen, dass mit Raw I/O eine um ca. 20% bessere I/O-Performance möglich istals mit anderen I/O-Optionen. Warum wird dann nicht immer Raw I/O ver-wendet? Als Hauptnachteil von Raw I/O gilt immer ein deutlich erhöhterAdministrationsaufwand bei der Einrichtung und Verwaltung der Oracle-Datenbank. Allerdings spielt auch ein psychologischer Aspekt beim Einsatzvon Raw I/O eine Rolle: Der Administrator »vermisst« seine Dateien. Doch

Name Bedeutung

Raw I/O Bei der Benutzung von Raw I/O (beziehungsweise Raw Devices) werden die Betriebssystemfunktionen für I/O komplett umgangen, und es wird direkt auf die logischen Volumes oder Festplatten zugegriffen. Es existiert auch kein Dateisystem und entsprechend auch keine Dateien im her-kömmlichen Sinn.

Concurrent I/O Wie bei Raw I/O werden File System Caching und File Locks umgangen, allerdings gibt es ein Dateisystem und damit auch normale Dateien. Das eingesetzte Dateisystem muss natürlich Concurrent I/O unterstützen (zum Beispiel Veritas VxFS). Dieser I/O-Typ ist bei Oracle-Datenbanken möglich, da die Oracle-internen Locking-Funktionen bereits für einen kollisionsfreien Zugriff sorgen und damit die Integrität der Daten sichern. Achtung: Nur Volumes, auf denen sich ausschließlich Oracle-Daten oder Redo-Log-Dateien befinden, dürfen in diesem Modus betrieben werden (also auch nicht die Oracle-Executables)!

Direct I/O Direct I/O deaktiviert nur das File System Caching des Betriebssystems, nutzt aber den Locking-Mechanismus für den Dateizugriff.

Cached I/O Nutzt alle Betriebssystemfunktionen für I/O und ist in der Regel die Stan-dardeinstellung für die I/O-Verarbeitung.

Tabelle 8.18 Optionen der I/O-Verarbeitung



485

auch die Oracle-Empfehlung zum Einsatz von Raw Devices lautet: »Oraclerecommends that raw devices should only be considered when the Oracledatabase is I/O bound.«2

Raw I/O wird von SAP, Oracle und allen relevanten Monitoring- undBackup-Lösungen voll unterstützt und integriert, sodass es vor allem bei per-formancekritischen Installationen, wie zum Beispiel beim SAP BusinessInformation Warehouse, eingesetzt werden kann. Dabei ist es auch möglich,nur Teile der Oracle-Datenbank, zum Beispiel die Redo-Log-Dateien oderden temporären Tablespace, auf Raw Devices zu betreiben.

Für die Nutzung der beschriebenen I/O-Optionen muss der Administratordes Weiteren zwei relevante Oracle-Parameter im Auge behalten:

� DISK_ASYNCH_IO (Default: TRUE)Diese Option bewirkt, dass sobald das Betriebssystem Asynchronous I/Oanbietet, dieses auch genutzt wird.

� FILESYSTEMIO_OPTIONS (Default: Oracle-seitig keiner, aber SAP setzt jenach Version ASYNC (9i) oder SETALL (10g) ein)Dieser Parameter übersteuert DISK_ASYNCH_IO bei der Nutzung von Datei-systemen, und folgende Optionen sind möglich:

� NONEKein Direct I/O und kein Asynchronous I/O.

� DIRECTIOAktiviert Direct I/O.

� ASYNCHAktiviert Asynchronous I/O.

� SETALLAktiviert Concurrent I/O (wenn verfügbar), Direct I/O und Asynchro-nous I/O.

Dies kann zum Beispiel bei Installationen mit der Kombination von RawDevices und Dateisystem genutzt werden, um einerseits auf dem Raw DeviceAsynchronous I/O zu nutzen (DISK_ASYNC_IO=TRUE), aber um andererseitsbei den Dateisystemdaten Cached I/O zu benutzen (FILESYSTEMIO_OPTI-ONS=NONE).

Neben den Optionen für die I/O-Verarbeitung gibt es für die verschiedenenvon SAP unterstützten Betriebssysteme weitere Parameter, mit denen die

2 Oracle empfiehlt Raw Devices nur dann in Betracht zu ziehen, wenn die I/O einen Perfor-manceengpass darstellt. Siehe http://www.oracle-training.cc/oracle_tips_raw_devices.htm


Performance8

486

I/O-Performance beeinflusst werden kann. Als Einstiegspunkt bietet sich derSAP-Hinweis 793113 an, von dem aus zu den einzelnen betriebssystemspe-zifischen Hinweisen verzweigt wird.

Eine weitere Möglichkeit zur Steigerung der Festplattenperformance istnatürlich der Austausch der Hardware. Besonders bei den schon beschriebe-nen komplexen Storage-Systemen, die heute in wichtigen Bereichen einge-setzt werden, gibt es viele Komponenten, die durch den Austausch mit einerneueren Generation deutlich beschleunigt werden können. Ob und wannein solcher Austausch sinnvoll ist, sollten Sie in Zusammenarbeit mit IhremHardwarepartner entscheiden.

Kommen wir nun zu der zweiten Möglichkeit, die I/O-Performance zu erhö-hen: dem Versuch, die I/O-Last zu reduzieren. Dabei ist natürlich zu berück-sichtigen, welche Art von I/O wo auftritt. Tabelle 8.19 gibt Hinweise zur I/O-Reduzierung.

Datentyp/I/O-Typ

Lese-I/O Schreib-I/O

Redo-Log-Dateien

/ � Datendateien beim Backup so kurz wie möglich im Backup-Modus halten (Parameter backup_dev_type)

� Wenn möglich, Verwendung von NOLOGGING

� Vermeidung von lange laufenden Transaktionen mit Timeouts/Rollbacks (da Änderungen unnöti-gerweise pro-tokolliert werden)

� Vermeidung unnötiger INSERT-, UPDATE- und DELETE-Operationen

� Vermeidung unnötiger Indexe

Datendateien � Tuning von teuren SQL-Statements (Abschnitt 8.3)

� Cachen von LOB-Zugriffen (SAP-Hinweis 563359)

� Vergrößerung des Oracle Buffer Pools

� Vergrößerung der PGA

� Zeit zwischen Log-Switches größer als eine Minute

� Verteilung der Datendateien auf ver-schiedene Volumes oder Festplatten


� Vergrößerung des Buffer Pools (bei free buffer waits)

Temporäre Datendateien (PSAPTEMP)

� Tuning von teuren Sortie-rungen mit Sort-, Hash- oder Bitmap-Funktionen


� Tuning von teuren Sortierungen mit Sort-, Hash- oder Bitmap-Funktionen


Tabelle 8.19 Hinweise zur Reduzierung der I/O-Last



487

Auf einen Punkt bei der Reduzierung der I/O-Last wollen wir noch etwasgenauer eingehen, und zwar auf das Verteilen von Datendateien, um dieZugriffe auf einzelne Volumes oder Festplatten zu verringern. Um einen Ein-druck von der Anzahl der Zugriffe auf die einzelnen Datendateien zu erhal-ten, eignet sich »Filesystem Requests« im Oracle Monitor (ST04N � OverallActivity). In Abbildung 8.12 ist der entsprechende View dargestellt, sortiertnach der Anzahl der Read-Zugriffe.

Abbildung 8.12 Zugriffsstatistik für die Oracle-Datendateien

Anhand der Zugriffsstatistiken kann der Administrator nun zum Beispiel dieTop 10 der Datendateien auf unterschiedliche Datenträger beziehungsweiseDatensubsysteme verteilen. Im Folgenden ist das Verschieben von Datenda-teien exemplarisch dargestellt:

1. Loggen Sie sich als sysdba-Benutzer ein. Der entsprechende Tablespacemuss für das Verschieben offline genommen werden:

alter tablespace PSAP<SID> offline;

2. Verschieben Sie die Datei auf Betriebssystemebene (der Einfachheit halberaus der Oracle Shell heraus mit vorangestelltem »!«):

! mv /Pfad mit altem Volume/<sid>.dataX /Pfad mit neuem Volume/<sid>.dataX


Performance8

488

3. Ändern Sie den Pfad in der Datei in der Oracle-Datenbank:

alter tablespace PSAP<SID> rename file‘/Pfad mit altem Volume/<sid>.dataX’ to ’/Pfad mit neuem Volume/<sid>.dataX’;

4. Setzen Sie den Tablespace wieder online:

alter tablespace PSAP<SID> online;

Da die Datendateien in der Regel sehr groß sind und der entsprechende Tab-lespace offline sein muss, ist es nicht möglich, die Verschiebungen bei einemlaufenden SAP-System durchzuführen. Wenn Dateien des SYSTEM- oder desUNDO-Tablespace verschoben werden müssen, dann funktioniert die obenaufgeführte Methode nicht. Stattdessen muss die Datenbank offline sein, umdie Dateien zu verschieben. Anschließend wird im MOUNT-Status der neuePfad zur Datei mit folgendem Kommando bekannt gemacht:

alter database rename file ...

8.2.2.4 Weitere performancerelevante Aspekte der Oracle-Datenbank

Am Ende dieses Abschnitts gehen wir auf zwei weitere sehr wichtige undperformancerelevante Punkte ein: Oracle Enqueues und Oracle-Optimizer-Statistiken

Oracle-Enqueues sind Sperren auf Datenbankebene, die einen konsistentenZugriff auf Oracle-Ressourcen wie Objekte oder Datensätze in Tabellensicherstellen. Wenn ein Oracle-Prozess zum Beispiel einen Datensatz ändernwill, so wird dafür ein Enqueue angelegt, um diese Änderung als atomareOperation zu schützen. Will nun parallel ein zweiter Prozess auf diesemDatensatz ändern, legt er ebenfalls einen Enqueue an, der aber in eine War-teschlange gestellt wird. Die Abarbeitung der Warteschlange erfolgt nachdem FIFO-Prinzip (First in, first out). Oracle-Enqueues werden oft auch alsExclusive Lockwaits oder Oracle Locks bezeichnet.

Tritt ein Enqueue, also eine Lock-Situation auf, so wird ein entsprechenderEnqueue-Wait-Event erzeugt. Grundsätzlich unterscheidet Oracle zwei Artenvon Enqueues, die sich noch einmal nach Typen unterscheiden:

� User-Enqueues sind die Enqueue-Art, die bei »normalen« Datenänderun-gen, zum Beispiel dem Einfügen beziehungsweise Löschen von Datensät-zen oder dem Neuaufbau eines Indexes, auftritt. Hier gibt es drei Typen:



489

� TX (Transaction-Enqueue): Entsteht bei jeder Änderung eines Daten-satzes, wenn auf diese Änderung gewartet werden muss. Dies ist deram häufigsten auftretende Enqueue-Typ.

� TM (DML-Enqueue): Tritt auf, wenn ein komplettes Objekt, zum Bei-spiel ein Index, gesperrt wurde.

� UL (User-Enqueue): Wird erzeugt, wenn ein Benutzer mit DBMS_LOCK.REQUEST selbst eine Sperre setzt. Diese Funktion wird im SAP-Standard nicht eingesetzt.

� System-Enqueues sind die Enqueue-Art, die bei den verschiedenen Ora-cle-internen Verwaltungsmechanismen auftritt. Hier gibt es über 40 ver-schiedene Typen, die jedoch zum großen Teil nicht oder nur wenig rele-vant sind. Der wichtigste Typ im SAP-Umfeld sollte dennoch genannt wer-den: ST (Space-Transaction-Enqueue). Dieser Enqueue entsteht bei derExtent-Verwaltung in DMTS.

Eine Datenbanksperre betrifft meistens eine Zeile einer Tabelle, wenn diesemit update, delete, insert oder select for update geändert wird. SolcheSperren nennt man, wie oben beschrieben, TX-Enqueues. Andere Enqueuessperren zum Beispiel auch ganze Segmente (zum Beispiel TM-Enqueues)oder kritische Pfade (ST-Enqueues). Die gesetzte Sperre wird immer bis zumDatenbankkommando COMMIT gehalten und danach wieder freigegeben. Danach jedem SAP-Transaktionsschritt (Achtung: nicht Transaktion) ein COMMIToder rollback ausgeführt wird, sollten die Datenbanksperren in der Regelnie länger als ein paar Sekunden gehalten werden.

Allgemein sind die Datenbanksperren natürlich wichtig für die Datenkonsis-tenz in der Datenbank, daher ist ihr Auftreten normal und grundsätzlich keinProblem für die Performance. Allerdings gilt dies nur, wenn die Sperrenmaximal so lange gehalten werden, dass es nicht zu Serialisierungseffektenkommt. Dies würde bedeuten, dass immer mehr Prozesse auf die Freigabeeiner Datenbanksperre warten. Beobachten Sie daher in Transaktion ST04N� Exceptional Conditions � Lock Monitor (oder Transaktion DB01) den OracleLock Monitor. Achtung: Dort sehen Sie nicht die aktuellen Sperren, die inder Oracle-Datenbank gehalten werden, sondern nur die Lockwaits, also dieangeforderten Locks, die nicht sofort zugeteilt wurden, sprich, auf diegewartet wird. Für Informationen über die aktuellen Datenbanksperren eig-nen sich die Views V$LOCK und V$LOCKED_OBJECT. In Abbildung 8.13sehen Sie diese beiden Views – aufgerufen ebenfalls über Transaktion ST04N� Additional Function � Display V$/GV$ Views and Values.


Performance8

490

In der Abbildung ist zu sehen, wie der Oracle-Prozess 31 (Session-ID) dasObjekt mit der ID 18992 sperrt. Aus V$LOCKED_OBJECT ist zu erkennen,dass es sich um einen TM-Enqueue in Modus 3 handelt. Außerdem zeigtV$LOCK, dass Prozess 31 noch einen TX-Enqueue in Modus 6 hält.

Der Modus gibt an, wie restriktiv das Objekt gesperrt ist. In der folgendenTabelle 8.20 sind die möglichen Modi einer Sperre aufgeführt.

Abbildung 8.13 Locks der Oracle-Datenbank

Die Beschreibung der einzelnen Modi mit ihren Auswirkungen würde meh-rere Seiten füllen. Daher verweisen wir auf die Oracle-Dokumentation unterhttp://www.oracle.com/pls/db102/homepage � Concepts � Data Concurrency

Modus Name

0 nicht gehalten oder nicht angefordert

1 Null Mode

2 Row Shared Table Locks (RS)

3 Row Exclusive Table Locks (RX)

4 Shared Table Locks (S)

5 Shared Row Exclusive Table Locks (SRX)

6 Exclusive Table Locks (X)

Tabelle 8.20 Modi der Oracle Locks



491

and Consistency. Kurz erläutern wollen wir nur den grundsätzlichen Unter-schied zwischen Shared und Exclusive Locks:

� Ein Exclusive Lock schützt eine Ressource vor einem Shared oder anderenExclusive Lock. Er wird gesetzt, wenn die Ressource geändert werden soll.Der erste Prozess, der einen Exclusive Lock auf eine Ressource anfordertund erhält, ist der einzige Prozess, der an der Ressource etwas ändernkann, bis er den Lock auflöst.

� Ein Shared Lock auf eine Ressource erlaubt auch andere Shared Locks aufdiese Ressource, aber er verhindert einen Exclusive Lock auf dieselbe. Dasbedeutet, dass auf eine Ressource mit Shared Lock kein Schreibzugriffmöglich ist, sie also konsistent gelesen werden kann.

Diese Prinzipien werden bei den einzelnen Modi auf Tabellen- und Zeilen-ebene verknüpft.

Kommen wir noch einmal zurück zum Beispiel aus Abbildung 8.13. Wasgeschieht hier? Nun, wie beschrieben, hält der Prozess 31 einen Lock mitModus 3 auf Tabelle 18992, das heißt, er hat einen Shared Lock auf diegesamte Tabelle (TM-Enqueue) und will dort Zeilen ändern. Dies entsprichtauch der Bedeutung von Modus 3 – Row Exclusive Table Locks. Das Ändernder Zeilen selbst bedingt natürlich noch einen Exclusive Lock auf die ent-sprechende Zeile, und dies ist ebenfalls in V$LOCK zu erkennen, denn derletzte Eintrag zeigt, dass Prozess 31 einen Exclusive Lock (Modus 6) auf eineZeile (TX-Enqueue) hält. Dies alles bedeutet nichts anderes, als dass der Pro-zess 31 Einträge in der Tabelle 18992 vornimmt oder ändert.

Welcher SAP-Workprozess mit dem Oracle-Prozess 31 verbunden ist, erfah-ren Sie über den Oracle Session Monitor (ST04N � Resource Consumption �Oracle Session, siehe auch Kapitel 4, SAP und Oracle). Welches Objekt sich hin-ter der Objekt-ID verbirgt, können Sie mit folgendem SQL-Befehl ermitteln:

SQL> select object_name, object_type from dba_objects where object_id=41733;

Werfen wir zum Abschluss noch einmal einen Blick auf den View V$LOCKund dort speziell auf die Spalte Lock Mode in Abbildung 8.13. (Achtung:Diese bitte nicht mit der gleichnamigen Spalte in V$LOCKED_OBJECT ver-wechseln.) In dieser Spalte steht der Modus eines angeforderten Locks, dasheißt, steht hier ein Wert > 0, wartet der Prozess auf einen Lock vom ModusLock Mode, den er angefragt hat. An dieser Stelle erkennt man also einenLockwait. Ein solch angeforderter, aber nicht erteilter Lock, würde dann, wie


Performance8

492

oben bereits beschrieben, auch vom Oracle Lock Monitor (Transaktion DB01)im SAP-System angezeigt werden. Des Weiteren können Sie über einen Ver-gleich der Spalten Lock ID1 und Lock ID2 (Objekte) auch den Oracle-Prozessermitteln, der den Lock auf das »begehrte« Objekt hält (Lock Mode=0).

Entdecken Sie also Oracle-Sperren, die länger gehalten werden beziehungs-weise auf die gewartet wird, so sollten Sie über den Client-Host und die Cli-ent-ID den SAP-Workprozess identifizieren, der die Sperre verursacht.Anschließend können Sie feststellen, welches Programm unter welchemUser die Sperre setzt und nicht wieder freigibt. Eine weitere Analyse kanndann mithilfe des Anwenders und/oder des Entwicklers erfolgen.

Können Sie keinen SAP-Prozess zur Sperre identifizieren, so gibt es zweiMöglichkeiten: Erstens, der SAP-Workprozess wurde abgebrochen und der»angehängte« Datenbank-Schattenprozess nicht richtig beendet. In diesemFall können Sie die Sperre von Hand löschen, indem Sie den entsprechendenDatenbank-Schattenprozess mit Bordmitteln des Betriebssystems beenden.(Vorsicht: Beenden Sie nicht einen falschen Datenbank-Schattenprozess odergar einen der Oracle-System-Prozesse!) Um einem solchen Fall vorzubeugen,können Sie den Parameter SQLNET.EXPIRE_TIME in der Datei sqlnet.ora set-zen, der für eine automatische Bereinigung abgebrochener Sessions sorgt.Nähere Informationen finden Sie in SAP-Hinweis 20071. Zweitens könntedie Sperre auch von einem externen Prozess beziehungsweise dessen »ange-hängtem« Datenbank-Schattenprozess gehalten werden.

Für weitere Informationen zu den Oracle-Enqueues verweisen wir auf dieentsprechenden Oracle-Dokumentationen und den SAP-Hinweis 745639.

Ein weiteres entscheidendes Performancemoment liefern die Tabellenstatisti-ken der Oracle-Datenbank. Der Oracle-Datenbank-Optimizer hat die Auf-gabe, bei einem Zugriff auf die Daten den optimalen, das heißt, schnellstenZugriffspfad zu wählen. Prinzipiell gibt es zwei Arten von Optimierern: denRule-Based Optimizer (RBO) und den Cost-Based Optimizer (CBO). Der RBOberechnet die Zugriffspfade nach Regeln, die von der »where«-Klausel der zuoptimierenden SQL-Anweisung abgeleitet werden. Da jedoch heute bei allenDatenbanken unter SAP-Systemen der CBO zum Einsatz kommt, ist dasgenaue Verfahren des RBO für uns nicht weiter interessant. Einzige Ausnah-men waren die R/3-Systeme Version 3.x oder niedriger auf Oracle niedrigerals 7.3.3, da dort aufgrund von technischen Problemen mit dem neu einge-führten CBO die SAP-Anwendungen für den RBO entwickelt wurden.



493

Der Cost-Based Optimizer berechnet den Zugriffspfad zu den Daten auf derBasis der für den Zugriff erforderlichen Kosten. Bei Oracle erkennen Sie dieNutzung des CBO am Parameter OPTIMIZER_MODE. Bei SAP-Systemen auf Ora-cle 9i hat dieser den Wert CHOOSE, der festlegt, dass der CBO immer genutztwird, wenn Statistiken für eine Tabelle vorhanden sind und anderenfalls derRBO zum Einsatz kommt. Ab Oracle 10g wird der RBO nicht mehr unter-stützt, sodass ausschließlich verschiedene Stufen des CBO zur Auswahl ste-hen. Der SAP-Standard für den Parameter ist daher ab 10g der Wert ALL_ROWS.

Wie die Zugriffskosten genau definiert werden, ist datenbankabhängig. BeiOracle-Release kleiner gleich 9i werden die Kosten ausschließlich über die zulesenden Blöcke bestimmt, wohingegen ab Oracle 10g mehrere Kennwerte(Single Block Reads, Multi Block Reads und CPU) zur Kostenbestimmungherangezogen werden. Die genaue Arbeitsweise des CBO wird von Oraclegeheim gehalten. Eine Erläuterung und Zusammenfassung zu den bekanntenFakten rund um den CBO finden Sie in SAP-Hinweis 750631 – Faustformelnzur Kostenberechnung des CBOs. Um es an dieser Stelle kurz zusammenzufas-sen: Entscheidend ist, dass die Kosten größtenteils aufgrund von Tabellensta-tistiken errechnet werden und daher die Erzeugung dieser Statistiken einewichtige Aufgabe des Administrators ist.

Die Erstellung der Optimizer-Statistiken erfolgt in zwei Schritten:

1. Analyse der Tabellen

2. Erstellung der Statistiken

Im ersten Schritt werden alle Tabellen der Datenbank analysiert, um festzu-stellen, für welche Tabelle die Statistiken erneuert werden müssen. Da dieeigentliche Erstellung der Statistiken sehr ressourcenintensiv ist, verhindertdieses zweistufige Verfahren, dass unnötig neue Statistiken erstellt werden,wenn sich der Inhalt einer Tabelle kaum verändert hat. SAP empfiehlt drin-gend, für die Erstellung der Optimizer-Statistiken ausschließlich die SAP-Werkzeuge zu verwenden, da diese speziell auf die Anforderungen der SAP-Software an die Oracle-Datenbank angepasst sind. Die bereits in Kapitel 4vorgestellten BR*Tools können für die Statistikerstellung entweder per Kom-mandozeile aufgerufen werden (als Benutzer <sid>adm)

brconnect -u / -c -f stats -t [<TABLESPACE_NAME>|ALL]

oder über den DBA-Einplanungskalender (Transaktion DB13) eingeplantwerden (siehe Abbildung 8.14).


Performance8

494

Abbildung 8.14 DBA-Einplanungskalender

Weitere Informationen zum DBA-Einplanungskalender finden Sie in Kapitel9, Systembetrieb und Monitoring.

Für jeden Durchlauf der BR*Tools, folglich auch für jeden Lauf der Tabellen-analyse und Statistikerstellung, finden Sie eine entsprechende Log-Datei inder Protokollanzeige für DBA-Operationen (Transaktion DB14). Dort gehenSie über den Button BRCONNECT und sehen dann alle BRCONNECT-Protokolle.Die Protokolle für das Update der Optimizer-Statistiken erkennen Sie an derBeschreibung beziehungsweise am Kürzel »sta« in der Spalte FID. Per Dop-pelkick können Sie dann die Protokolldatei einsehen und finden dort fürjede Tabelle, deren Statistik neu berechnet (method = C) oder geschätzt(method = E) wird, einen Eintrag, zum Beispiel:

BR0881I Collecting statistics for table SAPA22.CCMSBIDATA with method/sample C ...BR0881I Collecting statistics for table SAPA22.CPRTYPET with method/sample E/P30 ...

Welche Tabelle der Oracle-Datenbank überhaupt analysiert wird und wiedies geschieht, wird durch zwei Aspekte gesteuert:



495

� Am wichtigsten sind die Regeln, die fest im Programm BRCONNECT pro-grammiert sind. Diese lauten:

� Zuerst wird ermittelt, ob neue Statistiken nötig sind (Anhand derAnzahl von geänderten Tabellenzeilen), dann erfolgt die eigentlicheStatistikerstellung (Zwei-Phasen-Konzept).

� Keine Statistiken auf Pool- und Cluster-Tabellen für Oracle ≤ 9i.

� Genauigkeit der Statistiken in Abhängigkeit von der Anzahl der Ein-träge in der Tabelle etc.

� Der zweite Aspekt ist der Inhalt der Tabelle DBSTATC. Über diese Tabellekann der Systemadministrator auf die Statistikerstellung für einzelneTabellen Einfluss nehmen, daher wird sie auch als Ausnahmetabellebezeichnet. In jeder Zeile von DBSTATC werden die Parameter für denLauf zur Statistikerzeugung für eine bestimme Tabelle festgelegt. DiePflege der Tabelle DBSTATC erfolgt über die Transaktion DB21 (sieheAbbildung 8.15).

Abbildung 8.15 Auszug aus der Tabelle DBSTATC

Tabelle 8.21 gibt Aufschluss über die Bedeutung der wichtigsten Spalten derTabelle DBSTATC.

Spalte Bedeutung

Datenbankobjekt Name der Tabelle

Verwendung A = Application Monitor (ST09) und Optimizer

O = nur für den Optimizer

Tabelle 8.21 Spalten der Tabelle DBSTATC


Performance8

496

Des Weiteren können Sie in der Tabelle DBSTATC natürlich neue Tabelleneinpflegen, die beispielsweise durch Entwicklungen angelegt wurden. Wei-tere Informationen zur Pflege der Tabelle DBSTATC finden Sie in SAP-Hin-weis 106047.

8.2.3 Analyse des SAP-Systems

Nach der Analyse von Hardware und Betriebssystem sowie Oracle-Daten-bank kommen wir nun zur Analyse des SAP-Systems oder genauer gesagt,der einzelnen Instanzen des SAP-Systems.

Die performancerelevanten Kriterien einer SAP-Instanz wollen wir etwasvereinfacht in zwei Bereiche unterteilen:

1. Konfiguration der Merkmale einer Instanz, zum Beispiel die Anzahl undArt der Workprozesse oder noch wichtiger die Speicherkonfiguration derInstanz

2. Konfiguration der SAP-Puffer, also die Analyse und Administration derTabellenpufferung, der Nummernkreis- und Programmpufferung unterweiteren internen SAP-Puffern

In den folgenden Abschnitten wollen wir diese Bereiche kurz vorstellen undeinen Überblick über die wichtigsten Möglichkeiten und Einstellungen geben.

Aktiv Steuert, ob die Statistiken für die Tabelle erneuert werden. Mögliche Werte sind zum Beispiel:

� A: Aktiv (wird überprüft und, wenn nötig, aktualisiert)

� I: Ignorieren

� U: Erzwungen (Statistiken werden immer aktualisiert)

� N: Keine Statistiken

� R: Nur kurzzeitige Statistiken

ToDo Erzwingt ein einmaliges Erzeugen der Statistik.

Methode Wie wird die Statistik erzeugt? Entweder durch exakte Analyse der gesamten Tabelle (C) oder durch Schätzung nach den Verfahren <Probe> (E).

Probe Hier gibt es zwei Möglichkeiten:

� P <n> – n = Prozent der Tabellenzeilen werden analysiert

� R <n> – n×1.000 Tabellenzeilen werden analysiert

Spalte Bedeutung

Tabelle 8.21 Spalten der Tabelle DBSTATC (Forts.)


869

Index

28-Tage-Sicherungszyklus 71064 Bit 271

Betriebssystem 272Datenbank 273Hardware 272Software 271

A

ABAP 34, 60Dictionary 62, 516Dump 574Framework 34, 60Prozessor 45Puffer 41, 45Report 35Support Package 395Workbench 300, 339

ABC-Analyse 70Abhängigkeitsanalyse 797abort 144Abweichungsanalyse 797ACID-Eigenschaften 33, 50, 73, 146Add-on Installation Tool 395, 405Administrator Workbench 809Admin-Option 154After-Image 597, 614Aggregatfunktion 84Aggregation 793Ajax 129Aktionsprotokoll 364Alert-Log 148, 619algebraische Optimierung 138all_ 109ALL_ROWS 144alter table 79, 81Analytic Workspace 803, 807Analyze-Kommando 143Änderungsauftrag 317

Freigabe 346lokaler 333

Anfragebearbeitung 99, 136Anfrageoptimierung 136Anfragesprache 82Anmeldeverfahren 207

Antwortzeit 581Anwendungsdaten 305Application Service Provider 38, 263Applikationsschicht 37Applikationsserver 37, 39

Prozess 39Speicherstruktur 41

ARCH 98ArchiveLog-Modus 601

aktivieren 602Online-Datensicherung 612

Archiver Stuck 549, 603, 643, 653Vermeidung 606

Archiver-Prozess 600Archiver-Verzeichnis 101, 145, 146,

602, 653, 726Änderung 606

Archiving 98, 101, 423ARIS 811AS SYSDBA 92ASCII-Terminal 30ASM → Automatic Storage ManagementASSM → Automatic Segment Space

Managementasynchrone Verbuchung 50Asynchronous I/O 484ATO → Automatic Tuning OptimizerAttribut 77, 813Aufgabe 320Aufgabentyp 344Aufzeichnung von Änderungen 315

mandantenabhängig 315mandantenunabhängig 316

Ausführungsplan 125, 140, 513, 520, 525

Auslieferungsmandant 306Authentifizierung 131autoallocate 115autoextent 111Auto-Join 84Automatic Segment Space Management

(ASSM) 115, 477Automatic Shared Memory Management

(ASMM) 454


870

Index

Automatic Storage Management (ASM) 89, 105, 802

Automatic Tuning Optimizer (ATO) 136

B

BACKINT 638, 652Disaster Recovery 671Oracle Recovery Manager 680Split-Mirror-Datenbank 724Volume Management 674

Backup 122, 144, 277, 383Dauer 551differenzielles inkrementelles 151Domain Controller 324Größe 551inkrementelles 150kumulatives inkrementelles 151Level 150Mechanismus 75Offline 150, 423Online 150Protokoll 551Scheduler 152Split-Mirror 279Strategie 278, 709Technik 149Zeit 75

Band → VolumeBandsicherung 145BAPI (Business Application Programming

Interface) 63, 64Basis-Extent 112Basisoperationen 71Batch-Betrieb 32Batch-Input-Mappen 48Batch-Workprozess 40, 48B-Baum 528bdump 148Bedienungsfehler 145Before-Image 615Belieferungssystem 328Belieferungsweg 327Benutzer 153Benutzerkontext 47Benutzerprozesse → User-ProzessBerechtigung (Oracle) 213, 217Beschreibung 797betrieblicher Prozess 28

Betriebsart 384Betriebsartenumschaltung 48Betriebsmodus 600Betriebssystem 187, 595

Benutzer 215Kernel 173, 187Monitor 444, 481Patch 187Wartung 416

Betriebssystembenutzer 191, 209Betriebssystemgruppe 192, 208

dba 192oper 192sapsys 192

betriebssystemspezifische Umgebungsva-riable 198, 202

betriebswirtschaftliche Transaktion 33Bewegungsdaten 507, 824BEx Analyzer 828BEx Map 832Beziehung 77BI 787BIGFILE 115Bitmap 114

Index 528, 803Join-Index 803Tablespace 114

Blade-Technologie 38Blockgrenze 128Block-Split 615Bootstrap 743, 751BR*Tools 57, 96, 152, 233, 398, 588,

629allgemeine Optionen 237Attended versus Unattended Mode 238Betriebssystembenutzer 236BRCONNECT 245BRGUI 243BRSPACE 249, 256BRTOOLS (Frontend) 241Informationen 236Konfigurationsdatei 237Log-Dateien 239Oracle Recovery Manager 680, 684SAPDBA 234Standby-Datenbank 719temporärer Tablespace 668Windows-Umgebung 672

Brandschutz 290


871

Index

BRARCHIVE 630, 643Bandlaufwerk 646Datenbankobjekt 644detaillierte Protokolldatei 650Kompression 651kontinuierliches Sichern 646Oracle Recovery Manager 680Sicherungsgerät 652Sicherungsmodus 644Split-Mirror-Datenbank 724Standby-Datenbank 652, 719summarische Protokolldatei 647unbeaufsichtigt 652Verifikation 652Volume 674

BRBACKUP 630, 632Benutzer 641Datenbankobjekt 634Komprimierung 639Oracle Recovery Manager 680Parallelisierung 639Sicherungsgerät 638Sicherungsmodus 635Sicherungstyp 637Split-Mirror-Datenbank 724Split-Szenario 725Standby-Datenbank 719unbeaufsichtigt 641Verifikation 642Volume 674Volume Management 640

BRCONNECT 589BRRECOVER 630, 660

Benutzer 664detaillierte Protokolldatei 665Disaster Recovery 669Nacharbeiten 666Parallelisierung 662Sicherungsgerät 662Strukturänderung 664summarische Protokolldatei 665unbeaufsichtigt 663Wiederherstellungsszenario 662

BRRESTORE 630, 654Benutzer 658Datendatei 656detaillierte Protokolldatei 659Komprimierung 657Parallelisierung 657

Redo-Log-Datei 656Sicherungsgerät 655summarische Protokolldatei 659unbeaufsichtigt 657Verifikation 658Volume 657Wiederherstellungsmodus 655

BRTOOLS 602, 630BSP → Business Server PageBTC → Batch-WorkprozessB-Tree-Index 837Buchungskreis 36Buffer busy wait 476Bugfix 409Business Add-in 301Business Application Programming Inter-

face (BAPI) 63Business Content 810Business Explorer 809, 828Business Intelligence 30, 787Business Server Pages (BSP) 63, 282Busy Wait Time 452, 456, 465

C

Cached I/O 484Calendar 503CBO → Cost-Based OptimizerCBS → Component Build ServiceChange and Transport System (CTS) 312

Initialisierung 316Change Management Service (CMS) 769Change Request → ÄnderungsauftragCheckpoint 100, 122, 597Checkpoint not complete 474Checkpointer 97, 101, 598CKPT → CheckpointerClient-/Server-System 29Client-Bibliothek 90Client-Prozess 131Clustering 797CMS → Change Management ServiceCodd’sche Regeln 70Cold Backup → Offline-DatensicherungCollector-Job 583COMMIT 103

schnelles 100Compliance 29


872

Index

ComponentBuild Service 769Development 771Partitionierung 802Software 771Support Package 396

compute_statistics 141Concurrent I/O 484Config Tool 734Conflict Resolution Transport 396CONNECT 154Connection-Pooling 135Constraint 89Control-Datei 119, 121, 148, 598, 687,

688Cost-Based Optimizer (CBO) 492, 558count 83CPU 537, 580

Auslastung 446, 448Time 452, 456, 465

create any table 154create index 140create session 154create table 79, 81Critical Patch Update 414CUA 503Cube 806Cursor 62Customizing 35, 301

Auftrag 317Daten 304, 508Tabellen 511

D

DataBuffer 453, 455, 456, 458Cleansing 792, 807Cube 793Definition Language (DDL) 80Dictionary 87, 127, 137Manipulation Language (DML) 80Mart 795, 799, 804Mining 789, 797Pump 800Warehouse 789Warehousing Workbench 809

DatabaseCreation Assistant (DBCA) 96

Point-in-Time Recovery 627Reset 625Writer 97, 100, 596

DataSource 755, 821Datei, flache 820, 827Datei-Cache 105Dateisystem

Caching-Mechanismus 105lokales 104

DatenBereinigung 792Datei 145, 348, 593Definitionssprache 79, 80Element 62Export 609Fluss 825Integration 798Manipulationssprache 79Modell 76, 811Modellierung 76Paket 515Puffer 126Pumpe 790Qualität 807Schutz 153Sicherheit 57, 70, 75, 144, 147Sicherungsmethode 608Speicherung 37Typ 62, 79Würfel 793Ziel 808

Datenart (Datenbankobjekt) 225, 507Datenbank

Benutzer 173, 205, 216Check 245Export 555Interface 506Konsistenz 553Managementsoftware 17Objekt 153, 593, 634, 644Puffer 596Puffer-Cache 102Reorganisation 87Schicht 37Schnittstelle 45Sperre 489Standby 557Statistik 559Strukturen 107


873

Index

Wachstum 673Datenstamm, initialer 35db file parallel read 469db file scattered read 469db file sequential read 469DB LUW 50DB_BLOCK_BUFFERS 454DB_CACHE_SIZE 453DBA 154

Einplanungskalender 493, 554, 556Views 109

dba_data_files 108dba_lmt_free_space 116DBCA → Database Creation AssistantDBMS_STATS 143, 848dbms_xplan 140DB-Reconnect 176, 212DB-Release 90DBSID → Oracle-System-IDDBSL Client Library → SAP-Datenbank-

BibliothekDBSNMP 157DBSTATC 495DBVerify 554DBWR 97, 100, 126, 127DD-Cache 455DDIC-Benutzer 49DDL 79, 80Deadlocks → Lock-KonfliktDedicated Server 129Dedicated-Server

Prozess 99, 131Default-Profil 54, 166Default-Tablespace 210delete_from 82Delta

Abgleich 804Queue 827Upload 826Verfahren 826

demilitarisierte Zone (DMZ) 295Deployment 60, 736, 772Design Time Repository (DTR) 769deskriptive SQL-Anfrage 136Development Object 771Development Task 769Dialogbetrieb 29Dialog-Workprozess 40, 44, 596Dicing 797

Dictionary Cache 103, 460, 518Dictionary Managed Tablespace (DTMS)

108, 111Dictionary-Statistik 559Dimension 793, 810, 817Dimensions-ID 814Direct I/O 484direct path read 457, 470direct path read temp 470direct path write 457, 470direct path write temp 470direct path-Operation 457, 471Direct-hand-off-Verfahren 131dirty 101, 128Disaster Recovery 661, 669

Protokollierung 671Voraussetzung 670

DISK_ASYNCH_IO 485Disp+Work-Programm 39Dispatcher 40, 42, 98, 567

Queue 42, 569DML 80DML-Enqueue (TM) 489DMTS 108, 111, 840DMTS/P → TablespaceDMZ → demilitarisierte ZoneDO → Development ObjectDomain Link 357Downtime 420, 434Downtime-minimized 423dpmon 569dreischichtige Client-/Server-Architek-

tur 36Drill-across 797Drill-down 797, 806drop any table 154drop table 79, 81DTR → Design Time RepositoryDummy-Datei 606, 727Duplikat 792Dynamisierung 89Dynpro 34Dynpro-Prozessor 44

E

EarlyWatch 307Easy-Access-Menü 34E-Business 30


874

Index

E-Commerce 30, 150Einbettung von SQL 34Einführungsleitfaden → Implementation

GuideEinrechnerkonfiguration 37Endemarkierung 354ENQ → Enqueue-ProzessEnqueue 479, 565

Lock 566Prozess 40, 51Replication-Server 566Service 735

ensmon 565Enterprise Core Component (ECC) 31Enterprise Extension Set 31Enterprise Java Beans 64Entität 77Entity Relationship (ER)

Diagram 77Modell 76, 811Schema 77

Entwicklerschlüssel 61, 340Entwicklung 302Entwicklungsklasse 61Entwicklungslandschaft 145Entwicklungspartnerschaft 29Entwicklungssystem 308, 715Entwicklungsumgebung 34Entwurfsprozess 78EP → Enterprise Portalergonomische Darstellung 30erweitertes SAP-Sternschema 813

Dimensions-ID 814Surrogat-ID 814

ETL-Prozess 790, 799, 808, 820Exception Reporting 831Exclusive Lock 491Exclusive Lockwaits 488Executables 119, 120Exp/Imp SHM 504Expertenmodus 378Expertensystem 137explain_plan 140Export 800Export/Import 504Extended Memory 498, 500Extent 111Extraktion 790

F

Fachterminologie 32Failover 287Faktoren, externe 592Fast-Refresh-Mechanismus 804Fat Client 36FC → Fibre ChannelFehlerklasse 592Fehlerszenario 623, 687

Control-Datei 687, 688Offline-Redo-Log-Datei 705Online-Redo-Log-Datei 698, 704Online-Sicherung 706Redo-Log-Gruppe 700Rollback-Tablespace 694System-Tablespace 694Tablespace 623temporärer Tablespace 696

Fibre Channel (FC) 277Field Descriptions (FTAB) 503File System Cache 449FILESYSTEMIO_OPTIONS 485Firmware 416FIRST_ROWS 144Flashback-Intervall 152Flashback-Recovery-Log 152Flash-Backup-Technologie 152föderiertes Datenbanksystem 792Fortschreibung

direkt 823flexibel 823Regel 822

Fragmentierung 116externe 116interne 117

free buffer waits 477Free-Liste 113Fremdschlüssel 79Fremdsystem 820Frequent Itemset 806Frontend 435Full Restore and Complete Recovery 628Full Upload 826Fünf-Schichten-Architektur 86

G

Galaxy-Schema 796


875

Index

Gateway 571Monitor 572Prozess 41, 52

Generic Request and Message Genera-tor 758

Geo-Merkmal 832Gesamtantwortzeit 451gesetzliche Vorschriften 29, 144Granularität 819Grid Computing 89GRMG → Generic Request and Message

Generatorgroße Datenbank

Hardware 712Sicherung 711

Größenklasse (Datenbankobjekt) 225Großrechner 29group by 84grouping 806Gruppierung 84, 527gwmon 571

H

HA → HochverfügbarkeitHardwarefehler 592Hash

Gruppierung 140Join 139, 802Partitionierung 802Verfahren 528

HASH_AREA_SIZE 461Hauptspeicher 145, 449having 85Heap Memory 498, 501Heterogenität 791Heuristik 139Hierarchie 813, 817Hint 137, 144Hintergrundjob 384, 582Hinweiskorrektur 394Hitratio 452Hochverfügbarkeit 51, 264, 268, 287,

373Lizenz 383

Hot Backup → Online-DatensicherungHP-UX 417HTML 63

I

I/OAnalyse 480Konfiguration 846Last 447, 450, 482, 486Modi 484Performance 105, 127, 482

ICM → Internet Communication Mana-ger

Idle Wait Event 464IDoc (Intermediate Document) 67Implementation Guide 300, 334Import 800

Monitor 350Puffer 353Queue 348, 353Übersicht 348

Index 72, 87, 137, 528Range-Scan 142Rebuild 252

Individualsoftware 28, 300InfoCube 818InfoObject 816InfoPackage 822InfoProvider 808InfoSet 829InfoSource 821init.ora 103, 120init.sap 632Initial Record 503insert_into 82Installation

Phasen 369, 373Planung 119Werkzeuge 369

Instance Recovery 598Instant Client 129, 134, 749Instanz 37, 52

Name 52Nummer 373Profil 54, 166

Integration 28, 71, 789Integration Engine 790Integrationsplattform 37Integrationssystem 328Integritätskontrolle 72Integritätsregeln 79Interactive Query Language (IQL) 80


876

Index

Interface 741Interim-Patch 409, 418

Critical Patch Update 414Installation 413Merge Patch 409MOPatch 415OPatch 413

Intermediate Document (IDoc) 67Internet Communication Manager (ICM)

31, 730Internet Graphics Service 397Internet Transaction Server (ITS) 65, 281

integrierter 281IPC 130, 133IQL 80ISO/OSI-Sieben-Schichten-Modell 130isqlplus 93, 94ITS → Internet Transaction Server (ITS)

J

J2EECluster 738Engine 733Server 732Spezifikation 732

Java 64Cluster 730Connector 67, 730Pool 453Schema 748Stack 730Startup- und Control-Framework 743,

781Support Package 396Support Package Manager 395, 773,

776Upgradeprogramm 773, 778

JAVA_POOL_SIZE 453JCMon 746, 763JCo → Java Connectorjcontrol 743JDBC-Treiber 747jlaunch 743JNDI 755Jobs

Protokoll 583Join 80, 83, 519JPREPARE 426JSPM → Java Support Package Manager

K

Kardinalität, hohe 819Katalog 72Keep Pool 458Kennzahl 793, 817, 830Kernel 578Kernel-Parameter 103Klammerung 817Klassifikation 798klassisches Sternschema 812Klimatisierung 264, 265, 266Kommunikation SAP – Oracle 176Kommunikationshardware 450Kommunikationsstruktur 821Komponentenmodell 771Komprimierung 674

BRARCHIVE 651BRBACKUP 639

Konfigurationsdatei 120Konsistenz

Archive-Log 557Spooler 586TemSe 586

Konsolidierungssystem 328Konsolidierungsweg 327Kontrolldatei 348Kopierprofil 388Korrektur 342kostenbasierte Auswahl 139Kundennamensraum 61, 340Kurz-Dump → ABAP-Dump

L

Laden 793Langzeitspeicherung 711Large Objects 115Large Pool 453LARGE_POOL_SIZE 453Lastbalancierung 52Lastverteilung 135Latch 479latch free 479Laufzeitanalyse 521Laufzeitmessung 523LCK 98LDAP 153Least Recently Used (LRU) 100Least-Recently-Used-Block 597


877

Index

Lebenszyklus 394Level-0-Sicherung 681Level-1-Sicherung 682lgtst 565LGWR 97, 100, 127, 128, 152Library Cache 459Librarys 741like 83Line-Item 819Linux 416Listener 131listener.ora 132List-Partitionierung 802LISTSCHEMA 828LMTS → Locally Managed TablespaceLMTS/T → Locally Managed TablespaceLOB 115Locally Managed Tablespace (LMTS)

108, 114, 840, 845Lochkartenstapel 29Lock-Konflikt 557log buffer space 463, 471log file parallel write 471log file switch completion 473log file sync 471Log- und Trace-Datei → ProtokollLOG_BUFFER 454LOG_DIRECTORY_LISTENER 132LOG_FILE_LISTENER 132Log-Datei 74, 75Logical Read 452Logical Unit of Work (LUW) 43, 49, 74Logical Volume Manager (LVM) 105,

482Login-Shell 193logische Optimierung 138Logon-Gruppe 563Log-Sequence-Number 124, 599, 607Log-Switch 122, 124Log-Writer 97, 100, 146, 597lokale Mandantenkopie 388LRU-Algorithmus 100LRU-Verfahren 102, 103lsnrctl 135Luftfeuchtigkeit 267LUW → Logical Unit of WorkLZ-Analyse 528

M

Maintenance Optimizer 397Maintenance-Release 91Mandant 36, 303, 387

Export 389Hintergrundjob 393Import 390initialer Speicherplatz 390Mandantenfähigkeit 305Neuaufbau 392Nummer 303Pflege 309Rolle 308Transport 387Verwaltung 315, 392

Mandantenkopie 36, 384, 387große produktive 393Kopierprofil 388Kopierprotokoll 392lokal 388remote 389Testlauf 392

Massenlöschung 118Master Controller Process 800Match 807Materialized View 804max 84MaxDB 75MCOD → Multiple Components in One

DatabaseMCP 800Mediafehler 75, 145, 147Mehrbenutzerbetrieb 69mehrdimensionales Datenmodell 793Mehrfachspeicherung 71Mengensemantik 34Merge 805, 807Merge Patch 409Merkmal 817Message Server 41, 560, 735, 737Message-Server-Prozess 52Metadata Repository 811Metadaten 800Metrik 137Microsoft Management Console 166min 84Mirroring 105, 802Mirror-Log 119


878

Index

MMAN 98MMON 98Model-Konzept 806Model-View-Controller 282Model-View-Controller-Konzept (MVC)

64, 732Modifikation 302Modifikationsabgleich 433MOLAP 796, 804Monitoring 535, 757

extern 542Hardware 537Kategorie 539Last durch 540Netzwerk 538Performance 577Service 759Software 539Tabellenpufferung 508

MOPatch 415msmon 561msprot 560Multi Table Insert 805MultiCube 829Multidimensional OLAP 796Multidimensionales Entity-Relationship-

Modell 811Multidimensionalität 809Multi-Pass-Operation 461Multiple Components in One Database

(MCOD) 218, 375, 627, 655, 664MVC → Model-View-Controller (MVC)

N

Named Pipes 130Native SQL 46Net 8 129Net Manager 134netca 134netmgr 134NetWeaver

Developer Studio 729, 768Development Infrastructure 729, 733,

768Netzwerk 447Netzwerkperformance 177Next-Extent 112Nicht-Unicode-System 325, 366

NLS-Datei → Oracle-CharactersetNoArchiveLog-Modus 601

Offline-Datensicherung 611Normalisierung 78Note Assistant 406NTBACKUP 672NULL-Wert 82NWDI → NetWeaver Development Infra-

structureNWDS → NetWeaver Developer Studio

O

Object Navigator 63Objektkatalogeintrag 342

Kopie 342Original 342

objektorientiertes Konzept 34, 89Objektparameter (Datenbankobjekt) 225Objektprivileg 153objektrelationale Datenbank 89Objektzuordnung (Datenbankobjekt)

225OCI 130OCSS-Prozess 105ODM-Connector 849ODS-Objekt 818Offline

Backup 150Datensicherung 610Redo-Logs 481

OLAP (Online Analytical Processing) 787Cube 793Engine 799Prozessor 790

OLTP (Online Analytical Processing) 96, 787

OMF → Oracle Managed FilesOnline Analytical Processing → OLAPOnline Transaction Processing 787Online Transaction Processing → OLTPOnline-Backup 150Online-Datensicherung 612, 706OPatch 413open resetlogs 666Open SQL 46, 60, 76Operation 71OPI 130OPS$-Verfahren 209, 210, 212


879

Index

Optimal Execution 461Optimal Work Area Size 461Optimierer 99, 125, 136, 513Optimierung, interne 139Optimierungskreislauf 440OPTIMIZER_MODE 493Optimizer-Hint 143Optimizer-Statistiken 493Oracle

Block 615Business Intelligence Discoverer 807Call Interface (OCI) 130CBO-Statistik 247Characterset 197Client 194Client 9i 195Cluster Synchronization Service (OCSS)

105Control-Datei 275Data Migration Assistant 437Data Miner 807, 849Database Upgrade Assistant 437Datenbankmonitor 454Datenbank-Optimizer 492Datendatei 275Datenpuffer 503E-Business Suite 17Enqueues 488Enterprise Manager 94Installation 594Instant-Client (10g) 198Job 588Latch 479Listener 168, 172, 177, 216, 544, 750Lock Monitor 489Lock-Modus 490Managed Files (OMF) 105Mirror-Log 275Optimierer 529, 804Parameter 173, 254, 451Program Interface (OPI) 130Real Application Cluster (RAC) 38, 135Redo-Log 275Schattenprozess 172Schema-ID 221Server-Prozess 99Session Monitor 174, 468Speicherbereiche 840Statistiken 847

Stream 799System-ID 190Verfügbarkeit 544Versionsnummer 90Verzeichnisstruktur 189Wait Events 463Warehouse Builder 806

Oracle Net 96, 129Architektur 129Configuration Assistant 96, 134Manager 96Services 129, 199

Oracle Recovery Manager 635, 678, 713BR*Tools 684Einsatz 681externe Sicherungsbibliothek 686Features 679Level-0-Sicherung 681Level-1-Sicherung 682SAP-Sicherungsbibliothek 685Sicherungsbibliothek 684

ORACLE_HOME 91ORACLE_SID 91OracleBI

Beans 807Discoverer 807Spreadsheet 807

Oracle-ParameterAdministration 256BITMAP_MERGE_SIZE 844CREATE_BITMAP_AREA_SIZE 844DB_CACHE_ADVICE 458DB_FILE_MULTIBLOCK_READ_COUNT

841dynamischer versus statischer 255FILESYSTEMIO_OPTIONS 841HASH_AREA_SIZE 844PARALLEL_EXECUTION_MESSAGE_

SIZE 841PARALLEL_MAX_SERVER 841PGA_AGGREGATE_TARGET 843PGA_MAX_SIZE 843SORT_AREA_SIZE 844WORKAREA_SIZE_POLICY 843

Oracle-Prozess 97, 163, 170, 595ARC-Prozess 163CKPT 163DB-Workprozess 163DB-Writer 163


880

Index

LGWR 163Listener 163PMON 163RECO 163SMON 163

Oracle-Upgrade 436Pfade 436Werkzeuge 436

ORADEBUG 180order by 85Orig-Log 119OSS-Hinweis 35OTR (Online Text Repository) 503

P

Paging 447, 450Paging Memory 498PAI-Bereich (Process After Input) 45Paket 61, 329

$TMP 333PAM → Product Availability Matrixparallele Prozesse 391parallele Query 471Parameterdatei 103Parameterpflege (Oracle) 253Parametrisierungsdatei 593Partial Restore and Complete Recovery

624partielle Sicherung 715Partitionierung 802Passwort 153Passwortänderung (Oracle) 206Patchset 409, 418

Installation 411Voraussetzung 410

PBO-Bereich (Process Before Output) 45pctfree 113, 477pctincrease 112pctused 113Performance 59, 75, 137, 514Performanceprobleme 441

administrative 441Analyse 443benutzerspezifische 441programmatische 441

Persistent Staging Area (PSA) 822Personalisierung 301PFILE → Parameterpflege (Oracle)

PGA → Program Global AreaPGA_AGGREGATE_TARGET 461Physical Read 452Pivoting 797Planungsphase 263Plattenlayout 276PMON 97, 131Point-in-Time Recovery 626, 663Postinstallation 381Präsentationsschicht 36Prävention 525PREPARE 426, 428, 430

Module 430Protokolldatei 431

Prepare 125Prerequisites Check 374Primärindex 520Primärschlüssel 79, 81Problemlokalität 441Process After Input (PAI) 45Process Before Output (PBO) 45Product Availability Matrix (PAM) 418Produktivschlüssel 814Produktivsystem 308Profildatei 53Program Global Area (PGA) 101, 460,

843Verwaltung 461, 845, 846

Projekt-IMG 335CTS-Funktionalität 336Sicht 336

Projektion 138Projektionsliste 83Protocol Support 130protocol.ora 132Protokoll 178

Listener Log 178, 179Listener Trace 178Oracle Alert Log 178SAP-Workprozess-Trace 178Session Traces 178Start- und Stopp-Logs – Oracle 178Start- und Stopp-Logs – SAP 178

Prozess 97, 162Prozessübersicht 567Prüftabelle 73PSAPTEMP 457, 461, 481, 846PSPO 98


881

Index

Puffer 580Administration 511Qualität 452Synchronisation 507Verwaltung 87

Q

QA-Genehmigungsverfahren 333Qualitätssicherungssystem 308Quellsystem 820Query 831

Definition 829Designer 829Rewrite 804

Quick Sizer 269

R

R/2-System 52R/3-Tabellenpuffer 41R3trans 165, 314, 350, 361RAC 135RAID 88, 104, 119, 145, 147, 274RAM → SpeicherRange-Partitionierung 802Raw Device 105, 223, 484Raw I/O 484rdbms ipc reply 478RDDIMPDP 350read by other session 476Read-Only-Tablespaces 111Real Application Cluster (RAC) 38, 135Rechteart 153Rechtevergabe 145RECO 98Reconnect-Mechanismus 610Recovery 122, 152, 618

Katalog 679Manager (RMAN) 96, 150, 152Training 144Writer 152

Recycling Pool 458redirect-Verfahren 131Redo Buffer 454, 472Redo-Information 124, 152Redo-Log-Datei 100, 119, 122, 128, 145,

146, 394, 474, 597, 613, 643, 709Offline 601

Online 597Redo-Log-Gruppe 123, 599, 700Redo-Log-Puffer 100, 128, 597Redo-Log-Switch 599Sicherung 604, 644Split-Mirror-Datenbank 724Status 599Verlust 698, 704Verlust, Offline 705

Redo-Log-Puffer 124Redundanz 71, 78redundanzfreie Speicherung 37referenzielle Integrität 73regelbasierter Optimierer 138Relation 78Relational OLAP 796relationales Datenbank-Managementsys-

tem 37Release-Upgrade 261RemoteCube 820, 829Remote-Kopie 389Reorganisation 227, 251

Ablauf 231Online versus Offline 229Performance 232Werkzeuge 230

Reparatur 343Reparaturkennzeichen 343Reporting 828Repository-Daten 304Request-ID 818RESOURCE 154Resource-minimized 423Restore 122, 617RFC 66

Schnittstelle 66Servergruppe 391

RKWR 98, 152RMAN (Oracle Recovery Manager) 58,

96, 152, 800ROLAP 796, 804Roll Memory 497Rolle 153Roll-Puffer 42Roll-up 797, 805Rule-Based Optimizer (RBO) 492runInstaller 372


882

Index

S

SAINT → Add-on Installation ToolSAN → Storage Area Network (SAN)SAP

Applikationsserver 71Basis 33Benutzer 49Datenbank-Bibliothek 201, 203Datendateinamen 222GUI-Protokoll 37Hinweis 406LUW (Logical Unit of Work) 49NetWeaver 30NetWeaver Developer Studio 64NetWeaver Portal 283Note 35OS Collector 165, 186, 444Port 297Prozessübersicht 448Puffer 496, 501, 503Referenz-Implementation-Guide (SAP-

Referenz-IMG) 335SAP up 426, 428, 433SCM 30, 833SCM-Namesraum 836Service Marketplace 35, 61Sicherungsbibliothek 680, 685Sicherungsobjekt 593Software Change Registration 340Softwareentwicklung 60Solution Manager 542Solution Manager Key 378Speichermonitor 504, 508Standard 300Start-Service 166System-ID 190Systemlog 572Systemstart 164Tablespace 218, 250Transport-Tool 56Urmandant 306Verzeichnisstruktur 188, 222Workprozess 99Workprozess-Übersicht 181

SAP GUI 36HTML 281Java 280Windows 280

SAP NetWeaver 729SAP NetWeaver Application Server 64SAP NetWeaver BI 30, 52

Namensraum 835Performance 834

SAP NetWeaver Business Intelligence Accelerator 850

SAP NetWeaver Exchange Infrastructure (XI) 729

SAP-Berechtigungsrolle (Oracle) 213SAPCONN 214SAPDBA-Rolle 213

SAPCPE 398SAPDBA 589, 629SAPinst 369

GUI 371Log-Datei 380

SAP-InstanzSpeicherbereiche 497

SAPJup 426, 429SAP-Kernel 33, 200, 203, 397, 418

Aktualisierung 398Double-Stack-System 399Internet Graphics Service 397Parameter 204SAPCPE 398

SAPOS Collector 574SAP-Patch 394

Kernel-Dateien 397SAP-Prozess 162, 166

Gateway-Prozess 162Internet Communication Manager 162Message Server 162Prozess-ID 167Sapstart 162Syslog Collector 162Syslog-Sender 162Workprozess 162

SAProuter 295, 371SAPS 269, 439SAT → Single Activity TraceSchatteninstanz 433Schattenprozess 46, 99Scheduler 824Schlüssel 78Schneeflockenschema 796Schulungssystem 145Screen 43, 503SDM → Software Deployment Manager


883

Index

SDP (Session Description Protocol) 130SDU (Session Data Unit) 133Secure Store 750Segment 111Segment Shrinking 232Sekundärindex 126, 528Sekundärspeicher 145select from 83Selektion 83, 138Selektivität 140Self-Tuning 802Sequenznummer 147Serverprozess 97, 99, 131Serverübersicht 567Service 742Service Level Agreement (SLA) 285Service Manager 740Servicedefinition 133serviceorientierte Architektur 31Session Data Unit → SDU (System Global

Area)SGA → System Global AreaSGA_TARGET 454Shadow-System 423, 424Shape-Datei 832Shared

Cursor Cache 459Lock 491Memory 103Memory-Segment 103Pool 453, 460Server 134Server-Betrieb 98Server-Prozess 99SQL Pool 103

SHARED_POOL_SIZE 453, 460Short NTAB 503Sicherheit 215

Datenbank 293Lücke 416Netzwerk 294technische 292

SicherungBibliothek 680, 684Entwicklungs- und Testsystem 715Gerät 673Geschwindigkeit 712Offline 610Online 612, 706

partieller Tablespace 715Zwei-Phasen 717Zyklus 673, 709

Sicherung, inkrementelle 635, 682, 713Sicherungsbibliothek, externe 686Sicht 72Sichtexpansion 125, 137Sitzungsschicht 133Sizing 265, 269skalierbare Architektur 30Skalierbarkeit 37SLA → Service Level AgreementSlicing 796SMON 97Snapshot 98, 713SNOTE → Note AssistantSNPn 98Socket 132Software

Component Archive 396Deployment Manager 395, 736, 752,

773Fehler 592Management 35Pflege 55

Solaris 417SORT_AREA_SIZE 461Sortierung 85, 126, 527Space Management 106SPAM → Support Package ManagerSpeicher 537

Bereiche 497, 499Konfiguration 496Lücke 86, 101Monitor 499physisch 580Struktur 97Swap 580

Sperrtabelle 51Sperrverwaltung 51, 87SPFile 103, 120Split-Mirror-Datenbank 721Split-Szenario 725SPOF (Single Point of Failure) 560Spool-Prozess 40SPS → Support Package StackSQL

*NetV2 129Anfrage 125


884

Index

area get ratio 518area pin ratio 518Cache 459IDL 82Native 754Open 754Optimierung 513Trace 524Vendor 754

SQLA.Reloads/Pin 518SQLNET.EXPIRE_TIME 492sqlnet.ora 132sqlplus 91, 148SSL 130Stabilität 75Staging 820Staging Area 792Stammdaten 508, 813, 817, 823Standard

Job 49Passwort (Oracle) 206Software 28, 300Transportschicht 329

Standardsoftware, betriebliche 28Standby

Cold 286Datenbank 652, 718Hot 286Load Balancing 288

Stapelverarbeitung 29startdb 165, 167, 178Startproblem 172Startprofil 54, 165startsap 165, 178statistic_level 143Statistik 137, 141Sternschema 796

erweitertes 813klassisches 812

stopdb 178, 185Stoppmarke 354stopsap 178Storage 112, 591

Area Network (SAN) 274Array 273System 104

Streams Pool 454STREAMS_POOL_SIZE 454Striping 105, 802

Stromversorgung 267unterbrechungsfreie 266

Strukturänderung 664Sub-Cube 795sum 84Support Package 29, 56, 394, 418

ABAP 395Component 396Conflict Resolution Transport 396Java 396Maintenance Optimizer 397SAINT 395Software Component Archive 396SPAM 395Speicherbedarf 396Stack 400Systemlandschaft 408Typen 395

Support Package Managerdowntime-minimierter Modus 404Einspielszenario 403Generierung 405konventioneller Modus 404Queue definieren 402Queue einspielen 403Systemlandschaft 408Update 401

Support Package Manager (SPAM) 395, 401

Support Package Stack (SPS) 400, 776Surrogat-ID 814Swap-Speicher 173, 447Sychronisation 74Synchronous I/O 484SYS 154SYSAUX-Tablespace 109SYSDBA 108SYSDBA/SYSOPER – Connect 208SYS-Tablespace 109SYSTEM 154System

Analyse 443Änderbarkeit 315Change Number 598, 615Datei 120Downtime 591Enqueue 489Fehler 75, 144, 146Katalog 72


885

Index

Landschaft 39, 261, 308Monitor 97Privileg 153Prozess 581R 86Statistik 558Stillstand 152Stopp 184Switch Upgrade 433

System Global Area (SGA) 101, 453dynamische 454Puffer 449Speicher 449

System, externes 358Systemlandschaft

Drei-System-Landschaft 308Mehr-System-Landschaft 311Zwei-System-Landschaft 310

T

Tabelle, interne 63Tabellenpufferung

Einzelpufferung 505generische Pufferung 506Monitoring 508

Tabellenstatistiken 492Table Definition (TTAB) 503Table generic 504Table single 504Tablespace 612, 715

Backup-Modus 612, 616, 706Dictionary Managed 549Konzept 106Layout 616Locally Managed 547Point-in-Time Recovery 627Reorganisation 222Rollback 688System 688temporär 668, 696Verlust 623, 688, 694, 696

Tablespace-Layout 218altes Layout 219neues Layout 220, 228

Tablespace-Typ 107, 224Umstellung 225

TAF (Transport Application Failover) 135

Takeover 719Tape

Pool 673virtuelle Librarys 279

Task Handler 46TCP/IP 130Tertiärspeicher 145Testsystem 715Text 813, 817Thin JDBC 129TIMED_STATISTICS 452TNS 130, 131TNS_ADMIN 134tnsnames.ora 120, 132Top-SQL-Statements 519tp 314, 326, 350, 361Trace

Application 760Datei 122, 619Developer 745, 761JCo 767Level 745Performance 760Single Activity 761SQL 762

Transaction-Enqueue (TX) 489Transaktion 33, 73

Fehler 144Konzept 50Log 87, 119, 128Nummer 34Profil 517Verwaltung 99

Transferstruktur 821Transformation 791Transformationsregel 821Transparent Application Failover (TAF)

135Transparent Network Substrate (TNS)

130transparente Tabelle 63Transport

Auftrag 61Datei 348Domain Controller 324Domäne 323, 357Gruppe 323, 355Management System 314, 321Protokoll 364


886

Index

Schicht 328, 341Schritt 364Strategie 345System 145Verzeichnis 321, 373Weg 327Wegeeditor 329

Transport Organizer 312, 344Tools 344

transportabler Tablespace 799Treiberklasse 749TREX 811, 850Trigger 79, 89Two Task Common (TTC) 130

U

Übertragungsregel 821Ultra Large Database 799Umbenennung 83Umgebungsvariable 193

dbs_ora_schema 193DIR_LIBRARY 201ORACLE_BASE 193ORACLE_HOME 193ORACLE_SID 193SAPDATA_HOME 193, 222SAPSYSTEMNAME 193

UML 77Undo-Informationen 152Unicode 32, 325, 366, 375Unique-Index 530UNIX-Gruppe → BetriebssystemgruppeUPD (Verbucher) 49, 51UPD2 51Update 82Upgrade 369, 418, 436

Assistant 427Downtime 434Frontend 435Oracle 436Prepare 430Schatteninstanz 433Strategie 420, 423System Switch 433Werkzeuge 426

URL Prefix Table 765user_ 109user_role_privs 156

user_sys_privs 157user_tab_privs 157user_tablespaces 107User-Enqueue (UL) 489User-Prozess 581USV 267

V

v$controlfile 121V$LOCK 489V$LOCKED_OBJECT 489v$log 124v$log_history 125V$PGASTAT 460, 461V$SESSION_EVENT 463V$SESSION_WAIT 463, 467, 478V$SGASTAT 460V$SQL_WORKAREA_HISTOGRAM 462v$sysaux_occupants 109V$SYSTEM_EVENT 463, 465v$tablespace 116V$-View 454

V$DB_CACHE_ADVICE 458V$PGA_POOL_ADVICE 458V$PGA_TARGET_ADVICE 845V$PGASTAT 845V$SHARED_POOL_ADVICE 460V$SQL_WORKAREA_HISTOGRAM

845Variable 830VB*-Tabellen 50Verbindungsaufbau SAP – Oracle 171Verbucher 40, 49, 570

Fehler 571Typ 1 51Typ 2 51

Verbund 80, 83Verdrängungen 505Verfügbarkeit 38, 285Vergleich, unscharfer 83Verschnitt 106Verteilungsstrategie 42vi 92View 72virtueller Hostname 370virtueller View 109virtuelles System 331Visual Administrator 755


887

Index

vollständige Pufferung 505vollständiger Table Scan 139Volume 640, 652, 673

Initialisierung 674Management 640, 674Prüfung 676

Vorabkorrektur 343

W

Wait-Event 457Analyse 443Aufbau 463Klassen 464

Warenkorbanalyse 806Wartungsfenster 285Web Dynpro 730

ABAP 282Java 282

Web Reporting 829Webservice 31, 64Wertehilfe 34where 83Wiederherstellung 144, 147Wiederherstellungsmethode 617

Offline-Datensicherung 621Online-Datensicherung 622

Wiederherstellungsszenario 620, 660Windows 417Wirkungsprognose 798with admin option 154Workarea 461Workbench-Auftrag 318Workload Repository 98Workload-Analyse 443, 452Workprozess

Komponenten 182Multiplexing 42, 43PRIV-Modus 568

Wrapper 65write complete waits 477Würfel 793, 809

X

XI → SAP NetWeaver Exchange Infra-structure

XML 89, 791

Z

Zeitstempel 147zentrale Instanz 52Zero Administration Memory Manage-

ment 497Zugriff

Algorithmus 139Kontrolle 73Kosten 493Pfad 87

Zwei-Phasen-Datensicherung 717Zwei-Stufen-Anmeldung 211


Oracle-Datenbankadministration für SAP · 2018. 3. 26. · Michael Höding, André Faustmann,...

Documents

Transcript of Oracle-Datenbankadministration für SAP · 2018. 3. 26. · Michael Höding, André Faustmann,...