sap netweaver bw-performanceoptimierung...7 inhalt 1 einleitung 19 a t dagnu r hü f n 2ei warehouse...

Bonn � Boston

Thomas Schröder

SAP® NetWeaver BW-Performance-optimierung

1182.book Seite 3 Mittwoch, 4. März 2009 6:38 18

Auf einen Blick

1 Einleitung ................................................................ 19

2 Einführung Data Warehouse und SAP NetWeaver BW ....................................................... 27

3 Grundlagen der SAP NetWeaver BW-Architektur ...................................................... 47

4 Grundlagen der SAP-Speicherkonfiguration ........... 61

5 SAP NetWeaver BW-Sizing .................................... 81

6 SAP NetWeaver BW-Datenmodell ......................... 109

7 Analyse von Datenbank, Speicher und Hardware ... 181

8 Analyse der Systemlast ........................................... 247

9 Indizes und DB-Statistiken ..................................... 331

10 Information Lifecycle Management und Archivierung ............................................................ 395

11 Reportingperformance ............................................ 427

12 Performanceoptimierung durch Aggregate ............ 501

13 Business Warehouse Accelerator ........................... 559

14 Performanceoptimierung von InfoProvidern .......... 605

15 Performanceoptimierung von Extraktions- undLadeprozessen ........................................................ 647

16 BW-Performance-Review ....................................... 705

A Anhang .................................................................... 745

B Der Autor ................................................................ 805


7

Inhalt

1 Einleitung ................................................................. 19

2 Einführung Data Warehouse und SAP NetWeaver BW ................................................. 27

2.1 Einführung Data Warehouse ....................................... 272.2 Unterschiede zwischen operativen und dispositiven

Systemen .................................................................... 312.3 Aufbau von Data-Warehouse-Systemen ...................... 322.4 Überblick über SAP NetWeaver BW 7.0 ...................... 35

2.4.1 Administration und Customizing .................... 362.4.2 Datenextraktion in SAP NetWeaver BW ......... 382.4.3 Datenablage in SAP NetWeaver BW .............. 392.4.4 Metadatenmanagement ................................. 422.4.5 Analyse und Reporting ................................... 42

3 Grundlagen der SAP NetWeaver BW-Architektur ... 47

3.1 SAP NetWeaver Application Server ............................. 483.2 Softwarekomponenten des SAP NetWeaver

BW-Systems ............................................................... 55

4 Grundlagen der SAP-Speicherkonfiguration ............ 61

4.1 Begriffserklärungen ..................................................... 624.2 Funktionsweise des SAP-Speichermanagements .......... 63

4.2.1 Benutzerkontext und Moduskontext .............. 634.2.2 SAP-Speichertypen ......................................... 644.2.3 Reihenfolge der Speicherbelegung ................. 714.2.4 Zero Administration Memory Management

unter Windows .............................................. 754.2.5 SAP-Profilparameter ....................................... 75

5 SAP NetWeaver BW-Sizing ..................................... 81

5.1 Sizing-Methoden ........................................................ 835.2 Sizing-Berechnungen .................................................. 865.3 Der Sizing-Prozess ...................................................... 865.4 SAP Quick Sizer .......................................................... 88


Inhalt

8

5.5 SAP Application Performance Standard (SAPS) ........... 995.6 Sizing der Festplattenkapazität ................................... 101

5.6.1 Kalkulation von InfoCubes ............................. 1015.6.2 Kalkulation von DataStore-Objekten ............. 1035.6.3 Kalkulation von PSA-Tabellen ........................ 1055.6.4 Gesamtkalkulation Festplattenkapazität ......... 105

5.7 CPU-Sizing ................................................................. 1055.8 Memory-Sizing .......................................................... 1075.9 Zusammenfassung ...................................................... 108

6 SAP NetWeaver BW-Datenmodell .......................... 109

6.1 Das Star-Schema-Datenmodell ................................... 1106.2 Das erweiterte Star-Schema-Datenmodell in

SAP NetWeaver BW ................................................... 1116.2.1 Faktentabellen in BW .................................... 1146.2.2 Dimensionentabellen in BW .......................... 1146.2.3 Zeiten ........................................................... 1156.2.4 Kennzahlen ................................................... 1166.2.5 Einheiten ....................................................... 123

6.3 Modellierung des SAP NetWeaver BW-Datenmodells (InfoCube) ................................................................. 1246.3.1 Stammdatentabellen in SAP NetWeaver BW ... 1296.3.2 SID-Tabellen in SAP NetWeaver BW ............. 1376.3.3 Externe Hierarchien in SAP NetWeaver BW ... 1436.3.4 Zusammenfassung ......................................... 150

6.4 Realtime-InfoCubes ................................................... 1526.5 DataStore-Objekte (DSO) .......................................... 154

6.5.1 Standard-DataStore-Objekte ......................... 1556.5.2 DataStore-Objekte für direktes Schreiben ...... 1576.5.3 Schreiboptimierte DataStore-Objekte ............ 157

6.6 Virtuelle InfoProvider ................................................. 1596.7 InfoSets ..................................................................... 1626.8 MultiProvider ............................................................ 1666.9 Kennzahlenmodell und Kontenmodell ....................... 1716.10 Modellierungsaspekte aus Performancesicht .............. 173

7 Analyse von Datenbank, Speicher und Hardware .... 181

7.1 Allgemeine Datenbankaspekte in SAP NetWeaver BW ................................................... 1827.1.1 BW-Tabellentypen ......................................... 182


Inhalt

9

7.1.2 Indextypen in SAP NetWeaver BW ................. 1847.1.3 Star-Transformation ....................................... 185

7.2 Übersicht SAP-Performanceanalysewerkzeuge ............ 1877.3 Analyse der Datenbank ............................................... 189

7.3.1 Begriffserklärungen ........................................ 1897.3.2 Speicherbereiche der Datenbank .................... 1917.3.3 Analyse der Shared SQL Area ......................... 1987.3.4 Analyse der Table Scans ................................. 2037.3.5 Analyse der Sortiervorgänge ........................... 2047.3.6 Analyse der Datenbankpuffer ......................... 2057.3.7 Analyse von Speicherplatz, Tabellen und

Indizes ........................................................... 2067.3.8 Überprüfung der DB-Parameter ..................... 2117.3.9 DBA-Einplanungskalender .............................. 211

7.4 Analyse der SAP-Speicherbereiche .............................. 2127.4.1 Analyse der SAP-Puffer .................................. 2147.4.2 Analyse des SAP-Speichers ............................. 2177.4.3 Analyse des allokierten Speichers und

des Hauptspeichers ........................................ 2197.4.4 Analyse des Auslagerungsspeichers ................ 2227.4.5 Analyse der Profilparameter des

SAP-Memory-Management-Monitors ............ 2257.5 Analyse der Hardware ................................................. 226

7.5.1 Analyse eines CPU- bzw. Hauptspeicher-Engpasses ............................... 227

7.5.2 Analyse von Schreib-/Lese-Problemen (I/O) ... 2297.6 Analyse der SAP-Workprozesse .................................. 2317.7 Analyse der Benutzermodi .......................................... 2367.8 Speicherverbrauch von Benutzer und

Modi analysieren ........................................................ 2377.9 Kontinuierliche Systemüberwachung (Monitoring) ...... 239

7.9.1 Zentraler Überwachungsmonitor im CCMS ..... 2407.9.2 SAP Solution Manager ................................... 2437.9.3 SAP Solution Manager Diagnostics ................. 244

8 Analyse der Systemlast ............................................ 247

8.1 Grundlagen und Begriffe ............................................. 2488.1.1 Ablauf eines Transaktionsschrittes im

SAP-System ................................................... 2488.1.2 Verteilung der Antwortzeiten ......................... 252


Inhalt

10

8.2 Der Systemlastmonitor ............................................... 2538.3 SAP-Systemlastanalyse ............................................... 2578.4 BW-Systemlastanalyse ................................................ 261

8.4.1 BW-Query-Laufzeit-Statistiken ...................... 2618.4.2 Event-Konzept der BW-Statistikdaten ........... 2658.4.3 Pflege der BW-Statistikeigenschaften ............. 2688.4.4 Analyse der Statistikdaten von MultiProvider-

Queries ......................................................... 2708.4.5 Löschung von BW-Statistikdaten ................... 272

8.5 Werkzeuge für die Analyse der Statistikdaten ............. 2758.5.1 Analyse der Statistikdaten mit der

Transaktion SE16 ........................................... 2768.5.2 Analyse der Statistikdaten mit dem

Systemlastmonitor (Transaktion ST03N) ........ 2818.5.3 Analyse der Statistikdaten mit dem

Query-Monitor (Transaktion RSRT) ................ 2888.5.4 Analyse der Statistikdaten mit Queries

des Technischen Contents ............................. 2908.5.5 Analyse der Statistikdaten mit BEx

Web Analyzer ................................................ 2948.5.6 Analyse der Statistikdaten mit dem Analyse-

und Service-Toolset (Transaktion ST13) ......... 2968.5.7 Anwendungsanalyse (Transaktion ST14) ........ 2988.5.8 Analyse der Statistikdaten mit dem

BW Administration Cockpit ........................... 3018.5.9 Auswertungsstrategien und Tipps .................. 306

8.6 Technischer Content .................................................. 3128.7 Übernahme des Technischen Contents ....................... 322

8.7.1 Übernahme Technischer Content (Gesamt) .... 3238.7.2 Übernahme Technischer Content mit

BW-Content-Sammelanschluss ...................... 3248.7.3 Prozessketten des Technischen Contents ....... 328

9 Indizes und DB-Statistiken ...................................... 331

9.1 Grundlagen der DB-Speicherverwaltung ..................... 3329.2 Grundlagen zu Indizes und Ausführungsplänen .......... 334

9.2.1 Ein Einführungsbeispiel ................................. 3349.2.2 Tabellen-/Indexzugriffsalgorithmen ............... 3379.2.3 Join-Algorithmen ........................................... 339

9.3 Strukturtypen von Indizes .......................................... 341


Inhalt

11

9.4 Indizierungsschema in SAP NetWeaver BW ................ 3479.4.1 Indizierung bei Standard-InfoCubes ............... 3479.4.2 Indizierung bei transaktionalen InfoCubes ...... 3549.4.3 Indizierung partitionierter InfoCubes

(Oracle) .......................................................... 3559.4.4 Indizierung von DataStore-Objekten .............. 3569.4.5 Indizierung der Stammdatentabellen

(X-/Y-Tabellen) .............................................. 3589.5 Star-Join-Ausführungsplan .......................................... 3609.6 Administration der Indizes .......................................... 366

9.6.1 Indizes überprüfen ......................................... 3679.6.2 Indizes aufbauen ............................................ 3719.6.3 Index-Qualität überprüfen ............................. 376

9.7 Datenbankoptimierer ................................................. 3799.8 DB-Statistiken ............................................................ 3829.9 Administration der DB-Statistiken ............................... 384

9.9.1 Administration der DB-Statistiken mit BRCONNECT ................................................. 385

9.9.2 Administration der DB-Statistiken mit DBA-Einplanungskalender .............................. 386

9.9.3 Administration der DB-Statistiken mit Transaktion DB20 .......................................... 391

9.9.4 Administration der DB-Statistiken für InfoCubes ...................................................... 393

10 Information Lifecycle Management und Archivierung ............................................................. 395

10.1 Archivieren und Löschen von Basis-InfoCubes und DataStore-Objekten ................................................... 39910.1.1 Durchführung der Archivierung ...................... 40410.1.2 Durchführung des Löschens ........................... 40510.1.3 Wiederherstellung archivierter Daten ............. 407

10.2 Löschen von Stammdaten ........................................... 40810.3 Löschen von PSA-Daten und Change-Log ................... 41210.4 Archivieren und Löschen von Request-Informationen ... 415

10.4.1 Durchführung der Archivierung ...................... 41810.4.2 Durchführung des Löschens ........................... 42010.4.3 Zurückladen von Request-Verwaltungsdaten ... 421

10.5 Löschen von BW-Statistikdaten .................................. 42310.6 Archivieren und Löschen von Anwendungs-Logs ........ 424


Inhalt

12

11 Reportingperformance ............................................. 427

11.1 OLAP-Prozessor ......................................................... 42711.2 OLAP-Cache .............................................................. 431

11.2.1 Hauptspeicher-Cache .................................... 43211.2.2 Persistenter Cache ......................................... 43411.2.3 Cache-Modus ................................................ 43511.2.4 Cache-Invalidierung und Delta-Caching ......... 44011.2.5 Cache-Partitionierung .................................... 442

11.3 OLAP-Cache-Monitor ................................................ 44411.3.1 Cache-Verdrängung und -Auslagerung .......... 44711.3.2 Cache-Struktur .............................................. 44811.3.3 OLAP-Eigenschaften für InfoCubes ................ 451

11.4 Query-Monitor der Analytical Engine ......................... 45211.4.1 Query-Eigenschaften ..................................... 45311.4.2 Debug-Optionen ........................................... 46211.4.3 Performance Informationen im

Query-Monitor .............................................. 46611.4.4 Technische Informationen im

Query-Monitor .............................................. 46711.5 BW-Trace-Tool .......................................................... 470

11.5.1 Aufzeichnung von Traces ............................... 47011.5.2 Abspielen eines aufgezeichneten Trace .......... 472

11.6 CAT-Tool ................................................................... 47411.7 BEx Information Broadcaster ...................................... 47811.8 MultiProvider-Queries ............................................... 48011.9 Frontend-Performance und Netzwerk ........................ 490

11.9.1 BEx Analyzer ................................................. 49011.9.2 Hinweise zur Performanceoptimierung .......... 49311.9.3 Web-Reporting ............................................. 49811.9.4 Hardware- und Software-Empfehlungen

für das SAP NetWeaver BW-Frontend ........... 498

12 Performanceoptimierung durch Aggregate ............. 501

12.1 Grundlagen ................................................................ 50412.1.1 Aggregate auf Merkmalen ............................. 50412.1.2 Aggregate auf Navigationsattributen ............. 50812.1.3 Aggregate auf Hierarchieknoten .................... 51012.1.4 Aggregate auf Festwerten .............................. 51312.1.5 Ausnahmeaggregationen in InfoCubes ........... 51412.1.6 Line-Item-Aggregate (flache Aggregate) ........ 517


Inhalt

13

12.2 Automatische Erstellung von Aggregaten .................... 51912.2.1 Aggregate vorschlagen aus BW-Statistik ......... 52112.2.2 Aggregat vorschlagen aus Query-Definition .... 522

12.3 Manuelle Erstellung von Aggregaten ........................... 52412.3.1 Analyse der Query mit dem Query-Monitor

(RSRT) ............................................................ 52512.3.2 Anlegen des Aggregats ................................... 52812.3.3 Prüfung und Bewertung von Aggregaten ........ 530

12.4 Pflege von Aggregaten ................................................ 53212.4.1 Roll-up von Aggregaten ................................. 53212.4.2 Prüfung des Aggregatbaums

(Roll-up-Hierarchie) ....................................... 53912.4.3 Zusammenfassung von Aggregaten/

Optimierung .................................................. 54112.4.4 Abschaltung von Aggregaten .......................... 54312.4.5 Datenbeladung und Roll-up von Aggregaten

auswerten/überwachen .................................. 54312.4.6 Hierarchie-/Attributänderungen ..................... 54512.4.7 Parametrisierung des Hierarchie-/

Attributänderungslaufs ................................... 54712.4.8 Hierarchie-/Attributänderungslauf auswerten/

überwachen ................................................... 54912.5 Performanceeinstellungen für die Verwaltung von

Aggregaten ................................................................. 55012.5.1 Delta-Verfahren/Neuaufbau ........................... 55012.5.2 Blockgrößen für den Neuaufbau von

Aggregaten .................................................... 55112.5.3 Prä-Analyse des Aggregate-Füllens ................. 55312.5.4 Parallelisieren von Verwaltungsprozessen

der Aggregate ................................................ 555

13 Business Warehouse Accelerator ............................. 559

13.1 Grundlagen des Business Warehouse Accelerators ...... 56013.2 Architektur des Business Warehouse Accelerators ....... 56413.3 Verbindung von BW Accelerator und

SAP NetWeaver BW ................................................... 56913.4 InfoCube-Architektur im BW Accelerator .................... 571

13.4.1 Faktentabellen im BW Accelerator ................. 57113.4.2 Dimensionentabellen im BW Accelerator ....... 57213.4.3 Stammdatentabellen im BW Accelerator ........ 572


Inhalt

14

13.5 Administration des BW Accelerators .......................... 57413.5.1 Erstellen, Füllen und Löschen von

BWA-Indizes ................................................. 57613.5.2 Hierarchie- und Attributsänderungen

(Change-Run) ................................................ 58113.6 Optimieren von BWA-Indizes .................................... 582

13.6.1 BWA-Delta-Index .......................................... 58213.6.2 Neuaufbau von BWA-Indizes ......................... 58613.6.3 Verteilung von BWA-Indizes .......................... 58713.6.4 Globale Parameter von BWA-Indizes ............. 588

13.7 Analysieren und Testen von BWA-Indizes .................. 59113.7.1 Überwachung des BWA-

Indizierungsprozesses .................................... 59113.7.2 Laufzeitanalyse im Query-Monitor

(Transaktion RSRT) ........................................ 59413.7.3 Test- und Prüfprogramme (RSRV-Checks) ...... 59613.7.4 BWA-Datenkonsistenz-Checkcenter .............. 602

14 Performanceoptimierung von InfoProvidern ........... 605

14.1 Komprimierung von InfoCubes ................................... 60514.2 Partitionierung von InfoCubes .................................... 609

14.2.1 Partitionierung auf Datenbankebene – Range-Partitionierung ................................... 610

14.2.2 Partitionierung auf Datenbankebene – Clustering ...................................................... 618

14.2.3 Repartitionierung der Range-Partitionierung ... 62314.2.4 Monitoring und Fehlerbehandlung der

Repartitionierung .......................................... 62914.2.5 Partitionierung auf Applikationsebene –

Logische Partitionierung ................................ 63114.3 Performanceoptimierung von DataStore-Objekten ..... 636

14.3.1 Vermeidung der SID-Ermittlung .................... 63614.3.2 Clustering auf der Tabelle für die

aktiven Daten (A-Tabelle) .............................. 63714.3.3 Indizierung .................................................... 63814.3.4 Eindeutige Datensätze ................................... 63914.3.5 Unterdrückung der Optimizer-Statistiken ...... 64014.3.6 Einstellungen zu den Laufzeitparametern ....... 641

14.4 Performanceoptimierung von PSA-Tabellen ............... 644


Inhalt

15

15 Performanceoptimierung von Extraktions- und Ladeprozessen .......................................................... 647

15.1 Datenquellen und deren Anbindung ........................... 64815.2 Datenfluss in SAP NetWeaver BW .............................. 65215.3 Techniken zur Kommunikation zwischen SAP ERP

und SAP NetWeaver BW ............................................ 65715.4 Übertragungstechniken ............................................... 659

