SAP NetWeaver BW – Performanceoptimierung
Werbung
In diesem Kapitel finden Sie Informationen zur systematischen Analyse von Datenbank, Speicher und Hardware in SAP-Systemen. Sie lernen Methoden der Überwachung von Datenbank- und Speicherparametern sowie Möglichkeiten zur Identifizierung von Performanceproblemen kennen. 7 Analyse von Datenbank, Speicher und Hardware Der Schwerpunkt dieses Kapitels liegt auf der Systemanalyse von Performanceparametern, die Ihnen Hinweise auf kritische Zustände des Gesamtsystems geben sollen. Hierzu zählen insbesondere die Analyse der dem SAP-System zugrunde liegenden Datenbank, des Speichers und der Hardware. Die Analyse dieser Bereiche gibt Ihnen Aufschluss darüber, wie Ihr BW-System die verfügbaren Speicher-, Datenbank- und Hardwareressourcen nutzt und an welchen Stellen eventuell Ressourcenengpässe auftreten können. Von der Systemanalyse ist die Applikationsanalyse zu differenzieren, die Ihnen Hinweise zur Performance Ihrer analytischen Anwendungen gibt. Analysen in diesem Bereich haben immer eine bestimmte Applikation zum Inhalt, z.B. eine Query, eine Planungsanwendung oder ein ABAP-Programm, um Informationen über Laufzeit und Durchsatz zu gewinnen. Detaillierte Informationen zu Analysewerkzeugen und Vorgehensweisen für die Applikationsanalyse finden Sie in Kapitel 8, »Analyse der Systemlast«. Da sich die Nutzung eines BW-Systems hinsichtlich Speicher- und Datenbanknutzung von dem Auslastungsprofil eines OLTP-Systems (SAP ERP) unterscheidet, werden in diesem Kapitel, wo immer es möglich ist, Hinweise gegeben, wie ein BW-System bezüglich Speicher-, Datenbank- und Hardwareressourcen zu parametrisieren ist. Die hier angegebenen Werte können dabei aber nur grobe Richtwerte sein und sollten als initiale Einstellungen vor Produktivstart verstanden werden. Die Parametrisierung Ihres Systems sollte nach Produktivstart gegebenenfalls korrigiert und an die tatsächlichen Anforderungen angepasst werden. 273 7 Analyse von Datenbank, Speicher und Hardware Insbesondere ersetzen die hier beschriebenen Systemwerte nicht die Serviceleistungen des SAP-Supports, wie z.B. den SAP GoingLive Check oder den EarlyWatch-Alert-Service für BW-Systeme. Zur besseren Orientierung unterscheiden wir bei den Möglichkeiten der Analyse Ihres SAP NetWeaver BW-Systems zwei Anwendungsbereiche: 왘 Der eine Anwendungsbereich hat die fallweise Analyse von Performanceproblemen zur Identifizierung von Ursachen für Performanceengpässe im Fokus. Hierzu gibt es eine Reihe von SAP-Performanceanalysewerkzeugen, die Sie in der Analyse von verschiedenen Bereichen Ihres SAP NetWeaver BW-Systems unterstützen, wie z.B. Speicher- oder CPU-Auslastung. 왘 Darüber hinaus unterstützt SAP NetWeaver das Monitoring Ihrer BW-Applikationen und die regelmäßige und kontinuierliche Systemüberwachung. Die Systemüberwachung prüft die Verfügbarkeit und Performance aller Komponenten. Im Fall von Fehlern oder Abweichungen wird ein Alarm ausgelöst. Die Werkzeuge zur Einrichtung der kontinuierlichen Systemüberwachung werden ebenfalls in diesem Kapitel vorgestellt. 7.1 Allgemeine Datenbankaspekte in SAP NetWeaver BW Bevor die Werkzeuge zur Analyse der Datenbank- und Hardwareperformance vorgestellt werden, werden Ihnen zunächst einige Besonderheiten datenbankbezogener Performanceaspekte in SAP NetWeaver Business Warehouse (BW) vermittelt, um die Analyseaktivitäten auf die wichtigsten BW-Objekte zu lenken. Dazu zählen unter anderem die wichtigsten BW-Tabellentypen, temporäre Tabellen zur Zwischenspeicherung von Ergebnissen, das Indexschema in SAP NetWeaver BW sowie der Star-Transformation-Join, eine für Querys auf Oracle-Datenbanken typische Join-Operation. 7.1.1 Namenskonventionen BW-Tabellentypen Bei der Analyse von Datenbankproblemen in SAP NetWeaver BW sollten Sie zunächst die Analyseaktivitäten auf die wichtigsten performancerelevanten BW-Tabellentypen richten. Tabelle 7.1 zeigt die Namenskonvention der Tabellentypen in SAP NetWeaver BW. 274 Allgemeine Datenbankaspekte in SAP NetWeaver BW 7.1 BW-Bereich Tabellentyp Namenskonvention SAP-Content Namenskonvention Kunden-Content InfoCubes (relational) F-Faktentabellen /BI0/F<Cube> /BIC/F<Cube> E-Faktentabellen /BI0/E<Cube> /BIC/E<Cube> Fact View BW ≤ 3.5; UNION ALLView (über E- und F-Faktentabelle): BW ≤ 3.5; UNION ALLView (über E- und F-Faktentabelle): /BI0/V<Cube> /BIC/V<Cube> Dimensionstabellen /BI0/D<Cube> /BIC/D<Cube> InfoCubes (HANAoptimiert) Faktentabelle /BI0/F<Cube> /BIC/F<Cube> Dimensionstabelle (Paket) /BI0/D0<Cube>P /BIC/D<Cube>P Gültigkeitstabelle (nur gültig bei Bestands-InfoCubes) /BI0/L0<Cube> /BIC/L<Cube> Aggregate Aggregattabellen F-Faktentabellen – /BIC/F1* Aggregattabellen E-Faktentabellen – /BIC/E1* Aggregate zu Dimensionstabellen – /BIC/D1* SID-Tabellen /BI0/S<Merkmal> /BIC/S<Merkmal> SID-Tabellen (Navigationsattribute, zeitunabhängig) /BI0/X<Merkmal> /BIC/X<Merkmal> SID-Tabellen (Navigationsattribute, zeitabhängig) /BI0/Y<Merkmal> /BIC/Y<Merkmal> Attribute (zeitunabhängig) /BI0/P<Merkmal> /BIC/P<Merkmal> Attribute (zeitabhängig) /BI0/Q<Merkmal> /BIC/Q<Merkmal> Hierarchien /BI0/H<Merkmal> /BIC/H<Merkmal> Texte /BI0/T<Merkmal> /BIC/T<Merkmal> DataStoreChange-Log Objekt (DSO) DSO aktive Daten und Change-Log DSO neue Daten (relational) /BI0/B0000* /BIC/B0000* /BI0/A<Name>0 /BIC/A<Name>0 /BI0/A<Name>40 /BIC/A<Name>40 DSO und Change-Log (HANAoptimiert) aktive Daten /BI0/A0<Name>00 /BIC/A<Name>00 neue Daten /BI0/A0<Name>40 /BIC/A<Name>40 Change-Log-DataSource 80<Name> 8<Name> Delta-Index /BI0/A0<Name>70 /BIC/A<Name>70 History-Index /BI0/A0<Name>80 /BIC/A<Name>80 Stammdaten Tabelle 7.1 Übersicht über Tabellentypen in SAP NetWeaver BW 275 7 Analyse von Datenbank, Speicher und Hardware BW-Bereich Tabellentyp Namenskonvention SAP-Content Namenskonvention Kunden-Content PSA PSA-Tabellen /BIC/B0000* Temporäre Tabellen Query-Zwischenergebnisse /BI0/01* (werden einmalig verwendet und nach Verwendung automatisch gelöscht) – Hierarchie-Zwischenergeb- /BI0/02* nisse (werden mitsamt ihrem Inhalt wiederverwendet) – Query-Views (nur bis Release SAP BW 3.x gültig) /BI0/03* – Query-Zwischenergebnisse (werden wiederverwendet, aber nicht aus dem ABAP Dictionary gelöscht) /BI0/06* – /BI0/0P* materialisierte Teilergebnisse von komplexen Querys – /BI0/0D* Open Hub (enthalten gespeicherte Ergebnisse aus Open-Hub-Lesevorgängen) – Tabelle 7.1 Übersicht über Tabellentypen in SAP NetWeaver BW (Forts.) 7.1.2 Indextypen und Namenskonventionen Indextypen in SAP NetWeaver BW Die wichtigsten Tabellentypen in SAP NetWeaver BW werden standardmäßig mit Indizes bei der Anlage der BW-Objekte erstellt. Tabelle 7.2 gibt einen Überblick über die wichtigsten Indextypen. Ausführliche Informationen zur Administration und Analyse von Indizes in SAP NetWeaver BW finden Sie in Kapitel 9, »Indizes und Datenbankstatistiken«. Tabellentyp Indextyp Namenskonvention F-Faktentabelle 1. Normale Cubes: Bitmap-Indizes (non-unique) auf jeder Dimensionsspalte zur Query-Unterstützung KEY_<cube><suffix>, Indizes 010, 020 etc. 2. Ausnahme: B-Tree-Indizes (nonunique) für »High Cardinality«Dimensionsspalten Tabelle 7.2 Übersicht über Indextypen in SAP NetWeaver BW 276 Allgemeine Datenbankaspekte in SAP NetWeaver BW Tabellentyp Indextyp Namenskonvention 1. Realtimefähiger InfoCube: BTree-Indizes (non-unique) auf jeder Dimensionsspalte KEY_<cube><suffix>, Indizes 010, 020 etc. 2. B-Tree-Typ ist nötig zur besseren Unterstützung paralleler Schreibund Lesezugriffe. E-Faktentabelle Bitmap-Indizes (non-unique) auf jeder Dimensionsspalte zur QueryUnterstützung KEY_<cube><suffix>, Indizes 010, 020 etc. 1. B-Tree-Index (non-unique) über P-Index alle Dimensionsspalten zur Unterstützung der Komprimierung 2. Ausnahme: B-Tree-Indizes (nonunique) für »High Cardinality«Dimensionsspalten Dimensions- B-Tree-Index (unique) auf DIM-IDtabellen Spalte Index 0 B-Tree-Index (non-unique) über alle Index 010 SID-Spalten SID-Tabellen B-Tree-Index (unique) auf Merkmalsspalte SIDTabellen (Navigationsattribute) /BIC/<merkmal>, Index 0 B-Tree-Index (unique) auf SIDSpalte Index 001 B-Tree-Index (unique) auf SID- und OBJVERS-Spalte Index 0 Optional: weitere Indizes auf Merkmalsspalten Tabelle 7.2 Übersicht über Indextypen in SAP NetWeaver BW (Forts.) 7.1.3 Star-Transformation Die Star-Transformation ist eine Join-Operation auf Oracle-Datenbanken, die von vielen Querys beim Zugriff auf InfoCubes genutzt wird. Durch die Star-Transformation werden Abfragen mit Selektionen über mehrere Dimensionen ausgeführt. Dabei werden zunächst die Einschränkungen auf den Dimensionstabellen durch den Query Optimizer evaluiert und kombiniert, bevor dann auf die meist sehr große Faktentabelle zugegriffen wird, um darin relativ schnell die passenden Datensätze zu finden. Voraussetzung dafür sind BitmapIndizes auf allen Fremdschlüsselattributen der Faktentabelle. 277 7.1 7 Analyse von Datenbank, Speicher und Hardware Weitere Informationen Weitere Informationen zu den Star-Transformationen finden Sie in Abschnitt 9.6.2, »Indizes aufbauen«. Ausführungsplan Der Ausführungsplan einer Star-Transformation mit Bitmap-Index ist in Abbildung 7.1 vereinfacht dargestellt. TABLE ACCESS BY LOCAL INDEX ROWID (Fact Table) BITMAP CONVERSION TO ROWIDs BITMAP AND BITMAP MERGE BITMAP KEY ITERATION BUFFER SORT TABLE ACCESS FULL (Dimension Table) BITMAP INDEX RANGE SCAN (Fact Table Index) BITMAP MERGE BITMAP KEY ITERATION BUFFER SORT TABLE ACCESS FULL (Dimension Table) BITMAP INDEX RANGE SCAN (Fact Table Index) Abbildung 7.1 Star-Transformation im Ausführungsplan Die einzelnen Schritte werden dabei wie folgt durchlaufen: 1. Zunächst werden die passenden Dimensionsdatensätze anhand der Selektionsbedingungen in den Dimensionstabellen gelesen 1. 2. Anschließend wird mit den passenden Dimensionsdatensätzen auf die Bitmap-Indizes der Fremdschlüssel der Faktentabelle zugegriffen 2. 3. Außerdem werden die Bitmaps der korrespondierenden Faktentabellen-Datensätze ermittelt 3. 4. Dann werden die Bitmaps mit den passenden FaktentabellenDatensätzen aller im Rahmen der Star-Transformation enthaltenen Dimensionstabellen verknüpft 4. 5. Es folgt die Umwandlung der Bitmaps in ROWIDs 5. 278 Übersicht SAP-Performanceanalysewerkzeuge 6. Im letzten Schritt werden anhand der ROWIDs die passenden Datensätze aus der Faktentabelle gelesen 6. Oracle bestimmt die im Rahmen einer Star-Transformation verwendeten Dimensionen automatisch. Dabei werden die Dimensionen mit der höchsten erwarteten Selektivität genutzt, sodass die Treffermenge auf der Faktentabelle möglichst klein ist. Die zentrale Voraussetzung für die Durchführung der Star-Transformation sind Bitmap-Indizes auf der Faktentabelle. Liegen keine Bitmap-Indizes vor, kann keine Star-Transformation ausgeführt werden. Dies ist dann der Fall, wenn B-Tree- statt Bitmap-Indizes angelegt sind, z.B. bei der Definition von »High Cardinality«-Dimensionen oder in Realtime-InfoCubes, in denen die Indizes der F-Faktentabellen generell als B-Tree-Indizes angelegt werden (Vermeidung potenzieller Deadlocks bei parallelen Updates von realtimefähigen InfoCubes). Nur auf den E-Faktentabellen werden Bitmap-Indizes verwendet. 7.2 Bitmap-Indizes Übersicht SAP-Performanceanalysewerkzeuge Die in diesem Kapitel vorgestellten Werkzeuge zur Performanceanalyse sind Bestandteil der SAP-Performancemonitore. Für die Überwachung und Performanceanalyse umfasst das SAP-Basis-System eine Reihe von Monitoring- und Analyseprogrammen, die ständig durch SAP weiterentwickelt werden. Die Monitoring-Werkzeuge zur Performanceanalyse können Sie mit Transaktion STUN aufrufen. Tabelle 7.3 gibt Ihnen einen Überblick über die wichtigsten Monitore zur Basis- und Anwendungsanalyse. Anwendungs- Monitor/Werkzeug Beschreibung bereich (Transaktion) Datenbank Performance (ST04) 왘 Auslastung der Datenbankpuffer 왘 Datenbanksperren und Wartesituationen 왘 Schreib- und Lesezugriffe auf die Festplatten 왘 Überwachung von SQLAnweisungen Tabelle 7.3 Übersicht über SAP-Performancemonitore 279 Monitore 7.2 7 Analyse von Datenbank, Speicher und Hardware Anwendungs- Monitor/Werkzeug Beschreibung bereich (Transaktion) Datenbankmonitor (DB02) 왘 allgemeine Performanceanalyse 왘 Plattenkapazität der Datenbank 왘 Planung und Überwachung von Jobs 왘 Diagnosewerkzeuge für fehlende Tabellen und Indizes Speicher Datenbank-Parametereinstellungen (DB03) Überwachung der Änderung von Datenbankparametern DBA-Einplanungskalender (DB13) Einplanung von Datenbankaktionen SAP-Speicherkonfigurationsmonitor (ST02) Auslastung der SAP-Puffer und weiterer Speicherbereiche Betriebssystemmonitor (ST06) 왘 Auslastung des physischen Hauptspeichers 왘 Monitoring Paging 24-h-Profil Hardware (CPU und Platten) Betriebssystemmonitor (ST06) 왘 Auslastung der CPU 왘 Festplattenzugriffszeiten 왘 Netzwerk 왘 24-h-Profil für CPU, Speicher, Swap Space, Festplattenzugriffszeiten, Netzwerk Prozesse, Workprozess-ÜberBenutzer und sicht lokal (SM50) Anwendungen Workprozess-Übersicht global (SM66) Auslastung der SAP-Workprozesse globale Workprozess-Übersicht SAP-Instanzen (SM51) Übersicht SAP-Instanzen (SAP-Server) Benutzerliste lokal (SM04) Übersicht Benutzer Benutzerliste global (AL08) Liste aller angemeldeten Anwender nach Anzahl aktiver Anwender, interaktiver Anwender und RFCAnwender Tabelle 7.3 Übersicht über SAP-Performancemonitore (Forts.) 280 Analyse der Datenbank Anwendungs- Monitor/Werkzeug Beschreibung bereich (Transaktion) Prozesse, Workload-Monitor Benutzer und (ST03, ST03N, Anwendungen ST03G) Übersicht über Lastverteilung im SAP- und BW-System zur Analyse von Transaktionen, Programmen, Benutzern und BW-Systemlast durch Lade- und Leseprozesse Workload-Monitor Analyse und Identifikation von für Einzelsatzstatistik Prozessen und Usern mit hoher (STAD, STATTRACE) Systemlast Anwendungsmonitor Benutzerverteilung (ST07) Überwachung des Ressourcenverbrauchs und der Benutzer nach SAP-Modulen Analyse- und Sammlung verschiedener Tools für Service-Tools (ST13) Analyse von Business-Applikationen (z.B. SEM-BPS, BI-IP und SEM-BCS) Anwendungsanalyse (ST14) Monitoring und Analyse von Business-Applikationen für SEM, BW, Basis und Security Performanceanalyse- Analysen für SQL-, Enqueue-, RFCTraces (ST05) und Tabellenpuffer-Trace Laufzeitanalyse (SE30) Laufzeitanalyse für Transaktionen, Programme, Funktionsbausteine Tabelle 7.3 Übersicht über SAP-Performancemonitore (Forts.) In den folgenden Ausführungen werden die wichtigsten SAP-Analysewerkzeuge für die Performanceanalyse erklärt. 7.3 Analyse der Datenbank Bevor wir die Verwendung der Werkzeuge zur Analyse von Datenbankparametern und Performance der Datenbank beschreiben, müssen zunächst die in diesem Zusammenhang verwendeten Begriffe erläutert werden. 7.3.1 Begriffserklärungen Die Begriffe Rechner, Applikationsserver, Datenbankserver, SAPInstanz und Datenbankinstanz werden in diesem Buch wie folgt verwendet: 281 7.3 7 Analyse von Datenbank, Speicher und Hardware 왘 Ein Rechner ist eine physische Maschine (= physische Hardware) mit CPU, Hauptspeicher, IP-Adresse etc. 왘 Ein Applikationsserver ist ein Rechner, auf dem eine oder mehrere SAP-Instanzen laufen. 왘 Eine SAP-Instanz oder SAP-Applikationsinstanz ist eine abgeschlossene administrative Einheit auf einem Rechner, bestehend aus Workprozessen, Dispatcher zur Verwaltung der Workprozesse und SAP-Puffern im Shared Memory des Rechners, auf die Workprozesse zugreifen. Die SAP-Instanz kann eine ABAP- oder JavaApplikationsinstanz (SAP-J2EE-Engine) sein. Es können mehrere SAP-Instanzen auf einem physischen Rechner installiert sein. Jede SAP-Instanz hat einen eigenen Dispatcher, Workprozesse und Speicherbereiche (Puffer). 왘 Ein Datenbankserver ist ein Rechner, auf dem eine oder mehrere Datenbankinstanzen laufen. 왘 Die Datenbank ist die physische Datenbasis, z.B. in Form von Dateien und Tabellen. In den nachfolgenden Ausführungen soll zwischen relationalen Datenbanksystemen und In-MemoryDatenbanken, z.B. SAP HANA, differenziert werden. Als relationales Datenbanksystem werden hier solche Datenbanken bezeichnet, deren Daten in relationalen Tabellen und Dateien in einem Plattensystem gespeichert werden. In-Memory-Datenbanksysteme wie SAP HANA sind streng genommen auch relationale Datenbanksysteme, speichern die Daten aber im Hauptspeicher (RAM) des Datenbankservers sowie in einem Dateisystem. 왘 Eine Datenbankinstanz ist eine abgeschlossene administrative Einheit auf einem Rechner, bestehend aus Datenbankprozessen und Datenbankpuffern im Shared Memory des Rechners, die den Zugriff auf eine Datenbank ermöglicht. Als Datenbankserver wird der Rechner bezeichnet, auf dem eine oder mehrere Datenbankinstanzen laufen. Datenbank- und SAP-Instanz können auch parallel auf einem Rechner laufen. In der Regel läuft im SAP-Umfeld auf einer Datenbank nur eine Datenbankinstanz. Auf ein Datenbanksystem können auch mehrere Datenbankinstanzen zugreifen (parallele Datenbanksysteme). Unterstützte Datenbanken SAP NetWeaver BW ist auf verschiedenen relationalen Datenbanksystemen lauffähig (Informationen zu SAP NetWeaver BW auf SAP HANA als In-Memory-Datenbank finden Sie in Kapitel 3, »Einführung in das 282 Analyse der Datenbank In-Memory-Computing mit SAP HANA«, Kapitel 16, »Architektur von SAP HANA«, und Kapitel 17, »SAP NetWeaver BW auf SAP HANA«). Insgesamt werden von SAP NetWeaver BW zurzeit acht relationale Datenbanksysteme unterstützt (Stand Dezember 2012): 왘 Oracle (siehe auch SAP-Hinweis 1547947) 왘 Microsoft SQL Server 2008 왘 Microsoft SQL Server 2012 (siehe auch SAP-Hinweis 1651862) 왘 SAP MaxDB (vormals SAP DB) 왘 IBM DB2 왘 IBM DB2 für z/OS 왘 IBM DB2 für Linux, UNIX und Windows 왘 Sybase ASE Aktuelle Informationen zu den unterstützten Datenbanken Die jeweils aktuell von SAP NetWeaver BW unterstützten Datenbankversionen können Sie der Product Availability Matrix (PAM) im SAP Support Portal unter der URL https://websmp104.sap-ag.de/pam entnehmen (S-User erforderlich). Auch wenn die Architektur der Datenbanksysteme unterschiedlich ist, verfügt das dem BW-System zugrunde liegende SAP-System über einen zentralen Datenbankmonitor, der die Analyse von Performancedaten des basierenden Datenbanksystems ermöglicht. Der Datenbankmonitor greift dabei zum einen auf Performancedaten zurück, die das Datenbanksystem erstellt und die auch über die datenbankeigenen Monitoring-Werkzeuge zugänglich sind. Zum anderen wird ein Teil der Performancedaten direkt vom SAP-System gesammelt. Sie können den Datenbankmonitor mit Transaktion DBACOCKPIT aufrufen. Das DBA Cockpit ist der zentrale Einstiegspunkt für die Administration, Konfiguration und das Monitoring der Datenbank und wurde mit SAP NetWeaver 7.0 SP12 grundlegend überarbeitet. Es setzt sich aus den folgenden drei Bereichen zusammen: 왘 Die Auswahl des Systems und der korrespondierenden Datenbanksysteme erfolgt im oberen linken Menübereich (1 in Abbildung 7.2). Sie können hier mehrere Systeme und Datenbanken verwalten. 283 DBA Cockpit 7.3 7 Analyse von Datenbank, Speicher und Hardware 왘 Darunter finden Sie das Navigationsmenü für die Auswahl der verschiedenen Administrationsfunktionen 2. 왘 Der eigentliche Analysemonitor zur Anzeige der Inhalte und Ergebnisse befindet sich im rechten Bildschirmbereich 3. Abbildung 7.2 DBA Cockpit (Pflege Systemkonfiguration) Transaktionscodes Das DBA Cockpit vereint verschiedene Monitoring- und Administrationswerkzeuge. Die Transaktionscodes, mit denen diese Werkzeuge aufgerufen wurden, verzweigen nun zu den einzelnen Funktionen im DBA Cockpit im Navigationsmenü: 왘 Datenbankperformance (ST04) 왘 Datenmanagement/Space Overview (DB02) 왘 Datenbanksperren (DB01) 왘 Sicherungsprotokolle/Backup-Logs (DB12) 왘 DBA-Einplanungskalender (DB13, DB13C) 왘 Datenbankjobs (DB24) Die aufgeführten Funktionen könen direkt im DBA Cockpit aufgerufen werden, die Transaktionscodes sind aber nach wie vor verfügbar. Die nachfolgende Erklärung der Speicherbereiche erfolgt am Beispiel eines Oracle-Datenbanksystems; die Begrifflichkeiten können für andere Datenbanksysteme differieren. DBA Cockpit für Oracle Weitere Informationen zum DBA Cockpit für ein Oracle-Datenbanksystem finden Sie in SAP-Hinweis 1028624. 284 Analyse der Datenbank 7.3.2 7.3 Speicherbereiche der Datenbank Die Analyse der Datenbankpuffer rufen Sie im DBA Cockpit mit dem Menüpunkt Performance Overview (siehe Abbildung 7.3) auf. Abbildung 7.3 Analyse der Datenbankpuffer (Performance Overview) Datenbankpuffer sind Bereiche im Hauptspeicher, in denen bereits selektierte Daten (Tabelleninhalte, Indizes etc.) vorgehalten werden. Bei erneutem Zugriff auf diese Daten müssen diese nicht mehr vom Plattensystem gelesen werden, sondern können aus dem Datenbankpuffer abgerufen werden. Die Datenbankpuffer reduzieren somit die erforderlichen Plattenzugriffe und beschleunigen den Datenzugriff, da der Zugriff auf ein im Hauptspeicher persistiertes Objekt ca. zehn bis 100 Mal schneller ist als ein Lesezugriff auf das Plattensystem des Datenbankservers. Die Bezeichnungen der Puffer eines Datenbanksystems differieren je nach Hersteller. Die im Folgenden beschriebenen Speicherbereiche sind am Beispiel des Datenbanksystems Oracle erklärt. Im OracleDatenbanksystem wird unterschieden zwischen Shared Memory – also einem Speicherbereich, der von allen Oracle-Prozessen angesprochen werden kann – und prozesslokalem Speicher, der jeweils genau einem Prozess zugeordnet ist. 285 Datenbankpuffer 7 Analyse von Datenbank, Speicher und Hardware System Global Area (SGA) Die System Global Area (SGA) ist ein Speicherbereich im Shared Memory, der beim Start der Datenbankinstanz im Hauptspeicher des Datenbankservers allokiert wird. Die wichtigsten Speicherbereiche der SGA sind: 왘 der Data Buffer (auch als Buffer Pool oder Data Cache bezeichnet), in dem die Datenblöcke gepuffert werden 왘 der Shared Pool (auch als Shared SQL Area, Shared Cursor Cache oder Library Cache bezeichnet), in dem geparste SQL-Statements und Oracle-DDIC-Informationen gespeichert werden 왘 Java Pool, ein spezieller Pufferbereich für Java-Programme 왘 Large Pool, ein Puffer für spezielle Daten (z.B. bei Verwendung eines Multi-Threaded Servers, des Recovery Managers (RMAN) mit mehreren I/O-Slaves oder Aktivierung von PARALLEL_ AUTOMATIC_TUNING) 왘 Streams Pool (für Oracle ≥ 10g): Pool für Oracle-Streams 왘 der Log Buffer (auch als Redo Buffer bezeichnet), in dem die RedoLog-Daten gespeichert werden Seit der Datenbankversion Oracle 9i kann die Speicherverwaltung der SGA dynamisch konfiguriert und die vorhandenen Pufferbereiche können dynamisch verändert werden (vergrößert und auch verkleinert). Damit können Sie die Speicherverwaltung z.B. optimal an verschiedene Arbeitslasten anpassen. Parameter der SGA Die Parameter, die die Speicherbereiche der SGA bestimmen, sind in Tabelle 7.4 aufgelistet. Speicherbereich Parameter Bedeutung Buffer Pool DB_BLOCK_BUFFERS Pufferung von Datenblöcken Shared Pool SHARED_POOL_SIZE Speicherung geparster SQLStatements und Oracle-DDICInformationen Large Pool LARGE_POOL_SIZE Puffer für spezielle Daten Streams Pool (Oracle >= 10g) STREAMS_POOL_SIZE Pool für Oracle-Streams Redo Buffer LOG_BUFFER Pufferung Redo-Log-Daten Tabelle 7.4 Speicherbereiche und Parameter der System Global Area (SGA) 286 Analyse der Datenbank 7.3 Neben der System Global Area gibt es einen weiteren Speicherbereich, die Program Global Area (PGA), die prozesslokalen Speicher zur Verfügung stellt, der nur einem Datenbankprozess zugeordnet werden kann. Der einem Prozess zugewiesene Speicher ist variabel. Der wichtigste Speicherbereich in der PGA ist der Sort Buffer (auch als Sort and Hash Area bezeichnet), in dem Sortierungen, Hash Joins, BitmapOperationen und andere temporäre lokale Speicheranforderungen (z.B. beim Parsen von SQL-Statements) bearbeitet werden. Der Sort Buffer ist entscheidend für die Performance von Querys und sollte deshalb ausreichend groß gewählt werden, da bei der Ausführung von Querys sehr viele Sortierungen durchgeführt werden müssen. Program Global Area (PGA) Für die Verwaltung der Prozesse wird auf Betriebssystemebene weiterer Speicher benötigt. Während die Textsektion, die das ausführbare Programm enthält, nur einmal existiert und von allen Prozessen verwendet wird, existieren andere Bereiche wie Data oder Stack für jeden Prozess lokal. Man muss im Allgemeinen mit bis zu 6 MB betriebssystemseitigen Memory-Verbrauchs pro Oracle-Prozess (Windows: Oracle-Thread) rechnen. Betriebssystemseitiger Prozessspeicher Der Data Buffer (oder Data Cache) ist der Pufferbereich, der zur Zwischenspeicherung der zuletzt von der Festplatte gelesenen Datenblöcke von Datenbanktabellen und deren Indizes verwendet wird. Ein SAP-Workprozess liest die Daten nicht direkt von der Festplatte, sondern aus dem Data Buffer, weshalb alle von der Datenbank gelesenen Daten zunächst in diesen Pufferbereich geschrieben werden. Der Datenpuffer legt die Daten in sogenannten Blöcken oder Pages ab, die je nach Datenbank- und Betriebssystem zwischen 2 und 32 KB groß sind. Die Daten werden immer block- bzw. pageweise von der Festplatte gelesen. Der Data-Buffer-Speicher wird über den sogenannten LRU-Algorithmus (Least Recently Used) verwaltet. Dieser Algorithmus stellt sicher, dass immer die am häufigsten gebrauchten Datenblöcke im Speicher gehalten werden. Data Buffer Die Qualität des Datenpuffers wird durch die Anzahl der Datenblöcke bestimmt, die direkt aus dem Datenpuffer ohne Plattenzugriff gelesen werden können. Die Anzahl der Lesezugriffe aus dem Datenpuffer wird als Reads bezeichnet. Immer wenn ein Workprozess einen Datenblock anfordert, der sich bereits im Datenpuffer befindet, wird ein Hit (Treffer) für den Puffer registriert. Befindet sich der angeforderte Datenblock nicht im Datenpuffer, muss der Datenblock 287 7 Analyse von Datenbank, Speicher und Hardware von der Festplatte gelesen werden. Die Anzahl der physikalisch von der Platte gelesenen Datenbankblöcke wird als Physical Reads bezeichnet. Hitratio Die prozentuale Trefferquote (Hitratio) berechnet sich demnach nach folgendem Verhältnis: Trefferquote (%) = (Reads/(Reads + Physical Reads)) × 100 Je größer die Anzahl der Lesezugriffe aus dem Datenpuffer (Reads) im Verhältnis zu den physischen Lesezugriffen (Physical Reads) ist, umso besser ist die Pufferqualität. Eine Trefferquote von 100% bedeutet, dass alle Lesezugriffe aus dem Hauptspeicher der Datenbankinstanz beantwortet werden konnten und nicht von der Platte gelesen werden mussten. Beim Neustart einer Datenbankinstanz müssen die Puffer erst erneut aufgebaut werden, die Trefferquote ist zunächst dementsprechend niedrig. Zur Bewertung der Pufferqualität sollte die Datenbank deshalb bereits einige Zeit laufen. Datenpuffergröße Die Datenpuffergröße ergibt sich aus dem Produkt der Blockgröße (DB_BLOCK_SIZE) und der Anzahl der in der Parameterdatei init<SID>.ora bzw. durch die Serverparameterdatei angegebenen Datenbank-Blockpuffer (DB_BLOCK_BUFFERS). In den meisten Oraclebasierten BW-Systemen wird eine Standardgröße von 8.192 Bytes für die Blockgröße verwendet, die zu Beginn der Erstellung der Datenbank festgelegt werden muss und danach nicht mehr geändert werden kann. Die Größe des Datenbank-Blockpuffers kann an die Anforderungen des Betriebs jederzeit angepasst werden. Ab SAPRelease 6.40 und Oracle 9i wird der Parameter DB_CACHE_SIZE anstelle von DB_BLOCK_BUFFERS als Default verwendet. In diesen Fällen darf DB_BLOCK_BUFFERS nicht mehr verwendet werden. Mit Verwendung der dynamischen SGA müssen Sie neue Parameter setzen: SGA_MAX_SIZE und DB_CACHE_SIZE. SGA_MAX_SIZE Der Parameter SGA_MAX_SIZE legt die maximale Größe der SGA fest (in Byte), bis zu der die SGA dynamisch wachsen kann. Die dynamische SGA erlaubt die Anpassung der Größen für Buffer Cache, Shared Pool und Large Pool zur Laufzeit, solange die Summe ihrer Größen inklusive der anderen Komponenten (Fixed SGA, Variable, SGA, Redo Buffer) die Grenze von SGA_MAX_SIZE nicht überschreitet. Dieser Parameter dient in erster Linie dazu, ein »Oversizing« der SGA und Paging zu verhindern. 288 Analyse der Datenbank 7.3 Wird der Parameter nicht gesetzt, setzt Oracle SGA_MAX_SIZE als Default-Wert (wenn DB_CACHE_SIZE gesetzt ist) auf die Summe aller SGA-Komponenten beim Start der Instanz. Dies hat zur Folge, dass die SGA nicht größer werden kann als beim Start, sondern nur kleiner. Sie sollten den Parameter deshalb ausreichend groß wählen, sodass die SGA bis zum Parameterwert dynamisch – ohne SystemDowntime – wachsen kann, und ohne dass Paging auftritt. Der für SGA_MAX_SIZE spezifizierte Wert wird bereits beim Start der Instanz allokiert, auch wenn die Summe der einzelnen SGA-Komponenten geringer ist. Mit dem Parameter DB_CACHE_SIZE wird die dynamische SGA aktiviert, und die Größe des Buffer Caches wird festgelegt. Der frühere Parameter DB_BLOCK_BUFFERS ist damit obsolet. DB_CACHE_SIZE Die Datenpufferqualität in einem produktiven BW-System sollte nicht unter 95% liegen. Zur Beurteilung der Pufferqualität sollte die Datenbank aber einige Zeit nach dem letzten Start gelaufen sein. Die Pufferqualität kann im BW-System zeitweilig auch niedriger sein, da durch sehr viele Full Table Scans (z.B. durch Hash Joins) die Blocktrefferrate möglicherweise gesenkt wird, was auch nicht durch Vergrößern des Puffers gelöst werden kann. Datenpufferqualität Data Buffer Pool Die Größe des Data Buffers hat in der Regel den größten Einfluss auf die Datenbankperformance. Der Data Buffer Pool sollte deshalb ausreichend groß dimensioniert sein, damit möglichst wenige zeitintensive Plattenzugriffe durchgeführt werden müssen. Für ein produktives BW-System mit ca. 200 bis 500 Anwendern kann die Größe des Data Buffers bei 4 bis 8 GB und mehr liegen. Der Shared Pool ist, wie der Name schon andeutet, ein gemeinsam genutzter Speicherbereich, der Strukturen des Data Dictionary Caches und des Shared-SQL-Bereichs (auch Library Cache genannt) enthält. Im Data Dictionary Cache werden Informationen über die zuletzt verwendeten Objekte der Datenbank gespeichert (Tabellen, Views etc.), die von Administratoren, Anwendern und dem Datenbanksystem benötigt werden. Im Shared-SQL-Bereich (auch Shared Cursor Cache oder Shared SQL Area genannt) werden der SQL-Text, die Parse-Bäume von SQL-Anweisungen und die Ausführungspläne gespeichert. Die Größe des Shared Pools sollte in Oracle-basierten 289 Shared Pool 7 Analyse von Datenbank, Speicher und Hardware SAP NetWeaver BW-Systemen (200 bis 500 Benutzer) mindestens 800 bis 1.000 MB betragen. Die Größe des Shared Pools wird durch den init<SID>.ora-Parameter SHARED_POOL_SIZE bestimmt. Beachten Sie auch die SAP-Hinweise zur Datenbankparametrisierung Ihres BW-Systems in Anhang A.11. Data-DictionaryCache-Qualität Die Data-Dictionary-Cache-Qualität (DD Cache Quality) gibt an, wie häufig auf das Oracle Data Dictionary während der Verarbeitung von SQL-Befehlen zugegriffen werden muss. Die Data-Dictionary-CacheQualität sollte in einem BW-Produktivsystem möglichst immer über 90% liegen. Zugriffsqualität Die Zugriffsqualität auf SQL-Anweisungen im Shared-SQL-Bereich wird durch die Parameter SQL Area getratio und SQL Area pinratio gemessen. Die Wiederverwendung von identischen SQL-Anweisungen verringert die Systemlast, die durch das Parsen und Laden von SQL-Anweisungen in den Arbeitsspeicher entsteht. Während der Parameter SQL Area getratio die Anzahl der Anforderungen von Objekten im Library Cache bestimmt, misst der Parameter SQL Area pinratio die Anzahl der Ausführungen der Objekte im Library Cache. Dieser Wert sollte in einem produktiven BW-System nahe bei 99% liegen. Parameterwerte prüfen Beachten Sie, dass die angegebenen Werte immer für ein »eingeschwungenes« System gelten und nach dem Neustart des Systems abweichen können. Überprüfen Sie deshalb in einem eingeschwungenen System, ob die folgenden Parameterwerte erfüllt sind: 왘 DD Cache Quality > 80% 왘 SQL Area pinratio ≥ 95% 왘 SQLA Reloads/pins ≤ 0,04 왘 User/recursive calls ≥ 2 Falls diese Werte nicht erfüllt sind, ist der Shared Pool möglicherweise zu klein dimensioniert und sollte erhöht werden. Log Buffer Der Log Buffer (auch Redo Log Buffer) ist der Pufferbereich, in dem alle Änderungen der Datenbank protokolliert werden. Jede Datenänderung erzeugt einen Redo-Eintrag im Log Buffer, mit dem die Datenänderungen bei einer Wiederherstellung der Daten in einen früheren Zustand rekonstruiert werden können. So werden z.B. beim Laden von Daten in SAP NetWeaver BW sehr viele Redo-Einträge erzeugt. 290 Analyse der Datenbank Bei der Einstellung des Log Buffers ist zu beachten, dass der Wert ein Vielfaches von DB_BLOCK_SIZE sein muss (Standardgröße 8.192 Bytes). So liegt die Standardeinstellung eines ERP-Systems in der Regel bei 40 × 8.192 Bytes = 320 KB. Für ein produktives BW-System sollte die Startkonfiguration ca. beim 150- bis 200-Fachen des Wertes von DB_BLOCK_SIZE liegen. Der Parameter Allocation retries zeigt die Anzahl der fehlgeschlagenen Zuweisungsversuche von Platz im Redo-Log-Puffer an. Dieser Fall tritt immer dann ein, wenn der Oracle-Log-Writer-Prozess (LGWR) nicht sofort Redo-Log-Einträge vom Puffer auf die Festplatte schreiben konnte, sondern auf einen Redo-Log-Dateiwechsel warten muss, um den Platz zuzuweisen. Die Alloc fault rate gibt das Verhältnis zwischen den fehlgeschlagenen Zuweisungsversuchen (Allocation retries) und der Anzahl der gesamten Einträge (Entries) im Redo-Log-Buffer an. Der Wert sollte nicht über 1% steigen. Als Calls wird die Gesamtzahl der seit dem Start der Datenbankinstanz im Kernel des Datenbanksystems eingegangenen Abfragen bezeichnet. Unter der Rubrik Calls werden im Hauptbildschirm des Datenbankmonitors die folgenden Parameter angezeigt: 왘 User calls: Gesamtzahl der seit dem Start der Datenbankinstanz im Kernel des Datenbanksystems eingegangenen Abfragen 왘 User commits: Bei einem Commit werden alle von einer Transaktion durchgeführten Änderungen in der Datenbankinstanz dauerhaft festgeschrieben. Mit Commit abgeschlossene Transaktionen können nicht mehr durch ein Roll-back rückgängig gemacht werden. 왘 User roll-backs: Bei einem Roll-back werden alle von einer Transaktion durchgeführten Änderungen in der Datenbankinstanz rückgängig gemacht. Roll-backs werden durch Programmfehler, Applikationssperren oder sonstige Anwendungsabbrüche ausgelöst. 왘 Recursive calls: Rekursive Abfragen sind SQL-Anweisungen des Datenbanksystems, die zusätzlich zu benutzerseitigen SQL-Anweisungen ausgegeben werden müssen. Zur Beantwortung der Datenbank-Calls benötigt das System Verwaltungsinformationen aus dem Cache der Datenbank. Stehen diese Informationen nicht im Datenbank-Cache zur Verfügung, müssen sie mit einem Recursive 291 Calls 7.3 7 Analyse von Datenbank, Speicher und Hardware Call von der Festplatte nachgeladen werden. Rekursive Abfragen können z.B. durch fehlende Treffer (Misses) im Data Dictionary Cache ausgelöst werden und beeinträchtigen die Performance des Datenbanksystems. 왘 Das Verhältnis der rekursiven Calls zu den User Calls wird im Parameter User/recursive calls berechnet. Die Anzahl der rekursiven Calls sollte nicht größer sein als die User Calls. Ein höherer Wert ließe auf eine schlechte Data-Buffer-Hitquote schließen. Das Verhältnis sollte deshalb einen Wert von zwei zu eins nicht unterschreiten. Das Problem lässt sich meist durch eine Erhöhung des init<SID>.ora-Parameters SHARED_POOL_SIZE beheben. Rekursive Calls und User Calls Beachten Sie bei der Bewertung des Verhältnisses von rekursiven Calls zu User Calls, dass der Wert für rekursive Calls direkt nach Start der Datenbankinstanz meist hoch ist, da der Data-Dictionary-Cache zunächst leer ist und alle Abrufe für das Füllen des Caches rekursiv sind. Parses Vor der Ausführung einer SQL-Anweisung wird diese zunächst analysiert (geparst), wobei unter anderem die Zugriffsstrategien ermittelt werden und geprüft wird, ob die verwendeten Tabellen und Spalten tatsächlich in der Datenbank vorkommen. Das Ergebnis der Prüfung wird im Shared Cursor Cache abgelegt, wobei bei erneuter Ausführung der Query nur noch auf diese Informationen zugegriffen wird. Der Wert Parses zählt, wie oft SQL-Anweisungen geparst werden mussten. Das Verhältnis von Parses zu User Calls gibt die durchschnittliche Parsing-Rate an, deren Wert nicht über 25% liegen sollte. Hohe Parsing-Raten deuten auf ein Problem mit dem Halten des Cursors im Shared Cursor Cache (Shared SQL Area) hin. In diesem Fall sollten Sie die Data-Dictionary-Cache-Qualität überprüfen und die Größe des Shared Pools eventuell erweitern. Reads/User Calls Der Parameter Reads/User Calls ist das Verhältnis der aus dem Datenpuffer gelesenen Blöcke zur Gesamtzahl der Anfragen an die Datenbank seit dem Start der Datenbankinstanz und gibt an, wie viele Blöcke im Mittel aus dem Datenpuffer gelesen werden müssen, um eine Datenbankanfrage (Call) zu beantworten. Das Verhältnis Reads/User Call ist ein Indikator dafür, ob eine weiterführende Analyse der Shared SQL Area durchgeführt werden sollte. Ein hoher 292 Analyse der Datenbank Wert (> 30) deutet auf teure und komplexe Querys bzw. SQL-Statements hin, die näher untersucht werden sollten. 7.3.3 Analyse der Shared SQL Area Gegenstand der Statistikdaten in der Shared SQL Area sind z.B. Informationen zur Anzahl der Ausführungen einer SQL-Anweisung oder die Zahl der logischen und physischen Lesezugriffe je SQL-Anweisung. Die SQL-Anweisungen werden im Shared-SQL-Bereich gespeichert. Um die Statistikdaten der Shared SQL Area zu analysieren, starten Sie das DBA Cockpit und wählen im Menü Performance Overview den Hauptbildschirm des Datenbankmonitors. Folgen Sie hier dem Menüpfad SQL Statement Analysis 폷 Shared Cursor Cache. Im sich öffnenden Fenster Auswahlkriterien für Shared Cursor Cache können Sie verschiedene Einschränkungen für Selektionskriterien wie Anzahl der Buffer Gets, Disk Reads oder Database User vornehmen (siehe Abbildung 7.4). Bestätigen Sie dies mit einem Klick auf den grünen Haken, und Sie erhalten eine Liste mit den SQLAnweisungen, über die die Datenbank seit Datenbankstart Statistiken vorhält (siehe Abbildung 7.5). Abbildung 7.4 Analyse der Statistikdaten der Shared SQL Area (Oracle) – Kriterien 293 7.3
