SAP NetWeaver BW-Performanceoptimierung
Werbung
1182.book Seite 3 Mittwoch, 4. März 2009 6:38 18 Thomas Schröder SAP NetWeaver BW-Performanceoptimierung ® Bonn 폷 Boston 1182.book Seite 5 Mittwoch, 4. März 2009 6:38 18 Auf einen Blick 1 Einleitung ................................................................ 2 Einführung Data Warehouse und SAP NetWeaver BW ....................................................... 3 19 27 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- und Ladeprozessen ........................................................ 647 16 BW-Performance-Review ....................................... 705 A Anhang .................................................................... 745 B Der Autor ................................................................ 805 1182.book Seite 7 Mittwoch, 4. März 2009 6:38 18 Inhalt 1 Einleitung ................................................................. 19 2 Einführung Data Warehouse und SAP NetWeaver BW ................................................. 27 2.1 2.2 2.3 2.4 3 31 32 35 36 38 39 42 42 SAP NetWeaver Application Server ............................. Softwarekomponenten des SAP NetWeaver BW-Systems ............................................................... 48 55 Grundlagen der SAP-Speicherkonfiguration ............ 61 4.1 4.2 5 27 Grundlagen der SAP NetWeaver BW-Architektur ... 47 3.1 3.2 4 Einführung Data Warehouse ....................................... Unterschiede zwischen operativen und dispositiven Systemen .................................................................... Aufbau von Data-Warehouse-Systemen ...................... Überblick über SAP NetWeaver BW 7.0 ...................... 2.4.1 Administration und Customizing .................... 2.4.2 Datenextraktion in SAP NetWeaver BW ......... 2.4.3 Datenablage in SAP NetWeaver BW .............. 2.4.4 Metadatenmanagement ................................. 2.4.5 Analyse und Reporting ................................... Begriffserklärungen ..................................................... Funktionsweise des SAP-Speichermanagements .......... 4.2.1 Benutzerkontext und Moduskontext .............. 4.2.2 SAP-Speichertypen ......................................... 4.2.3 Reihenfolge der Speicherbelegung ................. 4.2.4 Zero Administration Memory Management unter Windows .............................................. 4.2.5 SAP-Profilparameter ....................................... 62 63 63 64 71 75 75 SAP NetWeaver BW-Sizing ..................................... 81 5.1 5.2 5.3 5.4 Sizing-Methoden ........................................................ Sizing-Berechnungen .................................................. Der Sizing-Prozess ...................................................... SAP Quick Sizer .......................................................... 83 86 86 88 7 1182.book Seite 8 Mittwoch, 4. März 2009 6:38 18 Inhalt 5.5 5.6 5.7 5.8 5.9 6 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 Das Star-Schema-Datenmodell ................................... Das erweiterte Star-Schema-Datenmodell in SAP NetWeaver BW ................................................... 6.2.1 Faktentabellen in BW .................................... 6.2.2 Dimensionentabellen in BW .......................... 6.2.3 Zeiten ........................................................... 6.2.4 Kennzahlen ................................................... 6.2.5 Einheiten ....................................................... Modellierung des SAP NetWeaver BW-Datenmodells (InfoCube) ................................................................. 6.3.1 Stammdatentabellen in SAP NetWeaver BW ... 6.3.2 SID-Tabellen in SAP NetWeaver BW ............. 6.3.3 Externe Hierarchien in SAP NetWeaver BW ... 6.3.4 Zusammenfassung ......................................... Realtime-InfoCubes ................................................... DataStore-Objekte (DSO) .......................................... 6.5.1 Standard-DataStore-Objekte ......................... 6.5.2 DataStore-Objekte für direktes Schreiben ...... 6.5.3 Schreiboptimierte DataStore-Objekte ............ Virtuelle InfoProvider ................................................. InfoSets ..................................................................... MultiProvider ............................................................ Kennzahlenmodell und Kontenmodell ....................... Modellierungsaspekte aus Performancesicht .............. 110 111 114 114 115 116 123 124 129 137 143 150 152 154 155 157 157 159 162 166 171 173 Analyse von Datenbank, Speicher und Hardware .... 181 7.1 8 99 101 101 103 105 105 105 107 108 SAP NetWeaver BW-Datenmodell .......................... 109 6.1 6.2 7 SAP Application Performance Standard (SAPS) ........... Sizing der Festplattenkapazität ................................... 5.6.1 Kalkulation von InfoCubes ............................. 5.6.2 Kalkulation von DataStore-Objekten ............. 5.6.3 Kalkulation von PSA-Tabellen ........................ 5.6.4 Gesamtkalkulation Festplattenkapazität ......... CPU-Sizing ................................................................. Memory-Sizing .......................................................... Zusammenfassung ...................................................... Allgemeine Datenbankaspekte in SAP NetWeaver BW ................................................... 182 7.1.1 BW-Tabellentypen ......................................... 182 1182.book Seite 9 Mittwoch, 4. März 2009 6:38 18 Inhalt 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 8 7.1.2 Indextypen in SAP NetWeaver BW ................. 7.1.3 Star-Transformation ....................................... Übersicht SAP-Performanceanalysewerkzeuge ............ Analyse der Datenbank ............................................... 7.3.1 Begriffserklärungen ........................................ 7.3.2 Speicherbereiche der Datenbank .................... 7.3.3 Analyse der Shared SQL Area ......................... 7.3.4 Analyse der Table Scans ................................. 7.3.5 Analyse der Sortiervorgänge ........................... 7.3.6 Analyse der Datenbankpuffer ......................... 7.3.7 Analyse von Speicherplatz, Tabellen und Indizes ........................................................... 7.3.8 Überprüfung der DB-Parameter ..................... 7.3.9 DBA-Einplanungskalender .............................. Analyse der SAP-Speicherbereiche .............................. 7.4.1 Analyse der SAP-Puffer .................................. 7.4.2 Analyse des SAP-Speichers ............................. 7.4.3 Analyse des allokierten Speichers und des Hauptspeichers ........................................ 7.4.4 Analyse des Auslagerungsspeichers ................ 7.4.5 Analyse der Profilparameter des SAP-Memory-Management-Monitors ............ Analyse der Hardware ................................................. 7.5.1 Analyse eines CPU- bzw. Hauptspeicher-Engpasses ............................... 7.5.2 Analyse von Schreib-/Lese-Problemen (I/O) ... Analyse der SAP-Workprozesse .................................. Analyse der Benutzermodi .......................................... Speicherverbrauch von Benutzer und Modi analysieren ........................................................ Kontinuierliche Systemüberwachung (Monitoring) ...... 7.9.1 Zentraler Überwachungsmonitor im CCMS ..... 7.9.2 SAP Solution Manager ................................... 7.9.3 SAP Solution Manager Diagnostics ................. 184 185 187 189 189 191 198 203 204 205 206 211 211 212 214 217 219 222 225 226 227 229 231 236 237 239 240 243 244 Analyse der Systemlast ............................................ 247 8.1 Grundlagen und Begriffe ............................................. 248 8.1.1 Ablauf eines Transaktionsschrittes im SAP-System ................................................... 248 8.1.2 Verteilung der Antwortzeiten ......................... 252 9 1182.book Seite 10 Mittwoch, 4. März 2009 6:38 18 Inhalt 8.2 8.3 8.4 8.5 8.6 8.7 9 253 257 261 261 265 268 270 272 275 276 281 288 290 294 296 298 301 306 312 322 323 324 328 Indizes und DB-Statistiken ...................................... 331 9.1 9.2 9.3 10 Der Systemlastmonitor ............................................... SAP-Systemlastanalyse ............................................... BW-Systemlastanalyse ................................................ 8.4.1 BW-Query-Laufzeit-Statistiken ...................... 8.4.2 Event-Konzept der BW-Statistikdaten ........... 8.4.3 Pflege der BW-Statistikeigenschaften ............. 8.4.4 Analyse der Statistikdaten von MultiProviderQueries ......................................................... 8.4.5 Löschung von BW-Statistikdaten ................... Werkzeuge für die Analyse der Statistikdaten ............. 8.5.1 Analyse der Statistikdaten mit der Transaktion SE16 ........................................... 8.5.2 Analyse der Statistikdaten mit dem Systemlastmonitor (Transaktion ST03N) ........ 8.5.3 Analyse der Statistikdaten mit dem Query-Monitor (Transaktion RSRT) ................ 8.5.4 Analyse der Statistikdaten mit Queries des Technischen Contents ............................. 8.5.5 Analyse der Statistikdaten mit BEx Web Analyzer ................................................ 8.5.6 Analyse der Statistikdaten mit dem Analyseund Service-Toolset (Transaktion ST13) ......... 8.5.7 Anwendungsanalyse (Transaktion ST14) ........ 8.5.8 Analyse der Statistikdaten mit dem BW Administration Cockpit ........................... 8.5.9 Auswertungsstrategien und Tipps .................. Technischer Content .................................................. Übernahme des Technischen Contents ....................... 8.7.1 Übernahme Technischer Content (Gesamt) .... 8.7.2 Übernahme Technischer Content mit BW-Content-Sammelanschluss ...................... 8.7.3 Prozessketten des Technischen Contents ....... Grundlagen der DB-Speicherverwaltung ..................... Grundlagen zu Indizes und Ausführungsplänen .......... 9.2.1 Ein Einführungsbeispiel ................................. 9.2.2 Tabellen-/Indexzugriffsalgorithmen ............... 9.2.3 Join-Algorithmen ........................................... Strukturtypen von Indizes .......................................... 332 334 334 337 339 341 1182.book Seite 11 Mittwoch, 4. März 2009 6:38 18 Inhalt 9.4 9.5 9.6 9.7 9.8 9.9 Indizierungsschema in SAP NetWeaver BW ................ 9.4.1 Indizierung bei Standard-InfoCubes ............... 9.4.2 Indizierung bei transaktionalen InfoCubes ...... 9.4.3 Indizierung partitionierter InfoCubes (Oracle) .......................................................... 9.4.4 Indizierung von DataStore-Objekten .............. 9.4.5 Indizierung der Stammdatentabellen (X-/Y-Tabellen) .............................................. Star-Join-Ausführungsplan .......................................... Administration der Indizes .......................................... 9.6.1 Indizes überprüfen ......................................... 9.6.2 Indizes aufbauen ............................................ 9.6.3 Index-Qualität überprüfen ............................. Datenbankoptimierer ................................................. DB-Statistiken ............................................................ Administration der DB-Statistiken ............................... 9.9.1 Administration der DB-Statistiken mit BRCONNECT ................................................. 9.9.2 Administration der DB-Statistiken mit DBA-Einplanungskalender .............................. 9.9.3 Administration der DB-Statistiken mit Transaktion DB20 .......................................... 9.9.4 Administration der DB-Statistiken für InfoCubes ...................................................... 347 347 354 355 356 358 360 366 367 371 376 379 382 384 385 386 391 393 10 Information Lifecycle Management und Archivierung ............................................................. 395 10.1 10.2 10.3 10.4 10.5 10.6 Archivieren und Löschen von Basis-InfoCubes und DataStore-Objekten ................................................... 10.1.1 Durchführung der Archivierung ...................... 10.1.2 Durchführung des Löschens ........................... 10.1.3 Wiederherstellung archivierter Daten ............. Löschen von Stammdaten ........................................... Löschen von PSA-Daten und Change-Log ................... Archivieren und Löschen von Request-Informationen ... 10.4.1 Durchführung der Archivierung ...................... 10.4.2 Durchführung des Löschens ........................... 10.4.3 Zurückladen von Request-Verwaltungsdaten ... Löschen von BW-Statistikdaten .................................. Archivieren und Löschen von Anwendungs-Logs ........ 399 404 405 407 408 412 415 418 420 421 423 424 11 1182.book Seite 12 Mittwoch, 4. März 2009 6:38 18 Inhalt 11 Reportingperformance ............................................. 427 11.1 11.2 11.3 11.4 11.5 11.6 11.7 11.8 11.9 OLAP-Prozessor ......................................................... OLAP-Cache .............................................................. 11.2.1 Hauptspeicher-Cache .................................... 11.2.2 Persistenter Cache ......................................... 11.2.3 Cache-Modus ................................................ 11.2.4 Cache-Invalidierung und Delta-Caching ......... 11.2.5 Cache-Partitionierung .................................... OLAP-Cache-Monitor ................................................ 11.3.1 Cache-Verdrängung und -Auslagerung .......... 11.3.2 Cache-Struktur .............................................. 11.3.3 OLAP-Eigenschaften für InfoCubes ................ Query-Monitor der Analytical Engine ......................... 11.4.1 Query-Eigenschaften ..................................... 11.4.2 Debug-Optionen ........................................... 11.4.3 Performance Informationen im Query-Monitor .............................................. 11.4.4 Technische Informationen im Query-Monitor .............................................. BW-Trace-Tool .......................................................... 11.5.1 Aufzeichnung von Traces ............................... 11.5.2 Abspielen eines aufgezeichneten Trace .......... CAT-Tool ................................................................... BEx Information Broadcaster ...................................... MultiProvider-Queries ............................................... Frontend-Performance und Netzwerk ........................ 11.9.1 BEx Analyzer ................................................. 11.9.2 Hinweise zur Performanceoptimierung .......... 11.9.3 Web-Reporting ............................................. 11.9.4 Hardware- und Software-Empfehlungen für das SAP NetWeaver BW-Frontend ........... 427 431 432 434 435 440 442 444 447 448 451 452 453 462 466 467 470 470 472 474 478 480 490 490 493 498 498 12 Performanceoptimierung durch Aggregate ............. 501 12.1 12 Grundlagen ................................................................ 12.1.1 Aggregate auf Merkmalen ............................. 12.1.2 Aggregate auf Navigationsattributen ............. 12.1.3 Aggregate auf Hierarchieknoten .................... 12.1.4 Aggregate auf Festwerten .............................. 12.1.5 Ausnahmeaggregationen in InfoCubes ........... 12.1.6 Line-Item-Aggregate (flache Aggregate) ........ 504 504 508 510 513 514 517 1182.book Seite 13 Mittwoch, 4. März 2009 6:38 18 Inhalt 12.2 12.3 12.4 12.5 Automatische Erstellung von Aggregaten .................... 12.2.1 Aggregate vorschlagen aus BW-Statistik ......... 12.2.2 Aggregat vorschlagen aus Query-Definition .... Manuelle Erstellung von Aggregaten ........................... 12.3.1 Analyse der Query mit dem Query-Monitor (RSRT) ............................................................ 12.3.2 Anlegen des Aggregats ................................... 12.3.3 Prüfung und Bewertung von Aggregaten ........ Pflege von Aggregaten ................................................ 12.4.1 Roll-up von Aggregaten ................................. 12.4.2 Prüfung des Aggregatbaums (Roll-up-Hierarchie) ....................................... 12.4.3 Zusammenfassung von Aggregaten/ Optimierung .................................................. 12.4.4 Abschaltung von Aggregaten .......................... 12.4.5 Datenbeladung und Roll-up von Aggregaten auswerten/überwachen .................................. 12.4.6 Hierarchie-/Attributänderungen ..................... 12.4.7 Parametrisierung des Hierarchie-/ Attributänderungslaufs ................................... 12.4.8 Hierarchie-/Attributänderungslauf auswerten/ überwachen ................................................... Performanceeinstellungen für die Verwaltung von Aggregaten ................................................................. 12.5.1 Delta-Verfahren/Neuaufbau ........................... 12.5.2 Blockgrößen für den Neuaufbau von Aggregaten .................................................... 12.5.3 Prä-Analyse des Aggregate-Füllens ................. 12.5.4 Parallelisieren von Verwaltungsprozessen der Aggregate ................................................ 519 521 522 524 525 528 530 532 532 539 541 543 543 545 547 549 550 550 551 553 555 13 Business Warehouse Accelerator ............................. 559 13.1 13.2 13.3 13.4 Grundlagen des Business Warehouse Accelerators ...... Architektur des Business Warehouse Accelerators ....... Verbindung von BW Accelerator und SAP NetWeaver BW ................................................... InfoCube-Architektur im BW Accelerator .................... 13.4.1 Faktentabellen im BW Accelerator ................. 13.4.2 Dimensionentabellen im BW Accelerator ....... 13.4.3 Stammdatentabellen im BW Accelerator ........ 560 564 569 571 571 572 572 13 1182.book Seite 14 Mittwoch, 4. März 2009 6:38 18 Inhalt 13.5 13.6 13.7 Administration des BW Accelerators .......................... 13.5.1 Erstellen, Füllen und Löschen von BWA-Indizes ................................................. 13.5.2 Hierarchie- und Attributsänderungen (Change-Run) ................................................ Optimieren von BWA-Indizes .................................... 13.6.1 BWA-Delta-Index .......................................... 13.6.2 Neuaufbau von BWA-Indizes ......................... 13.6.3 Verteilung von BWA-Indizes .......................... 13.6.4 Globale Parameter von BWA-Indizes ............. Analysieren und Testen von BWA-Indizes .................. 13.7.1 Überwachung des BWAIndizierungsprozesses .................................... 13.7.2 Laufzeitanalyse im Query-Monitor (Transaktion RSRT) ........................................ 13.7.3 Test- und Prüfprogramme (RSRV-Checks) ...... 13.7.4 BWA-Datenkonsistenz-Checkcenter .............. 574 576 581 582 582 586 587 588 591 591 594 596 602 14 Performanceoptimierung von InfoProvidern ........... 605 14.1 14.2 14.3 14.4 14 Komprimierung von InfoCubes ................................... Partitionierung von InfoCubes .................................... 14.2.1 Partitionierung auf Datenbankebene – Range-Partitionierung ................................... 14.2.2 Partitionierung auf Datenbankebene – Clustering ...................................................... 14.2.3 Repartitionierung der Range-Partitionierung ... 14.2.4 Monitoring und Fehlerbehandlung der Repartitionierung .......................................... 14.2.5 Partitionierung auf Applikationsebene – Logische Partitionierung ................................ Performanceoptimierung von DataStore-Objekten ..... 14.3.1 Vermeidung der SID-Ermittlung .................... 14.3.2 Clustering auf der Tabelle für die aktiven Daten (A-Tabelle) .............................. 14.3.3 Indizierung .................................................... 14.3.4 Eindeutige Datensätze ................................... 14.3.5 Unterdrückung der Optimizer-Statistiken ...... 14.3.6 Einstellungen zu den Laufzeitparametern ....... Performanceoptimierung von PSA-Tabellen ............... 605 609 610 618 623 629 631 636 636 637 638 639 640 641 644 1182.book Seite 15 Mittwoch, 4. März 2009 6:38 18 Inhalt 15 Performanceoptimierung von Extraktions- und Ladeprozessen .......................................................... 647 15.1 15.2 15.3 15.4 15.5 15.6 15.7 15.8 Datenquellen und deren Anbindung ........................... Datenfluss in SAP NetWeaver BW .............................. Techniken zur Kommunikation zwischen SAP ERP und SAP NetWeaver BW ............................................ Übertragungstechniken ............................................... 15.4.1 Application Link Enabling (ALE) ..................... 15.4.2 Intermediate Document (IDoc) ...................... 15.4.3 Business Application Programming Interface (BAPI) ............................................. Persistent Staging Area (PSA) ...................................... Performanceoptimierung für Datenextraktions- und Staging-Prozesse ......................................................... 15.6.1 Einstellungen zur Datenpaketgröße ................ 15.6.2 Performanceoptimierung durch Parallelisierung in der Datenextraktion ........... 15.6.3 Performanceoptimierung durch Parallelisierung in der Datentransformation .... 15.6.4 Performanceoptimierung bei 3.x-DataSources ............................................. 15.6.5 Performanceaspekte bei der Fortschreibung von InfoCubes ................................................ Monitoring von Extraktions- und Datentransferprozessen .............................................. 15.7.1 Monitoring der Datenextraktion .................... 15.7.2 Monitoring der Datentransferprozesse (DTP) ............................................................. Fehlersuche, Simulation und Debugging von Datentransferprozessen .............................................. 15.8.1 Simulation von Datentransferprozessen .......... 15.8.2 Debugging von Datentransferprozessen ......... 648 652 657 659 659 660 660 660 663 667 673 676 678 682 688 689 698 700 701 704 16 BW-Performance-Review ......................................... 705 16.1 16.2 Untersuchungsbereich Softwareanalyse ....................... 16.1.1 SAP NetWeaver BW ....................................... 16.1.2 SAP-Frontend-Analyse ................................... 16.1.3 Checkliste für den Untersuchungsbereich Softwareanalyse ............................................. Untersuchungsbereich Performanceüberblick .............. 707 708 708 710 711 15 1182.book Seite 16 Mittwoch, 4. März 2009 6:38 18 Inhalt 16.2.1 16.2.2 16.2.3 16.2.4 16.2.5 16.3 16.4 Allgemeine Systemlast ................................... BW-Systemlast .............................................. Analyse ABAP-Laufzeitfehler (Dumps) ........... Analyse der Benutzeranzahl ........................... Checkliste für den Untersuchungsbereich Performanceüberblick .................................... Untersuchungsbereich Hardwareanalyse .................... 16.3.1 Hardwareprofil .............................................. 16.3.2 CPU-Auslastung ............................................ 16.3.3 Speicherauslastung ........................................ 16.3.4 Datenbankperformance ................................. 16.3.5 Datenbankwachstum ..................................... 16.3.6 Checkliste für den Untersuchungsbereich Hardware ...................................................... Untersuchungsbereich BW-Anwendungsanalyse ........ 16.4.1 Analyse Datenverteilung in BW-InfoProvidern und -Stammdaten ......................................... 16.4.2 Analyse InfoProvider-Verteilung .................... 16.4.3 Analyse InfoCube-Design und Dimensionentabellen .................................... 16.4.4 Analyse Line-Item-Dimensionen und hohe Kardinalität ................................................... 16.4.5 Analyse der Query-Definitionen .................... 16.4.6 Analyse der Einstellungen zu BW-Statistiken ... 16.4.7 Analyse der Query-Nutzung .......................... 16.4.8 Analyse Upload-Prozesse ............................... 16.4.9 Checkliste für den Untersuchungsbereich Anwendungsanalyse ...................................... 711 712 714 715 717 718 718 719 720 721 722 724 726 727 728 733 735 736 739 739 740 741 Anhang ........................................................................... 745 A 16 Anhang ................................................................................ A.2 Migrationsdetails der Statistikdaten von SAP BW 3.x nach SAP NetWeaver BW 7.0 – Mapping ................... A.3 Mapping-Details der InfoObjects ............................... A.4 DB-Views und transparente Tabellen der BW Runtime Statistics ................................................ A.4.1 DB-View RSDDSTAT_OLAP: Statistikdaten des Frontend- und Calculation-Layers ............ A.4.2 DB-View RSDDSTAT_DM: Statistikdaten des Aggregation-Layers ................................. 745 746 751 751 752 753 1182.book Seite 17 Mittwoch, 4. März 2009 6:38 18 Inhalt A.4.3 A.5 A.6 A.7 A.8 A.9 Tabelle RSDDSTATHEADER – Kopftabelle der BW-Statistiktabellen des Frontend-/ Calculation-Layers und Aggregation-Layers .... A.4.4 Tabelle RSDDSTATINFO – Statistikdaten der Navigationsschritte ........................................ A.4.5 Tabelle RSDDSTATDM – Statistikdaten des Data-Managers im Aggregation-Layer ............ A.4.6 Tabelle RSDDSTATEVDATA – Statistikdaten zu Zeit und Anzahl aller Events ...................... A.4.7 Tabelle RSDDSTATEVENTS – OLAP-StatistikEvents ............................................................ A.4.8 Tabelle RSDDSTATEVENTS – Übersicht der OLAP-Statistik-Events für BW Suite ................ A.4.9 Tabelle RSDDSTATEVENTS – Übersicht der OLAP-Statistik-Events für Analytical Engine ... A.4.10 Tabelle RSDDSTATEVENTS – Übersicht der OLAP-Statistik-Events für Data Warehousing ... A.4.11 Tabelle RSPCLOGCHAIN: Statistikdaten der Kreuztabelle Protokoll-ID eines Laufs einer Prozesskette zur Prozessketten-ID .................. A.4.12 Tabelle RSPCPROCESSLOG – Statistikprotokolle der Prozesskettenläufe ...... A.4.13 Tabelle RSDDSTATDTP – WHM-Statistiken der DTP-Prozesse ........................................... A.4.14 Tabelle RSBKREQUEST – Statistikdaten der DTP-Requests ................................................ A.4.15 Tabelle RSDDSTATWHM – Statistikdaten des Data-Warehouse-Managements ..................... A.4.16 Tabelle RSMDATASTATE_EXT – Summationsstatistiken des Datenstatus in BW .................. A.4.17 Tabelle RSDDSTATTREX – Statistikdaten für Prozesse für TREX-Aggregate ......................... A.4.18 Tabelle RSDDSTATTREXSERV – Detail-Statistik des TREX Servers .................... ABAP-Programme in SAP NetWeaver BW ................... Job-Präfixe in SAP NetWeaver BW ............................. Transaktionen in SAP NetWeaver BW ......................... BW-relevante Transaktionen im ERP-System ............... SAP ERP- und NetWeaver BW-Systemtabellen ........... A.9.1 Administration ............................................... A.9.2 Modellierung ................................................. 754 755 755 756 757 757 764 769 773 774 775 776 778 779 781 781 782 785 786 794 794 794 798 17 1182.book Seite 18 Mittwoch, 4. März 2009 6:38 18 Inhalt B A.10 Temporäre Tabellen in SAP NetWeaver BW ............... A.11 SAP-Hinweise ............................................................ A.11.1 Indizes .......................................................... A.11.2 DB-Einstellungen für SAP NetWeaver BW ..... A.11.3 Systemeinstellungen ...................................... A.11.4 Aggregate ...................................................... A.11.5 Sammelhinweise und FAQs ........................... A.11.6 DB Connect ................................................... Der Autor ............................................................................. 800 802 802 802 803 803 804 804 805 Index .......................................................................................... 807 18 1182.book Seite 331 Mittwoch, 4. März 2009 6:38 18 Eine Voraussetzung für performante Lese- und Ladeprozesse sind korrekte Datenbankstatistiken und Indizes. In diesem Kapitel finden Sie alle Informationen zu Grundlagen und Administration dieser 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 diese Mittel sind performante Lese- und Ladeprozesse bei Zugriff auf große Datenmengen nahezu unmöglich. Der Analyse und Administration von Indizes und Datenbankstatistiken kommt deshalb in der Performanceoptimierung von BW-Anwendungen eine besondere Bedeutung zu. DB-Statistiken und Indizes einer Datenbank sind vergleichbar mit einem Reise-Routenplan. Die Ausgangssituation ist folgende: Der anzufahrende Zielort ist bekannt – um den Zielort zu erreichen, können aber verschiedene Routen gewählt werden: kürzeste Route, aber eventuell nicht die schnellste; schnellste Route, aber wahrscheinlich mit einem weiteren Weg. Mit der Abfrage von Daten in einem relationalen Datenbanksystem ist es ähnlich. Die Abfragesprache SQL, auf der alle Queries auf relationalen Datenzielen in SAP NetWeaver BW beruhen, stellt die mittels einer Query angeforderten 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ünstigsten erfolgt, um die schnellste Antwortzeit (im übertragenen Sinne also die kürzeste Reisedauer) zu erreichen. Ein Großteil der Abfragezeit in einer Datenbank wird nicht für das Lesen der Daten benötigt, sondern für die Suche. Sind z.B. in einer Datenbanktabelle mit 100.000 Datensätzen nur 100 Datensätze (also nur ein Promille) relevant für die vorgegebene Selek- 331 1182.book Seite 332 Mittwoch, 4. März 2009 6:38 18 9 Indizes und DB-Statistiken tion, dann dauert die Suche nach den richtigen Datensätzen um ein Vielfaches länger als der eigentliche Lesevorgang. Wenn die Datenbank jedoch wüsste, wo die 100 gesuchten Datensätze liegen, würde der Lesevorgang um ein Vielfaches beschleunigt werden. Eine solche Suchhilfe sind Indizes. Sie sind ergänzende Datenstrukturen, mit deren Hilfe die Inhalte von Datenbanktabellen nach Ordnungskriterien katalogisiert werden. Das Datenbanksystem erkennt anhand eines Index, wo die nachgefragten Datensä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 Speicherverwaltung in Datenbanken erklärt werden, deren Verständnis nicht immer vorausgesetzt werden kann. Logische und physische Ebene Bei der relationalen Speicherverwaltung in Datenbanken sind zwei Ebenen zu unterscheiden: Die logische und die physische Ebene. Die logische Ebene umfasst Objekte, die üblicherweise mit SQL angesprochen werden können. Hierzu zählen z.B. Tabellen und Indizes. Diese Objekte werden in 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 RedoLog-Files, die nicht der Ablage von Daten dienen, sondern der Systemverwaltung. Die physischen Objekte bilden eine hierarchische Ordnung: Tablespaces Eine Datenbank besteht aus mehreren Tablespaces. Ein Tablespace ist ein vordefinierter Speicherort, in den Tabellen, Indizes und andere Datenobjekte geschrieben werden. Ein Tablespace enthält eine oder mehrere Datendateien. Eine Datendatei ist eine physikalische Struktur, in der Tabellen und Indizes abgelegt werden. Tabellen und Indizes sind in sogenann- 332 1182.book Seite 333 Mittwoch, 4. März 2009 6:38 18 Grundlagen der DB-Speicherverwaltung ten Segmenten der Datenbank eingeordnet.1 Dabei kann ein Segment (Objekt) auch in mehreren Datendateien enthalten sein. Segmente sind logisch einem Tablespace zugeordnet und werden physisch in Dateien gespeichert. Abbildung 9.1 zeigt den hierarchischen Aufbau. Tabelle Tabelle Tabelle Tabelle Objekte (Segmente) Index Index Index Index Index Index Index Index Index Datenbankdatei Tablespace Abbildung 9.1 Hierarchischer Aufbau Datenbankobjekte Eine Datendatei ist in mehrere Extents unterteilt. Ein Extent ist Teil eines Segments und besteht aus diskreten Datenbankblöcken fester Größe (z.B. 8 KB). Ein oder mehrere Extents bilden ein Segment (siehe Abbildung 9.2). 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 Extent: 160 KB Extent: 80 KB Segment: 240 KB 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, Temporary, Cache, Lobsegment, Lobindex. 333 Extents 9.1 1182.book Seite 334 Mittwoch, 4. März 2009 6:38 18 9 Indizes und DB-Statistiken 9.2 Datenbankoptimierer Grundlagen zu Indizes und Ausführungsplänen Um die günstigste Suchstrategie für eine Datenbankabfrage zu finden, verfügt das Datenbanksystem über den sogenannten Datenbankoptimierer. Der Datenbankoptimierer ist Bestandteil des Datenbankprogramms und entscheidet, über welche Zugriffsroute die Daten zusammengestellt werden. Die Zugriffsroute wird im Datenbanksystem als Ausführungsplan bezeichnet und wird vom Datenbankoptimierer erstellt. Um die Arbeitsweise des Optimierers zu verstehen, werden in den folgenden Ausführungen zunächst einige Grundlagen der Datenverwaltung und -organisation in relationalen Datenbanksystemen vermittelt. 9.2.1 Ein Einführungsbeispiel Ein stark vereinfachtes, aber praxisbezogenes Beispiel soll die Grundlagen der Datenorganisation in einem relationalen Datenbanksystem beschreiben. In einer Datenbank sei eine Tabelle mit Mitarbeiterinformationen der angelegt, deren Struktur in Abbildung 9.3 zu sehen ist. Name Name Becker Becker ... ... Schroeder Schroeder ... ... Kessler Kessler ... ... Ansorge Ansorge ... ... Schroeder Schroeder ... ... Vorname Vorname Harald Harald Abteilung Abteilung Controlling Controlling Standort Standort München München Straße Telefon-Nr. Straße Telefon-Nr. Maximilianstr. Maximilian Str. 089-2476986 089-2476986 Thomas Thomas Beratung Beratung Hamburg Hamburg Lübecker Lübecker Str. Str. 040-8790657 040-8790657 Anja Anja Controlling Controlling Hamburg Hamburg Lübecker Lübecker Str. Str. 040-8790637 040-8790637 Berthold Berthold Beratung Beratung Münster Münster Hammer Hammer Str. Str. 0251-456539 0251-456539 Elisabeth Elisabeth Facility Münster Facility Mngm. Mngm. Münster Hammer Hammer Str. Str. 0251-456566 0251-456566 Abbildung 9.3 Beispieltabelle »Mitarbeiter« Die Einträge der Tabelle sind unsortiert, da relationale Datenbanksysteme in der Regel die Daten nicht sortiert abspeichern: Neu hinzukommende Daten werden an das Ende der Liste oder an Stellen eingefügt, die gerade frei sind. Damit Daten in einer Datenbanktabelle auffindbar sind, werden alle Zeilen der Tabelle mit einer sogenannten Row-ID gekennzeichnet (in der Beispieltabelle in Abbildung 9.3 nicht dargestellt). Diese Row-ID identifiziert jeden Datensatz in einer Tabelle eindeutig und teilt der Datenbank den genauen Standort der Zeile mit. Wollte man nun in der Tabelle Mitarbeiter in Abbildung 9.3 einen bestimmten Mitarbeiter aus der Datenbank selektieren, müsste die Tabelle bei jeder Abfrage Satz für Satz sequentiell 334 1182.book Seite 335 Mittwoch, 4. März 2009 6:38 18 Grundlagen zu Indizes und Ausführungsplänen 9.2 gelesen werden. Dies wäre ein sehr unperformanter Lesezugriff, der je nach Größe der Tabelle zu langen Lesezeiten führen kann, da ein Großteil der erforderlichen Zeit für die Suche des Datensatzes erforderlich wäre. Damit dies nicht geschieht, existiert zu der unsortierten Tabelle ein Primärindex, über den die Suche effizient gestaltet werden kann. Ein Index ist eine Datenbankstruktur, die eine sortierte Werteliste mit Zeigern zu den Datensätzen enthält und der Datenbank zum schnellen Auffinden einer Zeile in einer Tabelle verhilft. Indizes unterstützen verschiedene Datenbankoperation. 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>) Primärindex In der Beispieltabelle Mitarbeiter wäre der Primärindex eine alphabetisch nach Namen und Vornamen sortierte Liste, bei der zu jedem Namen und Vornamen die genaue Position des Datensatzes in der Tabelle gespeichert ist. Damit die Daten in der Tabelle auffindbar sind, sind alle Zeilen mit einer Row-ID eindeutig gekennzeichnet. In diesem Beispiel sind Name und Vorname die Felder des Index, und die Positionsnummer ist die RowID. Primärindizes sind in ERP-Tabellen immer als Unique-Index angelegt. Das heißt, dass zu jeder Kombination der Indexfelder ein eindeutiger Tabelleneintrag existiert. Für das Beispiel der Tabelle Mitarbeiter soll diese Anforderung vernachlässigt werden, da natürlich in der Mitarbeiter-Tabelle mehrere Einträge mit gleichem Namen und Vornamen existieren könnten. Die Faktentabelle eines SAP NetWeaver BW-Standard-InfoCube verfügt über keinen Unique-Index, da ihre Dimensionenschlüssel-IDs als Fremdschlüssel der Dimensionentabellen über einen sogenannten PIndex indiziert sind, der non-unique ist (siehe auch Abschnitt 9.4). Unique-Index Wollte man in einer nächsten Abfrage alle Mitarbeiter des Standorts Hamburg selektieren, kann der Primärindex für eine schnelle Suche vom Datenbanksystem nicht verwendet werden, da das Feld Standort nicht im Index enthalten ist. Um dennoch die Tabelle nicht sequentiell Satz für Satz lesen zu müssen, kann die Suchabfrage durch einen sogenannten Sekundärindex unterstützt werden. Ein Sekundärindex enthält ein oder mehrere Tabellenfelder sowie einen Verweis auf die Row-ID bzw. den Primärschlüssel der Tabelle. In der Beispieltabelle Mitarbeiter wäre ein Sekun- Sekundärindex 335 1182.book Seite 336 Mittwoch, 4. März 2009 6:38 18 9 Indizes und DB-Statistiken därindex auf dem Feld »Standort« geeignet, die Suchabfrage nach allen Mitarbeitern am Standort Hamburg zu unterstützen. Sekundärindizes sind in der Regel nicht unique, das heißt, zu einem Indexeintrag können mehrere Tabelleneinträge existieren. Ausführungsplan In dem Beispiel der Tabelle Mitarbeiter sollen in einer nächsten Abfrage alle Mitarbeiter mit Namen »Schröder« am Standort »Hamburg« selektiert werden. Die Datenbank könnte diese Abfragen mit verschiedenen Suchstrategien 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 Datenbankoptimierer. Der gewählte Zugriffspfad wird als Ausführungsplan bezeichnet. Der Ausführungsplan (auch Execution Plan genannt) einer Query kann im BWSystem im Query-Monitor (Transaktion RSRT) über die Funktion Ausführen + Debuggen 폷 Zeige Ausführungsplan eingesehen werden (siehe Abbildung 9.4). Abbildung 9.4 Aufruf des Ausführungsplans einer Query im Query-Monitor 336 1182.book Seite 337 Mittwoch, 4. März 2009 6:38 18 Grundlagen zu Indizes und Ausführungsplänen 9.2 Um einen Ausführungsplan lesen zu können, sollen zunächst verschiedene Zugriffsoptionen näher erläutert werden, die Sie in einem Ausführungsplan finden können. Der in Abbildung 9.4 dargestellte Ausführungsplan beruht auf dem Datenbanksystem Oracle, die hier genannten Begriffe der Datenbankoperationen können in anderen Datenbanksystemen verschieden sein. Bei der Analyse des Ausführungsplans soll unterschieden werden zwischen Tabellenzugriffsalgorithmen, also Methoden für den Zugriff auf Tabellen und Indizes für das Lesen von Daten, und Join-Algorithmen, also Methoden für die Verknüpfung von Daten in Tabellen. Die hier verwendeten Begriffe sind zum besseren Verständnis allgemein gehalten, in Ihrem SAP NetWeaver BW-System können die Begriffe je nach der zugrundeliegenden Datenbank hiervon abweichen. 9.2.2 Tabellen-/Indexzugriffsalgorithmen Tabellenzugriffsalgorithmen beschreiben Leseprozesse der Datenbank zum Auffinden der gesuchten Daten in den Datenbanktabellen. Die häufigsten Zugriffsoperationen sind hierbei in der allgemeinen Form der Table Scan und der Index Scan. Wie die Bezeichnungen schon vermuten lassen, unterscheiden sich diese beiden Formen des Datenzugriffs bezüglich des Datenobjektes, aus dem zuerst die Daten gelesen werden: einem Index oder einer Tabelle. Diese beiden Grundformen des Datenzugriffs werden in den folgenden Ausführungen näher spezifiziert. Eine besondere Form des Table Scans ist der Full Table Scan. Beim Full Table Scan muss die gesamte Datenbanktabelle sequentiell durchsucht werden. Der Full Table Scan wird deshalb auch als sequentieller Table Scan bezeichnet. Diese Form des Tabellenzugriffs muss vom Datenbanksystem immer dann ausgeführt werden, wenn für die Suche kein Index verwendet werden kann, weil die gewählten Suchfelder nicht in einem Index enthalten sind. In der Tabelle Mitarbeiter könnte eine SQL-Abfrage wie folgt aussehen: SELECT * FROM TABLE Mitarbeiter WHERE Abteilung = 'Controlling'. Für das Feld Abteilung existiert in der Tabelle Mitarbeiter kein Index, die Suche kann also nicht durch einen Index unterstützt werden, und die Tabelle muss Satz für Satz gelesen werden. Ein Full Table Scan ist für große Tabellen aufgrund der langen Suchzeiten sehr ungünstig. Für kleine Tabel- 337 Full Table Scan 1182.book Seite 338 Mittwoch, 4. März 2009 6:38 18 9 Indizes und DB-Statistiken 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 der Datenbankoptimierer. ROW-ID Scan Der ROW-ID Scan liest die Tabellenzeiger einer Tabelle. Die ROW-ID enthält die Datendatei, den Block und die Stelle im Block, an der die gesuchte Datenzeile zu finden ist. Die ROWID-Funktion gibt den Zeilenbezeichner in einer Tabelle zurück, der der angegebenen Datenkorrelation entspricht. Dieser Algorithmus wird benutzt, um Zeilen in einer Tabelle anhand eines Vergleichsausdrucks mit Hilfe der Funktion ROWID effizient zu suchen. Index Unique Scan 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 Suchverfahren zum Auffinden von wenigen Daten in großen Tabellen. Ein Index Unique Scan wird immer dann ausgeführt, wenn alle Felder des Primärindex in der WHERE-Klausel der SQL-Anweisung mit einer Gleichbedingung spezifiziert sind. Ein Beispiel für die Tabelle Mitarbeiter könnte wie folgt aussehen: SELECT * FROM TABLE Mitarbeiter WHERE Name = 'Schroeder' AND Vorname = 'Thomas' . Da der Primärindex immer ein Unique-Index ist, liefert der Index Unique Scan höchstens einen Datensatz zurück. Index Range Scan Bei einem Index Range Scan existiert zwar für die Suche ein Index, die Einschrä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 spezifiziert die WHERE-Klausel keinen eindeutigen Datensatz im Primärindex, sondern alle Datensätze mit dem Namen »Schroeder« (genauer gesagt, alle Row-IDs der Datensätze mit dem Namen »Schroeder«). Da dieser Indexbereich Satz fü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ührt werden, wenn nicht alle Felder des Index (hier Name und Vorname) in der WHERE-Bedingung mit = spezifiziert sind. Der Datenbankoptimierer muss 338 1182.book Seite 339 Mittwoch, 4. März 2009 6:38 18 Grundlagen zu Indizes und Ausführungsplänen 9.2 dann einen Indexbereich durchsuchen, um die Datensätze der Tabelle zu ermitteln. Ein bei der Suche von Daten in Tabellen einer Datenbank benutzter Algorithmus ist die binäre Suche (binary search). Die binäre Suche funktioniert ähnlich wie das Raten von Zahlen: In einer sortierten Werteliste wird der gesuchte Wert zunächst in der Mitte der Liste gesucht. Stimmt der zunächst gefundene Wert mit dem gesuchten Wert nicht überein, wird je nachdem, ob der gesuchte Wert größer oder kleiner als der gefundene Wert ist, vor oder hinter dem gefundenen Element in der gleichen Weise weitergesucht. Die Suche wird beendet, wenn das gesuchte Element gefunden wurde oder wenn es keinen restlichen Bereich mehr gibt, in dem gesucht werden könnte. 1 2 3 4 7 12 14 35 37 41 68 72 2 4 78 96 3 105 113 Abbildung 9.5 Binäre Suche Der Suchalgorithmus binäre Suche ist in Abbildung 9.5 illustriert. Gesucht wird die Zahl 96. Der Suchalgorithmus beginnt zunächst in der Mitte der Liste 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 rechten Teils der Liste fortgeführt; es wird der Wert 78 gefunden �. Der gesuchte Wert ist größer als der gefundene, die Suche wird deshalb weiter fortgesetzt in der Mitte des verbleibenden rechten Teils der Liste; es wird der Wert 105 gefunden �. Der gesuchte Wert ist kleiner als der gefundene, die Suche wird deshalb im linken Bereich fortgesetzt; es wird der Wert 96 gefunden �. Der gesuchte Wert ist gefunden, die Suche wird beendet. Das Beispiel in Abbildung 9.5 zeigt, dass die binäre Suche ein sehr effizienter Suchalgorithmus ist, da nur vier Lesezugriffe benötigt werden, um den gesuchten Wert zu finden. Würde die sortierte Liste Element für Element der Reihe nach durchsucht, wären 13 Lesezugriffe nötig. 9.2.3 Join-Algorithmen Der Join-Algorithmus verknüpft Datenzeilen von Datenobjekten entsprechend einem Vergleichsoperator und bildet darüber eine Ergebnismenge. In dem Datenbanksystem, das SAP NetWeaver BW unterliegt, sind ver- 339 Binäre Suche 1182.book Seite 340 Mittwoch, 4. März 2009 6:38 18 9 Indizes und DB-Statistiken schiedene Join-Algorithmen implementiert, die verschiedene Eigenschaften haben und durch den Datenbankoptimierer der jeweiligen Abfrage entsprechend ausgewählt werden. Die drei häufigsten Typen der JoinOperation sind Nested-Loop Join, Merge Join und Hash Join. Nested-Loop Join Der Nested-Loop Join ist der einfachste Join-Algorithmus. Er durchsucht für jeden Datensatz der ersten Ergebnismenge die gesamte zweite Ergebnismenge nach Übereinstimmungen aufgrund der Join-Bedingung. In der Regel wird über einen Index auf die Datensätze der ersten Ergebnismenge zugegriffen, um schnellere Suchzeiten zu bewirken. Für den Nested-Loop Join existieren weitere Varianten, wie z.B. der Left Outer oder der Full Outer Join. Full Outer Joins sind in der Regel sehr teuer und zeitintensiv in der Ausführung, weshalb der Datenbankoptimierer diese Join-Operationen nur in wenigen Fällen auswählen wird, wenn keine andere JoinOperation das Ergebnis kostengünstiger bereitstellen kann. Merge Join Ein Merge Join verknüpft gleich geordnete Ergebnismengen. Die JoinBedingung muss mindestens ein Gleichheitsprädikat enthalten, sonst kann der Optimierer diese Join-Operation nicht auswählen. Der Merge Join ist sehr effizient bei etwa gleich großen, bereits vorsortierten Ergebnismengen. Auch für den Merge Join gibt es Varianten, die den Left Outer Join oder den Full Outer Join unterstützen. Aufgrund der Sortierung der Ergebnismengen ist der Merge Join meist erheblich effizienter als der Nested-Loop Join. Hash Join Der Hash Join ist die vielseitigste Join-Methode. Der Hash-Join-Algorithmus liest die kleinere Ergebnismenge in den Speicher 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. Dann durchsucht der Hash-Algorithmus die größere Ergebnismenge und prüft die speicherresidente Hash-Tabelle auf Übereinstimmungen. Reicht der Speicher für die Hash-Tabelle nicht aus, werden die Ergebnismengen in Partitionen aufgeteilt, wobei die Join-Operation für jede Partition einzeln ausgeführt wird. Zudem kann der Hash-Join-Algorithmus zu einer indexbasierten Join-Strategie wechseln, wenn nicht genügend Cache-Speicher vorhanden ist, um alle Zeilen der Ergebnismenge aufzunehmen. Eine Übersicht mit weiteren Operationstypen finden Sie auch in Tabelle 9.3 in Abschnitt 9.5 bei der Erklärung des Star-Join-Ausführungsplans. 340 1182.book Seite 341 Mittwoch, 4. März 2009 6:38 18 Strukturtypen von Indizes 9.3 Strukturtypen von Indizes Im BW-System werden zwei Typen von Indizes unterschieden: Der Tabellen-Index und der Bitmap-Index. Der Tabellen-Index speichert die indizierten Wertefelder einer Tabellenzeile zusammen mit dem physischen Standort der Zeile (Row-ID). Dabei kann der Index auf eine oder mehrere Spalten angelegt sein. Die Indexeinträge werden in der sogenannten B-Tree-Struktur gespeichert. Der B-Tree ist eine Indexstruktur, die sich von binären Bäumen (Binary Tree) ableiten lässt und kurze Zugriffspfade auf die Schlüsselwerte unter minimalen I/OOperationen sicherstellt. Im Binary Tree enthält jeder Knoten einen Werteintrag, dem genau zwei Knoten zugeordnet sind (deswegen auch »binär«, »zwei«), wobei der linke Zeiger immer auf einen Knoten mit kleinerem Wert zeigt, der rechte Zeiger auf einen Knoten mit größerem Wert (siehe Abbildung 9.6). Binary Tree 37 7 78 3 2 14 4 12 68 35 41 105 72 96 113 Abbildung 9.6 Binary Tree Die Anzahl der Einträge pro Knoten wird als Ordnung bezeichnet. Ein Binary Tree hat deshalb immer die Ordnung 2. Die Anzahl der Zugriffsoperationen, die benötigt wird, um den gesuchten Wert zu finden, wird als Tiefe des Binary Trees bezeichnet. Die B-Tree-Struktur ist eine generalisierte Form des Binary Trees, da sie mehr als einen Werteintrag pro Knoten und damit auch mehr als zwei Zeiger pro Knoten enthalten darf. Ein Knoten in einem B-Tree der Ordnung d kann bis zu 2d Werteinträge und 2d+1 Zeiger enthalten, wobei wenigstens d Elemente im Knoten enthalten sein müssen, damit jeder Knoten zu 50% belegt ist. Abbildung 9.7 zeigt einen B-Tree-Index der Ordnung 2 mit vier Werten pro Knoten und fünf Zeigern. 341 B-Tree 9.3 1182.book Seite 342 Mittwoch, 4. März 2009 6:38 18 9 Indizes und DB-Statistiken Block X 1 2 3 4 Zeiger zum Datensatz Zeiger zum nächsten Block Block 4 Block 1 2 3 4 12 113 7 Block 3 Block 2 68 14 35 37 72 78 96 105 41 Abbildung 9.7 B-Tree-Index In einer B-Tree-Struktur haben alle Pfade vom Wurzelknoten bis zu den Blättern die gleiche Länge, was auch als balancierte Struktur bezeichnet wird. Die Werteinträge in den Knoten sind sortiert; jeder Knoten hat zwischen n und maximal 2n Einträge, der Wurzelknoten kann zwischen 1 und 2n Einträge haben. Die Suche von Werten im B-Tree-Index funktioniert nach dem in Abbildung 9.5 beschriebenen Algorithmus der binären Suche. Die Suchkosten in einem B-Tree-Index sind günstiger als in einem Binary Tree, da der B-Tree vollständig balanciert ist und mehr als zwei Werteinträge je Knoten aufnehmen kann, so dass weniger Knoten durchsucht werden müssen. Einfügen neuer Werte Das Einfügen bzw. Löschen von Elementen im B-Tree-Index muss wieder einen balancierten Baum hinterlassen. Wird ein neues Element hinzugefü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 Block gesucht und der Wert in den Block geschrieben. Ist der Block schon voll, wird der Inhalt in zwei neue Blöcke aufgeteilt (gesplittet), wobei die kleineren Einträge mit dem neuen Wert in den linken Block, der nächsthöhere Wert als Knoten in den übergeordneten Block und die restlichen Werte in den rechten Block geschrieben werden. Wenn der übergeordnete VaterBlock auch schon voll ist, muss der Block erneut gesplittet werden. Erst wenn der Splitting-Prozess bis zum Wurzelknoten fortgesetzt werden muss, erhöht sich die Tiefe des Baums. 342 1182.book Seite 343 Mittwoch, 4. März 2009 6:38 18 Strukturtypen von Indizes 9.3 Die Funktionsweise des Einfügens neuer Werte zeigt Abbildung 9.8. In Block 2 soll der Wert 15 neu hinzugefügt werden. Da Block 2 zuvor vollständig gefüllt war (siehe Abbildung 9.7), muss der Block gesplittet werden, wobei die Elemente bis zum neuen Wert in Block 2 verbleiben (Elemente 14 und 15), der nächsthöhere Wert 35 in den übergeordneten Block-4-Knoten eingefügt wird und die restlichen Elemente 37 und 41 aus Block 2 dem neuen Block 5 zugeordnet werden. Änderung Block 4 12 35 68 113 Block 3 72 78 96 Block 4 Block 1 2 3 4 7 105 Neu eingefügter Wert Block 2 14 15 Block 2 37 41 Split Block 2 Block X 1 2 3 4 Zeiger zum Datensatz Zeiger zum nächsten Block Abbildung 9.8 B-Tree-Index – Einfügen neuer Werte Eine spezielle Form des B-Tree-Index ist der B*-Tree-Index, der in den meisten kommerziellen relationalen Datenbanksystemen verwendet wird. Der B*-Tree-Index hat die Eigenschaft, dass alle Knoten zu zwei Dritteln gefüllt sein müssen. Es werden dadurch aufgrund der geringeren Baumtiefe eine höhere Speicherauslastung und eine schnellere Suche gegenüber dem Standard-B-Tree-Index erreicht. Allerdings sind die Kosten für die Reorganisation der Daten (Löschen und Einfügen) aufgrund des Füllgrades von 66% teurer als beim Standard-B-Tree-Index. 343 B*-Tree-Index 1182.book Seite 344 Mittwoch, 4. März 2009 6:38 18 9 Indizes und DB-Statistiken Ein normaler B*-Tree-Index ist ein aus Blöcken aufgebauter Baum mit ein bis fünf Ebenen. Die oberste Ebene besteht aus einem einzigen Block, der als Root-Block bezeichnet wird und der Ausgangspunkt für jeden Indexzugriff ist. Die unterste Ebene besteht aus einer potentiell sehr großen Anzahl von Blöcken, die Leaf-Blöcke genannt werden und von links nach rechts die eigentlichen Daten (Werte der indizierten Spalten und Row-ID für den Zugriff auf den zugehörigen Tabelleneintrag) in sortierter Reihenfolge enthalten. Diese Einträge werden als Leaf-Rows bezeichnet. Zu den Leaf-Rows werden auch frühere Einträge des Index gezählt, die nicht physikalisch aus dem Index entfernt, sondern nur mit einem Flag als gelöscht markiert werden. Diese spezielle Art von Leaf-Rows wird Deleted LeafRows genannt. Zwischen Root- und Leaf-Blöcken kann es in Abhängigkeit von der Indexgröße noch weitere Indexebenen mit sogenannten Branch-Blöcken geben, die Steuerdaten zum schnellen Auffinden der relevanten Daten im Index enthalten. Besteht ein Index aus nur einer Ebene, ist der Root-Block gleichzeitig ein Leaf-Block und enthält die eigentlichen Daten. Besteht ein Index aus 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 Kardinalität, also wenigen möglichen Ausprägungen, wie z.B. das Merkmal Geschlecht, das zwei Ausprägungen (m/w) annehmen kann. Solche Werteausprägungen sind nicht sehr selektiv; Bitmap-Indizes beschleunigen deshalb Suchvorgänge, bei denen nicht-selektive Spalten zur Reduzierung von Zeilen aus der Menge der zurückgegebenen Zeilen verwendet werden. Für Data-Warehouse-Applikationen wird der Bitmap-Index häufig verwendet, um vor allem komplexe und unselektive Abfragen beschleunigen 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 Ausprägung besitzt; sonst erhält das Bitmap-Feld den Wert »0«. Wenn ein Bitmap-Index viele Einsen enthält, spricht man von einer dichten Belegung des Bitmap-Index. Beim Attribut Geschlecht wäre der Belegungsgrad 50%. Das Beispiel einer Tabelle mit Feiertagen – dargestellt in Abbildung 9.9 – enthält zwei Bitmap-Indizes: einen Bitmap-Index über das Attribut Gesetzlicher Feiertag (ja/nein) und einen Bitmap-Index über den Monat (Monat 1 bis 12). 344 1182.book Seite 345 Mittwoch, 4. März 2009 6:38 18 Strukturtypen von Indizes ## Feiertag F Feiertag e ie rta g 11 Neujahr Neujahr 22 Heilige Dre r i Könige Könige Heilige Drei Drei 33 Valentinstag Valentinstag 44 Rosenmontag Rosenmontag 55 Fastnacht Fastnacht 66 Aschermittwoch Aschermittwoch 77 Karfreitag Karf rfreitag Karfreitag 88 Ostern Ostern 99 Ostermontag Ostermontag 10 10 Maifeiertag Maife f iert r ag Maifeiertag 11 11 Muttertag Muttert r ag Muttertag 12 Christi Himmelfahrt 12 Christi Himmelfa f hrt r Himmelfahrt 13 13 Pfingstsonntag Pfi f ngstsonntag Pfingstsonntag 14 14 Pfingstmontag Pfi f ngstmontag Pfingstmontag 15 15 Fronleichnam Fro r nleichnam Fronleichnam 16 16 Friedensfest Friedensfe f st Friedensfest 17 17 Mariä Mariä Himmelfahrt Himmelfa f hrt r Himmelfahrt 18 Erntedankfest 18 Erntedankfest Erntedankfe f st 19 19 Tag T g der Ta Tag der Deutschen Deutschen Einheit Einheit 20 2 0 Halloween Halloween 20 21 2 1 Reformationstag Refo f rmationstag 21 Reformationstag 22 2 2 Allerheiligen Allerheiligen 22 23 2 3 Volkstrauertag Volkstra r uert r ag 23 Volkstrauertag 24 2 4 BußBuß- und und Bettag Bettag 24 25 2 5 Totensonntag T To tensonntag 25 Totensonntag 26 2 6 1. 1. Advent Adve v nt 26 Advent 27 2 7 Barbara Barbara r 27 28 2 8 Nikolaus Nikolaus 28 29 2. Advent 2 9 2. Advent Adve v nt 29 30 30 3. 3. Advent Adve v nt Advent 31 31 4. 4. Advent Adve v nt Advent 32 32 Heiligabend Heiligabend 33 33 1. 1. Weihnachtstag Weihnachtstag 34 34 2. 2. Weihnachtstag Weihnachtstag 35 Silvester 3 5 Silve v ster 35 Silvester Gesetzlicher Gesetzlicher Ge se tz liche r Bitmap-Index B itm a p-IInde x Monat Monat M ona t Bitmap-Index Feiertag jj nn Feiert r ag g (j/n)? ((j/n)? j/n))? Feiertag jj 11 00 Januar JJanuar anuar jj 11 00 Januar Januar nn 00 11 Februar Februar nn 00 11 Februar Februar nn 00 11 Februar Februar nn 00 11 März März r jj 11 00 April April nn 00 11 April April jj 11 00 April April jj 11 00 Mai Mai nn 00 11 Mai Mai jj 11 00 Mai Mai jj 11 00 Juni Juni jj 11 00 Juni Juni jj 11 00 Juni Juni jj 11 00 August August jj 11 00 August August nn 00 11 Oktober Oktober jj 11 00 Oktober Oktober nn 00 11 Oktober Oktober jj 11 00 Oktober Oktober jj 11 00 November Nove v mber November nn 00 11 November Nove v mber November jj 11 00 November Nove v mber November nn 00 11 November Nove v mber November nn 00 11 Dezember Dezember nn 00 11 Dezember Dezember nn 00 11 Dezember Dezember nn 00 11 Dezember Dezember nn 00 11 Dezember Dezember nn 00 11 Dezember Dezember nn 00 11 Dezember Dezember jj 11 00 Dezember Dezember jj 11 00 Dezember Dezember nn 00 11 Dezember Dezember 11 11 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 22 00 00 11 11 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 33 00 00 00 00 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Bitmap-Index B itm a p-IInde x Bitmap-Index 44 55 66 77 88 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 11 00 00 00 00 11 00 00 00 00 11 00 00 00 00 00 11 00 00 00 00 11 00 00 00 00 11 00 00 00 00 00 11 00 00 00 00 11 00 00 00 00 11 00 00 00 00 00 00 11 00 00 00 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 99 10 10 11 11 12 12 2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 11 00 00 00 11 00 00 00 11 00 00 00 11 00 00 00 00 11 00 00 00 11 00 00 00 11 00 00 00 11 00 00 00 00 11 00 00 00 11 00 00 00 11 00 00 00 11 00 00 00 11 00 00 00 11 00 00 00 11 00 00 00 11 00 00 00 11 00 00 00 11 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-Index auf Feldern mit wenigen Merkmalsausprägungen sehr vorteilhaft ist: SELECT * FROM TABLE WHERE 'Gesetzl. Feiertag' = 'J' AND 'Monat' = 'Oktober' Bitmap-Indizes ermöglichen eine schnelle Leseperformance bei geringem Speicherbedarf (ca. 5 bis 10% des Speicherbedarfs von normalen Indizes, da die binäre Struktur sehr gut vom Datenbanksystem komprimiert werden kann), haben aber hohe Performancekosten bei der Aktualisierung. Bitmap-Indizes sollten nur auf Spalten mit geringer Kardinalität (nichtselektive Spalten) eingesetzt werden, die in WHERE-Bedingungen verwendet werden. Tabelle 9.1 zeigt die Unterschiede zwischen B-Tree-Index und BitmapIndex im Vergleich: 345 9.3 1182.book Seite 346 Mittwoch, 4. März 2009 6:38 18 9 Indizes und DB-Statistiken 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 mehrere Indizes pro Tabelle Tabelle Platzbedarf Platzbedarf unabhängig von Anzahl unterschiedlicher Werte Reorganisation durch effiziente Algorithmen aufwendig bei INSERT und geringere Kosten DELETE Zugriffsart Single-Record-Zugriffe, Schnittmengenbildung teuer Platzbedarf abhängig von Kardinalität des Attributs, gewöhnlich aber geringer als bei B-Tree Multiple-Record-Zugriffe, schnelle AND/OR-Verknüpfungen Tabelle 9.1 Vergleich von B-Tree-Index und Bitmap-Index Cluster-Index Ein weiterer Index in SAP NetWeaver BW ist der Cluster-Index, der aber nur für DB2 UDB-Datenbanksysteme (Unix, Windows und Linux) zum Einsatz kommt. Dieses Datenbanksystem kann Zeilen auf physischen Datenseiten in der Reihenfolge eines Index sortieren. Der Cluster-Index ist ein zusammengesetzter Index auf den Dimensionenschlüsselspalten der Faktentabelle und wird automatisch angelegt. Die Reihenfolge wird dabei bestimmt durch das InfoCube-Design und durch die Reihenfolge der InfoCube-Dimensionen. Durch das Clustering können die Datensätze in der Faktentabelle gemäß der Sortierfolge des Index abgelegt werden. Datensätze mit denselben Dimensionenschlüsseln können dadurch in gleichen Extents der Datenbank abgelegt werden. Die Anzahl der zu lesenden Extents kann dadurch massiv verringert werden, da die Datensätze nicht über viele Extents verteilt sind. Ist ein relevanter Extent bereits voll, wird der Datensatz in einen leeren Extent am Ende am Ende der Tabelle eingefügt. Durch ständige Einfüge- und Löschvorgänge degeneriert der Cluster-Index zunehmend, wodurch die Sortierreihenfolge nicht immer gewährleistet ist. Der Pflegeaufwand des Index ist dementsprechend größer als beim B-Tree- oder Bitmap-Index, da aber weniger physische Blöcke gelesen werden müssen, ist der Datenbank-I/O meist günstiger. 346 1182.book Seite 347 Mittwoch, 4. März 2009 6:38 18 Indizierungsschema in SAP NetWeaver BW 9.4 9.4 Indizierungsschema in SAP NetWeaver BW In diesem Abschnitt werden das Indizierungsschema in SAP NetWeaver BW und die im System verwendeten Indextypen für folgende Datenprovider erläutert: 왘 Standard-InfoCubes 왘 Transaktionale InfoCubes 왘 Partitionierte InfoCubes 왘 DataStore-Objekte 왘 InfoObjects Desweiteren lernen Sie die Analyse- und Optimierungsmöglichkeiten mit Indizes kennen. 9.4.1 Indizierung bei Standard-InfoCubes In SAP NetWeaver BW werden die Tabellen der Fakten und Dimensionen eines InfoCubes bei der Modellierung automatisch indiziert und brauchen gewöhnlich nicht selbst angelegt oder erweitert zu werden. Nur in Ausnahmefällen, z.B. bei besonders großen Datenvolumina, ist es ratsam, weitere Indizes anzulegen, um die Performance für Ladeprozesse und Lesezugriffe zu verbessern. Das Indizierungsschema der Datenbanktabellen eines InfoCubes soll an dem folgenden Beispiel des InfoCubes Materialverbräuche Ist (ZMVIST) erläutert werden. InfoCubes in BW sind nach dem sogenannten Star-Schema aufgebaut. Das Star-Schema hat seinen Namen aufgrund der sternförmigen Anordnung der Dimensionentabellen um die Faktentabelle des InfoCubes. Die Dimensionentabellen repräsentieren dabei die eigentlichen Auswertungssichten der Merkmale wie z.B. Kunde, Artikel, Tag usw.; die Stammdatentabellen enthalten die Merkmalsausprägungen wie z.B. Preis oder Farbe eines Produkts, während die Faktentabelle die metrischen Kennzahlen wie Umsatz, Absatz, Erlös usw. enthält. Alle Datenbanktabellen eines InfoCubes können über die Transaktion LISTSCHEMA aufgerufen werden (siehe Abbildung 9.10). 347 Star-Schema 1182.book Seite 348 Mittwoch, 4. März 2009 6:38 18 9 Indizes und DB-Statistiken Abbildung 9.10 Demo-InfoCube ZMVIST (I) In dem folgenden Beispiel soll die Verknüpfung der Faktentabelle des InfoCubes ZMVIST mit der Dimensionentabelle Material und den Stammdatentabellen 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 Fremdschlüssel zu den in Abbildung 9.10 aufgelisteten Dimensionentabellen. In dem Beispiel wird die Schlüsselbeziehung der Faktentabelle zur Dimensionentabelle Material (/BIC/DZMVIST2) und dem Stammdatenmerkmal Material (/BI0/XMATERIAL) sowie dem Attribut Materialgruppe (/BI0/SMATL_GROUP) betrachtet. Die Faktentabelle enthält je InfoCube-Dimension eine Spalte mit Fremdschlü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 je Merkmal in der Dimension. In diese Spalten werden die SID-Schlüssel der korrespondierenden Merkmale geschrieben. In Abbildung 9.11 enthält die Dimensionentabelle Material (/BIC/DZMVIST2) den Primärschlüssel der Tabelle (DIMID) sowie einen SID-Schlüssel zu den korrespondierenden Tabellen des Merkmals Material. 348 1182.book Seite 349 Mittwoch, 4. März 2009 6:38 18 Indizierungsschema in SAP NetWeaver BW Faktentabelle Attribut „Materialgruppe“ Dimensionentabelle „Material“ SID-Tabelle „Material“ (Nav-Attribute) Abbildung 9.11 Demo-InfoCube ZMVIST (II) Die korrespondierenden Tabellen zum SID-Schlüssel können verschiedene Tabellen sein: Die Standard-S-Tabelle /BI0/SMATERIAL, in der die Beziehung zwischen SID-Schlüsseln der Dimension und dem Merkmal gespeichert ist, die X-Tabelle /BI0/XMATERIAL, in der die Beziehung zwischen SID-Schlüsseln der Dimension und den SID-Schlüsseln der zeitunabhängigen Navigationsattribute gespeichert ist, oder die Y-Tabelle, in der die Beziehung zwischen SID-Schlüsseln der Dimension und den SIDSchlüsseln der zeitabhängigen Navigationsattribute gespeichert ist. Die SID-Schlüssel in den obigen Tabellen verzweigen dann auf die Standard-S-Tabelle der Navigationsattribute, z.B. auf das Navigationsattribut Materialgruppe (/BI0/SMATL_GROUP). Indizierung der Faktentabelle in Standard-InfoCubes Seit den BW-Releases BW 2.x und BW 3.x werden zwei Faktentabellen je InfoCube verwendet. Die F-Faktentabelle enthält die unkomprimierten Daten-Requests (Request-Package-IDs > 0), die E-Faktentabelle enthält die komprimierten Daten-Requests (Request-Package-IDs = 0). Wird ein InfoCube komprimiert, werden die Datensätze über die Request-ID verdichtet, aus der F-Faktentabelle gelöscht und in die E-Faktentabelle kopiert. 349 9.4 1182.book Seite 350 Mittwoch, 4. März 2009 6:38 18 9 Indizes und DB-Statistiken Indexschema Oracle Das Indexschema ist für beide Tabellentypen nahezu identisch. In der Regel werden in Oracle-Datenbanken alle Spalten mit einem Fremdschlüssel für die Dimensionentabelle (Präfix KEY_) mit einem Bitmap-Index indiziert. Eine Ausnahme bilden hier Dimensionen mit Merkmalen, für die das Flag Hohe Kardinalität eingeschaltet ist, also Dimensionentabellen, die über sehr viele Datensätze verfügen. Für solche Merkmale werden in OracleDatenbanksystemen die Fremdschlüssel mit B*-Tree-Index indiziert, da der Bitmap-Index für Merkmale mit vielen Ausprägungen schlechter geeignet ist. Die Auswahl des Indextyps (Bitmap oder B*-Tree) wird beim Anlegen des InfoCubes in der Pflege der Dimensionen bestimmt (siehe Abbildung 9.12). 09_12.emf Abbildung 9.12 Einstellung »Hohe Kardinalität« bei Pflege der Dimensionen Die so vom BW-System erzeugten Sekundärindizes haben als Präfix Namen der Form /BIC/F<InfoCube>~010, ~020 etc. Die Indizes auf den Dimensionenschlüsseln der Faktentabelle unterstützen die Lesezugriffe durch Queries. Weder die E- noch die F-Faktentabelle verfügt über einen eindeutigen Index, der über den Primärschlüssel der Tabelle definiert ist. Neben den Sekundärindizes existiert ein zusammengesetzter Index über alle Spalten der DIMIDs, der sogenannte P-Index (Präfix /BIC/F<InfoCube>~P). Der 350 1182.book Seite 351 Mittwoch, 4. März 2009 6:38 18 Indizierungsschema in SAP NetWeaver BW 9.4 P-Index existiert in Oracle-Datenbanksystemen nur auf der E-Faktentabelle und beschleunigt den Komprimierungsprozess. Dabei wird die E-Faktentabelle auf vorhandene Kombinationen von Dimensionen-IDs überprüft, um zu bestimmen, ob der aus der F-Faktentabelle zu verarbeitende Datensatz eingefügt (wenn die Kombination der Dimensionen-IDs noch nicht in der E-Faktentabelle vorhanden sind) oder fortgeschrieben werden soll. Ohne P-Index ist die Komprimierungsperformance erheblich beeinträchtigt. In DB2/400-basierten SAP NetWeaver BW-Systemen existieren für jede Spalte des Dimensionen-Fremdschlüssels zwei Sekundärindizes: ein sogenannter Radix-Index, der einem binären Baum entspricht. Bei Zugriffen auf die Faktentabelle wird hauptsächlich dieser Index benutzt. Diese Sekundä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 BitmapIndex; er ist durch seine kompakte Größe schnell aufzubauen und effizient in den Lesezugriffen. Er wird benötigt für dynamische Bitmap-Indizierung, wie sie z.B. beim Star-Join vorkommt. Damit der Datenbankoptimierer den EVI nutzen kann, benötigt er zusätzliche Informationen, sogenannte Optimizer-Hints, um einen besseren Zugriffsplan zu ermitteln. Der Datenbankoptimierer für DB2/400 muss hierfür über die sogenannten Query Options Files (QAQQINI) auf den EVI-Index eingerichtet werden, um ein bestimmtes Verhalten des Optimierers zu erzwingen. Nähere Hinweise für die Vorbereitung der EVI-Unterstützung in DB2/400-Datenbanksystemen finden Sie im SAP-Hinweis 501572. F-Faktentabelle „P-Index“ E-Faktentabelle „P-Index“ Abbildung 9.13 Indexschema bei Faktentabellen von Standard-InfoCubes 351 Indexschema DB2/400 non-unique, - ORACLE: Bitmap-Index (Ausnahme: Dimensionen mit hoher Kardinalität oder transaktionale InfoCubes), - DB2/400: EVI - Andere Datenbanksysteme: B-Tree-Index B-Tree-Index (non-unique) 1182.book Seite 352 Mittwoch, 4. März 2009 6:38 18 9 Indizes und DB-Statistiken P-Index Gewöhnlich werden die Dimensionenschlüssel der Faktentabelle mit einem non-unique P-Index (/BIC/F<InfoCube>~P bzw. /BIC/E<InfoCube>~P) indiziert. In Oracle- und Informix-basierten BW-Systemen wird nur die E-Faktentabelle mit dem P-Index indiziert. Auf MS SQL Server wird die E-Faktentabelle mit einem Unique-0-Index indiziert. In DB2/UDB-basierten BW-Systemen wird der P-Index auf der E- und auf der F-Faktentabelle als ein Clustering-Index angelegt. Ein Clustering-Index sortiert alle Datensätze einer Tabelle physikalisch in der Datenbank. Dabei beginnt der Cluster-Index mit der Zeitdimension, gefolgt von allen weiteren 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 Allgemeinen mittels eines Unique-B-Tree-Index indiziert. Diese Indizes haben Präfix-Namen der Form /BIC/D<InfoCube><#>~0 (# steht für die Nummer der Dimension des InfoCubes) bzw. die Suffixe P (Paket-Dimension), U (Unit-Dimension) oder T (Zeit-Dimension). Mit Ausnahme von Oracle- und DB2/400-Datenbanksystemen werden alle einzelnen Spalten der SID-Schlüssel zudem über non-unique B-Tree-Sekundärindizes indiziert, um die Ladeprozesse zu beschleunigen. Die erste SID-Spalte benötigt dabei gewöhnlich keinen Index, da sie die erste Spalte im Index über alle SID-Spalten ist. In Oracle- und DB2/400-Datenbanksystemen werden SID-Schlüssel in der Dimensionentabelle mittels eines zusammengesetzten non-unique B-TreeIndex indiziert (Präfix-Name /BIC/D<InfoCube><#>~010). Dimensionentabelle B-Tree (non-unique) B-Tree-Index (unique) Abbildung 9.14 Indexschema bei Dimensionentabellen 352 1182.book Seite 353 Mittwoch, 4. März 2009 6:38 18 Indizierungsschema in SAP NetWeaver BW Indizes für Dimensionentabellen mit hoher Kardinalität Standardmäßig erzeugt SAP NetWeaver BW auf den Spalten der Dimensionenschlüssel in der Faktentabelle eines InfoCubes einen Single-ColumnBitmap-Index (siehe Abbildung 9.14). Bei großen Dimensionen und Attributen mit hoher Kardinalität ist der Bitmap-Index nicht gut geeignet, da die durch Datenänderungen (Inserts, Deletes) bedingte Reorganisation der Bitmap-Indizes teurer ist als B-Tree-Indizes und der Platzbedarf des Bitmap-Index von der Kardinalität der Attribute abhängt. SAP NetWeaver BW bietet deshalb die Möglichkeit, in der Pflege der Dimensionen den standardmäß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 diese Umschaltung separat gepflegt werden von der Einstellung der Line Item Dimension. Das Kennzeichen Hohe Kardinalität sollte nur gesetzt werden, wenn die Anzahl der Datensätze in der Dimensionentabelle mindestens 20% der Anzahl Datensätze in der Faktentabelle entspricht. Bei anderen Datenbanksystemen als Oracle hat diese Einstellung keine Auswirkung auf den Indextyp oder die Query-Performance, da Bitmap-Indizes nur in OracleDatenbanken verwendet werden. Sie kann jedoch zu einer verbesserten Ladeperformance beitragen, da während des Ladevorgangs einige interne Prüfungen durchgeführt werden, die über den Einsatz verschiedener Ladestrategien entscheiden. Es wird deshalb empfohlen, auch bei NichtOracle-Datenbanksystemen bei hoher Kardinalität das Kennzeichen zu setzen. Die standardmäßig seitens SAP NetWeaver BW erzeugten Bitmap-Indizes in den Spalten der Dimensionenschlüssel der Faktentabelle sind die für den Star-Query-Join einzig verwendbaren Indizes. Bis zum Release Oracle 8.1 konnte bei Erzeugung von B-Tree-Indizes durch Einschaltung des Flags Hohe Kardinalität der Index in Oracle-basierten BW-Systemen nicht gewählt werden, da der B-Tree-Index im Star-Query-Join auf OracleDatenbanken nicht verwendet wurde. Theoretisch konnte Oracle den B-Tree-Index zwar nutzen, aber der Datenbankoptimierer musste den Index zur Laufzeit in einen Bitmap-Index umwandeln. Diese Eigenschaft wurde durch die SAP explizit ausgeschaltet, da ihr Einsatz zu falschen Daten geführt hatte. Die Option wurde durch den Datenbankparameter B_TREE_BITMAP_PLANS gepflegt, der seitens der SAP auf »FALSE« eingestellt war. 353 Hohe Kardinalität 9.4 1182.book Seite 354 Mittwoch, 4. März 2009 6:38 18 9 Indizes und DB-Statistiken 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üglich der Anzahl Datensätze ist, kann mit der Transaktion RSRV geprüft werden (siehe Abbildung 9.15). In der Rubrik Datenbank muss hierzu der Elementartest Datenbankinformationen über die Tabellen eines InfoProviders über das Kontextmenü ausgewählt � und der zu überprüfende InfoProvider angegeben werden �. Nach Ausführung des Tests � können im Testprotokoll die Anzahl der Datensätze sowie das Verhältnis der Größe der Dimensionentabellen anhand der Angabe der Größe der Faktentabelle 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-IDs nicht geeignet. Realtime-fähige InfoCubes sollen neben Leseprozessen auch gleichzeitige Schreibzugriffe unterstützen. Hierzu ist ein satzweises Sperren des Index erforderlich. Da für Bitmap-Indizes kein »Row-Level Locking« unterstützt wird, würde es bei Datenänderungen und Aktualisierung der Bitmap-Indizes zu Sperrungen kommen, die bei UPDATE-Operationen die Performance aufgrund von Deadlocks erheblich beeinträchtigen (ORA-60-Fehler). Der Unterschied zu Standard-InfoCubes liegt deshalb in der Indizierung der Dimensionen-IDs, der F-Faktentabelle mit dem B-Tree-Index, der satz- 354 1182.book Seite 355 Mittwoch, 4. März 2009 6:38 18 Indizierungsschema in SAP NetWeaver BW weises Sperren unterstützt. Die E-Faktentabelle für komprimierte Requests ist von dem geänderten Indexierungsschema nicht betroffen, da Schreibzugriffe nur auf der F-Faktentabelle stattfinden. Hinweis In dem geänderten Indexierungsschema für transaktionale InfoCubes auf Oracle- oder DB2/400-Datenbanksystemen ist deshalb auch der Grund für die schlechtere Leseperformance von Realtime-InfoCubes zu suchen, da die Verwendung des Bitmap-Index bei sehr vielen Datensätzen teurer ist als der B-TreeIndex. Achten Sie deshalb bei der Verwendung von transaktionalen InfoCubes auf die regelmäßige Komprimierung. Andere Datenbanksysteme als Oracle oder DB2/400 verwenden für Standard-InfoCubes und transaktionale InfoCubes ein identisches Indexierungsschema. F-Faktentabelle E-Faktentabelle „P-Index“ ORACLE : Bitmap-Index B-Tree-Index (non-unique) Abbildung 9.16 Indexschema Faktentabelle von Realtime-InfoCubes 9.4.3 Indizierung partitionierter InfoCubes (Oracle) In partitionierten InfoCubes werden die Daten der Faktentabelle physisch auf mehrere Partitionen der Datenbank verteilt. Die Verteilung der Daten erfolgt anhand eines Partitionierungsmerkmals, das im Basis-InfoCube als Zeitmerkmal definiert sein muss. In SAP NetWeaver BW können derzeit nur die Zeitmerkmale 0CALMONTH und 0FISCPER als Partitionierungs- 355 9.4 1182.book Seite 356 Mittwoch, 4. März 2009 6:38 18 9 Indizes und DB-Statistiken merkmale eingestellt werden. Die Partitionierung wird nur auf der komprimierten E-Faktentabelle durchgeführt. In der F-Faktentabelle wird hierzu ein weiterer Bitmap-Index auf der Spalte des Partitionierungsmerkmals eingefügt, die mit der entsprechenden Spalte des Partitionierungsmerkmals in der E-Faktentabelle korrespondiert (Präfix-Name /BIC/F<InfoCube>~900). Der Datenbankoptimierer erkennt anhand des Index auf dem Partitionierungsmerkmal in der F-Faktentabelle die richtige Partition auf der Datenbank in der komprimierten E-Faktentabelle. Bei einer Abfrage auf den partitionierten InfoCube übersetzt der SQL-Generator dazu die Zeitselektionen des Partitionierungsmerkmals in die entsprechenden Partitionierungsspalten, damit der Abfrageoptimierer die Query auf die relevanten Partitionen der E-Faktentabelle leiten kann. F-Faktentabelle Partitionierungsspalte E-Faktentabelle „P-Index“ ORACLE : Bitmap-Index B-Tree-Index (non-unique) 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 BW und gewöhnlich nicht als Analyse-Datenziele im Reporting verwendet werden. In DataStore-Objekten werden seitens SAP NetWeaver BW deshalb keine Sekundärindizes automatisch erzeugt. Es existiert lediglich ein Primärschlüssel, der über einen zusammengesetzten Primärindex auf die Schlüsselfelder des DataStore-Objekts verfügt. In schreiboptimierten DataStore-Objekten wird ergänzend zum Index auf dem technischen Schlüssel 356 1182.book Seite 357 Mittwoch, 4. März 2009 6:38 18 Indizierungsschema in SAP NetWeaver BW 9.4 zusätzlich ein Index auf die Felder des semantischen Schlüssels erzeugt, wenn dieser definiert ist. Sollen DataStore-Objekte auch in der Query-Analyse verwendet werden oder wird in Staging-Prozessen auf Feldern eines DataStore-Objekts gelesen, können Sekundärindizes in der Pflege des DataStore-Objekts auch manuell angelegt werden (siehe Abbildung 9.18). 09_18.emf Abbildung 9.18 Pflege Indizes bei DataStore-Objekten (I) Das Merkmalsfeld, auf das ein Index angelegt werden soll, muss hierfür aus den Datenfeldern über das Kontextmenü Kopieren (für Index) kopiert oder durch Ziehen des Merkmalsfelds in den Index eingefügt werden (siehe Abbildung 9.19). Wenn die Werte in den Indexfeldern jeden Datensatz eindeutig identifizieren, sollten Sie einen Unique-Index erstellen, andernfalls kann es zu Fehlern in der Aktivierung kommen, wenn die Werte nicht eindeutig sind. Die Bezeichnung des Index wird durch das System ausgewählt. Es können maximal 16 Sekundärindizes erstellt werden, es wird aber empfohlen, nicht mehr als fünf Sekundärindizes anzulegen. 357 Sekundärindizes manuell anlegen 1182.book Seite 358 Mittwoch, 4. März 2009 6:38 18 9 Indizes und DB-Statistiken Abbildung 9.19 Pflege Indizes bei DataStore-Objekten (II) 9.4.5 Navigationsattribute Indizierung der Stammdatentabellen (X-/Y-Tabellen) Die Stammdatentabellen der Navigationsattribute sind lediglich über den Primärschlüssel indiziert (Präfix-Name /BIC/X<Navigationsattribut>~0 beziehungsweise /BIC/Y<Navigationsattribut>~0), SAP NetWeaver BW legt auf den Spalten der Merkmalswerte und Navigationsattribute gewöhnlich keine Indizes an. Bei Verwendung von Navigationsattributen in Queries ist zu beachten, dass Navigationsattribute im erweiterten StarSchema einen zusätzlichen Join benötigen im Vergleich zu einer Query mit dem gleichen Objekt als Merkmal. Bei Verwendung von Einschränkungen auf Werten des Navigationsattributs in einer Query kann es deshalb sinnvoll sein, zusätzliche Indizes manuell auf den Stammdatentabellen des Navigationsattributs anzulegen. Ob zusätzliche Indizes angelegt werden sollen, hängt zuletzt von der Query-Selektion ab, ob Einschränkungen auf Merkmale oder Navigationsattribute 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 Navigationsattribut oder bei der (F4)-Wertehilfe auf solchen Navigationsattributen. SAP NetWeaver BW übersetzt die Datenselektion im Allgemeinen in SID-basierte Einschränkungen. 358 1182.book Seite 359 Mittwoch, 4. März 2009 6:38 18 Indizierungsschema in SAP NetWeaver BW Stammdatentabelle X (Material) 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 Abbildung 9.20 Indexschema bei Stammdatentabellen In der Regel ist eine Indizierung der Merkmalsspalten nicht erforderlich, meist ist ein Einspalten-Index über eingeschränkte Navigationsattribute sinnvoller. Je nach Kardinalität des Attributs sollten Sie bei wenigen Merkmalsausprägungen einen Bitmap-Index verwenden beziehungsweise bei sehr vielen Merkmalsausprägungen einen B-Tree-Index. Weiterführende Informationen zum Anlegen von Indizes auf InfoObjects von Stammdaten 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äfixName /BIC/S<Merkmal>~001). SID-Tabelle (Material) Primärindex /BI0/SCUSTOMER~0 Sekundärindex /BI0/SCUSTOMER~001 B-Tree-Index (unique) Abbildung 9.21 Indexschema bei SID-Tabellen 359 9.4 1182.book Seite 360 Mittwoch, 4. März 2009 6:38 18 9 Indizes und DB-Statistiken Schutzmechanismus Die Bedingung eines Unique-Index auf der SID-Spalte ist ein zusätzlicher Schutzmechanismus, der das Einfügen doppelter SID-Schlüssel verhindert. Beide Indizes beschleunigen die häufig benutzte Funktion der Übersetzung eines SID-Schlüssels in die Merkmalsausprägung und umgekehrt. 9.5 Query-Monitor Star-Join-Ausführungsplan Die Nutzung der Indizes bei der Ausführung einer Query kann über den Ausführungsplan (Execution Plan) in SAP NetWeaver BW eingesehen werden. Im Query-Monitor (Transaktion RSRT) muss hierzu in der Option Ausfü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. Der Ausführungsplan beschreibt die Schritte, die von der Datenbank bei der Ausführung der Query durchlaufen werden. 360 1182.book Seite 361 Mittwoch, 4. März 2009 6:38 18 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 Indizes und weitere Informationen zur Größe der Tabellen und Berechnung der Statistiken abgerufen werden (siehe auch Abschnitt 9.8). Hinweis Das Lesen und Interpretieren von Ausführungsplänen bedarf grundsätzlich einiger Übung und ist zumeist dem erfahrenen Datenbankadministrator vorbehalten. Die im Ausführungsplan angezeigten Begriffe werden zudem durch das Datenbanksystem bestimmt und unterscheiden sich bei den verschiedenen Datenbanksystemherstellern. Dem Ausführungsplan können Sie zum einen die an der Query beteiligten Objekte wie Tabellen und Indizes entnehmen, die durch die Schlüsselwörter TABLE und INDEX eingeleitet werden. Zum anderen lassen sich im Ausführungsplan die vom Datenbankoptimierer gewählten Zugriffsarten und Join-Operationen ablesen, die z.B. durch Schlüsselwörter wie TABLE ACCESS FULL oder MERGE JOIN bestimmt werden. Grundsätzlich können bei einem Ausführungsplan die folgenden Typen von Operationen unterschieden werden, die in Tabelle 9.2 dargestellt sind (Auszug am Beispiel des Datenbanksystems Oracle): 361 Aufbau des Ausführungsplans 1182.book Seite 362 Mittwoch, 4. März 2009 6:38 18 9 Indizes und DB-Statistiken 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 Für das strukturierte Lesen des Ausführungsplans ist empfehlenswert, den Ausführungsplan zunächst in Blöcke der an der Query beteiligten Tabellen zu zerlegen und den Plan von innen nach außen zu lesen, das heißt in der Reihenfolge der Tabellenzugriffe, die der Nummerierung der Operationsschritte entnommen werden können. Das Prinzip ist in Abbildung 9.24 dargestellt. Dimension „Zeit“ (/BI0/D0SD_C14T) Dimension „Kunde“ (/BI0/D0SD_C142) Faktentabelle /BI0/F0SD_C14 Dimension „Paket“ (/BI0/D0SD_C14P) Abbildung 9.24 Aufbau eines Ausführungsplans 362 1182.book Seite 363 Mittwoch, 4. März 2009 6:38 18 Star-Join-Ausführungsplan 9.5 In der Beispiel-Query werden Daten aus der Faktentabelle /BI0/F0SD_C14 des InfoCubes 0SD_C14 selektiert. Die Eingrenzung der Daten in der Faktentabelle erfolgt über die Dimensionen Zeit (Tabelle /BI0/D0SD_C14T), Kunde (Tabelle /BI0/D0SD_C142) und Paket (Tabelle /BI0/D0SD_C14P). Block 1 im Ausführungsplan: Index Full Scan 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 INDEX FULL SCAN auf den Index ~010 der Zeit-Dimensionentabelle /BI0/D0SD_ C14T gewählt. In Oracle-Datenbanksystemen werden die SID-Schlüssel in der Dimensionentabelle mittels eines zusammengesetzten non-unique BTree-Index indiziert (zum Indexschema von Dimensionentabellen siehe auch Abschnitt 9.4.1). Immer wenn ein Index Scan ausgeführt wird, werden Daten aus einem Index gelesen, um die Schlüssel (Row-IDs) der benötigten Datensätze zu finden. Beim INDEX FULL SCAN durchsucht der OracleProzess den Indexbaum anhand seiner logischen Sortierung. Das Ergebnis ist 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 lesende Block und die Nummer des Datensatzes über die physikalische Adresse (Row-ID) ermittelt, die zuvor über den Index Scan ausgelesen wurde. Der Zugriff über die Row-ID ermöglicht ein schnelles Lesen des Datensatzes aus der Tabelle. Das Ergebnis der Operation im ersten Block ist die Selektion eines Datenrecords in der Dimension Zeit, da die SAP BEx Query als Selektionsparameter das Zeitmerkmal 0CALMONTH enthält. Block 2 im Ausführungsplan: Full Table Scan TABLE ACCESS FULL /BI0/D0SD_C142 (Estim Costs = 2, Estim #Rows = 1) In Block 2 des Ausführungsplans erfolgt eine vollständige Tabellendurchsuchung (Full Table Scan) der Dimensionentabelle Kunde (/BI0/D0SD_ C142). Bei einem Full Table Scan werden alle Blöcke der Tabelle in den Block-Puffer gelesen und dort die einzelnen Zeilen mit der WHERE-Bedin- 363 1182.book Seite 364 Mittwoch, 4. März 2009 6:38 18 9 Indizes und DB-Statistiken gung oder anderen Zugriffen weiterverarbeitet. Mit dem Full Table Scan wird häufig ein langsamer Zugriff assoziiert. Bei kleinen Tabellen ist der Full Table Scan jedoch meist die günstigere Operation als der Zugriff über den Index. Bei der Durchsuchung großer Tabellen mit kleinen Ergebnismengen ist der Full Table Scan ein Hinweis auf fehlende Indizes. Das Ergebnis des Tabellenzugriffs wird anschließend im Daten-Puffer sortiert (Prozessschritt 4: BUFFER SORT). Die Ergebnismengen aus Block 1 und 2 werden dann über einen Cartesian Join miteinander verbunden (Prozessschritt 5: MERGE JOIN CARTESIAN). Beim Cartesian Join werden alle Datensätze der ersten Ergebnismenge (Block 1) mit allen Datensätzen der zweiten Ergebnismenge (Block 2) verknüpft, da beide Ergebnismengen aus Block 1 und Block 2 jeweils nur einen Datensatz enthalten. Index Range Scan Block 3 im Ausführungsplan: INDEX RANGE SCAN /BI0/F0SD_C14~020 Search Columns: 1 In Block 3 erfolgt ein Zugriff auf den Index ~020 der Faktentabelle /BI0/F0SD_C14 des InfoCubes 0SD_C14 mittels der Zugriffsart Index Range Scan. Der Index ~020 ist der durch einen Bitmap-Index indizierte Fremdschlüssel der Dimension Zeit in der Faktentabelle (zum Indexschema von Faktentabellen siehe auch Abschnitt 9.4.1). Beim Index Range Scan findet der Optimizer im Index eine Ergebnismenge von mehreren Row-IDs, der anschließende Datenzugriff in der Tabelle erfolgt wieder über die physikalische Adresse der Datensätze (Prozessschritt 7: TABLE ACCESS 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 8 miteinander verknüpft. Beim Nested Loop wird für jeden Datensatz der ersten Ergebnismenge die zweite Ergebnismenge vollständig durchsucht. Wenn beide Ergebnismengen sehr klein sind oder ein kartesisches Produkt (jeder mit jedem) vorliegt, ist der Nested Loop meist die günstigste Join-Variante. Wenn beide Ergebnismengen sehr groß sind, ist der Nested Loop die ungünstigste Join-Variante. Im Beispiel in Abbildung 9.18 sind beide Ergebnismengen sehr klein, weshalb hier die Join-Variante Nested Loop gewählt wird. Index Unique Scan Block 4 im Ausführungsplan: INDEX UNIQUE SCAN /BI0/D0SD_C14P~0 Search Columns : 1 364 1182.book Seite 365 Mittwoch, 4. März 2009 6:38 18 Star-Join-Ausführungsplan In Block 4 erfolgt ein Scan über den Index ~0 des Primärschlüssels der Tabelle /BI0/D0SD_C14P (Dimensionentabelle Paket). In Dimensionentabellen wird der Primärschlüssel der DIMIDs im Allgemeinen mittels eines Unique B-Tree-Index indiziert (zum Indexschema von Dimensionentabellen siehe auch Abschnitt 9.4.1). Der Index Unique Scan wird verwendet, wenn in der WHERE-Bedingung eine Spalte verwendet wird, auf der ein Unique-Index liegt. Die Indexblöcke werden dabei vom Root-Block bis zum Leaf-Block gelesen. Der eigentliche Datenzugriff erfolgt wieder über die physische Adresse des Datensatzes (TABLE ACCESS BY INDEX ROWID) in der 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 und Zugriffsarten des Datenbanksystems Oracle stellen nur einen kleinen Ausschnitt der verfügbaren Prozessschritte dar. Die wichtigsten Join-Operationen und Zugriffsarten sind deshalb bezüglich ihrer inhaltlichen Bedeutung in Tabelle 9.3 zusammengestellt: Typ Operation Beschreibung JoinOperationen NESTED LOOP Durchsucht für jeden Datensatz der ersten Ergebnismenge die gesamte zweite Ergebnismenge. SORT MERGE JOIN Verknüpft zwei gleich geordnete Ergebnismengen. Sehr effizient bei etwa gleich großen, bereits vorsortierten Ergebnismengen. HASH JOIN Liest die kleinere Ergebnismenge in den Speicher 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 korrespondierenden Datensätze existieren (z.B. bei NOT IN-Klauseln). OUTER JOIN Erzeugt eine Vereinigungsmenge zweier Datenmengen, auch wenn keine korrespondierenden Sätze enthalten sind. Tabelle 9.3 Zusammenstellung von Oracle-Join-Operationen und Zugriffsarten 365 9.5 1182.book Seite 366 Mittwoch, 4. März 2009 6:38 18 9 Indizes und DB-Statistiken Typ Operation Beschreibung JoinOperationen CARTESIAN JOIN Verknüpft alle Sätze der ersten Ergebnismenge mit allen Sätzen der zweiten Ergebnismenge (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 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 ROWID INDEX UNIQUE SCAN INDEX RANGE SCAN Index Scan auf Spalten mit Unique-Index, z.B. bei Primärschlüsseln. Es wird jeweils eine Zeile zurückgegeben. Index Scan auf einen Wertebereich im Indexbaum, es wird ein Zeilenbereich zurückgegeben (LIKE, BETWEEN, ORDER BY). INDEX FULL SCAN Durchsucht den Indexbaum, bis alle passenden Werte gefunden sind. Das Ergebnis liegt als sortierte Ergebnismenge vor. FAST FULL INDEX Liest alle Blöcke eines Index, ohne die Datenblöcke der Tabelle selbst zu lesen. Sehr effizient, wenn alle in der WHERE-Bedingung benötigten Daten im Index vorhanden sind. SCAN Tabelle 9.3 Zusammenstellung von Oracle-Join-Operationen und Zugriffsarten (Forts.) 9.6 Administration der Indizes Mit den BW-seitigen Administrationswerkzeugen können Indizes angelegt, überprüft und gelöscht werden. Die Administration von Indizes mit Datenbank-Tools ist hierfür nicht erforderlich. Die Erstellung der Indizes erfolgt mit der Anlage von Tabellen in SAP NetWeaver BW weitestgehend automatisch (z.B. Indizes auf Fremdschlüsseln der Faktentabelle eines InfoCubes). In einigen Fällen kann es nützlich sein, zu den bereits vorhandenen Indizes weitere Sekundärindizes anzulegen. Die Erstellung zusätzlicher Indizes oder die Löschung von Indizes sollte grundsätzlich mit den im BW-System vorhandenen Administrationswerkzeugen erfolgen, da auf diese Weise die Indextabellen automatisch im Data Dictionary bekanntgemacht werden. 366 1182.book Seite 367 Mittwoch, 4. März 2009 6:38 18 Administration der Indizes 9.6.1 9.6 Indizes überprüfen Für einen InfoCube kann der Status der Sekundärindizes der E- und F-Faktentabelle geprüft werden. Ausgenommen von dieser Prüfung sind der Primärindex der Faktentabelle sowie benutzerdefinierte Indizes (z.B. Indizes 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 � stehen unter der Registerkarte Performance verschiedene Administrationsfunktionen für Indizes zur Verfügung. Hierzu zählen die Überprüfung des Status der Indizes, das Löschen von Indizes und das Reparieren von Indizes �. Für die mit dem InfoCube korrespondierenden Aggregate stehen die gleichen Funktionen für die Indizes aller Aggregate-Faktentabellen zur Verfügung �. Über die Schaltfläche Indizes prüfen wird geprüft, ob bereits Indizes vorliegen und der Indextyp korrekt ist (Bitmap- oder B-Tree-Index): Ist der Status Grün, liegen Indizes im korrekten Indextyp vor. Bei Status Gelb liegen Indizes mit einem falschen Indextyp vor, bei Status Rot existieren keine Indizes oder Indizes sind defekt. Indizes prüfen Der Status der Indizes kann auch mit der Transaktion RSRV überprüft werden (siehe Abbildung 9.26). In der Rubrik Datenbank muss hierzu der Elementartest Datenbank-Indizes eines InfoCubes und seiner Aggre- Transaktion RSRV 367 1182.book Seite 368 Mittwoch, 4. März 2009 6:38 18 9 Indizes und DB-Statistiken gate über das Kontextmenü ausgewählt � und der zu überprüfende InfoCube angegeben werden �. Nach Ausführung des Tests � kann im Testprotokoll der Status der Datenbankindizes der Faktentabellen des InfoCubes und aller zugehörigen Aggregate geprüft werden �. Abbildung 9.26 Transaktion RSRV – Prüfung Datenbank-Indizes InfoCube und Aggregate Transaktion DB02 Fehlende Indizes können auch mit der Transaktion DB02 unter dem Menü Diagnose 폷 Fehlende Tabellen und Indizes überprüft werden (siehe Abbildung 9.27). Abbildung 9.27 Transaktion DB02 – Überprüfung fehlender Indizes 368 1182.book Seite 369 Mittwoch, 4. März 2009 6:38 18 Administration der Indizes 9.6 Hinweis Beachten Sie, dass beim Laden von InfoCubes Indizes automatisch gelöscht und neu aufgebaut werden, um den Ladeprozess zu beschleunigen. Stellen Sie fehlende Indizes auf InfoCube-Faktentabellen fest, sollten Sie zunächst prüfen, ob der InfoCube zum Zeitpunkt der Indexprüfung beladen wird. Über die Funktion Fehlende Tabellen und Indizes erfolgt die Konsistenzprüfung für Primärindizes und Sekundärindizes auf der Datenbank. Fehlende Primärindizes sind als hoch kritisch einzustufen, da in einem solchen Fall die Konsistenz der Daten nicht mehr gewährleistet ist und die Gefahr doppelter Schlüsseleinträge besteht. Durch den fehlenden Primärindex sind zudem die Datenbankzugriffe sehr inperformant. Konsistenzprüfung für Primär- und Sekundärindizes Im Ergebnisprotokoll der Konsistenzprüfung wird zwischen drei Indexkategorien unterschieden: 1. Indizes, die im ABAP Dictionary definiert sind, aber auf der Datenbank fehlen 2. Indizes, die auf der Datenbank gefunden wurden, aber nicht im ABAP Dictionary bekannt sind 3. Indizes, die im ABAP Dictionary als optionale Indizes definiert sind Fehlende Datenbankindizes, die im ABAP Dictionary definiert sind, können z.B. dadurch entstehen, dass der Index mit einem datenbankeigenen Tool gelöscht wurde. Die dauerhafte Löschung von Indizes sollte zur Vermeidung von Inkonsistenzen immer über das ABAP Dictionary erfolgen. Indizes im ABAP Dictionary Bei Indizes, die auf der Datenbank gefunden wurden, aber nicht im ABAP Dictionary bekannt sind, kann es sich ebenfalls um Indizes handeln, die mit einem Datenbank-Tool erzeugt wurden. Sofern die SAP-Namenskonvention für Indizes eingehalten wurde und der Index im Kundennamensraum liegt, können solche Indizes nachträglich im ABAP Dictionary angelegt werden. Andernfalls sollte der Index auf der Datenbank gelöscht werden und mit der Transaktion SE11 erneut angelegt werden. Indizes auf der Datenbank Optionale Indizes sind solche Indizes, für die in Abhängigkeit vom Datenbanksystem festgelegt wird, ob ein im ABAP Dictionary definierter Index auf der Datenbank angelegt werden soll. Es kann dabei ausgewählt werden zwischen dem permanenten Anlegen von im ABAP Dictionary definierten Indizes auf der Datenbank, dem Anlegen der Indizes nur auf ausgewählten Datenbanksystemen oder keiner Anlage des Index auf der Datenbank. In dieser Rubrik der Konsistenzprüfung werden solche Indizes Optionale Indizes 369 1182.book Seite 370 Mittwoch, 4. März 2009 6:38 18 9 Indizes und DB-Statistiken angezeigt, die auf der Datenbank angelegt sind, obwohl sie laut Definition im ABAP Dictionary nicht auf der vorliegenden Datenbank angelegt werden sollten, und Indizes, die auf der Datenbank fehlen, obwohl sie laut ABAP Dictionary für das vorliegende Datenbanksystem angelegt werden sollten. In SAP NetWeaver BW 7.0 ist auch weiterhin das bis BW 3.50 gültige DBA-Cockpit verfügbar, das mit der Transaktion DB02OLD aufgerufen werden kann. Die oben beschriebenen Funktionen haben auch hier weiterhin ihre Gültigkeit (siehe Abbildung 9.28). Abbildung 9.28 DBA-Cockpit DB02OLD Prüfung von Inkonsistenzen Bei den Prüfungen auf Inkonsistenzen zwischen dem ABAP Dictionary und dem Datenbankkatalog greift die Transaktion DB02 auf die interne Tabelle DBDIFF zurück. In der Tabelle DBDIFF werden Ausnahmefälle unter anderem für Tabellen und Indizes gespeichert, für die eine akzeptierte Inkonsistenz zwischen dem ABAP Dictionary und dem Datenbankkatalog besteht. Bei den in der Tabelle DBDIFF gespeicherten Objekten handelt es sich z.B. um Faktentabellen ohne Primärindex oder temporäre Objekte wie temporäre Tabellen, Views oder Trigger. Die Objekte der Tabelle DBDIFF werden bei der Transaktion DB02 berücksichtigt, indem für diese Objekte keine Konsistenzfehler gemeldet werden. 370 1182.book Seite 371 Mittwoch, 4. März 2009 6:38 18 Administration der Indizes 9.6 Hinweis Wenn temporäre Objekte in der Transaktion DB02 als inkonsistente Objekte gemeldet werden, sollten Sie den ABAP-Report SAP_UPDATE_DBDIFF ausführen, der die Tabelle DBDIFF aktualisiert und die temporären Objekte in die Tabelle einträgt. Nach Auffrischen der Ergebnisse in der Transaktion DB02 wird für diese Objekte kein Konsistenzfehler mehr gemeldet. Um Warnungen zur Inkonsistenz für ein Objekt zu unterdrücken, können Einträge in die Tabelle DBDIFF für Ausnahmeregeln auch manuell erzeugt werden. Hierzu existiert in der Transaktion SM30 die Pflegesicht DBDIFFVIEW. Benutzerdefinierte Einträge in die Tabelle DBDIFF sollten nur für Objekte wie z.B. temporäre Tabellen erfolgen, die auf der Datenbank existieren, nicht aber im ABAP Dictionary. 9.6.2 Indizes aufbauen Meldet die Transaktion DB02 im Ergebnisprotokoll fehlende Indizes, können diese direkt aus der Transaktion angelegt werden (siehe Abbildung 9.29). 09_29.emf 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 �. 371 Inkonsistenzwarnungen unterdrücken 1182.book Seite 372 Mittwoch, 4. März 2009 6:38 18 9 Indizes und DB-Statistiken Löschen von Indizes Über die Schaltfläche Indizes löschen können in der InfoCube-Administration unter der Registerkarte Performance die Indizes des InfoCubes gelöscht werden. Die InfoCube-Indizes sollten insbesondere dann gelöscht werden, wenn durch Delta-Uploads von großen Datenmengen (mehr als eine Million Sätze) aus Performancegründen die Indizes nicht beim Hochrollen angepasst, sondern zunächst gelöscht und nach dem Hochrollen vollständig neu aufgebaut werden sollen. Neuaufbau von Indizes Der Neuaufbau der Indizes erfolgt über die Schaltfläche Indexaufbau (batch). Diese Funktion stellt gelöschte Indizes wieder her und korrigiert defekte Indizes. Löschung und Neuaufbau von Indizes eines InfoCubes können durch die Einstellungen am InfoCube automatisiert werden (siehe Abbildung 9.30). Abbildung 9.30 Einstellungen für Löschung/Neuaufbau von InfoCube-Datenbankindizes Das Verfahren der automatischen Löschung von Indizes vor jedem Ladevorgang und des Neuaufbaus nach Abschluss des Ladens beschleunigt zwar den Ladeprozess, kann aber gleichzeitige Lesevorgänge auf einem InfoCube stark verlangsamen. Achten Sie deshalb bei Anwendung dieses Verfahrens darauf, dass während des Ladens von Daten keine Queries auf dem InfoCube ausgeführt werden. Der Neuaufbau von Indizes kann zu Sperrkonflikten mit dem automatischen Komprimieren und Hochrollen des InfoCubes führen, da während des Indexaufbaus keine Requests in Aggregate hochgerollt oder komprimiert werden können. Es empfiehlt sich in diesem Fall die Einplanung der Index-Jobs über Prozessketten. Ist für den InfoCube eine automatische Request-Verarbeitung eingestellt, werden allerdings bei der Verwendung von Prozessketten die Einstellungen der automatischen Request-Verarbeitung am InfoCube nicht berücksichtigt. Die automatischen Prozesse müssen dann als Prozesstypen in die Prozesskette zusätzlich eingebunden werden. 372 1182.book Seite 373 Mittwoch, 4. März 2009 6:38 18 Administration der Indizes Die Einplanung und Ausführung der Indexing-Jobs der InfoCube-Administration kann in der Jobübersicht mit der Transaktion SM37 geprüft werden. Die Namen aller Indexing-Jobs beginnen mit »BI_INDX«. 9.6 Jobeinplanung Die Reparatur der InfoCube-Indizes ist auch mit dem ABAP-Report SAP_ INFOCUBE_INDEXES_REPAIR möglich. Dieser Report gilt für alle aktiven InfoCubes und Aggregate. Der Bericht entfernt vorhandene Primärindizes und legt fehlende P-Indizes der F- und fehlende Sekundärindizes aller InfoCubes des BW-Systems neu an. Da eine selektive Auswahl eines InfoCubes nicht möglich ist und der Report zum systemweiten Reparieren von InfoCube-Indizes verwendet wird, sollte dieser Job als Hintergrundprozess eingeplant werden. Indizes auf Stammdatentabellen können mit Hilfe der Transaktion SE11 angelegt werden. Im Beispiel in Abbildung 9.31 kann ein zusätzlicher Index auf dem Navigationsattribut Warengruppe (S__0MATL_GROUP) bei sehr vielen Einträgen in der Stammdatentabelle des Objekts 0MATL_ GROUP die Query-Antwortzeit bei Verwendung des Navigationsattributs verbessern. Dabei ist zunächst die Stammdatentabelle des InfoObjects /BI0/XMATERIAL auszuwählen, um darin auf dem Feld des Navigationsattributs einen Index anzulegen. Abbildung 9.31 Indizierung von Navigationsattributen 373 Indizes auf Stammdatentabellen 1182.book Seite 374 Mittwoch, 4. März 2009 6:38 18 9 Indizes und DB-Statistiken Bitmap-Index Soll ein Bitmap-Index erstellt werden, können Sie genauso vorgehen wie bei der Erstellung des B-Tree-Index. Der Index wird aber zunächst nicht aktiviert, sondern nur gespeichert. Die Umstellung auf den Bitmap-Index erfolgt über ein Datenbank-Utility �, mit dessen Hilfe die Speicherparameter 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 Dictionary definierter Index auch auf der Datenbank physisch erstellt werden soll. 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 Datenbanksystem angelegt. Bei dieser Option muss angegeben werden, auf welchen Datenbanken der Index angelegt werden soll. Dies kann durch eine Auswahlliste (Liste der DB-Systeme, auf denen der Index angelegt werden soll) oder eine Ausschlussliste (Liste der DB-Systeme, auf denen der Index nicht angelegt werden soll) geschehen. In beiden Fällen können Sie bis zu vier verschiedene DB-Systeme auflisten. 374 1182.book Seite 375 Mittwoch, 4. März 2009 6:38 18 Administration der Indizes 왘 kein Datenbankindex Der Index wird nicht auf der Datenbank angelegt. Falls Sie diese Option für einen schon auf der Datenbank angelegten Index wählen, wird der Index beim Aktivieren von der Datenbank gelöscht. Hinweis Ein Unique-Index muss immer auf der Datenbank angelegt werden, da er die Einfügung doppelter Datensätze verhindert. Zur Gewährleistung der Datenkonsistenz darf ein Unique-Index nicht von der Datenbank gelöscht werden. In der Administration der Speicherparameter kann über die Schaltfläche Für Neuanlegen der Speicherparameter für Bitmap-Index = X gesetzt werden. Mit dem nächsten Neuanlegen wird der Index als Bitmap-Index erzeugt (siehe Abbildung 9.33). Anschließend muss der Index noch aktiviert werden. Abbildung 9.33 Erstellung eines Bitmap-Index (II) In jedem Falle sollte bei zusätzlichen Indizes auf Stammdatentabellen der Performancegewinn nach Anlegen der Indizes geprüft werden, da zusätzliche Indizes aufgrund des Wartungsaufwands die Ladeperformance der Stammdaten und den Attributänderungslauf (Change-Run) negativ beein- 375 9.6 1182.book Seite 376 Mittwoch, 4. März 2009 6:38 18 9 Indizes und DB-Statistiken flussen können. Weitere Informationen für die zusätzliche Indizierung von Stammdatentabellen finden Sie auch im SAP-Hinweis 402469. Hinweis Beachten Sie, dass Bitmap-Indizes keine Sperren auf Datensatzebene unterstützen, sondern nur die gesamte Tabelle, die mit einem Bitmap-Index versehen ist, bei Datensatzänderungen gesperrt werden kann. Für InfoObjects mit BitmapIndex kann dies den Nachteil bedeuten, dass die Parallelisierung von Datenpaketen bei Ladevorgängen nicht mehr möglich ist. 9.6.3 Index-Qualität überprüfen In einzelnen Fällen kann es passieren, dass trotz des richtigen Index die Performance unbefriedigend ist. In solchen Fällen sollten Sie die Qualität des Index überprüfen. Eine schlechte Index-Qualität kann immer dann auftreten, wenn Datensätze aus einer Tabelle gelöscht wurden. In diesem Fall wird der Datensatz auch aus dem Index gelöscht. Der Platz im Indexbaum bleibt leer, bis ein neuer Datensatz genau an diese Stelle eingefügt wird. Sind sehr viele solcher leeren Plätze vorhanden, müssen beim Zugriff auf den Index mehr Blöcke gelesen werden, um alle zutreffenden Datensätze zu finden. Index-Fragmentierung Man spricht in solchen Fällen von einer Fragmentierung des Index. Der Grad der Fragmentierung gibt an, wie gut der Platz in den Blöcken eines Index genutzt wird: Je kleiner der Anteil des tatsächlich genutzten Platzes ist, desto fragmentierter ist der Index. Der Index wird dann auch als »unbalanciert« oder »entartet« bezeichnet. Index-Fragmentierung tritt meist bei Tabellen mit großen Datenschwankungen auf. Die Storage-Qualität des Index kann auf verschiedene Weise geprüft werden. In SAP NetWeaver BW existiert hierzu der ABAP Report RSORATAD, mit dem über die Transaktion SE38 einzelne Indizes untersucht, bzw. der Report RSORAISQN, mit dem mehrere Indizes gleichzeitig überprüft oder die Analyse aller Indizes gestartet werden kann. Das DBA-Cockpit bietet ebenfalls die Möglichkeit, die Index-Qualität zu analysieren: Analyse IndexQualität 1. Wechseln Sie in der Transaktion DB02 über das Menü Segments 폷 Detailed Analysis in die Eingabemaske zur Selektion der zu analysierenden Tabelle oder des Indizes (siehe Abbildung 9.34), und geben Sie den technischen Tabellennamen bzw. Indexnamen ein. 376 1182.book Seite 377 Mittwoch, 4. März 2009 6:38 18 Administration der Indizes Abbildung 9.34 DBA-Cockpit – Analyse Index-Qualität (I) Selektieren Sie im anschließenden Bildschirm den zu untersuchenden Index ü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 �. Das Analyseprotokoll der Index-Qualität kann im unteren Bildschirm unter der Registerkarte Storage 폷 Storage Quality abgerufen werden �. Abbildung 9.35 DBA-Cockpit – Analyse Index-Qualität (II) 377 9.6 1182.book Seite 378 Mittwoch, 4. März 2009 6:38 18 9 Indizes und DB-Statistiken In dem entsprechenden Bildschirm � wird in der Zeile Index Storage Quality ein Prozentwert der Index-Qualität angegeben. Ist der angegebene Prozentwert < 70, wird in der Regel die Reorganisation des Index empfohlen. Bei sehr kleinen Indizes können möglicherweise zu kleine Prozentwert berechnet werden, obwohl der Index neu reorganisiert wurde. In diesem Fall sollte auch der Wert Number of blocks (used) überprüft werden. Ist er < 10, empfiehlt es sich, die in den folgenden Ausführungen beschriebene Methode zu benutzen, um die Storage-Qualität zu ermitteln: 1. Wechseln Sie in der Transaktion DB02OLD über die Schaltfläche Detailed Analysis in die Eingabemaske zur Selektion der zu analysierenden 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 analysierenden Index. 3. Verzweigen Sie über die Schaltfläche Detailed Analysis in die detaillierte 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 aus der Systemtabelle »index_stats« ermittelt. Beachten Sie, dass ein Validate die Performance des Systems beeinträchtigen kann, da Teile des Index gegen Updates gelockt sind. Führen Sie diese Kommandos also nicht zu Zeiten durch, zu denen viele Benutzer auf die entsprechende Tabelle zugreifen! Überprüfen Sie nach Durchführung des Validate Structure-Laufs durch erneutes Aufrufen des Detailed Analysis-Bildschirms in der Rubrik Analysis of B*-tree den Wert Used in tree … without del. rows (siehe Abbildung 9.36). Dieser Wert gibt die aktuelle Storage-Qualität des Index wieder und sollte nicht kleiner als 70% sein. Überprüfen Sie zudem in der Rubrik B*-tree leaf blocks die Werte entries und deleted. Das Verhältnis deleted/entries sollte kleiner als 25% sein. Wenn die zu überprüfenden Index-Parameter nicht im Rahmen der genannten Größen liegen, sollten Sie den Datenbankadministrator bitten, den Index neu aufzubauen. Hinweise zum Neuaufbau der Indizes eines InfoCubes finden Sie in Abschnitt 9.6.2. 378 1182.book Seite 379 Mittwoch, 4. März 2009 6:38 18 Datenbankoptimierer Abbildung 9.36 DBA-Cockpit – Analyse Index-Qualität (III) 9.7 Datenbankoptimierer Die SQL-Anweisung einer Query beschreibt, welche Datenbankobjekte bei Ausführung der Query zu lesen sind; sie kann aber nicht beschreiben, wie die Daten auf der Datenbank am besten gefunden werden. Die hierfür erforderliche Suchstrategie ermittelt eine Instanz in der Datenbank, die als Datenbankoptimierer bezeichnet wird. Der Datenbankoptimierer ermittelt anhand der SQL-Anweisung die günstigste Suchstrategie und erstellt hierfür den günstigsten Ausführungsplan. Abbildung 9.37 verdeutlicht das Problem. Im vereinfachten Star-Schema-Modell in Abbildung 9.37 soll eine Abfrage die Menge für Material M6000 im Werk W1030 für den Monat Oktober 2008 finden. Die Abfrage kann auf verschiedenen Wegen zum gewünschten Ergebnis führen. Würde z.B. zunächst in der Zeitdimension der Monat 10.2008 selektiert, müssten zunächst fünf Datensätze in der Faktentabelle gesucht werden, die dann über die Einschränkung des Materials M6000 und des Werks W1030 einen Datensatz in der Faktentabelle finden. 379 9.7 1182.book Seite 807 Mittwoch, 4. März 2009 6:38 18 Index A ABAP Buffer Programm-Puffer ABAP Dictionary 49 ABAP/HEAP_AREA_DIA 67, 73, 77 ABAP/HEAP_AREA_NONDIA 67, 74, 77 ABAP/HEAP_AREA_TOTAL 73, 74, 77, 223 ABAP/HEAPLIMIT 77 ABAP-Applikationsserver 48 ABAP-Dictionary-Puffer 70 ADK 398 ADK-Archivadministration 405 Advanced Sizing Sizing Aggregat 34, 501, 504 abschalten 543 Aggregatbaum 539 Aggregationsstufen 504 anlegen 528 auf Festwerten 513 auf Hierarchieknoten 510 auf Merkmalen 504 auf Navigationsattributen 508 auf zeitabhängigen Navigationsattributen 509 auf zeitkonstanten Navigationsattributen 508 automatische Erstellung 519 Bewertung 530 Blockgröße 551 Delta-Verfahren 550 des Hierarchie-/Attributänderungslaufs 545 Dimensionentabelle 505, 519 E-Faktentabelle 505, 536 Faktentabelle 519 F-Faktentabelle 505, 536 Hierarchie-/Attributänderungslauf 508 hochrollen 536 Kennzahlen mit Ausnahmeaggregation 507, 514 Komprimierung 536 Line-Item-Aggregat 517 Line-Item-Dimension 506 manuelle Erstellung 524 Neuaufbau 550 Aggregat (Forts.) optimieren 522, 524, 541 Roll-up 503, 532, 538 Roll-up-Hierarchie 539, 540 vorschlagen aus BW-Statistik 520, 521 vorschlagen aus Query-Definition 520, 522 Aktivierungs-Queue 155 ALE 659 Alloc fault rate 196 Allocation retries 196 allokierter Speicher 219 Antwortzeit in einem SAP-System Ausführungszeit 252 Datenbankzeit 252 Dispatcher-Wartezeit 252 Enqueue-Zeit 252 Ladezeit 252 Processing-Zeit 253 Roll-in 252 Roll-out 252 Roll-Wartezeit 252 Anwendungsmonitor Benutzerverteilung 715 Application Link Enabling 659 Applikationsserver 189 Archivdatei 400, 403 Archivierung 398, 399, 404 Archivierung von Anwendungs-Logs 424 Archivierung von Basis-InfoCubes und DataStore-Objekte 399 Archivierung von Request-Informationen 415 Archivierungsobjekt 398, 401, 406 Archivierungs-Request 404 Archiving Development Kit 398 asynchroner RFC 658 Aufrufer 693 Ausführungsplan 336, 360, 361, 527 Aufbau 361 Full Table Scan 337, 363 Index Full Scan 363 Index Range Scan 338, 364 Index Unique Scan 338, 364 Star-Join-Ausführungsplan 360 807 1182.book Seite 808 Mittwoch, 4. März 2009 6:38 18 Index Auslagerungsspeicher 68, 222, 223 Ausnahmeaggregation 514 Bezugsmerkmal 515 B BAPI 660 BAPI-Programmschnittstelle 38 BAPI-Schnittstelle 44 Batch-Manager 664 Benutzerkontext 63, 64, 65, 67, 73, 249 Benutzermodus 236, 255 Betriebssystemkollektor SAPOSCOL 226 Betriebssystemmonitor 226 Bewegungsdaten 686 BEx Analyzer 490 BEx Information Broadcaster 44, 478 BEx Repository Sheet 493 binäre Suche 339 binary search binäre Suche Binary Tree 341 BI-Systemlastanalyse 261 BI-Systemlastmonitor 261, 283 BI-Trace-Tool 470 Aufzeichnung von Traces 470 CAT-Tool 474 Blade-Server 565 Blade-System Blade-Server BRCONNECT 385 B-Tree 341, 342 Business Application Programming Interface 44 Business Content 36, 649 Business Explorer 43 Analyzer 43 Query Designer 43 Web Analyzer 43 Web Application Designer 43 Business Warehouse Accelerator 559 Business-Content 313 BW Accelerator Engine 564 BW Statistics 261, 519 BWA Index Maintenance Wizard 576 BWA Business Warehouse Accelerator BWA-Datenkonsistenz-Checkcenter 602 BWA-Index 560, 562 anlegen 576 ausschalten 577 Change-Run 581 Delta-Index 582 808 BWA-Index (Forts.) füllen 577, 588 Horizontale Partitionierung 561 Komprimierung 562 löschen 581 Neuaufbau 586 optimieren 582, 588 Roll-up 579 Spaltenbasierte Speicherung 561 Testwerkzeuge 591 BWA-Monitor 575 Einstellung globale Parameter 589 BW-Anwendungsanalyse 726 BW-Statistiken 739 Datenverteilung 727 InfoCube-Design 733 InfoProvider-Verteilung 728 Line-Item-Dimensionen 735 Query-Definition 736 Query-Nutzung 739 Upload-Prozesse 740 BW-Frontend-Checktool 499 BW-Performance-Review 705 BW-Anwendungsanalyse 726 Hardwareanalyse 718 Performanceüberblick 711 Softwareanalyse 707 BW-Systemlast 282 C Cache-Gültigkeit 452 Cache-Invalidierung 440 Cache-Modus 435, 459 Cache-Parameter 433 Cache-Struktur 448 Cache-Verdrängung 447 Calls 197 CAT-Tool 470, 474 CATT-Trace 474 CCMS 240 CCMS Alert-Monitor 241 Change-Log 155 Change-Run 545, 547, 548 Delta-Verfahren 550 parallel 555 Checkliste BW-Anwendungsanalyse 741 Hardware 724 Performanceüberblick 717 1182.book Seite 809 Mittwoch, 4. März 2009 6:38 18 Index Checkliste (Forts.) Softwareanalyse 710 Clustering 618 Clustering-Index 622 Index-Clustering 618 Mehrdimensionales Clustering (MDC) 619 Clustering-Index 622 Cost-based Optimizer 380, 382 CPU-Auslastung 227 CPU-Engpass 227 CPU-Kapazität 228 CPU-Zeit 253 CSV-Format 650 CUA Buffer 71 D Data Buffer 193 Data Warehouse 27, 32 Architektur 32 Frontend 35, 44 Data Warehousing Workbench 36 Data-Mart-Benchmark 99 DataMart-Interface 649 DataProvider 493 DataSource 652, 654, 656 3.x DataSource 654 7.0 DataSource 655 DataStore-Objekt 40, 636 Clustering 637 Eindeutige Datensätze 639 Eintellung der Laufzeitparameter 641 Indizierung 638 Standard-DataStore-Objekt 155 Unterdrückung Optimizer-Statistiken 640 Vermeidung der SID-Ermittlung 636 Data-Warehouse-Management 647 Datenarchivierungsprozess 399, 400, 401 Datenbank Index 35, 331 Statistik 331 Datenbankinstanz 190 Datenbankmonitor 190 Datenbankoptimierer 334, 336, 379 Cost-Based Optimizer 380 Rule-based Optimizer 380 Datenbankpuffer 191, 205 Datenbankserver 190 Datenbank-View RSDDSTAT_OLAP 278 Datenbankzeit 250, 252 Datenbewirtschaftung 647 Datenextraktion 38, 647, 649, 650, 651, 669 aus flachen Dateien 650 aus Fremdsystemen 651 aus multidimensionalen Datenbanken 650 aus relationalen Datenbanken 650 aus SAP-Systemen 649 Hauptspeicherbedarf 669 Daten-IDoc 675, 679, 696 Datenpaket 606, 666, 669, 679, 681, 682, 696 Datenpaketgröße 667, 668, 670 Pflege 670 Datenpaketnummer 661 Datenpufferqualität 195 Datentransferprozess 677 Debugging 704 Simulation 701 Datentransferprozess (DTP) 655 Datenwürfel 29, 33, 34 DB Connect 38, 650 DB_BLOCK_BUFFERS 194 DB_BLOCK_SIZE 194, 196 DB_CACHE_SIZE 194 DBA-Einplanungskalender 211, 386 DB-Laufzeit 307 DB-Parameter 211 DB-Statistiken 331, 382 Administration 384 BRCONNECT 385 DBA-Einplanungskalender 386 UPDATE STATISTICS 384, 388, 391 Debug-Optionen 462 Delta-Cache 441 Gruppierung 442 Delta-Index 582 Design Items 493 DIAG-Protokoll 491 Dialog-Workprozess 72, 73 Dimensionen-ID 348, 684 Dimensionentabelle 40, 348, 684, 686 Dispatcher 248 809 1182.book Seite 810 Mittwoch, 4. März 2009 6:38 18 Index DSO DataStore-Objekt DSO-Objekt Aktive Daten 155 Aktivierungs-Queue 155 Change-Log 155 DTP 677 E E-Faktentabelle 349, 606 EM/BLOCKSIZE_KB 76 EM/INITIAL_SIZE_MB 65, 72, 76, 218 Enqueue-Zeit 251, 252 Enterprise Core Component 25 Erst-Sizing Sizing ESM-Puffer Export/Import-Puffer ETL-Prozess 33, 647 Execution Plan Ausführungsplan Expertenmodus Benutzermodus Expert-Sizing Sizing Export/Import-Puffer 216 Export-DataSource 649 Extended Memory 218, 237 externer Modus 63 Extraktion 647, 660 Extraktionsstruktur 38, 649 Extraktor 656, 657 anwendungsspezifisch 656 anwendungsunabhängig 657 Extraktorprogramm 649 Extraktstruktur 654, 656 F Faktentabelle 40, 348, 683 E-Faktentabelle 349 F-Faktentabelle 349 Festplattenkapazität 101 F-Faktentabelle 349, 606 flacher Index 572, 588 flaches Aggregat Line-Item-Aggregat Flatfile 650, 672 Flatfile-Daten 38 Frontend-Laufzeit 309 Full Table Scan 203, 337, 363 810 G Generic Key Buffer 71 globale Benutzerübersicht 715 GUI-Zeit 250 H Hardwareanalyse 718 CPU-Auslastung 719 Datenbankperformance 721 Datenbankwachstum 722 Hardwareprofil 718 Speicherauslastung 720 Hauptindex 582 Hauptspeicher 219 Hauptspeicher-Cache 432 Heap Memory 218, 237 Hierarchie 39 Hierarchie-/Attributänderungslauf 545 Parametrisierung 547 Überwachung 549 Histogramm 381 Hit 193 Hitratio 193 I I/O-Engpass 229, 721 ICF 50 ICF-Service 51, 52 ICM 50 ICM-Monitor 53 ICM-Profilparameter 54 IDoc 679, 691 IDoc-Status 695 ILM 396 Import-/Export-Puffer 71 Index 35, 331, 335 Administration 366 B*-Tree-Index 343 Bitmap-Index 344, 353, 356 B-Tree-Index 341, 342, 352, 353 Clustering-Index 352 Encode Vector Index 351 fehlende Indizes 368 Feinanalyse Index-Qualität 378 Fragmentierung 376 Grobanalyse Index-Qualität 376 1182.book Seite 811 Mittwoch, 4. März 2009 6:38 18 Index Index (Forts.) Index-Qualität 376 Indexschema 350 Indizierungsschema 347 löschen 372 Neuaufbau 372, 378 P-Index 335, 350, 352, 608 Primärindex 335 Radix-Index 351 Reparatur 373 Sekundärindex 335 Tabellen-Index 341 überprüfen 367 Unique-Index 335 Index Full Scan 363 Index Range Scan 338, 364 Index Unique Scan 338, 364 InfoCube 29, 40 E-Faktentabelle 606 F-Faktentabelle 606 Komprimierung 605, 607 Partitionierung 609 providerspezifische Eigenschaften 632 Info-IDoc 660, 675, 679, 690, 694 Info-IDoc-Status 694, 695 InfoObject 39 InfoPackage 655 InfoProvider 40 Information Lifecycle Management 396 InfoSet 40, 41 InfoSpoke 649 Intermediate Document 660, 691 interner Modus 63 Internet Communication Framework 50 Internet Communication Manager 50 Internet-Communication-FrameworkService 51 J J2EE-Applikationsserver 48 Java Database Dictionary 49 K Kardinalität 344, 353 Kennzahl 39 Kommunikationsschnittstellen 647, 648 Kommunikationsstruktur 654 Kommunikationstechniken 657 Komprimierung 605, 607 Kontextwechsel 64, 65 L Lade-Request 689, 690 Gesamtstatus 692 Kopfdaten 689 Statusinformationen 691 Ladezeit 249 Leaf-Block 344 Leaf-Row 344 Lesemodus 454 Line-Item-Aggregat 517 Line-Item-Dimension 127, 353, 517 Local Memory 62 Log Buffer 196 Logical Unit of Work 659 logischer Index BWA-Index Long table scans 203 LUW Logical Unit of Work M MDC-Dimension 619, 620, 622, 623 MDX 44, 428 MDX-Prozessor 429 Memory/Disk Sort 204 Memory-Management-Monitor 68 Merkmal 39, 41 Metadaten 42 Management 42 Metadaten-Repository 42 Mixed-Load-Benchmark 101 Moduskontext 63 Monitoring 688 Datenextraktion 689 Datentransferprozesse (DTP) 698 Multidimensional Expression 44, 428 multidimensionale Datenhaltung 29 MultiProvider 40, 41, 480, 632 feste Adressierung von InfoProvidern 486 heterogene 168 heterogene MultiProvider 482 homogene MultiProvider 167, 481 MultiProvider-Queries analysieren 483 parallele Verarbeitung 482 811 1182.book Seite 812 Mittwoch, 4. März 2009 6:38 18 Index MultiProvider (Forts.) Selektion durch Festwerte 487 Selektion durch Kennzahlen 486 Selektion durch OLAP-Hints 488 sequentielle Verarbeitung 483 MultiProvider-Partitionierung 632 N Nametab-Puffer 70 Nearline-Speicherung 396, 398 Nicht-Dialog-Workprozess 72, 73 NLS-API 396 Normalform 32 Nummernkreis 684 Nummernkreisobjekt 684 Nummernkreispuffer 684 O ODBO 428 ODBO-Schnittstelle 44 OLAP 29, 31 Datenhaltung 29 OLAP-Cache 306, 308, 309 OLAP-Laufzeit 309 OLAP-Prozessor 281 OLAP-BAPI 44, 428 OLAP-Cache 431, 433 Cache-Gültigkeit 452 Cache-Invalidierung 440 Cache-Modus 435 Cache-Parameter 433 Cache-Struktur 448 Cache-Verdrängung 447 Delta-Cache 441 globaler Cache 431 Hauptspeicher-Cache 432 lokaler Cache 431 OLAP-Cache-Monitor 444 Persistenter Cache 434 Persistenz-Modus 436 OLAP-Cache-Monitor 444 OLAP-Hints 488 OLAP-Prozessor 427, 429 OLAP-System 31, 32 OLE DB for OLAP 44 OLE DB für OLAP ODBO OLTP 31 812 OLTP-System 31, 32 Online Analytical Processing OLAP Online Transaction Processing 31 Open Analysis Interface 428 Open Hub Destination 649 Open Hub Service 649 Open SQL 49 Open SQL for Java 49 Optimierungsmodus 460 P Page-Speicher 237 Paging Area 217 Paging-Datei Auslagerungsspeicher Parses 198 Partitionierung 34, 167, 356, 609 auf Applikationsebene 167, 631 auf Datenbankebene 610 Clustering 618 E-Faktentabelle 613 Einstellung 614 Einstellung der Datenverteilung 633 F-Faktentabelle 611 logische 34 logische Partitionierung 631 Maximalzahl an Partitionen 615 Partition 34 Partitionierungsmerkmal 610, 632 Partitionierungsschema 613, 617, 624 physiche Partitionierung 34 Range-Partitionierung 610, 611 von Aggregaten 617 Partitionierungsmerkmal 355 Performanceüberblick 711 ABAP-Laufzeitfehler (Dumps) 714 Allgemeine Systemlast 711 Benutzeranzahl 715 BW-Systemlast 712 Persistent Staging Area (PSA) 41, 655, 660, 679 Persistenter Cache 434 Persistenz-Modus 436 PGA Program Global Area Physical Reads 193 physischer Index BWA-Index P-Index 608 Plug-in 649 Primärindex 335 1182.book Seite 813 Mittwoch, 4. März 2009 6:38 18 Index privater Speicher 65 PRIV-Mode 66, 73 Processing-Zeit 253 Program Global Area 192, 204 Sort Buffer 193 Programm-Puffer 71, 215 PSA 41, 660, 681, 696 Verarbeitungsoptionen 680 PSAPTEMP 208 PSA-Tabellen 644, 661 Löschen von Requests 644 Partitionierung 645 Q qRFC queued RFC Quellsystem-Typen 648 Query-Eigenschaften 453 Query-Monitor 336, 360, 383, 452, 462, 525 Cache-Modus 459 Debug-Optionen 462, 525 Lesemodus 454 MultiProvider-Queries analysieren 483 Optimierungsmodus 460 Performance-Informationen 466 Query-Eigenschaften 453 Request-Status 461 technische Informationen 467 queued RFC 659 R Range-Partitionierung 610 RDISP/PG_MAXFS 70 RDISP/PG_SHM 70 RDISP/ROLL_MAXFS 76 RDISP/ROLL_SHM 76, 218 Reads 193 Rechner 189 Redo Log Buffer 196 Remote Function Call RFC Repartitionierung 623, 625 Monitoring 629 vollständige Repartitionierung 625 von Aggregaten 629 Zusammenfassen und Anhängen von Partitionen 628 Reportingperformance 427 Repository-Puffer 70 Request 539 Request-ID 533, 534, 536, 538, 605, 661, 689 Request-Status 461 Re-Sizing Sizing RFC 657, 679 asynchroner RFC 658 queued RFC 659 synchroner RFC 658 transaktionaler RFC 659 Roll Area 217 Roll-back 197 Roll-in 65, 252 Roll-out 65, 252 Roll-Speicher 218, 237 Roll-up 532, 537 automatisch 538 manuell 538 überwachen 543 Roll-up-Hierarchie 539, 540 Roll-up-Job 543 Root-Block 344 Roundtrip 250, 491 RSDDSTAT_DM 306 RSDDSTAT_OLAP 278, 306 RSMO-Monitor 689 Rule-based Optimizer 380 S SAP Application Performance Standard (SAPS) 99 SAP BW Reporting Agent 478 SAP ECC 6.0 25 SAP Executable Buffer Programm-Puffer SAP Extended Memory 63, 65 SAP GoingLive Check 88 SAP GUI 47 SAP Heap Memory 65, 67, 71 SAP NetWeaver Application Server 47, 48 SAP NetWeaver Application Server ABAP 49 SAP NetWeaver Application Server Java 49 SAP Paging Memory 70 SAP Quick Sizer 87, 88 813 1182.book Seite 814 Mittwoch, 4. März 2009 6:38 18 Index SAP Roll Memory 63, 71 SAP Service Marketplace 87, 88, 98 SAP Solution Manager 243 SAP Special Expertise Partner 569 SAP-Enqueues 251 SAP-Erweiterungsspeicher 63, 65, 71, 72, 73 SAP-GUI-Puffer 71 SAP-Instanz 189 SAP-Kalenderpuffer 71 SAP-Memory-Management-Monitor 212, 218, 219 SAP-Memory-Managementsystem 71 SAP-Paging Memory 223 SAP-Performancemonitor 187 SAP-Profilparameter 69, 75, 77 SAP-Puffer 70, 214 SAP-Pufferqualität 214 Hitratio 214 SAP-Rollbereich 63, 64 globaler SAP-Rollbereich 64 lokaler SAP-Rollbereich 64 SAP-Rolldatei 64 SAP-Speicherbereiche 61, 69, 212, 217 SAP-Speichermanagement 63 SAP-Systemlastanalyse 247, 257 SAP-Workprozess 231 SAP-Workprozess-Monitor 233 SAP-Workprozess-Typen 232, 257 Screen Buffer 71 Sekundärindex 335 Selektionsschema 401 Semantische Gruppe 402 Server-Blade Blade-Server Service Packages 706 Service-Ingenieur-Modus Benutzermodus SGA System Global Area Shared Buffer 71 Shared Memory 62 Shared Pool 195, 198 SHARED_POOL_SIZE 195, 197 Short table scans 203 SID-Schlüssel 348, 687 SID-Tabelle 686, 687 Simple Object Access Protocol 651 Single Record TableBuffer 71 Sizing 82, 108 Advanced Sizing 84 Datenwachstum 103 814 Sizing (Forts.) Delta-Sizing 85 Dimensionentabellen 101 Erst-Sizing 84 Expert-Sizing 84 Faktentabelle 102 Festplattenkapazität 101 InfoCubes 101 Re-Sizing 85 SAP GoingLive Check 88 SAP Quick Sizer 87 Sizing-Prozess 87 Upgrade-Sizing 85 SOAP Simple Object Access Protocol Softwareanalyse 707 SAP NetWeaver BW 708 SAP-Frontend 708 SP-Stack Support Package Stack Stammdaten 39, 41, 686 Star-Schema 40, 347 Suchalgorithmus binäre Suche Support Package 55, 57 Support Package Manager 58 Support Package Stack 57, 58 Swapping 68 Swaps 215 Swap-Space Auslagerungsspeicher synchroner RFC 658 System Global Area 191, 204 Data Buffer 192 Java Pool 192 Large Pool 192 Log Buffer 192 Redo Buffer 192 Shared Pool 192 Streams Pool 192 Systemlastmonitor 253, 254, 255, 258, 281 T Tabellen-Puffer 71 Table Scan 203 Technischer Content 312, 591 Übernahme des Technischen Contents 322 Text 39 Text Retrieval and Information Extraction TREX transaktionaler RFC 659 1182.book Seite 815 Mittwoch, 4. März 2009 6:38 18 Index Transfermethoden 679 IDoc 679 PSA 679, 680 Transformation 647 TREX 563 Revision 565 tRFC 659, 679 W U XML for Analysis 44, 428 XML/A 428 XML/A-Schnittstelle 44 XML-Daten 38, 651 Übertragungsregeln 654 Übertragungstechniken 647, 659, 660 Application Link Enabling 659 Intermediate Document 660 UD Connect 38, 650 UNION-Operation 41 Unique-Index 335 V Verbuchungssimulation 701 VirtualProvider 40, 41 virtueller Speicher 62 Workload-Kollektor-Datenbank 256 Workprozess SAP-Workprozess 231 Workprozess-Monitor 233 X Z Zeitscheibenarchivierung 401 zentraler Überwachungsmonitor CCMS Zero Administration Memory Management 75 ZTTA/ROLL_AREA 64, 74, 76 ZTTA/ROLL_EXTENSION 76 ZTTA/ROLL_FIRST 76 815