15.4.1 Application Link Enabling (ALE) ..................... 65915.4.2 Intermediate Document (IDoc) ...................... 66015.4.3 Business Application Programming

Interface (BAPI) ............................................. 66015.5 Persistent Staging Area (PSA) ...................................... 66015.6 Performanceoptimierung für Datenextraktions- und

Staging-Prozesse ......................................................... 66315.6.1 Einstellungen zur Datenpaketgröße ................ 66715.6.2 Performanceoptimierung durch

Parallelisierung in der Datenextraktion ........... 67315.6.3 Performanceoptimierung durch

Parallelisierung in der Datentransformation .... 67615.6.4 Performanceoptimierung bei

3.x-DataSources ............................................. 67815.6.5 Performanceaspekte bei der Fortschreibung

von InfoCubes ................................................ 68215.7 Monitoring von Extraktions- und

Datentransferprozessen .............................................. 68815.7.1 Monitoring der Datenextraktion .................... 68915.7.2 Monitoring der Datentransferprozesse

(DTP) ............................................................. 69815.8 Fehlersuche, Simulation und Debugging von

Datentransferprozessen .............................................. 70015.8.1 Simulation von Datentransferprozessen .......... 70115.8.2 Debugging von Datentransferprozessen ......... 704

16 BW-Performance-Review ......................................... 705

16.1 Untersuchungsbereich Softwareanalyse ....................... 70716.1.1 SAP NetWeaver BW ....................................... 70816.1.2 SAP-Frontend-Analyse ................................... 70816.1.3 Checkliste für den Untersuchungsbereich

Softwareanalyse ............................................. 71016.2 Untersuchungsbereich Performanceüberblick .............. 711


Inhalt

16

16.2.1 Allgemeine Systemlast ................................... 71116.2.2 BW-Systemlast .............................................. 71216.2.3 Analyse ABAP-Laufzeitfehler (Dumps) ........... 71416.2.4 Analyse der Benutzeranzahl ........................... 71516.2.5 Checkliste für den Untersuchungsbereich

Performanceüberblick .................................... 71716.3 Untersuchungsbereich Hardwareanalyse .................... 718

16.3.1 Hardwareprofil .............................................. 71816.3.2 CPU-Auslastung ............................................ 71916.3.3 Speicherauslastung ........................................ 72016.3.4 Datenbankperformance ................................. 72116.3.5 Datenbankwachstum ..................................... 72216.3.6 Checkliste für den Untersuchungsbereich

Hardware ...................................................... 72416.4 Untersuchungsbereich BW-Anwendungsanalyse ........ 726

16.4.1 Analyse Datenverteilung in BW-InfoProvidern und -Stammdaten ......................................... 727

16.4.2 Analyse InfoProvider-Verteilung .................... 72816.4.3 Analyse InfoCube-Design und

Dimensionentabellen .................................... 73316.4.4 Analyse Line-Item-Dimensionen und hohe

Kardinalität ................................................... 73516.4.5 Analyse der Query-Definitionen .................... 73616.4.6 Analyse der Einstellungen zu BW-Statistiken ... 73916.4.7 Analyse der Query-Nutzung .......................... 73916.4.8 Analyse Upload-Prozesse ............................... 74016.4.9 Checkliste für den Untersuchungsbereich

Anwendungsanalyse ...................................... 741

Anhang ........................................................................... 745

A Anhang ................................................................................ 745A.2 Migrationsdetails der Statistikdaten von SAP BW 3.x

nach SAP NetWeaver BW 7.0 – Mapping ................... 746A.3 Mapping-Details der InfoObjects ............................... 751A.4 DB-Views und transparente Tabellen der

BW Runtime Statistics ................................................ 751A.4.1 DB-View RSDDSTAT_OLAP: Statistikdaten

des Frontend- und Calculation-Layers ............ 752A.4.2 DB-View RSDDSTAT_DM: Statistikdaten

des Aggregation-Layers ................................. 753


Inhalt

17

A.4.3 Tabelle RSDDSTATHEADER – Kopftabelle der BW-Statistiktabellen des Frontend-/Calculation-Layers und Aggregation-Layers .... 754

A.4.4 Tabelle RSDDSTATINFO – Statistikdaten der Navigationsschritte ........................................ 755

A.4.5 Tabelle RSDDSTATDM – Statistikdaten des Data-Managers im Aggregation-Layer ............ 755

A.4.6 Tabelle RSDDSTATEVDATA – Statistikdaten zu Zeit und Anzahl aller Events ...................... 756

A.4.7 Tabelle RSDDSTATEVENTS – OLAP-Statistik-Events ............................................................ 757

A.4.8 Tabelle RSDDSTATEVENTS – Übersicht der OLAP-Statistik-Events für BW Suite ................ 757

A.4.9 Tabelle RSDDSTATEVENTS – Übersicht der OLAP-Statistik-Events für Analytical Engine ... 764

A.4.10 Tabelle RSDDSTATEVENTS – Übersicht der OLAP-Statistik-Events für Data Warehousing ... 769

A.4.11 Tabelle RSPCLOGCHAIN: Statistikdaten der Kreuztabelle Protokoll-ID eines Laufs einer Prozesskette zur Prozessketten-ID .................. 773

A.4.12 Tabelle RSPCPROCESSLOG – Statistikprotokolle der Prozesskettenläufe ...... 774

A.4.13 Tabelle RSDDSTATDTP – WHM-Statistiken der DTP-Prozesse ........................................... 775

A.4.14 Tabelle RSBKREQUEST – Statistikdaten der DTP-Requests ................................................ 776

A.4.15 Tabelle RSDDSTATWHM – Statistikdaten des Data-Warehouse-Managements ..................... 778

A.4.16 Tabelle RSMDATASTATE_EXT – Summations-statistiken des Datenstatus in BW .................. 779

A.4.17 Tabelle RSDDSTATTREX – Statistikdaten für Prozesse für TREX-Aggregate ......................... 781

A.4.18 Tabelle RSDDSTATTREXSERV – Detail-Statistik des TREX Servers .................... 781

A.5 ABAP-Programme in SAP NetWeaver BW ................... 782A.6 Job-Präfixe in SAP NetWeaver BW ............................. 785A.7 Transaktionen in SAP NetWeaver BW ......................... 786A.8 BW-relevante Transaktionen im ERP-System ............... 794A.9 SAP ERP- und NetWeaver BW-Systemtabellen ........... 794

A.9.1 Administration ............................................... 794A.9.2 Modellierung ................................................. 798


Inhalt

18

A.10 Temporäre Tabellen in SAP NetWeaver BW ............... 800A.11 SAP-Hinweise ............................................................ 802

A.11.1 Indizes .......................................................... 802A.11.2 DB-Einstellungen für SAP NetWeaver BW ..... 802A.11.3 Systemeinstellungen ...................................... 803A.11.4 Aggregate ...................................................... 803A.11.5 Sammelhinweise und FAQs ........................... 804A.11.6 DB Connect ................................................... 804

B Der Autor ............................................................................. 805

Index .......................................................................................... 807


331

Eine Voraussetzung für performante Lese- und Ladeprozesse sind korrekte Datenbankstatistiken und Indizes. In diesem Kapitel fin-den Sie alle Informationen zu Grundlagen und Administration die-ser Mittel. Es wird zunächst in die Grundlagen der Indizes und die Indizierung von SAP NetWeaver BW-InfoProvidern eingeführt. Zudem werden die Werkzeuge zur Analyse korrekter Indizes und Datenbankstatistiken sowie ihre Administration erklärt.

9 Indizes und DB-Statistiken

Indizes und Datenbankstatistiken sind ein mächtiges Performancemittel,da sie die Suche nach Daten in einer Datenbank unterstützen. Ohne dieseMittel sind performante Lese- und Ladeprozesse bei Zugriff auf großeDatenmengen nahezu unmöglich. Der Analyse und Administration vonIndizes und Datenbankstatistiken kommt deshalb in der Performanceopti-mierung von BW-Anwendungen eine besondere Bedeutung zu.

DB-Statistiken und Indizes einer Datenbank sind vergleichbar mit einemReise-Routenplan. Die Ausgangssituation ist folgende: Der anzufahrendeZielort ist bekannt – um den Zielort zu erreichen, können aber verschie-dene Routen gewählt werden: kürzeste Route, aber eventuell nicht dieschnellste; schnellste Route, aber wahrscheinlich mit einem weiterenWeg. Mit der Abfrage von Daten in einem relationalen Datenbanksystemist es ähnlich.

Die Abfragesprache SQL, auf der alle Queries auf relationalen Datenzielenin SAP NetWeaver BW beruhen, stellt die mittels einer Query angeforder-ten Daten zusammen. Insofern sind für das SQL-Statement die Datenziele(im übertragenen Sinne die Reiseziele zu verschiedenen Datenobjekten)bekannt. Ein SQL-Statement enthält aber keine Informationen darüber,über welche »Route« die Datensuche und -Zusammenstellung am günstigs-ten erfolgt, um die schnellste Antwortzeit (im übertragenen Sinne also diekürzeste Reisedauer) zu erreichen. Ein Großteil der Abfragezeit in einerDatenbank wird nicht für das Lesen der Daten benötigt, sondern für dieSuche. Sind z.B. in einer Datenbanktabelle mit 100.000 Datensätzen nur100 Datensätze (also nur ein Promille) relevant für die vorgegebene Selek-


332

Indizes und DB-Statistiken9

tion, dann dauert die Suche nach den richtigen Datensätzen um ein Viel-faches länger als der eigentliche Lesevorgang. Wenn die Datenbank jedochwüsste, wo die 100 gesuchten Datensätze liegen, würde der Lesevorgangum ein Vielfaches beschleunigt werden. Eine solche Suchhilfe sind Indi-zes. Sie sind ergänzende Datenstrukturen, mit deren Hilfe die Inhalte vonDatenbanktabellen nach Ordnungskriterien katalogisiert werden. DasDatenbanksystem erkennt anhand eines Index, wo die nachgefragtenDatensätze einer Tabelle liegen.

9.1 Grundlagen der DB-Speicherverwaltung

Bei der Erläuterung der Grundlagen zu rationalen Datenbanksystemen,Indizes und Ausführungsplänen sollen zunächst einige Begriffe der Spei-cherverwaltung in Datenbanken erklärt werden, deren Verständnis nichtimmer vorausgesetzt werden kann.

Logische undphysische

Ebene

Bei der relationalen Speicherverwaltung in Datenbanken sind zwei Ebe-nen zu unterscheiden: Die logische und die physische Ebene. Die logischeEbene umfasst Objekte, die üblicherweise mit SQL angesprochen werdenkönnen. Hierzu zählen z.B. Tabellen und Indizes. Diese Objekte werdenin der physischen Ebene in Datenstrukturen abgelegt; hierzu zählen u.a.:

� Tablespaces

� Datendateien (Data Files)

� Segmente

� Extents

� Blöcke

Zudem gibt es weitere physische Objekte wie z.B. Control Files und Redo-Log-Files, die nicht der Ablage von Daten dienen, sondern der Systemver-waltung.

Die physischen Objekte bilden eine hierarchische Ordnung:

Tablespaces Eine Datenbank besteht aus mehreren Tablespaces. Ein Tablespace ist einvordefinierter Speicherort, in den Tabellen, Indizes und andere Datenob-jekte geschrieben werden. Ein Tablespace enthält eine oder mehrereDatendateien. Eine Datendatei ist eine physikalische Struktur, in der Tabel-len und Indizes abgelegt werden. Tabellen und Indizes sind in sogenann-


333

Grundlagen der DB-Speicherverwaltung 9.1

ten Segmenten der Datenbank eingeordnet.1 Dabei kann ein Segment(Objekt) auch in mehreren Datendateien enthalten sein. Segmente sindlogisch einem Tablespace zugeordnet und werden physisch in Dateiengespeichert. Abbildung 9.1 zeigt den hierarchischen Aufbau.

Abbildung 9.1 Hierarchischer Aufbau Datenbankobjekte

ExtentsEine Datendatei ist in mehrere Extents unterteilt. Ein Extent ist Teil einesSegments und besteht aus diskreten Datenbankblöcken fester Größe (z.B.8 KB). Ein oder mehrere Extents bilden ein Segment (siehe Abbildung 9.2).

Abbildung 9.2 Segmente und Extents

1 Das Datenbanksystem Oracle 10g besteht z.B. aus folgenden elf Segmenten: Table,Table Partition, Index, Index Partition, Cluster, Rollback, Deferred Rollback, Tem-porary, Cache, Lobsegment, Lobindex.

Tabelle Tabelle Tabelle Tabelle

Index

Index

Index

Index

Index

Index

Index

Index

Index

Tablespace

Datenbankdatei

Objekte(Segmente)

Segment: 240 KB

Extent: 160 KB Extent: 80 KB

8KB

8KB

8KB

8KB

8KB

8KB

8KB

8KB

8KB

8KB

8KB

8KB

8KB

8KB

8KB

8KB

8KB

8KB

8KB

8KB

8KB

8KB

8KB

8KB

8KB

8KB

8KB

8KB

8KB

8KB


334


9.2 Grundlagen zu Indizes und Ausführungsplänen

Datenbank-optimierer

Um die günstigste Suchstrategie für eine Datenbankabfrage zu finden, ver-fügt das Datenbanksystem über den sogenannten Datenbankoptimierer.Der Datenbankoptimierer ist Bestandteil des Datenbankprogramms undentscheidet, über welche Zugriffsroute die Daten zusammengestellt wer-den. Die Zugriffsroute wird im Datenbanksystem als Ausführungsplanbezeichnet und wird vom Datenbankoptimierer erstellt. Um die Arbeits-weise des Optimierers zu verstehen, werden in den folgenden Ausführun-gen zunächst einige Grundlagen der Datenverwaltung und -organisationin relationalen Datenbanksystemen vermittelt.

9.2.1 Ein Einführungsbeispiel

Ein stark vereinfachtes, aber praxisbezogenes Beispiel soll die Grundlagender Datenorganisation in einem relationalen Datenbanksystem beschrei-ben.

In einer Datenbank sei eine Tabelle mit Mitarbeiterinformationen derangelegt, deren Struktur in Abbildung 9.3 zu sehen ist.

Abbildung 9.3 Beispieltabelle »Mitarbeiter«

Die Einträge der Tabelle sind unsortiert, da relationale Datenbanksystemein der Regel die Daten nicht sortiert abspeichern: Neu hinzukommendeDaten werden an das Ende der Liste oder an Stellen eingefügt, die geradefrei sind. Damit Daten in einer Datenbanktabelle auffindbar sind, werdenalle Zeilen der Tabelle mit einer sogenannten Row-ID gekennzeichnet (inder Beispieltabelle in Abbildung 9.3 nicht dargestellt). Diese Row-ID iden-tifiziert jeden Datensatz in einer Tabelle eindeutig und teilt der Datenbankden genauen Standort der Zeile mit. Wollte man nun in der Tabelle Mitar-beiter in Abbildung 9.3 einen bestimmten Mitarbeiter aus der Datenbankselektieren, müsste die Tabelle bei jeder Abfrage Satz für Satz sequentiell

Name Vorname Abteilung Standort Straße Telefon-Nr. Becker Harald Controlling München Maximilian Str. 089-2476986

...

Schroeder Thomas Beratung Hamburg Lübecker Str. 040-8790657

...

Kessler Anja Controlling Hamburg Lübecker Str. 040-8790637

...

Ansorge Berthold Beratung Münster Hammer Str. 0251-456539

...

Schroeder Elisabeth Facility Mngm. Münster Hammer Str. 0251-456566

...

Name Vorname Abteilung Standort Straße Telefon-Nr. Becker Harald Controlling München Maximilianstr. 089-2476986

...

Schroeder Thomas Beratung Hamburg Lübecker Str. 040-8790657

...

Kessler Anja Controlling Hamburg Lübecker Str. 040-8790637

...

Ansorge Berthold Beratung Münster Hammer Str. 0251-456539

...

Schroeder Elisabeth Facility Mngm. Münster Hammer Str. 0251-456566

...


335

Grundlagen zu Indizes und Ausführungsplänen 9.2

gelesen werden. Dies wäre ein sehr unperformanter Lesezugriff, der jenach Größe der Tabelle zu langen Lesezeiten führen kann, da ein Großteilder erforderlichen Zeit für die Suche des Datensatzes erforderlich wäre.

PrimärindexDamit dies nicht geschieht, existiert zu der unsortierten Tabelle ein Primä-rindex, über den die Suche effizient gestaltet werden kann. Ein Index isteine Datenbankstruktur, die eine sortierte Werteliste mit Zeigern zu denDatensätzen enthält und der Datenbank zum schnellen Auffinden einerZeile in einer Tabelle verhilft. Indizes unterstützen verschiedene Daten-bankoperation. Hierzu zählen z.B. Datenbankabfragen der Form

� SELECT ... WHERE <Tabellenspalte> = <Wert>

� UPDATE ... WHERE <Tabellenspalte> = <Wert>

� DELETE ... WHERE <Tabellenspalte> = <Wert>

� Table Joins (<Tabelle1.Spalte1> = <Tabelle2.Spalte2>)

In der Beispieltabelle Mitarbeiter wäre der Primärindex eine alphabetischnach Namen und Vornamen sortierte Liste, bei der zu jedem Namen undVornamen die genaue Position des Datensatzes in der Tabelle gespeichertist. Damit die Daten in der Tabelle auffindbar sind, sind alle Zeilen miteiner Row-ID eindeutig gekennzeichnet. In diesem Beispiel sind Nameund Vorname die Felder des Index, und die Positionsnummer ist die Row-ID.

Unique-IndexPrimärindizes sind in ERP-Tabellen immer als Unique-Index angelegt. Dasheißt, dass zu jeder Kombination der Indexfelder ein eindeutiger Tabellen-eintrag existiert. Für das Beispiel der Tabelle Mitarbeiter soll diese Anfor-derung vernachlässigt werden, da natürlich in der Mitarbeiter-Tabellemehrere Einträge mit gleichem Namen und Vornamen existieren könn-ten. Die Faktentabelle eines SAP NetWeaver BW-Standard-InfoCube ver-fügt über keinen Unique-Index, da ihre Dimensionenschlüssel-IDs alsFremdschlüssel der Dimensionentabellen über einen sogenannten P-Index indiziert sind, der non-unique ist (siehe auch Abschnitt 9.4).

SekundärindexWollte man in einer nächsten Abfrage alle Mitarbeiter des Standorts Ham-burg selektieren, kann der Primärindex für eine schnelle Suche vomDatenbanksystem nicht verwendet werden, da das Feld Standort nicht imIndex enthalten ist. Um dennoch die Tabelle nicht sequentiell Satz für Satzlesen zu müssen, kann die Suchabfrage durch einen sogenannten Sekun-därindex unterstützt werden. Ein Sekundärindex enthält ein oder mehrereTabellenfelder sowie einen Verweis auf die Row-ID bzw. den Primär-schlüssel der Tabelle. In der Beispieltabelle Mitarbeiter wäre ein Sekun-


336


därindex auf dem Feld »Standort« geeignet, die Suchabfrage nach allenMitarbeitern am Standort Hamburg zu unterstützen. Sekundärindizes sindin der Regel nicht unique, das heißt, zu einem Indexeintrag können meh-rere Tabelleneinträge existieren.

Ausfüh-rungsplan

In dem Beispiel der Tabelle Mitarbeiter sollen in einer nächsten Abfragealle Mitarbeiter mit Namen »Schröder« am Standort »Hamburg« selektiertwerden. Die Datenbank könnte diese Abfragen mit verschiedenenSuchstrategien umsetzen:

1. sequentielles Durchsuchen der gesamten Tabelle

2. Suche über den Primärindex über die Felder Name und Vorname

3. Suche über den Sekundärindex über das Feld Standort

Welche Suchstrategie verwendet wird, entscheidet der Datenbankoptimie-rer. Der gewählte Zugriffspfad wird als Ausführungsplan bezeichnet. DerAusführungsplan (auch Execution Plan genannt) einer Query kann im BW-System im Query-Monitor (Transaktion RSRT) über die Funktion Ausfüh-

ren + Debuggen � Zeige Ausführungsplan eingesehen werden (sieheAbbildung 9.4).

Abbildung 9.4 Aufruf des Ausführungsplans einer Query im Query-Monitor


337


Um einen Ausführungsplan lesen zu können, sollen zunächst verschie-dene Zugriffsoptionen näher erläutert werden, die Sie in einem Ausfüh-rungsplan finden können. Der in Abbildung 9.4 dargestellte Ausführungs-plan beruht auf dem Datenbanksystem Oracle, die hier genannten Begriffeder Datenbankoperationen können in anderen Datenbanksystemen ver-schieden sein.

Bei der Analyse des Ausführungsplans soll unterschieden werden zwi-schen Tabellenzugriffsalgorithmen, also Methoden für den Zugriff aufTabellen und Indizes für das Lesen von Daten, und Join-Algorithmen, alsoMethoden für die Verknüpfung von Daten in Tabellen. Die hier verwen-deten Begriffe sind zum besseren Verständnis allgemein gehalten, inIhrem SAP NetWeaver BW-System können die Begriffe je nach derzugrundeliegenden Datenbank hiervon abweichen.

9.2.2 Tabellen-/Indexzugriffsalgorithmen

Tabellenzugriffsalgorithmen beschreiben Leseprozesse der Datenbankzum Auffinden der gesuchten Daten in den Datenbanktabellen. Die häu-figsten Zugriffsoperationen sind hierbei in der allgemeinen Form derTable Scan und der Index Scan. Wie die Bezeichnungen schon vermutenlassen, unterscheiden sich diese beiden Formen des Datenzugriffs bezüg-lich des Datenobjektes, aus dem zuerst die Daten gelesen werden: einemIndex oder einer Tabelle. Diese beiden Grundformen des Datenzugriffswerden in den folgenden Ausführungen näher spezifiziert.

Full Table ScanEine besondere Form des Table Scans ist der Full Table Scan. Beim FullTable Scan muss die gesamte Datenbanktabelle sequentiell durchsuchtwerden. Der Full Table Scan wird deshalb auch als sequentieller TableScan bezeichnet. Diese Form des Tabellenzugriffs muss vom Datenbank-system immer dann ausgeführt werden, wenn für die Suche kein Indexverwendet werden kann, weil die gewählten Suchfelder nicht in einemIndex enthalten sind. In der Tabelle Mitarbeiter könnte eine SQL-Abfragewie folgt aussehen:

SELECT * FROM TABLE Mitarbeiter WHERE Abteilung = 'Controlling'.

Für das Feld Abteilung existiert in der Tabelle Mitarbeiter kein Index, dieSuche kann also nicht durch einen Index unterstützt werden, und dieTabelle muss Satz für Satz gelesen werden. Ein Full Table Scan ist für großeTabellen aufgrund der langen Suchzeiten sehr ungünstig. Für kleine Tabel-


338


len kann der Full Table Scan aber auch günstiger sein als der Datenzugriffüber einen Index. Die Entscheidung über die beste Suchstrategie fällt derDatenbankoptimierer.

ROW-ID Scan Der ROW-ID Scan liest die Tabellenzeiger einer Tabelle. Die ROW-ID ent-hält die Datendatei, den Block und die Stelle im Block, an der die gesuchteDatenzeile zu finden ist. Die ROWID-Funktion gibt den Zeilenbezeichner ineiner Tabelle zurück, der der angegebenen Datenkorrelation entspricht.Dieser Algorithmus wird benutzt, um Zeilen in einer Tabelle anhand einesVergleichsausdrucks mit Hilfe der Funktion ROWID effizient zu suchen.

Index UniqueScan

Ein Index Scan verwendet einen Index, um die gesuchten Daten zu finden.Der Zugriff erfolgt hierbei also zunächst nicht auf die Datenbanktabelle,sondern auf eine Indextabelle. Indizes bieten ein optimiertes Suchverfah-ren zum Auffinden von wenigen Daten in großen Tabellen. Ein Index Uni-que Scan wird immer dann ausgeführt, wenn alle Felder des Primärindexin der WHERE-Klausel der SQL-Anweisung mit einer Gleichbedingung spe-zifiziert sind. Ein Beispiel für die Tabelle Mitarbeiter könnte wie folgt aus-sehen:

SELECT * FROM TABLE Mitarbeiter WHERE Name = 'Schroeder' AND Vorname = 'Thomas' .

Da der Primärindex immer ein Unique-Index ist, liefert der Index UniqueScan höchstens einen Datensatz zurück.

Index RangeScan

Bei einem Index Range Scan existiert zwar für die Suche ein Index, die Ein-schränkung der Suche in der WHERE-Klausel ist aber nicht eindeutig.

In der SQL-Anweisung

SELECT * FROM Mitarbeiter WHERE Name = 'Schroeder'.

kann zwar der Primärindex zur Suche benutzt werden, doch spezifiziertdie WHERE-Klausel keinen eindeutigen Datensatz im Primärindex, sondernalle Datensätze mit dem Namen »Schroeder« (genauer gesagt, alle Row-IDsder Datensätze mit dem Namen »Schroeder«). Da dieser Indexbereich Satzfür Satz gelesen werden muss, spricht man von einem Index Range Scan.Über einen Sekundärindex wird immer ein Index Range Scan ausgeführt,da er nicht unique ist. Ein Index Range Scan muss immer dann ausgeführtwerden, wenn nicht alle Felder des Index (hier Name und Vorname) in derWHERE-Bedingung mit = spezifiziert sind. Der Datenbankoptimierer muss


339


dann einen Indexbereich durchsuchen, um die Datensätze der Tabelle zuermitteln.

Binäre SucheEin bei der Suche von Daten in Tabellen einer Datenbank benutzter Algo-rithmus ist die binäre Suche (binary search). Die binäre Suche funktioniertähnlich wie das Raten von Zahlen: In einer sortierten Werteliste wird dergesuchte Wert zunächst in der Mitte der Liste gesucht. Stimmt derzunächst gefundene Wert mit dem gesuchten Wert nicht überein, wird jenachdem, ob der gesuchte Wert größer oder kleiner als der gefundeneWert ist, vor oder hinter dem gefundenen Element in der gleichen Weiseweitergesucht. Die Suche wird beendet, wenn das gesuchte Elementgefunden wurde oder wenn es keinen restlichen Bereich mehr gibt, indem gesucht werden könnte.

Abbildung 9.5 Binäre Suche

Der Suchalgorithmus binäre Suche ist in Abbildung 9.5 illustriert. Gesuchtwird die Zahl 96. Der Suchalgorithmus beginnt zunächst in der Mitte derListe mit der Suche und findet den Wert 37 �. Der gesuchte Wert ist grö-ßer als der gefundene, die Suche wird deshalb in der Mitte des rechtenTeils der Liste fortgeführt; es wird der Wert 78 gefunden �. Der gesuchteWert ist größer als der gefundene, die Suche wird deshalb weiter fortge-setzt in der Mitte des verbleibenden rechten Teils der Liste; es wird derWert 105 gefunden �. Der gesuchte Wert ist kleiner als der gefundene,die Suche wird deshalb im linken Bereich fortgesetzt; es wird der Wert 96gefunden �. Der gesuchte Wert ist gefunden, die Suche wird beendet. DasBeispiel in Abbildung 9.5 zeigt, dass die binäre Suche ein sehr effizienterSuchalgorithmus ist, da nur vier Lesezugriffe benötigt werden, um dengesuchten Wert zu finden. Würde die sortierte Liste Element für Elementder Reihe nach durchsucht, wären 13 Lesezugriffe nötig.

9.2.3 Join-Algorithmen

Der Join-Algorithmus verknüpft Datenzeilen von Datenobjekten entspre-chend einem Vergleichsoperator und bildet darüber eine Ergebnismenge.In dem Datenbanksystem, das SAP NetWeaver BW unterliegt, sind ver-

1 2 34

682 3 4 7 12 14 35 37 41 10572 78 96 113


340


schiedene Join-Algorithmen implementiert, die verschiedene Eigenschaf-ten haben und durch den Datenbankoptimierer der jeweiligen Abfrageentsprechend ausgewählt werden. Die drei häufigsten Typen der Join-Operation sind Nested-Loop Join, Merge Join und Hash Join.

Nested-LoopJoin

Der Nested-Loop Join ist der einfachste Join-Algorithmus. Er durchsuchtfür jeden Datensatz der ersten Ergebnismenge die gesamte zweite Ergeb-nismenge nach Übereinstimmungen aufgrund der Join-Bedingung. In derRegel wird über einen Index auf die Datensätze der ersten Ergebnismengezugegriffen, um schnellere Suchzeiten zu bewirken. Für den Nested-LoopJoin existieren weitere Varianten, wie z.B. der Left Outer oder der FullOuter Join. Full Outer Joins sind in der Regel sehr teuer und zeitintensivin der Ausführung, weshalb der Datenbankoptimierer diese Join-Operati-onen nur in wenigen Fällen auswählen wird, wenn keine andere Join-Operation das Ergebnis kostengünstiger bereitstellen kann.

Merge Join Ein Merge Join verknüpft gleich geordnete Ergebnismengen. Die Join-Bedingung muss mindestens ein Gleichheitsprädikat enthalten, sonst kannder Optimierer diese Join-Operation nicht auswählen. Der Merge Join istsehr effizient bei etwa gleich großen, bereits vorsortierten Ergebnismen-gen. Auch für den Merge Join gibt es Varianten, die den Left Outer Joinoder den Full Outer Join unterstützen. Aufgrund der Sortierung derErgebnismengen ist der Merge Join meist erheblich effizienter als der Nes-ted-Loop Join.

Hash Join Der Hash Join ist die vielseitigste Join-Methode. Der Hash-Join-Algorith-mus liest die kleinere Ergebnismenge in den Speicher und berechnet fürdas Join-Kriterium eine Tabelle mit Hash-Schlüsseln, die einen schnellerenZugriff auf die Ergebnismenge ermöglichen als der Indexzugriff. Danndurchsucht der Hash-Algorithmus die größere Ergebnismenge und prüftdie speicherresidente Hash-Tabelle auf Übereinstimmungen. Reicht derSpeicher für die Hash-Tabelle nicht aus, werden die Ergebnismengen inPartitionen aufgeteilt, wobei die Join-Operation für jede Partition einzelnausgeführt wird. Zudem kann der Hash-Join-Algorithmus zu einer index-basierten Join-Strategie wechseln, wenn nicht genügend Cache-Speichervorhanden ist, um alle Zeilen der Ergebnismenge aufzunehmen.

Eine Übersicht mit weiteren Operationstypen finden Sie auch in Tabelle9.3 in Abschnitt 9.5 bei der Erklärung des Star-Join-Ausführungsplans.


341

Strukturtypen von Indizes 9.3

9.3 Strukturtypen von Indizes

Im BW-System werden zwei Typen von Indizes unterschieden: Der Tabel-len-Index und der Bitmap-Index.

Der Tabellen-Index speichert die indizierten Wertefelder einer Tabellen-zeile zusammen mit dem physischen Standort der Zeile (Row-ID). Dabeikann der Index auf eine oder mehrere Spalten angelegt sein. Die Indexein-träge werden in der sogenannten B-Tree-Struktur gespeichert. Der B-Treeist eine Indexstruktur, die sich von binären Bäumen (Binary Tree) ableitenlässt und kurze Zugriffspfade auf die Schlüsselwerte unter minimalen I/O-Operationen sicherstellt.

Binary TreeIm Binary Tree enthält jeder Knoten einen Werteintrag, dem genau zweiKnoten zugeordnet sind (deswegen auch »binär«, »zwei«), wobei der linkeZeiger immer auf einen Knoten mit kleinerem Wert zeigt, der rechte Zei-ger auf einen Knoten mit größerem Wert (siehe Abbildung 9.6).

Abbildung 9.6 Binary Tree

Die Anzahl der Einträge pro Knoten wird als Ordnung bezeichnet. EinBinary Tree hat deshalb immer die Ordnung 2. Die Anzahl der Zugriffs-operationen, die benötigt wird, um den gesuchten Wert zu finden, wirdals Tiefe des Binary Trees bezeichnet.

B-TreeDie B-Tree-Struktur ist eine generalisierte Form des Binary Trees, da siemehr als einen Werteintrag pro Knoten und damit auch mehr als zwei Zei-ger pro Knoten enthalten darf. Ein Knoten in einem B-Tree der Ordnungd kann bis zu 2d Werteinträge und 2d+1 Zeiger enthalten, wobei wenigs-tens d Elemente im Knoten enthalten sein müssen, damit jeder Knoten zu50% belegt ist.

Abbildung 9.7 zeigt einen B-Tree-Index der Ordnung 2 mit vier Wertenpro Knoten und fünf Zeigern.

68

2

3

4

7

12

14

35

37

41

105

72

78

96 113


342


Abbildung 9.7 B-Tree-Index

In einer B-Tree-Struktur haben alle Pfade vom Wurzelknoten bis zu denBlättern die gleiche Länge, was auch als balancierte Struktur bezeichnetwird. Die Werteinträge in den Knoten sind sortiert; jeder Knoten hat zwi-schen n und maximal 2n Einträge, der Wurzelknoten kann zwischen 1 und2n Einträge haben. Die Suche von Werten im B-Tree-Index funktioniertnach dem in Abbildung 9.5 beschriebenen Algorithmus der binärenSuche. Die Suchkosten in einem B-Tree-Index sind günstiger als in einemBinary Tree, da der B-Tree vollständig balanciert ist und mehr als zweiWerteinträge je Knoten aufnehmen kann, so dass weniger Knoten durch-sucht werden müssen.

Einfügenneuer Werte

Das Einfügen bzw. Löschen von Elementen im B-Tree-Index muss wiedereinen balancierten Baum hinterlassen. Wird ein neues Element hinzuge-fügt, wird zunächst geprüft, ob das Element schon im Baum vorhanden ist.Für den einzufügenden Datensatz wird anschließend der richtige Blockgesucht und der Wert in den Block geschrieben. Ist der Block schon voll,wird der Inhalt in zwei neue Blöcke aufgeteilt (gesplittet), wobei die klei-neren Einträge mit dem neuen Wert in den linken Block, der nächsthöhereWert als Knoten in den übergeordneten Block und die restlichen Werte inden rechten Block geschrieben werden. Wenn der übergeordnete Vater-Block auch schon voll ist, muss der Block erneut gesplittet werden. Erstwenn der Splitting-Prozess bis zum Wurzelknoten fortgesetzt werdenmuss, erhöht sich die Tiefe des Baums.

1 2 3 4 Block X

Zeiger zum nächsten Block

Zeiger zum Datensatz

14 35 37 41 Block 2

72 78 96 105 Block 3

12 68 113 Block 4

2 3 4 7 Block 1


343


Die Funktionsweise des Einfügens neuer Werte zeigt Abbildung 9.8. InBlock 2 soll der Wert 15 neu hinzugefügt werden. Da Block 2 zuvor voll-ständig gefüllt war (siehe Abbildung 9.7), muss der Block gesplittet wer-den, wobei die Elemente bis zum neuen Wert in Block 2 verbleiben (Ele-mente 14 und 15), der nächsthöhere Wert 35 in den übergeordnetenBlock-4-Knoten eingefügt wird und die restlichen Elemente 37 und 41 ausBlock 2 dem neuen Block 5 zugeordnet werden.

Abbildung 9.8 B-Tree-Index – Einfügen neuer Werte

B*-Tree-IndexEine spezielle Form des B-Tree-Index ist der B*-Tree-Index, der in denmeisten kommerziellen relationalen Datenbanksystemen verwendet wird.Der B*-Tree-Index hat die Eigenschaft, dass alle Knoten zu zwei Drittelngefüllt sein müssen. Es werden dadurch aufgrund der geringeren Baum-tiefe eine höhere Speicherauslastung und eine schnellere Suche gegenüberdem Standard-B-Tree-Index erreicht. Allerdings sind die Kosten für dieReorganisation der Daten (Löschen und Einfügen) aufgrund des Füllgradesvon 66% teurer als beim Standard-B-Tree-Index.

Split Block 2

Neu eingefügter Wert

Änderung Block 4

1 2 3 4Block X

Zeiger zum nächsten Block

Zeiger zum Datensatz

12Block 4 68 11335

2 3 4 7Block 1

72 78 96 105Block 3

14 15Block 2

37 41Block 2


344


Ein normaler B*-Tree-Index ist ein aus Blöcken aufgebauter Baum mit einbis fünf Ebenen. Die oberste Ebene besteht aus einem einzigen Block, derals Root-Block bezeichnet wird und der Ausgangspunkt für jeden Indexzu-griff ist. Die unterste Ebene besteht aus einer potentiell sehr großenAnzahl von Blöcken, die Leaf-Blöcke genannt werden und von links nachrechts die eigentlichen Daten (Werte der indizierten Spalten und Row-IDfür den Zugriff auf den zugehörigen Tabelleneintrag) in sortierter Reihen-folge enthalten. Diese Einträge werden als Leaf-Rows bezeichnet. Zu denLeaf-Rows werden auch frühere Einträge des Index gezählt, die nicht phy-sikalisch aus dem Index entfernt, sondern nur mit einem Flag als gelöschtmarkiert werden. Diese spezielle Art von Leaf-Rows wird Deleted Leaf-Rows genannt.

Zwischen Root- und Leaf-Blöcken kann es in Abhängigkeit von der Index-größe noch weitere Indexebenen mit sogenannten Branch-Blöcken geben,die Steuerdaten zum schnellen Auffinden der relevanten Daten im Indexenthalten. Besteht ein Index aus nur einer Ebene, ist der Root-Block gleich-zeitig ein Leaf-Block und enthält die eigentlichen Daten. Besteht ein Indexaus mehreren Ebenen, ist der Root-Block vergleichbar mit den Branch-Blö-cken und enthält Informationen zur Navigation im Index.

Bitmap-Index Der Bitmap-Index ist besonders hilfreich für Werte mit geringer Kardinali-tät, also wenigen möglichen Ausprägungen, wie z.B. das MerkmalGeschlecht, das zwei Ausprägungen (m/w) annehmen kann. Solche Wer-teausprägungen sind nicht sehr selektiv; Bitmap-Indizes beschleunigendeshalb Suchvorgänge, bei denen nicht-selektive Spalten zur Reduzierungvon Zeilen aus der Menge der zurückgegebenen Zeilen verwendet wer-den. Für Data-Warehouse-Applikationen wird der Bitmap-Index häufigverwendet, um vor allem komplexe und unselektive Abfragen beschleuni-gen zu können.

In einem Bitmap-Index wird für jede Ausprägung ein Bitmap-Feld erzeugt,das den Wert »1« erhält, wenn das indizierte Merkmal den Wert der Aus-prägung besitzt; sonst erhält das Bitmap-Feld den Wert »0«. Wenn einBitmap-Index viele Einsen enthält, spricht man von einer dichten Bele-gung des Bitmap-Index. Beim Attribut Geschlecht wäre der Belegungsgrad50%.

Das Beispiel einer Tabelle mit Feiertagen – dargestellt in Abbildung 9.9 –enthält zwei Bitmap-Indizes: einen Bitmap-Index über das Attribut Gesetz-licher Feiertag (ja/nein) und einen Bitmap-Index über den Monat (Monat1 bis 12).


345


Abbildung 9.9 Bitmap-Index mit Attributen »Gesetzlicher Feiertag (j/n)?« und »Monat«

Die Abbildung 9.9 zeigt, dass für die folgende Abfrage der Bitmap-Indexauf Feldern mit wenigen Merkmalsausprägungen sehr vorteilhaft ist:

SELECT * FROM TABLEWHERE'Gesetzl. Feiertag' = 'J' AND'Monat' = 'Oktober'

Bitmap-Indizes ermöglichen eine schnelle Leseperformance bei geringemSpeicherbedarf (ca. 5 bis 10% des Speicherbedarfs von normalen Indizes,da die binäre Struktur sehr gut vom Datenbanksystem komprimiert wer-den kann), haben aber hohe Performancekosten bei der Aktualisierung.Bitmap-Indizes sollten nur auf Spalten mit geringer Kardinalität (nicht-selektive Spalten) eingesetzt werden, die in WHERE-Bedingungen verwen-det werden.

Tabelle 9.1 zeigt die Unterschiede zwischen B-Tree-Index und Bitmap-Index im Vergleich:

# Feiertag Gesetzlicher Monat Feiertag (j/n)? j n 1 2 3 4 5 6 7 8 9 10 11 12

1 Neujahr j 1 0 Januar 1 0 0 0 0 0 0 0 0 0 0 0

2 Heilige Drei Könige j 1 0 Januar 1 0 0 0 0 0 0 0 0 0 0 0

3 Valentinstag n 0 1 Februar 0 1 0 0 0 0 0 0 0 0 0 0

4 Rosenmontag n 0 1 Februar 0 1 0 0 0 0 0 0 0 0 0 0

5 Fastnacht n 0 1 Februar 0 1 0 0 0 0 0 0 0 0 0 0

6 Aschermittwoch n 0 1 März 0 0 1 0 0 0 0 0 0 0 0 0

7 Karfreitag j 1 0 April 0 0 0 1 0 0 0 0 0 0 0 0

8 Ostern n 0 1 April 0 0 0 1 0 0 0 0 0 0 0 0

9 Ostermontag j 1 0 April 0 0 0 1 0 0 0 0 0 0 0 0

10 Maifeiertag j 1 0 Mai 0 0 0 0 1 0 0 0 0 0 0 0

11 Muttertag n 0 1 Mai 0 0 0 0 1 0 0 0 0 0 0 0

12 Christi Himmelfahrt j 1 0 Mai 0 0 0 0 1 0 0 0 0 0 0 0

13 Pfingstsonntag j 1 0 Juni 0 0 0 0 0 1 0 0 0 0 0 0

14 Pfingstmontag j 1 0 Juni 0 0 0 0 0 1 0 0 0 0 0 0

15 Fronleichnam j 1 0 Juni 0 0 0 0 0 1 0 0 0 0 0 0

16 Friedensfest j 1 0 August 0 0 0 0 0 0 0 1 0 0 0 0

17 Mariä Himmelfahrt j 1 0 August 0 0 0 0 0 0 0 1 0 0 0 0

18 Erntedankfest n 0 1 Oktober 0 0 0 0 0 0 0 0 0 1 0 0

19 Tag der Deutschen Einheit j 1 0 Oktober 0 0 0 0 0 0 0 0 0 1 0 0

20 Halloween n 0 1 Oktober 0 0 0 0 0 0 0 0 0 1 0 0

21 Reformationstag j 1 0 Oktober 0 0 0 0 0 0 0 0 0 1 0 0

22 Allerheiligen j 1 0 November 0 0 0 0 0 0 0 0 0 0 1 0

23 Volkstrauertag n 0 1 November 0 0 0 0 0 0 0 0 0 0 1 0

24 Buß- und Bettag j 1 0 November 0 0 0 0 0 0 0 0 0 0 1 0

25 Totensonntag n 0 1 November 0 0 0 0 0 0 0 0 0 0 1 0

26 1. Advent n 0 1 Dezember 0 0 0 0 0 0 0 0 0 0 0 1

27 Barbara n 0 1 Dezember 0 0 0 0 0 0 0 0 0 0 0 1

28 Nikolaus n 0 1 Dezember 0 0 0 0 0 0 0 0 0 0 0 1




32 Heiligabend n 0 1 Dezember 0 0 0 0 0 0 0 0 0 0 0 1

33 1. Weihnachtstag j 1 0 Dezember 0 0 0 0 0 0 0 0 0 0 0 1


35 Silvester n 0 1 Dezember 0 0 0 0 0 0 0 0 0 0 0 1

Bitmap-Index Bitmap-Index ### # # FFFFeeiiiieerrttttrrr aag g GGGeesseesss tttzzllliiicchhheerr MMMoonnaatttFeiertrr agg ((jj(((( /n))? j j n 1 2 3 4 5 6 7 8 9 10 11 122

1 Neujahr j 1 0 JJanuar 1 0 0 0 0 0 0 0 0 0 0 00

22 Heilige Drerr i Könige j 1 0 Januar 1 0 0 0 0 0 0 0 0 0 0 00




6 Aschermittwoch n 0 1 Märzrr 0 0 1 0 0 0 0 0 0 0 0 00

7 Karfrr rff err itag j 1 0 April 0 0 0 1 0 0 0 0 0 0 0 00

8 Ostern n 0 1 April 0 0 0 1 0 0 0 0 0 0 0 00


10 Maifeff iertrr ag j 1 0 Mai 0 0 0 0 1 0 0 0 0 0 0 00

11 Muttertrr ag n 0 1 Mai 0 0 0 0 1 0 0 0 0 0 0 00

12 Christi Himmelfaff hrt rr j 1 0 Mai 0 0 0 0 1 0 0 0 0 0 0 00

13 Pfiff ngstsonntag j 1 0 Juni 0 0 0 0 0 1 0 0 0 0 0 00

14 Pfiff ngstmontag j 1 0 Juni 0 0 0 0 0 1 0 0 0 0 0 00

15 Frorr nleichnam j 1 0 Juni 0 0 0 0 0 1 0 0 0 0 0 00

16 Friedensfeff st j 1 0 August 0 0 0 0 0 0 0 1 0 0 0 00

17 Mariä Himmelfaff hrtrr j 1 0 August 0 0 0 0 0 0 0 1 0 0 0 00

18 Erntedankfeff st n 0 1 Oktober 0 0 0 0 0 0 0 0 0 1 0 00

19 TaTT g der Deutschen Einheit j 1 0 Oktober 0 0 0 0 0 0 0 0 0 1 0 00


221 Refoff rmationstag j 1 0 Oktober 0 0 0 0 0 0 0 0 0 1 0 00

222 Allerheiligen j 1 0 Novevv mber 0 0 0 0 0 0 0 0 0 0 1 00

223 Volkstrarr uertrr ag n 0 1 Novevv mber 0 0 0 0 0 0 0 0 0 0 1 00

224 Buß- und Bettag j 1 0 Novevv mber 0 0 0 0 0 0 0 0 0 0 1 00

225 ToTT tensonntag n 0 1 Novevv mber 0 0 0 0 0 0 0 0 0 0 1 00

226 1. Advevv nt n 0 1 Dezember 0 0 0 0 0 0 0 0 0 0 0 11

227 Barbararr n 0 1 Dezember 0 0 0 0 0 0 0 0 0 0 0 11








335 Silvevv ster n 00 11 Dezember 00 00 00 00 00 00 00 00 00 00 00 11

BBBiiitttmmaapp-IIInndddeexx BBBiiitttmmaapp-IIInndddeexx# Feiertag Gesetzlicher Monat Feiertag (j/n)? j n 1 2 3 4 5 6 7 8 9 10 11 12

1 Neujahr j 1 0 Januar 1 0 0 0 0 0 0 0 0 0 0 0

2 Heilige Drei Könige j 1 0 Januar 1 0 0 0 0 0 0 0 0 0 0 0




6 Aschermittwoch n 0 1 März 0 0 1 0 0 0 0 0 0 0 0 0

7 Karfreitag j 1 0 April 0 0 0 1 0 0 0 0 0 0 0 0

8 Ostern n 0 1 April 0 0 0 1 0 0 0 0 0 0 0 0


10 Maifeiertag j 1 0 Mai 0 0 0 0 1 0 0 0 0 0 0 0

11 Muttertag n 0 1 Mai 0 0 0 0 1 0 0 0 0 0 0 0

12 Christi Himmelfahrt j 1 0 Mai 0 0 0 0 1 0 0 0 0 0 0 0

13 Pfingstsonntag j 1 0 Juni 0 0 0 0 0 1 0 0 0 0 0 0

14 Pfingstmontag j 1 0 Juni 0 0 0 0 0 1 0 0 0 0 0 0

15 Fronleichnam j 1 0 Juni 0 0 0 0 0 1 0 0 0 0 0 0

16 Friedensfest j 1 0 August 0 0 0 0 0 0 0 1 0 0 0 0

17 Mariä Himmelfahrt j 1 0 August 0 0 0 0 0 0 0 1 0 0 0 0

18 Erntedankfest n 0 1 Oktober 0 0 0 0 0 0 0 0 0 1 0 0

19 Tag der Deutschen Einheit j 1 0 Oktober 0 0 0 0 0 0 0 0 0 1 0 0


21 Reformationstag j 1 0 Oktober 0 0 0 0 0 0 0 0 0 1 0 0

22 Allerheiligen j 1 0 November 0 0 0 0 0 0 0 0 0 0 1 0

23 Volkstrauertag n 0 1 November 0 0 0 0 0 0 0 0 0 0 1 0

24 Buß- und Bettag j 1 0 November 0 0 0 0 0 0 0 0 0 0 1 0

25 Totensonntag n 0 1 November 0 0 0 0 0 0 0 0 0 0 1 0


27 Barbara n 0 1 Dezember 0 0 0 0 0 0 0 0 0 0 0 1








35 Silvester n 0 1 Dezember 0 0 0 0 0 0 0 0 0 0 0 1

Bitmap-Index Bitmap-Index


346


Cluster-Index Ein weiterer Index in SAP NetWeaver BW ist der Cluster-Index, der abernur für DB2 UDB-Datenbanksysteme (Unix, Windows und Linux) zumEinsatz kommt. Dieses Datenbanksystem kann Zeilen auf physischenDatenseiten in der Reihenfolge eines Index sortieren. Der Cluster-Index istein zusammengesetzter Index auf den Dimensionenschlüsselspalten derFaktentabelle und wird automatisch angelegt. Die Reihenfolge wird dabeibestimmt durch das InfoCube-Design und durch die Reihenfolge der Info-Cube-Dimensionen.

Durch das Clustering können die Datensätze in der Faktentabelle gemäßder Sortierfolge des Index abgelegt werden. Datensätze mit denselbenDimensionenschlüsseln können dadurch in gleichen Extents der Daten-bank abgelegt werden. Die Anzahl der zu lesenden Extents kann dadurchmassiv verringert werden, da die Datensätze nicht über viele Extents ver-teilt sind. Ist ein relevanter Extent bereits voll, wird der Datensatz in einenleeren Extent am Ende am Ende der Tabelle eingefügt. Durch ständige Ein-füge- und Löschvorgänge degeneriert der Cluster-Index zunehmend,wodurch die Sortierreihenfolge nicht immer gewährleistet ist. Der Pfle-geaufwand des Index ist dementsprechend größer als beim B-Tree- oderBitmap-Index, da aber weniger physische Blöcke gelesen werden müssen,ist der Datenbank-I/O meist günstiger.

B-Tree-Index Bitmap-Index

Kardinalität geeignet bei Attributen mit hoher Kardinalität

geeignet bei Attributen mit geringer Kardinalität

Anzahl in Tabellen typischerweise ein Index pro Tabelle

mehrere Indizes pro Tabelle

Platzbedarf Platzbedarf unabhängig von Anzahl unterschiedlicher Werte

Platzbedarf abhängig von Kardinalität des Attributs, gewöhnlich aber geringer als bei B-Tree

Reorganisation durch effiziente Algorithmen geringere Kosten

aufwendig bei INSERT und DELETE

Zugriffsart Single-Record-Zugriffe, Schnittmengenbildung teuer

Multiple-Record-Zugriffe, schnelle AND/OR-Verknüp-fungen

Tabelle 9.1 Vergleich von B-Tree-Index und Bitmap-Index


347

Indizierungsschema in SAP NetWeaver BW 9.4

9.4 Indizierungsschema in SAP NetWeaver BW

In diesem Abschnitt werden das Indizierungsschema in SAP NetWeaverBW und die im System verwendeten Indextypen für folgende Datenprovi-der erläutert:

� Standard-InfoCubes

� Transaktionale InfoCubes

� Partitionierte InfoCubes

� DataStore-Objekte

� InfoObjects

Desweiteren lernen Sie die Analyse- und Optimierungsmöglichkeiten mitIndizes kennen.

9.4.1 Indizierung bei Standard-InfoCubes

In SAP NetWeaver BW werden die Tabellen der Fakten und Dimensioneneines InfoCubes bei der Modellierung automatisch indiziert und brauchengewöhnlich nicht selbst angelegt oder erweitert zu werden. Nur in Aus-nahmefällen, z.B. bei besonders großen Datenvolumina, ist es ratsam,weitere Indizes anzulegen, um die Performance für Ladeprozesse undLesezugriffe zu verbessern.

Das Indizierungsschema der Datenbanktabellen eines InfoCubes soll andem folgenden Beispiel des InfoCubes Materialverbräuche Ist (ZMVIST)erläutert werden.

Star-SchemaInfoCubes in BW sind nach dem sogenannten Star-Schema aufgebaut. DasStar-Schema hat seinen Namen aufgrund der sternförmigen Anordnungder Dimensionentabellen um die Faktentabelle des InfoCubes. Die Dimen-sionentabellen repräsentieren dabei die eigentlichen Auswertungssichtender Merkmale wie z.B. Kunde, Artikel, Tag usw.; die Stammdatentabellenenthalten die Merkmalsausprägungen wie z.B. Preis oder Farbe eines Pro-dukts, während die Faktentabelle die metrischen Kennzahlen wie Umsatz,Absatz, Erlös usw. enthält. Alle Datenbanktabellen eines InfoCubes kön-nen über die Transaktion LISTSCHEMA aufgerufen werden (siehe Abbil-dung 9.10).


348


Abbildung 9.10 Demo-InfoCube ZMVIST (I)

In dem folgenden Beispiel soll die Verknüpfung der Faktentabelle desInfoCubes ZMVIST mit der Dimensionentabelle Material und den Stamm-datentabellen des Merkmals Material näher erläutert werden.

In Abbildung 9.11 sind die Tabellen des InfoCubes ZMVIST dargestellt.Die Faktentabelle /BIC/FZMVIST enthält die Kennzahlen und die Fremd-schlüssel zu den in Abbildung 9.10 aufgelisteten Dimensionentabellen. Indem Beispiel wird die Schlüsselbeziehung der Faktentabelle zur Dimensi-onentabelle Material (/BIC/DZMVIST2) und dem StammdatenmerkmalMaterial (/BI0/XMATERIAL) sowie dem Attribut Materialgruppe(/BI0/SMATL_GROUP) betrachtet.

Die Faktentabelle enthält je InfoCube-Dimension eine Spalte mit Fremd-schlüsseln und eine Spalte je Kennzahl.

DIMID Jede Dimensionentabelle besitzt eine Spalte mit einer Dimensionen-ID(DIMID), die den Primärschlüssel der Tabelle enthält, sowie eine Spalte jeMerkmal in der Dimension. In diese Spalten werden die SID-Schlüssel derkorrespondierenden Merkmale geschrieben. In Abbildung 9.11 enthältdie Dimensionentabelle Material (/BIC/DZMVIST2) den Primärschlüsselder Tabelle (DIMID) sowie einen SID-Schlüssel zu den korrespondieren-den Tabellen des Merkmals Material.


349


Abbildung 9.11 Demo-InfoCube ZMVIST (II)

Die korrespondierenden Tabellen zum SID-Schlüssel können verschie-dene Tabellen sein: Die Standard-S-Tabelle /BI0/SMATERIAL, in der dieBeziehung zwischen SID-Schlüsseln der Dimension und dem Merkmalgespeichert ist, die X-Tabelle /BI0/XMATERIAL, in der die Beziehung zwi-schen SID-Schlüsseln der Dimension und den SID-Schlüsseln der zeitunab-hängigen Navigationsattribute gespeichert ist, oder die Y-Tabelle, in derdie Beziehung zwischen SID-Schlüsseln der Dimension und den SID-Schlüsseln der zeitabhängigen Navigationsattribute gespeichert ist.

Die SID-Schlüssel in den obigen Tabellen verzweigen dann auf die Stan-dard-S-Tabelle der Navigationsattribute, z.B. auf das NavigationsattributMaterialgruppe (/BI0/SMATL_GROUP).

Indizierung der Faktentabelle in Standard-InfoCubes

Seit den BW-Releases BW 2.x und BW 3.x werden zwei Faktentabellen jeInfoCube verwendet. Die F-Faktentabelle enthält die unkomprimiertenDaten-Requests (Request-Package-IDs > 0), die E-Faktentabelle enthält diekomprimierten Daten-Requests (Request-Package-IDs = 0). Wird ein Info-Cube komprimiert, werden die Datensätze über die Request-ID verdichtet,aus der F-Faktentabelle gelöscht und in die E-Faktentabelle kopiert.

Faktentabelle

Dimensionentabelle „Material“

Attribut „Materialgruppe“

SID-Tabelle „Material“ (Nav-Attribute)


350


IndexschemaOracle

Das Indexschema ist für beide Tabellentypen nahezu identisch. In derRegel werden in Oracle-Datenbanken alle Spalten mit einem Fremdschlüs-sel für die Dimensionentabelle (Präfix KEY_) mit einem Bitmap-Index indi-ziert.

Eine Ausnahme bilden hier Dimensionen mit Merkmalen, für die das FlagHohe Kardinalität eingeschaltet ist, also Dimensionentabellen, die übersehr viele Datensätze verfügen. Für solche Merkmale werden in Oracle-Datenbanksystemen die Fremdschlüssel mit B*-Tree-Index indiziert, dader Bitmap-Index für Merkmale mit vielen Ausprägungen schlechtergeeignet ist. Die Auswahl des Indextyps (Bitmap oder B*-Tree) wird beimAnlegen des InfoCubes in der Pflege der Dimensionen bestimmt (sieheAbbildung 9.12).

Abbildung 9.12 Einstellung »Hohe Kardinalität« bei Pflege der Dimensionen

Die so vom BW-System erzeugten Sekundärindizes haben als PräfixNamen der Form /BIC/F<InfoCube>~010, ~020 etc. Die Indizes auf denDimensionenschlüsseln der Faktentabelle unterstützen die Lesezugriffedurch Queries.

Weder die E- noch die F-Faktentabelle verfügt über einen eindeutigenIndex, der über den Primärschlüssel der Tabelle definiert ist. Neben denSekundärindizes existiert ein zusammengesetzter Index über alle Spaltender DIMIDs, der sogenannte P-Index (Präfix /BIC/F<InfoCube>~P). Der

09_12.emf


351


P-Index existiert in Oracle-Datenbanksystemen nur auf der E-Faktentabelleund beschleunigt den Komprimierungsprozess. Dabei wird die E-Faktenta-belle auf vorhandene Kombinationen von Dimensionen-IDs überprüft, umzu bestimmen, ob der aus der F-Faktentabelle zu verarbeitende Datensatzeingefügt (wenn die Kombination der Dimensionen-IDs noch nicht in derE-Faktentabelle vorhanden sind) oder fortgeschrieben werden soll. OhneP-Index ist die Komprimierungsperformance erheblich beeinträchtigt.

Indexschema DB2/400

In DB2/400-basierten SAP NetWeaver BW-Systemen existieren für jedeSpalte des Dimensionen-Fremdschlüssels zwei Sekundärindizes: ein soge-nannter Radix-Index, der einem binären Baum entspricht. Bei Zugriffenauf die Faktentabelle wird hauptsächlich dieser Index benutzt. DieseSekundärindizes haben als Präfix Namen der Form /BIC/F<InfoCube>+10,+20 etc. Zudem gibt es noch den sogenannten Encode-Vector-Index (EVI).Dieser Index ist eine DB2/400-spezifische Weiterentwicklung des Bitmap-Index; er ist durch seine kompakte Größe schnell aufzubauen und effizientin den Lesezugriffen. Er wird benötigt für dynamische Bitmap-Indizie-rung, wie sie z.B. beim Star-Join vorkommt. Damit der Datenbankopti-mierer den EVI nutzen kann, benötigt er zusätzliche Informationen, soge-nannte Optimizer-Hints, um einen besseren Zugriffsplan zu ermitteln. DerDatenbankoptimierer für DB2/400 muss hierfür über die sogenanntenQuery Options Files (QAQQINI) auf den EVI-Index eingerichtet werden,um ein bestimmtes Verhalten des Optimierers zu erzwingen. Nähere Hin-weise für die Vorbereitung der EVI-Unterstützung in DB2/400-Daten-banksystemen finden Sie im SAP-Hinweis 501572.

Abbildung 9.13 Indexschema bei Faktentabellen von Standard-InfoCubes

E-Faktentabelle

F-Faktentabelle non-unique,- ORACLE:

Bitmap-Index(Ausnahme:Dimensionenmit hoherKardinalität odertransaktionaleInfoCubes),

- DB2/400: EVI- Andere Daten-banksysteme:B-Tree-Index

B-Tree-Index(non-unique)

„P-Index“

„P-Index“


352


P-Index Gewöhnlich werden die Dimensionenschlüssel der Faktentabelle miteinem non-unique P-Index (/BIC/F<InfoCube>~P bzw. /BIC/E<Info-Cube>~P) indiziert. In Oracle- und Informix-basierten BW-Systemen wirdnur die E-Faktentabelle mit dem P-Index indiziert. Auf MS SQL Serverwird die E-Faktentabelle mit einem Unique-0-Index indiziert. InDB2/UDB-basierten BW-Systemen wird der P-Index auf der E- und auf derF-Faktentabelle als ein Clustering-Index angelegt. Ein Clustering-Indexsortiert alle Datensätze einer Tabelle physikalisch in der Datenbank. Dabeibeginnt der Cluster-Index mit der Zeitdimension, gefolgt von allen weite-ren Dimensionen. Lese- und Löschzugriffe werden dadurch beschleunigt.

Indizierung der Dimensionentabellen

B-Tree-Index In den Dimensionentabellen wird der Primärschlüssel der DIMIDs im All-gemeinen mittels eines Unique-B-Tree-Index indiziert. Diese Indizeshaben Präfix-Namen der Form /BIC/D<InfoCube><#>~0 (# steht für dieNummer der Dimension des InfoCubes) bzw. die Suffixe P (Paket-Dimen-sion), U (Unit-Dimension) oder T (Zeit-Dimension). Mit Ausnahme vonOracle- und DB2/400-Datenbanksystemen werden alle einzelnen Spaltender SID-Schlüssel zudem über non-unique B-Tree-Sekundärindizes indi-ziert, um die Ladeprozesse zu beschleunigen. Die erste SID-Spalte benötigtdabei gewöhnlich keinen Index, da sie die erste Spalte im Index über alleSID-Spalten ist.

In Oracle- und DB2/400-Datenbanksystemen werden SID-Schlüssel in derDimensionentabelle mittels eines zusammengesetzten non-unique B-Tree-Index indiziert (Präfix-Name /BIC/D<InfoCube><#>~010).

Abbildung 9.14 Indexschema bei Dimensionentabellen

B-Tree (non-unique)

B-Tree-Index (unique)

Dimensionentabelle


353


Indizes für Dimensionentabellen mit hoher Kardinalität

Standardmäßig erzeugt SAP NetWeaver BW auf den Spalten der Dimensi-onenschlüssel in der Faktentabelle eines InfoCubes einen Single-Column-Bitmap-Index (siehe Abbildung 9.14). Bei großen Dimensionen und Attri-buten mit hoher Kardinalität ist der Bitmap-Index nicht gut geeignet, dadie durch Datenänderungen (Inserts, Deletes) bedingte Reorganisation derBitmap-Indizes teurer ist als B-Tree-Indizes und der Platzbedarf desBitmap-Index von der Kardinalität der Attribute abhängt. SAP NetWeaverBW bietet deshalb die Möglichkeit, in der Pflege der Dimensionen denstandardmäßig erzeugten Bitmap-Index in einen B-Tree-Index zu ändern(siehe Abbildung 9.12). Durch Aktivierung des Flags Hohe Kardinalität

wird der Bitmap-Index zum B-Tree-Index geändert. Ab BW 3.0 kann dieseUmschaltung separat gepflegt werden von der Einstellung der Line Item

Dimension.

Hohe Kardinalität

Das Kennzeichen Hohe Kardinalität sollte nur gesetzt werden, wenn dieAnzahl der Datensätze in der Dimensionentabelle mindestens 20% derAnzahl Datensätze in der Faktentabelle entspricht. Bei anderen Daten-banksystemen als Oracle hat diese Einstellung keine Auswirkung auf denIndextyp oder die Query-Performance, da Bitmap-Indizes nur in Oracle-Datenbanken verwendet werden. Sie kann jedoch zu einer verbessertenLadeperformance beitragen, da während des Ladevorgangs einige internePrüfungen durchgeführt werden, die über den Einsatz verschiedenerLadestrategien entscheiden. Es wird deshalb empfohlen, auch bei Nicht-Oracle-Datenbanksystemen bei hoher Kardinalität das Kennzeichen zu set-zen.

Die standardmäßig seitens SAP NetWeaver BW erzeugten Bitmap-Indizesin den Spalten der Dimensionenschlüssel der Faktentabelle sind die fürden Star-Query-Join einzig verwendbaren Indizes. Bis zum Release Oracle8.1 konnte bei Erzeugung von B-Tree-Indizes durch Einschaltung des FlagsHohe Kardinalität der Index in Oracle-basierten BW-Systemen nichtgewählt werden, da der B-Tree-Index im Star-Query-Join auf Oracle-Datenbanken nicht verwendet wurde.

Theoretisch konnte Oracle den B-Tree-Index zwar nutzen, aber der Daten-bankoptimierer musste den Index zur Laufzeit in einen Bitmap-Indexumwandeln. Diese Eigenschaft wurde durch die SAP explizit ausgeschal-tet, da ihr Einsatz zu falschen Daten geführt hatte. Die Option wurdedurch den Datenbankparameter B_TREE_BITMAP_PLANS gepflegt, derseitens der SAP auf »FALSE« eingestellt war.


354


Ab Oracle 8.1 ist dieser Fehler behoben. Der Datenbankparameter B_TREE_BITMAP_PLANS ist somit obsolet und nicht mehr gültig.

Wie groß das Verhältnis der Fakten- und Dimensionentabellen bezüglichder Anzahl Datensätze ist, kann mit der Transaktion RSRV geprüft werden(siehe Abbildung 9.15). In der Rubrik Datenbank muss hierzu der Ele-mentartest Datenbankinformationen über die Tabellen eines InfoPro-

viders über das Kontextmenü ausgewählt � und der zu überprüfendeInfoProvider angegeben werden �. Nach Ausführung des Tests � kön-nen im Testprotokoll die Anzahl der Datensätze sowie das Verhältnis derGröße der Dimensionentabellen anhand der Angabe der Größe der Fak-tentabelle geprüft werden (»Größe entspricht x % des InfoCubes«) �.

Abbildung 9.15 Transaktion RSRV – Prüfung der Fakten- und Dimensionentabellen

9.4.2 Indizierung bei transaktionalen InfoCubes

In transaktionalen InfoCubes, wie sie z.B. im SAP SEM eingesetzt werden,ist das standardmäßige Bitmap-Indexschema für die Dimensionen-IDsnicht geeignet. Realtime-fähige InfoCubes sollen neben Leseprozessenauch gleichzeitige Schreibzugriffe unterstützen. Hierzu ist ein satzweisesSperren des Index erforderlich. Da für Bitmap-Indizes kein »Row-LevelLocking« unterstützt wird, würde es bei Datenänderungen und Aktualisie-rung der Bitmap-Indizes zu Sperrungen kommen, die bei UPDATE-Operati-onen die Performance aufgrund von Deadlocks erheblich beeinträchtigen(ORA-60-Fehler).

Der Unterschied zu Standard-InfoCubes liegt deshalb in der Indizierungder Dimensionen-IDs, der F-Faktentabelle mit dem B-Tree-Index, der satz-


355


weises Sperren unterstützt. Die E-Faktentabelle für komprimierteRequests ist von dem geänderten Indexierungsschema nicht betroffen, daSchreibzugriffe nur auf der F-Faktentabelle stattfinden.

Andere Datenbanksysteme als Oracle oder DB2/400 verwenden für Stan-dard-InfoCubes und transaktionale InfoCubes ein identisches Indexie-rungsschema.

Abbildung 9.16 Indexschema Faktentabelle von Realtime-InfoCubes

9.4.3 Indizierung partitionierter InfoCubes (Oracle)

In partitionierten InfoCubes werden die Daten der Faktentabelle physischauf mehrere Partitionen der Datenbank verteilt. Die Verteilung der Datenerfolgt anhand eines Partitionierungsmerkmals, das im Basis-InfoCube alsZeitmerkmal definiert sein muss. In SAP NetWeaver BW können derzeitnur die Zeitmerkmale 0CALMONTH und 0FISCPER als Partitionierungs-

Hinweis

In dem geänderten Indexierungsschema für transaktionale InfoCubes auf Ora-cle- oder DB2/400-Datenbanksystemen ist deshalb auch der Grund für dieschlechtere Leseperformance von Realtime-InfoCubes zu suchen, da die Ver-wendung des Bitmap-Index bei sehr vielen Datensätzen teurer ist als der B-Tree-Index. Achten Sie deshalb bei der Verwendung von transaktionalen InfoCubesauf die regelmäßige Komprimierung.

E-Faktentabelle

ORACLE : Bitmap-Index

F-Faktentabelle

B-Tree-Index (non-unique)

„P-Index“


356


merkmale eingestellt werden. Die Partitionierung wird nur auf der kom-primierten E-Faktentabelle durchgeführt. In der F-Faktentabelle wirdhierzu ein weiterer Bitmap-Index auf der Spalte des Partitionierungsmerk-mals eingefügt, die mit der entsprechenden Spalte des Partitionierungs-merkmals in der E-Faktentabelle korrespondiert (Präfix-Name/BIC/F<InfoCube>~900). Der Datenbankoptimierer erkennt anhand desIndex auf dem Partitionierungsmerkmal in der F-Faktentabelle die richtigePartition auf der Datenbank in der komprimierten E-Faktentabelle. Beieiner Abfrage auf den partitionierten InfoCube übersetzt der SQL-Genera-tor dazu die Zeitselektionen des Partitionierungsmerkmals in die entspre-chenden Partitionierungsspalten, damit der Abfrageoptimierer die Queryauf die relevanten Partitionen der E-Faktentabelle leiten kann.

Abbildung 9.17 Indexschema Faktentabelle von partitionierten InfoCubes (Oracle)

9.4.4 Indizierung von DataStore-Objekten

DataStore-Objekte sind InfoProvider, die vorwiegend im Staging von BWund gewöhnlich nicht als Analyse-Datenziele im Reporting verwendetwerden. In DataStore-Objekten werden seitens SAP NetWeaver BW des-halb keine Sekundärindizes automatisch erzeugt. Es existiert lediglich einPrimärschlüssel, der über einen zusammengesetzten Primärindex auf dieSchlüsselfelder des DataStore-Objekts verfügt. In schreiboptimierten Data-Store-Objekten wird ergänzend zum Index auf dem technischen Schlüssel

E-Faktentabelle

ORACLE : Bitmap-Index

F-Faktentabelle

B-Tree-Index (non-unique)

„P-Index“

Partitionierungsspalte


357


zusätzlich ein Index auf die Felder des semantischen Schlüssels erzeugt,wenn dieser definiert ist.

Sekundärindi-zes manuell anlegen

Sollen DataStore-Objekte auch in der Query-Analyse verwendet werdenoder wird in Staging-Prozessen auf Feldern eines DataStore-Objekts gele-sen, können Sekundärindizes in der Pflege des DataStore-Objekts auchmanuell angelegt werden (siehe Abbildung 9.18).

Abbildung 9.18 Pflege Indizes bei DataStore-Objekten (I)

Das Merkmalsfeld, auf das ein Index angelegt werden soll, muss hierfüraus den Datenfeldern über das Kontextmenü Kopieren (für Index) kopiertoder durch Ziehen des Merkmalsfelds in den Index eingefügt werden(siehe Abbildung 9.19).

Wenn die Werte in den Indexfeldern jeden Datensatz eindeutig identifi-zieren, sollten Sie einen Unique-Index erstellen, andernfalls kann es zuFehlern in der Aktivierung kommen, wenn die Werte nicht eindeutig sind.Die Bezeichnung des Index wird durch das System ausgewählt. Es könnenmaximal 16 Sekundärindizes erstellt werden, es wird aber empfohlen,nicht mehr als fünf Sekundärindizes anzulegen.

09_18.emf


358


Abbildung 9.19 Pflege Indizes bei DataStore-Objekten (II)

9.4.5 Indizierung der Stammdatentabellen (X-/Y-Tabellen)

Navigations-attribute

Die Stammdatentabellen der Navigationsattribute sind lediglich über denPrimärschlüssel indiziert (Präfix-Name /BIC/X<Navigationsattribut>~0beziehungsweise /BIC/Y<Navigationsattribut>~0), SAP NetWeaver BWlegt auf den Spalten der Merkmalswerte und Navigationsattributegewöhnlich keine Indizes an. Bei Verwendung von Navigationsattributenin Queries ist zu beachten, dass Navigationsattribute im erweiterten Star-Schema einen zusätzlichen Join benötigen im Vergleich zu einer Querymit dem gleichen Objekt als Merkmal. Bei Verwendung von Einschrän-kungen auf Werten des Navigationsattributs in einer Query kann es des-halb sinnvoll sein, zusätzliche Indizes manuell auf den Stammdatentabel-len des Navigationsattributs anzulegen.

Ob zusätzliche Indizes angelegt werden sollen, hängt zuletzt von derQuery-Selektion ab, ob Einschränkungen auf Merkmale oder Navigations-attribute in der Query enthalten sind. Typische Szenarien hierfür sind z.B.Queries mit Navigationsattributen auf großen Stammdatentabellen (>20.000 Datensätze) mit Einschränkungen auf dem Navigationsattributoder bei der (F4)-Wertehilfe auf solchen Navigationsattributen. SAP Net-Weaver BW übersetzt die Datenselektion im Allgemeinen in SID-basierteEinschränkungen.


359


Abbildung 9.20 Indexschema bei Stammdatentabellen

In der Regel ist eine Indizierung der Merkmalsspalten nicht erforderlich,meist ist ein Einspalten-Index über eingeschränkte Navigationsattributesinnvoller. Je nach Kardinalität des Attributs sollten Sie bei wenigenMerkmalsausprägungen einen Bitmap-Index verwenden beziehungsweisebei sehr vielen Merkmalsausprägungen einen B-Tree-Index. Weiterfüh-rende Informationen zum Anlegen von Indizes auf InfoObjects vonStammdaten finden Sie in Abschnitt 9.6.2.

Indizierung der SID-Tabellen

Die SID-Tabellen eines Merkmals haben zwei Unique B-Tree-Indizes,einen Primärindex auf der Wertespalte des Merkmals (Präfix-Name/BIC/S<Merkmal>~0) und einen Sekundärindex auf der SID-Spalte (Präfix-Name /BIC/S<Merkmal>~001).

Abbildung 9.21 Indexschema bei SID-Tabellen

Primärindex /BI0/XCUSTOMER~0

•Sekundärindizes•Werden durch BW nicht automatisch erzeugt•Können zusätzlich auf Stammdatentabellen angelegt werden•Bitmap-Index oder B-Tree-Index

Stammdatentabelle X (Material)

Primärindex /BI0/SCUSTOMER~0

SID-Tabelle (Material)

Sekundärindex/BI0/SCUSTOMER~001

B-Tree-Index (unique)


360


Schutz-mechanismus

Die Bedingung eines Unique-Index auf der SID-Spalte ist ein zusätzlicherSchutzmechanismus, der das Einfügen doppelter SID-Schlüssel verhin-dert. Beide Indizes beschleunigen die häufig benutzte Funktion der Über-setzung eines SID-Schlüssels in die Merkmalsausprägung und umgekehrt.

9.5 Star-Join-Ausführungsplan

Query-Monitor Die Nutzung der Indizes bei der Ausführung einer Query kann über denAusführungsplan (Execution Plan) in SAP NetWeaver BW eingesehen wer-den. Im Query-Monitor (Transaktion RSRT) muss hierzu in der OptionAusführen und Debuggen die Einstellung Zeige Ausführungsplan

gewählt werden (siehe Abbildung 9.22).

Abbildung 9.22 Query-Monitor – Anzeige des Ausführungsplans

In Abbildung 9.23 ist der Ausführungsplan einer Query dargestellt. DerAusführungsplan beschreibt die Schritte, die von der Datenbank bei derAusführung der Query durchlaufen werden.


361

Star-Join-Ausführungsplan 9.5

Abbildung 9.23 Ausführungsplan einer Query

Über den Ausführungsplan kann die Nutzung der Indizes geprüft werden.Zu jeder im Ausführungsplan aufgerufenen Tabelle können die Indizesund weitere Informationen zur Größe der Tabellen und Berechnung derStatistiken abgerufen werden (siehe auch Abschnitt 9.8).

Aufbau des Ausführungs-plans

Dem Ausführungsplan können Sie zum einen die an der Query beteiligtenObjekte wie Tabellen und Indizes entnehmen, die durch die Schlüsselwör-ter TABLE und INDEX eingeleitet werden. Zum anderen lassen sich im Aus-führungsplan die vom Datenbankoptimierer gewählten Zugriffsarten undJoin-Operationen ablesen, die z.B. durch Schlüsselwörter wie TABLEACCESS FULL oder MERGE JOIN bestimmt werden. Grundsätzlich können beieinem Ausführungsplan die folgenden Typen von Operationen unter-schieden werden, die in Tabelle 9.2 dargestellt sind (Auszug am Beispieldes Datenbanksystems Oracle):

Hinweis

Das Lesen und Interpretieren von Ausführungsplänen bedarf grundsätzlich eini-ger Übung und ist zumeist dem erfahrenen Datenbankadministrator vorbehal-ten. Die im Ausführungsplan angezeigten Begriffe werden zudem durch das Da-tenbanksystem bestimmt und unterscheiden sich bei den verschiedenen Daten-banksystemherstellern.


362


Für das strukturierte Lesen des Ausführungsplans ist empfehlenswert, denAusführungsplan zunächst in Blöcke der an der Query beteiligten Tabellenzu zerlegen und den Plan von innen nach außen zu lesen, das heißt in derReihenfolge der Tabellenzugriffe, die der Nummerierung der Operations-schritte entnommen werden können. Das Prinzip ist in Abbildung 9.24dargestellt.

Abbildung 9.24 Aufbau eines Ausführungsplans

Operationstyp Beispiele

Basisoperation (Statement)

SELECT, UPDATE, INSERT, DELETE

Zugriffsarten INDEX UNIQUE SCAN, INDEX RANGE SCAN, INDEX FULL SCAN

TABLE ACCESS FULL, TABLE ACCESS BY INDEX ROWID, TABLE ACCESS CLUSTER

Join-Operationen HASH JOIN, HASH JOIN SEMI, HASH JOIN ANTI, MERGE JOIN

MERGE JOIN OUTER, MERGE JOIN ANTI, MERGE JOIN SEMI, MERGE JOIN CARTESIAN, NESTED LOOPS, NESTED LOOPS OUTER

Sortieroperationen SORT UNIQUE, SORT JOIN, SORT ORDER BY, SORT GROUP BY

SORT AGGREGATE, BUFFER SORT

Filteroperationen FILTER

Mengenoperationen INTERSECTION, MINUS, UNION, CONCATENATION

Tabelle 9.2 Operationstypen in Ausführungsplänen

Dimension „ Kunde “ (/BI0/D0SD_C142)

Dimension „ Paket “ (/BI0/D0SD_C14P)

Faktentabelle /BI0/F0SD_C14

Dimension „ Zeit “ (/BI0/D0SD_C14T)


363


In der Beispiel-Query werden Daten aus der Faktentabelle /BI0/F0SD_C14des InfoCubes 0SD_C14 selektiert. Die Eingrenzung der Daten in der Fak-tentabelle erfolgt über die Dimensionen Zeit (Tabelle /BI0/D0SD_C14T),Kunde (Tabelle /BI0/D0SD_C142) und Paket (Tabelle /BI0/D0SD_C14P).

Index Full ScanBlock 1 im Ausführungsplan:

INDEX FULL SCAN /BI0/D0SD_C14T~010(Estim Costs = 2, Estim #Rows = 1)Search Colums: 1

In Block 1 wird zunächst vom Datenbank-Optimizer die Zugriffsart INDEXFULL SCAN auf den Index ~010 der Zeit-Dimensionentabelle /BI0/D0SD_C14T gewählt. In Oracle-Datenbanksystemen werden die SID-Schlüssel inder Dimensionentabelle mittels eines zusammengesetzten non-unique B-Tree-Index indiziert (zum Indexschema von Dimensionentabellen sieheauch Abschnitt 9.4.1). Immer wenn ein Index Scan ausgeführt wird, wer-den Daten aus einem Index gelesen, um die Schlüssel (Row-IDs) der benö-tigten Datensätze zu finden. Beim INDEX FULL SCAN durchsucht der Oracle-Prozess den Indexbaum anhand seiner logischen Sortierung. Das Ergebnisist eine sortierte Ergebnismenge.

TABLE ACCESS BY INDEX ROWID /BI0/D0SD_C14T(Estim Costs = 2, Estim #Rows = 1)

Bei der Zugriffsart TABLE ACCESS BY INDEX ROWID werden der zu lesendeBlock und die Nummer des Datensatzes über die physikalische Adresse(Row-ID) ermittelt, die zuvor über den Index Scan ausgelesen wurde. DerZugriff über die Row-ID ermöglicht ein schnelles Lesen des Datensatzesaus der Tabelle.

Das Ergebnis der Operation im ersten Block ist die Selektion eines Daten-records in der Dimension Zeit, da die SAP BEx Query als Selektionspara-meter das Zeitmerkmal 0CALMONTH enthält.

Full Table ScanBlock 2 im Ausführungsplan:

TABLE ACCESS FULL /BI0/D0SD_C142(Estim Costs = 2, Estim #Rows = 1)

In Block 2 des Ausführungsplans erfolgt eine vollständige Tabellendurch-suchung (Full Table Scan) der Dimensionentabelle Kunde (/BI0/D0SD_C142). Bei einem Full Table Scan werden alle Blöcke der Tabelle in denBlock-Puffer gelesen und dort die einzelnen Zeilen mit der WHERE-Bedin-


364


gung oder anderen Zugriffen weiterverarbeitet. Mit dem Full Table Scanwird häufig ein langsamer Zugriff assoziiert. Bei kleinen Tabellen ist derFull Table Scan jedoch meist die günstigere Operation als der Zugriff überden Index. Bei der Durchsuchung großer Tabellen mit kleinen Ergebnis-mengen ist der Full Table Scan ein Hinweis auf fehlende Indizes. DasErgebnis des Tabellenzugriffs wird anschließend im Daten-Puffer sortiert(Prozessschritt 4: BUFFER SORT). Die Ergebnismengen aus Block 1 und 2werden dann über einen Cartesian Join miteinander verbunden (Prozess-schritt 5: MERGE JOIN CARTESIAN). Beim Cartesian Join werden alle Daten-sätze der ersten Ergebnismenge (Block 1) mit allen Datensätzen der zwei-ten Ergebnismenge (Block 2) verknüpft, da beide Ergebnismengen ausBlock 1 und Block 2 jeweils nur einen Datensatz enthalten.

Index RangeScan

Block 3 im Ausführungsplan:

INDEX RANGE SCAN /BI0/F0SD_C14~020Search Columns: 1

In Block 3 erfolgt ein Zugriff auf den Index ~020 der Faktentabelle/BI0/F0SD_C14 des InfoCubes 0SD_C14 mittels der Zugriffsart IndexRange Scan. Der Index ~020 ist der durch einen Bitmap-Index indizierteFremdschlüssel der Dimension Zeit in der Faktentabelle (zum Index-schema von Faktentabellen siehe auch Abschnitt 9.4.1). Beim Index RangeScan findet der Optimizer im Index eine Ergebnismenge von mehrerenRow-IDs, der anschließende Datenzugriff in der Tabelle erfolgt wiederüber die physikalische Adresse der Datensätze (Prozessschritt 7: TABLEACCESS BY INDEX ROWID).

Die Ergebnismenge aus Block 3 wird mit dem Join-Ergebnis aus den Blö-cken 1 und 2 über die Join-Operation NESTED LOOPS in Prozessschritt 8miteinander verknüpft. Beim Nested Loop wird für jeden Datensatz derersten Ergebnismenge die zweite Ergebnismenge vollständig durchsucht.Wenn beide Ergebnismengen sehr klein sind oder ein kartesisches Pro-dukt (jeder mit jedem) vorliegt, ist der Nested Loop meist die günstigsteJoin-Variante. Wenn beide Ergebnismengen sehr groß sind, ist der NestedLoop die ungünstigste Join-Variante. Im Beispiel in Abbildung 9.18 sindbeide Ergebnismengen sehr klein, weshalb hier die Join-Variante NestedLoop gewählt wird.

Index UniqueScan

Block 4 im Ausführungsplan:

INDEX UNIQUE SCAN /BI0/D0SD_C14P~0Search Columns : 1


365


In Block 4 erfolgt ein Scan über den Index ~0 des Primärschlüssels derTabelle /BI0/D0SD_C14P (Dimensionentabelle Paket). In Dimensionenta-bellen wird der Primärschlüssel der DIMIDs im Allgemeinen mittels einesUnique B-Tree-Index indiziert (zum Indexschema von Dimensionentabel-len siehe auch Abschnitt 9.4.1). Der Index Unique Scan wird verwendet,wenn in der WHERE-Bedingung eine Spalte verwendet wird, auf der einUnique-Index liegt. Die Indexblöcke werden dabei vom Root-Block biszum Leaf-Block gelesen. Der eigentliche Datenzugriff erfolgt wieder überdie physische Adresse des Datensatzes (TABLE ACCESS BY INDEX ROWID) inder Tabelle /BI0/D0SD_C14P der Dimension Paket.

Die Ergebnismenge aus Block 4 wird mit der Ergebnismenge aus Block 1+ 2 und 3 erneut über einen Nested Loop verknüpft.

Die hier vorgestellte Methodik zum Lesen von Ausführungsplänen hilft,die meisten Ausführungspläne in BW zu verstehen und zu interpretieren.Die in dem Beispiel in Abbildung 9.24 vorgestellten Join-Operationen undZugriffsarten des Datenbanksystems Oracle stellen nur einen kleinen Aus-schnitt der verfügbaren Prozessschritte dar. Die wichtigsten Join-Operati-onen und Zugriffsarten sind deshalb bezüglich ihrer inhaltlichen Bedeu-tung in Tabelle 9.3 zusammengestellt:

Typ Operation Beschreibung

Join-Operationen

NESTED LOOP Durchsucht für jeden Datensatz der ersten Ergebnismenge die gesamte zweite Ergebnis-menge.

SORT MERGE JOIN Verknüpft zwei gleich geordnete Ergebnis-mengen. Sehr effizient bei etwa gleich gro-ßen, bereits vorsortierten Ergebnismengen.

HASH JOIN Liest die kleinere Ergebnismenge in den Spei-cher und berechnet für das Join-Kriterium eine Tabelle mit Hash-Schlüsseln, die einen schnelleren Zugriff auf die Ergebnismenge ermöglichen als der Indexzugriff.

ANTI JOIN Liest die Datensätze, zu denen keine korres-pondierenden Datensätze existieren (z.B. bei NOT IN-Klauseln).

OUTER JOIN Erzeugt eine Vereinigungsmenge zweier Datenmengen, auch wenn keine korrespon-dierenden Sätze enthalten sind.

Tabelle 9.3 Zusammenstellung von Oracle-Join-Operationen und Zugriffsarten


366


9.6 Administration der Indizes

Mit den BW-seitigen Administrationswerkzeugen können Indizes ange-legt, überprüft und gelöscht werden. Die Administration von Indizes mitDatenbank-Tools ist hierfür nicht erforderlich. Die Erstellung der Indizeserfolgt mit der Anlage von Tabellen in SAP NetWeaver BW weitestgehendautomatisch (z.B. Indizes auf Fremdschlüsseln der Faktentabelle einesInfoCubes). In einigen Fällen kann es nützlich sein, zu den bereits vorhan-denen Indizes weitere Sekundärindizes anzulegen. Die Erstellung zusätz-licher Indizes oder die Löschung von Indizes sollte grundsätzlich mit denim BW-System vorhandenen Administrationswerkzeugen erfolgen, da aufdiese Weise die Indextabellen automatisch im Data Dictionary bekanntge-macht werden.

Join-Operationen

CARTESIAN JOIN Verknüpft alle Sätze der ersten Ergebnis-menge mit allen Sätzen der zweiten Ergebnis-menge (Kreuzprodukt).

Zugriffsarten FULL TABLE SCAN Durchsucht vollständig eine Tabelle. Sehr effizient bei kleinen Tabellen. Ineffektiv bei großen Tabellen mit kleinen Ergebnismengen (möglicher Hinweis auf fehlenden Index).

TABLE ACCESS BY INDEX ROWID

Ermittelt über die physikalische Adresse (Row-ID) des Datenblocks die Nummer des Datensatzes, wobei die Row-ID in der Regel über einen Index Scan ermittelt wird.

INDEX UNIQUE SCAN

Index Scan auf Spalten mit Unique-Index, z.B. bei Primärschlüsseln. Es wird jeweils eine Zeile zurückgegeben.

INDEX RANGE SCAN

Index Scan auf einen Wertebereich im Index-baum, es wird ein Zeilenbereich zurückgege-ben (LIKE, BETWEEN, ORDER BY).

INDEX FULL SCAN Durchsucht den Indexbaum, bis alle passen-den Werte gefunden sind. Das Ergebnis liegt als sortierte Ergebnismenge vor.

FAST FULL INDEX SCAN

Liest alle Blöcke eines Index, ohne die Daten-blöcke der Tabelle selbst zu lesen. Sehr effizi-ent, wenn alle in der WHERE-Bedingung benö-tigten Daten im Index vorhanden sind.

Typ Operation Beschreibung

Tabelle 9.3 Zusammenstellung von Oracle-Join-Operationen und Zugriffsarten (Forts.)


367

Administration der Indizes 9.6

9.6.1 Indizes überprüfen

Für einen InfoCube kann der Status der Sekundärindizes der E- und F-Fak-tentabelle geprüft werden. Ausgenommen von dieser Prüfung sind derPrimärindex der Faktentabelle sowie benutzerdefinierte Indizes (z.B. Indi-zes mit Präfix-Namen der Form /BIC/F<InfoCube>~A10).

Abbildung 9.25 Überprüfung der Indizes von InfoCube und Aggregaten

Über das Kontextmenü Administrieren in der InfoCube-Pflege � stehenunter der Registerkarte Performance verschiedene Administrationsfunk-tionen für Indizes zur Verfügung. Hierzu zählen die Überprüfung des Sta-tus der Indizes, das Löschen von Indizes und das Reparieren von Indizes�. Für die mit dem InfoCube korrespondierenden Aggregate stehen diegleichen Funktionen für die Indizes aller Aggregate-Faktentabellen zurVerfügung �.

Indizes prüfenÜber die Schaltfläche Indizes prüfen wird geprüft, ob bereits Indizes vor-liegen und der Indextyp korrekt ist (Bitmap- oder B-Tree-Index): Ist derStatus Grün, liegen Indizes im korrekten Indextyp vor. Bei Status Gelb lie-gen Indizes mit einem falschen Indextyp vor, bei Status Rot existierenkeine Indizes oder Indizes sind defekt.

Transaktion RSRV

Der Status der Indizes kann auch mit der Transaktion RSRV überprüft wer-den (siehe Abbildung 9.26). In der Rubrik Datenbank muss hierzu derElementartest Datenbank-Indizes eines InfoCubes und seiner Aggre-


368


gate über das Kontextmenü ausgewählt � und der zu überprüfende Info-

Cube angegeben werden �. Nach Ausführung des Tests � kann im Test-protokoll der Status der Datenbankindizes der Faktentabellen desInfoCubes und aller zugehörigen Aggregate geprüft werden �.

Abbildung 9.26 Transaktion RSRV – Prüfung Datenbank-Indizes InfoCube und Aggre-gate

TransaktionDB02

Fehlende Indizes können auch mit der Transaktion DB02 unter dem MenüDiagnose � Fehlende Tabellen und Indizes überprüft werden (sieheAbbildung 9.27).

Abbildung 9.27 Transaktion DB02 – Überprüfung fehlender Indizes


369


Konsistenz-prüfung für Primär- und Sekundär-indizes

Über die Funktion Fehlende Tabellen und Indizes erfolgt die Konsistenz-prüfung für Primärindizes und Sekundärindizes auf der Datenbank. Feh-lende Primärindizes sind als hoch kritisch einzustufen, da in einem sol-chen Fall die Konsistenz der Daten nicht mehr gewährleistet ist und dieGefahr doppelter Schlüsseleinträge besteht. Durch den fehlenden Primär-index sind zudem die Datenbankzugriffe sehr inperformant.

Im Ergebnisprotokoll der Konsistenzprüfung wird zwischen drei Indexka-tegorien unterschieden:

1. Indizes, die im ABAP Dictionary definiert sind, aber auf der Datenbankfehlen

2. Indizes, die auf der Datenbank gefunden wurden, aber nicht im ABAPDictionary bekannt sind

3. Indizes, die im ABAP Dictionary als optionale Indizes definiert sind

Indizes im ABAP Dictionary

Fehlende Datenbankindizes, die im ABAP Dictionary definiert sind, kön-nen z.B. dadurch entstehen, dass der Index mit einem datenbankeigenenTool gelöscht wurde. Die dauerhafte Löschung von Indizes sollte zur Ver-meidung von Inkonsistenzen immer über das ABAP Dictionary erfolgen.

Indizes auf der Datenbank

Bei Indizes, die auf der Datenbank gefunden wurden, aber nicht im ABAPDictionary bekannt sind, kann es sich ebenfalls um Indizes handeln, diemit einem Datenbank-Tool erzeugt wurden. Sofern die SAP-Namenskon-vention für Indizes eingehalten wurde und der Index im Kundennamens-raum liegt, können solche Indizes nachträglich im ABAP Dictionary ange-legt werden. Andernfalls sollte der Index auf der Datenbank gelöschtwerden und mit der Transaktion SE11 erneut angelegt werden.

Optionale Indizes

Optionale Indizes sind solche Indizes, für die in Abhängigkeit vom Daten-banksystem festgelegt wird, ob ein im ABAP Dictionary definierter Indexauf der Datenbank angelegt werden soll. Es kann dabei ausgewählt wer-den zwischen dem permanenten Anlegen von im ABAP Dictionary defi-nierten Indizes auf der Datenbank, dem Anlegen der Indizes nur auf aus-gewählten Datenbanksystemen oder keiner Anlage des Index auf derDatenbank. In dieser Rubrik der Konsistenzprüfung werden solche Indizes

Hinweis

Beachten Sie, dass beim Laden von InfoCubes Indizes automatisch gelöscht undneu aufgebaut werden, um den Ladeprozess zu beschleunigen. Stellen Sie feh-lende Indizes auf InfoCube-Faktentabellen fest, sollten Sie zunächst prüfen, obder InfoCube zum Zeitpunkt der Indexprüfung beladen wird.


370


angezeigt, die auf der Datenbank angelegt sind, obwohl sie laut Definitionim ABAP Dictionary nicht auf der vorliegenden Datenbank angelegt wer-den sollten, und Indizes, die auf der Datenbank fehlen, obwohl sie lautABAP Dictionary für das vorliegende Datenbanksystem angelegt werdensollten.

In SAP NetWeaver BW 7.0 ist auch weiterhin das bis BW 3.50 gültigeDBA-Cockpit verfügbar, das mit der Transaktion DB02OLD aufgerufenwerden kann. Die oben beschriebenen Funktionen haben auch hier wei-terhin ihre Gültigkeit (siehe Abbildung 9.28).

Abbildung 9.28 DBA-Cockpit DB02OLD

Prüfung vonInkonsistenzen

Bei den Prüfungen auf Inkonsistenzen zwischen dem ABAP Dictionaryund dem Datenbankkatalog greift die Transaktion DB02 auf die interneTabelle DBDIFF zurück. In der Tabelle DBDIFF werden Ausnahmefälleunter anderem für Tabellen und Indizes gespeichert, für die eine akzep-tierte Inkonsistenz zwischen dem ABAP Dictionary und dem Datenbankka-talog besteht. Bei den in der Tabelle DBDIFF gespeicherten Objekten han-delt es sich z.B. um Faktentabellen ohne Primärindex oder temporäreObjekte wie temporäre Tabellen, Views oder Trigger. Die Objekte derTabelle DBDIFF werden bei der Transaktion DB02 berücksichtigt, indemfür diese Objekte keine Konsistenzfehler gemeldet werden.


371


Inkonsistenz-warnungen unterdrücken

Um Warnungen zur Inkonsistenz für ein Objekt zu unterdrücken, könnenEinträge in die Tabelle DBDIFF für Ausnahmeregeln auch manuell erzeugtwerden. Hierzu existiert in der Transaktion SM30 die Pflegesicht DBDIFF-VIEW. Benutzerdefinierte Einträge in die Tabelle DBDIFF sollten nur fürObjekte wie z.B. temporäre Tabellen erfolgen, die auf der Datenbank exis-tieren, nicht aber im ABAP Dictionary.

9.6.2 Indizes aufbauen

Meldet die Transaktion DB02 im Ergebnisprotokoll fehlende Indizes, kön-nen diese direkt aus der Transaktion angelegt werden (siehe Abbildung9.29).

Abbildung 9.29 Anlegen von Indizes aus Transaktion DB02

Hierzu muss der fehlende Index mit der Schaltfläche Auf Datenbank

anlegen � auf der Datenbank erstellt werden �.

Hinweis

Wenn temporäre Objekte in der Transaktion DB02 als inkonsistente Objekte ge-meldet werden, sollten Sie den ABAP-Report SAP_UPDATE_DBDIFF ausführen,der die Tabelle DBDIFF aktualisiert und die temporären Objekte in die Tabelleeinträgt. Nach Auffrischen der Ergebnisse in der Transaktion DB02 wird für dieseObjekte kein Konsistenzfehler mehr gemeldet.

09_29.emf


372


Löschen vonIndizes

Über die Schaltfläche Indizes löschen können in der InfoCube-Administ-ration unter der Registerkarte Performance die Indizes des InfoCubesgelöscht werden. Die InfoCube-Indizes sollten insbesondere danngelöscht werden, wenn durch Delta-Uploads von großen Datenmengen(mehr als eine Million Sätze) aus Performancegründen die Indizes nichtbeim Hochrollen angepasst, sondern zunächst gelöscht und nach demHochrollen vollständig neu aufgebaut werden sollen.

Neuaufbau vonIndizes

Der Neuaufbau der Indizes erfolgt über die Schaltfläche Indexaufbau

(batch). Diese Funktion stellt gelöschte Indizes wieder her und korrigiertdefekte Indizes. Löschung und Neuaufbau von Indizes eines InfoCubeskönnen durch die Einstellungen am InfoCube automatisiert werden (sieheAbbildung 9.30).

Abbildung 9.30 Einstellungen für Löschung/Neuaufbau von InfoCube-Datenbank-indizes

Das Verfahren der automatischen Löschung von Indizes vor jedem Lade-vorgang und des Neuaufbaus nach Abschluss des Ladens beschleunigtzwar den Ladeprozess, kann aber gleichzeitige Lesevorgänge auf einemInfoCube stark verlangsamen. Achten Sie deshalb bei Anwendung diesesVerfahrens darauf, dass während des Ladens von Daten keine Queries aufdem InfoCube ausgeführt werden.

Der Neuaufbau von Indizes kann zu Sperrkonflikten mit dem automati-schen Komprimieren und Hochrollen des InfoCubes führen, da währenddes Indexaufbaus keine Requests in Aggregate hochgerollt oder kompri-miert werden können. Es empfiehlt sich in diesem Fall die Einplanung derIndex-Jobs über Prozessketten. Ist für den InfoCube eine automatischeRequest-Verarbeitung eingestellt, werden allerdings bei der Verwendungvon Prozessketten die Einstellungen der automatischen Request-Verarbei-tung am InfoCube nicht berücksichtigt. Die automatischen Prozesse müs-sen dann als Prozesstypen in die Prozesskette zusätzlich eingebunden wer-den.


373


JobeinplanungDie Einplanung und Ausführung der Indexing-Jobs der InfoCube-Admi-nistration kann in der Jobübersicht mit der Transaktion SM37 geprüftwerden. Die Namen aller Indexing-Jobs beginnen mit »BI_INDX«.

Die Reparatur der InfoCube-Indizes ist auch mit dem ABAP-Report SAP_INFOCUBE_INDEXES_REPAIR möglich. Dieser Report gilt für alle aktivenInfoCubes und Aggregate. Der Bericht entfernt vorhandene Primärindizesund legt fehlende P-Indizes der F- und fehlende Sekundärindizes allerInfoCubes des BW-Systems neu an. Da eine selektive Auswahl eines Info-Cubes nicht möglich ist und der Report zum systemweiten Reparieren vonInfoCube-Indizes verwendet wird, sollte dieser Job als Hintergrundpro-zess eingeplant werden.

Indizes auf Stammdaten-tabellen

Indizes auf Stammdatentabellen können mit Hilfe der Transaktion SE11angelegt werden. Im Beispiel in Abbildung 9.31 kann ein zusätzlicherIndex auf dem Navigationsattribut Warengruppe (S__0MATL_GROUP) beisehr vielen Einträgen in der Stammdatentabelle des Objekts 0MATL_GROUP die Query-Antwortzeit bei Verwendung des Navigationsattributsverbessern. Dabei ist zunächst die Stammdatentabelle des InfoObjects/BI0/XMATERIAL auszuwählen, um darin auf dem Feld des Navigations-attributs einen Index anzulegen.

Abbildung 9.31 Indizierung von Navigationsattributen


374


Bitmap-Index Soll ein Bitmap-Index erstellt werden, können Sie genauso vorgehen wiebei der Erstellung des B-Tree-Index. Der Index wird aber zunächst nichtaktiviert, sondern nur gespeichert. Die Umstellung auf den Bitmap-Indexerfolgt über ein Datenbank-Utility �, mit dessen Hilfe die Speicherpara-

meter des Index geändert werden können � (siehe Abbildung 9.32).

Abbildung 9.32 Erstellung eines Bitmap-Index (I)

Beim Anlegen des Index kann entschieden werden, ob ein im ABAP Dic-tionary definierter Index auch auf der Datenbank physisch erstellt werdensoll. SAP NetWeaver BW stellt dabei drei Optionen alternativ zur Verfü-gung:

� Index auf allen Datenbanksystemen

Der Index soll stets auf der Datenbank angelegt werden.

� auf ausgewählten Datenbanksystemen

Der Index wird in Abhängigkeit vom verwendeten Datenbanksystemangelegt. Bei dieser Option muss angegeben werden, auf welchen Da-tenbanken der Index angelegt werden soll. Dies kann durch eine Aus-wahlliste (Liste der DB-Systeme, auf denen der Index angelegt werdensoll) oder eine Ausschlussliste (Liste der DB-Systeme, auf denen derIndex nicht angelegt werden soll) geschehen. In beiden Fällen könnenSie bis zu vier verschiedene DB-Systeme auflisten.


375


� kein Datenbankindex

Der Index wird nicht auf der Datenbank angelegt. Falls Sie diese Optionfür einen schon auf der Datenbank angelegten Index wählen, wird derIndex beim Aktivieren von der Datenbank gelöscht.

In der Administration der Speicherparameter kann über die SchaltflächeFür Neuanlegen der Speicherparameter für Bitmap-Index = X gesetztwerden. Mit dem nächsten Neuanlegen wird der Index als Bitmap-Indexerzeugt (siehe Abbildung 9.33). Anschließend muss der Index noch akti-viert werden.

Abbildung 9.33 Erstellung eines Bitmap-Index (II)

In jedem Falle sollte bei zusätzlichen Indizes auf Stammdatentabellen derPerformancegewinn nach Anlegen der Indizes geprüft werden, da zusätz-liche Indizes aufgrund des Wartungsaufwands die Ladeperformance derStammdaten und den Attributänderungslauf (Change-Run) negativ beein-

Hinweis

Ein Unique-Index muss immer auf der Datenbank angelegt werden, da er dieEinfügung doppelter Datensätze verhindert. Zur Gewährleistung der Datenkon-sistenz darf ein Unique-Index nicht von der Datenbank gelöscht werden.


376


flussen können. Weitere Informationen für die zusätzliche Indizierungvon Stammdatentabellen finden Sie auch im SAP-Hinweis 402469.

9.6.3 Index-Qualität überprüfen

In einzelnen Fällen kann es passieren, dass trotz des richtigen Index diePerformance unbefriedigend ist. In solchen Fällen sollten Sie die Qualitätdes Index überprüfen. Eine schlechte Index-Qualität kann immer dannauftreten, wenn Datensätze aus einer Tabelle gelöscht wurden. In diesemFall wird der Datensatz auch aus dem Index gelöscht. Der Platz im Index-baum bleibt leer, bis ein neuer Datensatz genau an diese Stelle eingefügtwird. Sind sehr viele solcher leeren Plätze vorhanden, müssen beimZugriff auf den Index mehr Blöcke gelesen werden, um alle zutreffendenDatensätze zu finden.

Index-Frag-mentierung

Man spricht in solchen Fällen von einer Fragmentierung des Index. DerGrad der Fragmentierung gibt an, wie gut der Platz in den Blöcken einesIndex genutzt wird: Je kleiner der Anteil des tatsächlich genutzten Platzesist, desto fragmentierter ist der Index. Der Index wird dann auch als»unbalanciert« oder »entartet« bezeichnet. Index-Fragmentierung trittmeist bei Tabellen mit großen Datenschwankungen auf.

Die Storage-Qualität des Index kann auf verschiedene Weise geprüft wer-den. In SAP NetWeaver BW existiert hierzu der ABAP Report RSORATAD,mit dem über die Transaktion SE38 einzelne Indizes untersucht, bzw. derReport RSORAISQN, mit dem mehrere Indizes gleichzeitig überprüft oderdie Analyse aller Indizes gestartet werden kann.

Das DBA-Cockpit bietet ebenfalls die Möglichkeit, die Index-Qualität zuanalysieren:

Analyse Index-Qualität

1. Wechseln Sie in der Transaktion DB02 über das Menü Segments � De-

tailed Analysis in die Eingabemaske zur Selektion der zu analysieren-den Tabelle oder des Indizes (siehe Abbildung 9.34), und geben Sie dentechnischen Tabellennamen bzw. Indexnamen ein.

Hinweis

Beachten Sie, dass Bitmap-Indizes keine Sperren auf Datensatzebene unterstüt-zen, sondern nur die gesamte Tabelle, die mit einem Bitmap-Index versehen ist,bei Datensatzänderungen gesperrt werden kann. Für InfoObjects mit Bitmap-Index kann dies den Nachteil bedeuten, dass die Parallelisierung von Datenpa-keten bei Ladevorgängen nicht mehr möglich ist.


377


Abbildung 9.34 DBA-Cockpit – Analyse Index-Qualität (I)

Selektieren Sie im anschließenden Bildschirm den zu untersuchendenIndex über die Schaltfläche Select Segments (siehe � in Abbildung 9.35).Die Berechnung der Index-Qualität wird über die Schaltfläche Validate �im unteren Bildschirm in der Registerkarte Main Data gestartet �. DasAnalyseprotokoll der Index-Qualität kann im unteren Bildschirm unterder Registerkarte Storage � Storage Quality abgerufen werden �.

Abbildung 9.35 DBA-Cockpit – Analyse Index-Qualität (II)


378


In dem entsprechenden Bildschirm � wird in der Zeile Index Storage

Quality ein Prozentwert der Index-Qualität angegeben. Ist der angege-bene Prozentwert < 70, wird in der Regel die Reorganisation des Indexempfohlen. Bei sehr kleinen Indizes können möglicherweise zu kleineProzentwert berechnet werden, obwohl der Index neu reorganisiertwurde. In diesem Fall sollte auch der Wert Number of blocks (used) über-prüft werden. Ist er < 10, empfiehlt es sich, die in den folgenden Ausfüh-rungen beschriebene Methode zu benutzen, um die Storage-Qualität zuermitteln:

1. Wechseln Sie in der Transaktion DB02OLD über die Schaltfläche De-

tailed Analysis in die Eingabemaske zur Selektion der zu analysieren-den Tabelle, und geben Sie den Tabellennamen ein.

2. Listen Sie im anschließenden Bildschirm über die Schaltfläche Table <->

Indices die Indizes der Tabelle auf, und markieren Sie den zu analysie-renden Index.

3. Verzweigen Sie über die Schaltfläche Detailed Analysis in die detail-lierte Analyse des Index.

Starten Sie die Berechnung der Index-Qualität über das Menü Analyze

index � Validate structure � Dialog.

Mit dem beschriebenen Verfahren werden die aktuellen Statistiken ausder Systemtabelle »index_stats« ermittelt. Beachten Sie, dass ein Validate

die Performance des Systems beeinträchtigen kann, da Teile des Indexgegen Updates gelockt sind. Führen Sie diese Kommandos also nicht zuZeiten durch, zu denen viele Benutzer auf die entsprechende Tabellezugreifen!

Überprüfen Sie nach Durchführung des Validate Structure-Laufs durcherneutes Aufrufen des Detailed Analysis-Bildschirms in der Rubrik Ana-

lysis of B*-tree den Wert Used in tree … without del. rows (sieheAbbildung 9.36). Dieser Wert gibt die aktuelle Storage-Qualität des Indexwieder und sollte nicht kleiner als 70% sein. Überprüfen Sie zudem in derRubrik B*-tree leaf blocks die Werte entries und deleted. Das Verhält-nis deleted/entries sollte kleiner als 25% sein.

Wenn die zu überprüfenden Index-Parameter nicht im Rahmen dergenannten Größen liegen, sollten Sie den Datenbankadministrator bitten,den Index neu aufzubauen. Hinweise zum Neuaufbau der Indizes einesInfoCubes finden Sie in Abschnitt 9.6.2.


379

Datenbankoptimierer 9.7

Abbildung 9.36 DBA-Cockpit – Analyse Index-Qualität (III)

9.7 Datenbankoptimierer

Die SQL-Anweisung einer Query beschreibt, welche Datenbankobjektebei Ausführung der Query zu lesen sind; sie kann aber nicht beschreiben,wie die Daten auf der Datenbank am besten gefunden werden. Die hierfürerforderliche Suchstrategie ermittelt eine Instanz in der Datenbank, die alsDatenbankoptimierer bezeichnet wird. Der Datenbankoptimierer ermit-telt anhand der SQL-Anweisung die günstigste Suchstrategie und erstellthierfür den günstigsten Ausführungsplan. Abbildung 9.37 verdeutlichtdas Problem.

Im vereinfachten Star-Schema-Modell in Abbildung 9.37 soll eine Abfragedie Menge für Material M6000 im Werk W1030 für den Monat Oktober2008 finden. Die Abfrage kann auf verschiedenen Wegen zum gewünsch-ten Ergebnis führen. Würde z.B. zunächst in der Zeitdimension der Monat10.2008 selektiert, müssten zunächst fünf Datensätze in der Faktentabellegesucht werden, die dann über die Einschränkung des Materials M6000und des Werks W1030 einen Datensatz in der Faktentabelle finden.


807

Index

A

ABAP Buffer � Programm-PufferABAP Dictionary 49ABAP/HEAP_AREA_DIA 67, 73, 77ABAP/HEAP_AREA_NONDIA 67, 74, 77ABAP/HEAP_AREA_TOTAL 73, 74, 77,

223ABAP/HEAPLIMIT 77ABAP-Applikationsserver 48ABAP-Dictionary-Puffer 70ADK 398ADK-Archivadministration 405Advanced Sizing � SizingAggregat 34, 501, 504

abschalten 543Aggregatbaum 539Aggregationsstufen 504anlegen 528auf Festwerten 513auf Hierarchieknoten 510auf Merkmalen 504auf Navigationsattributen 508auf zeitabhängigen Navigationsattribu-

ten 509auf zeitkonstanten Navigationsattributen

508automatische Erstellung 519Bewertung 530Blockgröße 551Delta-Verfahren 550des Hierarchie-/Attributänderungslaufs

545Dimensionentabelle 505, 519E-Faktentabelle 505, 536Faktentabelle 519F-Faktentabelle 505, 536Hierarchie-/Attributänderungslauf 508hochrollen 536Kennzahlen mit Ausnahmeaggregation

507, 514Komprimierung 536Line-Item-Aggregat 517Line-Item-Dimension 506manuelle Erstellung 524Neuaufbau 550

Aggregat (Forts.)optimieren 522, 524, 541Roll-up 503, 532, 538Roll-up-Hierarchie 539, 540vorschlagen aus BW-Statistik 520, 521vorschlagen aus Query-Definition 520,

522Aktivierungs-Queue 155ALE 659Alloc fault rate 196Allocation retries 196allokierter Speicher 219Antwortzeit in einem SAP-System

Ausführungszeit 252Datenbankzeit 252Dispatcher-Wartezeit 252Enqueue-Zeit 252Ladezeit 252Processing-Zeit 253Roll-in 252Roll-out 252Roll-Wartezeit 252

Anwendungsmonitor Benutzervertei-lung 715

Application Link Enabling 659Applikationsserver 189Archivdatei 400, 403Archivierung 398, 399, 404Archivierung von Anwendungs-Logs

424Archivierung von Basis-InfoCubes und

DataStore-Objekte 399Archivierung von Request-Informationen

415Archivierungsobjekt 398, 401, 406Archivierungs-Request 404Archiving Development Kit 398asynchroner RFC 658Aufrufer 693Ausführungsplan 336, 360, 361, 527

Aufbau 361Full Table Scan 337, 363Index Full Scan 363Index Range Scan 338, 364Index Unique Scan 338, 364Star-Join-Ausführungsplan 360


808

Index

Auslagerungsspeicher 68, 222, 223Ausnahmeaggregation 514

Bezugsmerkmal 515

B

BAPI 660BAPI-Programmschnittstelle 38BAPI-Schnittstelle 44Batch-Manager 664Benutzerkontext 63, 64, 65, 67, 73, 249Benutzermodus 236, 255Betriebssystemkollektor SAPOSCOL 226Betriebssystemmonitor 226Bewegungsdaten 686BEx Analyzer 490BEx Information Broadcaster 44, 478BEx Repository Sheet 493binäre Suche 339binary search � binäre SucheBinary Tree 341BI-Systemlastanalyse 261BI-Systemlastmonitor 261, 283BI-Trace-Tool 470

Aufzeichnung von Traces 470CAT-Tool 474

Blade-Server 565Blade-System � Blade-ServerBRCONNECT 385B-Tree 341, 342Business Application Programming Inter-

face 44Business Content 36, 649Business Explorer 43

Analyzer 43Query Designer 43Web Analyzer 43Web Application Designer 43

Business Warehouse Accelerator 559Business-Content 313BW Accelerator Engine 564BW Statistics 261, 519BWA Index Maintenance Wizard 576BWA � Business Warehouse AcceleratorBWA-Datenkonsistenz-Checkcenter 602BWA-Index 560, 562

anlegen 576ausschalten 577Change-Run 581Delta-Index 582

BWA-Index (Forts.)füllen 577, 588Horizontale Partitionierung 561Komprimierung 562löschen 581Neuaufbau 586optimieren 582, 588Roll-up 579Spaltenbasierte Speicherung 561Testwerkzeuge 591

BWA-Monitor 575Einstellung globale Parameter 589

BW-Anwendungsanalyse 726BW-Statistiken 739Datenverteilung 727InfoCube-Design 733InfoProvider-Verteilung 728Line-Item-Dimensionen 735Query-Definition 736Query-Nutzung 739Upload-Prozesse 740

BW-Frontend-Checktool 499BW-Performance-Review 705

BW-Anwendungsanalyse 726Hardwareanalyse 718Performanceüberblick 711Softwareanalyse 707

BW-Systemlast 282

C

Cache-Gültigkeit 452Cache-Invalidierung 440Cache-Modus 435, 459Cache-Parameter 433Cache-Struktur 448Cache-Verdrängung 447Calls 197CAT-Tool 470, 474CATT-Trace 474CCMS 240CCMS Alert-Monitor 241Change-Log 155Change-Run 545, 547, 548

Delta-Verfahren 550parallel 555

ChecklisteBW-Anwendungsanalyse 741Hardware 724Performanceüberblick 717


809

Index

Checkliste (Forts.)Softwareanalyse 710

Clustering 618Clustering-Index 622Index-Clustering 618Mehrdimensionales Clustering (MDC)

619Clustering-Index 622Cost-based Optimizer 380, 382CPU-Auslastung 227CPU-Engpass 227CPU-Kapazität 228CPU-Zeit 253CSV-Format 650CUA Buffer 71

D

Data Buffer 193Data Warehouse 27, 32

Architektur 32Frontend 35, 44

Data Warehousing Workbench 36Data-Mart-Benchmark 99DataMart-Interface 649DataProvider 493DataSource 652, 654, 656

3.x DataSource 6547.0 DataSource 655

DataStore-Objekt 40, 636Clustering 637Eindeutige Datensätze 639Eintellung der Laufzeitparameter 641Indizierung 638Standard-DataStore-Objekt 155Unterdrückung Optimizer-Statistiken

640Vermeidung der SID-Ermittlung 636

Data-Warehouse-Management 647Datenarchivierungsprozess 399, 400,

401Datenbank

Index 35, 331Statistik 331

Datenbankinstanz 190Datenbankmonitor 190Datenbankoptimierer 334, 336, 379

Cost-Based Optimizer 380Rule-based Optimizer 380

Datenbankpuffer 191, 205Datenbankserver 190Datenbank-View

RSDDSTAT_OLAP 278Datenbankzeit 250, 252Datenbewirtschaftung 647Datenextraktion 38, 647, 649, 650, 651,

669aus flachen Dateien 650aus Fremdsystemen 651aus multidimensionalen Datenbanken

650aus relationalen Datenbanken 650aus SAP-Systemen 649Hauptspeicherbedarf 669

Daten-IDoc 675, 679, 696Datenpaket 606, 666, 669, 679, 681,

682, 696Datenpaketgröße 667, 668, 670

Pflege 670Datenpaketnummer 661Datenpufferqualität 195Datentransferprozess 677

Debugging 704Simulation 701

Datentransferprozess (DTP) 655Datenwürfel 29, 33, 34DB Connect 38, 650DB_BLOCK_BUFFERS 194DB_BLOCK_SIZE 194, 196DB_CACHE_SIZE 194DBA-Einplanungskalender 211, 386DB-Laufzeit 307DB-Parameter 211DB-Statistiken 331, 382

Administration 384BRCONNECT 385DBA-Einplanungskalender 386UPDATE STATISTICS 384, 388, 391

Debug-Optionen 462Delta-Cache 441

Gruppierung 442Delta-Index 582Design Items 493DIAG-Protokoll 491Dialog-Workprozess 72, 73Dimensionen-ID 348, 684Dimensionentabelle 40, 348, 684, 686Dispatcher 248


810

Index

DSO � DataStore-ObjektDSO-Objekt

Aktive Daten 155Aktivierungs-Queue 155Change-Log 155

DTP 677

E

E-Faktentabelle 349, 606EM/BLOCKSIZE_KB 76EM/INITIAL_SIZE_MB 65, 72, 76, 218Enqueue-Zeit 251, 252Enterprise Core Component 25Erst-Sizing � SizingESM-Puffer � Export/Import-PufferETL-Prozess 33, 647Execution Plan � AusführungsplanExpertenmodus � BenutzermodusExpert-Sizing � SizingExport/Import-Puffer 216Export-DataSource 649Extended Memory 218, 237externer Modus 63Extraktion 647, 660Extraktionsstruktur 38, 649Extraktor 656, 657

anwendungsspezifisch 656anwendungsunabhängig 657

Extraktorprogramm 649Extraktstruktur 654, 656

F

Faktentabelle 40, 348, 683E-Faktentabelle 349F-Faktentabelle 349

Festplattenkapazität 101F-Faktentabelle 349, 606flacher Index 572, 588flaches Aggregat � Line-Item-AggregatFlatfile 650, 672Flatfile-Daten 38Frontend-Laufzeit 309Full Table Scan 203, 337, 363

G

Generic Key Buffer 71globale Benutzerübersicht 715GUI-Zeit 250

H

Hardwareanalyse 718CPU-Auslastung 719Datenbankperformance 721Datenbankwachstum 722Hardwareprofil 718Speicherauslastung 720

Hauptindex 582Hauptspeicher 219Hauptspeicher-Cache 432Heap Memory 218, 237Hierarchie 39Hierarchie-/Attributänderungslauf 545

Parametrisierung 547Überwachung 549

Histogramm 381Hit 193Hitratio 193

I

I/O-Engpass 229, 721ICF 50ICF-Service 51, 52ICM 50ICM-Monitor 53ICM-Profilparameter 54IDoc 679, 691IDoc-Status 695ILM 396Import-/Export-Puffer 71Index 35, 331, 335

Administration 366B*-Tree-Index 343Bitmap-Index 344, 353, 356B-Tree-Index 341, 342, 352, 353Clustering-Index 352Encode Vector Index 351fehlende Indizes 368Feinanalyse Index-Qualität 378Fragmentierung 376Grobanalyse Index-Qualität 376


811

Index

Index (Forts.)Index-Qualität 376Indexschema 350Indizierungsschema 347löschen 372Neuaufbau 372, 378P-Index 335, 350, 352, 608Primärindex 335Radix-Index 351Reparatur 373Sekundärindex 335Tabellen-Index 341überprüfen 367Unique-Index 335

Index Full Scan 363Index Range Scan 338, 364Index Unique Scan 338, 364InfoCube 29, 40

E-Faktentabelle 606F-Faktentabelle 606Komprimierung 605, 607Partitionierung 609providerspezifische Eigenschaften 632

Info-IDoc 660, 675, 679, 690, 694Info-IDoc-Status 694, 695InfoObject 39InfoPackage 655InfoProvider 40Information Lifecycle Management 396InfoSet 40, 41InfoSpoke 649Intermediate Document 660, 691interner Modus 63Internet Communication Framework 50Internet Communication Manager 50Internet-Communication-Framework-

Service 51

J

J2EE-Applikationsserver 48Java Database Dictionary 49

K

Kardinalität 344, 353Kennzahl 39Kommunikationsschnittstellen 647, 648Kommunikationsstruktur 654

Kommunikationstechniken 657Komprimierung 605, 607Kontextwechsel 64, 65

L

Lade-Request 689, 690Gesamtstatus 692Kopfdaten 689Statusinformationen 691

Ladezeit 249Leaf-Block 344Leaf-Row 344Lesemodus 454Line-Item-Aggregat 517Line-Item-Dimension 127, 353, 517Local Memory 62Log Buffer 196Logical Unit of Work 659logischer Index � BWA-IndexLong table scans 203LUW � Logical Unit of Work

M

MDC-Dimension 619, 620, 622, 623MDX 44, 428MDX-Prozessor 429Memory/Disk Sort 204Memory-Management-Monitor 68Merkmal 39, 41Metadaten 42

Management 42Metadaten-Repository 42Mixed-Load-Benchmark 101Moduskontext 63Monitoring 688

Datenextraktion 689Datentransferprozesse (DTP) 698

Multidimensional Expression 44, 428multidimensionale Datenhaltung 29MultiProvider 40, 41, 480, 632

feste Adressierung von InfoProvidern 486

heterogene 168heterogene MultiProvider 482homogene MultiProvider 167, 481MultiProvider-Queries analysieren 483parallele Verarbeitung 482


812

Index

MultiProvider (Forts.)Selektion durch Festwerte 487Selektion durch Kennzahlen 486Selektion durch OLAP-Hints 488sequentielle Verarbeitung 483

MultiProvider-Partitionierung 632

N

Nametab-Puffer 70Nearline-Speicherung 396, 398Nicht-Dialog-Workprozess 72, 73NLS-API 396Normalform 32Nummernkreis 684Nummernkreisobjekt 684Nummernkreispuffer 684

O

ODBO 428ODBO-Schnittstelle 44OLAP 29, 31

Datenhaltung 29OLAP-Cache 306, 308, 309OLAP-Laufzeit 309OLAP-Prozessor 281

OLAP-BAPI 44, 428OLAP-Cache 431, 433

Cache-Gültigkeit 452Cache-Invalidierung 440Cache-Modus 435Cache-Parameter 433Cache-Struktur 448Cache-Verdrängung 447Delta-Cache 441globaler Cache 431Hauptspeicher-Cache 432lokaler Cache 431OLAP-Cache-Monitor 444Persistenter Cache 434Persistenz-Modus 436

OLAP-Cache-Monitor 444OLAP-Hints 488OLAP-Prozessor 427, 429OLAP-System 31, 32OLE DB for OLAP 44OLE DB für OLAP � ODBOOLTP 31

OLTP-System 31, 32Online Analytical Processing � OLAPOnline Transaction Processing 31Open Analysis Interface 428Open Hub Destination 649Open Hub Service 649Open SQL 49Open SQL for Java 49Optimierungsmodus 460

P

Page-Speicher 237Paging Area 217Paging-Datei � AuslagerungsspeicherParses 198Partitionierung 34, 167, 356, 609

auf Applikationsebene 167, 631auf Datenbankebene 610Clustering 618E-Faktentabelle 613Einstellung 614Einstellung der Datenverteilung 633F-Faktentabelle 611logische 34logische Partitionierung 631Maximalzahl an Partitionen 615Partition 34Partitionierungsmerkmal 610, 632Partitionierungsschema 613, 617, 624physiche Partitionierung 34Range-Partitionierung 610, 611von Aggregaten 617

Partitionierungsmerkmal 355Performanceüberblick 711

ABAP-Laufzeitfehler (Dumps) 714Allgemeine Systemlast 711Benutzeranzahl 715BW-Systemlast 712

Persistent Staging Area (PSA) 41, 655, 660, 679

Persistenter Cache 434Persistenz-Modus 436PGA � Program Global AreaPhysical Reads 193physischer Index � BWA-IndexP-Index 608Plug-in 649Primärindex 335


813

Index

privater Speicher 65PRIV-Mode 66, 73Processing-Zeit 253Program Global Area 192, 204

Sort Buffer 193Programm-Puffer 71, 215PSA 41, 660, 681, 696

Verarbeitungsoptionen 680PSAPTEMP 208PSA-Tabellen 644, 661

Löschen von Requests 644Partitionierung 645

Q

qRFC � queued RFCQuellsystem-Typen 648Query-Eigenschaften 453Query-Monitor 336, 360, 383, 452, 462,

525Cache-Modus 459Debug-Optionen 462, 525Lesemodus 454MultiProvider-Queries analysieren 483Optimierungsmodus 460Performance-Informationen 466Query-Eigenschaften 453Request-Status 461technische Informationen 467

queued RFC 659

R

Range-Partitionierung 610RDISP/PG_MAXFS 70RDISP/PG_SHM 70RDISP/ROLL_MAXFS 76RDISP/ROLL_SHM 76, 218Reads 193Rechner 189Redo Log Buffer 196Remote Function Call � RFCRepartitionierung 623, 625

Monitoring 629vollständige Repartitionierung 625von Aggregaten 629Zusammenfassen und Anhängen von Par-

titionen 628Reportingperformance 427

Repository-Puffer 70Request 539Request-ID 533, 534, 536, 538, 605,

661, 689Request-Status 461Re-Sizing � SizingRFC 657, 679

asynchroner RFC 658queued RFC 659synchroner RFC 658transaktionaler RFC 659

Roll Area 217Roll-back 197Roll-in 65, 252Roll-out 65, 252Roll-Speicher 218, 237Roll-up 532, 537

automatisch 538manuell 538überwachen 543

Roll-up-Hierarchie 539, 540Roll-up-Job 543Root-Block 344Roundtrip 250, 491RSDDSTAT_DM 306RSDDSTAT_OLAP 278, 306RSMO-Monitor 689Rule-based Optimizer 380

S

SAP Application Performance Standard (SAPS) 99

SAP BW Reporting Agent 478SAP ECC 6.0 25SAP Executable Buffer � Programm-Puf-

ferSAP Extended Memory 63, 65SAP GoingLive Check 88SAP GUI 47SAP Heap Memory 65, 67, 71SAP NetWeaver Application Server 47,

48SAP NetWeaver Application Server ABAP

49SAP NetWeaver Application Server Java

49SAP Paging Memory 70SAP Quick Sizer 87, 88


814

Index

SAP Roll Memory 63, 71SAP Service Marketplace 87, 88, 98SAP Solution Manager 243SAP Special Expertise Partner 569SAP-Enqueues 251SAP-Erweiterungsspeicher 63, 65, 71,

72, 73SAP-GUI-Puffer 71SAP-Instanz 189SAP-Kalenderpuffer 71SAP-Memory-Management-Monitor

212, 218, 219SAP-Memory-Managementsystem 71SAP-Paging Memory 223SAP-Performancemonitor 187SAP-Profilparameter 69, 75, 77SAP-Puffer 70, 214SAP-Pufferqualität 214

Hitratio 214SAP-Rollbereich 63, 64

globaler SAP-Rollbereich 64lokaler SAP-Rollbereich 64

SAP-Rolldatei 64SAP-Speicherbereiche 61, 69, 212, 217SAP-Speichermanagement 63SAP-Systemlastanalyse 247, 257SAP-Workprozess 231SAP-Workprozess-Monitor 233SAP-Workprozess-Typen 232, 257Screen Buffer 71Sekundärindex 335Selektionsschema 401Semantische Gruppe 402Server-Blade � Blade-ServerService Packages 706Service-Ingenieur-Modus � Benutzermo-

dusSGA � System Global AreaShared Buffer 71Shared Memory 62Shared Pool 195, 198SHARED_POOL_SIZE 195, 197Short table scans 203SID-Schlüssel 348, 687SID-Tabelle 686, 687Simple Object Access Protocol 651Single Record TableBuffer 71Sizing 82, 108

Advanced Sizing 84Datenwachstum 103

Sizing (Forts.)Delta-Sizing 85Dimensionentabellen 101Erst-Sizing 84Expert-Sizing 84Faktentabelle 102Festplattenkapazität 101InfoCubes 101Re-Sizing 85SAP GoingLive Check 88SAP Quick Sizer 87Sizing-Prozess 87Upgrade-Sizing 85

SOAP � Simple Object Access ProtocolSoftwareanalyse 707

SAP NetWeaver BW 708SAP-Frontend 708

SP-Stack � Support Package StackStammdaten 39, 41, 686Star-Schema 40, 347Suchalgorithmus � binäre SucheSupport Package 55, 57Support Package Manager 58Support Package Stack 57, 58Swapping 68Swaps 215Swap-Space � Auslagerungsspeichersynchroner RFC 658System Global Area 191, 204

Data Buffer 192Java Pool 192Large Pool 192Log Buffer 192Redo Buffer 192Shared Pool 192Streams Pool 192

Systemlastmonitor 253, 254, 255, 258, 281

T

Tabellen-Puffer 71Table Scan 203Technischer Content 312, 591

Übernahme des Technischen Contents 322

Text 39Text Retrieval and Information Extraction

� TREXtransaktionaler RFC 659


815

Index

Transfermethoden 679IDoc 679PSA 679, 680

Transformation 647TREX 563

Revision 565tRFC 659, 679

U

Übertragungsregeln 654Übertragungstechniken 647, 659, 660

Application Link Enabling 659Intermediate Document 660

UD Connect 38, 650UNION-Operation 41Unique-Index 335

V

Verbuchungssimulation 701VirtualProvider 40, 41virtueller Speicher 62

W

Workload-Kollektor-Datenbank 256Workprozess � SAP-Workprozess 231Workprozess-Monitor 233

X

XML for Analysis 44, 428XML/A 428XML/A-Schnittstelle 44XML-Daten 38, 651

Z

Zeitscheibenarchivierung 401zentraler Überwachungsmonitor �

CCMSZero Administration Memory Manage-

ment 75ZTTA/ROLL_AREA 64, 74, 76ZTTA/ROLL_EXTENSION 76ZTTA/ROLL_FIRST 76


sap netweaver bw-performanceoptimierung...7 inhalt 1 einleitung 19 a t dagnu r hü f n 2ei warehouse...

Documents