Adm515_de_col63_fv

ADM515

ADM515 Datenbankadministration SAP MaxDB

Datenbankadministration SAP MaxDB

SAP NetWeaver

2008

© SAP 2008

„

Materialnummer: 50092400

Copyright

Copyright 2008 SAP AG. All rights reserved. Neither this training manual nor any part thereof may be copied or reproduced in any form or by any means, or translated into another language, without the prior consent of SAP AG. The information contained in this document is subject to change and supplement without prior notice. All rights reserved.

„ „

„ „ „ „ „ „ „ „ „ „ „ „ „ „ „

„

Trademarks: Microsoft ®, Windows ®, NT ®, PowerPoint ®, WinWord ®, Excel ®, Project ®, SQL-Server ®, Multimedia Viewer ®, Video for Windows ®, Internet Explorer ®, NetShow ®, and HTML Help ® are registered trademarks of Microsoft Corporation. Lotus ScreenCam ® is a registered trademark of Lotus Development Corporation. Vivo ® and VivoActive ® are registered trademarks of RealNetworks, Inc. ARIS Toolset ® is a registered Trademark of IDS Prof. Scheer GmbH, Saarbrücken Adobe ® and Acrobat ® are registered trademarks of Adobe Systems Inc. TouchSend Index ® is a registered trademark of TouchSend Corporation. Visio ® is a registered trademark of Visio Corporation. IBM ®, OS/2 ®, DB2/6000 ® and AIX ® are a registered trademark of IBM Corporation. Indeo ® is a registered trademark of Intel Corporation. Netscape Navigator ®, and Netscape Communicator ® are registered trademarks of Netscape Communications, Inc. OSF/Motif ® is a registered trademark of Open Software Foundation. ORACLE ® is a registered trademark of ORACLE Corporation, California, USA. INFORMIX ®-OnLine for SAP is a registered trademark of Informix Software Incorporated. UNIX ® and X/Open ® are registered trademarks of SCO Santa Cruz Operation. ADABAS ® is a registered trademark of Software AG The following are trademarks or registered trademarks of SAP AG; ABAP/4, InterSAP, RIVA, R/2, R/3, R/3 Retail, SAP (Word), SAPaccess, SAPfile, SAPfind, SAPmail, SAPoffice, SAPscript, SAPtime, SAPtronic, SAP-EDI, SAP EarlyWatch, SAP ArchiveLink, SAP Business Workflow, and ALE/WEB. The SAP logo and all other SAP products, services, logos, or brand names included herein are also trademarks or registered trademarks of SAP AG. Other products, services, logos, or brand names included herein are trademarks or registered trademarks of their respective owners.

Voraussetzungen

Erforderliche Vorkenntnisse „

SAPTEC – SAP NetWeaver: Grundlagen der Application Platform

„

oder äquivalente Kurse für SAP Business One oder äquivalente Kurse für SAP Business by Design

„

Empfohlene Vorkenntnisse ADM100 – SAP Netweaver Administration I „ Grundlegende Betriebssystemkenntnisse „

„

© SAP 2008 / Seite 1

Grundlegende Datenbankkenntnisse

Zielgruppe

Diese Schulung richtet sich an die folgende Zielgruppe: Datenbankadministratoren im SAP Umfeld (SAP Netweaver, SAP Business One, SAP Business by Design) „ Interessierte der MaxDB Community „

Dauer: 3 Tage

© SAP 2008

„

Benutzerhinweise y Die Schulungsunterlagen bilden keine Selbstlernprogramme. Nur in Verbindung mit den Erläuterungen des Referenten bzw. der Referentin haben Sie komplette Unterlagen. Auf Ihren Unterlagen finden Sie Platz, um diese Zusatzinformationen zu notieren. y Es ist möglich, dass die Zeit während eines Kurses nicht ausreicht, um alle Übungen durchzuführen. Bei den Übungen handelt es sich um zusätzliche Beispiele, die während des Kurses behandelt werden. Anhand dieser Beispiele können die Teilnehmer ihre Kenntnisse aber auch im Anschluss an den Kurs vertiefen.

Überblick über die Schulung

Inhalt: „

Ziele der Schulung

Lernziele der Schulung „ Inhaltsverzeichnis „

Übersichtsdiagramm „ Gesamtunternehmensszenario „

© SAP 2007 / Page 1

© SAP AG

ADM515

1-1

Lernziele der Schulung

Nach Abschluß dieses Kurses sollten sie die Fähigkeit besitzen: „

eine MaxDB Installation administrieren zu können

© SAP 2008

© SAP AG

ADM515

1-2

Inhaltsverzeichnis

Vorwort Kapitel 1 Der erste Kontakt

Kapitel 5 Weitere Administrations-

themen

Kapitel 2 MaxDB betreiben

Kapitel 6 Performance-Tuning und

Kapitel 3 MaxDB-Interna

Problemsituationen

Kapitel 4 Datenbanksicherung und -wiederherstellung

Kapitel 7 Ausblick: MaxDB 7.8

Anhänge

© SAP 2007 / Page 1

© SAP AG

ADM515

1-3

Agenda I

1. Der erste Kontakt 1.1. 1.2. 1.3. 1.4. 1.5. 1.6.

3. MaxDB-Interna

Einführung Werkzeuge und Schnittstellen Architektur und Betriebszustände MaxDB und SAP NetWeaver Integration mit SAP NetWeaver Serverlandschaft der Schulung

3.1. 3.2. 3.3. 3.4. 3.5.

4. Datenbanksicherung und -wiederherstellung

2. MaxDB betreiben 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8.

Prozesse Sperren Speicherbereiche Plattenbereiche Logging

Überblick Database Studio Wichtige Informationsquellen im Database Studio Benutzer der MaxDB im SAP-Umfeld Plattenbereiche für Daten und Log Konfigurationsänderungen DBFULL und LOGFULL Situationen Parameter Übungswerkzeug

4.1. 4.2. 4.3. 4.4. 4.5. 4.6. 4.7. 4.8.

Vollständige Datensicherung Inkrementelle Datensicherungen MaxDB Snapshots Log-Sicherungen Automatische Log-Sicherung Überprüfen der Sicherungen Sicherungsstrategie Externe Sicherungstools

© SAP 2008

© SAP AG

ADM515

1-4

Agenda II

5.

Weitere Administrationsthemen 5.1. 5.2. 5.3. 5.4. 5.5. 5.6. 5.7.

7.

Prüfen der Datenbank Erstellen einer Datenbankinstanz Neuinitialisierung einer Datenbankinstanz Installation eines Patches (Releasewechsel) Migration zur MaxDB Hochverfügbarkeit MCOD

Ausblick auf MaxDB 7.8 7.1. 7.2. 7.3. 7.4. 7.5.

Übersicht Änderungen des Datenbankkerns Neue administrative Funktionen Setup und Infrastruktur Interface & User

6. Performance-Tuning und Problemsituationen 6.1. 6.2. 6.3. 6.4. 6.5. 6.6.

B*-Bäume Optimierung Monitore des SAP NetWeaver Vermeidbare Probleme Diagnosedateien und TraceMöglichkeiten Fehlerarten und deren Analyse

© SAP 2008

© SAP AG

ADM515

1-5

© SAP AG

ADM515

1-6

Der erste Kontakt

Inhalt: Hintergründe zur MaxDB „ Erster Kontakt mit der Datenbank „

MaxDB im Umfeld der SAP NetWeaver-Architektur „ Kommunikation mit MaxDB „

© SAP 2008 / Page 1

© SAP AG

ADM515

2-1

Der erste Kontakt: Lernziele

Am Ende dieses Kapitels, können Sie: Die Komponenten einer MaxDB-Datenbankinstanz und die Datenbankwerkzeuge benennen „ Die Architektur eines SAP NetWeaver-Systems mit MaxDB beschreiben „

© SAP 2008 / Page 1

© SAP AG

ADM515

2-2

Agenda I

1. Der erste Kontakt 1.1. 1.2. 1.3. 1.4. 1.5. 1.6.

3. MaxDB-Interna

Einführung Werkzeuge und Schnittstellen Architektur und Betriebszustände MaxDB und SAP NetWeaver Integration mit SAP NetWeaver Serverlandschaft der Schulung

3.1. 3.2. 3.3. 3.4. 3.5.

4. Datenbanksicherung und -wiederherstellung

2. MaxDB betreiben 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8.

Prozesse Sperren Speicherbereiche Plattenbereiche Logging

Überblick Database Studio Wichtige Informationsquellen im Database Studio Benutzer der MaxDB im SAP-Umfeld Plattenbereiche für Daten und Log Konfigurationsänderungen DBFULL und LOGFULL Situationen Parameter Übungswerkzeug

4.1. 4.2. 4.3. 4.4. 4.5. 4.6. 4.7. 4.8.

Vollständige Datensicherung Inkrementelle Datensicherungen MaxDB Snapshots Log-Sicherungen Automatische Log-Sicherung Überprüfen der Sicherungen Sicherungsstrategie Externe Sicherungstools

© SAP 2008

© SAP AG

ADM515

2-3

Agenda II

5.

Weitere Administrationsthemen 5.1. 5.2. 5.3. 5.4. 5.5. 5.6. 5.7.

7.

Prüfen der Datenbank Erstellen einer Datenbankinstanz Neuinitialisierung einer Datenbankinstanz Installation eines Patches (Releasewechsel) Migration zur MaxDB Hochverfügbarkeit MCOD

Ausblick auf MaxDB 7.8 7.1. 7.2. 7.3. 7.4. 7.5.

Übersicht Änderungen des Datenbankkerns Neue administrative Funktionen Setup und Infrastruktur Interface & User

6. Performance-Tuning und Problemsituationen 6.1. 6.2. 6.3. 6.4. 6.5. 6.6.

B*-Bäume Optimierung Monitore des SAP NetWeaver Vermeidbare Probleme Diagnosedateien und TraceMöglichkeiten Fehlerarten und deren Analyse

© SAP 2008

© SAP AG

ADM515

2-4

Einführung: Übersichtsdiagramm

Der erste Kontakt Abschnitt 1: Einführung Abschnitt 2: Werkzeuge und Schnittstellen Abschnitt 3: Architektur und Betriebszustände Abschnitt 4: MaxDB und SAP NetWeaver Abschnitt 5: Integration mit SAP NetWeaver Abschnitt 6: Serverlandschaft der Schulung

© SAP 2008 / Page 1

© SAP AG

ADM515

2-5

Mehr als 30 Jahre Geschichte der MaxDB

1977

Start an der TU Berlin als Forschungsprojekt

1979-1997 Nixdorf Computer AG, Siemens-Nixdorf, Software AG 1993

Erstes Produkt für SAP Anwendungen: ADABAS for R/3

1997

Weiterentwicklung als SAP DB (Version 6.2.10 bis 7.4) bei der SAP AG. Verbreitung in andere Produkte z.B. als liveCache (APO / SCM)

2003

Umbenennung in MaxDB (Kooperation mit MySQL)

2007

MaxDB ist jetzt ein Trademark der SAP AG Planung, Entwicklung, Support und Vertrieb von MaxDB durch SAP SAP MaxDB als alleiniges Datenbanksystem für Business by Design

15 Jahre Erfahrung als SAP Datenbank

© SAP 2008

© SAP AG

ADM515

2-6

SAP und MaxDB

MaxDB ist das Datenbankangebot der SAP „

Teil des SAP Technologie Portfolios

„

Unterstützt alle SAP Anwendungen

„

Teil der SAP NetWeaver Plattform und der Development Workbench

„

Vorteil: Alle Komponenten einer SAP Installation von einem Anbieter

MaxDB „

Fokussiert auf Anforderungen des SAP Kunden und SAP Anwendungen

„

Fortlaufende Weiterentwicklung

„

Geringe Lizenz- und Wartungskosten

„

Strategische und sichere Alternative

© SAP 2008

© SAP AG

ADM515

2-7

Entwicklungsziele

„

Einfache Handhabung

„

Keine permanente Überwachung notwendig

„

Keine Reorganisation

„

Wenige Konfigurationsparameter

„

Keine Größenabschätzungen notwendig

„

Automatische Platzzuteilung für Datenpakete

„

Automatischer Lastausgleich auf den verwendeten Festplatten

„

Breite Plattformunterstützung (Unix und Windows)

Niedrige Gesamtbetriebskosten (Total Cost of Ownership) © SAP 2008 / Page 1

© SAP AG

ADM515

2-8

Einsatzgebiete der MaxDB

„

Online Transaction Processing (OLTP) z. B. SAP NetWeaver SAP Business by Design SAP Business One

„

Objektorientierte Speichertechnik im SCM-Umfeld (SAP liveCache)

„

Online Analytical Processing (OLAP) z. B. SAP Business Information Warehouse (BI)

„

Dokumentenmanagement z. B. SAP Content Server

„

Internet-Katalog-Anwendungen

„

Java-Entwicklung

© SAP 2008

Das Datenbanksystem MaxDB unterstützt verschiedene Anwendungsgebiete. Entsprechend werden folgende Anwendungstypen unterschieden: „ MaxDB OLTP ist für die schnelle Bearbeitung einzelner Transaktionen mit einer hohen Anzahl von Benutzern und großen Datenbanken optimiert. Es kommt in diversen Kundenprojekten von LKWVerkehrsleitsteuerung bis Hochregallagerverwaltung zum Einsatz. „ SAP liveCache arbeitet objektorientiert und hält seine Daten im Hauptspeicher des Datenbanksystems. „ MaxDB OLAP ermöglicht dank Online Analytical Processing (OLAP)-Technologien flexible Analysen aus unterschiedlichen betriebswirtschaftlichen Blickwinkeln. Grundlage dieses Datenbankinstanztyps ist ein multidimensionales Datenmodell, das mit relationalen Datenbanktabellen realisiert ist. „ MaxDB Document Server wurde auf Basis des relationalen Datenbanksystems MaxDB OLTP entwickelt, um auch Dokumente mit unstrukturierten Daten (Video, XML-Dokumente) zu verwalten. „ MaxDB E-Catalog ist ein OLTP-Datenbanksystem mit integrierter TREX Suchmaschine. Mit Hilfe der Suchmaschine können Langtexte indiziert und anschließend effizient durchsucht werden. Ein Anwendungsbeispiel ist das Produkt BugsEye oder eMerge von Requisite. „ Bei der Installation einer Java-Enwicklungsumgebung für den SAP WebAS 6.40 wird direkt eine administrationsarme MaxDB für die Ablage diverser Informationen der Entwicklungsumgebung installiert.

© SAP AG

ADM515

2-9

SAP DB & MaxDB-Versionen Version

Verwendung

Neuerungen

7.1

liveCache

Wechsel von 4K- auf 8K-Seiten, SQL- und OMS-Datenbank

OLTP

nur Content Server

7.2

liveCache & OLTP

vollständige Erweiterung auf OLTP, Einsatz mit neuen Produkten, liveCache

7.3

OLTP

Unicode-fähig, hohe Performance

7.4

OLTP

Strukturelle Änderungen, neues Logging & Datenmanagement

liveCache

Zusätzlich komplettes Logging im liveCache

OLTP

Performanceoptimierungen (u.a. SQL-Optimizer)

liveCache

Release with SCM 4.1

OLTP

Performanceoptimierungen, Verbesserung in der Supportbarkeit, mehr automatische Funktionen

liveCache

Release mit SCM 5.0

OLTP

Neues IO-System, Release ist Basis für SAP Business by Design

liveCache

Release mit SCM 6.0

7.5

7.6

7.7 7.8

OLTP

Neues flexibleres Taskmanagement, Isolierte Installation

liveCache

Release mit SCM 7.0

© SAP 2008

Ab SAP DB 7.4 bzw. später mit MaxDB 7.5 sind für die Standard-Unix-Versionen (HP-UX, AIX, Solaris etc.) keine 32Bit-Releases mehr zu erhalten. „ Für Linux und Windows sind weiterhin 32Bit-Releases neben den neu erhältlichen 64-Bit-Versionen zu bekommen. „ 32-Bit liveCaches sind nicht erhältlich. „

© SAP AG

ADM515

2-10

Flexibilität: Betriebssysteme und Plattformen

MaxDB unterstützt folgende Plattformen: Linux „

ia32, ia64

„

x86_64 (EM64T)

„

PowerPC

HP-UX „

PA-RISC (Nach Ende der Produktunterstützung nur noch Patches)

„

ia64

AIX „

IBM pSeries

Solaris „

Sun SPARC

„

x86_64 in Vorbereitung

Windows 2003, Windows 7 „

ia32, ia64

„

x86_64 (ab Windows 2003)

© SAP 2008 / Page 1

Für die meisten UNIX-Varianten sind nur als 64-Bit-Versionen der MaxDB erhältlich. „ Benchmarks für MaxDB finden Sie unter „http://www.sap.com/benchmark/ Ö SD two-tier results”. „

© SAP AG

ADM515

2-11

Weitere Schulungen zur MaxDB und liveCache

UMEW60 Empowering Workshop SAP DB/MaxDB (Performance Monitoring and Optimization) „

Dauer: 3 Tage

„

Besonderheit: Teilnehmer beobachten und optimieren das eigene Produktivsystem während des Workshops

„

Ist in deutsch und englisch verfügbar

WB550 - Workshop - MaxDB Internals - Version 7.7 „

Dauer: 5 Tage

Ist in deutsch und englisch verfügbar „ Geeignet für fortgeschrittene MaxDB Administratoren, da Interna intensiv vorgestellt werden „

TEWA60 Empowering Workshop liveCache (Performance Monitoring and Optimization) „

Dauer: 3 Tage

Besonderheit: Teilnehmer beobachten und optimieren das eigene Produktivsystem während des Workshops „ Ist in deutsch und englisch verfügbar „

© SAP 2008 / Page 1

Alle Kurse können über den Schulungskatalog gebucht werden. „ Der UMEW60 wird üblicherweise quartalsweise in Berlin angeboten, während der WB550 ein- bis zweimal pro Jahr stattfindet. „ Der TEWA60 wird ebenfalls quartalsweise angeboten. „

© SAP AG

ADM515

2-12

Literatur

Verfügbare Bücher: SAP DB / MaxDB „

Zielgruppe: OpenSource Community

„

Verlag: C & l Computer- u. Literaturverlag

MaxDB - Administration Zielgruppe: MaxDB Admininistatoren im SAP Produktumfeld „ Verlag: SAP Press „

„

Erscheinungstermin: Herbst 2008

© SAP 2008 / Page 1

„

Derzeit sind zwei MaxDB Bücher am Markt verfügbar.

© SAP AG

ADM515

2-13

MaxDB Homepage

© SAP 2008 / Page 1

© SAP AG

ADM515

2-14

SAP Network: Informationen zur MaxDB

© SAP 2008 / Page 1

© SAP AG

ADM515

2-15

SAP Network: MaxDB Wiki

© SAP 2008 / Page 1

© SAP AG

ADM515

2-16

SAP Netzwerk: MaxDB Forum

© SAP 2008 / Page 1

© SAP AG

ADM515

2-17

Werkzeuge und Schnittstellen: Übersichtsdiagramm Kapitel: Der erste Kontakt Abschnitt 1: Einführung Abschnitt 2: Werkzeuge und Schnittstellen Abschnitt 3: Architektur und Betriebszustände Abschnitt 4: MaxDB und SAP NetWeaver Abschnitt 5: Integration mit SAP NetWeaver Abschnitt 6: Serverlandschaft der Schulung

© SAP 2008 / Page 1

© SAP AG

ADM515

2-18

Werkzeuge und Schnittstellen der MaxDB

Administration

Datenzugriff

Schnittstellen

Database Studio

Database Studio

DBMCLI SQLCLI

Loader Sync Manager

DBanalyzer

WebDAV

SQL Database Connectivity (SQLDBC) ODBC 3.5 JDBC 3.0 Perl, Python, PHP (C/C++ Precompiler zur Abwärtskompatibilität)

Installation Manager

MaxDB Datenbankinstanz © SAP 2008

Die MaxDB-Datenbankwerkzeuge lassen sich in folgende Bereiche unterteilen: y Verwalten der Datenbankinstanz y Arbeiten mit der Datenbank „ Die beiden früheren rein Windows-basierten Tools DBMGUI und SQL Studio wurden mittlerweile in eine Eclipse basierte Anwendung integriert. Damit ist das Database Studio plattformunabhängig. „ Alle aktuellen Schnittstellen inklusive PHP werden unterstützt. „ SQL Database Connectivity (SQLDBC) ist die Nachfolgegeneration für die MaxDB PreCompilerSchnittstelle. Mit NetWeaver 7.0 (2004s) und dem darin enthaltenen SAP Kernel 7.00 wird SQLDBC eingeführt und ersetzt dort den MaxDB PreCompiler. Auch der neue Kernel 6.40_EX2 für die älteren SAP NetWeaver Releases enthält nun das SQLDBC anstelle des früheren PreCompilers. „

© SAP AG

ADM515

2-19

Database Studio

Integrierte, ECLIPSE-basierte Tool-Plattform Plattform-unabhängige Java-Umgebung „ PlugIns zum „

„

Management der Landschaft „ User Repositories Datenbankmanagement „

„ „ „ „ „

SQL-Abfragen, Reporting Loader Synchronization Manager DBAnalyzer

ab Version 7.8 vollständige Unterstützung aller notwendigen administrativen Datenbankfunktionen (z.B. Anlegen & Reinitialisieren von Datenbanken) „ Vorabversionen ab 7.7 sind schon länger verfügbar „

© SAP 2008 / Page 1

© SAP AG

ADM515

2-20

Database Studio: Weitere Informationen

Database Studio ist abwärtskompatibel bis MaxDB 7.5. Für ältere Releases (<= 7.4) bitte weiter den Database Manager GUI 7.6.03 verwenden. Upgrades verfügbar über: „

http://service.sap.com/patches → Database Patches → MaxDB and SAP DB → MaxDB GUI Components/Tools

„

Wichtig: Die Version des Database Studio muß mindestens dem Versionsstand der zu administrierenden Datenbank entsprechen

© SAP 2008

Die Software-Versionen des Database Studio sind aufgrund der Client/Server-Technologie abwärtskompatibel. Das aktuelle Database Studio 7.8 kann auch mit den älteren SAP MaxDBVersionen (bis 7.5) benutzt werden. „ Ältere Releases (≤ 7.4.x) sollten weiterhin mit der Kombination DBMGUI- und SQL Studio administriert werden. „ Hinweis 386714 erläutert Installation und Upgrade der Software. „ Bitte beachten Sie die Versionsabhängigkeiten zwischen Database Studio und administrierter Datenbank y Die administrierte Datenbank sollte den gleichen oder einen älteren Versionstand des verwendeten Database Studios besitzen. Es fehlen sonst in älteren Database Studio Versionen die Unterstützung zu neueren Features. Dadurch können Fehler oder unbeabsichtige Dinge auf der Datenbankinstanz passieren. „

© SAP AG

ADM515

2-21

Database Studio: Administrationsbereich

© SAP 2008

Im Startbildschirm erhalten Sie die Liste der registrierten Datenbankinstanzen. Nach der Auswahl einer Instanz bietet das Database Studio weitere Informationen und Statistiken. „ Um Details anzuzeigen, markieren Sie eine Datenbankinstanz und wählen im Kontextmenü (rechte Maustaste) den Administrationsbereich aus. „ Viele Funktionen und Optionen sind über das Kontextmenü im Database Studio erreichbar. „ Um Informationen über einen bestimmten Bereich anzuzeigen, wählen Sie bitte den entsprechenden Reiter für die gewünschte Information an. „

© SAP AG

ADM515

2-22

Database Studio: SQL-Bereich

© SAP 2008 / Page 1

Neben Administrativen Aufgaben unterstützt das Database Studio auch den SQL-Zugriff auf die Datenbank und übernimmt damit auch die Rolle des früheren SQL-Studio. „ Auch hier ist das Kontextmenü des Datenbankinstanznamens der Einstieg. Bitte wählen sie den SQL-Editor aus. „ Mehr Informationen zum Database Studio im zweiten Kapitel. „

© SAP AG

ADM515

2-23

Installation Manager

Einfache Installation und Setup per graphischer Oberfläche als „ „ „

Mobile clients / Laptop Workstations / PC SAP Developer Workstation (im SAP-Umfeld immer diese Möglichkeit wählen)

Template-based installation & configuration „

Stiller Modus

„

Template-Auswahl Optionale Demodaten

„

Automatic operations „

Neustart, Shutdown

„

Backup, Recovery Datenbankerweiterungen

„

GUI „

Plattform-unabhängige Java-Entwicklung

© SAP 2008 / Page 1

„

Die Funktionen des Installation Managers können ebenfalls mit Kommandozeilen-Tools wir SDBINST und STBUPD ausgeführt werden.

© SAP AG

ADM515

2-24

Database Studio – Datenbankregistrierung

Erster Schritt: Registrieren einer Datenbankinstanz „

Eingabe des Rechnernamens (falls im Netzwerk)

„

Bei lokalem Verbindungsaufbau Rechnernamen leer lassen

„

Liste der vorhandenen Datenbankinstanzen anzeigen lassen (Next)

„

Datenbankinstanz auswählen, dann „Finish“

© SAP 2008 / Page 1

„

„ „ „

„ „ „

Das Database Studio ist ein Datenbankwerkzeug für die Verwaltung von MaxDB-Datenbanken. Mit ihm können Sie Datenbankinstanzen anlegen, steuern, überwachen, sichern, löschen und gegebenenfalls wiederherstellen. Um mit dem Database Studio Datenbankinstanzen verwalten zu können, müssen diese registriert sein. Wählen Sie im Kontextmenü des Servers Add Ö Server/Database Geben Sie den Namen des Rechners ein, auf dem die gewünschte Datenbankinstanz installiert ist, und lassen Sie sich mit Next die Liste der dort installierten Datenbankinstanzen anzeigen. Falls alles auf dem lokalen Rechner installiert ist, braucht kein Rechnername eingegeben zu werden. Löschen Sie die Markierungen für die Datenbankinstanzen, die Sie die nicht wünschen und wählen Finish. Der Eintrag für die gewählte Datenbankinstanz taucht dann in dem Hauptschirm des Database Studios unter dem Servernamen auf. Die endgültige Anmeldung an die Datenbank erfolgt im zweiter Schritt auf der Folgeseite.

© SAP AG

ADM515

2-25

Database Studio – Datenbankanmeldung

Zweiter Schritt: Anmeldung an die Datenbankinstanz „

Datenbankinstanzeintrag anschließend auswählen

„

Benutzername und Kennwort eingeben. Daten können ebenfalls in der Registry gespeichert werden.

© SAP 2008

„ „ „ „ „ „

Führen Sie einen Doppelklick auf den Instanznamen aus oder wählen im Kontextmenü den Punkt Login aus. Es erscheint das Popup um Anmeldedaten zu definieren. Zur Administration wird zuerst der Benutzer CONTROL mit dem Kennwort CONTROL benötigt. Ob die Zugangsdaten richtig sind, können Sie auch über den Button Test Login prüfen. Sobald Anmeldedaten zu einer Datenbankinstanz fehlen, wird dieser Dialog immer automatisch auftauchen. Über den Login-Eintrag im Kontextmenü der Datenbankinstanz können Sie weitere User hinterlegen. Für SQL-Operationen werden später ein oder mehrere weitere User hier hinterlegt.

© SAP AG

ADM515

2-26

Database Manager CLI: Überblick

Aufruf des Database Manager CLI: dbmcli [] [] Optionen:

Kommandos:

„

„

help apropos „ explain „ db_enum „ db_online „ db_admin „ db_offline „ db_state „ db_create

-h „ -u <userid,password> „ -U <Userkey> „ -d „ -n <server_node> „ -i „ -uUTL <userid,password> „ -uSQL <userid,password> „ -uSRV <userid,password>

„

Beispiel für einen Aufruf des Database Manager CLI: dbmcli –n -d <SID> -u control,control db_state

© SAP 2008

Sie können an den Database Manager Verbindungsoptionen und gleichzeitig maximal ein DBMKommando in einer Kommandozeile übergeben. „ Mit dem Kommando dbmcli –h erhalten Sie die möglichen Verbindungsoptionen angezeigt. „

„

Um eine Verbindung zur Datenbankinstanz auf dem lokalen Rechner herzustellen, müssen Sie mindestens den Namen der Datenbankinstanz mit der Option -d angeben.

„

Befindet sich die Datenbankinstanz auf einem entfernten Rechner, müssen Sie zusätzlich diesen Rechnernamen mit der Option -n <server_node> angeben.

Um eine interaktive Sitzung zu eröffnen, geben Sie zunächst nur die Verbindungsoptionen an. Anschließend können Sie Ihre DBM-Kommandos interaktiv eingeben. „ Das DBM-Kommando besteht immer aus dem Kommandonamen und optionalen Parametern. „ Mit dem DBM-Kommando help erhalten Sie alle verfügbaren DBM-Kommandos angezeigt. „

„

Sie können Ihre DBM-Kommandos in eine separate Datei schreiben. Geben Sie dann beim Aufruf des Database Manager CLI auch die Option -i an.

© SAP AG

ADM515

2-27

SQLCLI: Überblick

Aufruf des SQLCLI: sqlcli [] [<sql command>] Optionen: „

-h -u „ -U „ -d „ -n „ -S „ -i „

<sqluserid,password> <Userkey> <server_node> SQLMODE

Beispiel für einen Aufruf des Database Manager CLI: sqlcli -n -d <SID> -u sapt00,sap “SELECT * FROM users”

© SAP 2008

„

Mit dem Kommando sqlcli –h erhalten Sie die möglichen Verbindungsoptionen angezeigt.

Um eine Verbindung zur Datenbankinstanz auf dem lokalen Rechner herzustellen, müssen Sie mindestens den Namen der Datenbankinstanz mit der Option -d und einen SQL-Benutzer angeben. „ Befindet sich die Datenbankinstanz auf einem entfernten Rechner, müssen Sie zusätzlich diesen Rechnernamen mit der Option -n <server_node> angeben. „

Um eine interaktive Sitzung zu eröffnen, geben Sie zunächst nur die Verbindungsoptionen an. Anschließend können Sie Ihre SQL-Kommandos interaktiv am Prompt des SQLCLI eingeben. „ Es ist aber auch möglich, wie in dem Beispiel alle Aufrufoptionen in einer Zeile zu übergeben. „ Sie können Ihre SQL-Kommandos in eine separate Datei schreiben. Geben Sie dann beim Aufruf des SQLCLI auch die Option -i an. „

© SAP AG

ADM515

2-28

Architektur und Betriebszustände: Übersichtsdiagramm Kapitel: Der erste Kontakt Abschnitt 1: Einführung Abschnitt 2: Werkzeuge und Schnittstellen Abschnitt 3: Architektur und Betriebszustände Abschnitt 4: MaxDB und SAP NetWeaver Abschnitt 5: Integration mit SAP NetWeaver Abschnitt 6: Serverlandschaft der Schulung

© SAP 2008 / Page 1

© SAP AG

ADM515

2-29

Database Manager: Architektur

Client

X-Server

Database Studio

DBM-Server dbmcli sqlcli

Kern

Server

config files config files

DB © SAP 2008

„ „ „

„ „

„ „

Der Database Manager besteht aus einem Server- und einem Client-Teil. Unabhängig davon, welchen Client Sie verwenden, wird für den Database Manager dieselbe Funktionalität angeboten. Der Database Manager-Server (DBM-Server) stellt die Verbindung zur Datenbankinstanz her. Es gibt folgende Clients: y Database Studio mit einer einfach zu bedienenden graphischen Benutzeroberfläche. y DBMCLI als kommandozeilenorientierte Schnittstelle, ebenfalls unabhängig vom Betriebssystem. y Skriptschnittstelle ist vorhanden. Client und DBM-Server können auf verschiedenen Rechnern installiert sein. Die Datenbankinstanz muss immer auf dem Rechner installiert sein, auf dem der DBM-Server installiert ist. Der X-Server stellt als Kommunikationsinstanz die Verbindung zwischen Client und DBM-Server her. (Ausnahme: Auf Windows-Betriebssystemen ist die lokale Kommunikation auch ohne X-Server möglich.) Die auf der folgenden Folie vorgestellten Betriebszustände der Datenbank beziehen sich auf die Kern-Ebene, dargestellt durch die Ampel. Bitte behalten Sie diese schichtartige Struktur des MaxDB Datenbank Server in der Erinnerung, da Sie mit dieser Struktur bei der Arbeit mit der MaxDB immer wieder konfrontiert werden.

© SAP AG

ADM515

2-30

Betriebszustände einer Datenbankinstanz

OFFLINE „ Keine

SQL-Verbindung zur Datenbank möglich

„ Keine

Datenbankkern-Prozesse aktiv

„ DBM-Server

zur Abarbeitung von Client-Kommandos kann aktiv sein

ADMIN „ Administration „ Backup

möglich

und Restore möglich

ONLINE „ Datenbank

vollständig betriebsbereit

„ Datenbankbenutzer „ Backup

können sich anmelden

möglich

© SAP 2008

Es gibt folgende Betriebszustände einer MaxDB-Datenbankinstanz: „ OFFLINE Die Datenbankkern ist nicht in Betrieb. Die Prozesse und Caches des Datenbankkerns existieren nicht auf Betriebssystemebene. Der Prozess dbmsrv ist als Server-Komponente aktiv zur Abarbeitung der Kommandos die von Clients (Database Studio, dbmcli usw.) an die Datenbank geschickt werden. „ ADMIN (COLD in früheren Versionen) Der Datenbankkern ist aktiv, aber noch nicht mit Daten und Logbereich verbunden. Die Datenbankinstanz steht nur dem Database Manager-Benutzer für administrative Zwecke zur Verfügung. Änderungen von Datenbankparametern werden beim nächsten Neustart von OFFLINE nach ONLINE wirksam. In diesem Betriebszustand kann die Datenbank wiederhergestellt werden. „ ONLINE (WARM) Der Datenbankkern ist gestartet und die Datenbankinstanz befindet sich im Betriebszustand. Die Datenbankbenutzer können sich anmelden und auf ihre Tabellen zugreifen. Im Normalfall sollten Sie die Datenbankinstanz in diesem Betriebszustand sichern. Änderungen von Datenbankparametern werden beim nächsten Neustart von OFFLINE nach ONLINE wirksam. „ Um zwischen den Betriebszuständen zu wechseln, markieren Sie im Database Sudio die Datenbankinstanz und wählen Sie Actions → Online/Admin/Offline nach dem Verbindungsaufbau zur Datenbankinstanz.

© SAP AG

ADM515

2-31

Stoppen der Datenbankinstanz (Shutdown)

Shutdown Normal Eine letzte Synchronisation mit den DataVolumes wird durchgeführt (Savepoint) „ Anschließend wird die Datenbank gestoppt „

Shutdown Quick

„

SHUTDOWN ADMIN oder OFFLINE

ONLINE

T1

(dbmcli-Kommando: db_stop) „

Zeit

T2

Alle bestehenden Benutzerverbindungen und Transaktionen werden sofort abgebrochen (ohne Synchronisation bzw. Savepoint).

T3 T4

Option wird über das Database Studio nicht angeboten

COMMIT

Die Datenbank ist nach jedem Shutdown konsistent

ADMIN

ROLLBACK

Alle Sicherungen, die danach angefertigt werden, sind mit MaxDB konsistent. © SAP 2008

Einen Überblick über die offenen Transaktionen in der Datenbankinstanz erhalten Sie im Database Studio über Instance → Information → Sessions. „ Der Shutdown Quick ist eine recht raue Art und Weise die DB zu beenden. Dabei werden die Shared Memory Bereiche der DB entrissen. Nichtsdestotrotz bleibt die DB konsistent. „ Mit dem Kommandozeilentool dbmcli, das auf den folgenden Seiten ebenfalls vorgestellt wird, können Sie mit den Kommandos y db_online y db_admin y db_offline „

den Modus zwischen den Betriebszuständen wechseln. Mit diesen Kommandos wird immer ein Shutdown Normal durchgeführt. „ Den aktuellen Status des Datenbankkerns können Sie mit dem Kommando db_state ermitteln. „ Wird in besonderen Situationen ein sofortiger Shutdown benötigt, kann dieser mit dem Kommando db_stop ausgeführt werden. Bitte beachten sie, daß damit keine Synchonisation mit den Plattenbereichen mehr erfolgt (SAVEPOINT) und damit alle Änderungen seit der letzten Synchronisation verloren sind. Daher das db_stop nur in Ausnahmefällen einsetzen.

© SAP AG

ADM515

2-32

MaxDB und SAPNetWeaver: Übersichtsdiagramm Kapitel: Der erste Kontakt Abschnitt 1: Einführung Abschnitt 2: Werkzeuge und Schnittstellen Abschnitt 3: Architektur und Betriebszustände Abschnitt 4: MaxDB und SAP NetWeaver Abschnitt 5: Integration mit SAP NetWeaver Abschnitt 6: Serverlandschaft der Schulung

© SAP 2008 / Page 1

© SAP AG

ADM515

2-33

MaxDB und SAP NetWeaver

SAP MaxDB

© SAP 2008 / Page 1

„ „ „ „

„ „

SAP NetWeaver ist ein Client-Server-System. Für den Betrieb wird neben den SAP-Komponenten ein relationales Datenbanksystem genutzt. Ein SAP NetWeaver-System kann auf einem oder mehreren Servern installiert werden. Auf einem dieser Server, dem Datenbankrechner, ist die Datenbanksoftware installiert. Die SAP NetWeaver-Kernel-Software kann auf beliebig vielen Applikationsservern (einschließlich dem Datenbankrechner) in jeweils bis zu 100 Instanzen eingerichtet und mit dem zentralen Datenbankrechner verbunden werden. Jede Instanz des SAP NetWeaver besteht aus einer Vielzahl von Prozessen und Hauptspeicherbereichen. Der SAP NetWeaver zeichnet sich damit durch ein hohes Maß an Skalierbarkeit aus. Der Quellcode der betriebswirtschaftlichen Anwendungen (Programmiersprache: ABAP) ist in Datenbanktabellen gespeichert. Bei Bedarf greifen die Instanzen des SAP NetWeaver darauf zu. Die Daten des SAP NetWeaver sind ebenfalls in Datenbanktabellen gespeichert.

© SAP AG

ADM515

2-34

Unterstützte SAP & NetWeaver-Releases ApplikationsRelease

SAP Kernelversion

Neueste unterstützte MaxDB Version*

3.1I – 4.5B

31I_EXT – 45B_EXT

7.5.0 mit zusätzlichem CCMS-Transport (Freigabe 7.6 & 7.7 nur für Upgrade-Phase)

4.6C

46D_EXT

7.5, 7.6, 7.7 mit Support Packages

4.7 Enterprise

6.10, 6.20

7.3.0, mit AKK 6.40: 7.5, 7.6

NetWeaver 2004

6.40 6.40_EX2

7.5, 7.6 7.6, 7.7

NetWeaver 7.0 (2004s)

7.00

7.6, 7.7

NetWeaver 7.1

7.10

7.6, 7.7

7.11

7.7 * Stand Herbst 2008

© SAP 2008 / Page 1

„

AKK: abwärts-kompatibler Kernel

© SAP AG

ADM515

2-35

Die dreistufige Client-Server-Architektur

Präsentationsebene SAP GUI

SAP GUI

Dispatcher

Dispatcher

Anwendungsebene

WP

WP

WP

WP

WP

Datenbankinstanz

© SAP 2008

Die dreistufige Client-Server-Architektur des SAP NetWeaver funktioniert nach folgenden Grundlagen: „ Auf Präsentationsebene benutzen die Anwender einen SAPGUI, um mit dem SAP WebAS zu kommunizieren. „ Auf Anwendungsebene empfängt der Dispatcher die Benutzeranfragen und schickt sie an verfügbare Workprozesse, die für die Abarbeitung der Anfrage zuständig sind. „ Der beauftragte Workprozess führt den entsprechenden ABAP-Code aus. Dabei formuliert und verschickt er SQL-Kommandos an die Datenbank und empfängt die Ergebnisse. Der Workprozess sendet die Antwort direkt an den SAPGUI des Anwenders. „ Neu mit dem SAP NetWeaver ist es im Gegensatz zu älteren Releases möglich, daß ein Workprozeß beliebig viele Verbindung zur Datenbank öffnet. Der Workprozeß ist hier aber nur ausführendes Organ und wird hier komplett durch die Applikation gesteuert. Nach einiger Zeit sind dann evt. alle Verbindungsmöglichkeiten auf der Seite der Datenbank belegt. Derzeit werden in der Datenbankschnittstelle des SAP NetWeaver (DBSL) nur maximal 16 Verbindungen pro Workprozess zu Datenbanken zugelassen. Sollte es also hier Auffälligkeiten geben, muß die Applikation kontrolliert werden. Überprüfen kann man diese Verbindungszahlen einfach über den Development Trace der Workprozesse (dev_w*). Bei jedem Verbindungsaufbau wird eine komplette Liste alle Verbindungen aufgeführt und die Übeltäter können schnell identifiziert werden.

© SAP AG

ADM515

2-36

Kommunikation zwischen SAP NetWeaver und MaxDB Dispatcher

Dispatcher

WP

WP

WP

WP

SAP SAP NetWeaver-Instanzen NetWeaver-Instanzen

UKTs

Usertasks MaxDB-Prozesse MaxDB-Prozesse

Coordinator

Requstor

IO Buffer Cache Catalog Cache Speicherbereiche Speicherbereiche

Shared SQL

Log Warteschlange

© SAP 2008

„

„ „ „ „ „

Der SAP NetWeaver erscheint gegenüber der Datenbank als eine Gruppe von Datenbanksitzungen der Workprozesse eines einzigen Users mit Namen sap<sid>. Jedem Workprozess ist genau eine User-Task der Datenbank fest zugeordnet. Beim Start des SAP NetWeaver sendet der Workprozess eine Anmeldeanforderung an den Datenbankserver. Der Requestor sucht eine freie User-Task und übergibt dieser die Anmeldeanforderung. Nach Übermitteln der gültigen Kombination aus Benutzername und Kennwort wird die Datenbanksitzung etabliert. Die Sitzung bleibt bis zum expliziten Abmelden des Workprozesses durch den SAP NetWeaver bestehen oder wird nach 30 Minuten Untätigkeit auch automatisch wieder abgebaut. Die User-Task hat Zugriff auf die gemeinsam genutzten Speicherbereiche der Datenbank (Shared Memory) und übernimmt die Verarbeitung der Benutzer-Aktionen.

© SAP AG

ADM515

2-37

Kommunikation im Netzwerk Datenbankrechner SAP WebAS-Instanz Dispatcher Datenbankinstanz UKT Task n

Task 1

…

IPC

WP

WP

WP

X-Server SAP WebAS-Applikationsserver SAP WebAS-Instanz

TCP/IP

Dispatcher

Port sql6 – 7210/tcp Port sapdbni – 7269/tcp

WP

WP

WP

© SAP 2008

„

„ „ „

„ „

Während bei der Kommunikation mit Prozessen, die auf dem Datenbankrechner laufen, das IPCProtokoll verwendet wird, erfolgt die Netzwerk-Kommunikation mit Prozessen auf entfernten Rechnern mit Hilfe von TCP/IP. Dabei werden die Ports 7210 und 7269 benutzt (Service-Eintrag sql6 7210/tcp und sapdbni 7269/tcp). Letzterer wird von der SAP DB Connection (SAP Hinweis 202344) benutzt. Der X-Server (Remote SQL Server) als Kommunikationsinstanz muss auf dem Datenbankrechner gestartet sein, damit der Zugriff von einem entfernten Rechner aus möglich ist. Der X-Server ist beim Einsatz mehrerer Applikationsserver Voraussetzung für den Aufbau und die Aufrechterhaltung der Verbindung zwischen SAP-Workprozessen auf entfernten Rechnern und den MaxDB-Usertasks. Clients der MaxDB-Werkzeuge (z.B. DBMCLI, Database Studio) wenden sich ebenfalls an den XServer, wenn sie eine Verbindung zu einer Datenbankinstanz von außerhalb aufnehmen wollen. Beim lokalen Zugriff auf die DB ist üblicherweise kein X-Server notwendig. Es mag evt. spezielle Situationen beim Upgrade, gemischte 32Bit/64Bit-Umgebungen o.ä. geben, aber Änderungen die aktiv vorgenommen werden müssen, sollten in der begleitenden Dokumentation explizit beschrieben sein.

© SAP AG

ADM515

2-38

Integration mit SAP NetWeaver: Übersichtsdiagramm Kapitel Titel Abschnitt 1: Einführung Abschnitt 2: Werkzeuge und Schnittstellen Abschnitt 3: Architektur und Betriebszustände Abschnitt 4: MaxDB und SAP NetWeaver Abschnitt 5: Integration mit SAP NetWeaver Abschnitt 6: Serverlandschaft der Schulung

© SAP 2008 / Page 1

© SAP AG

ADM515

2-39

Integration MaxDB ins SAP NetWeaver-Umfeld: DBA Cockpit

© SAP 2008 / Page 1

Mit SAP NetWeaver 7.0 (2004s) ersetzt das DBA-Cockpit einige bis dahin vorhandene MaxDBTransaktionen und harmonisiert das DBA-Interface zu Datenbanken, die mit SAP NetWeaver verwendet werden können. Daher werden nun die Funktionen von DB50, DB59, DB12, DB13 usw. hier vereint. „ Das DBA-Cockpit stellt einen zentralen Einstiegspunkt dar und ist über /nDBACOCKPIT im Transaktionsfeld direkt aufrufbar. „

© SAP AG

ADM515

2-40

SAP Landschaft – Zentrale Administration

BW

CRM

Applikation

MaxDB

Applikation

MaxDB

OLTP

nicht-SAP

Applikation

Applikation

MaxDB

MaxDB

SCM

KW

Applikation

Applikation

MaxDB

MaxDB

liveCache

Content Server

© SAP 2008 / Page 1

Ihr Systemlandschaft kann viele verschiedene SAP NetWeaver-Systeme mit unterschiedlichen Anwendungsbereichen enthalten. „ Die damit verbundenen Datenbankinstanzen können zentral über das Database Studio verwaltet werden. „ Das Database Studio bietet hier viele Funktionen bis hin zur Performance-Optimierung an. „

© SAP AG

ADM515

2-41

SAP Landschaft – Zentrales Monitoring

BW

CRM

Applikation

MaxDB

Applikation

MaxDB

OLTP

nicht-SAP

Applikation

Applikation

MaxDB

MaxDB

SCM

KW

Applikation

Applikation

MaxDB

MaxDB

liveCache

Content Server

© SAP 2008 / Page 1

In gleicher Form kann das DBA-Cockpit ebenfalls ein zentrales Monitoring in verteilten ServerLandschaften anbieten. „ Ein zusätzliche Installation des Database Studio wird hierfür nicht benötigt. Die Verwendung kann über die Berechtigungskonzepte im SAP NetWeaver gesteuert werden. „ Die zu administrierenden Instanzen müssen dann über zusätzliche Databankverbindungen in der DB59 eingerichtet werden. „ Oft bietet sich für so eine zentrale Administrationsplattform der SAP Solution Manager an. „

© SAP AG

ADM515

2-42

Serverlandschaft der Schulung: Übersichtsdiagramm Kapitel Titel Abschnitt 1: Einführung Abschnitt 2: Werkzeuge und Schnittstellen Abschnitt 3: Architektur und Betriebszustände Abschnitt 4: MaxDB und SAP NetWeaver Abschnitt 5: Integration mit SAP NetWeaver Abschnitt 6: Serverlandschaft der Schulung

© SAP 2008 / Page 1

© SAP AG

ADM515

2-43

Serverlandschaft Gruppe NN

Database Studio starten

Windows Terminal-Server

Datenbank-Server

Registrieren

MaxDB MaxDB MaxDB

MaxDBÜbungsdatenbanken T01 ... T30 (T01a ... T30a) (T01b ... T30b)

telnet starten

OLTP Applikation

NetWeaver System DEV (7.00)

MaxDB

Anmelden © SAP 2008

„

„

„ „

„

Jede Gruppe NN meldet sich am Datenbank-Server ___________ mit telnet an. y Benutzername: tadm y Kennwort: tadm Für geben Sie Ihre Gruppennummer ein. Auf diesem Server sind folgende Systeme verfügbar: y Eine MaxDB-Datenbankinstanz T; tadm entspricht <SID>adm y Ein SAP NetWeaver-Installation DEV, verwaltet vom Benutzer devadm Versuchen Sie, sich als Benutzer ADM515- mit einem Passwort welches Ihnen der Referent nennt am System DEV anzumelden. Starten Sie das Database Studio 7.8. Diese Anwendung läuft auf dem Windows Terminal Server und wird mit Hilfe des Terminal Server Client (TS Client) auf Ihrem Rechner bereitgestellt. Registrieren Sie die Datenbankinstanz T im Database Studio auf dem Datanbank-Server______________. In Abhängigkeit vom TerminalServer-Setup müssen Sie diese Registrierung nach jeder Neuanmeldung am Terminal-Server wiederholen. Im Abschnitt „Voraussetzungen“ der Übungen finden Sie weitere Details zur Serverlandschaft dieser Schulung.

© SAP AG

ADM515

2-44

Der erste Kontakt: Zusammenfassung

Sie können nun: Die Komponenten einer MaxDB-Datenbankinstanz und die Datenbankwerkzeuge benennen „ Die Architektur eines SAP NetWeaver-Systems mit MaxDB beschreiben „

© SAP 2008 / Page 1

© SAP AG

ADM515

2-45

© SAP AG

ADM515

2-46

Übungen Kapitel: 1 Thema: Datenbank-Grundwissen Am Ende dieser Übungen können Sie: • Die Tools der Datenbank anwenden, die für die Schulung und die allgemeine Administration notwendig sind.

Mit dem ersten Teil der hier aufgeführten Tools findet die Administration der Datenbank statt. Die sichere Verwendung dieses ersten Teils der Tools ist daher Ziel dieser Übung.

1-1

Anmeldung an das Database Studio und Start der eigenen Schulungsdatenbank 1-1-1 Melden Sie sich am Terminalserver an. 1-1-2 Start des Administrationstools Database Studio 1-1-3 Registierung der Datenbank <SID> 1-1-4 Öffnen Sie die Administrationanzeige des Database Studio im Kontextmenü Ihrer Testdatenbank. 1-1-5 Bringen Sie die Datenbank <SID> mit dem Database Studio in den Betriebszustand ONLINE 1-1-6 Wechseln Sie den Betriebszustand der Datenbank <SID> von ONLINE nach OFFLINE.

1-2

Anmeldung am Datenbankserver per Console 1-2-1 Starten Sie auf dem Terminalserver die Konsole (Telnet) und verbinden sich mit dem Datenbankserver. Melden Sie sich mit den vom Referenten mitgeteilen Logondaten an und führen das Kommando dbmcli –h und dbmcli –d <SID> -u control,control help aus. Verwenden Sie dabei den Administrationsuser <sid>adm. 1-2-2 Setzen Sie das Kommando dbmcli db_enum ab und kontrollieren die Ausgabe. Welche Informationen gibt Ihnen diese Ausgabe. 1-2-3 Starten und stoppen Sie die Datenbank per dbmcli.

© SAP AG

ADM515

2-47

© SAP AG

ADM515

2-48

Lösungen Kapitel: 1 Thema: Datenbank-Grundwissen

1-1

Anmeldung an den Database Manager GUI und Start der Schulungsdatenbank 1-1-1 Verwenden Sie die Server- und Anmeldedaten die der Referent für Ihre Gruppe mitgeteilt hat und melden sich am Terminalserver an 1-1-2 Auf dem Terminalserver ist das Database Studio installiert und muß über den Menüpfad Start → Programs → MaxDB → Database Studio aufgerufen werden. 1-1-3 Registrieren Sie die Datenbank über das Kontextmenü im Database Studio für Servers → Add → Server/Database. Tragen Sie im erscheinenden Fenster den Hostnamen des Datenbankservers ein. Mit Next erhalten Sie die Liste der Datenbanken für diesen Server. Wählen Sie dann in der Liste die Datenbank Ihrer Gruppe aus und registrieren diese. Daraufhin wird der Server und darunter die Datenbankinstanz in der Baumstruktur angezeigt. 1-1-4 Über das Kontextmenü der Instanz T<xx> können Sie den Administrationsbereich öffnen. Dabei wird die Frage nach dem DatenbankAdministrator und dessen Paßwort gestellt (User: control, Password: control). 1-1-5 Durch Auswahl des Set State → Online im Kontextmenüpunktes der Datenbankinstanz im Database Studio können Sie die Datenbank starten. Alternativ können Sie ebenfalls direkt den grünen Knopf in der Buttonleiste des Administrationsbereich anwählen. 1-1-6 Das gleiche Vorgehen bei diesem Schritt wie zuvor beim Start. Bitte wählen Sie im Kontextmenü Set State → Offline aus und bestätigen Sie das Popup.

1-2

Anmeldung am Datenbankserver per Console 1-2-1 Bei dem dbmcli-Kommando dbmcli –h erhalten Sie die Liste der Optionen des dbmcli, während bei einem dbmcli –d <SID> -u control,control help die Kommandos aufgelistet werden, die innerhalb des dbmcli bekannten sind. 1-2-2 Mit dem dbmcli db_enum erhalten Sie einen ersten Eindruck über die vorhandenen Datenbankinstanzen, die sich auf dem Server befinden. Es wird Ihnen pro installierte Datenbankinstanz die Version, das INSTROOT und der derzeitige Status des Datenbankkerns mitgeteilt. Pro Instanz finden Sie zwei Einträge „SLOW, FAST“. Diese spiegeln den normalen und einen speziellen Trace-Kern(SLOW) der Datenbank wieder. Dieses Kommando ist zur ersten Orientierung sehr wichtig.

© SAP AG

ADM515

2-49

1-2-3 Die MaxDB Instanz kann mit dem Kommando dbmcli –d <SID> -u control,control db_online gestartet und mit dbmcli –d <SID> -u control,control db_offline gestoppt werden. Den Administrationsmodus Admin erreicht man per dbmcli –d <SID> -u control,control db_admin. In seltenen Fällen von Hängesituationen benötigt man auch den Shutdown Quick dbmcli –U c db_stop mit allen seinen Nachteilen, um die Datenbank ohne letzten Savepoint (Synchronisation der Daten-Volumes mit dem Cache) zu beenden. In diesem Fall können Sie den Status der Datenbank ermitteln, wenn Sie anschließend im Modus Admin das Kommando dbmcli –d <SID> -u control,control db_restartinfo absetzen.

© SAP AG

ADM515

2-50

MaxDB betreiben

Inhalt: Informationsquellen im neuen Tool Database Studio „ Benutzer im MaxDB-Umfeld „

Einblicke in den Betrieb der MaxDB und Reaktionen auf besondere Ausnahmesituationen im Betrieb der MaxDB „ MaxDB Datenbankparameter „

© SAP 2008 / Page 1

© SAP AG

ADM515

3-1

MaxDB betreiben: Lernziele

Am Ende dieses Kapitels, können Sie: Das Database Studio bedienen und kennen wichtige Informationsquellen „ Können Ausnahmesituationen des Datenbankbetriebs beheben „

© SAP 2008 / Page 1

© SAP AG

ADM515

3-2

Agenda I

1. Der erste Kontakt 1.1. 1.2. 1.3. 1.4. 1.5. 1.6.

3. MaxDB-Interna

Einführung Werkzeuge und Schnittstellen Architektur und Betriebszustände MaxDB und SAP NetWeaver Integration mit SAP NetWeaver Serverlandschaft der Schulung

3.1. 3.2. 3.3. 3.4. 3.5

4. Datenbanksicherung und -wiederherstellung

2. MaxDB betreiben 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8.

Prozesse Sperren Speicherbereiche Plattenbereiche Logging

Überblick Database Studio Wichtige Informationsquellen im Database Studio Benutzer der MaxDB im SAP-Umfeld Plattenbereiche für Daten und Log Konfigurationsänderungen DBFULL und LOGFULL Situationen Parameter Übungswerkzeug

4.1. 4.2. 4.3. 4.4. 4.5. 4.6. 4.7. 4.8.

Vollständige Datensicherung Inkrementelle Datensicherungen MaxDB Snapshots Log-Sicherungen Automatische Log-Sicherung Überprüfen der Sicherungen Sicherungsstrategie Externe Sicherungstools

© SAP 2008

© SAP AG

ADM515

3-3

Agenda II

5.

Weitere Administrationsthemen 5.1. 5.2. 5.3. 5.4. 5.5. 5.6. 5.7.

7.

Prüfen der Datenbank Erstellen einer Datenbankinstanz Neuinitialisierung einer Datenbankinstanz Installation eines Patches (Releasewechsel) Migration zur MaxDB Hochverfügbarkeit MCOD

Ausblick auf MaxDB 7.8 7.1. 7.2. 7.3. 7.4. 7.5.

Übersicht Änderungen des Datenbankkerns Neue administrative Funktionen Setup und Infrastruktur Interface & User

6. Performance-Tuning und Problemsituationen 6.1. 6.2. 6.3. 6.4. 6.5. 6.6.

B*-Bäume Optimierung Monitore des SAP NetWeaver Vermeidbare Probleme Diagnosedateien und TraceMöglichkeiten Fehlerarten und deren Analyse

© SAP 2008

© SAP AG

ADM515

3-4

MaxDB betreiben: Übersichtsdiagramm

MaxDB betreiben Thema 1: Überblick Database Studio Thema 2: Wichtige Informationsquellen im Database Studio Thema 3: Benutzer der MaxDB im SAP-Umfeld Thema 4: Plattenbereiche für Daten und Log Thema 5: Konfigurationsänderungen Thema 6: DBFULL und LOGFULL Situationen Thema 7: Parameter Thema 8: Übungswerkzeug

© SAP 2008 / Page 1

© SAP AG

ADM515

3-5

Database Studio – Überblick mit Hyperlinks

© SAP 2008 / Page 1

„ „ „

„ „ „

„

Über die Icons im Kopf der Administration können Sie direkt den Betriebsmodus der administrierten Datenbank wechseln. Viele wichtige Funktionen im Database Studio können auf dem Overview-Reiter über Hyperlinks erreicht werden. Auch werden wichtige Warnhinweise mit entsprechenden Hyperlinks zu dem entsprechenden Wizard hier gezeigt, wenn Sie auftreten. y Hierzu zählen – fehlende vollständige Datensicherungen, – defekte oder fehlende Indizes, – usw. Der Bereich mit dem Füllungsbalken kann über den Button rechts erweitert werden, um ausführlichere Infos zum Füllstand anzeigen zu können. Durch einen Doppelklick auf die Reiter für Administration usw. kann die linke Baumstruktur mit den Servern und Datenbanken ausgeblendet und die gesamte Darstellungsbreite genutzt werden. Außerdem gibt es viele weitere Spezialbildschirmbereiche die über den rechten unteren Bereich in der Statuszeile eingeblendet weden können. Hier in dem Beispiel sehen Sie den kleinen Bildschirm, der ein Konsolenfenster erreichbar macht, mit dem man die dbmcli-Kommandos der Aktionen im Database Studio anzeigen kann. Wie diese Spezialbildschirmbereiche aktiviert werden können sehen Sie in Kapitel 5. Auf den folgenden Folien werden die verschiedenen Reiter im Administrationsbereich vorgestellt.

© SAP AG

ADM515

3-6

Database Studio – Task Manager

© SAP 2008

„ „ „ „ „

Im Taskmanager erhalten Sie Einblick in die gerade laufenden Tasks und Betriebszustände in der Datenbank. Die Liste der Tasks kann eingeschränkt werden, hier auf die aktiven Tasks. Auch ausführliche Details zu den internen Prozessen der Tasks können eingeblendet werden und werden in der nächsten Folie weiter erläutert. Über den Auffrisch-Button im oberen Bereich kann die Liste aktualisiert werden. Außerdem ist es möglich eine ausführliche Zeitmessung verschiedenster interner Datenbankprozesse einzuschalten. y Bitte bedenken Sie, daß die Aktivierung der ausführlichen Zeitmessung einen Mehraufwand für die Datenbankinstanz bedeutet, die angezeigten Zeiten zu ermitteln und zu berechnen. Dies kann in Abhängigkeit von der allgemeinen Last auf der Datenbank zu einer Beeinträchtigung der Performance führen. Die Auswirkungen sind höher, je mehr Last auf die Instanz kommt. Diese Zeitmessung sollte daher nur im Bedarfsfalle und ansonsten nur auf Test- und Entwicklungssystemen längerfristig einschalten werden. Im Allgemeinen sind die Auswirkungen auch auf großen Systemen kaum vernehmbar.

© SAP AG

ADM515

3-7

Database Studio – Task Manager Details

© SAP 2008 / Page 1

Ein Ergebnis der Aktivierung der ausführlichen Zeitmessung sehen wir hier in den Details zum Task 554: Die durchschnittlichen Schreibzeiten werden mit 1,5 ms angezeigt. Dieser Wert ist sehr gut. Werte unter 10 ms sind üblicherweise für eine gute Performance der Datenbank wichtig. Daher ist es wichtig, diese Werte besonders bei Performanceproblemen zu ermitteln. „ Das Thread-Layout sowie einige statistische Daten der Threads sind hier ebenfalls abrufbar. „

© SAP AG

ADM515

3-8

Database Studio – Activities

„

© SAP 2008 / Page 1

Im Bereich Activities sind viele statistische Betriebsdaten der MaxDB aufgelistet. Viele haben reinen Protokollcharakter „ Interessant bleiben die Einträge für Sperreskalationen und Überläufe der Log-Warteschlange (Log I/O Queue Overflow). y Der Wert für Log I/O Queue Overflow sollte möglichst bei Null liegen. Wenn das nicht der Fall ist, zeigen entweder die Log-Platten nicht die entsprechende Performance oder es tritt manchmal kurzzeitig eine extrem hohe Log-Last auf. Dann können Sie versuchen, durch Erhöhen des Parameters LogQueueSize einen größeren Puffer zu schaffen, aber die schlechten COMMITZeiten werden trotzdem bestehen bleiben. „

© SAP AG

ADM515

3-9

Database Studio – Caches

© SAP 2008

Unter Caches sehen Sie die wichtigen Cache-Bereiche der MaxDB und deren Trefferraten (Hit Rate). „ Die Werte für den Data Cache sollten möglichst über 98% liegen. Je höher der Wert desto besser. „ Für den Catalog Cache gelten andere Empfehlungen von größer 85% auch wenn schlechtere Werte hier keinen erhöhten IO-Bedarf bedeutet, wie z.B. beim Data Cache. Der Catalog Cache hat daher nicht den großen Einfluß auf die Gesamtperformance der Datenbank. „ Die zugrundeliegenden Werte werden seit Start der Datenbank ermittelt. Daher sind die Werte nach einer gewissen Laufzeit der Datenbank stark gemittelt und zeigen u.U. nicht mehr kurzzeitige Effekte an. Um diese zu erkennen, muß dann auf den DBanalyzer zurückgegriffen werden (Kapitel 6). „

© SAP AG

ADM515

3-10

Database Studio – Command Line

© SAP 2008 / Page 1

Im Database Studio ist es ebenfalls möglich weitergehende Informationen direkt mit Konsolenkommandos des dbmcli zu ermitteln. „ Hier bieten die INFO-Kommandos weitere Infos an. „ Auch andere dbmcli-Kommandos sind hier ohne weitere Kennwort-Angaben möglich. „

© SAP AG

ADM515

3-11

MaxDB betreiben: Übersichtsdiagramm

MaxDB betreiben Thema 1: Überblick Database Studio Thema 2: Wichtige Informationsquellen im Database Studio Thema 3: Benutzer der MaxDB im SAP-Umfeld Thema 4: Plattenbereiche für Daten und Log Thema 5: Konfigurationsänderungen Thema 6: DBFULL und LOGFULL Situationen Thema 7: Parameter Thema 8: Übungswerkzeug

© SAP 2008

© SAP AG

ADM515

3-12

Database Studio – Database Server Infos

© SAP 2008 / Page 1

Neben den Daten, die im Administrationsbereich generell angezeigt werden, können auch die Rohdaten über die Kommandos unter Database Server erreicht werden. „ Es handelt sich hier um die gleichen Kommandos die auf der Konsole über das x_cons oder dbmcli aufgeführt werden können. „

„

Hier ist die Ausgabe des x_cons <SID> show dev_io zu erkennen, dessen interessantesten Spalten die AvgRead und AvgWrite sind. Dort können Device-bezogene IO-Zeiten ermittelt werden und so Hardware-Probleme mit einzelnen Platten oder Plattenbereichen festgestellt werden. Mit MaxDB 7.7.04 und folgende wird dieses Kommando sowohl für Unix als auch Windows angeboten (Für Windows könnte diese Ausgabe in früheren Versionen nicht angeboten werden).

© SAP AG

ADM515

3-13

Database Studio – Diagnosedateien

© SAP 2008 / Page 1

Alle Diagnosedateien der MaxDB sind im Datenbank-Baum unterhalb des Administrationsbenutzers zu finden. „ Die wichtigste zu erwähnende Diagnosedatei ist hier die Datei knlMsg, die mit Database Messages im Baum angezeigt wird. „ Fehler werden unter Database Errors zusammengefaßt. „

© SAP AG

ADM515

3-14

Database Studio – SQL Inhalte

© SAP 2008 / Page 1

„

SQL-Inhalte der Datenbank erhalten Sie unter dem Besitzer der SQL-Tabelle im Bereich Tables.

© SAP AG

ADM515

3-15

MaxDB betreiben: Übersichtsdiagramm

MaxDB betreiben Thema 1: Überblick Database Studio Thema 2: Wichtige Informationsquellen im Database Studio Thema 3: Benutzer der MaxDB im SAP-Umfeld Thema 4: Plattenbereiche für Daten und Log Thema 5: Konfigurationsänderungen Thema 6: DBFULL und LOGFULL Situationen Thema 7: Parameter Thema 8: Übungswerkzeug

„

© SAP 2008

© SAP AG

ADM515

3-16

Windows

Unix

Betriebssystem-Benutzer mit MaxDB

Name

Funktion

Gruppe

Home Directory

root

UNIX-Superuser

sys

/

sdb

Eigentümer aller ausführbaren Dateien und Verzeichnisstrukturen der MaxDB

sdba

/sapdb/<SID>/db

<sid>adm

SAP NetWeaver-Administration

sapsys,sdba

freie Wahl

<sid>adm

SAP NetWeaver-Administration

Administratoren

freie Wahl

SAPservice<SID>

Serviceverwaltung

Administratoren

-

© SAP 2008 / Page 1

Im Umfeld des SAP NetWeaver-Systems mit MaxDB sind folgende Betriebssystembenutzer wichtig: „ Der Benutzer root wird für die SAP-Installationstools benötigt. Diese Tools springen intern auf die Benutzer <sid>adm oder sdb um. „ Der User sdb ist der Eigentümer der Dateien im Verzeichnis /sapdb. Dieser User ist kein Logonuser. Bei manchen Anwendungsbereichen (z. B. liveCache) ist der Benutzer <sid>adm sowohl zur Installation als auch zur Administration berechtigt. „ <sid>adm ist der Eigentümer aller SAP NetWeaver-Programmdateien. Im UNIX-Umfeld sollten alle Aktivitäten auf Betriebssystemebene mit <sid>adm durchgeführt werden. Durch die Zuordnung der Gruppenzugehörigkeit zur Unix-Gruppe SDBA erhält er die Möglichkeit MaxDB Programme auszuführen. „ Unter Windows startet die Serviceverwaltung die Datenbank und die NetWeaver-Instanzen mit dem Benutzer SAPService<SID>. „ Für die Kennwörter gelten die üblichen Sicherheitsrichtlinien.

© SAP AG

ADM515

3-17

MaxDB-Benutzer

Benutzer/Paßwort

Funktion

Gruppe

Modus

control/control

Database Manager-Benutzer kann keine SQL-Anweisungen ausführen

DBM

Online, Admin, Offline

superdba/admin

Datenbanksystemadministrator

SYSDBA

Online

sap<sid>/sap bzw. sapr3/sap

Datenbankbenutzer (SQL)

DBA

Online

domain/domain

Datenbankbenutzer (SQL)

DBA

Online

© SAP 2008

MaxDB unterscheidet folgende Benutzerklassen: „ Database Manager-Benutzer (DBM-Benutzer) y wird beim Installieren einer Datenbankinstanz angelegt y kann alle Database Manager-Funktionen in jedem beliebigen Betriebszustand ausführen y kann weitere Database Manager-Benutzer anlegen und ihnen Berechtigungen zuweisen y ist jedoch kein Datenbankbenutzer, d.h. er kann keine SQL-Anweisungen ausführen y Im SAP-Umfeld ist dies üblicherweise der control user (Kennwort: control) „ Datenbanksystemadministrator (Datenbankbenutzer SYSDBA) y wird beim Installieren einer Datenbankinstanz angelegt y ist Eigentümer von Statistik- und Monitor-Systemtabellen y kann weitere Datenbankbenutzer DBA anlegen und ihnen Privilegien gewähren y Im SAP-Umfeld ist dies üblicherweise der superdba user (Kennwort: admin) „ DBA-Benutzer (Datenbankbenutzer DBA) y ist Benutzer der Datenbank y kann Daten und Datenbankprozeduren definieren y kann anderen Benutzern Privilegien für diese Datenbankobjekte gewähren „ Der DBA-Benutzer sapr3 bzw. sap<sid> (Kennwort: sap) ist Eigentümer der Applikationstabellen. Die Workprozesse des SAP-Systems melden sich mit dieser Kennung an der Datenbankinstanz an. „ Der DOMAIN-Benutzer ist ein spezieller DBA-Benutzer und Eigentümer bestimmter Systemtabellen.

© SAP AG

ADM515

3-18

Zusammenhänge der Usertypen

Drei wichtige Userbereiche und deren Überschneidungen Betriebssystembenutzer „ Administrative Datenbankbenutzer „

„

SQL Benutzer

Betriebssystem • root • sdb • <sid>adm • SAPservice<SID> Datenbankadministration • control

Xuser data

SQL-User Bereich • superdba • domain • sap<sid>

• superdba • domain

© SAP 2008 / Page 1

MaxDB besitzt drei Bereiche in denen User genutzt werden: y Auf der Seite des Betriebssystems y Zur Datenbankadministration y Um auf SQL-Daten zuzugreifen „ Die zugehörigen Daten werden in unterschiedlichen Dateien oder Strukturen gespeichert: y Betriebssystembenutzer werden wie üblich von dem OS verwaltet. Die Xuserinformationen liegen hier in Form einer Datei oder Windows Registery-Eintragungen vor. Weiteres später am Ende dieses Kapitels. y Die Informationen zu den Datenbankadministratoren werden teilweise in den Parametern (CONTROLUSERID) und in den Dateien <SID>.upc im Config-Verzeichnis sowie dbm.upc im RUNDIRECTORY der DB-Instanz gehalten. Die Registrierungen dieser Administratoren liegen in der Datei <SID>.cfg im config-Verzeichnis. y Die SQL-Userinformation werden innerhalb der Datenbank abgelegt. „ Einzig die User superdba und domain sind omnivalente User, die sowohl auf der administrativen als auch SQL-Seite bekannt sind. „ Hier ist darauf zu achten, daß die Userinformationen konsistent zwischen diesen verschiedenen Ablagen gehalten werden. Seit Database Studio bietet dieses Tool zwei Einstellungsbereiche für diese unterschiedlichen Userinformationen (Administrations- oder SQL-User) im Unterschied zu früheren Versionen. Normalerweise werden Inkonsistenzen zwischen diesen Bereichen durch das Neuladen der Systemtabellen mit richtig bereitgestellten User-Optionen (dbmcli –U c loadsystab –u superdba, -ud <domain-pwd>), so weit wie es möglich ist, glattgezogen, indem die Anmeldedaten von der SQL-Seite auf die administrative Seite übertragen werden. „

© SAP AG

ADM515

3-19

Anmelde-Automatisierung: XUSER

USER SESSION des OS Users dbmcli –U w

User Parameter Sets

XUSER-Data

Parameter Set 1 USERKEY USERID PASSWORD Repeat password SERVERDB SERVERNODE SQLMODE CACHELIMIT TIMEOUT ISOLATION ENCRYPTION

DEFAULT sap<sid> *** *** E20 ws0815 SAPR3 -1 0 0 NO

Set 2 c CONTROL ******** ******** E20 ws0815 INTERNAL -1 0 0 NO

Set 3

…

w SUPERDBA ***** ***** E20 ws0815 INTERNAL -1 0 0 NO

Client Abschließend: Verbindungsaufbau mit versteckten Anmeldedaten, entsprechend dbmcli –d E20 –u SUPERDBA,

Co nn ec t

MaxDB Server

© SAP 2008

„

„ „ „

„ „ „ „ „

Mit dem Werkzeug XUSER können Sie Benutzerangaben als Parametersätze unter Angabe eines Benutzerschlüssels (USERKEY) speichern. Beim Aufruf des Database Manager CLI, der SQL Database Connectivity (SQLDBC) beim Start des SAP-Systems und des alten C/C++-Precompiler kann über diese Schlüssel auf die Benutzerangaben zugegriffen werden. Das Programm XUSER verwaltet für einen Betriebssystembenutzer bis zu 32 Parametersätze. Die Parametersätze werden in der Datei .XUSER.62 im Homeverzeichnis des Betriebssystembenutzers abgelegt. Bei Windows erfolgt die Ablage in der Windows Registry. Der erste Parametersatz heißt DEFAULT und dieser Name ist nicht änderbar. Wenn bei der Datenbankanmeldung kein Schlüssel angegeben wird, benutzt das System diesen Parametersatz an der ersten Stelle im XUSER. Für eine SAP NetWeaver-Datenbank identifiziert DEFAULT den Benutzer sap<sid>. Damit können sich die Workprozesse operatorlos an der Datenbank anmelden. Das Computing Center Management System (CCMS) innerhalb des SAP NetWeaver benötigt darüber hinaus die Schlüssel w und c. SERVERDB bezeichnet den Namen der Datenbankinstanz (<SID>). SERVERNODE bezeichnet den Rechner, auf dem Datenbankinstanz installiert ist. Ab Datenbankversionen MaxDB 7.6 aufwärts kann auch die Verschlüsselung auf der Netzwerkverbindung zwischen Client (Applikationsserver, dbmcli, usw.) und Xserver der Datenbank eingeschaltet werden. Dazu werden derzeit noch weitere Verschlüsselungsbibliotheken von der SAP benötigt.

© SAP AG

ADM515

3-20

XUSER-Daten pflegen

Optionen

Aktionen

„

„

-U „ -u „ -d „ -n „ -S „ -t „ -I

User key Benutzername Datenbankname Servername SQL-Mode Timeout Isolation level

list Auflistung set Änderungen setzen „ clear Eintrag löschen „

Beispiel: xuser –U DEFAULT –u sap<sid>,passwd –d <SID> -n -S SAPR3 set

© SAP 2008 / Page 1

Hier sind die wichtigsten Optionen des XUSER Tools aufgeführt. „ Das Beispiel zeigt einen Zugriff ohne einen kompletten Satz von Daten zu setzen. „

© SAP AG

ADM515

3-21

Logon-Option SQL-Modus Folgende SQL-Modus sind möglich: „

INTERNAL

„

ORACLE

„

(SAPR3)

© SAP 2008 / Page 1

„

„ „ „ „ „

MaxDB versteht verschiedene SQL-Dialekte. Diese Eigenschaft ist besonders bei der Portierung vorhandener, selbstentwickelter Software interessant, um den Aufwand für den Wechsel hin zur MaxDB zu erleichtern. Der SQL-Modus kann gewählt werden (Beispiel: MaxDB-Datenbankwerkzeug Database Studio) Der SQL-Modus INTERNAL (systeminterne Definition) ist der Vorschlagswert. Es wird der Standard SQL92 mit MaxDB-spezifischen Ergänzungen unterstützt. Die Unterstützung anderer SQL-Modi bezüglich der DDL-Anweisungen ist eingeschränkt. Der SQL-Modus “SAPR3” ist eine Kopie des Oracle SQL-Modus, der für fast alle Zugriffe des SAP NetWeaver-Systems auf die MaxDB genutzt wird.

© SAP AG

ADM515

3-22

Zusätzliche User-Authentifizierung ab 7.7

„

„

„

Als Alternative zu der traditionellen Anmeldung kann auch ein Betriebssystemnutzer innerhalb der Datenbank als Datenbankbenutzer angemeldet werden. Hiermit kann ein Benutzer über die Authentifizierung am Betriebssystem oder über die Sicherheitsprotokolle Kerberos oder Secude an der Datenbank anmelden. Datenbankbenutzer können auch deaktivert werden, damit Arbeiten auf der DB störungsfrei ablaufen können

CREATE USER <sid>adm IDENTIFIED EXTERNALLY AS ‘<sid>adm’ sqlcli -d <SID> -u <sid>adm “select * from users”

ALTER USER sap<sid> IDENTIFIED EXTERNALLY AS ‘<sid>adm’ sqlcli -d <SID> -u sap<sid> “select * from users”

ALTER USER sap<sid> DISABLE CONNECT sqlcli -d <SID> -u sap<sid> “select * from users” * -8026: Connect disabled for this user

© SAP 2008

© SAP AG

ADM515

3-23

MaxDB betreiben: Übersichtsdiagramm

MaxDB betreiben Thema 1: Überblick Database Studio Thema 2: Wichtige Informationsquellen im Database Studio Thema 3: Benutzer der MaxDB im SAP-Umfeld Thema 4: Administration der Plattenbereiche für Daten und Log Thema 5: Konfigurationsänderungen Thema 6: DBFULL und LOGFULL Situationen Thema 7: Parameter Thema 8: Übungswerkzeug

© SAP 2008

© SAP AG

ADM515

3-24

Daten-Volume anfügen

© SAP 2008 / Page 1

Die Datenbank kann immer bis zu der angezeigten Anzahl von DatenVolumes bis zum nächsten Restart erweitert werden. „ Die Größe der DatenVolumes kann individuell gesetzt werden, es wird aber empfohlen an einer Volume-Größe festzuhalten. Unterschiedliche Volume-Größen können sich negativ auf die Gesamtperformance der Datenbank auswirken. „ Die Datenbank kann über einen Doppelklick auf den ausgegrauten Eintrag in der Volume-Liste oder über den Button New erweitert werden. „ Mit einem Doppelklick auf die vorhandenen Volumes erhalten Sie die Eigenschaften und Einstellungen des Volumes. „

© SAP AG

ADM515

3-25

Log-Volume anfügen

© SAP 2008 / Page 1

Gleiches wie für die Daten-Volumes gilt auf für die Log-Volumes (Doppelklick auf ausgegraute Einträge oder den New-Button) „ Die Anzahl der Log-Volumes liegt üblicherweise bei ein bis zwei Volumes. Mehr Log-Volumes sind auf jeden Fall möglich, aber unnötig. „ Viele weitere Informationen zum Zustand des Log werden in dieser Darstellung aufgelistet. Über die Hyperlinks gelangen Sie oft direkt in die entsprechenden Wizards zur Einstellung der Fähigkeiten wie z.B. automatische Log-Sicherungen. „ Bitte seinen Sie sehr vorsichtig mit der Deaktivierung des Redo-Log-Managements! Es besteht die Gefahr, Business-Daten unwiderruflich zu verlieren. „

© SAP AG

ADM515

3-26

MaxDB betreiben: Übersichtsdiagramm

MaxDB betreiben Thema 1: Überblick Database Studio Thema 2: Wichtige Informationsquellen im Database Studio Thema 3: Benutzer der MaxDB im SAP-Umfeld Thema 4: Administration der Plattenbereiche für Daten und Log Thema 5: Konfigurationsänderungen Thema 6: DBFULL und LOGFULL Situationen Thema 7: Parameter Thema 8: Übungswerkzeug

© SAP 2008

© SAP AG

ADM515

3-27

Konfigurationsänderungen

Beschreibung

Betriebszustand

Protokollierte Aktion

Hinzufügen eines neuen Data-Volumes

ADMIN ONLINE

ADD DATA VOLUME

Ausgliedern und Löschen eines Data-Volumes

ADMIN ONLINE

DEL DATA VOLUME

Hinzufügen eines neuen Log-Volumes

ADMIN ONLINE

ADD LOG VOLUME

Änderung der Pfadangaben für vorhandene Data- und Log-Volumes

OFFLINE

Änderung des Log-Modus Log spiegeln Automatisches Überschreiben Log Management deaktivieren (Vorsicht!) Neuaufbau der Systemtabellen nach einem Kernel-Upgrade

ONLINE Ö ADMIN ONLINE Ö ADMIN ONLINE Ö ADMIN ONLINE

© SAP 2008

Daten- oder Log-Bereich vergrößern: Entsprechende Aktionen stehen im Database Studio zur Verfügung. y Diese Aktionen können sowohl im Zustand ONLINE als auch ADMIN durchgeführt werden. y Im Zustand ONLINE kann immer nur eine bestimmte Anzahl von Volumes hinzugefügt werden. Das Database Studio zeigt alle verfügbaren Volumes als ausgegraute Einträge an. „ Eigenschaften bestehender Volumes ändern: y Die Definition bestehender Volumes können im Zustand OFFLINE editiert werden. y So ist es beispielsweise möglich, nach Verschieben eines Volumes von einem Verzeichnis zu einem anderen den Pfad dieses Volumes entsprechend anzupassen. y Es ist nicht möglich, bestehende Volumes nachträglich in der Größe zu verändern. Einziger indirekter Weg, dieses zu erreichen, ist eine Ausgliederung und Löschung des Daten-Volumes und anschließend das Daten-Volume in gewünschter Größe wieder anzulegen. „

© SAP AG

ADM515

3-28

Reduktion der Datenbankgröße

Reduktion der Datenbankgröße im Modus ONLINE

DATA DATA DATA

„

Das Kommando db_deletevolume erlaubt es, im Modus ONLINE ein Daten-Volume aus der Konfiguration zu entfernen und damit die Größe der Datenbank zu reduzieren.

„

Mit dieser Funktion können DataVolumes auch indirekt in der Größe verändert werden (das bestehende Daten-Volume löschen und durch größeres oder kleineres ersetzen)

„

Die Daten des zu löschenden Volumes müssen zuerst automatisch auf die anderen Volumes verteilt werden

„

Im Database Studio können Daten-Volumes im Administrationsbereich Ö DataVolumes gelöscht und auch indirekt ersetzt werden

DATA

dbmcli –U c … db_deletevolume [DATA] [ NAME | [ID] ] © SAP 2008

Mit dieser Option wird indirekt eine Größenänderung von Daten-Volumes angeboten: Entsprechend größere Daten-Volumes müssen erst angelegt werden und dann können die älteren, kleinen gelöscht werden. Damit können nach und nach alle Datenvolumes im ONLINE-Modus auf eine andere Größe gebracht werden, während die neuen Volumes die Daten der alten Volumes übernehmen. „ Mit param_getvolsall oder param_getvolume DATA kann ermittelt werden, was die vol_no oder vol_name zu dem zu löschenden Volume ist. „

© SAP AG

ADM515

3-29

Daten-Volume ausgliedern und entfernen

© SAP 2008

Um ein Volume auslagern und löschen zu können, muß in den anderen Daten-Volumes genug Platz für die Daten zur Verfügung stehen. „ Eine Verschiebung von großen Datenbeständen hat natürlich einen gewissen Einfluß auf die Performance des Systems, je nach Fähigkeiten der darunterliegenden Hardware mit den Datenströmen umzugehen. „ Zusätzlich erfolgt der Transfer der Daten noch über den DataCache der Datenbank und kann zu Verdrängung führen. Es ist in Planung für solche Transfers in Zukunft andere Speicherstrukturen außerhalb des DataCache zu verwenden. „ Daher sollten solche Aktionen auf Produktivsystemen möglichst zu lastärmeren Zeiten erfolgen. „

© SAP AG

ADM515

3-30

Änderung der Lage der Volumes

Im Offline Modus:

© SAP 2008 / Page 1

Setzen Sie die Datenbank in den Betriebszustand Offline und erhalten damit die Möglichkeit, die Lage der Volumes zu verändern. „ Vor dem nächsten Restart der Datenbank von OFFLINE nach ADMIN müssen dann auch die betroffenen Volumes manuell an die neue Position verschoben werden. „

© SAP AG

ADM515

3-31

Wechsel des Log-Modus – Log spiegeln

© SAP 2008 / Page 1

„ „ „ „ „

Der Wechsel des Log-Modus von nichtgespiegelt nach gespiegelt und zurück ist vergleichbar. Die gespiegelten Log-Volumes werden definiert oder gelöscht. Durch den Wechsel des Log-Modus von nichtgespiegelt nach gespiegelt oder umgekehrt wird die Sicherungshistorie nicht aufgebrochen. Die Datenbank wird während des Vorgangs durchgestartet. Der anschließende Prozeß des Bereitstellens der Spiegellung kann entsprechend lange dauern, je nachdem wie groß das zu formatierende Log-Volume ist. Als allgemeine Empfehlung gilt: Log-Spiegelung nur für Kleinstsysteme verwenden.

© SAP AG

ADM515

3-32

Wechsel des Log-Modus – Log überschreiben

© SAP 2008

„

„

„

„

„ „ „

Bei Installationen, die reinen Testcharakter haben, ist es möglich, den Log-Modus in einen Überschreibmodus zu setzen. Dabei werden die Log-Einträge vor dem Überschreiben nicht gesichert. Sie sollten entscheiden, ob ein Datenverlust im Entwicklungssystem durch nicht durchgeführte LogSicherungen verschmerzbar ist. Falls nicht, sollten Sie auch für diese Systeme den normalen LogModus mit oder ohne Spiegellung wählen. Datenbankinstanzen, die im Log-Modus OVERWRITE laufen, nutzen die Log-Einträge im LogVolume nur, um im Falle eines Problems mit anschließendem Neustart die offenen Transaktionen vorzurollen. Daher sollte der Log-Bereich auch im Log-Modus OVERWRITE groß genug gewählt sein, um die Log-Einträge offener Transaktionen aufzunehmen. Dies gilt besonders für Content-ServerInstallationen: Hier muss der Log-Bereich zusätzlich Änderungen an großen (binären) Objekten protokollieren. Daher sollte er hier mindestens so groß gewählt werden wie das größte zu ändernde Objekt in der Datenbank. Sonst kommt es trotz Log-Modus OVERWRITE zu einer LOG FULLSituation. Bei Änderungen an Objekten werden nur die After-Images in den Log-Bereich geschrieben. Den Log-Modus können Sie im Database Studio im Administrationsbereich über den Reiter Log Area umstellen. Sie werden dabei von einem Wizard unterstützt. Sie können hier auf den Überschreib-(Overwrite) Modus und zurück auf den Normalmodus wechseln. Dabei wird die Datenbank durchgestartet. Außerdem hat es Auswirkungen auf die Sicherungshistorie, da mit dem Überschreibmodus keine Log-Sicherungen mehr angefertigt werden können und daher nur noch DatenSicherungen als Rücksetzmöglichkeit bestehen. Die Auswirkungen werden in der Folgefolie aufgezeigt.

© SAP AG

ADM515

3-33

Log-Modus wechseln - Auswirkung auf Backup-Historie

© SAP 2008

Durch die Umstellung des Log-Modus auf den Überschreibmodus sind keine Log-Sicherungen mehr möglich und damit ist eine Wiederherstellung bis zur letzten abgeschlossenen Transaktion nur in Ausnahmefällen möglich. „ Daher wird nach jeder Datensicherung eine zusätzliche Zeile in die Sicherungshistorie eingetragen, die auf den Bruch der Sicherungshistorie hindeutet (HISTLOST). „ Aufgrund dieser HISTLOST –Einträge wird beim Start von Sicherungen immer nur noch die Vollsicherung angeboten um eine neue Sicherungshistorie zu starten. „ Weiteres zur Sicherungshistorie im Kapitel 4. „

© SAP AG

ADM515

3-34

Wechsel des Log-Modus – Log deaktivieren Ö Vorsicht!

© SAP 2008

Es gibt auch die Möglichkeit, das Log-Management komplett zu deaktivieren, was natürlich mit entsprechender Vorsicht bedacht werden sollte. „ Damit werden keine Log-Informationen mehr in das Log-Volume geschrieben, außer ein paar wenige Synchronisationsinformationen. „ Desweiteren werden keine zeitgesteuerten SAVEPOINTs mehr ausgeführt. „ Auch bedenken Sie bitte, daß nach einem Crash die DB beim Restart auf den Stand zurückfällt, der beim letzten SAVEPOINT bestand und zusätzlich alle dort offenen Transaktionen auch noch zurückgerollt werden. y Es gibt keine Möglichkeit mehr des Vorrollens. y Sie verlieren hier also Informationen aus bereits abgeschlossenen Transaktionen, deren Ergebnisse aber zwischen den SAVEPOINTs nur im IO Buffer Cache stehen und sind daher nach einem Crash verloren. y Bei einem normalen Shutdown der DB wird kurz vor dem Abschluß noch ein SAVEPOINT geschrieben. y Bei einem db_stop durch das dbmcli wird kein SAVEPOINT mehr durchgeführt. „

„

Die Umstellung findet im Admin-Mode statt.

© SAP AG

ADM515

3-35

Wechsel des Log-Modus – Log deaktiviert Ö Vorsicht!

© SAP 2008 / Page 1

Nach erfolgreicher Umstellung wird der Log-Zustand “Redo Log Management is deactivated” angezeigt. „ Das Deaktivieren des Log-Managements hat die gleichen Auswirkungen auf die Sicherungshistorie wie das Automatische Überschreiben des Logs. Es wird ein Eintrag Histlost erzeugt. „ Bitte beachten Sie die Warnungen der vorhergehenden Seiten zum Thema das Log-Management zu deaktivieren. „

© SAP AG

ADM515

3-36

Laden der Systemtabellen auf der Console

Das Laden der Systemtabellen „

kann auf der Console mit dem dbmcli

„

oder über das Database Studio

erfolgen. Besonders wichtig ist es, nach einem Update der Datenbanksoftware.

© SAP 2008 / Page 1

Die Updatetools der MaxDB (hier SDBUPD) führen diesen wichtigen Update der Systemtabellen automatisch als Abschluß der Aktivitäten aus. Nur beim SDBINST erfolgt dieses nicht und ein Update der Systemtabellen muß dort manuell erfolgen. „ Der Update bzw. das Laden der Systemtabellen kann zu jedem Zeitpunkt im Online-Modus der Datenbank durchgeführt werden. „

© SAP AG

ADM515

3-37

Laden der Systemtabellen im Database Studio

© SAP 2008 / Page 1

„

Über das Database Studio können keine Benutzerinformationen an den Prozeß übergeben werden. Diese Eingaben werden intern ermittelt.

© SAP AG

ADM515

3-38

MaxDB betreiben: Übersichtsdiagramm

MaxDB betreiben Thema 1: Überblick Database Studio Thema 2: Wichtige Informationsquellen im Database Studio Thema 3: Benutzer der MaxDB im SAP-Umfeld Thema 4: Administration der Plattenbereiche für Daten und Log Thema 5: Konfigurationsänderungen Thema 6: DBFULL und LOGFULL Situationen Thema 7: Parameter Thema 8: Übungswerkzeug

© SAP 2008

© SAP AG

ADM515

3-39

FULL-Situationen

Daten

Log © SAP 2008 / Page 1

FULL-Situationen können sowohl im Daten- als auch Log-Bereich auftreten „ Achtung: Die DB FULL-Situation kann besonders bei kleineren Datenbankinstallationen schon vor Erreichen eines 100%-Wertes in der Log-Belegung auftreten, da Teile des Log- und Data-Bereichs reserviert sind und nicht von den Benutzerprozessen (User-Tasks) genutzt werden können. Die reservierten Bereiche dienen unter anderem dazu, einen Shutdown der Datenbank trotz LOG FULLSituation durchführen zu können. „ Erst wenn die DB FULL- bzw. LOG FULL-Situation wieder behoben ist, werden die Tasks ihre Arbeit fortsetzen. „ Die Analyse erfolgt üblicherweise direkt im Database Studio und den gut sichtbaren Anzeigen dort. Aber wenn diese Möglichkeit nicht besteht, gibt es über die Prozessliste und die Datei Database Messages Alternativen der Analyse. Diese werden im Folgenden gezeigt. „

© SAP AG

ADM515

3-40

Analyse DB FULL Situation – Taskliste

ACTIVE

TASKS © SAP 2008

Es gibt die Möglichkeit, in der Prozessliste der aktiven Tasks (ACTIVE) zu erkennen, welcher Task durch den vollgelaufenen Log-Bereich angehalten wurde und warum. „ Die Prozessliste (TASKS) zeigt, welche Aktionen in der Datenbank durchgeführt werden. „ Der Benutzerprozess (T82: User) wurde angehalten aufgrund des DB FULL. „ Über die APPL-pid ist es möglich, den Verursacher auf der Seite des SAP NetWeaver zu ermitteln. „

„

Evt. ist dieser aber auch nur Leidtragender, der zufällig die letzte frei Datenbankseite angefordert hat.

© SAP AG

ADM515

3-41

Analyse LOG FULL Situation – Taskliste

ACTIVE

TASKS © SAP 2008

Direkt auf dem Datenbankserver kann diese Ausgabe auch mit x_cons <SID> show tasks bzw. x_cons <SID> show active erreicht werden. „ Alternative Möglichkeit für entfernte Datenbanksserver: dbmcli –U c show tasks oder dbmcli –U c show active „

„

Über die Application-PID kann zurückverfolgt werden, welcher Prozess auf Betriebssystemebene für diese Situation verantwortlich ist.

© SAP AG

ADM515

3-42

DB FULL Situation in den Database Messages

© SAP 2008 / Page 1

Eine weitere Möglichkeit, die DB FULL- bzw. LOG FULL-Situationen zu erkennen, besteht darin, die Database Messages nach entsprechenden Meldungen zu durchsuchen. „ Warungen vor einer DB FULL-Situation erscheinen hier schon früher. „

© SAP AG

ADM515

3-43

LOG FULL-Situation in den Database Messages

© SAP 2008

Hier ist beispielhaft das Auftreten einer LOG FULL-Situation gezeigt. „ Üblicherweise werden schon lange vor dem Eintreten dieser Situation entsprechende Meldungen protokolliert: Schon ab 50 Prozent Belegung des Log-Bereichs tauchen Meldungen auf. „

© SAP AG

ADM515

3-44

Gründe für Suspend-Situationen

© SAP 2008 / Page 1

„

Analog läßt sich eine Ausgabe mit x_cons <SID> show SUSPENDS anzeigen.

In dieser Ausgabe wird angegeben in welchen Situationen der Kernel seit Start wie lange verweilte. Dieses wird auch prozentual umgerechnet. „ In der kurzen Betriebszeit war die Datenbank zu fast 28% mit dem Warten auf das Log-Schreiben beschäftigt. Die restliche Zeit wurde auf Arbeit gewartet und etwas Zeit auch für das Schreiben von Daten verwendet. „

© SAP AG

ADM515

3-45

Vorgehen zur Behebung einer DB FULL Situation Lösung durch Anfügen eines oder mehrerer Daten-Volumes Ein Durchstarten der DB ist nicht notwendig! Datenbankinstanz bleibt einfach stehen und wartet auf neu hinzugefügten Plattenplatz

© SAP 2008 / Page 1

© SAP AG

ADM515

3-46

Vorgehen zur Behebung einer LOG FULLSituation LOG FULL-Situation aufgetreten Log 1

„

Letzter ungesicherter Log-Eintrag

„

Aktuelle Schreibposition im Log-Bereich

Log-Volume angefügt „

Log 2

Log 1

Keine Lösung, da das neue Log-Volume nicht in die Logik eingefügt werden kann

Stattdessen: Log-Sicherung LOGSAVE.001 LOGSAVE.002 LOGSAVE.003

Log 2

BACKUP

Log 1 „

Log 1 & 2

Befreiung der Anschlussstelle im bestehenden Log-Volume von Log-Einträgen für das neue Volume

Einbinden des neuen Log-Volume in den LogBereich

© SAP 2008

„ „

„

„ „

„

Nach den Erfahrungen mit dem Anfügen von Data-Volume könnte man auf die Idee kommen, die LOG FULL-Situation einfach durch das Anfügen eines weiteren Log-Volume zu beheben. Leider hilft das nicht: Die aktuelle Schreibposition im Log-Volume kann bei einer LOG FULLSituation an einer beliebigen Stelle sein, da die Log-Einträge zyklisch geschrieben werden. Das bedeutet, dass sich der neue Log-Volume nicht physikalisch wie logisch direkt an die aktuelle Schreibposition anfügen lässt, d.h. nicht nahtlos weitergeschrieben werden kann. Der einzige Ausweg aus der LOG FULL-Situation ist eine interaktive Log-Sicherung, die den gesamten Log-Bereich sichert. Erst danach kann der neue Log-Volume integriert und genutzt werden. Wenn kein neuer Log-Volume integriert werden soll, genügt es auch, die automatische LogSicherung mit funktionierendem Sicherungsmedium wieder zu aktivieren. Für alle diese Sicherungsaktionen muss immer eine Voraussetzung erfüllt sein: Es wird eine intakte Sicherungshistorie mit initialer vollständiger Datensicherung und evtl. darauf folgenden inkrementellen Datensicherungen benötigt. Wenn Sie in Testdatenbanken eine neue Datenbankinstanz erstellen und sofort den Log-Bereich komplett füllen, dann kann es möglich sein, dass der erste der hier beschriebenen Lösungsversuche funktioniert. Dann entspricht die aktuelle Schreibposition gerade dem physikalischen Anknüpfungspunkt des Log-Volumes, und der neue Log-Volume kann direkt eingebunden werden. Dies ist aber ein Spezialfall.

© SAP AG

ADM515

3-47

MaxDB betreiben: Übersichtsdiagramm

MaxDB betreiben Thema 1: Überblick Database Studio Thema 2: Wichtige Informationsquellen im Database Studio Thema 3: Benutzer der MaxDB im SAP-Umfeld Thema 4: Plattenbereiche für Daten und Log Thema 5: Konfigurationsänderungen Thema 6: DBFULL und LOGFULL Situationen Thema 7: Datenbankparameter Thema 8: Übungswerkzeug

© SAP 2008

Siehe auch SAP Hinweis 1139904 (FAQ: MaxDB/liveCache Kernel Parameter) „ und SAP Hinweis 1004886 (MaxDB-Version 7.7 Parameterempfehlungen) „ Ähnliche Parameterempfehlungshinweise finden Sie für alle MaxDB-Datenbankreleases wie z.B. für MaxDB 7.6: SAP Hinweis 814704 (MaxDB-Version 7.6 Parametereinstellungen für OLTP/BW) „

© SAP AG

ADM515

3-48

Datenbankparameter

Die Zahl der Parameter wurde zugunsten der TCO reduziert und auf Automatismen verlagert Parameter werden verwendet für Einstellungen der Systemkonfiguration „ Caches und andere Speicherstrukturen „

Threading, CPU-Auslastung „ I/O, Kommunikation über SQL „

„ „

Logging-Strategien Optimierer-Funktionen (für SQL-Anweisungen)

Der Speicherverbrauch der Datenbank wird über Datenbankparameter gesteuert.

© SAP 2008 / Page 1

Die Software wird mit den jeweils optimalen Werten abhängig von der Betriebssystemplattform ausgeliefert. „ Größenangaben werden in Datenseiten (Pages) oder kByte gemacht. Näheres zu den Einheiten kann z.B. in den Parameterbeschreibungen gefunden werden. „ Durch vordefinierte Abhängigkeiten und Beziehungen zwischen Parametern, werden viele der vorhanden Parameter automatisch bereichnet und müssen daher nicht explizit gesetzt werden. „

© SAP AG

ADM515

3-49

Parameterklassifizierung

© SAP 2008 / Page 1

„

Datenbankparameter sind in drei Klassen eingeteilt: y Allgemeine Parameter (General) Diese Parameter werden vom Datenbankadministrator eingestellt. y Spezielle Parameter (Extended) Diese Parameter werden in Absprache mit dem MaxDB-Support oder gemäß der Anleitung in Hinweisen vom Datenbankadministrator gesetzt. y Support-Parameter Diese Parameter werden vom MaxDB-Support oder den Entwicklern eingestellt.

© SAP AG

ADM515

3-50

Parameterhistorie

© SAP 2008 / Page 1

Das Database Studio bietet auch eine Historie für die Parameter an. „ Hier können Sie die Veränderungen der Parameter seit Anlegen der Datenbankinstanz auf diesem Server verfolgen. y Zum Beispiel kann an der Historie des Parameters KernelVersion nachvollzogen werden, wann und welche Datenbankversion durch einen Patch erhöht wurde. „

© SAP AG

ADM515

3-51

Parametersuche

© SAP 2008

Sehr praktisch zum Finden von Parametern ist der neue Bereich View All in Kombination mit dem Filter-Feld. Hier können Sie auch Bruchstücke von Parametern eingeben und das Database Studio zeigt Ihnen dann alle Parameter mit diesem Testbruchstück an. „ Alternativ ist es möglich mit dem dbmcli-Kommando param_getfull zusammen mit der alten Parameterbezeichnung von MaxDB <= 7.6 den neuen Parameternamen zu erhalten: dbmcli -U c param_getfull MAXLOCKS „

OK int 2500 4040 ID CHANGE INTERN MANDATORY CLEAR DYNAMIC CASESENSITIVE DEVSPACE MODIFY GROUP DISPLAYNAME VALUESET MAX MIN INSTANCES SCOPE DEPRECATEDID USERDEFINED CLASS LASTKNOWNGOOD ACTIVEVALUE

MaxSQLLocks OFFLINE NO YES NO NO NO NO YES GENERAL

INSTANCE MAXLOCKS NO GENERAL TRANSACTIONS SYNCHRONISATION 4040 4040

… © SAP AG

ADM515

3-52

Wege zur Parameteränderung

Database Studio

Parameter

Database Manager CLI

Beispiel im Database Manager CLI: Aufrufen

dbmcli –d <SID> –u user,password

Alle anzeigen

param_directgetall

Anzeigen

param_directget CacheMemorySize

Ändern

param_put CacheMemorySize 100000

Prüfen (wichtig!)

param_checkall

Wirksam nach Neustart aus dem Zustand OFFLINE © SAP 2008

Mit dem Database Studio können Sie Parameterwerte lesen und ändern. Die Änderungen können teilweises sofort aktivert oder werden erst durch einen Restart der Datenbankinstanz aus dem Status OFFLINE gültig. „ Mit dem Database Manager CLI ändern Sie Parameter direkt oder in einer Parametersitzung. Bei einer Parametersitzung werden die gesamten Änderungen durch ein COMMIT gültig oder durch einen Abbruch (ABORT) ungültig, also zurückgesetzt. param_startsession startet eine Parametersitzung param_commitsession beendet die Sitzung und speichert die neuen Werte param_abortsession bricht die Sitzung ab und verwirft die Änderungen param_getvalue zeigt einen Parameterwert an param_put ändert den Wert eines Parameters param_restore setzt die Parameter auf alte Werte zurück help param zeigt weitere Kommandos an „

y Nach Parameteränderungen prüfen Sie die neuen Werte mit param_checkall. Dabei berechnet das System abhängige Parameter neu. Wenn param_checkall nicht durchgeführt wurde, taucht beim nächsten Restart u.U. der Fehler „Shareddynpool too small“ auf. „ Das Database Studio führt diese Parameterprüfung (param_checkall) automatisch durch. Die Parameterdatei wird im Binärformat abgelegt: /config/ „ Bei jeder Parameteränderung wird eine Sicherung angelegt: . „ Mit dem dbmcli-Kommando param_restore kann eine, zwei oder mehr Generationen zurückgesprungen werden. Bitte beachten Sie dabei, daß in der Zwischenzeit weitere Volumes o.ä. angefügt wurden, die dann manuell nachgetragen werden müssen. „

© SAP AG

ADM515

3-53

Neue Parameternamen

UKT- und Task-Konfiguration MaxCPUs MaxUserTasks SessionTimeout

UKT1 Console UKTn Console UKT1 UKTn

MaxExclusiveLockCollisionLoops

Requestor Coordinator Requestor Coordinator

Caches und Memory-Größen CacheMemorySize CAT_CACHE_SUPPLY UseSharedSQL

Sperrverhalten I/O-Buffer-Cache I/O-Buffer-Cache Catalog-Cache Catalog-Cache

MaxSQLLocks RequestTimeout DeadlockDetectionLevel

SharedSQL SharedSQL & & Hashing Hashing

.

LOG'

Volume-Parameter

DATA n

LOG DATA 1

Analyse

.

MaxLogVolumes AutoLogBackupSize LogQueues LogQueueSize

MaxDataVolumes

FormatDataVolume VolumeFormattingMode

Sicherungsmedien

RunDirectoryPath KernelMessageFileSize DiagnoseHistoryPath

MaxBackupMedia

© SAP 2008

„

Die folgenden Parameter sind besonders wichtig: y MaxCPUs Anzahl der CPUs, auf welche die User-Tasks verteilt werden y MaxUserTasks Maximale Anzahl paralleler Benutzersitzungen y SessionTimeOut Nach welcher Zeit der Inaktivität wird eine Session beendet y CacheMemorySize Größe des Data-Cache (in 8 KB-Seiten) y CAT_CACHE_SUPPLY Größe des Catalog-Cache für alle User-Tasks (in 8 KB-Seiten) y UseSharedSQL Wird SharedSQL verwendet? y HashedResultsetCacheSize Wie groß ist der Speicherbereich für das Hashing bei SQL y RequestTimeout Maximale Wartezeit auf die Freigabe einer Sperre (in Sekunden) y DeadlockDetectionLevel Analysetiefe bei der Deadlock-Erkennung y MaxSQLLocksBegrenzung der Anzahl möglicher Sperren auf Tabellen und Zeilen y MaxDataVolumes Maximale Anzahl der Data-Volumes y MaxLogVolumes Maximale Anzahl der Log-Volumes y AutoLogBackupSize Definiert die maximale Größe der einzelnen Log-Sicherungsdateien y LogQueues Wieviele Log-Queues werden verwendet? y LogQueueSize Größe der Log-Queues y UseLobClustering Binärdaten als Blobs auf den Daten-Volumes in Clustern halten y MaxBackupMedia Maximale Anzahl der parallelen Backup-Medien y RunDirectoryPath Arbeitsverzeichnis der DB-Instanz, Ablage von Diagnosedateien y KernelMessageFileSize Größe der Diagnosedatei knlMsg (im Arbeitsverzeichnis) y DiagnoseHistoryPath Definiert die Lage der Diagnosedateien, die nach einem Absturz extra gesichert werden

© SAP AG

ADM515

3-54

Online änderbare Datenbankparameter

„ Viele

Datenbankparameter können während des Betriebs im Online-Modus geändert werden.

„ Generell

ist dieses Feature für alle Parameter denkbar, die keine Änderung im Speicherlayout nach sich ziehen, wie z.B. Optimizer-Verhalten, Trace- oder Analyseeinstellungen

„ Mit

einem “Running” in den Parametereinstellungen wird diese Möglichkeit angezeigt

„ Desweiteren

können nun Informationen zu dem Hintergrund der Parameteränderung direkt bei den Parametern hinterlegt werden

dbmcli –U c … param_put [] <parameter_name> [] ::= -running | -permanent | -running –permanent

© SAP 2008 / Page 1

© SAP AG

ADM515

3-55

Online änderbare Datenbankparameter „ Eine

komplette Liste der Datenbankparameter, die online änderbar sind, kann über die Systemtabelle ACTIVECONFIGURATION ermittelt werden.

„ Die

Spalte CHANGEABLE zeigt dieses mit einem YES an.

„ Die

alten Datenbankparameter werden hier mit einem YES unter DEPRECATED markiert

© SAP 2008

© SAP AG

ADM515

3-56

Allgemeiner MaxDB Parametercheck

„ Bei

Bedarf kann das aktuelle Setup der Datenbankparameter mit dem Datenbank Analyzer überprüft werden.

„ Als

Ergebnis wird eine Liste von empfohlenen Parameteränderungen ausgegeben.

„ Weiteres

zu dem Parameter-Check per DB Analyzer im SAP Hinweis 1111426.

„ Die

im Hinweis enthaltenen Dateien dbanalyzer.cfg liefert aktualisierte Parameterempfehlungen.

„ Das

dbmcli-Kommando param_getfull zeigt den „alten“ und „neuen“ Parameternamen an.

© SAP 2008

„Alte“ und „Neue“ Parameternamen anzeigen: dbmcli – U c param_getfull <Parametername> „ Beispiel: dbmcli – U c param_getfull CACHE_SIZE … ID CacheSizeMemory … DEPRECIATED CACHE_SIZE … „

© SAP AG

ADM515

3-57

MaxDB betreiben: Übersichtsdiagramm

MaxDB betreiben Thema 1: Überblick Database Studio Thema 2: Wichtige Informationsquellen im Database Studio Thema 3: Benutzer der MaxDB im SAP-Umfeld Thema 4: Plattenbereiche für Daten und Log Thema 5: Konfigurationsänderungen Thema 6: DBFULL und LOGFULL Situationen Thema 7: Datenbankparameter Thema 8: Übungswerkzeug

© SAP 2008

© SAP AG

ADM515

3-58

Tools für Übungen

„

Einstellung des Shell-Environments (bereits voreingestellt): set PYTHONPATH=G:\sapdb\<SID>\db\lib\python2.3

„

Alle Python-Kommandos (x_python) müssen Sie im Verzeichnis %PYTHONPATH% ausführen. cd \d %PYTHONPATH%

„

Auffüllen der Data- und Log-Volumes: x_python filldb.py -d <SID> -u <sql-user>,<password> -data x_python filldb.py -d <SID> -u <sql-user>,<password> -log

„

Weitere Optionen: x_python filldb.py -help

© SAP 2008

„

Die Ablage der Testdaten mit dem Tool erfolgt in der Tabelle FILLTABLE.

© SAP AG

ADM515

3-59

MaxDB betreiben: Zusammenfassung

Sie können nun: „

Das Database Studio bedienen und kennen wichtige Informationsquellen

„

Können Ausnahmesituationen des Datenbankbetriebs beheben

© SAP 2008 / Page 1

© SAP AG

ADM515

3-60

Übungen Kapitel: 2 Thema: MaxDB betreiben Am Ende dieser Übungen können Sie: • Die Konfiguration der Datenbank <SID> verändern oder erweitern, um sie den Bedürfnissen des Datenbankbetriebs anzupassen. • Außerdem können Sie die ersten Ausnahmesituationen meistern.

Im normalen Datenbankbetrieb sind Anpassung der Konfiguration durch wachsende Bedürfnisse der Anwendungen notwendig. Die Möglichkeiten der MaxDB werden hier vorgestellt und praktisch durchgeführt.

2-1

Einrichten der Anmeldeautomatisierung mit dem Xuser-Tool 2-1-1

Anmeldung am Datenbankserver per Console (Telnet)

2-1-2

Führen Sie das Tool xuser aus und kontrollieren die hinterlegten Userkeys.

2-1-3

Tragen Sie die folgenden Standardeinträge in das Tool xuser ein, falls sie noch nicht vorhanden sind (Hinweis 39439): Userkey

UserID

Password

ServerDB

Servernode

SQLmode

DEFAULT

SAP<SID>

sap

T<xx>



SAPR3

c

CONTROL

control

T<xx>



INTERNAL

w

SUPERDBA

admin

T<xx>



INTERNAL

domain

DOMAIN

domain

T<xx>



INTERNAL

<SID>

SAP<SID>

sap

T<xx>



INTERNAL

Bitte entnehmen Sie die Syntax des Tools xuser aus dem Kapitel 2. 2-1-4

© SAP AG

Testen Sie die eingetragenen Daten durch Ausführung des folgenden Kommandos: dbmcli -U c db_state und dbmcli -U c –USQL DEFAULT sql_execute “select * from users“ oder sqlcli -U DEFAULT “select * from users“ Welche Ausgaben erhalten Sie bei diesen Kommandos?

ADM515

3-61

2-2

2-3

2-4

2-5

Starten des Database Studios und Ermittlung von Tabellendaten 2-2-1

Starten Sie das Database Studio

2-2-2

Verbinden Sie sich mit Ihrer Datenbank <SID> auf dem Datenbankserver und öffnen über das Kontextmenü einen SQL-Editor. Bei der Ausführung des Kommandos über das Ausrufezeichen (!) nutzen Sie den User SAP<SID> und dessen Standardpaßwort.

2-2-3

Setzen Sie das SQL-Kommando select * from users ab und kontrollieren die User in der Datenbank

Umbenennen eines Datenbankusers 2-3-1

Nutzen Sie den SQL-Editor im Database Studio um den Datenbanknutzer SAP<SID> umzubenennen. Melden Sie sich dazu mit dem superdba-User an.

2-3-2

Benennen Sie den User SAP<SID> zuerst mit dem Kommando rename user sapt<xx> to sapr3 um.

2-3-3

Alternativ: Benennen Sie den User per dbmcli um dbmcli -U c –USQL w sql_execute “<SQL-Statement>“

2-3-4

Machen Sie Ihre Änderungen wieder rückgängig rename user sapr3 to sapt<xx> dbmcli -U c –USQL w sql_execute “<SQL-Statement>“ um die SQL-Kommandos aus der vorherigen Übung an die Datenbank zu schicken.

Die Xuser-Funktionalität nach Änderung des Paßwortes vom User SAP<SID> 2-4-1

Melden Sie sich als User SAP<SID> am SQL Editor des Database Studios an. Ändern Sie das Paßwort des Users SAP<SID> mit dem SQL-Kommando alter password <current> to

2-4-2

Testen Sie die automatisierte Anmeldung erneut mit dbmcli -U c –USQL DEFAULT sql_execute “select * from users“

2-4-3

Passen Sie die Xuser-Daten dem geänderten Paßwort an und testen erneut.

Wiederherstellen der ursprünglichen Einstellung für weitere Übungen 2-5-1

2-6

© SAP AG

Ändern Sie das Paßwort des Users SAP<SID> z.B. mit dbmcli wieder zurück auf den vorherigen Zustand (Default-Paßwort: sap), damit die weiteren Übungen wie vorbereitet durchgeführt werden können.

Überprüfen Sie mit dem Database Studio die Konfiguration der Datenbank <SID> 2-6-1

An welcher Stelle liegen die Daten- und Log-Volumes?

2-6-2

Wo ist die instanzabhängige Software zu Ihrer Instanz und die übergreifenden Teile der Software zu finden?

2-6-3

Wo finden Sie die Konfigurations- und Protokolldateien? ADM515

3-62

2-7

2-8

2-9

2-10

Ermitteln Sie die Liste der Tasks der Datenbank 2-7-1

Um einen Überblick über die Task in der Datenbank zu erhalten, zeigen Sie sich die Liste aller Tasks (TASKS) und alternativ nur der aktiven Tasks (ACTIVE) im Database Studio an.

2-7-2

Alternativ können Sie sich diese Liste auch auf der Konsole mit dbmcli -U c show tasks oder dbmcli -U c show active anzeigen.

Ermitteln Sie die Liste der Parameter 2-8-1

Ermitteln Sie die Liste aller Parameter über das Database Studio

2-8-2

Führen Sie das entsprechende dbmcli-Kommando aus um die Liste der Parameter zu erhalten.

2-8-3

Sind alle Parameter der dbmcli-Kommandoausgabe im Bereich der Parameterverwaltung des Database Studios zu finden?

Anpassen von Parametern und deren Aktivierung 2-9-1

Notieren Sie den aktuellen Wert für den Parameter MaxUserTasks und verändern ihn auf 2 um damit z.B. ein Fehlen von freien Usertasks zu simulieren.

2-9-2

Starten Sie die Datenbank durch, damit die Änderungen aktiv werden.

2-9-3

Überprüfen Sie durch Starten mehrere dbmcli-Sessions, ab wann die Verbindung zur Datenbank nicht mehr möglich ist. dbmcli –U c –USQL DEFAULT [ENTER-Taste]

2-9-4

Ändern Sie den Parameter mit dem dbmcli wieder in den Urzustand zurück. Was ist dabei zu beachten, damit die Parameterumsetzung vollständig durchgeführt wird?

Ermitteln Sie wichtige Installationsdaten der Datenbankinstanz mit Hilfe des dbmcli 2-10-1 Ermitteln Sie den Pfad IndepDataPath und IndepProgPath mit Hilfe des dbmcli. 2-10-2 Wie lautet das INSTROOT Ihrer Datenbankinstanz (Ermittlung mit dbmcli).

2-11

Informationen zu den Daten- und zum Log-Bereichen 2-11-1 In der Datenbank sind bereits einige Informationen in übersichtliche Listen aufbereitet. Eine Liste der verfügbaren Informationen erhalten Sie mit dbmcli –U c info infos 2-11-2 Überprüfen Sie die Ausgaben der Kommandos dbmcli -U c info data bzw. dbmcli –U c info log Können Sie diese Informationen auch im Database Studio finden?

© SAP AG

ADM515

3-63

2-12

Anfügen von Volumes 2-12-1 Vergrößern Sie unter Verwendung des Database Studio die Datenbank im laufenden Betrieb um 100%. 2-12-2 Legen Sie das Daten-Volume an dem Ort der bisherigen Daten-Volumes an. 2-12-3 Was kann die Erweiterung der Datenbank bremsen? 2-12-4 Löschen Sie das gerade angelegte Volume wieder.

2-13

Füllen der Datenbank und Simulation einer DB FULL-Situation Mit Hilfe der Kommandos cd /d %PYTHONPATH% x_python filldb.py –d <SID> -u sarp<sid>,sap –data können Sie die Datenbank füllen. Mit der Option –R können Sie die Pakete vergrößern, die in die Datenbank gepumpt werden. Führen Sie dieses Kommando so lange aus, bis die Ausführung des Kommandos schließlich während der Ausführung stehen bleibt. Zusätzlich gibt auch das filldb.py einen Füllgrad der Datenbank aus. 2-13-1 Den Status des Datenbereichs können Sie währenddessen mit dem Database Studio überwachen. Analysieren Sie die DBFULL-Situation mit den in den Unterlagen beschriebenen Methoden.

2-14

Behebung der DB FULL-Situation durch Erweitern der Datenbank 2-14-1 Erweiteren Sie nach Schulungsunterlagen die Datenbank während des laufenden Betriebs um ein weiteres Daten-Volume und beobachten sowohl die Kommandozeile als auch das Database Studio.

2-15

Erzeugung der LOG FULL-Situation mit anschließender Bereinigung Achtung: Damit Sie eine LOG FULL Situation simmulieren können deaktivieren Sie zunächst die automatische Log-Sicherung. Mit Hilfe des Kommandos x_python filldb.py –d <SID> -u sarp<sid>,sap –log können Sie den Log der Datenbank füllen. Mit der Option –R können Sie die Pakete vergrößern. Führen Sie dieses Kommando so lange aus, bis es schließlich während der Ausführung stehen bleibt. Den Status des Logbereichs können Sie währenddessen mit dem Database Studio überwachen. 2-15-1 Erweiteren Sie nach Schulungsunterlagen die Datenbank während des laufenden Betriebs um ein weiteres Log-Volume und beobachten sowohl die Kommandozeile als auch das Database Studio. Löst diese Erweiterung das Problem? 2-15-2 Sollte die Aktion die Situation nicht bereinigen (nur in Spezialfällen funktioniert dies) aktivieren Sie die automatische Log-Sicherung. Anschließend sollte das Fülltool auf der Konsole wieder in die Datenbank schreiben können.

© SAP AG

ADM515

3-64

2-16

Optional: Wechsel des Log-Modus 2-16-1Wechseln Sie wie in den Unterlagen beschrieben den Log-Modus auf Überschreiben des Logs und zurück. 2-16-2 Welche Auswirkungen sehen Sie in der Sicherungshistorie?

© SAP AG

ADM515

3-65

© SAP AG

ADM515

3-66

Lösungen Kapitel: 2 Thema: MaxDB betreiben

2-1

2-2

© SAP AG

Einrichten der Anmeldeautomatisierung mit dem Xuser-Tool 2-1-1

Öffnen Sie die Console (Telnet) zum Datenbankserver.

2-1-2

Die folgende Pflege der Paßworte in dem Xuser-Bereich muß für jeden User erfolgen, der diesen Logonautomatismus an die Datenbank nutzen möchte. Wurde der erste Logon mit einem anderen User durchgeführt, können Sie diesen durch Anpassen des ersten (DEFAULT) Userkeys wieder korrigieren. Die Anzeige der bisher vorhandenen xuser-Einträge erfolgt mit xuser list. Mit xuser –h erhalten sie eine ausführliche Hilfe.

2-1-3

Die SAP-Anwendungen nutzen für die Anmeldung an die Datenbank grundsätzlich die Xuser-Funktionalität. Der übliche Kontakt erfolgt über den DEFAULT-Userkey. Einzig im CCMS-Umfeld werden noch weitere (c-,w-) Userkeys benötigt, um weitergehende Informationen aus der Datenbank zu ermitteln. Bitte beachten Sie, daß die Userkey „case sensitive“ sind.

2-1-4

Die Ausführung der Kommandos nutzt jeweils den c-Userkey zur Anmeldung. Bei dem zweiten Kommando wird zusätzlich eine implizite Anmeldung über den DEFAULT-Userkey vorgenommen, um anschließend das SQL-Statement an die Datenbank zu schicken.

Starten des Database Studios und Ermittlung von Tabellendaten 2-2-1

Auf dem Terminalserver ist das Database Studio installiert und muß über den Menüpfad Start → Training → MaxDB → Database Studio aufgerufen werden.

2-2-2

Melden Sie sich an die Datenbank über das Kontextmenü einen SQLEditor. Bei der Ausführung des Kommandos über das Ausrufezeichen (!) nutzen Sie den User SAP<SID> und dessen Standardpaßwort. Der Administrationsuser control besitzt nicht die Berechtigung, SQLStatements auf der Datenbank auszuführen.

2-2-3

Bei dem Objekt users handelt es sich um einen View auf interne Strukturen. Daher lassen sich diese Daten nur einsehen und nicht verändern. Über die Baumstruktur des Database Studios haben Sie Einblick in weitere Systemtabellen der MaxDB.

ADM515

3-67

2-3

2-4

2-5

Umbenennen eines Datenbankusers 2-3-1

Öffnen Sie einen SQL-Editor im Database Studio im Kontextmenü Ihrer Instanz. Verwenden Sie anschließend zur Ausführung der folgenden SQLKommandos den User superdba mit dem Standardpaßwort admin.

2-3-2

Nutzen Sie den SQL-Editor und geben das SQL-Statement rename user sap<sid> to sapr3 ein. Anschließend nutzen Sie das rote Ausrufezeichen um das SQLStatement auszuführen.

2-3-3

Das dbmcli-Kommando lautet vollständig: dbmcli -U c –USQL w sql_execute “rename user sap<sid> to sapr3“

2-3-4

Machen Sie Ihre Änderungen mit dem Kommando rename user sapr3 to sap<sid> wieder rückgängig.

Die Xuser-Funktionalität nach Änderung des Paßwort vom User SAP<SID> 2-4-1

Öffnen Sie einen neuen SQL -Editor im Database Studio. Mit dem neuen SQL-Editor können Sie auch einen neuen Connect-User beim späteren Logon angeben, hier dann den User sap<sid>. Führen Sie das SQLKommando unter dem User SAP<SID> alter password <current> to aus. Alternativ können Sie auch das dbmcli-Kommando dbmcli -U c –USQL DEFAULT sql_execute “alter password <current> to “ verwenden.

2-4-2

Die Verbindung sollte nun mit den alten Xuserdaten nicht mehr funktionieren.

2-4-3

Nach Anpassung in der zuvor beschrieben Vorgehensweise mit dem XuserTool wird die Verbindung zur Datenbank über diese Automatisierung wieder funktionieren. Sie müssen die Xuser-Daten mit dem Tool xuser für den DEFAULT-Eintrag an das neue Paßwort des SAP<SID> anpassen.

Wiederherstellen der ursprünglichen Einstellung für weitere Übungen 2-5-1

2-6

© SAP AG

Verwenden Sie die gleiche Syntax um den ursprünglichen Zustand der Paßwörter auf der Datenbank und in den Xuser-Daten wieder herzustellen.

Überprüfen Sie mit dem Database Studio die Konfiguration der Datenbank <SID> 2-6-1

Daten-Volumes: Log-Volumes:

G:\sapdb\<SID>\sapdata\... G:\sapdb\<SID>\saplog\...

2-6-2

Instanzabhängige Software: Instanzunabhängige Software:

G:\sapdb\<SID>\db\... G:\sapdb\programs\...

2-6-3

Konfigurationsdateien: G:\sapdb\data\config\... Instanzübergreifende Protokolle: G:\sapdb\data\wrk\... Instanzabhängige Protokolle: G:\sapdb\data\wrk\<SID>\... ADM515

3-68

2-7

2-8

Ermitteln Sie die Liste der Task der Datenbank 2-7-1

Der Menübaum unterhalb des CONTROL-Users zu Ihrer Datenbankinstanz finden Sie die Einträge: Database Server → TASKS bzw. Database Server → ACTIVE

2-7-2

Es handelt sich hierbei um die gleiche Ausgabe wie im x_cons <SID> show tasks oder show active.

Ermitteln Sie die Liste der Parameter 2-8-1

Im Administrationsbereich zu Ihrer Instanz im Database Studio Parameter

→ View All

2-9

© SAP AG

2-8-2

Das entsprechende Kommando mit dem dbmcli: dbmcli -U c param_directgetall

2-8-3

Beim ersten Aufruf der Parameter in dem Database Studio wird zuerst nur die Liste der allgemeinen Parameter gezeigt. Erst durch Anwahl der weiteren Menüpunkte werden die restlichen Parameterbereiche oder die Gesamtliste gezeigt. Die Besonderheit mit dem Database Studio ist nun, daß die Gesamtliste mit Namensbruchstücken gefiltert werden kann.

Anpassen von Parametern und deren Aktivierung 2-9-1

Wählen Sie den Administrationsbereich für Ihre Instanz an und editieren den Parameter MaxUserTasks entsprechend der Aufgabenstellung.

2-9-2

Nach Änderung des Parameter speichern Sie den Parameter und starten die Datenbank mit Set State → Offline und anschließend Set State → Online. wieder in Status Online. Hier können Sie auch das dbmcli verwenden mit den Kommandos: dbmcli -U c db_offline und dbmcli -U c db_online

2-9-3

Öffnen Sie mehrere Konsolen zu dem Datenbankserver und verbinden sich jeweils mit dbmcli -U c –USQL DEFAULT [Enter-Taste] an die Datenbank. Es ist nur die von Ihnen eingerichteten Verbindungszahl zur Datenbank möglich.

ADM515

3-69

2-9-4

2-10

Beenden Sie alle dbmcli-Sessions durch Eingabe eines exit an dem dbmcli-Prompt und führen das Kommando dbmcli -U c param_put MaxUserTasks aus. Zu beachten ist, daß bei der Verwendung von dbmcli nach Veränderung der Parameter ein Check der Parameterabhängigkeiten durchzuführen ist. Dieser Check sammelt ebenfalls die intern benötigten Speicherbedarfe und fordert diesen Bedarf beim Neustart und Umsetzen der Parameteränderung in der richtigen Größe an. Auszuführen ist der Parameter-Check mit dbmcli -U c param_checkall (Das Database Studio führt diesen Check automatisch durch) Abschließend starten Sie bitte die Datenbank neu: dbmcli -U c db_offline und dbmcli -U c db_online

Ermitteln Sie die wichtige Installationsdaten der Datenbankinstanz mit Hilfe des dbmcli 2-10-1 Die dbmcli-Kommandos lauten: dbmcli dbm_getpath IndepDataPath und dbmcli dbm_getpath IndepProgPath 2-10-2 Kommando zur Emittlung der Information: dbmcli -U c dbm_version INSTROOT.

2-11

Informationen zu den Daten- und zum Logbereichen 2-11-1 Die Option –c des dbmcli bedeutet hier, daß anschließend das eigentliche Kommando beginnt, das der dbmcli weiterverarbeiten muß. 2-11-2 Die Infos und mehr können im Database Studio auch im Administrationsbereich unter → Data Area bzw. → Log Area gefunden werden.

2-12

Anfügen von Volumes 2-12-1 Im Administrationsbereich zu Ihrer Instanz im Database Studio Parameter → View All Liste der Parameter: MaxDataVolumes MaxLogVolumes Notieren Sie hier die aktuellen Werte.

© SAP AG

ADM515

3-70

2-12-2 Im Administrationsbereich Ihrer Instanz im Database Studio → Data Area Wählen Sie einen noch nicht genutzen aber vorbereiteten Volume-Eintrag und betätigen Sie die Drucktaste New. Richten Sie das Volume in dem Unterverzeichnis G:\sapdb\<SID>\sapdata\ ein. 2-12-3 Nach Ausnutzung des letzten reservierten Volume wird der Parameter MaxDataVolumes automatisch bei der Einrichtung des Volume um eins erhöht. Diese Parameteränderung wird dann aber erst aktiv, wenn ein Neustart der Datenbank stattfindet. Gleiches gilt für MaxLogVolumes. Mit MaxDB 7.7.04 ist es aber nicht mehr speicherlastig, diese Parameter sehr groß oder auf das Maximum von 255 einzustellen. 2-12-4 Zum Löchen eines Volumes markieren Sie dieses und betätigen die Drucktaste Delete. 2-13

Füllen der Datenbank und Simulation einer DB FULL-Situation Mit x_python filldb.py –help erhalten Sie weitere Optionen 2-13-1 Analyse im Instanzenbaum des Database Studios unterhalb des CONTROL-Users Database Server → ACTIVE oder über die Konsole mit dbmcli -U c show active

2-14

Behebung der DB FULL-Situation durch Erweitern der Datenbank 2-14-1 Gehen Sie bitte wie unter 2-13 vor. Die Fülltool bleibt solange ohne Aktivität in der Konsole stehen, bis man erkennt, daß der Volume im Database Manager GUI vollständig in die Volume-Verwaltung eingebaut wurde.

2-15

Erzeugung der LOG FULL-Situation mit anschließender Bereinigung Damit Sie eine LOG FULL Situation simmulieren können deaktivieren Sie zunächst die automatische Log-Sicherung. Im Administrationsbereich zu Ihrer Instanz im Database Studio Overview → Settings doppelkilick auf Automatic Log Backup. Dann Deactivate automatic log Backup markieren und Drucktaste Deactivate betätigen. 2-15-1 Normalerweise sollte dieses Vorgehen nicht zum Erfolg führen, wie in den Unterlagen ausführlich beschrieben wird. Nur in Spezialfällen kann es helfen.

© SAP AG

ADM515

3-71

2-15-2 Automatische Log-Sicherung aktivieren: Im Administrationsbereich zu Ihrer Instanz im Database Studio Overview → Settings doppelkilick auf Automatic Log Backup. Dann Activate automatic log Backup markieren und Drucktaste Activate betätigen. Für den Fall, daß die Sicherungshistorie durch das bisherige Umkonfigurieren der Datenbank zerstört wurde, fehlt nun eine initiale Datenvollsicherung als Basis für für die Logsicherung. Daher kann eine Logsicherung nicht gestartet werden und es bleibt nichts anderes übrig, als die Datenbank mit db_offline (dbmcli -U c db_offline) zu beenden. Starten Sie dann nach Admin (dbmcli -U c db_admin) und führen die Daten- und Logsicherung durch. Anschließend können Sie die Datenbank wieder nach Online (dbmcli -U c db_online) starten.

2-16

Optional: Wechsel des Log-Modus 2-16-1 Starten Sie Administrationsbereich für Ihre Datenbankinstanz und wechseln in den Menübereich für → Log Area. Wählen Sie den Hyperlink hinter dem Begriff Overwrite Mode: an und folgen Sie dem Wizard wir in den Unterlagen beschrieben. Während der Umstellung wird die Datenbankinstanz durchgestartet. Folgen Sie dem Wizard erneut um diese Einstellung wieder zurückzunehmen. Beachten Sie anschließend dringend auch die Sicherungshistorie.

© SAP AG

ADM515

3-72

MaxDB-Interna

Inhalt: „

Tiefer Einblick in den technischen Hintergrund der MaxDB

© SAP 2008 / Page 1

© SAP AG

ADM515

4-1

MaxDB-Interna: Lernziele

Am Ende dieses Kapitels, können Sie: „

Den technischen Hintergrund der MaxDB erläutern

© SAP 2008 / Page 1

© SAP AG

ADM515

4-2

Agenda I

1. Der erste Kontakt 1.1. 1.2. 1.3. 1.4. 1.5. 1.6.

3. MaxDB-Interna

Einführung Werkzeuge und Schnittstellen Architektur und Betriebszustände MaxDB und SAP NetWeaver Integration mit SAP NetWeaver Serverlandschaft der Schulung

3.1. 3.2. 3.3. 3.4 3.5.

4. Datenbanksicherung und -wiederherstellung

2. MaxDB betreiben 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8.

Prozesse Sperren Speicherbereiche Plattenbereiche Logging

Überblick Database Studio Wichtige Informationsquellen im Database Studio Benutzer der MaxDB im SAP-Umfeld Plattenbereiche für Daten und Log Konfigurationsänderungen DBFULL und LOGFULL Situationen Parameter Übungswerkzeug

4.1. 4.2. 4.3. 4.4. 4.5. 4.6. 4.7. 4.8.

Vollständige Datensicherung Inkrementelle Datensicherungen MaxDB Snapshots Log-Sicherungen Automatische Log-Sicherung Überprüfen der Sicherungen Sicherungsstrategie Externe Sicherungstools

© SAP 2008

© SAP AG

ADM515

4-3

Agenda II

5.

Weitere Administrationsthemen 5.1. 5.2. 5.3. 5.4. 5.5. 5.6. 5.7.

7.

Prüfen der Datenbank Erstellen einer Datenbankinstanz Neuinitialisierung einer Datenbankinstanz Installation eines Patches (Releasewechsel) Migration zur MaxDB Hochverfügbarkeit MCOD

Ausblick auf MaxDB 7.8 7.1. 7.2. 7.3. 7.4. 7.5.

Übersicht Änderungen des Datenbankkerns Neue administrative Funktionen Setup und Infrastruktur Interface & User

6. Performance-Tuning und Problemsituationen 6.1. 6.2. 6.3. 6.4. 6.5. 6.6.

B*-Bäume Optimierung Monitore des SAP NetWeaver Vermeidbare Probleme Diagnosedateien und TraceMöglichkeiten Fehlerarten und deren Analyse

© SAP 2008

© SAP AG

ADM515

4-4

MaxDB-Interna: Übersichtsdiagramm

MaxDB-Interna Thema 1: Prozesse Thema 2: Sperren Thema 3: Speicherbereiche Thema 4: Plattenbereiche Thema 5: Logging

© SAP 2008

© SAP AG

ADM515

4-5

Laufzeitumgebung (LZU)

User-Kernel-Thread (UKT) User-Kernel-Thread (UKT) – Tasks:

Console

Garbage

Trace-Writer

Timer

Utility

Log-Writer

Pager Pager

Server Server

User User

Requestor IO-Threads

I/O Buffer Cache Catalog-Cache SharedSQL Hash Memory

Festplatten

Coordinator (Clock)

Caches

Prozesse

Prozesse

DATA

Log-Queue

LOG LOG

/sapdb Programme etc.

© SAP 2008

© SAP AG

ADM515

4-6

Prozeßüberblick

Coordinator

User-Kernel-Thread (UKT) Tasks

Requestor Console (Clock)

(IO-Threads) (IO-Worker)

User User

Timer

Trace-Writer

Server Server

Garbage

Log-Writer

Pager Pager

Utility

© SAP 2008 / Page 1

Der MaxDB-Datenbankkern läuft als ein Prozess, der in Threads unterteilt ist. Threads können innerhalb des Betriebssystems parallel auf mehreren Prozessoren aktiv sein. „ Es werden User-Kernel-Threads (UKTs) und Spezialthreads unterschieden. „ User-Kernel-Threads (UKT) bestehen jeweils aus mehreren Tasks (internes Tasking), die unterschiedliche Aufgaben erfüllen. Dieses Tasking erlaubt eine effektivere Koordination der Aufgaben als ein Betriebssystem-Tasking bei Verwendung einzelner Threads. „ Die Laufzeitumgebung (LZU, engl. Runtime Environment RTE) definiert die Struktur des Prozesses und der User-Kernel-Threads. „

© SAP AG

ADM515

4-7

Spezialthreads

Coordinator

Studio

Client Connect

Requestor Console

Restart

knlMSg

Clock / Timer

SELECT * FROM ..0,0005 sec.

IO-Threads

User Kernel Process (UKT)

User-Kernel-ThreadTasks (UKT) Tasks

(IO-Worker) User

Timer

Trace-Writer

Pager

Server

Garbage

Log-Writer

Utility

© SAP 2008

Beim Start der Laufzeitumgebung, d.h. beim Starten der Datenbankinstanz in den Zustand ADMIN, wird zuerst der Coordinator-Thread erzeugt. Dieser ist von besonderer Bedeutung. y Der Coordinator-Thread benutzt beim Start Datenbankparameter, um die Speicher- und Prozesskonfiguration der Datenbankinstanz zu ermitteln. y Der Coordinator-Thread koordiniert auch die Startvorgänge der anderen Threads und überwacht diese während des Betriebs der Datenbankinstanz. y Kommt es zu Betriebsfehlern, kann der Coordinator-Thread andere Datenbank-Threads stoppen. „ Der Requestor-Thread empfängt Anmeldungen der Benutzerprozesse an die Datenbank und ordnet sie einer Task innerhalb eines User-Kernel-Threads zu. „ Der Console-Thread sammelt für den Administrator wichtige Nachrichten von den anderen Threads in der Datei knlMsg, die im Arbeitsverzeichnis der Datenbankinstanz abgelegt ist. „ Der Clock- bzw. Timer-Thread dient der internen Zeitermittlung, um beispielsweise festzustellen, wieviel Zeit die Ausführung einer SQL-Anweisung benötigte. „

© SAP AG

ADM515

4-8

Spezialthreads – IO Management

Coordinator Requestor Console

User-Kernel-Thread (UKT) Tasks User

Timer

Trace-Writer

Pager

Server

Garbage

Log-Writer

Utility

Clock / Timer I/O Buffer Cache

Queues Volume 1 IO-Threads

prio low

prio med

(IO-Worker)

prio high

Queues Volume 2 prio low

prio med

prio high

Pool von I/O Threads Thread 1

Thread 2

Thread 3

Thread 4

Thread 5

Thread 6

Aufträge Daten

DATA

DATA

© SAP 2008

Mehrere IO-Threads sind für die Abwicklung der von den Tasks anfallenden Schreib- und Leseaufträge von Data- und Log-Volumes zuständig. MaxDB unterstützt asynchrone I/O-Aufträge. Mit 7.7.04 wurde das IO-System wesentlich flexibilisiert und die Vorraussetzungen geschaffen, auch unter Unix asynchrone IO unter den verschiedenen Unix-Derivaten nutzen zu können. Bei Microsoft Windows wird das asynchrone I/O des Betriebssystems schon länger genutzt. „ Die Anzahl der IO-Threads ist seit der Umstellung des IO-Systems mit 7.7.04 nicht mehr von der Anzahl der Volumes in der Datenbankinstanz abhängig. In der Regel werden für die Data-Volumes und jeden Log-Volume ein flexibler Pool an IO-Thread aktiviert, die mit einem Ticket-System gesteuert werden. Damit ist es auch möglich Queues mit verschiedenen Prioritäten auzubieten. Bei Nutzung der asynchronen I/O des Betriebssystems wird jeweils nur ein IO-Thread gestartet, da hier die asynchronen I/O-Aufrufe der Betriebsysteme die übrige Arbeit übernehmen. „ Die IO-Worker-Prozesse unter Windows übernehmen dann die Aufgabe der Signalübermittlung, wenn ein IO-Auftrag vom Betriebssystem als erledigt gemeldet wird. „ Mit der Neuimplementierung sind einige neue interne Parameter eingeführt worden, in die automatische Steuerung des IO-Managements eingreifen zu können. „

© SAP AG

ADM515

4-9

User-Kernel-Threads: User-Tasks

Coordinator Requestor

User-Kernel-Thread

UKT 2

User User User Tasks

User User user

90-95% der Last in der Datenbankinstanz wird hier erzeugt

Console Clock / Timer SELECT * FROM tab WHERE col1 = 5

IO-Threads Parameter: MaxCPUs (hier im Beispiel =2)

(IO-Worker)

Parameter: MaxUserTasks (hier im Beispiel =6) Parameter: MaxUserTaskStackSize (üblicherweise =1024) © SAP 2008 / Page 1

Jedem Benutzer bzw. jedem Anwendungsprozess wird bei der Anmeldung genau eine User-Task fest zugeordnet. Die maximale Anzahl der zur Verfügung stehenden User-Tasks ist vom Datenbankparameter MaxUserTasks abhängig. Dieser Parameter begrenzt damit auch die Anzahl der Benutzersitzungen, die gleichzeitig am Datenbanksystem möglich sind. „ Der Datenbankparameter MaxCPUs gibt an, auf wie viele User-Kernel-Threads die User-Tasks verteilt werden. Die User-Tasks erzeugen die Hauptlast. Alle andere sowie die globalen Threads verbrauchen sehr wenig CPU-Zeit. Durch den Parameter MaxCPUs kann also die Anzahl der von der Datenbankinstanz parallel genutzten Prozessoren begrenzt werden. „ Üblicherweise liegt die CPU-Belastung aber bei etwa 10-30% der Gesamtlast „ Mit dem Datenbankparameter MaxTaskStackSize (Default: 1024 KB) kann der Speicherverbrauch durch die Anzahl der User-Tasks abgeschätzt werden. Bei einem begrenzten Adressraum bzw. Speicherangebot sollte daher die Anzahl der User-Tasks nicht zu sehr über den Empfehlungen von zweimal die Anzahl der Workprozesse in den angeschlossenen Applikationsinstanzen liegen. „

© SAP AG

ADM515

4-10

User-Kernel-Threads: Task-Abfolge

Console Clock / Timer

User User User Tasks UKT 4 Pager Pager Pager

UKT 2

UKT 3

User User user

Server Server server

User Kernel Thread 1 Task1

IO System

Task2 Task3

I/O Anfrage 2

IO-Threads (IO-Worker)

1

I/O Anfrage 1

UKT 5

IO Thread

Requestor

User-Kernel-Thread

I/O Antwort 1

Floating Service Floating FloatingService Service

2 IO Thread

Coordinator

3 4 5

I/O Anfrage 3

Task running Task runable Task waiting

IO Thread

I/O Anfrage 1

IO Thread

I/O Antwort 2

6

t

© SAP 2008

Innerhalb der User-Kernel-Threads wird ein kooperatives Multitasking betrieben, während zwischen den Threads moderner Betriebssysteme ein präemptives Multitasking durchführen. „ Dies führt dazu, daß in den Threads immer nur ein Prozeß aktiv sein kann und einer oder mehrere User-Tasks innerhalb des gleichen UKT auf die Beendigung und Übernahme der Kontrolle auf dem UKT warten. „ Ab MaxDB 7.5 ist hier ein Parameter eingeführt worden, der das Verhalten ändern kann und auch innerhalb der UKTs auf präemptives Multitasking umschaltet. Dieser Parameter UseCoroutineForUserTask sollte aber nur bei liveCache-Instanzen oder auf Datenbanken auf NO gestellt werden, die auch liveCache-Funktionen übernehmen (Siehe auch SAP Hinweis 1038709 FAQ: MaxDB/liveCache OneDB Server). y Vorteil: Langlaufende User-Tasks mit livecache-Applikationsfunktionen (LCApps) können zwingend unterbrochen werden. y Nachteil: Stripes (Regionen) in der Datenbank können höhere Kollisionsraten beim Zugriff von User-Tasks zeigen (andere Datenbanken nennen diese Stripes auch Latches) „

© SAP AG

ADM515

4-11

Load Balancing für liveCache User-Kernel-Thread

UKT 2

Task aktiv Task startbereit

User User User User User

Task wartet z.B. auf IO

User User user user user

Task nicht genutzt

User-Kernel-Thread User User User User

Der gesamte Kontext des UserTasks wird transferiert

UKT 2 User User user user user User

Pro Aktion wird ein UserTask umgesetzt Für MaxDB (OLTP) ist diese Funktion zu langsam „

SQL-Statements sind üblicherweise schneller abgearbeitet als der Umschaltvorgang benötigt.

„

SQL-Statements benötigen häufig Plattenzugriffe, die automatisch einen Wechsel im UKT bewirkt

© SAP 2008 / Page 1

Im liveCache-Umfeld wird diese Funktion häufig eingesetzt um User-Tasks zwischen UKTs verschieben zu können. liveCache-Applikationsroutinen (LCApps) können über Stunden laufen und sehr viele Daten aus dem Cache verarbeiten. Dort lohnt es sich über eine Verlagerung auf unbelastete UKTs und damit CPUs nachzudenken. „ Nach dem Umschaltvorgang befindet sich der gesamte Kontext (Speicher usw.) des User-Tasks im Umfeld des neuen User-Kernel-Threads. „ Datenbankparameter die hier genutzt werden: y LoadBalancingCheckLevel – Mit Werten von 4 bis 600 Sekunden wird das Load-Balancing aktiviert. Der Wert stellt die Wartezeit zwischen Meßpunkten dar. y LoadBalancingWorkloadDeviation – Beschreibt den notwendigen internen Laufzeitunterschied der UKTs in Prozent, unter dem die UKTs als gleich angesehen werden (Default 5%). y LoadBalancingWorkloadThreshold – Lastunterschied in Prozent zwischen UKTs, bevor LoadBalancing überhaupt berücksichtigt wird (Default 10%). „ Weiteres zu dem Thema im TEWA60 (liveCache Monitoring und Performanceoptimierung) „

© SAP AG

ADM515

4-12

User-Kernel-Threads: Server-Tasks

Coordinator

User-Kernel-Thread

UKT 2

UKT 3

Requestor

User User User

User User user

Server Server server

Console Clock / Timer

Drop Table/Index

IO-Threads (IO-Worker)

DATA

Create Index

Check Data (Verify)

© SAP 2008

„

„

„ „

„ „

Server-Tasks dienen der Durchführung administrativer Aufgaben in der MaxDB Instanz. Einige Server-Tasks steuern das Lesen von den Daten-Volumes, andere steuern das Schreiben auf das Sicherungsmedium. Bei der CREATE INDEX- und asynchronen DROP INDEX- oder DROP TABLE-Anweisung werden die Server-Tasks beauftragt, die Tabellendaten parallel von den Daten Volumes zu lesen oder asynchron zu löschen. Auch die Ausführung des Check Data (Verify) wird durch die ServerTask betreut. Ab der MaxDB-Version 7.6.05 waren die Server-Tasks auch für das PreFetching zuständig. Diese Funktion wird auch in MaxDB 7.7 bald bereitgestellt (MaxDB 7.7.06). Das System berechnet die Anzahl der Server-Tasks bei der Konfiguration der Datenbankinstanz automatisch aus der Anzahl der Daten-Volumes und der Anzahl der vorgesehenen Sicherungsgeräte. Über den Parameter MaxServerTasks kann diese Anzahl höher eingestellt werden. Wie üblich werden die Lese- und Schreibaktionen nicht von den Server-Tasks selber erledigt, sondern an die IO-Threads übertragen. Ab MaxDB 7.5 ist es auch möglich, die Server-Tasks in speziellen Situationen, bei denen sich die Server Tasks nur noch gegenseitig blockieren, auf mehr UKTs und damit CPUs zu verteilen. Der MaxDB Parameter lautet hier EnableMultipleServerTaskUKT. Diese Möglichkeit wird meist bei der Migration genutzt.

© SAP AG

ADM515

4-13

Anhang: Neue ServerTask Typen

Anzeige

Langer Name

Beschreibung

"PrefBlb"

"Prefetch Blob"

Prefetch of BLOB when returning last part to appl.

"PrefSel"

"Prefetch Select“

Prefetching records when scanning

"PrefPag"

"Prefetch Pages"

"PrefOCo"

"Prefetch Objects Coordinator“

"AutoLgW"

"Autosave Log Writer“

Writes Log pages to the backup medium

"AutoLgW"

"Autosave Log Reader”

Reads Log pages from the log volumes

"BUPmed "

"Backup / Restore Medium Task“

Reads/Writes from/to a data backup medium

"BUPvol "

"Backup / Restore Volume Task”

Reads/Writes from/to data volumes for backup

"ChkData"

"Check Data“

Checks a B*Tree

"CrIndex"

"Create Index“

Parallel Create Index

"DropAux"

"Drop Auxiliary Files“

Performs Drop Table in background

"PrefObj"

"Prefetch Objects“

Prefetch liveCache objects after restart

© SAP 2008

Liste der möglichen ServerTasks-Zustände in der Taskliste des MaxDB Taskmanager. „ Erkennbar sind die vielen Prefetch-Tasktypen zur Vorbereitung diverser Prozesse innerhalb der Datenbank „

© SAP AG

ADM515

4-14

Anhang: Neue ServerTask Typen (Fortsetzung)

Anzeige

Langer Name

Beschreibung

"RedoRea"

"RedoLog Reader“

Reads from log volume or log file during restore

"RedoExe"

"RedoLog Execution Task"

Executes redo of log entries

"StdbyRC"

"Standby Restart Coordinator"

Coordinates a takeover in a Hot Standby system

"StdbySy"

"Standby Synchronize Server"

Waits for sync calls from a Hot Standby master

"Savepnt"

“Savepoint Coordinator"

Coordinates the phases of a savepoint

"JoinInS"

"Join Index Select"

Perform parallel join via index

"UpdStat"

"Update Statistics"

Perform parallel update statistics

"DropVol"

Drop Volume"

Drops a volume

"UpdCnt"

"Update Counter"

Scans tables to read counters.

© SAP 2008

„

Fortsetzung der Liste.

© SAP AG

ADM515

4-15

Pager und Timer-Task

Coordinator

User-Kernel-Thread

UKT 2

UKT 3

Requestor

User User User

User User user

Server Server Server

Console UKT 4 Clock / Timer

Timer

Session Timeout

Pager Pager Pager

IO-Threads (IO-Worker) DATA

© SAP 2008 / Page 1

Pager-Tasks sind für das Schreiben der Daten vom IO Buffer Cache in die Daten-Volumes zuständig. Sie werden dann aktiv, wenn ein Savepoint durchgeführt wird. Die Anzahl der Pager wird vom System berechnet. Sie ist in erster Linie von der Größe des IO Buffer Cache und der Anzahl der Daten-Volumes abhängig. „ Die Timer-Task dient zur Behandlung aller Arten von Timeout-Situationen (z.B. SessionTimeout für Verbindungen, RequestTimeout für Sperren). „

© SAP AG

ADM515

4-16

Analyzer, Log-Writer

Coordinator Requestor Console Clock / Timer

User-Kernel-Thread

UKT 2

UKT 3

User User User

User User user

Server Server server

UKT 4

UKT 5

UKT 6

Timer

Floating Service Floating Floating Service Service

Log-Writer

Pager Pager Pager

IO-Threads (IO-Worker)

LOG‘

© SAP 2008

Floating Services können viele verschiedene Funktionen in der Datenbank übernehmen. Die zwei wichtigsten, die hier zu erwähnen wären: y DBanalyzer – Dieser ermöglicht eine umfassende Beobachtung der Datenbank inklusive Protokollierung. y Eventmanagement – Es ermöglicht die automatische und autonome Steuerung von Managementfunktionen zum Betrieb der Datenbank wie z.B. automatische Erweiterung und automatisches Update Statistics. Diese Funktionen werden im SAP-Umfeld bisher aber nicht eingesetzt. „ Der Log-Writer ist für das Schreiben der After-Images in die Log-Volumes zuständig. Auch er bemüht die IO-Threads um die eigentlichen Schreibarbeiten zu übernehmen. „

© SAP AG

ADM515

4-17

GarbageCollector und FloatingService-Task

Coordinator

User-Kernel-Thread

UKT 2

UKT 3

Requestor

User User User

User User user

Server Server server

UKT 4

UKT 5

UKT 6

Timer

Floating Service Floating FloatingService Service

Log-Writer

Console Clock / Timer

Pager Pager Pager

IO-Threads (IO-Worker)

UKT 7 Garbage Collector

DATA „

© SAP 2008 / Page 1

Der vom liveCache schon länger bekannte Garbage-Collector wurde nun auch ab MaxDB 7.6 eingeführt und übernimmt Aufräumaktionen innerhalb der Datenbank. Er entfernt überschüssige Daten (History, also Before-Images der Transaktionslogik) aus der Datenbank. In früheren Versionen mußte der User-Task diese Aufgabe selber erledigen, und kann dies nun asynchron ausführen lassen. „ Siehe auch SAP Hinweis 1247666 (FAQ: MaxDB/liveCache History-Seiten) „

© SAP AG

ADM515

4-18

Trace-Writer-Task, Utility-Task

Coordinator

User-Kernel-Thread

UKT 2

UKT 3

Requestor

User User User

User User user

Server Server server

UKT 4

UKT 5

UKT 6

Floating Service Floating FloatingService Service

Log-Writer

UKT 7

UKT 8

UKT 9

Garbage Collector

Trace-Writer

Utility-Task

knltrace

CREATE INSTANCE ... ADD VOLUME ...

Console Clock / Timer

Timer Pager Pager Pager

IO-Threads (IO-Worker)

© SAP 2008 / Page 1

MaxDB bietet die Möglichkeit, für Diagnosezwecke ein spezielles Protokoll, den sogenannten Kernel-Trace, zu schreiben. Wenn Sie diese Funktion einschalten, wird die Trace-Writer-Task aktiv. Die Protokolldaten werden von den aktiven Tasks in einen Puffer geschrieben. Die Trace-WriterTask schreibt die Daten aus diesem Puffer in die Datei knltrace. „ Die Utility-Task ist ausschließlich für die Verwaltung der Datenbankinstanz reserviert. Da nur eine Utility-Task pro Datenbankinstanz existiert, können Verwaltungsaufgaben nicht parallel durchgeführt werden, um Konflikte auszuschließen. Eine Ausnahme bildet die automatische Logsicherung. Diese AutoLog-Sicherung kann parallel zu anderen Verwaltungsaufgaben durchgeführt werden. Nur das Ein- und Ausschalten der Funktion der automatischen Log-Sicherung wird noch über die Utility-Task durchgeführt. „ Ab MaxDB 7.5 und folgende wird die Utility-Task immer unwichtiger und ist nur aufgrund der Abwärtskompatibilität vorhanden. Die Koordination der mit ihr früher durchgeführten Aktionen kann auch direkt über den DBMServer Prozeß per db_execute-Kommandos laufen. Dieser besitzt eine interne Tabelle, die definiert, welche Aktion mit welcher anderen Aktivität parallel ausgeführt werden darf. „

© SAP AG

ADM515

4-19

Beispiel für ein Thread Layout unter UNIX

Hier das beispielhafte Task-Arrangement einer kleinen Datenbankinstanz unter Linux:

© SAP 2008

Hier sehen Sie eine Minimalkonfiguration unter Linux, so wie sie ohne weiteren Eingriff des Administrators angelegt wird. „ Die Ausgabe kann ebenfalls über die folgenden Konsolenkommando ermittelt werden: y x_cons <SID> show rte „

y oder dbmcli –d <SID> -u show rte

© SAP AG

ADM515

4-20

Beispiel für ein Thread Layout unter Windows

Hier das beispielhafte TaskArrangement der SAP NetWeaver Datenbank DEV unter Windows:

© SAP 2008

Hier sehen Sie das Setup der SAP NetWeaver für Schulungszwecke. „ Zu Beginn werden die Spezialtreads aufgeführt. Da es sich hier um ein Windowssystem handelt, folgen die IO Worker-Prozesse, die die asynchrone IO des Betriebssystems unterstützen und überwachen. Danach wird das Layout der UKTs aufgelistet. „ Folgende Kürzel sind zu finden: TW Tracewriter LW Logwriter UT Utility-Task SV Server-Tasks FS Floating-Service GC Garbage-Collector TI Timer-Task PG Pager-Tasks US User-Task IDL Idle-Tasks (Vorbereitung für flexibleres Taskmanagment) „ Lastinformationen einer Datenbankinstanz werden durch den DB-Analyzer (Kapitel 6) zeitaufgeschlüsselt protokolliert oder können in der Tabelle MACHINEUTILIZATION in akkumulierter Form nachgesehen werden. „

© SAP AG

ADM515

4-21

X-server

Coordinator Requestor

User-Kernel-Thread

Thread/Prozess-Layout

User User User Tasks

Windows „

serv.exe

Linux

Console

„

Clock / Timer

vserver (watchdog) „ vserver

UNIX xserver xserver X-Server

„

IO-Threads (IO-Worker)

vserver (watchdog) „ vserver „ vserver „ … „ vserver (n+1)

x_show „

zeigt am Ende den Status des X-servers

© SAP 2008

„

„

„

„ „ „

Die Abwicklung der Zugriffe auf die Datenbank über das Netzwerk wird über den Prozess vserver (UNIX) oder serv.exe (Microsoft Windows) durchgeführt. Diese Serverprozesse können manuell über das Kommando x_server gestartet werden. Üblicherweise erfolgt dies aber automatisch beim Systemstart. Unter Windows läuft der X-Server als Service. Für jeden Benutzerprozess, der sich remote an die Datenbank anmeldet, wird ein neuer X-ServerProzess erzeugt. Der erzeugende Prozess bedient den Benutzer, der neue Prozess wartet auf die nächste Benutzeranmeldung. Je nach Implementierung sind diese Prozesse zu erkennen (Unix) oder es wird ein Threadding eingesetzt und die Prozesse sind als Thread innerhalb des Prozesses implementiert (Linux, Microsoft Windows). Per Default werden Remote-Zugriffe erlaubt, sobald der X-Server gestartet ist. Mit dem Programm xtcpupd können Sie jedoch außerdem unter Windows den Zugriff „remote SQL“ ein- oder ausschalten, d.h. Zugriffe auf die Datenbankinstanzen über ein Netzwerk erlauben oder verbieten. Der Status des X-Servers lässt sich über das Tool x_show ermitteln. Am Ende der Ausgabe erfolgt die Statusinformation. Mit den Optionen –r und –v des x_show können unter Windows noch ein wenig mehr Informationen zum X-Server ermittelt werden. Außerdem ist es zu Analysezwecken möglich, einen Trace-Level für den X-Server während des Betriebs des X-Servers einzuschalten: x_server –N Damit können Sie u.a. überprüfen, welche Zugriffe auf die Datenbankinstanz erfolgen. Protokolliert werden diese Informationen in der Datei /sapdb/data/wrk/xserver_.prt.

© SAP AG

ADM515

4-22

SSL-gesicherte Verbindungen

Die Verbindung zwischen Client und Server kann optional mit SSL verschlüsselt werden Der verschlüsselte Tunnel wird zwischen den Client-Programmen (Database Studio, dbmcli, SQLDBC, usw.) und dem X-Server auf dem Datenbankserver aufgebaut. Es werden weitere Bibliotheken zur Nutzung der starken Verschlüsselung benötigt. Die Aktivierung der Verschlüsselung erfolgt „

individuell über die Logon-Prozeduren der ClientTools „ mit der dbmcli-Option –e SSL. „

„

beim Database Studio im Login-Popup

für SAP-Netweaver (SQLDBC) über die XuserFunktionalität

© SAP 2008 / Page 1

Zur Nutzung des SSL-Tunnels sind zusätzliche Verschlüsselungsbibliotheken der SAP notwendig. Diese werden auf speziellen Medien ausgeliefert. Hier bestehen die üblichen Exportbeschränkungen zum Thema “Starke Verschlüsselung”. Die Bibliotheken sind auf dem Service-Marktplatz unter http://service.sap.com/swdc Ö Downloads Ö SAP Cryptographic Software (SAP-Hinweis 455033) zu finden. „ Werden die Bibliotheken nicht gefunden, funktioniert der X-Server trotzdem, aber es wird dazu eine Warnmeldung ausgegeben (WNG 12453 NISSLSRV NISSL Init: SSL: Could not locate licence file). Weitere Informationen dazu auch im SAP-Hinweis 1032643. „ Die Aktivierung der Verschlüsselung hat Auswirkungen auf die Performance (etwa 20% durch den zusätzlichen Aufwand). „

© SAP AG

ADM515

4-23

MaxDB-Interna: Übersichtsdiagramm

MaxDB-Interna Thema 1: Prozesse Thema 2: Sperren Thema 3: Speicherbereiche Thema 4: Plattenbereiche Thema 5: Logging

© SAP 2008 / Page 1

„

Siehe auch SAP Hinweis 1243937 (FAQ: MaxDB SQL-Sperren)

© SAP AG

ADM515

4-24

Datensatzsperren mit MaxDB

Jede Sperranforderung zur Änderung eines Datensatzes in einer beliebigen Tabelle wird in der Sperrliste hinterlegt

MaxDB-Parameter MaxSQLLocks

Prozesse

Zeilensperren (row_exclusive) oder „ Tabellensperren (tab_exclusive) oder „

Katalogsperren (sys_exclusive) in der Administration.

„

Die Größe der Sperrliste wird durch den MaxDB-Parameter MaxSQLLocks gesteuert

Sperrliste

Sperren erscheinen als

20%

Tabelle

10%

Typischer Wert 300.000 bis 500.000 für SAP Netweaver Installationen „ Größere Werte möglich „

„

Die Größe eines Sperreintrages beträgt etwa 200 Bytes im Hauptspeicher

0 Prozess

© SAP 2008

„

Mit dem SQL-Kommando select * from lockliststatistics können weitere Informationen aus dem Sperrmanagement ermittelt werden: DESCRIPTION VALUE MAX LOCKS 300000 TRANS LIST REGIONS 8 TABLE LIST REGIONS 8 ROW LIST REGIONS 8 ENTRIES 902400 USED ENTRIES 0 USED ENTRIES (%) 0 AVG USED ENTRIES 15 AVG USED ENTRIES (%) 0 MAX USED ENTRIES 25500 MAX USED ENTRIES (%) 3 OMS SHARE LOCK CONTROL ENTRIES 0 OMS SHARE LOCK CONTROL ENTRIES USED 0 OMS SHARE LOCK ENTRIES 0 OMS SHARE LOCK ENTRIES USED 0 OMS SHARE LOCK COLLISION ENTRIES USED 0 CONSIST VIEW ENTRIES 0 OPEN TRANS ENTRIES 0 LOCK ESCALATION VALUE 60000 LOCK ESCALATIONS 0 SQL LOCK COLLISIONS 63 OMS LOCK COLLISIONS 0 DEADLOCKS 0 SQL REQUEST TIMEOUTS 0 OMS REQUEST TIMEOUTS 0 TRANSACTIONS HOLDING LOCKS 0 TRANSACTIONS REQUESTING LOCKS 0 TRANSACTIONS HOLDING OMS LOCKS 0 CHECKPOINT WANTED FALSE SHUTDOWN WANTED FALSE

© SAP AG

ADM515

4-25

Sperren und Sperrtypen

SHARE Sperre „

Weitere Transaktionen können die SHARE gesperrten Objekte lesen, aber nicht ändern

EXCLUSIVE Sperre „

Weitere Transaktionen können die Datensätze zwar lesen, aber mit der Gefahr, daß die Datensätze geändert werden Eine Transaktion hält die folgende … Tabellensperre

Zeilensperre

Katalogsperren

Kann eine weitere Transaktion …

EXCLUSIVE

SHARE

EXCLUSIVE

SHARE

EXCLUCIVE

SHARE

… diese Tabelle ECLUSIVE sperren ?

Nein

Nein

Nein

Nein

Nein

Ja

… diese Tabelle SHARE sperren ?

Nein

Ja

Nein

Ja

Nein

Ja

… irgendeine Zeile dieser Tabelle EXCLUSIVE sperren ?

Nein

Nein

Nein

Ja

Ja

Ja

… eine schon gesperrte Zeile EXCLUSIVE sperren ? … eine andere Zeile EXCLUSIVE sperren ? … eine beliebige Zeile dieser Tabelle SHARE sperren ?

Ja

Nein

Nein

Ja

Ja

Ja

… eine einzige Zeile SHARE sperren ? … eine andere Zeile SHARE sperren ?

Nein

Ja

Ja

Ja

… die Definition der Tabelle im Katalog ändern ?

Nein

Nein

Nein

Nein

Nein

Nein

… die Definition der Tabelle aus dem Katalog lesen ?

Ja

Ja

Ja

Ja

Ja

Ja

© SAP 2008 / Page 1

„

Hier sind die verschiedenen Kombinationen von Sperrtypen aufgelistet.

© SAP AG

ADM515

4-26

Sperr-Eskalation mit MaxDB

Sperr-Eskalation (LockListEscalation)

Andere Datanbanken lassen Sperrlisten extrem wachsen und gefährden damit die Gesamtperformance. Bei MaxDB kommt es nur zu Problemen beim Zugriff auf eine Tabelle, aber der Rest der DB kann performant weiterarbeiten.

MaxDB-Parameter MaxSQLLocks

Prozesse

Sperrliste

Wenn 20% der Sperrliste durch 1 Prozeß mit dem Zugriff auf 1 Tabelle belegt wird, kommt es zur Sperr-Eskalation „ Tabelle wird dann komplett und exklusiv für den Prozeß gesperrt . Aus vielen row_exclusive wird eine tab_exclusive. „

20%

Tabelle

10%

Prozess

0

© SAP 2008

„

Der Wert LOCK ESCALATION VALUE aus der Systemtabelle LOCKLISTESCALATION definiert die Grenze, ab der es zu einer Lock-Eskalation kommt. Er entspricht in dem Auszug zuvor mit dem Wert 60.000 den erwähnten 20 % des Wertes MAX LOCKS mit 300.000.

© SAP AG

ADM515

4-27

Sperr-Eskalation mit MaxDB - Lösungsansätze

Sperrverhalten kann nicht für eine Tabelle geändert werden

MaxDB-Parameter MaxSQLLocks

Einzige Möglichkeit ist Sperrliste vergrößern, Werte bis 5 Mio. Einträge sind bekannt

„

COMMITs in das Batchinput oder Report einbauen

Prozesse

Sperrliste

„

20%

Tabelle

10%

Prozess

0

© SAP 2008

„

Sehr lange Sperrlisten verlangsamen jedes Arbeiten mit Datensätzen, da diese langen Listen bei jedem Datensatzzugriff auf Sperren für diesen Datensatz geprüft werden müssen. Wenn die Sperrliste aber nicht mit Sperren gefüllt sind, ist es kein Problem.

© SAP AG

ADM515

4-28

Sperrfreie Index-Erstellung Ausgabe in der Diagnosedatei knlMsg:

© SAP 2008

Ab MaxDB 7.7.04 besteht die Möglichkeit, Tabellenindizes auch ohne die bisherigen Sperrsituationen auf der Basistabelle anzulegen. „ Dieses Verfahren wird nur bei größeren Tabellen angewendet. Bei kleineren Basistabellen dauert die Indexerstellung üblicherweise nur kurz und daher gibt es kaum Auswirkungen durch die kurzzeitige Katalogsperre. „ Bei größeren Tabellen werden die Änderungsaufträge an den Basistabellen während der Indexerstellung in temporären Strukturen mitgeschrieben und im Anschluss der Indexerstellung schließlich ausgeführt. „ In der Diagnosedatei knlMsg kann dieses Verfahren - wie gezeigt - verfolgt werden. „

© SAP AG

ADM515

4-29

MaxDB-Interna: Übersichtsdiagramm

MaxDB-Interna Thema 1: Prozesse Thema 2: Sperren Thema 3: Speicherbereiche Thema 4: Plattenbereiche Thema 5: Logging

© SAP 2008 / Page 1

© SAP AG

ADM515

4-30

Laufzeitumgebung (LZU)

User-Kernel-Thread (UKT) User-Kernel-Thread (UKT) – Tasks:

Console

Garbage

Trace-Writer

Timer

Utility

Log-Writer

Pager Pager

Server Server

User User

Requestor IO-Threads

I/O Buffer Cache Catalog-Cache SharedSQL Hash Memory

Festplatten

Coordinator (Clock)

Caches

Prozesse

Cache-Bereiche

DATA

Log-Queue

LOG LOG

/sapdb Programme etc.

© SAP 2008

Die Datenbank besitzt Puffer, um die Anzahl der Lese- und Schreiboperationen auf den Platten so gering wie möglich zu halten. y Der IO Buffer Cache enthält die zuletzt benötigten Daten von den Daten-Volumes (LRUMechanismus). Diese bestehen aus - Daten-Pages der Tabellen - Converter-Informationen mit logische Positionen von Daten-Pages in den Daten-Volumes. - Before Images (history data) über die aktuell laufenden Transaktionen y Log-Einträge werden über die Log-Queue in den Log-Volumes geschrieben. y Der Catalog-Cache enthält Strukturinformationen über Tabellen. Der Catalog-Cache wird dynamisch von UKTs jeder Session zugeordnet und ist ein prozesslokaler Speicher. „ Die Caches können nach Benutzervorgaben dimensioniert werden. „ Der Speicherbedarf einer MaxDB-Instanz kann über die Tabelle ALLOCATORSTATISTIC ermittelt werden. Hier werden Informationen über diverse Speicherstrukturen der MaxDB abgelegt. Die Gesamtgröße incl. IO-Buffer-Cache, sonstige Caches, Taskstacks usw. aber ohne Executable kann in der Zeile SystemHeap und der Spalte USED_BYTES gefunden werden. Das entsprechende SQL-Statement lautet (bitte auf Schreibweise des 'SystemHeap' achten): select USED_BYTES from ALLOCATORSTATISTIC where ALLOCATOR = 'SystemHeap' „

© SAP AG

ADM515

4-31

Caches und zugehörige Plattenbereiche Catalog Cache

IO Buffer Cache

SharedSQL Cache

Log Queue

Converter Pages Data Pages Undo Pages free Pages

Data-Volumes

Log-Volumes

LOG Undo

Undo

Undo

Der IO Buffer Cache enthält verschiedene Typen von Datenseiten. Die Synchronisation zwischen IO Buffer Cache und Data-Volumes erfolgt mit den SAVEPOINTs Der Log wird hingegen kontinuierlich geschrieben und im Falle eines COMMIT sogar synchron. Catalog Cache und SharedSQL Cache sind Prozesszwischenspeicher und besitzen daher keine korresponierenden Plattenbereiche. © SAP 2008

„ „ „

„ „

„

Alle Daten werden hier in 8-kByte-Pages organisiert. Der IO Buffer Cache und die Log Queue sind beide statische Speicher und werden zum Start der Datenbank komplett aufgebaut. Catalog Cache und Shared SQL Cache sind wachsende Speicher, die zu Beginn zu 50% aufgebaut werden und dann zur festgelegten Maximalgröße bei Bedarf wachsen. Einmal angeforderter Speicher wird nicht wieder an das Betriebssystem zurückgegeben. Der Catalog Cache enthält Daten von aufbereiteten SQL-Statements inkl. Parse-Informationen und Eingabeparametern usw. Er enthält nicht das initiale SQL-Statement in lesbarer Form. Diese Information wird dem Informationssatz aus dem Catalog Cache zugeordnet, wenn das aufbereitete SQL-Statement schließlich im Shared SQL Cache abgelegt wird. Damit ist es dann möglich die lesbaren SQL-Statements zu ermitteln. Wenn eine SQL-Statementanalyse erfolgen soll, geschieht dies nicht wie bei anderen Datenbanken aus diesem Cache, sondern es werden SQL-Monitore zusätzlich gestartet, die noch weitaus mehr Nutzungsdaten ermitteln.

© SAP AG

ADM515

4-32

Faustregel zur Größe des IO Buffer Caches

Erfahrungen aus vielen Kundensystemen zeigen folgende Faustregel zur initialen Einstellung der Größe des IO Buffer Caches Die Größe des IO Buffer Cache wird durch die Datenmenge in der Datenbank bestimmt und prozentual berechnet, wie in der Tabelle gezeigt

ASCII

UNICODE

OLTP

1%

2%

OLAP

2%

4%

Mehr Speicher ist natürlich möglich und stellt einen Sicherheitspuffer da. UNICODE bewirkt eine notwendige Verdoppellung des benötigten IO Buffer Caches. Für OLAP(BI) gilt ähnliches aufgrund der großen Datenmengen die dort verarbeitet werden.

© SAP 2008

„

Mit diesen Speicher-Bereitstellungen für die MaxDB kann erfahrungsgemäß eine Datenbank gut funktionieren. Eine Ausnahme stellen Anwendungen dar, die Funktionen nutzen, die viele Daten lesen und daher anders bewertet werden müssen.

© SAP AG

ADM515

4-33

Zentrale Bedeutung des Converter

Seiten im I/O Buffer Cache

Page 1

Page 2

Page 4

Page 5

Page 6

Page 7

I/O Buffer Cache

Restart DATA Start der Datenbankinstanz

Physische Position der Seiten

Page 3

Adressübersetzung mit Hilfe des Converters

Catalog-Cache Shared SQL Cache Hash Memory

Log-Queue

File Dir

Page 5

Page 1

DATA

DATA Page 6

Page 2

DATA Page 4

DATA

DATA

Page 7

Page 3

© SAP 2008

Im Daten-Volume (d. h. im dort enthaltenen Converter) wird die Abbildung der logischen Seitennummern auf physische Seitenadressen verwaltet. Der I/O Buffer Cache hält die Seiten des Converters, auf die zuletzt lesend oder schreibend zugegriffen wurde. Er wird von allen gleichzeitig aktiven Benutzern gemeinsam genutzt. „ Die Größe des Converters beträgt 1/1861 der Datenbankgröße, da eine Converter-Seite die Verwaltungsinformation (Referenzen) von 1861 Datenseiten enthalten kann. Eine Datenbank mit 500 GB belegten Daten benötigt einen Converter der Größe von ca. 278 MB. „

© SAP AG

ADM515

4-34

Flexible Gestaltung des Converters Data-Volumes

Converter-Seite

Restart

Definition der Wurzel des Converters in der Restart-Seite

Converter wird als B*-Baum über alle Data-Volumes verteilt „ „ „

schneller Neustart, da der Converter von mehreren Devices gelesen wird kein Hotspot beim Schreiben von Converter-Daten Einteilung des Converters im Speicher in kleinere Bereiche, um auch dort Hotspots zu vermeiden

Converter kann wachsen und schrumpfen

© SAP 2008

Ab Version 7.4 kann der Converter dynamisch wachsen und schrumpfen. Die Converter-Seiten sind verteilt auf allen Daten-Volumes abgelegt. Der lesende Zugriff auf die Converter-Seiten erfolgt beim Restart über eine Baumstruktur. „ Der Baum hat 3 Ebenen, eine Wurzel- (Root), eine Index- und eine Blatt (Leaf)-Ebene. Über die Restart-Seite vorn im ersten Daten-Volume findet die Datenbank beim Restart die Wurzelseite des Converters. Diese enthält Positionen der Indexseiten. Die Indexseiten wiederum enthalten Positionen der Blattseiten. Die Blattseiten sind nicht zwangsläufig sortiert. Beim Start liest die Datenbank den Converter parallel aus. „

© SAP AG

ADM515

4-35

Converter und Auswirkungen auf DatenVolumes

Restart

Undo

DISKD0003

Undo Undo

Converter Page Header: Version # log. DATA Offset DATA Save Saved Converter Page Header: Version # data Device on DATA page DATA log. DATA Offset DATA Save Saved page Number device type pages data device on DATA page DATA 4711 1 240 f 0 0 page number device type page 4712 3 219 t 1 0 4711 3 140 p 0 0 4712 2 191 t 1 0

DISKD0002

Converter-Inhalt

DISKD0001

Page-Adressierung: 0

...

6

Device-Nummer

7

8

9 10 11 12

...

30 31

32 TB adressierbar

Offset auf Device

8 Bit

Standard: 256 * 128 GB = 32 TB

24 Bit

6 Bit

große Volumes: 64 * 512 GB = 32 TB

26 Bit 12 Bit

20 Bit

Kleine Volumes: 4096 * 8 GB = 32 TB

© SAP 2008

MaxDB nummeriert die Datenseiten (Pages) und ordnet ihnen physische Seitenadressen im DataVolume zu. Diese Zuordnung wird im Converter verwaltet. Der Converter ist Teil des I/O Buffer Cache. „ Als eine Folge des Einsatzes der Schattenspeichertechnologie kann es von jeder Datenseite eine aktuelle Version geben sowie eine alte Version, die für einen möglichen Restart benötigt wird. Damit kann es je Datenseite auch zwei Converter-Einträge geben: Die Adresse der alten und die der neuen Version. Für beide Versionen einer logischen Page existiert je ein 35 Bit langer Converter-Eintrag mit folgenden Informationen: y Devicenummer (8 Bit): Nummer des Data-Volumes y Deviceoffset (24 Bit): Position im entsprechenden Data-Volume y Pagetyp (1 Bit): permanent (p) oder temporär (t) benötigt y Save Pages (1 Bit): Flag wird gesetzt, falls die Datenseite bei einer inkrementellen Datensicherung (SAVEPAGES) gesichert werden muss y Saved (1 Bit): Flag wird während der Sicherung gesetzt „ Bei einem Savepoint „merkt“ sich der Converter die Adresse der aktuellen Seitenversion; die Adresse der alten Version wird nach dem Savepoint wieder zum Überschreiben freigegeben. „ Mit einer Converter-Seite von 8 KB können 1861 Seiten des Data-Volume verwaltet werden. Die Größe des Converter beträgt also ungefähr 1/1861 der Datenbankgröße. „

© SAP AG

ADM515

4-36

Verlagerung von synchronen Operationen auf asynchrone Ausführung; User-Tasks sind nicht auf das Ende von I/O-Vorgängen angewiesen

„

Verstärkte Nutzung von Cache-Techniken (Converter)

„

Reduzierung der Schreiblast; erst bei Savepoints werden die geänderten Datenseiten aus dem Cache auf die Platten geschrieben

„

Der Datenbankstand auf den Platten ist immer strukturell konsistent (Restart-fähig); im Fehlerfall gibt es die Möglichkeit, auf diesen Stand zurückzugreifen

Änderung an Page 4711

keine Änderung an Page 4711 zwei Versionen einer Page

Platte

„

Zeit

Page 4711

stattdessen eine neue Page 4711’

DATA‘ DATA

Page 4711’

Schreiblast

I/O-Konzept nach dem Prinzip der Schattenspeicherverwaltung:

Speicher

Schattenspeicher-Konzept

Savepoint © SAP 2008

„

„

„

„

„

Das I/O-Konzept der Datenbank arbeitet nach dem Prinzip der Schattenspeicherverwaltung. Kernpunkte dabei sind: die optimierte Unterstützung von symmetrischen Multi-Prozessor-Systemen, die Verlagerung von möglichst viel I/O auf eine asynchrone Ausführung und eine stark optimierte Datensicherungs-Performance, die den heutigen Datenbankgrößen gerecht wird. Eine User-Task soll nicht darauf angewiesen sein, auf das Ende von I/O-Vorgängen warten zu müssen. Alle Änderungsoperationen werden im Hauptspeicher durchgeführt. Das I/O-Subsystem muss dafür sorgen, dass die vollständige Wiederanlauffähigkeit erhalten bleibt. Die Schattenspeicherverwaltung unterscheidet für die Datenseiten zwischen Originalen und Kopien. Beim Wiederanlauf werden die jeweils gültigen Zustände der Datenseiten erkannt. Das Konzept basiert auf Savepoint-Zyklen, die durch einen Savepoint abgeschlossen werden. Ein abgeschlossener Zyklus wird durch die Versionsnummer seines Savepoints spezifiziert. Diese Nummer wird als ‘savepoint version’ oder ‘converter version’ bezeichnet. Die auf Basis dieser Savepoint-Zyklen entstehenden unterschiedlichen Versionen der Datenseiten werden im sog. Converter verwaltet. Hier werden den Originalen bzw. den Kopien der logischen Datenseiten physikalische Blöcke zugeordnet. Der Ort, an dem eine logische Datenseite gespeichert ist, kann also von Savepoint-Zyklus zu Savepoint-Zyklus wechseln. Durch die Nutzung parallel arbeitender Pager- und Server-Tasks wurde der Data-Cache auf Unterstützung von symmetrischen Multiprozessorarchitekturen (SMP) hin optimiert.

© SAP AG

ADM515

4-37

Merkmale des Savepoints

Transaktion 1

Savepoint

Transaktion 2

zeitgesteuert

Transaktion 3

Startup / Shutdown Sicherungen

0

Zeit

CREATE INDEX IO Buffer Cache

LOG FULL DB FULL

Restart DATA Undo

© SAP 2008

„ „ „ „

„

Der Savepoint ist zeitgesteuert. Defaultmäßig wird er alle 10 Minuten angestoßen. Zusätzlich wird beim Starten und Stoppen der Datenbank ein Savepoint geschrieben. Ein Savepoint wird auch geschrieben, wenn ein CREATE INDEX-Kommando abgesetzt wurde, sowie bei LOG FULL- und DB FULL-Situtationen. Sicherungen werden mit der MaxDB immer auf Basis eines SAVEPOINT erstellt. Durch die Eigenschaft, daß die Before Images der Transaktionen bis zum COMMIT im Datenbereich stehen, sind die darauf basierenden Sicherungen immer konsistent. Beim Deaktivieren des Log-Writers wird die Zeitsteuerung des SAVEPOINTS ausgesetzt. Daher Vorsicht mit der Deaktivierung des Redo-Logmanagement.

© SAP AG

ADM515

4-38

Savepoint-Zyklus x25: Page im I/O Buffer Cache geändert vor Savepoint 25

x25

X 25 X 25

X 25

X 25

I/O Cache I/O Buffer Buffer Cache X X X 25

x26: Page im I/O Buffer Cache geändert vor Savepoint 26

x26

25

25

26

X 25

X 25

26

26

I/O Buffer Cache X X X 25

26

X 25

25

25

X 25

Restart

Restart I/O Buffer Cache nach Savepoint 25

Undo

Savepoint 25

X 26

I/O Buffer Cache I/O Buffer Cache X X X X

X 25

X 25

DATA

X 26

DATA Undo

10 Minuten oder mehr

Savepoint 26

t

© SAP 2008

„

Savepoints können auch manuell per dbmcli –U c db_execute force savepoint gestartet werden

© SAP AG

ADM515

4-39

Savepoint-Phasen Geänderte Datenseiten schreiben (parallel)

Data Cache

3. Phase

2. Phase kurz

1. Phase

„

dc0 dc1 dc2

„

B*Baum Operationen unterbinden

„

Transaktions-Regions belegen

„

Log-Eintrag schreiben

„

Offene Transaktionen merken

„

Alle Bereiche wieder freigeben

„

Die in der 1. Phase geänderte Datenseiten schreiben (parallel)

„

Converter-Seiten schreiben (parallel)

„

Log-Info und Restart-Seite schreiben

„

Savepoint-Version erhöhen

dc3

.... ....

Restart

Undo Undo

Undo

dcn

DISKD0003

DISKD0002

DISKD0001

c1 c2 … cn Converter Cache

© SAP 2008

„ „

„

„

„

„

Der Savepoint kann als eine zentrale Funktion des I/O-Konzepts angesehen werden. Die Abbildung zeigt, was während eines Savepoints passiert. Der Savepoint muss den Data-Cache und den Converter-Cache auf die zugehörigen Volumes durchschreiben. Aufgrund der Größe der beiden Caches kann dies nicht einfach als synchrone Aktion geschehen, da dann das System zu lange blockiert würde. Es muss aber eine möglichst kurze Phase geben, in der die Caches geschützt durchgeschrieben werden können. Ein Savepoint erfolgt zeitgetaktet in einem Standardabstand von 10 Minuten. Damit die im geschützten Abschnitt (Phase 2) durchzuschreibende Menge von Seiten klein ist, beginnt der Savepoint mit dem Flush des Data-Cache parallel zum laufenden Betrieb. Dabei wird der DataCache von mehreren Pager-Tasks gleichzeitig bearbeitet. Mit dieser Phase ist der größte Teil der Seiten durchgeschrieben. In der zweiten Phase wird ein Flag gesetzt, das Ausgleichsoperationen auf B*-Bäumen verbietet. Zusätzlich wird das Öffnen neuer Transaktionen innerhalb dieser Phase unterbunden. Alle Seiten, die innerhalb der ersten Phase verändert wurden, werden als savepoint-relevant markiert. Für die offenen Transaktionen wird ein Open Trans File erstellt. In der letzten Phase werden alle Seiten durchgeschrieben, die während der zweiten Phase markiert wurden. Die Markierungen werden zurückgesetzt. Danach werden alle geänderten Converter-Seiten parallel in die Daten-Volumes geschrieben. Der Savepoint selbst wird mit Schreiben der RestartSeite abgeschlossen. Nachträglich wird die Savepoint-Version hochgezählt. Die geschützte Phase des Savepoints ist im Allgemeinen sehr kurz und wird vom Endanwender nicht wahrgenommen.

© SAP AG

ADM515

4-40

Savepoint-Phasen in den Database Messages (knlMsg)

02:00:36 02:00:36 02:00:36 02:00:36 02:00:36 02:00:36 02:00:36 02:00:36 02:00:36 02:00:36 02:00:36

Savepoint Pager Pager Pager Pager SAVPOINT Pager Pager Pager Pager SAVPOINT

1: 20004: 20005: 20006: 20007: 53070: 20008: 20009: 20010: 20012: 53071:

Savepoint (Time) started by T1 SVP(1) Start Write Data SVP(1) Stop Data IO, Pages: 3051 IO: 501 SVP(2) Wait for last synchronizing task: 557 SVP(2) Stop Wait for last synchronizing task, Pages: 0 IO: 0 B20PREPARE_SVP: 13082 SVP(3) Start Write Data SVP(3) Stop Data IO, Pages: 4 IO: 4 SVP(3) Start Write Converter SVP(3) Stop Converter IO, Pages: 502 IO: 502 B20SVP_COMPLETED: 13082

Wichtig für die Performance ist ein großes Verhältnis von geschriebenen Seiten zur Zahl der dafür ausgeführten IOs in der ersten Phase des Savepoints Die Savepoint-Nummer wird ausgegeben (hier 13082) Ein weiteres Kriterium für die Performance ist die Laufzeit des Savepoints - hier mit Zeiten unter einer Sekunde.

© SAP 2008

© SAP AG

ADM515

4-41

File Directory – Tabellenzähler

Neugestaltung des File Directory „

Das globale File-Verzeichnis, eine einfache Ablage der Datenbank um auf Datenstrukturen der Tabellen, Indices und LOBs zugreifen zu können, wird nun komplett im Speicher gehalten. Die flachen Strukturen werden über einen hash Algorithmus verwaltet und ermöglichen einen schnellen Zugriff.

„

Zusätzlich werden hier wichtige Statistiken z.B. zum “SELECT COUNT(*)” gehalten, die bei einer Bestimmung der Anzahl der Datensätze in der Tabelle sehr schnell über das File Directory ermittelt werden kann. Dieses wird die Ausführungen von ‘SELECT COUNT (*)’ stark beschleunigen.

© SAP 2008

Bestimmung der Anzahl der Datensätze in einer Tabelle: select roots.tablenaname, files.* from files, roots where files.root=roots.root order by files.fileid Die Anzahl der Datensätze wird in der Spalte ENTRYCOUNT angegeben. „ Diese Werte für ENTRYCOUNT werden automatisch gepflegt, wenn die Datenbankinstanz mit MaxDB 7.6 neu aufgebaut wurde. „ Sollte die Datenbankinstanz durch ein Update aus einem älteren Release entstanden sein, stehen die Werte dieser Spalte auf 0 (Initial). „ Anschließend werden diese Zahlen im Hintergrund automatisch zu lastarmen Zeiten aktualisiert. Sollte dieser Prozess zu selten zur Arbeit kommen, da die DB rund um die Uhr ausgelastet ist, gibt es noch die Möglichkeit, diese absoluten Zahlen durch einen Check Data im Betriebsmodus ADMIN auf einen Schlag ermitteln zu lassen. „

© SAP AG

ADM515

4-42

Shared SQL Cache Globale Zwischenspeicherung von SQL-Statements und Ausführungsplänen Detailiertes Monitoren von Ausführungsplänen Parameter: „ UseSharedSQL YES/NO „ SharedSQLCommandCacheSize Systemtabellen zum Monitoren „

CACHESTATISTICS COMMANDCACHESTATISTICS

„

COMMANDSTATISTICS

„

Benutzer 1: select * from T100

Benutzer n: select * from T100

I/O Buffer Cache

Parsed Informations

Catalog-Cache Shared SQL Cache File Dir

Log-Queue

Parsed Select * from T100 Informations

© SAP 2008

„

„ „

„ „

„ „

Wenn Shared SQL eingeschaltet ist, zeigen die SQL-Monitore in der DB50 (Resource Monitor) die SQL-Statements an, die sie im Shared SQL Cache finden, aber nicht die Informationen über Kosten usw. wie es üblicherweise von den SQL-Monitoren bekannt ist. Nachdem die SQL-Monitore gestartet wurden, werden für die danach gesammelten Statements diese Daten angezeigt. Die Funktion des Shared SQL bietet aber generell die Möglichkeit, ohne die Notwendigkeit von speziellen SQL-Monitoren immer genau zu wissen, welche Statements gelaufen sind bzw. laufen. Dieses war in früheren Releases nicht möglich, sondern erst nach Start der SQL-Monitore. Diese Funktion ist seit frühen Support Packages des SAP NetWeaver 6.40 und des SAP NetWeaver 7.00 möglich. Der Catalog-Cache fungiert nur als Zwischenspeicher bevor die aufbereiteten (geparsten) Statements dann endgültig im Shared SQL Cache zusammen mit dem vollständigen SQL-Statement gespeichert werden. Im Catalog-Cache besitzen die Usersessions weiterhin private Bereiche in denen die Funktion des Parsens stattfindet. Der Shared SQL Cache ist ein wachsender Cache und wird initial in der halben Grösse erzeugt und wächst dann bis zum Wert SharedSQLCommandCacheSize nach Bedarf an. Informationen zum Betrieb des Shared SQL können in den angezeigten Systemtabellen ermittelt werden.

© SAP AG

ADM515

4-43

Anhang: Stripes (Regionen)

z.B. im Data Cache

Reserviert

User-Kernel-Thread

Zur Synchronisierung von parallel agierenden Prozessen auf Speicherstrukturen und sonstigen Resourcen in der Datenbank werden Stripes (Regionen) genutzt. DataCache „ ConverterCache „ usw. „

User User User User-Kernel-Thread Tasks User User User Tasks

© SAP 2008

„ „ „ „ „

„

„ „

Stripes (Regionen) findet man in allen Bereichen der parallelen Nutzung von Resourcen in der Datenbank. Zum Beispiel ist der DataCache in mehrere Hauptspeicher-Segmente unterteilt. Einstellbare Einteilung von Stripes im DataCache (8 – 1024, Default abhängig von der Data CacheGröße) MaxDB-Parameter: DataCacheStripes, ConverterStripes usw. Durch eine Vervielfachung der Stripes kann eine höhere Parallelität erreicht werden (MaxDBinterner Synchronisations-Mechanismus). Mit dieser größeren Zahl von Stripes gibt es aber auch einen höheren Verwaltungsaufwand. Beide Dinge müssen gegeneinander abgewägt werden. In einem Multiprozessorsystem (Parameter MaxCPUs > 1) sind Kollisionen von Prozessen unterschiedlicher UKTs nicht vermeidbar. Entscheidend ist, wie schnell der Wechsel auf den Stripes von statten geht, daß heißt, wie lange der kollidierte Task warten muß, um an den Stripe (Region) zu gelangen und seine Arbeit beginnen kann. Daher ist die Prozentangabe Waits von hoher Bedeutung, wie oft lange auf einen Stripe im Durchschnitt gewartet werden mußte. Das DBA-Cockpit und der DBanalyzer bietet hier viele Informationen in unterschiedlicher Ausprägung (zeitlich aufgeschlüsselt oder summiert). Es gibt viele unterschiedliche Arten von Stripes, die mit diversen geteilten Funktionen innerhalb der Datenbank zusammenhängen. Die Schulung UMEW60 (MaxDB Performance Optimierung) versucht eine versionsabhängige Auflistung.

© SAP AG

ADM515

4-44

Page-Clusterung

Wird ab MaxDB 7.7.04 angeboten Funktion automatisch verfügbar, da MaxDB-Parameter DataIOClusterSize üblicherweise auf 64 eingestellt ist Aktivierung erfolgt in erster Implementierung über eine Umsetzung der Tabelle mit „

ALTER TABLE CLUSTER

Deaktivierung erfolgt über „

ALTER TABLE NOT CLUSTER

Erste Kundenerfahrungen werden gesammelt „

Datendurchsatz auf den Datenplatten steigt enorm an

„

Durchschnittliche IO-Zeiten sinken unter 1 ms

Weiterentwicklung in 7.7 und 7.8 „

In Zukunft automatische Aktivierung ohne die Notwendigkeit der Umsetzung (Umsetzung erfolgt dann im laufenden Betrieb der Datenbank)

© SAP 2008

„ „ „

„ „

„ „

Diese Funktion steht ab MaxDB 7.6.05 zur Verfügung. In 7.6 lautet der Parameter DATA_IO_BLOCK_COUNT, der auch in dem Release schon auf 64 steht. In neueren Versionen der DB50 werden Informationen der Güte von Tabellen in Clustern angegeben. Zu finden sind diese Informationen unter DB50 -> Tables, View & Synonyms -> Tabelle eingeben -> Datenablage -> Faktor Viele Systemtabellen wurden für die Aufnahme von Statusinformationen der Clusterung erweitert oder neue Systemtabellen erstellt. Die Umsetzungszeit der Tabellen, die in Page-Cluster umgesetzt werden sollen, ist mit einem einfachen Table-Scan zu vergleichen. Im Anschluss läuft der Garbage-Collector los und löscht die Pages der alten Tabellenstruktur. Indizes werden in folgenden Erweiterungen der Funktionalität ebenfalls in Clustern ablegbar sein, sobald die Basistabelle auf Cluster umgestellt wird. SAP Hinweis 1162332 zum Thema Page Clustering. Dort werden weitere Tipps&Tricks zu dem Thema gesammelt.

© SAP AG

ADM515

4-45

Prefetch

Wird in MaxDB 7.7 ab Version 7.7.06 angeboten Aktivierung „

MaxDB parameter ReadAHeadTableThreshold auf Wert größer 0 setzen: 100 „ Tabellen-Bereichscans (Range Scans) mit mehr als 100 Pages werden an Server-Tasks deligiert „ Optimizer ermittelt die Anzahl der zu lesenden Pages und steuert damit die Entscheidung „ Kann im Betriebsmodus ONLINE über eine Parameteränderung umgestellt werden (Aktivierung und Deaktivierung)

Erste Ergebnisse im Kundenumfeld mit dieser Funktion in 7.6.05 Hintergrundjob mit vielen Plattenzugriffen konnte vom 40 auf 2 Stunden reduziert werden „ Der erste Start des SAP Netweavers kann in Einzelfällen von Minuten auf Sekunden reduziert werden. „

Einschränkungen in der ersten Implementierungsphase Anfänglich wird diese Technik nicht mit JOINs genutzt. Die Zahl der Server-Tasks ist limitiert und muß bei paralleler Nutzung verteilt werden. „ Keine Kombination von Page Clusterung und Prefetch: Die Server-Tasks kennen das Lesen von Clustern noch nicht „ „

© SAP 2008

Prefetching wird in der Linie MaxDB 7.7 ab Version 7.7.06 und folgende bereitstehen. „ Es erfolgt zuerst eine Implementierung wie in MaxDB 7.6 ab Version 7.6.05 y Der MaxDB-Parameter lautet dort READAHEAD_TABLE_THRESHOLD und sollte wie bei MaxDB 7.7.06 eingestellt werden. „ SAP Hinweis 1255050 zum Thema Prefetch. Dort werden weitere Tipps&Tricks zu dem Thema gesammelt. „

© SAP AG

ADM515

4-46

Cache bzw. Table-Pinning

Wird angeboten ab MaxDB 7.7.06 Zwei Arten der Tabellenbehandlung im IO Buffer Cache werden bereitgestellt „ „

Tabellen werden bevorzugt im Cache gehalten Tabellen werden bevorzugt aus dem Cache verdrängt (z.B. Protokollierungen)

Aktivierung ALTER TABLE CACHE „ für Tabellen, die im Cache gehalten werden sollen „ ALTER TABLE NOCACHE „ für Tabellen, die aus dem Cache schnell verdrängt werden sollen „ Beide Ergänzungen sind auch für das CREATE TABLE-Statement verfügbar „ Einstellung kann zum normalen Verhalten zurückgestellt werden mit „ NOT CACHE „ NOT NOCACHE „

Die aktuelle Einstellung kann über die Systemtabelle FILES für jede Tabelle ermittelt werden

© SAP 2008 / Page 1

„

Diese Funktionalität wird zum ersten Mal mit MaxDB 7.7.06 angeboten.

© SAP AG

ADM515

4-47

MaxDB-Interna: Übersichtsdiagramm

MaxDB-Interna Thema 1: Prozesse Thema 2: Sperren Thema 3: Speicherbereiche Thema 4: Plattenbereiche Thema 5: Logging

© SAP 2008 / Page 1

© SAP AG

ADM515

4-48

Laufzeitumgebung (LZU)

User-Kernel-Thread (UKT) User-Kernel-Thread (UKT) – Tasks:

Console

Garbage

Trace-Writer

Timer

Utility

Log-Writer

Pager Pager

Server Server

User User

Requestor IO-Threads

I/O Buffer Cache Catalog-Cache SharedSQL Hash Memory

Festplatten

Coordinator (Clock)

Caches

Prozesse

Festplattenbereiche und IO

Log-Queue

Restart DATA

LOG LOG

Undo

/sapdb Programme etc.

© SAP 2008

Der Begriff Volume (früher mit Versionen kleiner 7.4 auch Devspace genannt) bezeichnet eine physische Platte bzw. einen Teil einer physischen Platte. „ Es werden zwei Arten von Volumes unterschieden. y In den Data-Volumes sind hauptsächlich Daten der Benutzer (Tabellen, Indizes) und der Datenbankkatalog aber auch der Converter sowie History-Pages mit Before Images der laufenden Transaktionen gespeichert. Durch ein datenbankinternes Striping werden die zu einer Tabelle gehörenden Daten gleichmäßig auf alle Data-Volumes verteilt. y In den Log-Volumes werden alle Änderungen von Datenbankinhalten in Form von AfterImages aufgezeichnet, um bei einer Wiederherstellung der Datenbankinstanz die Änderungen nachladen zu können, die in der letzten vollständigen Datensicherung nicht enthalten sind. Für die Gewährleistung eines sicheren Datenbankbetriebs eines kleinen Systems ohne RAID1Platten haben Sie die Möglichkeit, die Log-Volumes zu spiegeln. Im ungespiegelten LogModus muß die Platte zumindest für ein Produktivsystem vom Betriebssystem oder physisch gespiegelt werden. „

© SAP AG

ADM515

4-49

Verzeichnisstruktur seit SAP DB Version 7.2.4

/sapdb

LVC SDB P01

INSTROOT für die liveCache-Instanz LVC

db db db

INSTROOT für den Content-Server SDB INSTROOT für das produktive SAP-System P01

bin pgm sap ...

Beispiel: drei Instanzen auf einem Server

sapdata saplog

IndepProgPath

Instanz- und releaseunabhängige Programme

programs

bin → x_server pgm → dbmcli

IndepDataPath

data wrk config

LVC SDB P01

Arbeitsverzeichnis für LVC Arbeitsverzeichnis für SDB Arbeitsverzeichnis für P01 Parameterdateien für alle Instanzen

© SAP 2008

„

Das Verzeichnis für die Datenbanksoftware wird seit Version 7.2.04 abhängig von der Datenbankinstanz registriert. Im Database Manager CLI rufen Sie mit dem Kommando db_enum ab, welche Datenbankinstanzen auf dem Server installiert sind und in welchem Verzeichnis die zugehörige Software abgelegt ist. Die Informationen fast und slow beschreiben die Datenbankkerne, die aktiv sind. Der slow-Kernel ist ein spezieller Diagnose- und Trace-Kernel. Beispiel: dbmcli –n <Servername> db_enum P01 /sapdb/P01/db P01 /sapdb/P01/db

7.7.04.29 fast running 7.7.04.29 slow offline

„

Abwärtskompatible Datenbankprogramme liegen im Verzeichnis /sapdb/programs (dbmcli dbm_getpath IndepProgPath). Konfigurationsdaten und Diagnosedateien liegen im Verzeichnis /sapdb/data (dbmcli dbm_getpath IndepDataPath).

„

Folgende Verzeichnisse sollten über die Umgebung erreichbar sein (Hinweis 327578): y PATH-Variable in der SYSTEM-Umgebung: Laufwerk:\sapdb\programs\bin Laufwerk:\sapdb\programs\pgm y PATH-Variable in der USER-Umgebung: Laufwerk:\sapdb\<SID>\db\bin Laufwerk:\sapdb\<SID>\db\pgm Laufwerk:\sapdb\<SID>\db\sap

Unter UNIX sollten die Pfadinformationen angepasst und im dbenv_<Servername>.<shell> des Datenbankadministrators <sid>adm eingetragen werden. „ Ab MaxDB 7.8 wird es ebenfalls die Möglichkeit der “Isolierten Installation” geben. „

© SAP AG

ADM515

4-50

Verzeichnisstruktur im SAP-Umfeld

sapdb

<SID>

programs bin

pgm

env

etc

lib

runtime Support symbols

data

wrk

config

wrk

SID

SID

db saplog

sapdata bin

DISKD0001

pgm

DISKD0002

env

etc

lib

…

incl

misc symbols sap

DISKD0255

DISKL001

…

DISKL0xx

M_DISKL001

…

M_DISKL0xx

Bei gespiegelten Log-Volumes © SAP 2008

„ „ „

„ „ „

„ „

Bei der Installation einer MaxDB Datenbank für SAP-Anwendungen gelten für die benötigten Verzeichnisse bestimmte Namenskonventionen. Im Verzeichnis sapdata sind die Daten-Volumes eingebunden. Es können bis zu 256 Daten-Volumes eingerichtet werden. Im Verzeichnis saplog sind die Log-Volumes eingebunden. Bei Verwendung des gespiegelten LogModus sind die Log-Volumes datenbankseitig gespiegelt. Es gibt keine Beschränkung für die Anzahl von Log-Volumes. Üblicherweise wird nur ein sapdata- und ein saplog-Verzeichnis angelegt. Es sind natürlich auch auch mehr möglich. In diese Verzeichnisse können auch Links gelegt werden, die dann auf Dateinamen in Filesysteme verweisen, auf denen es Kapazitäten gibt, die Volumes anzulegen. Es können aber auch Mountpoints für verschiedene sapdata- oder saplog-Verzeichnisse angelegt werden, um den Platz für die Volumes zu schaffen. Bei einer großen Anzahl von Daten-Volumes empfiehlt SAP, pro Filesystem etwa 5-10 Daten-Volumes anzulegen. Grund: Es gibt keine Möglichkeit dem Betriebssystem mitzuteilen, wieviele parallele Schreib/-Lese-Devices hinter einem Mountpoint liegen. Das frühere DBROOT-Verzeichnis ist nun mit dem INSTROOT vergleichbar und ist unter /sapdb/<SID>/db zu finden. Wenn Ihr System eine hardwarebasierte Spiegelung ermöglicht (RAID-1-Systeme), empfehlen wir, diese für die Spiegelung der Log-Volumes zu nutzen.

© SAP AG

ADM515

4-51

Faustregeln zum Datenbankaufbau

Restart

Undo Undo

Undo

DISKD0003

DISKD0002

DISKD0001 Empfehlungen für Storagesysteme: „

SAP empfiehlt hier, die folgende Berechnungsformel: Quadratwurzel aus der Systemgröße in GB nach oben gerundet’ zur Größenbestimmung der MaxDB Daten-Volumes zu verwenden.

„

Dies stellt ein empirisch ermitteltes Minimum zwischen zu vielen bzw. zu wenigen DatenVolumes dar

„

Es bietet einen gewissen Puffer zu mehr Volumes, so daß die Datenbank in der Zahl der Volumes noch wachsen kann.

© SAP 2008

Datenseiten (Pages) werden vom Datenbanksystem so auf die vorhandenen Daten-Volumes verteilt, dass ein möglichst gleichmäßiger Füllgrad und eine möglichst gleichmäßige I/O-Auslastung der Daten-Volumes gewährleistet ist. Die Daten-Volumes werden hier anhand des absoluten Füllgrads und nicht relativ befüllt. „ Bei Verwendung eines RAID-Controllers mit lokalen Platten wird empfohlen, so viele DatenVolumes anzulegen, wie dort Laufwerke verfügbar sind. Daten-Volumes werden normalerweise auf RAID5-Plattensystemen abgelegt, aufgrund des geringeren Sicherheits-Overheads (ParityInformationen). „ Datenbankunabhängige Dateien wie Betriebssystem-Swap oder Page-Bereiche und Dateien des SAP-Systems sollten auf eigenen Platten liegen. „ Beispiele für die Quadratwurzel-Berechnungsformel: Gesamtgröße Datenbank anzulegende Anzahl von Daten-Volumes 10 GB 4 Volumes 50 GB 8 Volumes 100 GB 10 Volumes 200 GB 15 Volumes 500 GB 23 Volumes 1 TB 32 Volumes Die neueren Installationroutinen des SAPinst verwenden diese Berechnungsformel bereits. „

© SAP AG

ADM515

4-52

Volumes in RAW-Devices oder Dateisystem?

SAP empfiehlt für Unix, alle Volumes auf RAWDevices abzulegen Sicherheit „ Performance „

IO Buffer Cache

„

Da die RAW-Device-Implementierung unter Linux interne File-System-Caches nutzt, sollte hier der Parameter ebenfalls gesetzt werden

„

Beim Mounten von Filesystemen von Fremdherstellern unter Unix bitte die O_DIRECT oder ähnliche Optionen nutzen.

EC

IOThread

N_ DIR E_ OP E

Nutzt die Betriebssystemfunktion O_DIRECT um Volumes und Backups im Filesystem auf direktem Weg ohne File-System-Cache beschreiben zu können

US

„

T

Parameter UseFilesystemCacheForVolume und UseFilesystemCacheForBackup

DB OS

Filesystem Cache

Restart DATA Undo

© SAP 2008

„

„

„

„

„ „

In UNIX-Systemen wird empfohlen, Log- und Daten-Volumes als RAW-Devices zu konfigurieren. Damit wird eine zusätzliche Verwaltungsebene (hier besonders das Journaling moderner Filesysteme) eingespart. Sollte ein Dateisystem wirklich schneller als RAW-Devices sein, werden in der Filesystemsteuerung interne Caches genutzt, die den Betrieb der Datenbank gefährden können, wenn es zu abrupten Systemausfällen kommt (Spannungsverlust o.ä.). Damit können Administratoren nicht davon ausgehen, daß als geschrieben geltende Daten auch wirklich sofort geschrieben wurden. Das Dateisystemmanagement quittiert meist sofort die Annahme der Pages und führt u.U. die Schreibaktion erst einige Zeit später durch, nachdem mehrere Schreibaufträge gesammelt wurden. Es kommt dann während des weiteren Betriebs zu Page-Fehlern beim Zugriff auf hier zuvor nicht gesicherte Pages, spätestens bei der nächsten Sicherung oder Check Data der Datenbank. Damit ist es dann meist nötig, ein Recovery durchzuführen. Zur Sicherheit sollte bei der Verwendung von Filesystemen zusammen mit der MaxDB die Datenbank´parameter UseFilesystemCacheForVolume (USE_OPEN_DIRECT) und UseFilesystemCacheForBackup (USE_OPEN_DIRECT_FOR_BACKUP) gesetzt werden, um wirklich sicherzustellen, daß alle Pages vor der Rückquittierung geschrieben wurden. Dann öffnet der Datenbankkern die Volumes mit der Betriebssystemoption O_DIRECT. Da unter älteren Linux-Releases die Implementierung der RAW-Devices auch Betriebssystemcaches zur Zwischenlagerung der Daten nutzt, ist auch hier der Parameter zur Sicherheit empfohlen. Für andere Unix-Versionen und Windows-Systeme wird dieser Parameter nicht genutzt, selbst wenn er gesetzt werden kann. Unter Windows wird der Zugriff auf die Files immer mit entsprechenden Optionen zum direkten Durchschreiben auf die Platten genutzt, während unter Unix die Mountoptionen ein O_DIRECT üblicherweise bieten.

© SAP AG

ADM515

4-53

Gleichverteilung nach Konfigurationsänderung

DATA

DATA

DATA

DATA

DATA

DATA

„

Data-Volume gefüllt

„

Neuer Data-Volume angefügt

„

Für neue Daten ist nur im neuen Volume Platz: Gefahr eines Hotspots.

„

Gleichverteilung der Data-Volume zu lastarmen Zeiten.

„

Gleichverteilung erreicht, Hotspot vermieden.

DATA

DATA

© SAP 2008

„ „ „

„ „ „

Einhergehend mit der Automatisierung der Page-Clusterung wird auch diese Thema angegangen: Der Gleichverteilungsprozess findet nur zu lastarmen Zeiten statt. Trotzdem kann es zu einem etwas verzögertem Ansprechverhalten kommen, bis die Datenbank die Gleichverteilungsprozedur bei erneuter Last unterbrochen hat. Die Gleichverteilung wird dann später fortgeführt. Ab der Version MaxDB 7.7.06 wird dieses Funktion implementiert. Bisherige Ansätze laufen über den Daten-Cache und führen zur nachhaltigen Cache-Verdrängung und damit zu einer großen Belastung für laufendes Business. In der finalen Implementierung werden Speicherstrukturen außerhalb des Daten-Cache genutzt, die noch bereitgestellt werden müssen.

© SAP AG

ADM515

4-54

Daten-Volumes – Paralleles Formatieren

Paralleles Formatieren der Daten-Volumes während der Aktivierung Beschleunigt den Datenbankaufbau, wenn die Daten-Volumes als Dateien auf Filesystemen liegen „ Parameter: VolumeFormattingMode (default: PARALLEL) „

Datenbankkern Datenbankkern db_activate db_activate

DATA DATA

DATA

© SAP 2008

„

Da der sequenzielle Formatierungsprozess in der Vergangenheit sehr wenig Systemresourcen benötigt hat, konnte es leicht passieren, daß man diesen Schritt der Installation nicht richtig erkannte. Daher wurde der Installationsprozess von Benutzern oft abgebrochen, weil es keine Aktivität auf dem Server gab und der Installationsprozess lange wartete. Mit dieser Umstellung sollte sich der Prozess entscheidend beschleunigen.

© SAP AG

ADM515

4-55

MaxDB-Interna: Übersichtsdiagramm

MaxDB-Interna Thema 1: Prozesse Thema 2: Sperren Thema 3: Speicherbereiche Thema 4: Plattenbereiche Thema 5: Logging

© SAP 2008 / Page 1

„

siehe auch SAP Hinweis 869267 (FAQ: MaxDB LOG-Bereich)

© SAP AG

ADM515

4-56

Log-Volumes

Übliche Größen von Log-Volumes: 2 bis 8 GB Übliche Anzahl von Log-Volumes: 1-2 Volumes

Mirrored Log

M_DISKL001

Mirrored Log

M_DISKL002 Log

DISKL001 Log

DISKL002 © SAP 2008

„

„ „ „ „

Der Log-Bereich kann aus beliebig vielen Log-Volumes und gespiegelten Log-Volumes bestehen. Diese werden von der MaxDB wie ein einziger zusammenhängender Bereich behandelt und zyklisch beschrieben. Daher wird die Administration durch viele Log-Volumes nur komplizierter und bringt keine weiteren Vorteile und die Zahl der Log-Volumes sollte besser klein gehalten werden. Die Empfehlung geht hier zu 1-2 Log-Volumes. Diese sind typischerweise 2 bis 8 GB groß, können aber in Einzelfällen auch bis zu 64 GB groß sein. Alle Log-Volumes sollten, physisch getrennt von den Datenbereichen, auf eigenen Platten liegen. Dies ist aus Gründen der Datensicherheit, Verfügbarkeit und Performance erforderlich. Eine softwareseitige Spiegelung der Log-Volumes über den Datenbankkern kann eingestellt werden, aber SAP empfiehlt, dieses besser durch hardwareseitige Spiegelung (RAID1) zu realisieren. Log-Information wird erst nach erfolgreicher Log-Sicherung zum erneuten Überschreiben freigegeben. Aus Performancegründen rät SAP davon ab, Log-Volumes auf RAID5-Laufwerke zu legen. y Log-Information werden meist in kleinen Portionen (ein bis zwei 8-kB-Pages pro Aktion) asynchron geschrieben. Nur beim Abschluss (COMMIT) einer Transaktion muss der Prozess, der den COMMIT abgesetzt hat, auf die erfolgreiche Durchführung des synchronen Schreibens der Logdaten zu dieser Transaktion warten. Daher sollten die Platten, auf denen der Log-Bereich liegt, möglichst schnell sein, um Wartezeiten beim COMMIT so weit wie möglich zu vermeiden. Gute Log-Schreibzeiten liegen bei unter einer Millisekunde. Ausnahmen sind hier verteilte und gespiegelte Platten in verschiedenen Rechenzentren. Da kann es aufgrund der Signallaufzeiten zwischen der Platten schon mal bis zu 2-3 ms dauern. y Da der Lese-/Schreibaufwand bei einfachen Plattensystemen mit RAID5 bei solchen kleinen Schreiboperationen um Faktoren größer ist als bei RAID1-Platten, sollte RAID1 genutzt werden. Auf großen Plattenstoragesystemen mit erweiterter Cache-Technologie hat der Unterschied in der Technologie zwischen RAID1 und RAID5 keine so große Auswirkung und RAID5 könnte in diesem Fall auch für den Log-Bereich verwendet werden. Definitve Aussagen sind dort nur nach Performancemessungen möglich.

© SAP AG

ADM515

4-57

Log-Volumes Physische Sicht: Log-Volumes

Logische Sicht:

Zusammenhängender Log-Bereich

Log-Volume 1

Log-Volume 2

Parameter AutoLogBackupSize Default: 1/3 der Log-Größe Maximal: 1/2 der Log-Größe

Log-Bereich = Summe der Log-Volumes © SAP 2008

„ „ „

„ „

Die Größe des Log-Bereichs ist die Summe der Größen der Log-Volumes. Physische Log-Segmente, wie sie von anderen Datenbanken her bekannt sind, gibt es nicht. Einzig eine Steuerung von automatischen Log-Sicherungen kann über den Parameter AutoLogBackupSize eingestellt werden. Diese Größe wurde in der Vergangenheit oft fälschlich als Segment bezeichnet. Es handelt sich hier aber um einen Countdown, der am Ende eine automatische Log-Sicherung auslöst. Log-Sicherungen erfolgen generell in Paketen der Größe des Parameters AutoLogBackupSize oder kleiner. Zusätzlich wird in MaxDB auch eine zeitliche Steuerung von automatischen Logsicherungen angeboten.

© SAP AG

ADM515

4-58

Verwaltung der Log-Information Inhalt der ersten Log-Seiten HardwareLogLogInfo-Block Info-Page Page 1

LogPage 2

Freie Freier LogAkt. Freie Page n Log-Page Log-Page Log-Page Log

Reserviert für LOG FULL

Änderung an Tabelleninhalten Before Images After Images

Restart

DATA

Pager Pager Pager

History LogPages Queue

Log-Writer

Log

Undo

© SAP 2008

Am Anfang des Log-Volumes befinden sich insgesamt drei Seiten mit Verwaltungsinformation: y Der Hardware-Info-Block enthält wie bei allen Volumes Konfigurationsinformation der Volumes. y Die Log-Info-Page enthält Informationen, die während eines Restarts benötigt werden, bzw. Informationen über die Lage wichtiger Einträge im Log-Bereich wie z.B. die erste Log-Seite, welche Log-Information über noch offene Transaktionen enthält usw. „ Die Log-Seiten direkt hinter der aktuell verwendeten Seite sind für LOG-FULL-Situationen reserviert, um den nächsten Restart zu ermöglichen. „ Jeder Logeintrag ist mit einer eindeutigen Sequenznummer versehen. „ Die Änderungen an Tabelleninhalten werden in zwei Arten protokolliert: y Die Before-Images bzw. die Zustände der Seiten vor der Änderung werden in History-Pages innerhalb des Datenbereichs der Datenbank gehalten. Von dort können sie auch unter Umständen auf die Daten-Volumes verdrängt werden. Diese tritt bei OLTP-Installationen nur sehr selten auf. Meist ist es so, daß die History-Pages schon lange vor der Auslagerung im DataCache gelöscht werden, da die zugehörige Transaktion abgeschlossen ist. y Die After-Images, also die Änderungsvorschriften werden stattdessen auf das Log-Volume geschrieben und dauerhaft gesichert. „

© SAP AG

ADM515

4-59

Logging von Änderungen

Wenn Transaktionen Daten ändern, werden

Log-Queue

„

die Zustände der Daten vor der Ausführung der Änderung bleiben im Datenbereich und werden dort in die History umkopiert (Before Image)

„

die geänderten Daten in Form einer Änderungsvorschrift in der LogQueue gespeichert (AfterImage)

s=1 update Table set s = 3

Upd s (3)

Data-Cache

Table

History s (1)

ss (15) (3)

© SAP 2008

„

Der Prozess der Trennung von kurzfristigen Log-Daten (Before Images) und langfristig zu sichernden Log-Daten sehen wir hier noch mal ein einem ausführlicheren Beispiel.

© SAP AG

ADM515

4-60

Schreiben von Log-Informationen

Log-Writer

Der Logwriter schreibt die gefüllten LogPages aus der LogQueue auf das Log-Volume (asynchron)

Log

Nach dem Abschluß einer Transaktion (COMMIT) müssen die Daten aus der LogQueue synchron auf das LogVolume geschrieben werden

Log-Queue Upd s (3) commit

Data-Cache

Die Daten in den History-Pages die zu der Transaktion gehören, werden dann im Anschluß von dem Garbage-Collector asynchron gelöscht

Table

History s (1)

ss (15) (3)

© SAP 2008

„

Erfahrungsgemäß werden die History-Pages fast nie aus dem Data-Cache auf die Daten-Volumes ausgelagert. Im liveCache-Umfeld ist das schon mal der Fall, wenn viele Consistent Views in Aktion sind.

© SAP AG

ADM515

4-61

Multiple LogQueues

Um eine bessere Skalierbarkeit beim Schreiben des Logs zu erreichen, ist es nun möglich, mehrfache Log Queues zu verwenden. „

Die Anzahl der Queues wird durch die UKTs bestimmt, sollte aber nicht größer als diese sein, so daß jeder UKT in eine separate Queue schreibt.

Nachteil: Stärkeres Log-Aufkommen, da unvollständige Seiten beim COMMIT geschrieben werden müssen, um die Synchronität der Queues zu gewährleisten. „

Parameter: LogQueues (default = MaxCPUs)

UKT user 1

UKT user 3

user 2

user 4

Log Queue

Log Queue

Upd

Ins

K1,Y

R1,X

C

C

UKT logwriter

Empfohlen wird diese Funktion nur für liveCacheInstanzen, da dort das Log-Aufkommen in größeren Paketen an den Logwriter übertragen wird. Log

© SAP 2008 / Page 1

„

Jede einzelne Log-Queue (pro UKT) kann mit dem Parameter LogQueueSize erweitert werden.

© SAP AG

ADM515

4-62

Logwriter abschalten Ö Vorsicht !!

Der Logwriter kann deaktiviert werden.

UKT user 3

Damit sind folgende schwerwiegenden Nachteile verbunden:

user 4

„

Änderungen von Business-Transaktionen werden nicht mehr protokolliert

„

Bei Datenbankproblemen können Shutdown-SAVEPOINTs ausbleiben (abschließende Synchronisation fehlt)

Log Queue

„

Zeitgesteuerte SAVEPOINTs werden nicht mehr ausgeführt

R1,X

Ins C

Alle Faktoren zusammen stellen eine große Gefahr dar und können zu teurem Verlust von Business-Informationen führen! Im Problemfall startet die Datenbank wie üblich mit dem Stand des letzten SAVEPOINTs, der aber u.U. Tage zurückliegen kann. Alle Transaktionsdaten sind verloren !!

UKT logwriter

STOP

Log © SAP 2008 / Page 1

„

In Zukunft wird diese Möglichkeit nicht mehr so einfach in den graphischen Frontends angeboten

© SAP AG

ADM515

4-63

Log-Spiegellung

Log-Spiegelung deaktiviert

Log-Spiegelung aktiviert

Log

Mirrored Log

Log

Mirrored Log

DISKL001

RAID1

DISKL001

M_DISKL001

„

Beispiel für eine Konfiguration ohne gespiegelte Volumes und RAID1-Unterstützung

„

Beispiel für eine Konfiguration mit gespiegelten Volumes ohne RAID1-Unterstützung

„

Plattenfehleranzeige im Verwaltungstool des RAID

„

Plattenfehler protokolliert in Diagnosedateien der MaxDB

© SAP 2008 / Page 1

„

Der Log kann mit MaxDB folgendermaßen betrieben werden: y Log-Spiegellung deaktiviert (Parameter UseMirroredLog = NO): Log-Einträge werden in ein Log-Volume gesichert. Die Daten- und Ausfallsicherheit wird durch hardwarebasierte Spiegelung (z. B. mit RAID1- oder RAID5-Systemen) gewährleistet. Im Falle eines Fehlers auf den verwendeten Platten werden die Tools der RAID-Systeme genutzt, um die Fehler zu beheben. Die Datenbankinstanz sollte nicht betroffen sein, da die Verwaltungs-Software des RAID die Mängel online bereinigt. Fehler am RAID können nur innerhalb der VerwaltungsTools erkannt werden. Sollten trotzdem Fehler zur Datenbank hin weitergegeben werden, führt dies unweigerlich zum Emergency Shutdown, weil die Datenbank die Log-Integrität auf den Platten nicht mehr garantieren kann. y Log-Spiegellung aktiviert (Parameter UseMirroredLog = YES): Log-Einträge werden in zwei Log-Volumes gleichzeitig (gespiegelt) gesichert. Tritt ein Fehler in einem der Log-Bereiche auf, dann steht der zweite Log-Bereich zur Verfügung. Da die Datenbank für diese Spiegelung verantwortlich ist, kann sie hier auch die Fehler auf den Platten erkennen und protokollieren. Sollte ein Fehler auf dem Original oder dem Spiegel auftreten, wird die Datenbank sofort über einen Emergency Shutdown gestoppt, um nicht in die Gefahr zu laufen, daß die Datenbank länger mit defektem Log betrieben wird. Der Softwarespiegel kann dann genutzt werden, um den Fehler zu beheben. y Überschreibmodus (Overwrite Mode, Kein MaxDB-Parameter): Hiermit werden Log-Bereiche ohne vorherige Sicherung der Log-Einträge überschrieben. In einer SAP-Umgebung kommt dieser Log-Modus nur bei Upgrades oder Umsetzungsoperationen zum Einsatz. Im Produktivbetrieb sollten Sie diesen Überschreibmodus (Overwrite Mode) nicht verwenden. Beim Umschalten des Log-Modus und Aktivierung des Überschreibmodus wird die Sicherungshistorie aufgebrochen.

© SAP AG

ADM515

4-64

MaxDB Interna: Zusammenfassung

Sie können nun: „

Den technischen Hintergrund der MaxDB erläutern

© SAP 2008 / Page 1

© SAP AG

ADM515

4-65

© SAP AG

ADM515

4-66

Übungen Kapitel: 3 Thema: MaxDB-Interna Am Ende dieser Übungen können Sie: • Tiefer in die inneren Strukturen sehen.

D.

3-1

Setzen Sie bitte die Übungen des vorherigen Kapitels fort.

3-2

Savepoint analysieren 3-2-1

3-3

Laufzeit-Umgebung der Datenbank analysieren 3-3-1

3-4

Öffnen Sie im Baum des Database Studio unter dem CONTROL-User -> Database Server -> RTE die aktuelle Laufzeit-Umgebung Ihrer Datenbank und vergleichen die Ausgaben mit denen in den Schulungsunterlagen.

Nutzung der Page-Clusterung auch für das Füllen der Datenbank 3-4-1

© SAP AG

Nutzen Sie das Database Studio um für Ihre Instanz um die Aktivitäten der Übungen zu Kapitel 2 zu kontrollieren Während der Übungen wurden unzählige Savepoints erzeugt, deren Informationen im knlMsg protokolliert wurden. Vergleich Sie die Ausgaben mit den Informationen aus den Unterlagen. Suchen Sie im knlMSg nach Einträgen die den String „SAV“ enthalten.

Zu diesem Zweck steht ein erweiteres Filldb.py mit dem Namen Filldbcluster.py zur Verfügung, das genauso gesteuert wird.

ADM515

4-67

© SAP AG

ADM515

4-68

Lösungen Kapitel: 3 Thema: MaxDB-Interna

3-1

Setzen Sie bitte die Übungen des vorherigen Kapitels fort.

3-2

Savepoint analysieren 3-2-1

3-3

Laufzeit-Umgebung der Datenbank analysieren 3-3-1

3-4

Öffnen Sie im Baum des Database Studio unter dem CONTROL-User -> Database Server -> RTE die aktuelle Laufzeit-Umgebung Ihrer Datenbank und vergleichen die Ausgaben mit denen in den Schulungsunterlagen.

Nutzung der Page-Clusterung auch für das Füllen der Datenbank 3-4-1

© SAP AG

Nutzen Sie das Database Studio um für Ihre Instanz um die Aktivitäten der Übungen zu Kapitel 2 zu kontrollieren Während der Übungen wurden unzählige Savepoints erzeugt, deren Informationen im knlMsg protokolliert wurden. Suchen Sie im knlMSg nach Einträgen die den String „SAV“ enthalten.

Zu diesem Zweck steht ein erweiteres Filldb.py mit dem Namen Filldbcluster.py zur Verfügung, das genauso gesteuert wird. Das Füllen der Datenbank und die Option –clear sollte ein bessere Performance zeigen. Die IO-Zeiten in Database Server -> DEV_IO sollten sinken. Hierzu muß aber erst die ausführliche Zeitmessung aktiviert sein, damit alle Spalten in der Ausgabe des DEV_IO auch gefüllt werden.

ADM515

4-69

© SAP AG

ADM515

4-70

Datenbanksicherung und -wiederherstellung

Inhalt: Methoden und Optionen von Datenbanksicherungen „ Allgemeine Sicherungsstrategie „

Durchführung von Wiederherstellungen „ Aktionsmatrix für Wiederherstellungsszenarien „

© SAP 2008

© SAP AG

ADM515

5-1

Datenbanksicherung und -wiederherstellung: Lernziele

Am Ende dieses Kapitels, können Sie: Sicherungen und Wiederherstellungen durchführen „ Kennen wichtige Aspekte einer Sicherungsstrategie „

© SAP 2008

© SAP AG

ADM515

5-2

Agenda I

1. Der erste Kontakt 1.1. 1.2. 1.3. 1.4. 1.5. 1.6.

3. MaxDB-Interna

Einführung Werkzeuge und Schnittstellen Architektur und Betriebszustände MaxDB und SAP NetWeaver Integration mit SAP NetWeaver Serverlandschaft der Schulung

3.1. 3.2. 3.3. 3.4. 3.5.

4. Datenbanksicherung und -wiederherstellung

2. MaxDB betreiben 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8.

Prozesse Sperren Speicherbereiche Plattenbereiche Logging

Überblick Database Studio Wichtige Informationsquellen im Database Studio Benutzer der MaxDB im SAP-Umfeld Plattenbereiche für Daten und Log Konfigurationsänderungen DBFULL und LOGFULL Situationen Parameter Übungswerkzeug

4.1. 4.2. 4.3. 4.4. 4.5. 4.6. 4.7. 4.8. 4.9.

Vollständige Datensicherung Inkrementelle Datensicherungen MaxDB Snapshots Log-Sicherungen Automatische Log-Sicherung Überprüfen der Sicherungen Sicherungsstrategie Externe Sicherungstools Wiederherstellungen

© SAP 2008

© SAP AG

ADM515

5-3

Agenda II

5.

Weitere Administrationsthemen 5.1. 5.2. 5.3. 5.4. 5.5. 5.6. 5.7.

7.

Prüfen der Datenbank Erstellen einer Datenbankinstanz Neuinitialisierung einer Datenbankinstanz Installation eines Patches (Releasewechsel) Migration zur MaxDB Hochverfügbarkeit MCOD

Ausblick auf MaxDB 7.8 7.1. 7.2. 7.3. 7.4. 7.5.

Übersicht Änderungen des Datenbankkerns Neue administrative Funktionen Setup und Infrastruktur Interface & User

6. Performance-Tuning und Problemsituationen 6.1. 6.2. 6.3. 6.4. 6.5. 6.6.

B*-Bäume Optimierung Monitore des SAP NetWeaver Vermeidbare Probleme Diagnosedateien und TraceMöglichkeiten Fehlerarten und deren Analyse

© SAP 2008

© SAP AG

ADM515

5-4

MaxDB-Sicherungskonzept

Datensicherung

DATA_A0

Periodische Sicherung des Datenbestandes auf externe Sicherungsmedien DATA_A2

DATA_A1

Log-Sicherung

Periodische Sicherung des LogBereichs über Filesicherungen auf externe Sicherungsmedien zur Vermeidung von LOG FULLSituationen

File(s)

LOG

LOG_A1 LOG_A2 LOG_A3 LOG_A4

Wichtig !! Alle Sicherungen werden durch den Datenbankkern durchgeführt Dateisicherungen von Volumes sollten nur in Ausnahmefällen angelegt werden © SAP 2008

In einer produktiv genutzten Datenbank ist das regelmäßige Sichern von Daten- und Logbereich unerlässlich, um Datenverlusten vorzubeugen. „ MaxDB bietet mit dem Database Studio ein komfortables Werkzeug zur Durchführung dieser Sicherungen. Dieses Werkzeug bietet neben der Anzeige der Sicherungshistorie auch die Möglichkeit, externe Sicherungstools wie z.B. Legato Networker, NetVault und TSM einzusetzen. Seit frühen Datenbankversionen der MaxDB (SAP DB) wird auch die von Oracle bekannte BackintSchnittstelle angeboten. Darauf aufbauend gibt es eine Erweiterung des backint-Standards, Backint for MaxDB. Diese Erweiterung erlaubt es auch, Pipes für die Sicherung von Datenbanken über diese Schnittstelle zu verwenden. „ Eine Sicherung der Datenbankinstanz umfasst zwei Teilbereiche: y Periodisches Sichern des Datenbereichs y Sichern der Log-Einträge „ Die Datenbank bleibt während der Durchführung von Sicherungen uneingeschränkt verfügbar. Lediglich die Performance kann etwas eingeschränkt sein. Deshalb wird empfohlen, diese zu Zeiten niedriger SAP-Dialoglast auszuführen. „

© SAP AG

ADM515

5-5

Datensicherung: vollständig - inkrementell

DATA 1

Complete = Vollständige Datensicherung

DATA 2

...

DATA n

Incremental = seit der letzten vollständigen Sicherung geänderte Seiten

© SAP 2008 / Page 1

„ „

„

Die Backup-Funktionalitäten im Database Studio sind im Kontextmenü der Instanz unter Backup… zu erreichen. Mit Complete wird eine vollständige Sicherung aller benutzten Seiten des Datenbereichs erzeugt. Zusätzlich wird die Konfiguration der Datenbankinstanz gesichert. So ist im Fall einer Wiederherstellung auch die Wiederherstellung der Originalkonfiguration möglich. ConverterSeiten werden nicht gesichert. Incremental erzeugt eine inkrementelle Sicherung des Datenbereichs. Diese Sicherung enthält alle Seiten, die seit der letzten vollständigen Datensicherung geändert wurden.

© SAP AG

ADM515

5-6

Parallele Datensicherung

DATA 1

DATA 2

DATA 3

IOThreads

IOThreads

IOThreads

Ring puffer

IOThreads

Sicherungszeiten von 1 TB in 1:25 h sind dokumentiert für kundeneigene Systeme

IOThreads Datenbankparameter MaxBackupMedia = 2

© SAP 2008 / Page 1

Die zu sichernden Datenseiten können parallel auf mehrere Medien (Templates) gesichert werden. Dadurch wird eine Beschleunigung der Sicherung erreicht. Beispiel: Die Laufzeit mit drei Bandstationen beträgt im Optimalfall ein Drittel der Laufzeit bei Verwendung einer Bandstation. „ Die maximale Anzahl paralleler Sicherungsmedien (Templates) wird durch den Datenbankparameter MaxBackupMedia (1 - 32) festgelegt. Eine Änderung dieses Parameters wird erst nach dem nächsten Neustart der Datenbank wirksam. Systemintern wird ein Speicherbereich als (Ring-)Puffer (8 x 8K Blockung, bei Page-Clusterung 8 x 64K Blockung) bereitgestellt, in den die Schreib- und Lesevorgänge der Server-Tasks und der für die Sicherung temporär erzeugten IOThread-Prozesse erfolgen. Die Grenzen dieses Verfahrens bilden entweder die Zugriffsgeschwindigkeit der Daten-Volumes, die Schreibleistung der Backup-Geräte oder die Transportschicht (z.B. Netzwerk) zwischen dem Datenbank-Server und den Backup-Geräten. Solange diese Grenzen nicht erreicht sind, skaliert das Verfahren im parallelen Betrieb mit jedem weiteren Backup-Gerät. „ Folgende Voraussetzungen müssen erfüllt sein, um die Parallelisierung zu ermöglichen: y Vorhandensein mehrerer gleichwertiger Bandstationen, Pipes oder Plattenbereiche y Der Wert von MaxBackupMedia entspricht der Anzahl der zu verwendenden Bandstationen/Sicherungsdateien oder Pipes. y Eine Gruppe von Sicherungsmedien (Templates) mit einem Sicherungsmedium pro Bandstation wurde angelegt „ Unterschiedliche Sicherungsmedien (in Größe und Geschwindigkeit): y Sollte eines der Devices (Bandlaufwerk, Pipe oder Platte) langsamer als die restlichen sein, wird es je nach den gegebenen Möglichkeiten mit der maximalen Geschwindigkeit beschrieben, unabhängig von den anderen Devices. Daher können in Notsituationen auch schnelle Platten mit langsamen Bandlaufwerken kombiniert werden. Am Ende der Sicherung werden auf dem langsamen Device verhältnismaßig weniger Daten über die Zeit der Sicherung geschrieben worden sein, als auf den schnelleren Devices. „

© SAP AG

ADM515

5-7

Unterstützte Sicherungsmedien Data Volumes File

Pipe

Unterstützte Medien: Band / Datei / Pipe

File(s)

Pipes Pipes

Mediengruppen: Bis zu 32 parallel genutzte Bänder / Dateien / Pipes

DATA

Log Volumes File(s)

Unterstützte Medien der man. Log-Sicherung: Datei / Pipe

Pipes

LOG File.3

File.2

File.1

Automatische Log-Sicherung: Versionsdateien

© SAP 2008 / Page 1

Die Datensicherung kann auf eines oder mehrere Medien erfolgen. y Wenn mehrere Medien verwendet werden sollen, müssen diese in einer Gruppe paralleler Sicherungsmedien (Template Group) organisiert sein. y Unterstützte Sicherungsmedien sind Bänder, Dateien und Pipes. Pipes werden u.a. als Schnittstelle zu externen Sicherungstools genutzt. „ Interaktive Log-Sicherungen können auf reguläre Dateien oder Pipes erfolgen. y Parallele Log-Sicherungen werden nicht unterstützt. y Pipes werden nur dann unterstützt, wenn dabei Sicherungstools die Daten aus der Pipe entgegennehmen und nach Abschluss der Sicherung eine Rückmeldung vom Sicherungstool erfolgt. „ Automatische Log-Sicherungen über die Funktion AutoLog können nur in Dateien erfolgen. y Pipes sind nicht möglich. y Die automatische Log-Sicherung schreibt Versionsdateien (Version Files). y Mit dem dbmcli-Kommando archive_stage können diese im Dateisystem abgelegten Versionsdateien automatisch an ein Sicherungstool weiterreicht werden. „

© SAP AG

ADM515

5-8

Backup auf Windows Share

Der Benutzer <SID>ADM muss auf dem Server des Windows Shares bekannt sein und alle Rechte zum Zugriff (Netzwerk und Dateisystem) auf den Share besitzen © SAP 2008

„ „

„ „ „

Normalerweise arbeitet der Datenbankkern auf dem Windowsserver unter dem Local System Account. Local System Accounts besitzen aber generell keine Berechtigung auf Netzwerk-Shares zuzugreifen und daher funktioniert in dieser Form auch keine Sicherung auf einen Netzwerk-Share (Fehler -903), wenn auf den Share vom Datenbankkern aus zugegriffen wird. Daher muß der User, unter dem der Datenbankkern läuft, geändert werden. Hierzu bietet sich der <sid>adm User an, da dieser bereits das richtige Environment usw. besitzt. Anschließend wird diese Änderung gültig, wenn der Datenbankservice oder die Datenbankinstanz über das Database Studio durchgestartet wird. Bitte geben Sie immer UNC-Namen an, wie z.B. „\\hostname\sharename“ und verwenden bitte keine lokalen Windowsshares.

© SAP AG

ADM515

5-9

Datenbanksicherung und -wiederherstellung: Übersichtsdiagramm Datenbanksicherung und -wiederherstellung Thema 1: Vollständige Datensicherung Thema 2: Inkrementelle Datensicherungen Thema 3: MaxDB Snapshots Thema 4: Log-Sicherungen Thema 5: Automatische Log-Sicherung Thema 6: Überprüfen der Sicherungen Thema 7: Sicherungsstrategie Thema 8: Externe Sicherungstools

© SAP 2008 / Page 1

© SAP AG

ADM515

5-10

DAT_00001

Vollständige Datensicherung

DATA 1 DATA 2

DataVolumes

DATA n

Label: DAT_00001

Parameterdatei /sapdb/data/config/<SID>

LogVolumes

LOG 1 LOG 2 © SAP 2008 / Page 1

„

„ „ „ „

„ „

Eine vollständige Datensicherung speichert alle belegten Seiten der Daten-Volumes auf Sicherungsmedien (Templates). Zusätzlich wird zu Beginn mit jedem Datenstrom einer Sicherung (Template Gruppen) die aktuelle Parameterdatei (im Umfeld des SAP Netweaver der Inhalt aus der Datei /sapdb/data/config/<SID>) mitgeschrieben. So ist es im nachhinein immer möglich, die für diese Sicherung benötigte Instanzumgebung wieder herzustellen. Jede Sicherung erhält ein Label in der Reihenfolge der Sicherungen. Dieses Label wird durch die Administrationswerkzeuge benutzt, um die Sicherungen voneinander zu unterscheiden. Dabei wird auch dann die Sicherungsnummer um eins erhöht, wenn die Sicherung nicht erfolgreich war. Für jede Sicherung wird ein Eintrag in der Sicherungshistorie (Datei dbm.knl) im Arbeitsverzeichnis der Datenbank geschrieben. Sicherungen werden durch den Datenbankkern durchgeführt. Online-Sicherungen mit Betriebssystemmitteln (z.B. dd, copy) von Plattenbereichen der Datenbankinstanz, auf denen die Volumes abgelegt sind, sollten nicht durchgeführt werden. Meist sind diese nutzlos, da offene Dateien nicht gesichert werden können und/oder nicht vollständig gesichert werden. Auch OfflineSicherungen mit Betriebssystemmitteln sollten Sie aus ähnlichen Gründen vermeiden. Nutzen Sie die Funktionen der Datenbank, um Sicherungen durchzuführen. Der Vorteil ist, daß jede gesicherte Page aus den Daten-Volumes während des Lesens geprüft wird (Header/Trailer-Vergleich) und damit frühzeitig Fehler gefunden werden können. Diese Überprüfung könnte mit einer Konsistenzprüfung Check Data (Verify) verglichen werden, obwohl die Analysetiefe nicht so weit geht, wie bei einem normalen Verify.

© SAP AG

ADM515

5-11

Anlegen des Sicherungstemplate

© SAP 2008

„ Bevor Sie Sicherungen durchführen können, müssen Sie die entsprechenden Sicherungsmedien (Templates)

definieren. Im Database Studio haben Sie unter Backup Ö Templates die Möglichkeit, Sicherungs-Templates oder Template-Gruppen paralleler Sicherungsmedien anzulegen und zu ändern. „ Um parallele Sicherungsmedien anlegen zu können, muß der Parameter MaxBackupMedia entsprechend der

Anzahl der Einzelmedien in einem parallelen Medium gesetzt sein. Wenn z.B. eine Mediengruppe aus 10 Einzelmedien bestehen soll, dann muß der Parameter MaxBackupMedia den Wert 10 haben. „ Folgende Angaben zum Template können festgelegt werden:

y Name des Sicherungsmediums. Dieser Name kann unabhängig vom verwendeten Ablageort (Device/File) gewählt werden. y Backup Type: Geben Sie an, für welche Art von Sicherung dieses Medium genutzt werden soll. y Device Type: Band, Datei oder Pipe y Backup Tool: Typ des externen Sicherungstools (falls verwendet; mehr dazu auf der folgenden Seite) y Device/File: Pfad auf ein Device, Name einer definierten Pipe oder der Name einer Datei inklusive Pfad. Wenn Sie keinen Pfad angeben, wird eine Datei im Arbeitsverzeichnis der Datenbankinstanz erzeugt. y Size (KB): Maximalgröße der Sicherung, die auf diesem Medium erzeugt werden kann (wenn Sie keine Angabe machen, können Dateien mit unbegrenzter Größe angelegt werden) y OS Command: Sie haben hier die Möglichkeit, Betriebssystemkommandos für das Sichern auf Band anzugeben. y Overwrite: Diese Option ermöglich das fortlaufende Sichern in die gleiche Datei mit Überschreiben der vorherigen Sicherung. Sie ist mit Vorsicht zu nutzen, weil damit die Sicherungshistorie ausgehebelt wird und es keine Möglichkeit für das Zurückgehen zu einer der letzten Sicherungen gibt. y Block Size: Hiermit wird bestimmt, wie groß die Datenpakete sind, die auf das Medium geschrieben werden. Sollte Page Clusterung auf der Instanz genutzt werden, muß dieser Wert dringend größer als ein Vielfaches der verwendeten Clustergröße eingestellt werden (minimal einfache Größe z.B. 64.) y Autoloader: Markieren Sie das Feld Autoloader, wenn Sie eine Bandstation mit automatischem Bandwechsel verwenden wollen.

© SAP AG

ADM515

5-12

Externe Sicherungswerkzeuge

© SAP 2008

MaxDB unterstützt mehrere externe Sicherungstools und Sicherungstechniken: y Networker (NSR) y Tivoli Storage Manager (TSM) y Werkzeuge, die das Interface Backint for MaxDB oder Backint for Oracle unterstützen (BACK) z.B. - HP Data Protector >6.0 unterstützt Backint for MaxDB - Comvault QiNetix > 6.1 unterstützt Backint for MaxDB - Alle weiteren nicht aufgeführten und am Markt bekannten externen Sicherungstools müssen über das Backint for Oracle angeschlossen werden und benötigen erfahrungsgemäß weitere Adapter der Anbieter von externen Sicherungstools. „ Um eines dieser Werkzeuge zu unterstützen, ist als Device Type des Sicherungstemplates Pipe notwendig. „ Weitere beispielhafte Definitionen für Templates unter Unix und Windows: y Windows: Erstes Bandlaufwerk: \\.\tape0 Pipe: \\.\pipe\PipeName UNIX: Bandlaufwerke z.B.: /dev/tape0 Pipes: /tmp/pipe0 Template-Definitionen werden in der Datei dbm.mmm im Arbeitsverzeichnis der Datenbankinstanz abgelegt. „

© SAP AG

ADM515

5-13

Backup-Wizard – Einstieg

Ohne Backup-Historie

Mit Backup-Historie

© SAP 2008

Mit dem Database Studio wird ein Backup Wizard verwendet, der Sie bei der Durchführung des Backups unterstützt. „ Um eine vollständige Datensicherung zu starten, wählen Sie im Kontextmenü des Instanznamens Backup…. „ Im ersten Schritt wird nach der Art der Sicherung gefragt: Vollständige Datensicherung, Inkrementelle Datensicherung, Log-Sicherung „ Falls noch keine vollständige Datensicherung erfolgt ist, wird nur diese Option beim Start des Wizards angeboten und eine entsprechene Warnung gezeigt. „

© SAP AG

ADM515

5-14

Backup-Wizard – Vorbereitung und Start

Anlegen und Verändern eines Sicherungstemplates

Vorsicht bei OVERWRITE !! © SAP 2008 / Page 1

Wählen Sie im folgenden Schritt ein Medium bzw. Template aus oder legen ein Neues an. „ Vor der engültigen Ausführung der Sicherung wird noch einmal eine Zusammenfassung der Randbedingungen gegeben. „ Über den Back- oder Next-Button kann der Sicherungsprozess noch einmal zurückgerollt und Eingaben geändert werden. „ Mit der Option OVERWRITE aus der Templatedefinition sollten Sie vorsichtig sein. Es werden damit sehr leicht Sicherungsdateien überschrieben, die noch benötigt werden. Stattdessen sollten Sie Scripte anlegen, die die Dateien weiter verarbeiten (z.B. Transport auf nachgeschaltete Sicherungslösung). Diese Scripte löschen nach erfolgreicher Nachbehandlung die originalen Sicherungsdateien, so daß die Datenbank immer wieder mit einem verfügbaren Dateinamen arbeiten kann. Bitte prüfen Sie, ob nicht eine direkte Verbindung von der MaxDB zur nachgeschalteten Sicherungslösung möglich ist. Dazu sehen Sie später Konzepte. „

© SAP AG

ADM515

5-15

Backup-Wizard – Hintergrundverarbeitung

© SAP 2008 / Page 1

In diesem Sicherungsschritt wird die Sicherung schließlich ausgeführt. „ Über den Button Background kann das Popup und die damit ausgeführte Funktion in den Hintergrund verschoben werden. Ein Doppelklick auf den Eintrag in der Aktionsliste unter dem Reiter Actions bringt die Details zu der Aktion im Wizard-Fenster zurück und Sie können sich über den Status der Aktion informieren. „ Die Sicherungshistorie zeigt anschließend die vollständige Sicherung als Startpunkt für weitere Sicherungen an. „

© SAP AG

ADM515

5-16

Sicherungen: Übersichtsdiagramm

Datenbanksicherung und -wiederherstellung Thema 1: Vollständige Datensicherung Thema 2: Inkrementelle Datensicherungen Thema 3: MaxDB Snapshots Thema 4: Log-Sicherungen Thema 5: Automatische Log-Sicherung Thema 6: Überprüfen der Sicherungen Thema 7: Sicherungsstrategie Thema 8: Externe Sicherungstools

© SAP 2008 / Page 1

© SAP AG

ADM515

5-17

Inkrementelle Datensicherung

DAT_00001 PAG_00002

DATA 1

PAG_00003

DataVolumes

PAG_00002

DATA 2 DATA n

DAT_00004 PAG_00005 PAG_00006

LogVolumes

LOG 1 LOG 2 © SAP 2008 / Page 1

Neben der vollständigen Datensicherung können einzelne geänderte Datenseiten auch über eine inkrementelle Datensicherung gespeichert werden. Dabei werden nur die Datenseiten gesichert, die seit der letzten vollständigen Datensicherung geändert wurden. „ Die Versionsnummer des Labels wird bei jeder Datensicherung um eins erhöht, auch dann, wenn die Sicherung nicht erfolgreich war. „ Diese Information wird zuerst in die Sicherunghistorie geschrieben. „

© SAP AG

ADM515

5-18

Inkrementelle Datensicherung - Beginn

© SAP 2008 / Page 1

„

Eine inkrementelle Datensicherung kann im Kontextmenü der Instanz innerhalb des Database Studios unter Backup... → Backup Wizard → Incremental Data Backup gestartet werden, wenn zuvor eine vollständige Datensicherung durchgeführt wurde.

© SAP AG

ADM515

5-19

Inkrementelle Datensicherung – Definition

© SAP 2008 / Page 1

„

Wie auch bei der vollständigen Datensicherung müssen Sie anschließend das entsprechende Sicherungmedium (Template) auswählen oder gegebenenfalls anlegen. Die weitere Vorgehensweise ist identisch mit der der vollständigen Datensicherung.

© SAP AG

ADM515

5-20

Inkrementelle Datensicherung – Ausführung

© SAP 2008 / Page 1

Unter dem Reiter Summary finden Sie die Einstellungen zur ausgeführten Sicherung „ Auf dem Reiter Results nach der Ausführung die Ergebnisse „

© SAP AG

ADM515

5-21

Inkrementelle Datensicherung – Sicherungshistorie

„ Sicherungshistorie

„ Details

der Sicherung

„ Verfügbare

Sicherungstemplates „ laufende

oder abgeschlossene Aktionen

© SAP 2008 / Page 1

Die Sicherungshistorie zeigt die inrementelle Sicherung als letzte Aktion oben in der Liste an. „ Nach Selektion wird unter Details (Klappmenü) die Label-Information ausgegeben. „ Die verfügbaren Sicherungsmedien werden im darunterliegenden Klappmenü Template angezeigt „ Schlußendlich finden sie im unteren Teil des Database Studios die Aktionsinformationen im Reiter Actions. Bei einem Doppelklick auf die Einträge dort erhalten Sie die zugehörigen Wizards und deren Aktionsergebnisse wieder angezeigt. „

© SAP AG

ADM515

5-22

Sicherungen: Übersichtsdiagramm

Datenbanksicherung und -wiederherstellung Thema 1: Vollständige Datensicherung Thema 2: Inkrementelle Datensicherungen Thema 3: MaxDB Snapshots Thema 4: Log-Sicherungen Thema 5: Automatische Log-Sicherung Thema 6: Überprüfen der Sicherungen Thema 7: Sicherungsstrategie Thema 8: Externe Sicherungstools

© SAP 2008 / Page 1

© SAP AG

ADM515

5-23

MaxDB Snapshots

Snapshots frieren einen DB-Zustand ein um ihn später z.B. wieder herstellen zu können; Alle weiteren Änderungen erfolgen in neuen (kopierten) Pages MaxDB bietet multiple Snapshots mit eigenen Funktionen innerhalb der Datenbank an Snapshots können im Modus Online erzeugt oder gelöscht werden Eine Wiederherstellung eines Zustandes aus einem Snapshot kann nur im Modus Admin erfolgen Typischer Einsatz „ Sehr schnelles Point-In-Time Recovery

(z.B. bei SAP Upgrades, Einspielen von SP)

„ Restore von Training-Systemen auf definierten Status

Vor dem Upgrade

Upgrade nicht erfolgreich

System wieder auf Datenbestand des Snapshot zurückgesetzt

Create SNAPSHOT

DATA

Upgrade Daten SNAP-Daten

Restore SNAPSHOT

DATA

© SAP 2008

„ „ „

„

„

„

Ab Version 7.7 haben Sie die Möglichkeit, den Datenbereich einer MaxDB mit Hilfe interner Snapshots in mehrfacher Ausführung einzufrieren. Ein Snapshot kann im Zustand Online erzeugt werden. Zu einem späteren Zeitpunkt können Sie auf den Datenbestand des Snapshots zurücksetzen und/oder den Snapshot löschen. Mit dem Kommando CREATE SNAPSHOT kopiert der Datenbankkern die Restart-Page aus dem zweiten Block des ersten Data-Volume an eine andere Position. Des weiteren wird der komplette Converter kopiert. Der originale Restart-Record enthält einen Verweis auf den für den Snapshot relevanten Restart-Record. Mit dem Kommando RESTORE SNAPSHOT wird der aktuelle Converter gelöscht. Alle nicht mehr benötigten Blöcke werden als wieder frei markiert. Die überschüssigen Transaktionsinformationen werden aus dem Log herausgelöscht, so daß der Zustand HISTLOST eintritt. Ab dem nächsten Restart arbeitet die Instanz mit den zum Zeitpunkt des CREATE SNAPSHOT eingeforenen und nun reaktivierten Daten. Die Anweisung DROP SNAPSHOT löscht den zugehörigen Restart-Record und den damit verknüpften Converter, der für diesen Snapshot relevant ist. Das FreeBlockManagement (FBM) markiert alle nicht mehr benötigten Blöcke als frei. MaxDB unterstützt mehrere Snapshots. Der Betrieb der Instanz mit multiplen Snapshots führt zu einem erhöhtem Belegungsgrad im Datenbereich.

© SAP AG

ADM515

5-24

MaxDB Snapshots – anlegen

© SAP 2008

„

Die entsprechenden DBMCLI Kommandos lauten: dbmcli –U c db_execute CREATE SNAPSHOT “Kommentar” Es wird eine ID des angelegten Snapshots zurückgeliefert, die auch in der Liste des Database Studios wieder auftaucht. dbmcli –U c db_execute DROP SNAPSHOT dbmcli –U c db_execute RESTORE SNAPSHOT

© SAP AG

ADM515

5-25

MaxDB Snapshot – Management

© SAP 2008 / Page 1

„

Wiederherstellen (Revert to…) und Löschen eines MaxDB-internen Snapshots

© SAP AG

ADM515

5-26

MaxDB Snapshots: Master – Slave mit Snapshots Master Stand

: : DATA : :

01.01.2009

Stand 07.01.2009

Slave vollständig

Complete

CreateDATA Snapshot

:

Restore Snapshot Inkrementell

Incremental

: : : :

14.01.2009

DATA

Stand 07.01.2009

:

DATA :

DATA

Stand

Stand 01.01.2009

: Restore Snapshot Inkrementell

Incremental

seit letzter vollständiger Sicherung

Stand 14.01.2009

DATA

© SAP 2008 / Page 1

MaxDB bietet die Möglichkeit der Verwendung von Snapshots zur Synchronisation zwischen einer Master- und einer oder mehreren Slave-Instanzen. „ Erstellen Sie die Slave-Instanz als homogene Systemkopie mit Hilfe von Backup/Restore. Erzeugen Sie vor dem ersten Restart der Slave-Instanz einen Snapshot. „ Um Änderungen in der Master-Instanz in die Slave-Instanz zu überführen, setzen Sie die SlaveInstanz auf den Snapshot zurück. Spielen Sie dann eine inkrementelle Sicherung aus der MasterInstanz ein. Sie können die Slave-Instanz beliebig oft auf den Snapshot zurücksetzen und inkrementelle Sicherungen aus der Master-Instanz einspielen. „ Dieses Verfahren funktioniert so lange, bis im Master eine komplette Datensicherung erstellt wird. Dann passen neue inkrementelle Sicherungen nicht mehr zum Snapshot in der Slave-Instanz. Zur Synchronisation mit dem Master kann eine komplette Datensicherung in der Slave-Instanz eingespielt werden. „

© SAP AG

ADM515

5-27

Sicherungen: Übersichtsdiagramm

Datenbanksicherung und -wiederherstellung Thema 1: Vollständige Datensicherung Thema 2: Inkrementelle Datensicherungen Thema 3: MaxDB Snapshots Thema 4: Log-Sicherungen Thema 5: Automatische Log-Sicherung Thema 6: Überprüfen der Sicherungen Thema 7: Sicherungsstrategie Thema 8: Externe Sicherungstools

© SAP 2008 / Page 1

© SAP AG

ADM515

5-28

Log-Sicherung

Option 1

Option 2 LOGSAVE.001 LOGSAVE.002 LOGSAVE.003

LOGSAVE.001 LOGSAVE.002 LOGSAVE.003

abgeschlossenes Log-Region aktive Log-Region

Log Volume

Restbelegung im Log Volume

gesicherte Log-Region

Restbelegung im Log Volume

interaktiv oder skriptgesteuert

automatisch

© SAP 2008

Unter Kontextmenü der Instanz Backup… → Log Backup können Sie eine Log-Sicherung starten, die den gesamten noch nicht gesicherten Inhalt des Log-Bereichs auf ein anzugebendes Sicherungsmedium speichert. Anschließend wird der Inhalt des Log-Bereichs zum Überschreiben freigegeben. Es ist wichtig zu wissen, dass die Log-Einträge dabei nicht aktiv gelöscht, sondern nur zum Überschreiben freigegeben werden. y Die Log-Sicherung erfolgt in Teilstücken, deren Größe durch den Parameter AutoLogBackupSize (Angabe in Seiten) bestimmt ist. Standardmäßig wird der Parameter AutoLogBackupSize zum Installationzeitpunkt anhand der vorhandenen Log-Volumes berechnet und auf ein Drittel des gesamten Log-Bereichs als Parameterwert voreingestellt. „ Durch Aktivieren der automatischen Log-Sicherung werden abgeschlossene Log-Bereiche automatisch auf dafür ausgewählte Sicherungsmedien gesichert. y Es wird empfohlen, für die automatische Log-Sicherung einen eigenen Festplattenbereich zu benutzen. Als Sicherungsmedium können derzeit nur Dateien (Device Type: File) verwendet werden. Bitte schauen Sie nach der dbmcli-Kommandobeschreibung für das archive_stage später in diesem Kapitel, wie diese Dateien automatisch versorgt werden können. y Während einer Datensicherung oder während eines Verify muss die automatische LogSicherung nicht ausgeschaltet werden. Der Datenbankkern übernimmt die Überwachung der abgeschlossenen Log-Bereiche. y Wenn Sie trotz der automatischen Log-Sicherung eine interaktive Log-Sicherung durchführen wollen, müssen Sie die automatische Log-Sicherung erst deaktivieren und nach der erfolgten interaktiven Log-Sicherung wieder aktivieren. „

© SAP AG

ADM515

5-29

Interaktive Log-Sicherung (1)

LOG_00001

Labels:

DATA 1

LOGSAVE.001

DATA 2

LOGSAVE.002

LOG_00001

LOGSAVE.003

DataVolumes

DATA n

LogVolumes

LOG 1 LOG 2 © SAP 2008

„ „

„

„ „

Interaktive Log-Sicherungen sichern alle belegten Log-Seiten aus dem Log-Volume, die noch nicht gesichert wurden und nicht zu einer offenen Transaktion (ohne COMMIT) gehören. Nur Versionsdateien (Version Files) und externe Sicherungswerkzeuge mit Rückmeldungsfunktion werden als Sicherungsmedium für die interaktive Log-Sicherung akzeptiert. Die Log-Sicherungen sollten daher anschließend endgültig auf anderen Sicherungsmedien gespeichert werden. An den Dateinamen, der in dem Sicherungsmedium definiert ist, wird automatisch eine Versionsnummer angefügt (drei Stellen mit führenden Nullen). Wenn der Nummernvorrat erschöpft ist, werden weitere Stellen angefügt. Die Label der Log-Sicherungen werden unabhängig von der Nummerierung der vollständigen und inkrementellen Datensicherungen vergeben. Alle Log-Sicherungen werden zusammen mit den Datensicherungen in der Sicherungshistorie in umgekehrt zeitlicher und logischer Reihenfolge aufgelistet.

© SAP AG

ADM515

5-30

Interaktive Log-Sicherung (2)

© SAP 2008 / Page 1

Unter Backup… können Sie eine interaktive Log-Sicherung starten. „ Wie üblich wird zur Erstellung einer Log-Sicherung eine initiale Vollsicherung der Daten für eine folgende Log-Sicherung benötigt. Log-Sicherung sind hier Delta-Sicherungen, die einen Startpunkt benötigen. Wenn diese Vorraussetzung nicht erfüllt ist, wird die Option Log Backup ausgeblendet. „ Wählen Sie anschließend Next Step. „

© SAP AG

ADM515

5-31

Interaktive Log-Sicherung (3)

© SAP 2008 / Page 1

Wie bei der Datensicherung muss auch hier zuerst ein entsprechendes Sicherungsmedium angelegt oder ein bestehendes Sicherungsmedium ausgewählt werden. „ Sollte die automatische Log-Sicherung aktiv sein, müssen Sie diesen Modus vor dem Start der interaktiven Log-Sicherung ausschalten und anschließend wieder aktivieren. „

© SAP AG

ADM515

5-32

Interaktive Log-Sicherung (4)

© SAP 2008

„ „ „ „

„

Es erfolgt eine Zusammenfassung der Einstellung vor dem Start der Log-Sicherung. Nach erfolgter Log-Sicherung wird das Label der Sicherung angezeigt. Dauert die Log-Sicherung sehr lange können Sie auch hier den Wizard in den Hintergrund legen und über den Reiter Actions wieder erreichen. Wenn Sie die interaktive Log-Sicherung wegen einer LOG FULL-Situation starten, dann werden die mit der Datenbank arbeitenden Programme so lange gestoppt, bis die Datenbank ihre Transaktionen fortsetzen kann. Diese Programme werden nach Abschluss der Log-Sicherung automatisch wieder aktiv, falls sie nicht manuell gestoppt oder Timeout-Werte der Applikation überschritten wurden. Wenn Sie bei einer LOG FULL-Situation dagegen nicht eine interaktive Log-Sicherung durchführen, sondern gleich die automatische Log-Sicherung wieder aktivieren, dann werden die gestoppten Transaktionen direkt nach dem Sichern des ersten Log-Bereichs (per Default ein Drittel des gesamten Log-Bereichs) wieder aktiv, während die anderen Log-Bereiche noch gesichert werden.

© SAP AG

ADM515

5-33

Sicherungen: Übersichtsdiagramm

Datenbanksicherung und -wiederherstellung Thema 1: Vollständige Datensicherung Thema 2: Inkrementelle Datensicherungen Thema 3: MaxDB Snapshots Thema 4: Log-Sicherungen Thema 5: Automatische Log-Sicherung Thema 6: Überprüfen der Sicherungen Thema 7: Sicherungsstrategie Thema 8: Externe Sicherungstools

© SAP 2008 / Page 1

© SAP AG

ADM515

5-34

Automatische Log-Sicherung

Log-Volumes

Log-Zyklus, durch Downcounter eingeteilt

Log – Volume 1

Log – Volume 2

e en s os hl ion c s g ge Re ab ogL

Log-Sicherungen (Versionsdateien)

AULOG_001 AULOG_002 AULOG_003 AULOG_004 Labels LOG_00001 LOG_00002

LOG_00003 LOG_00004

Letzte Log-Sicherung Wenn die automatische Log-Sicherung aktiviert ist, sichert die Datenbankinstanz Log-Informationen automatisch, so bald ein vordefiniertes Log-Aufkommen erzeugt wurde Die Größe wird durch den MaxDB-Parameter AutoLogBackupSize bestimmt Zusätzlich kann eine zeitbasierte Steuerung aktiviert werden SAP empfiehlt, diesen Automatismus immer zu nutzen, um LOG FULL-Situationen zu vermeiden © SAP 2008

Um die Datenbank vor LOG FULL-Situationen zu bewahren, sollte die automatische Log-Sicherung aktiviert werden. „ Immer, wenn so viele Log-Einträge aufgetreten sind, daß die Größe AutoLogBackupSize erreicht ist, werden diese Daten auf dem definierten Sicherungstemplate gesichert und der Log-Bereich wird wieder zum Überschreiben freigegeben. Der Log-Bereich wird nicht durch Überschreiben mit Leerdaten gelöscht. y Jeder Log-Bereich wird in eine eigene Sicherungsdatei abgelegt, die eine Versionsnummer erhält. y Automatische Log-Sicherungen sind nur auf Sicherungsdateien möglich. Diese sollten dann wiederum mit den entsprechenden Tools auf Bänder oder Sicherungs-Server gesichert werden. y Die automatische Log-Sicherung kann auch neben skriptgesteuerten Log-Sicherungen als Auffangnetz genutzt werden, falls das Skript versagt. y Während jeder Durchführung einer skriptgesteuerten Log-Sicherung muss die automatische Log-Sicherung deaktiviert werden (z.B. mit dem Kommando dbmcli –U c autolog_off). „ Die automatische Log-Sicherung ist um so wichtiger, je länger Datensicherungsaktionen unter Verwendung der Utility-Task dauern, da während dieser Zeit die Utility-Task nicht anderweitig genutzt werden kann und daher auch keine interaktive Log-Sicherung gestartet werden kann. Zum Beispiel: Wenn Datensicherungen im Online-Betrieb aufgrund langsamer Sicherungsmedien sehr lange laufen, kann es während dieser Sicherung durch Online-Aktivitäten passieren, dass der LogBereich zu 100 Prozent gefüllt wird. Mit eingeschalteter automatischer Log-Sicherung kann trotz der belegten Utility-Task der Log-Bereich gesichert werden und es kommt nicht zur LOG_FULL Situation. „

© SAP AG

ADM515

5-35

Aktivieren der automatischen Log-Sicherung

© SAP 2008

Um die automatische Log-Sicherung zu aktivieren, legen Sie ein entsprechendes Sicherungsmedium mit dem Backup Type Log an. Schalten Sie die automatische Log-Sicherung dann ein, indem Sie AutoLog ON wählen. „ Wie üblich benötigen Sie für das Aktivieren der automatischen Log-Sicherung eine initiale Datensicherung. Anderenfalls wird die Option im Wizard nicht angeboten. „ Die automatische Log-Sicherung ist so lange aktiv, bis sie manuell abgeschaltet wird oder ein Fehler beim Sichern auftritt. „ Den Status der automatischen Log-Sicherung erkennen Sie zum Beispiel unter Reiter Log Area der registrierten Datenbankinstanzen. „

© SAP AG

ADM515

5-36

Aktivieren der automatischen Log-Sicherung

© SAP 2008 / Page 1

Das Database Studio bietet auch die Option, die automatische Log-Sicherung zeitgesteuert zu starten. „ Um das Sicherungsinterval zu setzen, können Sie aber auch die dbmcli-Kommandos autolog_on oder medium_put nutzen: y Kommando-Überblick autolog_on ... [INTERVAL ] medium_put ... (ab MaxDB Version 7.7.02) y Kommadosyntax (ab MaxDB Version 7.7.02) medium_put <size> „

Der Default-Wert für den Parameter ist 0, was bedeutet, daß kein Instervall genutzt werden soll. „ Der Intervall-Wert des Sicherungs-Template (Sicherungsmedium) kann übersteuert werden wenn die Funktion der automatischen Log-Sicherung aktiviert wird: autolog_on [<medium>] [INTERVAL ] „

© SAP AG

ADM515

5-37

Aktivieren der automatischen Log-Sicherung

© SAP 2008 / Page 1

„

Eine typische Abfolge von Sicherungen im Database Studio mit dem Fokus auf die letzte LogSicherung und den dazugehörenden Details.

© SAP AG

ADM515

5-38

Sicherungen: Übersichtsdiagramm

Datenbanksicherung und -wiederherstellung Thema 1: Vollständige Datensicherung Thema 2: Inkrementelle Datensicherungen Thema 3: MaxDB Snapshots Thema 4: Log-Sicherungen Thema 5: Automatische Log-Sicherung Thema 6: Überprüfen der Sicherungen Thema 7: Sicherungsstrategie Thema 8: Externe Sicherungstools

© SAP 2008 / Page 1

© SAP AG

ADM515

5-39

Überprüfen der Sicherungen

Aufruf z.B. über das Database Studio: „

Kontextmenü der Datenbankinstanz → Check Backup…

„

Kontextmenü der Sicherung in der Sicherungshistorie → Check Backup

„

Kontextmenü des Sicherungstemplates → Check Backup

Prüfen mit Hilfe einer Servicedatenbank „

Daten werden nicht auf die Platten geschrieben

„

Servicedatenbank belegt keinen Plattenplatz

„

Prüfen von parallelen Sicherungen möglich

Überprüfung der Sicherung auf Vollständigkeit Das erfolgreiche (richtige) Lesen der Sicherungsinhalte (Page Header) „ Es wird keine Überprüfung der Dateninhalte vorgenommen „ „

© SAP 2008 / Page 1

Bevor die Sicherungen einer Sicherungsgeneration überschrieben werden, sollte überprüft werden, ob eine intakte Sicherung vorhanden ist. „ Die Überprüfung einer Datensicherung kann auch über das folgende Kommando erfolgen: dbmcli –U c -uSRV recover_check <Medienname> DATA „

© SAP AG

ADM515

5-40

Sicherung prüfen

© SAP 2008

Im Database Studio können Sie Sicherungen im Kontextmenü der Instanz unter Check Backup... und dem daraufhin erscheinenden Backup Check Wizard prüfen. „ Sie können sowohl Log- als auch Datensicherungen überprüfen. „ Wählen Sie das entsprechende Sicherungsmedium, und wählen Sie Next Step. „ Hinweis: Diese Funktion ist im Database Studio 7.8.00.06 noch nicht implementiert. „

© SAP AG

ADM515

5-41

Sicherung prüfen – Sicherung aus Historie

© SAP 2008

Drei Optionen der Analyse von Backups werden angeboten: y Überprüfen des letzten Sicherungssatzes bestehend aus evt. Daten- und/oder Log-Sicherung y Überprüfen eines bestimmten Sicherungstandes y Überprüfen eines einzelnen Mediums oder Mediumgruppe „ Hier wird die Option gezeigt, einen bestimmten Sicherungsstand zu testen. „ Bitte Legen oder Selektieren Sie ein zu überprüfendes Medium an. „ Um die Überprüfung zu starten, wählen Sie Start. „

© SAP AG

ADM515

5-42

Sicherung prüfen – ein spezielles Medium

© SAP 2008 / Page 1

Die Ausführung der Option Check Backup… für ein Template wird hier gezeigt. „ Nachdem die Überprüfung der Sicherung abgeschlossen ist, wird das Ergebnis angezeigt. „

© SAP AG

ADM515

5-43

Sicherungen: Übersichtsdiagramm

Datenbanksicherung und -wiederherstellung Thema 1: Vollständige Datensicherung Thema 2: Inkrementelle Datensicherungen Thema 3: MaxDB Snapshots Thema 4: Log-Sicherungen Thema 5: Automatische Log-Sicherung Thema 6: Überprüfen der Sicherungen

Thema 7: Sicherungsstrategie Thema 8: Externe Sicherungstools

© SAP 2008 / Page 1

© SAP AG

ADM515

5-44

Sicherungsstrategien

Data backup (complete)

Automatic log backup Data backup (incremental)

Check data (Verify) Check data backup

28 days online

Data backup (complete)

© SAP 2008

Zur Gewährleistung der Datensicherheit ist es erforderlich, Daten- und Log-Sicherungen in sinnvoll gewählten Abständen durchzuführen. SAP empfiehlt: y vollständige Datensicherung (Data) mindestens einmal pro Woche oder, wenn möglich, täglich y inkrementelle Datensicherung (Pages) nach gößeren Systemaktivitäten innerhalb der Woche y Log-Sicherungen mindestens einmal täglich optimalerweise durch die Funktion der automatischen Log-Sicherung. „ In einem 28-Tage-Zyklus werden so vier Sicherungsgenerationen erzeugt. Dann können die Sicherungsmedien wiederverwendet werden. y Vor Wiederverwendung von Sicherungsmedien soll zumindestens einmal innerhalb des Sicherungszyklus eine Konsistenzprüfung Check Data (VERIFY) der Datenbank erfolgen (Kapitel 5). Damit wird sichergestellt, dass sich die Datenbank in einem physikalisch konsistenten Zustand befindet und Sie es sich erlauben können, diese Bänder zu überschreiben. y Zu Beginn eines Sicherungszykluses sollte auch die Lesbarkeit der vollständigen Datensicherungen überprüft werden (siehe: Sicherungen prüfen) um sicher zu gehen, daß das Sicherungskonzept erwartungsgemäß funktioniert. y Sollten Snapshots des Filesystems als Ersatz für datenbankeigene Sicherung genutzt werden, muß der konsistente Zustand des Systems mit dem Check Data häufiger geprüft werden. Dies sollte dann mindestens einmal in der Woche passieren, entsprechend der Vollsicherung im obigen Beispiel einmal die Woche. „

© SAP AG

ADM515

5-45

Wochenplaner für Sicherungen – DBA-Cockpit

© SAP 2008 / Page 1

Das Computing Center Management System (CCMS) bietet Ihnen mit dem DBA-Cockpit und dem darin verankerten DBA-Planungskalender die komfortable Möglichkeit, die wichtigsten Verwaltungsaufgaben einzuplanen. y Die eingeplanten Aktionen laufen, vom SAP Netweaver gesteuert, automatisiert ab. Der Systemadministrator hat die Aufgabe, die richtigen Sicherungsmedien zur Verfügung zu stellen. y Den Erfolg der eingeplanten Aktionen können Sie direkt im DBA-Cockpit überprüfen. y Sie können Aktionen in einem ein- oder mehrwöchigen Rhythmus einplanen und so die Sicherungsstrategie Ihrer Wahl implementieren. „ Der Planungskalender greift auf dieselben Informationen zu wie das Database Studio. y Er zeigt die Sicherungsmedien an, die Sie mit dem Database Studio definiert haben. y Die Sicherungshistorie können Sie in den DBA-Aktionsprotokollen einsehen (Transaktion DB12). „ Zusätzlich zu Sicherungsaktionen können Sie mit Hilfe des Planungskalenders auch die Optimiererstatistiken erneuern. Dies wird im Kapitel Problemsituationen und Performance Tuning behandelt. „ Wichtig: Planungseinträge übernehmen den momentanen Zustand der Datenbankumgebung. Wenn nach Umschaltvorgängen in ausfallsicheren Systemlandschaften Aktionen nicht mehr auf dem ursprünglichen Datenbankrechner durchgeführt werden, kann dies zu Fehlern führen. Bei vielen datenbankbezogenen Einplanungen wird der aktuelle Datenbankrechner ermittelt und diese Information in die Planung mit eingetragen. Nach einem Ausfall des Datenbankrechners kann das CCMS nicht mehr auf diesen zugreifen. Planen Sie in diesem Fall die Aktionen neu ein und schalten Sie auf den Normalzustand der Systemlandschaft zurück. Es kann nicht unbedingt sichergestellt werden, dass auf dem zweiten Rechner die gleichen Sicherungsmedien definiert sind. „

© SAP AG

ADM515

5-46

Sicherungen: Übersichtsdiagramm

Datenbanksicherung und -wiederherstellung Thema 1: Vollständige Datensicherung Thema 2: Inkrementelle Datensicherungen Thema 3: MaxDB Snapshots Thema 4: Log-Sicherungen Thema 5: Automatische Log-Sicherung Thema 6: Überprüfen der Sicherungen

Thema 7: Sicherungsstrategie Thema 8: Externe Sicherungstools

© SAP 2008 / Page 1

„

Siehe auch SAP Hinweis 822240 (FAQ: MaxDB und der Einsatz von externen Sicherungswerkzeugen)

© SAP AG

ADM515

5-47

Sicherung mit externen Werkzeugen Database Manager CLI

Database Studio

Datenbankrechner Medium

DBM-Server Ext. Sicherungshistorie

Sicherungshistorie

Backup-Server

MaxDBKern Pipes Pipes

DATA

Sicherungswerkzeug (Client)

Sicherungswerkzeug (Server)

Hauptdatenfluss Kontroll- und Kommandodaten

Bänder

© SAP 2008

„ „ „ „ „ „ „

„

Die Anbindung externer Sicherungswerkzeuge ist im DBM-Server implementiert. Der DBM-Server setzt das Sicherungskommando an den Datenbankkern ab. Dieser erzeugt und öffnet ein oder mehrere Pipes sequentiell. Der DBM-Server startet den Backup-Client des Sicherungswerkzeugs, sobald der Datenbankkern die erste Pipe öffnet. Das Sicherungswerkzeug öffnet die Pipes, überträgt die Daten zum Backup-Server und speichert sie auf Band. Der Datenbankkern vermerkt das Ergebnis der Sicherung in der Sicherungshistorie. Der DBM-Server befragt ggf. das Sicherungswerkzeug nach den eindeutigen Sicherungs-IDs (External Backup ID) und trägt diese in die External Backup History (dbm.ebf) ein. Damit ist es möglich, die von Datenbankkern erzeugten Backup-IDs mit der Sicherungskennung des externen Sicherungswerkzeugs in Verbindung zu bringen. Protokolliert wird die Sicherung im External Backup Protocol (dbm.ebp) bzw. der langen Version (dbm.ebl): y wird bei jeder Aktion mit einem direkt unterstützten Sicherungswerkzeug geschrieben y Die Datei dbm.ebp wird nach jedem Start des DBM-Server überschrieben y lässt sich im Database Studio anzeigen (DB-Instanz → Control → Diagnosis Files) y Inhalt: Konfigurationsangaben Datenbankkernkommandos Aufrufe des Sicherungswerkzeugs Ergebnisse von Sicherungswerkzeug und Datenbank Ausgaben des Sicherungswerkzeugs

© SAP AG

ADM515

5-48

Externe Sicherungs-ID Database Manager CLI

Database Studio

Datenbankrechner DBM-Server Ext. Sicherungshistorie

Sicherungshistorie

MaxDBKern

Backupserver Sicherungswerkzeug (Client)

Sicherungswerkzeug (Server)

DATA Bänder © SAP 2008

In neueren Versionen des Database Studio werden in der Sicherungshistorie unter Details neben den Medieninformationen ggf. auch Informationen über External Backup IDs der Sicherung angezeigt. „ Zur Ermittlung der Daten wird der Datenbankkern nicht benötigt. „ Diese Informationen können Sie auch mit dem Database Manager CLI erhalten (siehe Hinweis 387583). „

© SAP AG

ADM515

5-49

Konzept der Sicherung mit Backupmedien

DBMSRV (Management inkl. techn. Wissen über Sicherungstools usw.)

SicherungsServer

DatenbankServer

Datenbank Management

Log medium Data medium

Pipes

Kernel

Clienttool der SicherungsServer Software

Netzwerk

Ext. Sicherungstool

Autolog medium

DATA

File.3 File.3 File.3 LOG Log Staging

Backuptools, die Pipes unterstützen: • Networker (Legato) • ADSM/Tivoli (IBM) (ADINT2) • Data Protector ≥ 5.5 (HP)

© SAP 2008

Hier wird das Funktionsprinzip der Backupmedien gezeigt und erläutert, warum das AutoLog nur auf den Log Staging Bereich schreiben kann: Das Knowhow, auf andere Backuptools zuzugreifen, ist auf dieser Ebene des Datenbankkerns nicht realisiert. Dieses ist stattdessen im DBMServer vorhanden. „ Da das AutoLog aber parallel zu Daten- und manuellen Log-Sicherungen arbeiten muß und die Funktionalität nicht im Datenbankkern ein weiteres Mal implementiert werden sollte, kann der Datenbankkern hier nur auf Plattenbereiche schreiben. „

„

Zuletzt hat HP das Tool Data Protector ab 5.5 um die Funktion von Pipes erweitert. Mehr dazu finden Sie unter www.openview.hp.com/products/storage_data_protector/device_matrices/Platform_Integrtn_SptMt x_DP55.pdf Der Kommentar auf Seite 6: (Online integration based on ‘Backint for SAPDB / MaxDB’) bedeutet, daß die Verwendung von Pipes nun möglich ist. Das Management erfolgt aber über das bereits übliche backint-Arrangement.

© SAP AG

ADM515

5-50

Konzept archive_stage

DBMSRV (Management inkl. techn. Wissen über Sicherungstools usw.)

SicherungsServer

DatenbankServer

Datenbank Management

Log medium Data medium

Pipe

Kernel

Clienttool der SicherungsServer Software

Netzwerk

Ext. Sicherungstool

Autolog medium

archive_stage

DATA

File.3 File.3 File.3 LOG Log Staging

Backuptools, die Pipes unterstützen: • Networker (Legato) • ADSM/Tivoli (IBM) (ADINT2) • Data Protector ≥ 5.5 (HP)

© SAP 2008

„ „ „

„ „

Nachdem die AutoLog-Sicherungen stattfanden und diese Sicherungen im Log Staging-Bereich stehen, muß eine Nachbehandlung bzw. Weiterverarbeitung dieser Dateien erfolgen. In früheren Versionen der Datenbank mussten Administratoren eigene Scripte/Konzepte erstellen um diese zu bewerkstelligen. Aber die Implementierung des dbmcli-Kommandos archive_stage bietet nun eine einfache Lösung und überlässt dem DBMserver die Aufgabe, die Verionsdateien des AutoLog an die externe Sicherungslösung zu schicken. Der DBMserver weiß zu jeder Zeit, welche der Dateien beschrieben wird und welche zur Weiterverarbeitung bereit sind. Daher nimmt der DBMserver die fertigen Dateien aus dem Log Staging-Bereich und schickt sie über ein existierendes Log-Sicherungsmedium an die externe Sicherungslösung. Derzeit werden nur externe Sicherungslösungen aber keine lokalen Bandstationen unterstützt, auch wenn diese Unterstützung auf der Agenda steht.

© SAP AG

ADM515

5-51

Konzept des „backint for Oracle“ mit MaxDB

Datenbank

Backint control files *.in / *.out / *.err

Management

Log medium Data medium

Kernel

MaxDB Adapterprogramm: backint

Autolog medium

DATA

File.3 File.3 File.3

File.3 File.3 File.3

LOG Log Staging

Sicherungsserver

DatenbankServer Backint-Adapter des Clienttools

DBMSRV (Management inkl. techn. Wissen über Sicherungstools usw.)

Backint Staging

Clienttool der Sicherungs- Netzwerk Server Software

Ext. Sicherungstool

Backuptools, die keine Pipes unterstützen: • ARCserv • ADSM/Tivoli (IBM) (ADINT) • DataProtector < 5.5 (HP)

© SAP 2008

„

„

„ „

„

Wenn die vorhandene externe Sicherungslösung die Verwendung von Pipes nicht unterstützt, wird hier ein alternatives Konzept dargestellt. MaxDB muß hier auf die beschränkte Funktionalität des „Backint for Oracle“ zurückfallen, da dieser Standard nur für Dateien (und RAW-Devices) definiert ist. Auch hier schreibt der Datenbankkern weiterhin auf Pipe-Devices, aber diese Daten werden von einem MaxDB-Adapterprogramm (ebenfalls mit dem Namen backint) übernommen und die damit übermittelten Daten aus der Pipe in Dateien zerhackt. Diese Dateien definierter Größe werden dann im Backint Staging-Bereich abgelegt und der Lageort und Dateiname an das externe Sicherungstool zur Weiterverarbeitung übermittelt. Dies stellt den Übergabepunkt dar. Wie bereits vorher kann auch hier das AutoLog unabhängig aktiv werden um LOG FULLSituationen zu vermeiden. Aber auch hier kann es generell keine Pipes verwenden. Meist wird auch auf Seiten der externen Sicherungslösung ein Adapterprogramm für die Behandlung des Backint for Oracle und der damit definierten Schnittstellenkommunikation notwendig. Da diese Adapterprogramme auch meist backint heißen, verwechseln Sie diese bei der Implementierung der Anbindung bitte nicht mit dem MaxDB-Adapterprogramm backint. Auch in diesem Arrangement ist es möglich die Funktion archive_stage zu verwenden, damit der DBMserver die Versionsdateien des AutoLog aus dem Log Staging-Bereich an die externe Sicherungslösung übermittelt. Die Versionsdateien nehmen dann den gleichen Weg der Datensicherungen über den Backint Staging Bereich.

© SAP AG

ADM515

5-52

Konzept archive_stage mit „backint for Oracle“ Datenbank

Backint control files *.in / *.out / *.err

Management

Log medium Data medium

Kernel

MaxDB Adapterprogramm: backint

Autolog medium

DATA

File.3 File.3 File.3

File.3 File.3 File.3

LOG Log Staging

SicherungsServer

DatenbankServer Backint-Adapter des Clienttools

DBMSRV (Management inkl. techn. Wissen über Sicherungstools usw.)

Backint Staging

Clienttool der Sicherungs- Netzwerk Server Software

Ext. Sicherungstool

Backuptools, die keine Pipes unterstützen: • DataProtector (HP) • ADSM/Tivoli (IBM) (ADINT) • ARCserv

© SAP 2008 / Page 1

„

Auch in diesem Arrangement ist es möglich die Funktion archive_stage zu verwenden, damit der DBMserver die Versionsdateien des AutoLog aus dem Log Staging-Bereich an die externe Sicherungslösung übermittelt. Die Versionsdateien nehmen dann den gleichen Weg der Datensicherungen über den Backint Staging Bereich.

© SAP AG

ADM515

5-53

Konzept des „backint for MaxDB“

Datenbank

Backint control files *.in / *.out / *.err

Management

Log medium Data medium

Pipe

Kernel Autolog

DATA

medium

SicherungsServer

DatenbankServer Backint-Adapter des Clienttools

DBMSRV (Management inkl. techn. Wissen über Sicherungstools usw.)

Clienttool der Sicherungs- Netzwerk Server Software

Ext. Sicherungstool

Sicherungstools, die Pipes im Rahmen von BACKINT (Backint for MaxDB) unterstützen:

File.3 File.3 File.3 LOG

•Comvault QiNetix 6.1 •DataProtector >= 5.5 (HP)

Log Staging © SAP 2008

© SAP AG

ADM515

5-54

Konzept archive_stage mit „backint for MaxDB“ Datenbank

Backint control files *.in / *.out / *.err

Management

Log medium Data medium

Pipe

Kernel Autolog medium

DATA

DatenbankServer Backint-Adapter des Clienttools

DBMSRV (Management inkl. techn. Wissen über Sicherungstools usw.)

Clienttool der SicherungsServer Software

SicherungsServer

Network

Ext. Sicherungstool

Sicherungstools, die Pipes im Rahmen von BACKINT (Backint for MaxDB) unterstützen :

File.3 File.3 File.3 LOG

• Comvault QiNetix 6.1 • DataProtector >= 5.5 (HP)

Log Staging © SAP 2008

© SAP AG

ADM515

5-55

Syntax des archive_stage

Syntax: archive_stage <medium> <stage> [VERIFY|NOVERIFY] [REMOVE|KEEP] [FileNumberList|FNL <list>] Parameter: <medium> <stage> VERIFY

Zielmedium, auf das die existierenden Versionsdateien geschrieben werden sollen Medium, das beim AutoLog genutzt wird gesicherte Logsicherungen werden verifiziert (default)

NOVERIFY

gesicherte Logsicherungen werden nicht verifiziert

REMOVE

gesicherte Logsicherungen werden nach erfolgreicher Sicherung gelöscht (default)

KEEP

gesicherte Dateien werden nicht gelöscht

<list>

Kommaseparierte Liste der Versiondateien, die bearbeitet werden sollen.

Beispiel: dbmcli –U c archive_stage BACKLog AutoLog NOVERIFY KEEP FNL 1,002,3-10

© SAP 2008

Die Syntax des archive_stage ist hier erläutert: Sehr empfehlenswert ist hier die Option VERIFY, die es erlaubt, nach Abschluß des Transfers der Versionsdateien an die externe Sicherungslösung, diese wieder zurückzuholen und den Datenstrom dann mit der Originaldatei zu vergleichen. Mit dieser Funktion testen Sie immerwährend die sichere Funktion der externen Sicherungslösung. „ Das dbmcli-Kommando mit dem archive_stage sollte mit cron, at oder einem zentralen Planungskalender eingeplant werden. Dieses kann auch aus der Ferne über die Remote-Fähigheiten des dbmcli erfolgen. „

© SAP AG

ADM515

5-56

Syntax des archive_stage_repeat

Syntax: archive_stage_repeat <medium> [VERIFY|NOVERIFY] [REMOVE|KEEP] Parameters: <medium>

Zielmedium, auf das die existierenden Versionsdateien geschrieben werden sollen

VERIFY

gesicherte Logsicherungen werden verifiziert (default)

NOVERIFY REMOVE

gesicherte Logsicherungen werden nicht verifiziert gesicherte Logsicherungen werden nach erfolgreicher Sicherung gelöscht (default)

KEEP

gesicherte Dateien werden nicht gelöscht

Example: dbmcli –U c archive_stage BACKLog AutoLog NOVERIFY KEEP FNL 1,002,3-10 archive_stage_repeat BACKLog VERIFY REMOVE Einschränkung: „

Damit archive_stage_repeat arbeiten kann, muß das Kommando zusammen mit dem archive_stage in der gleichen DBMSRV Session abgesetzt werden. Ansonsten sind die zu vererbenden Daten verloren.

© SAP 2008

Mit archive_stage_repeat bietet die MaxDB die Möglichkeit Versionsdateien mehrfach an die externe Sicherungslösung zu schicken. Damit ist es etwa möglich, die Dateien auf unterschiedliche Bänder oder Bandlaufwerke zu schicken. „ Die einzige Einschränkung dabei ist derzeit, daß das archive_stage_repeat in der gleichen DBMserver-Session wie das archive_stage zuvor ausgeführt werden muß. „

© SAP AG

ADM515

5-57

Externe Snapshots in Sicherungshistorie

Die MaxDB erlaubt erst dann eine Logsicherung, wenn nach einem Bruch in der LogHistorie eine komplette Sicherung des Datenbereichs erstellt wurde. Diese Sicherung dient als Wiederaufsetzpunkt für ein Recovery. Bei Verwendung von Split Mirror oder Snapshot Clones hat die Datenbank kein Wissen über eine existierende Sicherung. Ab MaxDB 7.7.06.07 können Sie der Datenbank mittteilen, dass eine vollständige Sicherung des Datenbereichs vorliegt. Dazu gibt es nun die Option, mit einem Datenbankkommando, dieses HISTLOST zu entfernen bzw. umzuwandeln. Hier vertraut MaxDB der Kompetenz des Datenbankadministrators und erwartet eine Sicherung auf Storagesystemebene wie zum Beispiel Filesystem-Snapshots. Der Eintrag HISTLOST wird ausgetauscht mit der Information über den externen Snapshot Anschließend ist es möglich, die automatische Log-Sicherung zu aktivieren.

© SAP 2008

„

Bis MaxDB 7.7 kommt es nach Konfigurationsänderungen in der Datenbank in bestimmten Fällen zu Eintragungen in der Form eines Eintrages HISTLOST in die Sicherungshistorie (siehe auch Kapitel 2 bzw. 4). Anschließend muß eine neue Sicherungshistorie mit einer initialen Datensicherung begonnen werden. Erst nach erfolgreicher Datensicherung ist es dann möglich, die automatische Log-Sicherung zu aktivieren.

„

Um der Datenbank mitzuteilen, dass eine vollständige Datensicherung vorliegt gehen Sie wie folgt vor ( siehe Hinweis 1285996 Backup Historie starten ohne Erstellung eines DB-Backups): y Sorgen Sie durch antriggerns eines Savepoint für ein Herausschreiben der geänderten Daten aus dem Data Cache. y Setzen Sie den Aufsetzpunkt für ein Logrecovery mit dem dbmcli-Komando: db_execute save DATA quick to ‘< Kommentartext >‘ external medianame ‘‘

- Mit dem Kommentartext ist es möglich, wichtige Informationen zu dem externen Snapshot zu protokollieren. - Die Daten können später in der Sicherungshistorie wiedergefunden werden. y Erstellen Sie den externen Snapshot „ Diese Funktion muß noch im Database Studio implementiert werden.

© SAP AG

ADM515

5-58

Sicherungslösungen und deren Unterstützung

Tool

Client Tool Name

EMC Legato Networker IBM – Tivoli Storage Manager

ADINT2

Direkter Support durch MaxDB via Pipes

Backint for MaxDB via Pipes

NSR

X

ADSM (TSM with MaxDB 7.6.0 B26 ff.) X X1 (Version ≥ 5.5)

X2 (Version ≥ 6.1)

Veritas Netbackup

BACK BACK

X

CA Brightstor ARCserv Commvault QiNetix

Backup Template Name

X

ADINT HP Data Protector

Backint for Oracle via Files

BACK BACK

X

BACK

© SAP 2008

„

Fußnoten: 1 Zertifizierung für „Backint for MaxDB“ bisher noch nicht abgeschlossen, aber die Lösung wird bereits großflächig genutzt. 2 Erstes Produkt mit abgeschlossener Zertifizierung des „Backint for MaxDB“.

„

Weitere Informationen über Technologie Partner finden Sie unter: http://www.sap.com/partners/directories (Verwenden Sie in der Suche die Kategorie: „Certification Category:Backup“)

© SAP AG

ADM515

5-59

Wiederherstellung: Übersichtsdiagramm

Wiederherstellung Thema 1: Ausgangssituation und Analyse Thema 2: Strategie Thema 3: Durchführung der Wiederherstellung Thema 4: Nutzung gespiegelter Log-Volumes Thema 5: Vorgänge in der Datenbank Thema 6: Aktionsmatrix

© SAP 2008

© SAP AG

ADM515

5-60

Wiederherstellungsfall: Ausgangssituation

LOG

vollständige Datensicherung

Log-Sicherung

DATA

AutoLog-Sicherung inkrementelle Datensicherung AutoLog-Sicherung

© SAP 2008

Bei Befolgen der Empfehlungen, die die SAP für die Plattenkonfiguration Ihrer Datenbankinstanzen sowie die Sicherungsstrategie gibt, stehen im Problemfall immer die aktuellen Log-Einträge sowie mindestens vier Sicherungsgenerationen zur Verfügung, um den Inhalt der Datenbankinstanz wiederherzustellen. Dies macht einen Datenverlust sehr unwahrscheinlich. „ Erleidet ein Data-Volume einen physischen Schaden, so wird eine vollständige Datenbankrestaurierung notwendig. Die Grundlage für eine solche Wiederherstellung sind normalerweise die vollständigen und inkrementellen Datensicherungen sowie die Log-Sicherungen der jüngsten Sicherungsgeneration. „ Tritt im SAP-System ein logischer Fehler auf, der ein Zurücksetzen des Systems auf einen älteren Zustand notwendig macht, erfolgt dieses Zurücksetzen ebenfalls durch eine Datenbankwiederherstellung mittels einer vollständigen Datensicherung und anschließendem Einspielen von inkrementellen Daten- und Log-Sicherungen. Dabei kann der Administrator bestimmen, ob bis zu einem bestimmten Zeitpunkt der Vergangenheit und damit die letzten Transaktionen ausgelassen werden, oder alle verfügbaren Log-Informationen bis zum letztmöglichen Zeitpunkt wiederhergestellt werden soll. „ Um auf einen Wiederherstellungsfall gut vorbereitet zu sein, empfehlen wir, mindestens zwei Mitarbeiter zu schulen, die eine vollständige Datenbankwiederherstellung anhand der Sicherungen des Produktivsystems in regelmäßigen Abständen testen. Für diese Tests sollten Sie über einen dem Datenbankrechner vergleichbaren Testrechner verfügen. Dies könnte beispielsweise Ihr Qualitätssicherungssystem sein. „

© SAP AG

ADM515

5-61

Diagnose im Database Studio

Laufzeitumgebung

knlMsg knlMsg.old knlMsg.err

Sicherungshistorie

dbm.knl dbm.mdf

/sapdb/data/wrk/<SID>

Aktionen der Utility-Task

dbm.utl

/sapdb/data/wrk/<SID>

Protokoll der Client-Kommandos

dbm.prt

/sapdb/data/wrk/<SID>

/sapdb/data/wrk/<SID>

© SAP 2008

„

Die folgenden Dateien enthalten Informationen zum Erkennen der Ursache von Datenbankproblemen: y Die Diagnosedatei knlMsg stellt die wichtigste Informationsquelle bei Datenbankproblemen dar. In der Datei werden die Meldungen protokolliert, die in der Kommunikation zwischen der Laufzeitumgebung der MaxDB und dem Datenbankkern auftreten. Diese Datei wird bei jedem Start des Datenbankkerns neu angelegt und die bereits vorhandene unter dem Namen knlMsg.old gesichert. Zusätzlich wird die Datei knlMsg ebenfalls nach einem Datenbankabsturz rechtzeitig gesichert, bis zwei weitere Datenbankabstürze aufgetreten sind. Die Ablage erfolgt in dem Verzeichnis, das durch den Parameter DiagnoseHistoryPath definiert ist. y Die reinen Fehlermeldungen des knlMsg werden auch in knlMsg.err protokolliert. Diese Datei wird nicht überschrieben und kann bei großem Dateiwachstum archiviert und anschliessend gelöscht werden. Sie wird dann automatisch wieder neu angelegt. y Die Dateien dbm.knl und dbm.mdf enthalten Informationen zur Sicherungshistorie und zur Verwendung von Sicherungsmedien und Labels. Anhand dieser Informationen ist die Datenbankinstanz in der Lage, Hilfestellung bei der Ausführung von Wiederherstellungsprozessen zu geben. Bei Verlust dieser Dateien müssen Sie die zur Wiederherstellung erforderlichen Aktionen selbst ermitteln. y Im Gegensatz dazu enthalten die Dateien dbm.prt und dbm.utl Informationen über die an den Datenbankrechner geschickten Kommandos (dbm.prt) bzw. die sich daraus ergebenen Aktionen, die über die Utility-Task ausgeführt werden (dbm.utl).

© SAP AG

ADM515

5-62

Wiederherstellung: Übersichtsdiagramm

Wiederherstellung Thema 1: Ausgangssituation und Analyse Thema 2: Strategie Thema 3: Durchführung der Wiederherstellung Thema 4: Nutzung gespiegelter Log-Volumes Thema 5: Vorgänge in der Datenbank Thema 6: Aktionsmatrix

© SAP 2008

© SAP AG

ADM515

5-63

Wiederherstellungsstrategie

Sicherungshistorie vollständige Datensicherung (DAT_00014) inkrementelle Datensicherung (PAG_00015)

Wiederherstellungsvorgänge

neue Platte einrichten Betriebszustand Admin DAT_00014

LOG_00020

LOG_00021 PAG_00015

LOG_00022 PAG_00016

inkrementelle Datensicherung (PAG_00016) aktuelle LogEinträge

{

LOG_00022 LOG_00023

LOG_00020 LOG_00021 LOG_00022 LOG_00023

LOG_00023 LOG_00024 Betriebszustand Online

LOG_00024 LOG_00025

© SAP 2008

„ „ „ „

„

„

„

Zur Wiederherstellung der Datenbankinstanz nach einem Struktur- oder Plattenfehler muss zunächst neuer Festplattenplatz zur Verfügung gestellt werden. Anhand der Sicherungshistorie können Sie sich einen Überblick über die notwendigen Aktionen schaffen. Die Wiederherstellung erfolgt im Betriebszustand ADMIN. Die Wiederherstellung beginnt mit dem Einlesen der neuesten vollständigen Datensicherung. Reicht die Information im Log-Bereich bis zu einem Zeitpunkt zurück, der vor dem Beginn dieser Datensicherung liegt, ist die Datenbankinstanz in der Lage, sofort nach dem erfolgreichen Einlesen mit Hilfe der Informationen aus dem Log-Bereich den aktuellsten Datenbankzustand wiederherzustellen. Anderenfalls werden die letzte inkrementelle Datensicherung und anschliessend die noch fehlenden Log-Sicherungen eingelesen. Dabei haben Sie die Möglichkeit, einen Zeitpunkt anzugeben, bis zu dem die Log-Einträge nachgefahren werden sollen. Sollte die letzte inkrementelle Datensicherung nicht zur Verfügung stehen, ist es auch möglich, als Ausweichlösung eine der letzten dieser Sicherungen zu nehmen. Entsprechend wird der Aufwand für das Nachfahren von Log größer Mit dem Starten der Datenbankinstanz in den Betriebszustand ONLINE wird die letzte LogInformation aus dem Online-Log-Volume genutzt und die Wiederherstellung abgeschlossen.

© SAP AG

ADM515

5-64

Wiederherstellung: Übersichtsdiagramm

Wiederherstellung Thema 1: Ausgangssituation und Analyse Thema 2: Strategie Thema 3: Durchführung der Wiederherstellung Thema 4: Nutzung gespiegelter Log-Volumes Thema 5: Vorgänge in der Datenbank Thema 6: Aktionsmatrix

© SAP 2008

© SAP AG

ADM515

5-65

Wiederherstellen (1)

© SAP 2008 / Page 1

„

Im Folgenden ist der Wiederherstellungsvorgang im Database Studio erläutert.

Wählen Sie im Kontextmenü zur Instanz → Recovery… und der Recovey Wizard wird erscheinen. „ Bringen Sie zunächst die Datenbankinstanz in den Betriebszustand ADMIN. „

© SAP AG

ADM515

5-66

Wiederherstellen (2)

© SAP 2008 / Page 1

„

„

„

„ „

Wählen Sie die gewünschte Wiederherstellungsoption. y Recover last backup: Setzt die Datenbank in ihren letzten Zustand vor dem Absturz zurück. y Recover specified backup from history: Setzt die Datenbank in einen bestimmten Zustand in der Vergangenheit der Sicherungshistorie zurück. y Recover a medium: Wiederherstellen ohne Sicherungshistorie, um z.B. eine Sicherung einer anderen Datenbank einzuspielen. Über die Option Initialize database before recovery kann die Datenbank und insbesondere der Log neu initialisiert werden. y Dabei werden alle Log-Informationen, die nicht bereits gesichert wurden, unwiederruflich überschrieben. Hier besteht die Gefahr des Verlusts von Transaktionsdaten. y Wenn das Log-Volume defekt ist, ist diese Option wichtig um den Log zu reparieren. Vorher sollte aber noch eine Log-Sicherung sicherheitshalber durchgeführt werden, um so viel Log wie möglich aus dem defekten Log-Volume herauszuziehen. y Bei einer Systemkopie von einer anderen Datenbank in diese Instanz ist es wichtig, diese Option zu wählen, damit das Log-Volume gelöscht wird und die alten Log-Informationen nicht mit dem unterschiedlichen Datenbestand kollidieren. Sie können hier einen Zeitpunkt in der Vergangenheit angeben, bis zu dem die Wiederherstellung durchgeführt werden soll. Dies betrifft aber nur das Nachfahren von Log-Einträgen, d.h. alle Informationen, die bereits in den Datensicherungen enthalten sind, werden komplett wiederhergestellt. Nur beim Nachfahren von Log-Einträgen aus zusätzlichen Log-Sicherungen oder dem Log-Volume kann ein Wiederherstellungszeitpunkt berücksichtigt werden. Die weiteren Schritte hängen von Ihrer Auswahl ab. In diesem Fall wählen wir die Option Recover specified backup from history. Im nächsten Schritt werden alle vollständigen Datensicherungen als Datenbasis (Startpunkt) für die Wiederherstellung aufgelistet.

© SAP AG

ADM515

5-67

Wiederherstellen (3)

© SAP 2008

„ „ „ „ „

Der Startpunkt ist mit der Vollsicherung gewählt und nun geht es um die weitere Fortführung der Wiederherstellung. Im nächsten Schritt wird nun die inkementelle Sicherung ausgewählt, soweit diese vorher überhaupt erstellt wurden. Anschließend füllt die Datenbank die eventuell bestehende transaktionale Lücke mit Log-Backups und/oder dem online Log-Volume auf. In der Summary finden Sie diese Angaben. Da das Wiederherstellen von transaktionalen Log-Informationen oft zeitaufwendig ist, empfiehlt es sich, die jüngste verfügbare inkrementelle Sicherung zu verwenden. Diese Wahl beschleunigt direkt den Wiederherstellungsprozess.

© SAP AG

ADM515

5-68

Wiederherstellen (4)

Die Sicherungs-Templates DEV_DATA und „ DEV_INC „

wurden jeweils mehrfach mit unterschiedlichen Dateinamen DATA2, DATA3 bzw. „ DEV_INC1, DEV_INC2, DEV_INC3 „

usw. verwendet. Daher keine eindeutige Zuordnung von Template zu Dateinamen Lösung: Automatismus im Database Studio um diese Zuordnung zu bereinigen Erreichbar über Resolve… jeweils für beide Templates

© SAP 2008

Unter Data Carriers werden die Sicherungdateien noch einmal im Einzelnen aufgeführt. „ Es werden ebenfalls die notwendigen Log-Sicherungen gezeigt, die die transaktionale Lücke bis zum ersten Log-Eintrag des online Log-Volume auffüllen. „ Bevor der Start-Button auftauchen kann, müssen evt. existierende Inkonsistenzen in der Sicherungshistorie noch behoben werden. y Die Bereinigung wird hier notwendig, da einmal definierte Templates auf verschiedene Dateinamen zeigen. y Die folgende Folie zeigt die Behebung des Problems über den Automatismus im Database Studio. „

© SAP AG

ADM515

5-69

Wiederherstellen (5)

© SAP 2008

Bei der Verwendung von Dateien zur Datensicherung kann es passieren, daß die Definition des Datenmediums in der Zwischenzeit mehrfach von einem Dateinamen zum nächsten geändert wurde. „ Das Database Studio erkennt dieses anhand der Informationen in der Sicherungshistorie und bietet für diesen Fall an, automatisch temporäre Mediendefinitonen zu erstellen. Sie können hier noch entscheiden, ob diese Definitionen im Anschluss bestehen bleiben oder auch wieder automatisch gelöscht werden sollen. „ Diese Entscheidung muß in diesem Fall der hier aufgebauten Sicherungshistorie sowohl für die Vollsicherung als auch die inkrementelle Sicherung getroffen werden. „

© SAP AG

ADM515

5-70

Wiederherstellen (6)

© SAP 2008

Damit erscheint der Start-Button und die Wiederherstellung kann gestartet werden. „ Nach erfolgter Wiederherstellung der Datenvollsicherung, stoppt der Prozess und Sie können die Wiederherstellung mit der inkrementellen Sicherung fortführen. „ Alternativ ist es auch möglich, die Wiederherstellung hier über den Cancel-Button zu beenden und zu einem späteren Zeitpunkt fortzuführen, wenn zwischenzeitlich die Datenbankinstanz nicht vom ADMIN in den ONLINE-Zustand gebracht wurde. y Damit ist es möglich, manuell eine Schatteninstanz aufzubauen. Mehr zu diesen Ausfallsicherheitslösungen mit MaxDB im nächsten Kapitel. „

© SAP AG

ADM515

5-71

Wiederherstellen (7)

© SAP 2008

Das gleiche Verhalten sehen wir nach erfolgter Wiederherstellung der inkrementellen Sicherung: Der Wizard stoppt und gibt die Möglichkeit den Wiederherstellungsprozess optional zu unterbrechen. „ Am Schluß wird unter Results eine Zusammenfassung des Wiederherstellungsprozess mit Rückgabewerten der verschiedenen Schritte ausgegeben. y Der Rückgabewert -8020 ist hier kein Fehler, sondern die Info, daß diese Log-Sicherung erfolgreich abgearbeitet ist und die nächste Log-Sicherung angefordert wird. „

© SAP AG

ADM515

5-72

Wiederherstellen – Indizes

© SAP 2008

Die Wiederherstellungsprozedur wird natürlich auch in der Sicherungshistorie protokolliert. Da wir hier eine Wiederherstellung auf der gleichen Datenbankinstanz durchgeführt haben, taucht kein HISTLOST auf. „ Dies wäre der Fall bei einer Wiederherstellung mit Initialisierung des Log-Volumes. „ Im Überblicksreiter Overview erkennen wir dann oft die Info, daß es sogenannte Bad Indexes gibt. y Dieses bedeutet nicht, daß die Indizes durch fehlerhafte Hardware erzeugt wurden, sondern es handelt sich um eine Besonderheit im MaxDB-Umfeld: y Um die Wiederherstellung so schnell wie möglich abzuschließen und die Datenbank produktiv zu bekommen, wird das Erstellen von sekundären Indizes beim Vorrollen von Log übersprungen. y Alle Indizes, die in den Daten-Sicherungen schon vorhanden sind, betrifft dies nicht, sondern nur die CREATE INDEX-Kommandos in den zu verarbeiteten Log-Informationen während der Wiederherstellungsprozedur. y Es gibt den Datenbankparameter UseAutomaticBadIndexRecreation mit dem diese Option deaktiviert werden kann, was aber eine längere Downtime zur Folge hat. „

© SAP AG

ADM515

5-73

Wiederherstellen – Fehlerhafte Indizes anzeigen und wiederherstellen

© SAP 2008

In der aktuell verfügbaren Version des Database Studio 7.8 ist das Erreichen dieser Ausgabe mit den defekten Indizes nicht direkt durch Folgen des Hyperlinks erreichbar. Es erscheint ein Popup mit einer Fehlermeldung. Hier wird dann mit dem CONTROL-User versucht, SQL-Statements an die Datenbank zu schicken, da der CONTROL-User genutzt wurde, die Overview-Ausgabe aufzubereiten. CONTROL-User sind aber reine Administrationsuser und können keine SQLStatements an die Datenbank schicken. Dieser Fehler wird in zukünftigen Versionen des Database Studio behoben. „ Löschen Sie unter dem zugehörigen Datenbankinstanznamen in der Baumstruktur der Datenbanken den Unterpunkt für den CONTROL-User und lassen dort nur den SUPERDBA-User stehen, wird dieser User für die Ausführung des SQL-Statements zur Ermittlung der defekten Indizes genutzt. Dann erhalten Sie die hier dargestellte Ausgabe. „ Für jeden gefundenen defekten Index gibt es einen Eintrag in der Liste und über das Kontextmenü können die Indizes kollektiv oder individuell wiederhergestellt werden. „

© SAP AG

ADM515

5-74

Wiederherstellen – Indizes

© SAP 2008

„

Die Ermittlung der fehlenden Indizes kann mit den Info-Kommandos erfolgen: info badidx y Mit dem dbmcli lautet das Kommando: dbmcli –d -u control,control info badidx

„

Mit dem Kommando sql_recreateindex kann ein fehlender Index leicht wieder hergestellt werden. Die Angabe des Index erfolgt in der Form <Schemaname>..

© SAP AG

ADM515

5-75

Behandlung von Transaktionen beim Restart Savepoint

Savepoint

T1

Savepoint

Absturz

C T2 T3

R T4

C T5 R T6 C Zeit

Keine Wiederherstellung der Transaktionen T1 und T5 Wiederherstellung der Transaktionen T4 und T6 Zurückrollen der Transaktionen T2 und T3 © SAP 2008 / Page 1

Bei jedem Restart, z.B. nach einem Datenbankfehler, wird nach offenen Transaktionen oder Änderungen nach dem letzten Savepoint gesucht und je nach Bedarf eine automatische Wiederherstellung (Recovery) gestartet. „ Nur die Daten, die zum Zeitpunkt des letzten Savepoints gültig waren, wurden auf die DatenVolumes geschrieben und stehen nun noch zur Verfügung. Die Änderungen zwischen den Savepoints sind nach einem abrupten Ende der Datenbank nur noch in den Log-Einträgen nachvollziehbar. „ Der letzte Savepoint wird nun als Aufsetzpunkt für die automatische Wiederherstellung verwendet. „ Die dargestellten Transaktionen werden folgendermaßen behandelt: y Keine Wiederherstellung für Transaktionen T1 und T5 T1 ist vollständig im letzten Savepoint vor dem Datenbankabsturz enthalten. T5 wurde nach dem letzten Savepoint gestartet und vor dem Absturz manuell abgebrochen und zurückgerollt und erübrigt sich damit. y Wiederherstellung der Transaktionen T4 und T6 T4 war beim letzten Savepoint aktiv und wurde erfolgreich abgeschlossen. T6 wurde nach dem Savepoint gestartet und erfolgreich abgeschlossen. y Zurückrollen der Transaktionen T2 und T3 T2 war während des Absturzes aktiv und muss daher zurückgerollt werden. T3 war zum letzten Savepoint aktiv. Die Änderungen durch diese Transaktion sind also im Savepoint enthalten und müssen daher wieder entfernt werden, da die Transaktion nach dem Savepoint zurückgerollt wurde. „

© SAP AG

ADM515

5-76

Nachfahren der Log-Einträge

Log

Log-Dateien 1 2 3 4 5 6 7 C

6

...

...

R

7

C

1 2 3 R

Daten

6

...

7

C

...

R

Log-Sicherung 1

1

...

2

2

3

3

4

5

Das Einlesen der Log-Einträge wird parallelisiert durchgeführt Der aktuelle online-LogVolume bleibt hierbei unverändert

© SAP 2008 / Page 1

Sammlung aller transaktionsrelevanter Aktionen in sogenannten Log-Dateien pro Transaktion innerhalb der Data-Volumes „ Die Log-Information kann dabei aus einer Log-Sicherung oder aus dem Log-Volume stammen. „ Sobald alle Daten einer Transaktion gesammelt sind, wird die nachzufahrende Transaktion abgearbeitet. „ Das Nachfahren der Log-Einträge benötigt daher Platz im Daten-Volume und kann je nach LogAufkommen theoretisch den gesamten Datenbereich füllen. „

© SAP AG

ADM515

5-77

Wiederherstellung: Übersichtsdiagramm

Wiederherstellung Thema 1: Ausgangssituation und Analyse Thema 2: Strategie Thema 3: Durchführung der Wiederherstellung Thema 4: Nutzung gespiegelter Log-Volumes Thema 5: Vorgänge in der Datenbank Thema 6: Aktionsmatrix

© SAP 2008

© SAP AG

ADM515

5-78

Nutzung gespiegelter Logs zur Wiederherstellung Derzeit keine direkte Unterstützung im Database Studio 7.7 (bis 7.8.00 B06) Bis dahin alternativ manuell über Bestimmung des fehlerhaften Log-Volume mit folgendem Kommando: db_execute GET BAD LOG VOLUME „ Wiederherstellen des defekten Log-Volumes (als Teil eines Spiegels) durch das Kommando: db_execute RESTORE LOG VOLUME '/DISKL001' „

Oder indirekt über das Database Studio, wenn nur der Log-Spiegel defekt ist: „

Deaktivierung der Option Log-Spiegelung und ungespiegelte Log-Volumes nutzen. Anschließend sollte die Log-Spiegelung über den Wizard wieder reaktiviert werden.

© SAP 2008 / Page 1

Bitte anschließend eine genauere Analyse beginnen, um die Ursache für diese Fehler zu finden. Meist handelt es sich hier um Hardwareprobleme. „ SAP Hinweis 1177052 erläutert die Optionen bei dem Vorgehen detailiert. „

© SAP AG

ADM515

5-79

Wiederherstellung: Übersichtsdiagramm

Wiederherstellung Thema 1: Ausgangssituation und Analyse Thema 2: Strategie Thema 3: Durchführung der Wiederherstellung Thema 4: Nutzung gespiegelter Log-Volumes Thema 5: Vorgänge in der Datenbank Thema 6: Aktionsmatrix

© SAP 2008

© SAP AG

ADM515

5-80

Wiederherstellen – vollständige Datensicherung t

Restore

DAT_00004 DAT_004

DAT_004

Data 1

Data 2

Data n

© SAP 2008 / Page 1

Diese Darstellung zeigt noch einmal die Vorgänge in der Datenbank beim Wiederherstellen der verschieden Sicherungen (Daten- und Log-Sicherungen). „ 1. Schritt: y Datenbank in den Betriebszustand ADMIN bringen. y Die Wiederherstellung der vollständigen Datensicherung wird gestartet und die Seiten werden in die Daten-Volumes übertragen. „

© SAP AG

ADM515

5-81

Wiederherstellen – inkrementelle Sicherung

Restore PAG_005

DAT_004

Restore DAT_004

PAG_005

t

Data 1

Data 2

Data n

© SAP 2008 / Page 1

„

2. Schritt: Die Seiten aus der inkrementellen Datensicherung werden über die bereits bestehenden Seiten aus der vollständigen Datensicherung geschrieben.

© SAP AG

ADM515

5-82

Wiederherstellen – Logsicherung t

PAG_005

Restore PAG_005

DAT_004

Restore DAT_004

Redo Log Info vom Log Volume

LOG_010

Restore LOG_010

and Restart

Log Log

Data 1

Data 2

Data n

© SAP 2008

„

3. Schritt – Änderungen nach den Datensicherungen wiederherstellen y Variante 1: Alle benötigten Daten stehen noch im Log-Volume, auch wenn schon ein oder mehrere Log-Sicherungen angefertigt wurden. Alle Log-Einträge werden aus dem Log-Volume und nicht aus der Log-Sicherung entnommen. y Wenn die Datenbankinstanz in den Zustand ONLINE gebracht wird, werden die Log-Einträge nachgefahren.

© SAP AG

ADM515

5-83

Wiederherstellen – Nachfahren der Logeinträge t and Restart

Redo Log Info vom Log Volume

Until 01.01.2006 12:45:21

PAG_005

Restore PAG_005

DAT_004

Restore DAT_004

Log Log

01.01.2006 12:45:21

Data 1

Data 2

Data n

© SAP 2008

„

3. Schritt – Änderungen nach den Datensicherungen wiederherstellen y Variante 2: Die Datenbankinstanz soll nur bis zu einem bestimmten Zeitpunkt in der Vergangenheit wiederhergestellt werden, um einen Eingabefehler rückgängig zu machen und den ursprünglichen Zustand der Daten zu erhalten. y Es wird ein Restore Until-Zeitpunkt für das Starten der Datenbankinstanz und das Nachfahren der Log-Einträge angegeben. Log-Einträge, die nach diesem Zeitpunkt liegen, werden ignoriert und gelöscht. y Um diese Log-Informationen für nachfolgende Restore-Operationen weiter zur Verfügung zu haben (z.B. für einen weiteren Restore Until mit einem späteren Zeitpunkt), wird dringend empfohlen, vor dem Restore Until eine Log-Sicherung anzufertigen!

© SAP AG

ADM515

5-84

Wiederherstellen – Log-Versionsdateien

Data 1

Restore

Redo Log Info vom

LOG_010

LOG_011

Log Volume

and Restart

LOG_011

Restore

LOG_010

Restore PAG_005

DAT_004

Restore DAT_004

PAG_005

t

Version Files

Log

log.010 log.011

Data 2

Log

Data n

© SAP 2008

„

3. Schritt y Variante 3: Es wurden durch den Betrieb der Datenbankinstanz seit der letzten Log-Sicherung bereits so viele Log-Einträge produziert, dass der zum Überschreiben freigegebene Log-Bereich tatsächlich mit neueren Log-Einträgen überschrieben wurde. y Die nicht mehr im Log-Volume vorhandene Log-Information muss aus den Log-Sicherungen wiederhergestellt werden. y Dies erfolgt über die Daten-Volumes, damit bestehende Log-Einträge im Log-Volume nicht überschrieben werden. y Wenn die Log-Sicherungsdateien schon auf Band gesichert wurden, müssen sie unter dem gleichen Namen wieder auf den Platten bereitgestellt werden. y Das Nachfahren der Log-Einträge erfolgt während des Wechsels in den Betriebszustand ONLINE. y Die Log-Einträge aus den Sicherungen werden dabei bis zu dem ersten im Log-Volume vorhandenen Log-Eintrag gelesen.

© SAP AG

ADM515

5-85

Wiederherstellen – Log-Versionsdateien t Restore

Redo Log Info vom

LOG_010

LOG_011

Log Volume

and Restart

Until 01.01.2006 12:45:21

PAG_005

Restore PAG_005

DAT_004

Restore DAT_004

Restore

Version Files

Log

log.010 log.011

Log

01.01.2006 12:45:21

Data 1

Data 2

Data n

© SAP 2008

„

3. Schritt y Variante 3: Auch bei dieser Variante ist es möglich, einen Restore Until-Zeitpunkt anzugeben. y Dieser Zeitpunkt kann auch im Bereich der Log-Sicherungen liegen.

© SAP AG

ADM515

5-86

Wiederherstellung mit externen Sicherungstools Database Manager CLI

Database Studio

Datenbankrechner Medium

DBMServer Ext. Backup History

Backup History

Backupserver

MaxDBKern Pipes Pipes

DATA

Sicherungswerkzeug (Client)

Sicherungswerkzeug (Server)

Hauptdatenfluss Kontroll- und Kommandodaten

Tapes

© SAP 2008

„ „ „ „

„ „ „

Die Abwicklung der Wiederherstellung wird vom DBMServer gesteuert und verwaltet. Der DBMServer entnimmt dem Mediennamen, welches externe Sicherungswerkzeug verwendet werden soll und ermittelt dann das weitere Vorgehen. Der DBMServer setzt das Wiederherstellungskommando an den Datenbankkern ab, dieser öffnet daraufhin die benötigten Pipes nacheinander Wenn der Datenbankkern versucht die erste Pipe zu öffnen, startet der DBMServer den Client des Sicherungswerkzeuges. Dazu wird aus der Liste der External Backup Identifier die Information entnommen, welche Sicherungen genau wiederhergestellt werden sollen. Das Sicherungswerkzeug stellt die gewünschten Sicherungsdaten in den Pipes bereit, die der Datenbankkern entgegennimmt und auf den Data-Volumes verteilt. Nach Abschluss der Aktion interpretiert der DBMServer die Antwort des Datenbankkernes und den Returncode des Sicherungswerkzeuges und vermeldet das Ergebnis des Wiederherstellungsversuchs. Weitere Informationen (z.B. welche dbmcli-Kommandos sich dahinter verbergen) finden Sie unter http://maxdb.sap.com

© SAP AG

ADM515

5-87

Wiederherstellung: Übersichtsdiagramm

Wiederherstellung Thema 1: Ausgangssituation und Analyse Thema 2: Strategie Thema 3: Durchführung der Wiederherstellung Thema 4: Nutzung gespiegelter Log-Volumes Thema 5: Vorgänge in der Datenbank Thema 6: Aktionsmatrix

© SAP 2008

© SAP AG

ADM515

5-88

Aktionsmatrix nach Fehlersituation (1)

Ausfall eines Daten-Volume

Data

Normale Wiederherstellung der Datenbankinstanz „

Das bestehende Log-Volume wird verwendet, um den letzten Stand der Datenbankinstanz wiederherzustellen.

„

Sind die benötigten Log-Einträge nicht mehr im Log-Volume vorhanden (gesichert und dann im Log-Volume überschrieben), müssen zusätzlich Log-Sicherungen nachgefahren werden.

© SAP 2008

© SAP AG

ADM515

5-89

Aktionsmatrix nach Fehlersituation (2)

Ausfall eines Log-Volume

Vorgehen ähnlich der Systemkopie (Hinweis 129352) „

Initialisierung der Datenbankinstanz und Formatierung der Log-Volumes (Database Studio: Recovery → Option Initialization...) ohne Konfigurationsänderungen

„

Wenn Sie die Lage von Volumes ändern müssen, wählen Sie bitte stattdessen Initialize Database… im Kontextmenü der Instanz des Database Studios

„

Während der verschiedenen Wizards werden dann Datenund evtl. erstellte Log-Sicherungen wiederhergestellt.

„

Bei diesem Vorgehen kommt es zu Datenverlust. Der Datenbankzustand kann bis zum Zeitpunkt des letzten Eintrags der vorhandenen Log-Sicherungen wiederhergestellt werden. Es fehlen jedoch alle Datenänderungen, die nach der letzten Log-Sicherung vorgenommen wurden.

Log

© SAP 2008

Wie eine Systemkopie erstellt wird, beschreibt das folgende Kapitel. „ Wenn Sie den Log-Modus Mirroring (gespiegelte Volumes) nutzen und einer der beiden LogVolumes ausgefallen ist, beachten Sie bitte den Abschnitt mit dem Thema „Nutzung gespiegelter Log-Volumes“. „ Es ist immer empfehlenswert, die letzen Log-Informationen aus dem online-Log-Volume noch ein letztes Mal zu sichern, auch wenn das Log-Volume evt. stellenweise defekt ist. Der Sicherungsprozess wird dann alle intakten Log-Pages sichern bis der erste Page-Fehler auftritt. „

© SAP AG

ADM515

5-90

Aktionsmatrix nach Fehlersituation (3)

Ausfall der Platte mit der Datenbanksoftware unter /sapdb

/sapdb Programme etc.

Wiederherstellung des Programmverzeichnisses „ „

Per Installation des zuletzt verwendeten Patches Angabe der Installationsverzeichnisse im interaktiven Modus des Installationstools (sdbinst): „

Independent Data Path: /sapdb/data

„

Independent Program Path: /sapdb/programs

„

Dependent Path: /sapdb/<SID>/db

Wiederherstellung der Datenbank wie beim Ausfall eines LogVolume „

Kontrollieren Sie, dass evtl. genutzte RAW-Volumes wieder bereitstehen

Achten Sie bei der Wiederherstellung darauf, dass der Parametersatz aus der Datensicherung verwendet wird.

© SAP 2008 / Page 1

Alternative Wiederherstellungen sind in Notsituationen eventuell möglich. Bitte wenden Sie sich an den SAP Support. „ Falls die Konfigurationsdaten unter /sapdb/data/config nach jeder Konfigurationsänderung gesichert wurden, kann es mit viel Erfahrung möglich sein, die Datenbankinstanz ohne Recovery wieder zu rekonstruieren. „ Diese Daten sind aber auf jeden Fall als Parametersatz in jeder Sicherung enthalten. „

© SAP AG

ADM515

5-91

Datenbanksicherung und -wiederherstellung: Zusammenfassung

Sie können nun: „

Sicherungen und Wiederherstellungen durchführen

„

Kennen wichtige Aspekte einer Sicherungsstrategie

© SAP 2008 / Page 1

© SAP AG

ADM515

5-92

Übungen Kapitel: 4 Thema: Datenbanksicherung und -wiederherstellung Am Ende dieser Übungen können Sie: • Sicherungen erstellen und diese wieder rekonstuieren. Außerdem können Sie mit diesen Fähigkeiten Fehlersituationen beheben, die im Datenbankbereiche auftreten können. Fehlersituation wie der Ausfall einer Platte oder des entsprechenden Kontrollers können die Funktion der Datenbank beeinträchtigen oder auch komplett beenden. Nach Reparatur ist meist eine Wiederherstellung des Datenbanksystems notwendig. Diese Situationen werden hier simuliert und praktisch gelöst. 4-1

Definition der Backupmedien Zur Erstellung von Sicherungen wurden Bereiche für jede Datenbankinstanz angelegt, die von den Teilnehmern entsprechend der verwendeten Datenbankinstanz bei der Definition der Backupmedien angegeben werden können: Gruppe NN → Datenbank T → G:\sapdb\T\savefiles\ Bitte stellen Sie sicher, daß Sie die für Sie bereitgestellten Bereiche nutzen. Bei der Erstellung der Datenbank wurde gleich eine erste Sicherung G:\sapdb\T\savefiles\datasave (Mediumname data) erzeugt. Diese kann jederzeit genutzt werden, um wieder auf den Urzustand zu Beginn der Schulung zurückzukehren. Dazu verwenden Sie bitte die Beschreibung zur Installation einer neuen Datenbankinstanz aus Kapitel 5 (Kontextmenü der Instanz → Initialize Database…). Bitte halten Sie diese Sicherung für Notfälle zurück.

4-2

4-1-1

Anlegen des Medium für eine vollständige Datensicherung.

4-1-2

Anlegen des Mediums für inkrementelle Datensicherungen

4-1-3

Anlegen des Mediums für Log-Sicherungen

4-1-4

Optional: Erzeugen Sie eine Mediengruppe bestehend aus zwei oder mehr Einzelmedien um eine Parallel Sicherung durchführen zu können. (Hinweis: Achten Sie auf die korrekte Einstellung der notwendigen Datenbankparameter)

Erstellung eines vollständigen Datenbackups 4-2-1

© SAP AG

Führen Sie mit Hilfe des Database Studios eine vollständige Datensicherung durch.

ADM515

5-93

4-3

Erstellung einer inkrementellen Datensicherung 4-3-1

4-4

Erstellung einer Logsicherung 4-4-1

4-5

4-6

4-5-1

Verwenden Sie den Database Studio um die Autolog Funktion zu aktivieren. Dabei können Sie das bestehende Log-Medium verwenden.

4-5-2

Füllen Sie den Log weiter mit dem Tool und überprüfen der Funktion des AutoLog.

4-5-3

Stimmt die Größe der Sicherungen mit dem Parameter AutoLogBackupSize überein? Bitte verändern Sie den Parameter AutoLogBackupSize entsprechend der Möglichkeiten des Mediums oder entsprechend des Logaufkommens eines Arbeitstages.

4-5-4

Nutzen Sie die Zeitsteuerung der automatischen Los-Sicherung im Database Studio um eine zeitgesteuerte Log-Sicherung zu aktivieren.

Sicherungshistorie

Überprüfen Sie ein oder mehrere Sicherungen mit dem im Trainingmaterial beschriebenen Verfahren.

Ausfall eines Daten-Volumes simulieren und wiederherstellen der Datenbank druchführen 4-8-1

© SAP AG

Konsultieren Sie die Sicherungshistorie, um sich einen Überblick über die gemachten Sicherungen zu verschaffen. Identifizieren Sie die Sicherungen mit deren Hilfe Sie am schnellsten ein Restore erreichen.

Sicherung überprüfen 4-7-1

4-8

Führen Sie Log-Sicherungen durch, indem Sie wiederum das Tool filldb.py zur Erzeugung von Log-Informationen verwenden.

Einrichten und aktivieren des AutoLog

4-6-1

4-7

Verwenden Sie das filldb.py um die Datenbank zu füllen und Daten zur Erstellung der inkrementellen Datensicherungen zu erhalten..

Mit Hilfe des Tools filldb.py füllen Sie die Datenbank und stellen währenddessen incrementelle und Vollsicherungen her. Ziel ist, eine Sicherungshistorie zu erzeugen um die verschieden Alternativen bei dem anschließenden Recovery zu testen. In vielen Fällen kann eine umfangreichere Sicherungshistorie schon aus den vorhergehenden Übungen vorhanden sein.

ADM515

5-94

4-9

4-8-2

Sollte die Datenbank drohen vollzulaufen, löschen Sie bitte die Tabelle FILLTABLE um damit die Datenbank wieder zu leeren und weitere Sicherungen erstellen zu können. Das Kommando lautet dbmcli -U c -USQL w sql_execute “drop table FILLTABLE“ oder ein x_python filldb.py –d <SID> -u sapt<xx> -clear (Achtung: Sollte die DB schon zu über 95% gefüllt sein und keine weiteren Kommandos annehmen, ist es zu einer DBFULL-Situation gekommen und es hilft nur eine Erweiterung der Datenbank.)

4-8-3

Nachdem Sie eine ansehnliche Sicherungshistorie aus Voll-, inkrementellen und Log-Sicherungen besitzen, stoppen Sie bitte die DB und benennen ein Daten-Volume um oder löschen es.

4-8-4

Anschließend benutzen Sie das in den Unterlagen beschriebene Szenario, um die Datenbank wieder herzustellen.

Optional: Point in Time Recovery 4-9-1

© SAP AG

Während der Tests des Wiederaufsetzens der Datenbank ist es ebenfalls möglich anschließend auch das Point-in-Time-Recovery zu probieren. (Tipp: Sie können die Tabelle FILLTABLE zu einem bestimmten Zeitpunkt löschen und dann bei dem Point-in-Time Recovery eine Zeitpunkt vor dem Löschen der Tabelle wählen. Damit können Sie über die Existenz der Tabelle nach der Wiederherstellung überprüfen, ob das Pointin-Time Recovery funktioniert hat.

ADM515

5-95

© SAP AG

ADM515

5-96

Lösungen Kapitel: 4 Thema: Datenbanksicherung und -wiederherstellung

4-1

Definition der Backupmedien 4-1-1 Wählen Sie bitte im Database Studio im Administrationsbereich den Menüpunkt → Backup und → Templates und anschließend den Menüpunkt → New oder das entsprechende Klappmenü auf der linken Seite des Tools. Vorschlag: Mediumname DATAcomp_<SID> Backup Type Complete Data . Device Type File . Backup Tool NONE . Device/File G:\sapdb\<SID>\savefiles\DataC_<SID>.bak 4-1-2 Wählen Sie im Database Studio im Administrationsbereich den Menüpunkt → Backup und → Templates und darin anschließend den Menüpunkt → New oder das entsprechende Klappmenü auf der linken Seite des Tools. Vorschlag: Mediumname DATAinc_<SID> Backup Type Incremental Data . Device Type File . Backup Tool NONE . Device/File G:\sapdb\<SID>\savefiles\DataI_<SID>.bak 4-1-3 Wählen Sie im Database Studio im Administrationsbereich den Menüpunkt → Backup und → Templates und darin anschließend den Menüpunkt → New oder das entsprechende Klappmenü auf der linken Seite des Tools. Vorschlag: Mediumname LOG_<SID> Backup Type Log . Device Type File . Backup Tool NONE . Device/File G:\sapdb\<SID>\savefiles\Log_<SID>

© SAP AG

ADM515

5-97

4-1-4 Wählen Sie im Database Studio im Administrationsbereich den Menüpunkt → Backup und → Templates und darin anschließend das entsprechende Klappmenü unter dem Menüpunkt → New auf der linken Seite des Tools. Es erscheint die Option → New Parallel Backup Template. Vorschlag: Name GruppeDATA_<SID> . Backup Type Complete Data Device Type File . Backup Tool None Device 1 Device/File: G:\sapdb\<SID>\savefiles\GroupM1_<SID>.bak Device 2 Device/File: G:\sapdb\<SID>\savefiles\GroupM2_<SID>.bak Die hier angezeigte Zahl vom Device-Reitern hängt direct vom DatenbankParameter MaxBackupMedia ab.

4-2

Erstellung eines vollständigen Datenbackups 4-2-1 Wählen Sie im Kontextmenü der Datenbankinstanz den Menüpunkt → Backup an und folgen der in den Unterlagen beschriebenen Vorgehensweise zu Erstellung einer Daten-Vollsicherung. Wählen Sie im Folgebild das entsprechende Medium für die Vollsicherung aus und spezifizieren anschließend die Art der Sicherung. Danach starten Sie bitte die Sicherung. Sollten Fehler auftreten, kontrollieren Sie bitte die Einträge in der Datei knlMsg zum Zeitpunkt des Fehlers

4-3

Erstellung einer inkrementelle Datensicherung 4-3-1 Füllen Sie zuerst zusätzliche Daten in Ihre Datenbank mit Hilfe des Tools filldb.py ein: cd /d %PYTHONPATH% x_python filldb.py –d <SID> -u sap<sid>,sap –data Gehen Sie entsprechend der Daten-Vollsicherung vor, und nutzen den Wizard hinter Menüpunkt →Backup. Wählen Sie aber die Option →Incremental Data Backup, das Medium für die inkrementelle Sicherung und spezifizieren dann die Art der Sicherung. Danach starten Sie bitte die Sicherung.

© SAP AG

ADM515

5-98

4-4

Erstellung einer Logsicherung 4-4-1 Füllen Sie zuerst Log in Ihre Datenbank mit Hilfe des Tools filldb.py: cd /d %PYTHONPATH% x_python filldb.py –d <SID> -u sap<sid>,sap –log Gehen Sie entsprechend der vorherigen Sicherung vor, wählen aber im Wizard die Option →Log Backup aus, dann das Medium für die LogSicherung und starten dann die Sicherung.

4-5

Einrichten und aktivieren des AutoLog 4-5-1 Kontrollieren Sie bitte, ob sich Ihre Datenbank im Zustand Online befindet, damit sie unter Administrationbereich → Log Area den Hyperlink zum Aktivieren der automatischen Log-Sicherung finden →Automatic Log Backup. Sollte die Datenbankinstanz nicht Online sein, meldet sich der Wizard entsprechend. Wählen Sie das gewünschte Medium aus und aktivieren die Funktionalität, falls Sie nicht bereits aktiviert ist. 4-5-2 Füllen Sie weiter Log in Ihre Datenbank mit Hilfe des Tools filldb.py ein: cd /d %PYTHONPATH% x_python filldb.py –d <SID> -u sap<sid>,sap –log Der Log aus dem Log-Volume wird nun immer beim Erreichen einer Größe von AutoLogBackupSize automatisch gesichert. Beobachten Sie bitte das Verzeichnis, in das die Log-Sicherungen geschrieben werden. 4-5-3 Den Parameter AutoLogBackupSize können Sie über den Administrationsbereich → Parmeters oder über das folgende Kommando ermitteln: dbmcli -U c param_directget AutoLogBackupSize Bei diesem Wert handelt es sich um die Anzahl der Pages. Die Dateigröße ist daher durch 8kByte zu dividieren um sie mit dem Parameter vergleichen zu können. 4-5-4 Während der Aktivierung des AutoLog ist Ihnen bestimmt schon das Feld zur Bestimmung der Wiederholungszeit aufgefallen. Nutzen Sie es bitte und setzen es auf 10 Minuten oder weniger.

4-6

Sicherungshistorie 4-6-1 Über den Administrationsbereich → Backup im Database Studio können Sie die Sicherungshistorie komfortabel einsehen. Die einzelnen Sicherungstypen werden mit unterschiedlichen Farben bzw. Farbschattierungen markiert.

© SAP AG

ADM515

5-99

4-7

Sicherung überprüfen 4-7-1 Die Funktion findet sich im Database Studio im Administrationsbereich → Backup. Wählen die den entsprechenden Template-Namen oder direkt eine Sicherung in der Sicherungshistorie aus, hinter dem sich die zu prüfende Sicherung befindet. Mit dem Kontextmenü erhalten Sie die Funktion Check Backup. Notfalls legen Sie bitte ein weiters Template an, das Sie nur für diesen Zweck verwenden und auf eine spezielle Sicherung zeigt.

4-8

Ausfall eines Daten-Volumes simulieren und wiederherstellen der Datenbank druchführen 4-8-1 Es sollten mindestens eine Datenvollsicherung, zwei inkrementelle Sicherungen und mehrere Log-Sicherungen (interaktiv oder per AutoLog) vorhanden sein um evt. verschiedene Recovery-Szenarien probieren zu können. 4-8-2 Daneben können Sie die Tabelle FILLTABLE auch über das Database Studio oder das filldb.py löschen. Zeigen Sie sich dazu bitte die Objekte unterhalb des SAP<SID>-Users an und löschen die Tabellen mit der rechte Maustaste über der Tabelle FILLTABLE → Funktion: Drop Table. 4-8-3 Bitte stoppen Sie die Datenbank nach OFFLINE und löschen anschließend mit Betriebssystemmitteln ein Daten-Volume. Die Daten-Volumes sollten im Unterverzeichnis G:\sapdb\<SID>\sapdata\ zu finden sein. 4-8-4 Vorraussetzungen: Bringen Sie die Datenbank in den Modus Admin. Anschließend nutzen Sie im Kontextmenü Ihrer Datenbankinstanz →Recovery ... um die Bestimmung der Recoverystrategie zu starten.

4-9

Optional: Point in Time Recovery. 4-9-1 Die Recovery-Prozedur kann noch einmal unter Verwendung eines Restore Until-Zeitpunktes durchgeführt werden. Dieser Zeitwert kann sowohl am Anfang als auch später kurz vor dem Start des Log-Recovery eingegeben werden. Bitte überprüfen Sie nach Erfolg die Funktionsweise anhand der Existenz der Tabelle FILLTABLE z.B. mit dbmcli -U c -USQL w sql_execute “select * from TABLES where TABLENAME=’FILLTABLE’“ oder mit dem Database Studio. Wenn eine Meldung ROW NOT FOUND erscheint, ist der Log zu weit nachgefahren worden.

© SAP AG

ADM515

5-100

Weitere Administrationsthemen

Inhalt: Vorstellung weitergehender administrativer Tätigkeiten „ Systemkopien mit MaxDB „

Installationen der Datenbanksoftware und genutzte Werkzeuge „ Hochverfügbarkeitslösungen mit MaxDB „

„

Migrationen zur MaxDB

© SAP 2007 / Page 1

© SAP AG

ADM515

6-1

Weitere Administrationsthemen: Lernziele

Am Ende dieses Kapitels, können Sie: Systemkopien mit MaxDB erstellen „ Installationstools der MaxDB-Software nutzen „

„

die Hochverfügbarkeitslösungen benennen

© SAP 2008

© SAP AG

ADM515

6-2

Agenda I

1. Der erste Kontakt 1.1. 1.2. 1.3. 1.4. 1.5. 1.6.

3. MaxDB-Interna

Einführung Werkzeuge und Schnittstellen Architektur und Betriebszustände MaxDB und SAP NetWeaver Integration mit SAP NetWeaver Serverlandschaft der Schulung

3.1. 3.2. 3.3. 3.4. 3.5.

4. Datenbanksicherung und -wiederherstellung

2. MaxDB betreiben 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8.

Prozesse Sperren Speicherbereiche Plattenbereiche Logging

Überblick Database Studio Wichtige Informationsquellen im Database Studio Benutzer der MaxDB im SAP-Umfeld Plattenbereiche für Daten und Log Konfigurationsänderungen DBFULL und LOGFULL Situationen Parameter Übungswerkzeug

4.1. 4.2. 4.3. 4.4. 4.5. 4.6. 4.7. 4.8. 4.9.

Vollständige Datensicherung Inkrementelle Datensicherungen MaxDB Snapshots Log-Sicherungen Automatische Log-Sicherung Überprüfen der Sicherungen Sicherungsstrategie Externe Sicherungstools Wiederherstellungen

© SAP 2008

© SAP AG

ADM515

6-3

Agenda II

5.

Weitere Administrationsthemen 5.1. 5.2. 5.3. 5.4. 5.5. 5.6. 5.7.

7.

Prüfen der Datenbank Erstellen einer Datenbankinstanz Neuinitialisierung einer Datenbankinstanz Installation eines Patches (Releasewechsel) Migration zur MaxDB Hochverfügbarkeit MCOD

Ausblick auf MaxDB 7.8 7.1. 7.2. 7.3. 7.4. 7.5.

Übersicht Änderungen des Datenbankkerns Neue administrative Funktionen Setup und Infrastruktur Interface & User

6. Performance-Tuning und Problemsituationen 6.1. 6.2. 6.3. 6.4. 6.5. 6.6.

B*-Bäume Optimierung Monitore des SAP NetWeaver Vermeidbare Probleme Diagnosedateien und TraceMöglichkeiten Fehlerarten und deren Analyse

© SAP 2008

© SAP AG

ADM515

6-4

Weitere Administrationsthemen:

Übersichtsdiagramm

Weitere Administrationsthemen Thema 1: Prüfen der Datenbank Thema 2: Erstellen einer Datenbankinstanz Thema 3: Neuinitialisierung einer Datenbankinstanz Thema 4: Installation eines Patches (Releasewechsel) Thema 5: Migration zur MaxDB Thema 6: Hochverfügbarkeit Thema 7: MCOD

© SAP 2007 / Page 1

„

Siehe auch SAP Hinweis 940420 (FAQ: Datenbankstrukturprüfung (VERIFY))

© SAP AG

ADM515

6-5

Formen der Konsistenzprüfung

EXTENDED „

Ausführliche Überprüfung der Schlüsselsequenzen

WITH LONG CHECK (früher WITH SHARE LOCK) „ „

Zusätzliche Überprüfung der LONG (BLOB) Spalten Share-Sperren werden gesetzt

EXCEPT INDEX „

Indizes werden nicht überprüft

WITH UPDATE „

Ausführung nur im Betriebszustand ADMIN

„

Zusätzliche Pflege des Converters: Page-Nummern ohne Referenzen werden gelöscht

© SAP 2008

„

„

„ „ „

Kommandos: y CHECK DATA [EXTENDED] [EXCEPT INDEX] y CHECK TABLE .. [EXTENDED] [WITH LONG CHECK] y CHECK DATA WITH UPDATE (nur im Modus ADMIN) Eine intensivere Diagnosemöglichkeit der Daten in den Volumes wird mit CHECK DATA EXTENDED geboten. Während dieser Überprüfung wird eine präziserer Test der Primärschlüssellängeninformation ausgeführt und auf allen Ebenen des B*Baums wird die Sortierung der Primärschlüssel überprüft. Aufgrund der etwas höheren Komplexität dieser Überprüfung kann die Laufzeit erhöht sein. Die Option WITH LONG CHECK überprüft ebenfalls die BLOBs. Hier wird auch eine Share-Sperre auf die gerade untersuchte Tabelle gesetzt. Um etwas Resourcen zu sparen, könnte mit der Option EXCEPT INDEX die Untersuchung der Sekundärindizes ausgelassen werden. Die Option WITH UPDATE funktioniert nur im Modus ADMIN und baut den Converter wieder auf, bei dem die nicht referenzierten Pages gelöscht werden. Diese nicht referenzierten Pages können auftreten, wenn die DB durch den Spannungsschalter des Datenbanksservers beendet wird und damit der Status der asynchron arbeitenden SERVER-Prozesse nicht durch einen richtigen Shutdown gesichert werden konnte z.B. bei einem drop table.

© SAP AG

ADM515

6-6

Konsistenzprüfung der Datenbankinstanz

Prüfung im Betriebszustand ONLINE: „

Es wird nur eine Analyse durchgeführt und es werden keine Änderungen an der Datenbankinstanz vorgenommen.

Prüfung im Betriebszustand ADMIN: „

Es wird während der Analyse eine Reparatur defekter Strukturen versucht. Dabei wird der Converter neu aufgebaut.

Ausführung „

im Database Studio: Kontextmenü der Datenbankinstanz → Check Database Structure…

„

DBA Cockpit „

„

Aktion: Datenbankstruktur prüfen oder Datenbankstruktur prüfen (nur Tabellen)

Weitere Möglichkeiten über die Konsole

© SAP 2008

„

Ausführen der Prüfung über die Konsole: y dbmcli –U c –uUTL -c util_execute check data

Die Aktion Datenbankstruktur prüfen wird als CheckData im Kalender des DBA Cockpit eingetragen. Diese Aktion wird über den Work-Prozess ausgeführt. Dabei wird pro Volume eine Servertask gestartet, die die Analyse durchführt. „ Die Aktion Datenbankstruktur prüfen (nur Tabellen) erscheint als CheckTables im DBA Cockpit und überprüft nur die Tabellen und keine Indizes. Hierbei wird eine feste Anzahl von parallel arbeitenden Tasks vom Planer erfragt. Bei Performanceproblemen ist es bei der Verwendung von wenigen Volumes sinnvoll, mit dem CheckTables zu arbeiten, um eine höhere Parallelität zu erreichen. „

© SAP AG

ADM515

6-7

Konsistenzprüfung im Database Studio

© SAP 2007 / Page 1

© SAP AG

ADM515

6-8

Konsistenzprüfung einzelner Tabellen

Die SQL-Anweisung CHECK TABLE . prüft alle Verknüpfungen innerhalb des Tabellenbaums. „

Liefert sie einen Fehler, muss der Hardwarefehler behoben und eine Sicherung eingelesen werden.

Ausführung „

Database Studio

„

über das DBA Cockpit oder die Transaktion DB50 (Problemanalyse → Tabellen/Indizes)

„

mit dem Database Manager CLI

© SAP 2008

Die Anweisung CHECK TABLE prüft alle Abhängigkeiten und Verknüpfungen innerhalb des Tabellenbaums. „ Jede Seite enthält eine Prüfzahl im Header und Trailer. Beide Zahlen müssen gleich sein. Ist der Wert unterschiedlich, liegt ein Fehler vor. Die Seite konnte beim letzten Schreib- und Lesevorgang (I/O) nicht vollständig geschrieben werden. „ Ausführung mit dem Database Manager CLI: „

dbmcli –U c –USQL DEFAULT sql_execute “check table <SCHEMA>.” „

Ausführung im Database Studio: CHECK TABLE <SCHEMA>.

© SAP AG

ADM515

6-9

Weitere Administrationsthemen: Unit Overview Diagram Weitere Administrationsthemen Thema 1: Prüfen der Datenbank Thema 2: Erstellen einer Datenbankinstanz Thema 3: Neuinitialisierung einer Datenbankinstanz Thema 4: Installation eines Patches (Releasewechsel) Thema 5: Migration zur MaxDB Thema 6: Hochverfügbarkeit Thema 7: MCOD

© SAP 2007 / Page 1

© SAP AG

ADM515

6-10

Anlegen einer Datenbankinstanz

Sie haben beim Anlegen einer Datenbankinstanz folgende Möglichkeiten: Anlegen einer neuen Instanz ohne Inhalt „ Anlegen einer Instanz auf Basis einer bestehenden Sicherung eines Quellsystems (z.B. für eine Systemkopie) „

Der Prozess kann per Skript automatisiert werden. siehe auch Hinweis 129352

© SAP 2007 / Page 1

Beispielskript für die Erstellung einer Systemkopie auf Basis einer Sicherung: y dbmcli -R -n db_create , <sid>adm,<password> y dbmcli -d SX1 -u , -n -i scriptfile1 y dbmcli -d SX1 -u , -n -uUTL -c -i scriptfile2 „ Skriptfile1 (Volumes entsprechend Quellsystem anpassen): param_startsession param_init OLTP param_put LOG_MIRRORED YES param_checkall EXTENDED param_commitsession param_addvolume 1 DATA F 10000 param_addvolume 1 LOG F 2500 param_addvolume 1 MLOG F 2500 db_admin „ Scriptfile2: util_execute db_activate <sysdba_user>,<sysdba_password> RECOVER load_systab -u <sysdba_user>,<sysdba_password> -ud <domain_password> backup_media_put “Medienname" ”Datei mit Pfad" FILE DATA 0 8 NO NO "“ backup_start “Medienname” DATA db_restart „ Standard-Benutzernamen in SAP-Umfeld Standard-Kennwörter control control <sysdba_user> superdba <sysdba_password> admin <domin_user> domain <domain_password> domain „

© SAP AG

ADM515

6-11

Tracen von DBM Kommandos in der Console

© SAP 2007 / Page 1

„

„ „ „

In den Preferences vom Database Studio “Window Ö Preferences” kann generell eine Konsole für die Ausgabe von Kommandos eingeschaltet werden. Anschließend muß diese Konsole dann noch angezeigt werden über “Window Ö Show View Ö Other… ”. Dies könnte eine große Hilfe bei der Entwicklung von dbmcli-Scripten zur Automatisierung von wiederkehrenden Aufgaben sein. Mit dieser Funktion können leicht Importdateien erstellt werden, die dann später über die Option „– i“ in das dbmcli geladen und ausgeführt werden können. Im Konsolenfenster stehen oben rechts noch mehr Funktionen zur Verfügung.

© SAP AG

ADM515

6-12

Instanz anlegen – Einstieg

© SAP 2008

Mit dem Kontextmenü des Servers -> Create Database... erreichen Sie den Wizard. „ Bitte wählen Sie die Option Create a new database in advanced mode aus, bei dem Sie alle Optionen uneingeschränkt definieren können. „ Mit der Option Create a new database haben Sie nur wenige Möglichkeiten, die für den SAPBereich richtigen User und Verzeichnisbereiche usw. zu ändern. „

„

Wichtig: Im SAP-Umfeld ist die Installation des SAP Netweaver zusammen mit MaxDB anders konzipiert als zusammen mit anderen Datenbanken. y Mit MaxDB wird die Datenbankinstallation innerhalb der SAP Netweaver Installation durch den SAPINST ausgeführt und nicht im Vorraus, wie es bei anderen Datenbanken der Fall ist. y Daher ist es nicht notwendig, eine MaxDB-Datenbankinstanz vorher zu erstellen. y Der Grund ist darin zu suchen, daß MaxDB mittlerweile in vielen Produkten integriert ist und sich daher entsprechend wartungsarm installieren lässt.

© SAP AG

ADM515

6-13

Instanz anlegen – Serveranmeldung

Auf dem lokalen Datenbankserver Login Informationen frei lassen

© SAP 2008

Nur beim Anlegen der Datenbankinstanz auf einem entfernten Rechner müssen Sie den Rechnernamen, Benutzernamen und Kennwort angeben. „ Sollte eine Remote-Installation unvermeidbar sein, benötigt der Benutzer besondere Rechte: y Unix: root-Rechte y Windows: Eigenschaft “logon as a batch job” sowie Administratorenrechte. „

Wählen Sie, mit welcher Softwareversion die Datenbankinstanz angelegt werden soll. „ Im SAP-Umfeld wird immer pro Datenbankinstanz auch eine Softwareinstanz angelegt. Damit ist sichergestellt, dass jedes SAP-Systemohne Auswirkung auf andere Datenbankinstanzen auf eine neue Version umgestellt werden kann. y Wählen Sie daher genau die Softwareversion aus, die Sie für diese Datenbankinstanz installiert haben. (Zu Testzwecken ist es auch möglich, eine andere Softwareinstanz unter Beachtung der erläuterten Zusammenhänge zu nutzen.) y Es ist technisch möglich mehrere Datenbankinstanzen auf einer Softwareinstanz zu fahren, aber beim nächsten Datenbankupgrade durch das Tool SDBUPD wird es zu einem Problem: Das SDBUPD wird den Upgrade der unterliegenden Softwareinstanz verweigern, solange nicht wieder eine 1:1 Beziehung zwischen DB- und Software-Instanz hergestellt ist. Der Grund ist darin zu suchen, daß ein sicherer Betrieb der zweiten DB-Instanz nach dem Upgrade nicht zugesichert werden kann. y Einfachste Lösung ist, mit dbmcli ... db_drop oder im Database Studio im Kontextmenü der Datenbankinstanz -> Drop Database… die zusätzliche Instanz wieder zu löschen. „

© SAP AG

ADM515

6-14

Instanz anlegen – Datenbank Manager setzen

Default: control Default: control

© SAP 2008

Weitere Sonderfunktionen können im Folgeschritt eingestellt werden. Generell sind diese Funktionen dazu gedacht, die TCO von Kleinstdatenbanken zu senken. y Im SAP-Umfeld werden diese Funktionen noch nicht eingesetzt, da die Funktionen dort aufgrund der Datenbank- bzw. Tabellengrößen länger dauern und durch den Automatismus dann nicht auf Nachtstunden begrenzt werden können. „ Anschließend definieren Sie bitte den Administrationsbenutzer der Datenbank. Im SAP-Umfeld ist dies traditionsgemäß der CONTROL-User mit dem Paßwort CONTROL. „ Bei der Installation des SAP NetWeaver wird üblicherweise ein “Master”-Kennwort zu Beginn abgefragt und im Folgenden immer genutzt, wenn ein Kennwort gefragt ist. Sollte dieses Paßwort auch hier verwand werden, dieses angeben. „

© SAP AG

ADM515

6-15

Instanz anlegen – Initiale Parameter

© SAP 2007 / Page 1

Bei der Parameterinitialisierung haben Sie folgende Optionen: y Initialisierung eines neuen Parametersatzes mit Default-Werten (z.B. Testinstallation) y Kopie eines bestehenden Parametersatzes von einer anderen Datenbankinstanz (z.B. zweite Datenbankinstanz mit Vorlage) y Übernahme der Parameter aus einer Sicherung, die üblicherweise später wiederhergestellt werden soll. (z.B. Systemkopie von einem anderen Rechner) „ Bevor der letzte Schritt des Wizard ausgeführt und die Datenbankinstanz angelegt wird, sollten diese geänderten Pfade (mit dem neuen Instanznamen) auch in Ihrem Dateisystem angelegt sein. „ Während des Anlegens einer Datenbankinstanz können Sie Änderungen an den Parameterwerten vornehmen. „

© SAP AG

ADM515

6-16

Instanz anlegen – Kopierte Parameter

© SAP 2008

Achten Sie besonders bei Systemkopien und der Übernahme der Parameter aus dem Parametersatz in der Sicherungsdatei darauf, daß Sie die dort hinterlegten Pfadangaben (z.B. RunDirectoryPath, Pfade zu den Volumes usw.) anpassen. „ Bevor der letzte Schritt des Wizard ausgeführt und die Datenbankinstanz angelegt wird, sollten diese geänderten Pfade (mit dem neuen Instanznamen) auch in Ihrem Dateisystem angelegt sein. „ Während des Anlegens einer Datenbankinstanz können Sie Änderungen an den Parameterwerten vornehmen. „

© SAP AG

ADM515

6-17

Instanz anlegen – Parameter aus Sicherung

© SAP 2007 / Page 1

„

„ „

Bei der Übernahme der Parameter aus einer Sicherung, die üblicherweise später wiederhergestellt werden soll, muß natürlich zuerst die Sicherungsdatei(en) angeboten werden, um dort die Parameterinformationen zu entnehmen. Dieses Template kann später auch für die Wiederherstellung genutzt werden. Bitte darauf achten, daß bei der Verwendung von Page-Clusterung die Block Size auf ein Vielfaches der Clustergröße gestellt wird (1-fach, 2-fach oder ähnliches).

© SAP AG

ADM515

6-18

Instanz anlegen – Parameter anpassen

© SAP 2008

Achten Sie besonders bei Systemkopien und der Übernahme der Parameter aus dem Parametersatz in der Sicherungsdatei darauf, daß Sie die dort hinterlegten Pfadangaben (z.B. RunDirectoryPath, DiagnoseHistoryPath, Pfade zu den Volumes usw.) anpassen. „ Bevor der letzte Schritt des Wizards ausgeführt und die Datenbankinstanz angelegt wird, sollten diese geänderten Pfade (mit dem neuen Instanznamen) auch in Ihrem Dateisystem angelegt sein. „ Während des Anlegens einer Datenbankinstanz können Sie Änderungen an den Parameterwerten vornehmen. „

© SAP AG

ADM515

6-19

Instanz anlegen – Volumes und Pfade anpassen

© SAP 2008

Achten Sie besonders bei Systemkopien und der Übernahme der Parameter aus dem Parametersatz in der Sicherungsdatei darauf, daß Sie die dort hinterlegten Pfadangaben (z.B. RunDirectoryPath, Pfade zu den Volumes usw.) anpassen. „ Bevor der letzte Schritt des Wizards ausgeführt und die Datenbankinstanz angelegt wird, sollten diese geänderten Pfade (mit dem neuen Instanznamen) auch in Ihrem Dateisystem angelegt sein. „ Minimalausstattung einer Mini-Datenbankinstanz: y 50 MB Data y 20 MB Log „

© SAP AG

ADM515

6-20

Instanz anlegen – Leere Datenbank erzeugen und Abschluss

© SAP 2008

„

„ „ „

„ „ „

Mit diesem Prozessschritt wird eine Erstellung einer leeren Datenbankinstanz gewünscht und daher wählen Sie hier die erste Option. Der vorgegebene User für die SAP NetWeaver-Umgebung ist der SUPERDBA mit dem üblichen Paßwort ADMIN. Dieser Benutzer verwaltet später alle weiteren Datenbankbenutzer (SQL-Benutzer). Sie möchten keine Wiederherstellung einer Sicherung anschließend vornehmen. Schließlich gibt der Wizard noch eine Zusammenfassung aus und beginnt mit Start den eigentlichen Installationsprozess. Sie erkennen die verschiedenen Installationsschritte in dem Reiter Results: y Starten der Datenbankinstanz in ADMIN-Modus y Aktivierung der Instanz im ONLINE-Modus y Laden der Systemtabellen im ONLINE-Modus Diese Systemtabellen sind im Anschluß der einzige Inhalt der Datenbank. Bei der Erstellung dieser Systemtabellen werden auch Log-Informationen erzeugt, was zu der Vorbelegung (Füllung) in den Log-Volumes führt. Die Datenbank befindet sich nach dem Abschluß im Modus ONLINE

© SAP AG

ADM515

6-21

Instanz anlegen – für Daten aus Sicherung

Wählen Sie Create database for recovery, wenn Sie eine Systemkopie erstellen möchten

© SAP 2008

„

„

„ „ „

Wählen Sie Create Instance for recovery, wenn Sie eine Datenbankinstanz auf Basis einer Sicherung erstellen möchten (Systemkopie). y Wenn Sie stattdessen die erste Option (Create and start instance) wählen, dann erhalten Sie nach dem Einspielen der Sicherung aus dem Quellsystem beim Versuch, die so erstellte kopierte Instanz zu starten, die Fehlermeldung –8003 (Log- und Datenbereich müssen kompatibel sein). y Sollte dieser Fehler auftreten, müssen Sie die fehlerhafte Datenbankinstanz noch einmal initialisieren. Aus dem Reiter Results erkennen Sie, daß die Datenbank zwar angelegt und der Datenbankkern gestartet wird (bis Modus ADMIN), aber es erfolgt keine Aktivierung der Datenbankinstanz und damit ist es im Anschluss möglich, Sicherungen wiederherzustellen. Für große Datenbanken kann das Anlegen der Volumes in Abhängigkeit der Hardware einige Zeit in Anspruch nehmen. Nach der Initialisierung wird im Wizard der Wiederherstellungprozess über den Button Recovery automatisch gestartet. Die Datenbank befindet sich in dem Modus ADMIN

© SAP AG

ADM515

6-22

Instanz anlegen – Sicherung wiederherstellen

© SAP 2008

„ „ „ „ „ „ „

Die Sicherungen werden im Betriebszustand ADMIN importiert. Sollte die DB hier schon im Zustand ONLINE sein, muß vor dem Start der Wiederherstellung noch einmal initialisiert werden (siehe nächster Abschnitt), bis der Zustand ONLINE hier nicht auftritt. Es gibt die üblichen Optionen für die Wiederherstellung. In diesem Fall steht nur eine Wiederherstellung aus einem Medium zur Verfügung. Wählen Sie das Template aus oder legen ein neues Template an. Der Wizard wird dann die Label-Informationen des Medium hinter dem Template auslesen und präsentieren. Mit Start kann die Wiederherstellung gestartet und das Ergebnis im Reiter Results kontrolliert werden. Es folgten die schon im Kapitel “Backup und Recovery” vorgestellten Prozesse.

© SAP AG

ADM515

6-23

Weitere Administrationsthemen: Übersichtsdiagramm Weitere Administrationsthemen Thema 1: Prüfen der Datenbank Thema 2: Erstellen einer Datenbankinstanz Thema 3: Neuinitialisierung einer Datenbankinstanz Thema 4: Installation eines Patches (Releasewechsel) Thema 5: Migration zur MaxDB Thema 6: Hochverfügbarkeit Thema 7: MCOD

© SAP 2007 / Page 1

„

Siehe auch SAP Hinweis 1014782 (FAQ: MaxDB Systemkopie)

© SAP AG

ADM515

6-24

Neuinitialisierung – Einstieg

© SAP 2007 / Page 1

„

Bei einem bereits existierenden Datenbankinstanznamen versichert sich der Wizard noch einmal, daß Sie die Instanz auch wirklich reinitialisieren möchten. Alle derzeit bestehenden Daten in der Datenbankinstanz werden verloren gehen.

© SAP AG

ADM515

6-25

Neuinitialisierung – Parameter anpassen

© SAP 2008

In diesem Schritt haben Sie ebenfalls die Möglichkeit, die Parameter- und Volume-Konfiguration komplett umzustellen. „ Typische Anwendung ist hier eine Reduktion der Anzahl und Vergrößerung der Volumes, da die Anzahl der zu administrierenden Objekte einfach zu groß geworden ist. „ Auch aus Performancegründen kann es empfohlen sein, diese Konfigurationsänderungen durchzuführen. „

Wenn die Datenbank zu klein angelegt wird, erhalten Sie einen Fehler –2008 (Volume zu klein) bei der späteren Installation der Datenbankinstanz. „ Die Standard-Verzeichnisstruktur der MaxDB im SAP-Umfeld wird im Hinweis 327578 erläutert. „

Bei der Option zur Übernahme der Parameter aus einer Datensicherung können Sie sowohl einzelne Sicherungsmedien als auch Gruppen paralleler Sicherungsmedien angeben. „ Der Parametersatz ist sowohl auf einzelnen Sicherungsmedien als auch jeweils auf allen Medien einer Mediengruppe vorhanden. „ Daher muss immer ein einzelnes Medium und nicht die Mediengruppe ausgewählt werden. „

© SAP AG

ADM515

6-26

Neuinitialisierung – Volumes ändern

© SAP 2008

Nur in dieser Phase eines Datenbanklebens der MaxDB ist es möglich, die Größe von bestehenden Log-Volumes zu ändern. Diese Änderung besteht dann so lange bis wieder im Rahmen einer Initialisierung dieser Schritt erreicht wird und hier Änderungen vorgenommen werden können. „ Im Bereich der Daten-Volumes ist es auch im späteren Online-Betrieb möglich, die Größe der Daten-Volumes indirekt zu ändern (neues Volume anlegen, altes Volume ausgliedern) „ Bei Systemkopien, besonders auf dem gleichen Datenbankserver, achten Sie BITTE peinlichst auf die richtigen Pfadangaben, so daß später nicht ein Satz von Volumes von zwei Datenbanken genutzt wird !! Gleiches trifft auch zu, wenn entfernte Platten auf beiden Servern gemountet werden. „

© SAP AG

ADM515

6-27

Neuinitialisierung – Vorbereitung für Wiederherstellung

© SAP 2008

Da hier ein Recovery in den meisten Fällen folgen soll, ist die zweite Option (Create database for recovery) meist die richtige Wahl. „ Das Initialisieren ist meist recht schnell geschehen, da die eigentliche Arbeit des Formatierens von Log- und Vorbereiten der Daten-Volumes erst später kurz vor der eigentlichen Wiederherstellung passiert. Im Reiter Results erkennen Sie auch nur einen Eintrag für das Starten des Datenbankkerns. „ Mit Recovery wird dann der übliche Wiederherstellungsprozess mit den im letzten Kapitel bereits vorgestellten Optionen durchgeführt. „

© SAP AG

ADM515

6-28

Wiederherstellung mit Einzelmedien Vollsicherung

© SAP 2007 / Page 1

„ „

„ „ „ „

Nach der Initialisierung wird der Recovery Wizard automatisch gestartet. In der Situation, daß die aktuelle Datenbankinstanz auf dem gleichen Datenbankserver nur neu aufgesetzt werden soll, können auch die Optionen Recover last backup und Recover specified backup from history gewählt werden. Bei der üblichen Systemkopie von einem Datenbankserver zu einem anderen wird nur die Option Recover a medium sinvoll sein. In diesem Schritt muß auch die Entscheidung über eine Point-In-Time-Wiederherstellung getroffen werden und bis zu welchem Zeitpunkt diese Wiederherstellung laufen soll. Anschließend im nächsten Schritt muß ein Template erzeugt werden, hinter dem die Vollsicherung zu finden ist. Nach der üblichen Zusammenfassung kann der erste Schritt der Wiederherstellung gestartet werden.

© SAP AG

ADM515

6-29

Wiederherstellung mit Einzelmedien – Inkrementelle Sicherung

Weitere Sicherungen

keine weiteren Sicherungen

© SAP 2008

Nach erfolgreicher Wiederherstellung der Vollsicherung, gibt es eine mögliche Stolperfalle. Der Restart-Button ist hier sehr verführerisch, er sollte aber nur angewählt werden, wenn keine weiteren inkrementellen oder Log-Sicherungen wiederhergestellt werden sollen. „ Wenn weitere Sicherungen vorhanden sind, muß der Zyklus aus » Medium anlegen und anschließendes Wiederherstellen der Sicherung « solange durchgeführt werden, bis alle Sicherungsquellen bereitgestellt und abgearbeitet sind, wie dargestellt. „ Bei jedem der Restart-Buttons kann dieser Zyklus beendet werden und die Datenbank mit dem Stand aus den bis dahin verwendeten Sicherungen hochgefahren werden. „

© SAP AG

ADM515

6-30

Wiederherstellung mit Einzelmedien – Log-Sicherung

© SAP 2008

Nach Definition des Log-Medium mit den Dateien des Quellsystems kann die LogWiederherstellung beginnen. „ Bitte spezifizieren Sie die Versionsnummer der Versionsdateien mit der Sie starten wollen oder müssen. „ Sollten Sie sich unsicher sein, mit welchen Sie beginnen müssen, nehmen Sie einfach die erste Versionsnummer, die Sie in dem Verzeichnis finden. Der DB-Kern wird die überflüssigen Dateien einfach überspringen, wie Sie auch in der Folgefolie erkennen können. „

© SAP AG

ADM515

6-31

Wiederherstellung mit Einzelmedien – Abschlussoptionen

Option 1

Option 2

© SAP 2008

„ „

„ „

„

„

Zu dem in diesem Beispiel als Startpunkt verwendeten Vollsicherung DATA3 passen zeitgemäß auch die inkrementelle Sicherung DEV_INC6 und die Log-Sicherungen ab DEV_log.011 und folgende. Um sicher zu gehen, daß alle Log-Informatioen zu allen offenen Transaktionen bzw. deren Startpunkte dem Wiederherstellungsprozess vorliegen, ist es angebracht, ein oder mehrere ältere Log-Sicherungen anzubieten. In diesem Falle liegen alle Log-Sicherungen seit 001 in dem Verzeichnis bereit, so daß mit der LogSicherung DEV_log.001 begonnen werden kann. Der Wiederherstellungsprozess erhöht die laufende Versionsnummmer so lange und versucht die entsprechende Log-Sicherung zu finden, bis ein Lesefehler auftritt, also die Datei nicht existiert oder fehlerhaft ist. Hier in dem Beispiel passiert dies mit der Datei DEV_log.014, die in dem Verzeichnis nicht existiert (siehe auch Fehlermeldung -3004). Dann gibt das Database Studio die Option, ein weiteres Verzeichnis mit fortführenden LogSicherungen anzugeben (Option 1), oder die Datenbankinstanz zu starten (Option 3 auf der Folgefolie). Auch bleibt die Möglichkeit (Option 2), den Wiederherstellungprozess hier über Cancel zu beenden und eine fortführende Log-Wiederherstellung zu einem späteren Zeitpunkt wieder aufzusetzen. Hier ist es auch erlaubt die Datenbank in den Modus OFFLINE zu fahren. Aber sobald die Instanz in den Modus ONLINE kommt, gibt es keine weitere Möglichkeit die Log-Wiederherstellung fortzuführen. Dieses ist eine manuelle Lösung eines LogShippings.

© SAP AG

ADM515

6-32

Wiederherstellung mit Einzelmedien Abschlussoptionen

Option 3

© SAP 2008

„ „

„ „ „

Hier die Option 3, die Datenbank in den Modus ONLINE zu starten. Im Ergebnisreiter Results sind die Rückgabewerte erkennbar, die die einzelnen Sicherungsdateien des letzten Schritts ergeben haben. Mit y -7075 wurden die Log-Sicherungen übersprungen und mit y -8020 nach erfolgreicher Abarbeitung die nächste Logdatei angefordert. Mit dem Wechsel in den Modus ONLINE ist die manuelle Wiederherstellung abgeschlossen. Bitte nicht vergessen: Es muß im Anschluß durch eine Vollsicherung ein Startpunkt für eine neue Sicherungshistorie gesetzt werden. Neuerdings gibt es mit externen Filesystem-Snapshots die Möglichkeit der Datenbank mitzuteilen, daß damit die Wiederherstellbarkeit gesichert ist und ein HISTLOST nicht in die Sicherungshistorie eingetragen werden muß.

© SAP AG

ADM515

6-33

Weitere Administrationsthemen: Übersichtsdiagramm Weitere Administrationsthemen Thema 1: Prüfen der Datenbank Thema 2: Erstellen einer Datenbankinstanz Thema 3: Neuinitialisierung einer Datenbankinstanz Thema 4: Installation eines Patches (Releasewechsel) Thema 5: Migration zur MaxDB Thema 6: Hochverfügbarkeit Thema 7: MCOD

© SAP 2007 / Page 1

„

Siehe auch SAP Hinweis 1020175 (FAQ: MaxDB Installation/Upgrade und Patch einspielen)

© SAP AG

ADM515

6-34

Installation eines Patches

Patches werden über den SAP Service Marketplace unter http://service.sap.com/patches Ö Database vendors Ö SAP DB & MaxDB bereitgestellt Üblicherweise führen neue Servicepacks auch neue Funktionen ein, während Patches nur Fehlerbehebungen enthalten. Patches werden nur innerhalb einer Versionen (7.7.04, 7.7.06 usw.) angeboten. Mit dem Einspielen eines Patches wird immer die gesamte Software ausgetauscht. Die Installation des Patch wird mit dem Tool SDBUPD ausgeführt. Nur in Situationen in denen die Datenbank nicht gestartet werden kann, wird das Tool SDBINST verwendet, da SDBUPD eine funktionierende Datenbank voraussetzt. „

Bitte bedenken, daß SDBUPD noch Nacharbeiten ausführt, die der SDBINST nicht ausführen kann (z.B. Laden der Systemtabellen)

© SAP 2007 / Page 1

„

Bitte dringend beachten, daß der SDBINST eine Untermenge des Funktionsumfangs des SDBUPD darstellt. Wenn also ein Patch mit SDBINST installiert wird, müssen unbedingt die Aufgaben manuell erfolgen (Laden der Systemtabellen etc.), die der SDBUPD sonst automatisch durchführt. Daher bitte so weit wie möglich den SDBUPD hier zum Patchen verwenden.

© SAP AG

ADM515

6-35

Releasestrategie

Der Releasewechsel der MaxDB (ab 7.5) wird in Upgrade-Leitfäden erläutert, die weitergehende Hinweise zu bekannten Ergänzungen enthalten. 7.7.04 B29 Mit den ersten beiden Ziffern werden Releases definiert. 7.7.04 B29 Die dritte Zahl stellt das ServicePack dar, mit dem neue Funktionen eingeführt werden.

Patch ServicePack Releasewechsel

7.5.0 B51

7.6.00 B36

7.6.03 B15 7.6.05 B10

7.7.01 B20 7.7.02 B36 7.7.03 B25

7.7.04 B29 Mit der Build-Nummer werden nur Fehlerbehebungen durchgeführt.

7.7.04 B20

Einige mögliche Releasewechselpfade sind hier dargestellt

7.7.04 B30

7.7.06 B06

7.7.06 B15

© SAP 2008

Üblicherweise werden gewisse Minimalversionen der MaxDB definiert, mit denen man den Releasewechsel durchführen kann. „ Bitte beachten Sie dazu den Leitfaden zum Releasewechsel, erhältlich auf dem SAP Service Marketplace. „

© SAP AG

ADM515

6-36

Werkzeuge rund um die Installation

Installationswerkzeug sdbinst „

Installationspakete können in unterschiedlichem Umfang installiert werden (Client, Server, Precompiler, Base usw.)

Update-Werkzeug sdbupd „

wird auch für die Durchführung von Releasewechseln (z.B. Version 7.6 → Version 7.7) und Installation von Patches eingesetzt

Installationsregistrierung „

Jede Installation über sdbinst und sdbupd wird in der Installationregistrierung festgehalten.

Wichtig: Installationen (z.B. Patches) müssen ordnungsgemäß abgeschlossen werden, bevor eine neue Installation begonnen werden kann. „ Deinstallationsroutine mit sdbuninst „

Installationsverifikation mit sdbverify „ Einsicht in Installationsregistrierungen mit sdbregview „

© SAP 2008

„

Das Tool sdbregview ist über den Pfad erreichbar

„

Aufruf des sdbuninst: sdbuninst –package “<Paketname mit richtiger Groß-/Kleinschreibung>”

„

Verzeichnisse:

„

Logdateien der Installation: \sapdb\data\wrk

„

Installationsregistrierung: \sapdb\data\config\install

© SAP AG

ADM515

6-37

Installation & Deinstallation

Durchführung der Installation mit sdbinst Option –help listet wertvolle Optionen Installationslogs werden in /wrk geschrieben

Deinstallation der MaxDB-Software erfolgt mit sdbuninst Bitte nicht die Verzeichnisse der MaxDB mit Betriebssystemmitteln löschen!

© SAP 2007 / Page 1

„ „

Optionen des SDBINST: sdbinst –force_extract Optionen des SDBUNINST: sdbuninst [-h|--help] | [-v|--version] | [-l|--list] | -all | -package <package name> [-package_dir <package directory>] [-autoresolve] -h --help show this -v --version show version -l --list list installed packages -package <package name> uninstall a package with such name -package_dir <package directory> uninstall package <package name> installed in <package directory> -all uninstall all registered MaxDB packages -autoresolve uninstall package <package name> and all dependent packages

„

Sollten Programme oder Verzeichnisse gelöscht worden sein, bitte den gleichen Patch an die gleiche Stelle wieder installieren und anschließend eine offizielle Deinstallation durchführen.

© SAP AG

ADM515

6-38

Typische Fehler während der Installation

Beispiele (bitte auch STDERR beachten): „

Übersehene, weiterhin aktive MaxDB-Komponenten

„

Lokales SAP-System ist per dbmrfc noch mit einer MaxDB-Instanz (lokal oder remote) verbunden

„

Downgrade wird versucht

© SAP 2008

Bitte alle Komponenten der MaxDB während einer Installation oder eines Updates beenden, damit diese ausführbaren Dateien auch ausgetauscht werden können. „ Unter Windows müssen alle MaxDB-relevanten Services (außer X-Server) beendet werden: SAPP DB: SAPDBXIE (SAP DB WWW) Unter Unix muß auch der X-Server beendet werden. „ Mit der Option –force_extract für SDBINST und SDBUPD ist es zwar möglich, auch aktuell laufende Programme auszutauschen und es funktioniert auch in vielen Fällen, aber es kann hier zu Problemen, wie Abstürzen dieser Komponenten kommen, wenn z.B. noch laufende Programme Bibliotheken nachladen müssen und diese dann nicht mehr in der passenden Version vorfinden. „ Downgrade eines Patches wird nicht unterstützt. „

© SAP AG

ADM515

6-39

Überprüfung der MaxDB Installation: sdbverify

...

© SAP 2007 / Page 1

„

Optionen des SDBVERIFY: usage: sdbverify [-h|--help] [-v|--version] [-F|--file ][-set_corrupted_invalid] -h –help show this -v –version show version -F --file check installed file --set_corrupted_invalid set inconsistent packages to invalid

„

Defekte Dateien austauschen : y Pakete die Inkonsistenzen laut sdbverify enthalten mit der Option -set_corrupted_invalid auf invalid setzen y Mit sdbinst den gleichen MaxDB-Patchlevel noch einmal installieren und damit diese Pakete austauschen lassen.

© SAP AG

ADM515

6-40

MaxDB Client-Installation

Kann mit dem interaktiven Modus des SDBINST ausgeführt werden. Bitte Option 1 wählen (Client) Anschließend werden einige weitere Eingaben bzgl. Autorisation (control user) abgefragt. Unter Custom gibt es dann die Möglichkeit weitere Komponenten individuell nachzuinstallieren.

© SAP 2008

„

Siehe auch SAP Hinweis 822271 (FAQ: SAP MaxDB Client-Software)

© SAP AG

ADM515

6-41

Zusammenhang: Datenbankinstanz – Softwareinstanz

DatenbankInstanz(en) DatenbankSoftware Arrangement funktioniert? Konsequenzen für Software Updates

QAS

DEV

QAS

/sapdb/DEV/db

/sapdb/QAS/db

missing

Ja

/sapdb/QAS/db

Ja

SDBINST, SDBUPD funktionieren

SDBINST, SDBUPD: Prozeß bricht ab

© SAP 2007 / Page 1

Multiple Datenbankinstanzen auf einer Datenbank-Softwareinstallation sind technisch möglich und funktionieren auch solange keine Änderungen der Software durchgeführt werden soll. „ Bei einem Wechsel der Software kommt es aber mit den Installations- und Update-Tools zu Problemen. Die Tools können selber nicht beurteilen, ob nach dem Update der Datenbank auch alle Anwendungen auf den Datenbankinstanzen für diese Version freigegeben sind. „ Daher empfiehlt die SAP für jede Anwendung eine individuelle Softwareinstallation der Datenbank zu verwenden, also eine 1:1-Beziehung zwischen Datenbankinstanz und Softwareinstallation besteht. „ Sollte so ein 1:n-Fall bei dem Update der Datenbanksoftware auffallen, bleiben nur die Optionen y Löschen der unwichtigeren Datenbankinstanz um die 1:1-Beziehung wieder herzustellen y Oder Sicherung der zweiten Instanz und Neuaufbau dieser Instanz in Form einer Systemkopie mit einer individuellen Softwareinstallation. y Oder zweite Datenbankinstanz von der Softwareinstallation trennen (db_drop WITHOUTFILES), dann eine individuelle Datenbanksoftwareinstallation nur für diese Instanz erstellen und die besagte Datenbankinstanz damit wieder verknüpfen (db_create) „

© SAP AG

ADM515

6-42

Weitere Administrationsthemen: Übersichtsdiagramm Weitere Administrationsthemen Thema 1: Prüfen der Datenbank Thema 2: Erstellen einer Datenbankinstanz Thema 3: Neuinitialisierung einer Datenbankinstanz Thema 4: Installation eines Patches (Releasewechsel) Thema 5: Migration zur MaxDB Thema 6: Hochverfügbarkeit Thema 7: MCOD

© SAP 2007 / Page 1

„

Weitere aktuelle Infos zum Thema Migration im SAP-Hinweis 1007129 (FAQ: DB Migration mit Ziel MaxDB).

© SAP AG

ADM515

6-43

Migration zur MaxDB

Generell „

Migrationsservice verfügbar „ Zusätzliches Consulting wird benötigt (zertifiziert für Migration)

„

MaxDB Migration Safeguarding „ Service wird durch den Active Global Support angeboten „

Besteht aus Performanceanalyse, Optimierung und Training

Datenladen mit R3load „

IO Buffer Cache während Import maximieren

„

Indexerzeugung frühzeitig auf kleinen Tabellen beginnen Parameter EnableMultipleServerTaskUKT verwenden um Servertasks auf mehr UKTs zu verteilen „ Das Laden der Datentabellen schon in geclusterte Tabellen vornehmen „

„

Tabellenpartitionierung auf Primärschlüsselbasis um sehr große Tabellen zu beschleunigen „ Exportprozess muß auf der Quelldatenbank geändert werden „

Späterer Import kann mit vielen kleinen statt wenigen großen Imports begonnen werden

© SAP 2008

„

Für das Laden der Daten in geclusterte Tabellen auf der MaxDB muß die Datei DDLADA.TPL angepasst werden und das CREATE TABLE Statement dort um die Funktion CLUSTER PRIMARY KEY erweitert werden.

© SAP AG

ADM515

6-44

Optionen der Migration zur MaxDB

Besonderheit: Little Endian/Big Endian „ „

Big Endian (z.B. RISC)

Beschreibt die Reihenfolge der Bytes im Hauptspeicher oder in Dateien

15..........8 7..........0

8 Bit

CPU Registery MSB

Typische Vertreter: Motorola 680x0 Sun SPARC „ Little Endian Intel x86 AMD 64 „ switchable Endian PowerPC Intel Itanium

8 Bit

LSB

„ Big Endian

Speicher-Layout

Speicheradresse $0 ...... $1 ...... Hexadezimales Beispiel für dez. 65534 im Hauptspeicher

Konsequenzen für MaxDB „

Migration per Backup & Recovery wenn Endian gleich bleibt

„

Sehr schneller Plattformwechsel z.B. zwischen MS Windows und Linux oder zwischen RISC-Unix möglich Ein Ausschnitt aus der verfügbaren Matrix ist in Hinweis 129352 verfügbar, die vollständige Matrix ist unter help.sap.com zu finden

„

Besonderheit: liveCache „

MSB LSB

Aufgrund der Objekte im liveCache ist üblicherweise keine Migration durch Backup & Recovery möglich. Bitte beachten Sie die Leitfäden und Best Practices.

FF

FE

Little Endian (z.B. Intel x86) 15..........8 7..........0

8 Bit

CPU Registery

8 Bit

MSB LSB

Speicher-Layout

LSB MSB

Speicheradresse

$0 ...... $1 ......

Hexadezimales Beispiel für dez. 65534 im Hauptspeicher:

FE

FF

© SAP 2008

„

Weitere Informationen zu Little Endian/Big Endian in SAP-Hinweis 552464.

© SAP AG

ADM515

6-45

Migration von Content Servern

Ab MaxDB 7.7.04 B30 (aber auch 7.6.05 B11) ist es möglich, Content Server mit dem MaxDB Loader ohne zeitintensive Unterstützung des ABAP direkt zwischen ASCII und UNICODE „ sowie zwischen Little Endian und Big Endian „

zu migrieren

© SAP 2008

© SAP AG

ADM515

6-46

Weitere Administrationsthemen: Übersichtsdiagramm Weitere Administrationsthemen Thema 1: Prüfen der Datenbank Thema 2: Erstellen einer Datenbankinstanz Thema 3: Neuinitialisierung einer Datenbankinstanz Thema 4: Installation eines Patches (Releasewechsel) Thema 5: Migration zur MaxDB Thema 6: Hochverfügbarkeit

© SAP 2007 / Page 1

„

siehe auch SAP Hinweis 952783 (FAQ: MaxDB Hochverfügbarkeit)

© SAP AG

ADM515

6-47

Hochverfügbarkeitslösungen für MaxDB (1)

Schattendatenbank „

Transfer der Log-Einträge von der produktiven Datenbankinstanz zu einer bereitstehenden Schatteninstanz

Im Fehlerfall werden die noch zur Verfügung stehenden Log-Einträge bereitgestellt und die Schatteninstanz produktiv genutzt. „ Verfügbare Tools: „

„

Recovery

primary

DATA

LOG

Saved Log File(s)

LOG

DATA

DBShadow von Libelle (www.libelle.com)

© SAP 2008

„ „ „ „ „

Ein anderer, für diese Lösung im Markt bekannter Name ist LogShipping Verschiedene Lösungen sind je nach den speziellen Anwendungsbedürfnissen möglich. Weitergehende Informationen zur Schattendatenbank finden Sie im Help-Portal http://help.sap.com. Diese Lösung ist mit datenbankeigenen Mittel durch Entwicklung von eigenen Skripten realisierbar. Mit vielen manuellen Schritten ist es sogar mit dem Database Studio möglich. Fertige Lösungen bieten dann den Komfort der Wartung und Pflege sowie Anpassung an neuere Datenbankversionen durch den Anbieter.

© SAP AG

ADM515

6-48

Hochverfügbarkeitslösungen für MaxDB (2)

Cluster-Technologie für Ausfallsicherheit „

Zwei Server können wechselseitig die Kontrolle über Plattenbereiche der Datenbankinstanz übernehmen.

ABAP Application

primary

Im Fehlerfall übernimmt ein zweiter Server die Datenbankfunktionen. „ UNIX: Skripte der Cluster-Agenten werden von den Betriebssystemherstellern angeboten. „

„

Service name

backup

cluster

„

AIX:

HACMP

„

HP-UX:

Service Guard

„

SunOs:

Sun Cluster

„

Linux:

Steeleye

„

Implementierungstips: SAP Hinweis 803452

DATA

LOG Area

Microsoft Windows: direkte Unterstützung durch MaxDB (Hinweise 319835, 576063)

© SAP 2007 / Page 1

„

Verschiedene Lösungen sind je nach den speziellen Anwendungsbedürfnissen möglich.

© SAP AG

ADM515

6-49

Hochverfügbarkeitslösungen für MaxDB (3)

Snapshot-Technologie „

In festgelegten Zeitabständen werden Datenbestände von einem Plattenbereich auf andere Plattenbereiche/Server kopiert (Snapshot).

„

Im Fehlerfall kann ein zweiter Server auf Basis des letzten oder eines der letzten Snapshots gestartet werden.

„

Dabei werden Log-Einträge ab der zum letzten Snapshot-Zeitpunkt vorhandenen Log-Information eingespielt.

„

MaxDB

DATA

LOG

Snapshot 3

Snapshot 3

Viele Storagesysteme am Markt bieten diese Technologie

© SAP 2007 / Page 1

„ „

„

„

„

Weitere Infos zur Verwendung von Storage-Systemen mit MaxDB im SAP-Hinweis 912905 (FAQ: Storage Systeme im Einsatz mit MaxDB) Nicht alle Storagesysteme bieten bei der Verwendung von mehreren Daten-Volumes eine zeitliche Schreibkonsistenz auf allen Platten/Dateien an, wenn alle Daten-Volumes in einer SnapshotGruppe enthalten sind. Bitte lassen Sie sich dieses von dem Storage-Systemanbieter garantieren. Sollte dieses tatsächlich nicht der Fall sein, müßte zum Anlegen eines betriebssystemseitigen Snapshot auf dem Storagesystem der Datenbankbetrieb kurzzeitig gestoppt werden. Dieses kann mit dem Anhalten des Logwriters einfach erreicht werden, der mit dem Kommando dbmcli –U c db_execute suspend logwriter kurzfristig angehalten und mit dbmli –U c db_execute resume logwriter wieder aktiviert werden kann. Diese kurzfristige Deaktivierung des Schreibens in die Volumes (Daten und Log) hat sonst keine Konsequenzen z.B. auf die Sicherungshistorie. Durch das Deaktivieren des Logwriters wird auch das Schreiben des Savepoints auf die Daten-Volumes indirekt verhindert und die DB damit quasi in einen ReadOnly-Modus gehalten. Weiteres in SAPHinweis 616814. Auf Basis dieser Snapshots ist es auch möglich, nach dem Wiederherstellen eines Snapshots auf dem Storagesystem die MaxDB-Instanz anschließend in den ADMIN Modus zu fahren und anschließend mit Logsicherungen bis zu dem gewünschten Zeitpunkt vorzurollen. In zukünftigen Versionen der MaxDB können externe Filesystem-Snapshots auch in die Sicherungshistorie mit aufgenommen werden.

© SAP AG

ADM515

6-50

Hochverfügbarkeitslösungen für MaxDB (4) MaxDB

Split-Mirror-Technik Datenbestände werden durch Trennen gespiegelter Platten festgehalten. „ Im Fehlerfall kann ausgehend von den getrennten Spiegelplatten das Einspielen von Log-Einträgen durchgeführt werden. „ siehe auch Hinweis 371247 „

„

DATA

LOG

DATA

LOG

Eine Menge Lösungen sind hier in verschiedenen Ausprägungen verfügbar

MaxDB

© SAP 2008

Komfortable Lösung um auf einem ausgegliederten Mirror Sicherungen und weitere administrative Aktionen ausführen zu können, die den Produktivbetrieb in keinster Weise beeinträchtigen. „ Nachteil ist üblicherweise der doppelte bzw. dreifache Plattenplatzbedarf. „

© SAP AG

ADM515

6-51

Hochverfügbarkeitslösungen für MaxDB (5)

HotStandby-Technologie „

Kombination aus Cluster und LogShipping

„

Sehr schneller Umschaltvorgang üblicherweise unter 1 Minute, dabei benötigt das OS für Umschaltung bereits 40-50 Sekunden

„

MaxDB unterstützt den Umschaltvorgang und die Administration direkt per mitgelieferter Bibliothek (z.B. synchrones Anlegen von neuen Volumes für beiden Nodes)

„

Benötigt höherentwickelte Funktionen auf dem Storagesystem

„

Derzeit für folgende Storagesysteme angeboten „

IBM ESS

„

EMC

„

HP (in Vorbereitung)

Application RECONNECT

primary

backup

IP SWITCH

Cluster

After Images

Data

continous RESTART

DATA

LOG

DATA

Storage System © SAP 2007 / Page 1

Weitergehende Informationen zur HotStandby-Lösung finden Sie im Help-Portal http://help.sap.com oder im SAP-Hinweis 952783 (FAQ: MaxDB Hochverfügbarkeit). „ Neben der Bibliothek, die von der MaxDB-Entwicklung angeboten wird, bedarf es noch einer Unterstützung per Bibliothek von dem Storage-Partner. Damit werden die betriebssystemseitigen Umstellung beim Umschaltvorgang gesteuert. „ Für IBM ESS gibt es für das Betriebssystem AIX folgendes White Paper: y White paper: HotStandby for MaxDB/liveCache together with IBM ESS: „

http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP100442

© SAP AG

ADM515

6-52

Weitere Administrationsthemen: Übersichtsdiagramm Weitere Administrationsthemen Thema 1: Prüfen der Datenbank Thema 2: Erstellen einer Datenbankinstanz Thema 3: Neuinitialisierung einer Datenbankinstanz Thema 4: Installation eines Patches (Releasewechsel) Thema 5: Migration zur MaxDB Thema 6: Hochverfügbarkeit Thema 7: MCOD

© SAP 2007 / Page 1

© SAP AG

ADM515

6-53

MCOD: Multiple Components in One Database Beispiel: Systemname der Anwendung 1 : SC1 z.B. SAP SCM Systemname der Anwendung 2 : LVC z.B. liveCache …

Eine Datenbankinstanz enthält die Daten für mehrere Anwendungen Alle Anwendungen nutzen die Ressourcen der Datenbank gemeinsam

MaxDB Datenbank SID: SC1

Anwendungsbeispiel:

Daten für Anwendung 1 User/Schema: sapsc1

„

SCM/APO on One DB (nur für MaxDB verfügbar)

Daten für Anwendung 2 User/Schema: saplvc

© SAP 2008

Jede Installation einer Anwendung in die bestehende Datenbankinstanz erzeugt ein neues Schema (Datenbankbenutzer). Darin werden die Daten dieser Anwendung abgelegt. „ Die Datenbankinstanz trägt den Systemnamen der ersten Anwendung, die installiert wurde. „ Diese erste Anwendung muss nicht MCOD-fähig sein. „ Alle weiteren Anwendungen müssen MCOD-fähig sein. „

© SAP AG

ADM515

6-54

Weitere Administrationsthemen: Zusammenfassung

Sie können nun: „

Systemkopien mit MaxDB erstellen

Installationstools der MaxDB-Software nutzen „ die Hochverfügbarkeitslösungen aufzählen „

© SAP 2007 / Page 1

© SAP AG

ADM515

6-55

© SAP AG

ADM515

6-56

Übungen Kapitel: 5 Thema: Weitere Administrationstätigkeiten Am Ende dieser Übungen können Sie: • Eine Kopie einer bestehenden Datenbankinstanz erstellen und • die interne Struktur der Datenbank überprüfen lassen • Sie kennen die Vorgehensweise bei dem Installieren eines Datenbankpatches Bei der produktiven Nutzung einer Datenbank besteht immer wieder die Notwendigkeit, Datenbankinstanzen zu kopieren um dann mit den Kopien und den darin enthaltenen Daten Tests durchzuführen. Der Vorgang wird hier praktisch durchgeführt. 5-1

5-2

Überprüfung der Datenbank (Check Database Structure) 5-1-1

Starten Sie einen Check Database Structure-Lauf mit Hilfe des Database Studio für die gesamte Datenbank.

5-1-2

Nutzen Sie das dbmcli oder den SQL-Editor im Database Studio um über die Konsole ein Check Data auf eine einzelne Tabellen z.B. Tabelle FILLTABLE zu starten.

Erstellung einer Systemkopie Zu diesem Zwecke wurden schon einige Vorbereitungen im Filesystem und der Userverwaltung des Datenbankservers vorgenommen: Zu jeder Trainingsdatenbank sind jeweils zwei weitere Datenbankeinträge vorgesehen mit dem Namen z.B. T → Ta bzw. Tb sowie der entsprechende Administrationsuser taadm bzw. tbadm angelegt. Die Verzeichnisse sind neben den bisher genutzten INSTROOTs zu finden z.B. unter G:\sapdb\Ta\ oder G:\sapdb\Tb\. Bitte kontrollieren Sie die Existenz der Verzeichnisse für Ihre Trainingsdatenbank. 5-2-1

© SAP AG

Gehen Sie anhand der ausführlichen Beschreibung zur Installation einer Datenbankinstanz vor um eine Kopie der bestehenden Instanz T vorzunehmen. Da diese Installation mit einem Database Studio von einem entfernten Rechner durchgeführt wird, müssen Sie im ersten Step des Database Wizards den Datenbankserver (vom Referent mitgeteilt), Administrationsuser (z.B. taadm bzw. tbadm) und dessen Password (z.B. taadm bzw. tbadm) angeben.

ADM515

6-57

5-3

© SAP AG

5-2-2

Nachdem die Instanz mit dem Database Wizard aufgebaut wurde und sich im Admin Zustand befindet, können Sie dann eine der Datenvollsicherungen von der Quelldatenbank verwenden, um die neue Datenbank mit Initialdaten zu versorgen. Erzeugen Sie dafür bitte ein entsprechendes Medium für die notwendigen Sicherungsfiles (Voll-, inkrementelle und Log-Sicherungen), je nachdem wie Ihre Recoverystrategie aussieht. Am Ende des Recovery können Sie dann die Datenbank in den Zustand Online setzen.

5-2-3

Zum Abschluß erzeugen Sie dann auf der neuen Datenbankinstanz eine initiale Datenvollsicherung um damit einen Startpunkt für die weiteren Log-Sicherungen zu haben. Richten Sie dann auch die AutoLogFunktionalität wieder ein und laden zur Sicherheit noch einmal die Systemtabellen neu.

Referent: Vorführung der Installation eines Patches 5-3-1

Erläuterung der Vorbereitungen, z.B. welche Komponenten müssen beendet werden

5-3-2

Erläuterung der Nachbereitungen

ADM515

6-58

Lösungen Kapitel: 5 Thema: Weitere Administrationstätigkeiten

5-1

5-2

5-3

© SAP AG

Überprüfung der Datenbank (VERIFY) 5-1-1

Führen Sie im Kontextmenü Ihrer Datenbankinstanz den Menüpunkt → Check Database Structure… aus und kontrollieren anschließend die Diagnosedatei knlMsg auf Fehlermeldungen.

5-1-2

Vorgehen mit dbmcli: Ausführung z.B. des Kommandos dbmcli -U c –uSQL sap<sid>,sap sql_execute “check table SAP<SID>.FILLTABLE“. Vorgehen beim SQL-Editor im Database Studio: Setzen Sie bitte das SQLStatement check table SAP<SID>.FILLTABLE ab. Kontrollieren Sie anschließend erneut die Datei knlMsg auf evt. aufgetretene Fehler für den Ausführungszeitraum.

Erstellung einer Systemkopie 5-2-1

Das Vorgehen ist im Kapitel 4 ausführlich beschrieben. Auch die Möglichkeit der Automatisierung wird in den Notizen vorgestellt.

5-2-2

Das Vorgehen ist im Kapitel 4 ausfühlich beschrieben.

5-2-3

Das Vorgehen ist im Kapitel 4 ausfühlich beschrieben.

Referent: Vorführung der Installation eines Patches

ADM515

6-59

© SAP AG

ADM515

6-60

Performance-Tuning und Problemsituationen

Inhalt: Tabellen- und Indexstrukturen „ Monitoring MaxDB und Performanceoptimierung „

„

Fehlersituationen und deren Behebung

© SAP 2008

© SAP AG

ADM515

7-1

Performance-Tuning und Problemsituationen: Lernziele

Am Ende dieses Kapitels, können Sie: Fehlersituationen erkennen und beheben „ Die MaxDB Monitore zur Beurteilung der Performance bedienen „

© SAP 2008

© SAP AG

ADM515

7-2

Agenda I

1. Der erste Kontakt 1.1. 1.2. 1.3. 1.4. 1.5. 1.6.

3. MaxDB-Interna

Einführung Werkzeuge und Schnittstellen Architektur und Betriebszustände MaxDB und SAP NetWeaver Integration mit SAP NetWeaver Serverlandschaft der Schulung

3.1. 3.2. 3.3. 3.4. 3.5.

4. Datenbanksicherung und -wiederherstellung

2. MaxDB betreiben 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8.

Prozesse Sperren Speicherbereiche Plattenbereiche Logging

Überblick Database Studio Wichtige Informationsquellen im Database Studio Benutzer der MaxDB im SAP-Umfeld Plattenbereiche für Daten und Log Konfigurationsänderungen DBFULL und LOGFULL Situationen Parameter Übungswerkzeug

4.1. 4.2. 4.3. 4.4. 4.5. 4.6. 4.7. 4.8. 4.9.

Vollständige Datensicherung Inkrementelle Datensicherungen MaxDB Snapshots Log-Sicherungen Automatische Log-Sicherung Überprüfen der Sicherungen Sicherungsstrategie Externe Sicherungstools Wiederherstellungen

© SAP 2008

© SAP AG

ADM515

7-3

Agenda II

5.

Weitere Administrationsthemen 5.1. 5.2. 5.3. 5.4. 5.5. 5.6. 5.7.

7.

Prüfen der Datenbank Erstellen einer Datenbankinstanz Neuinitialisierung einer Datenbankinstanz Installation eines Patches (Releasewechsel) Migration zur MaxDB Hochverfügbarkeit MCOD

Ausblick auf MaxDB 7.8 7.1. 7.2. 7.3. 7.4. 7.5.

Übersicht Änderungen des Datenbankkerns Neue administrative Funktionen Setup und Infrastruktur Interface & User

6. Performance-Tuning und Problemsituationen 6.1. 6.2. 6.3. 6.4. 6.5. 6.6.

B*-Bäume Optimierung Monitore des SAP NetWeaver Vermeidbare Probleme Diagnosedateien und TraceMöglichkeiten Fehlerarten und deren Analyse

© SAP 2008

© SAP AG

ADM515

7-4

Tabellen und Indizes organisiert in B*-Bäumen

Index Index organisiert in B*Bäumen, Indexebene

Tabelle Logische Referenz (über Primärschlüssel) 2

1

2

3

3

1

3

2

1

Datensätze in Seiten, Blattebene

3

2

Index

Data

Tabellen sind logisch über relationale Daten verknüpft

Data

Navigation über logische Schlüssel © SAP 2008

Im Datenbankmanagementsystem der MaxDB werden die Daten in relationalen Tabellen abgelegt. Die Ablage und Organisation der Daten erfolgt mit Hilfe von B*-Baumstrukturen. Dabei ermöglicht der B*-Baum einen schnellen Zugriff auf die Daten. „ Die Struktur dieser Ablage ist in diesem Schaubild skizziert. y Die Tabellen bestehen jeweils aus Indexstrukturen, die aus dem Primärschlüssel aufgebaut werden und in B*-Bäumen liegen, als auch aus den sogenannen Blattseiten mit den abgelegten Daten. Die Ablage der Indexstrukturen erfolgt innerhalb der Tabellen und nicht in gesonderten Strukturen. „ Der Zugriff auf die Daten mit einer komplexen SQL-Anweisung wird in den Schritten 1 bis 3 beispielhaft im Überblick gezeigt. y Der Zugriff auf die Basistabelle erfolgt über den Primärschlüssel ohne die Zuhilfenahme außerhalb liegender Indizes. y Ein Zugriff über Sekundärindizes erfolgt zuerst auf den Index. Die sich aus den dort gefundenen Daten ergebenen Querverbindungen zur Basistabelle ziehen dann weitere Zugriffe auf diese Tabellen nach sich. y Die logische Referenz zwischen Sekundärindex und Basistabelle erfolgt über den Primärschlüssel. „ Diese Methode ermöglicht es, Tabellen und Indizes platzsparend zu speichern. Gleichzeitig ist der Zugriff über den Primärindex besonders schnell. „

© SAP AG

ADM515

7-5

Primärschlüssel und Sekundärschlüssel

Primärschlüssel Primärschlüssel wird auf dem Datenbaum angelegt „ Kein separater Primärschlüssel-Baum „

Primärschlüssel dient als Separator im B*-Baum „ Sätze in Tabellen sind in Schlüsselreihenfolge sortiert abgelegt „

Sekundärschlüssel (Index) „

Aufbau eines separaten Index-B*-Baumes

„

Sekundärschlüssel enthält keine physischen Adressen des Datenbaums, sondern logische Adressen in Form von Primärschlüsseln

© SAP 2008

© SAP AG

ADM515

7-6

Datenspeicherung im B*-Baum

CREATE TABLE Population ( CITY CHAR(40), COUNTRY CHAR(40), INHABITANTS CHAR(10), PRIMARY KEY (CITY) )

Aufbau des B*-Baums

entspricht einer Seite (8 KB)

Wurzelebene

N

Wurzelseite (root page) der Tabelle Population

Par

Ix

Indexebene

At

Me

Suche durch B*-Baum

...

N

...

Par

Indexeintrag: Wert (Separator) und Verknüpfung

...

Blattebene

Alger, Ankara, Algeria, Turkey, 4.4 Mio. 3.2 Mio.

...

Athens, Greece, 3 Mio.

...

Mexico City, Mexico, 18 Mio.

...

New York, USA, 16 Mio.

...

© SAP 2008

„ „ „

„ „

„

Der Aufbau bzw. Wachsum des B*-Baums erfolgt in entgegengesetzter Richtung zu der späteren Verwendung. Ausgegangen wird dabei von den Datenseiten, wobei der Datensatz mit dem kleinsten Wert im Primärindexfeld auch der erste Eintrag in der Datenseite ist. Diese Werte werden übertragen in die darüber liegende Indexseite auf der Indexebene. Dabei werden jeweils nur die Zeichen bis zur signifikanten Unterscheidung zum größten Datensatz der vorherigen Seite der Blattebene eingetragen. Daher können die Einträge der Indexebene und der Wurzelebene unterschiedliche Längen haben. Die Seiten auf den verschiedenen Ebenen sind untereinander verknüpft. Dagegen sind die einzelnen Ebenen untereinander nur durch die Anfänge der Indexketten bzw. Blattseitenketten verknüpft. Sobald die aktuelle Wurzelseite durch Indexeinträge gefüllt ist und eine weitere Seite zur Aufnahme der Indexinformationen benötigt wird, wandelt die Datenbank die derzeitige Wurzelseite in eine normale Indexseite um und erzeugt eine neue Wurzelseite in der Indexebene darüber. Es sind insgesamt sieben Ebenen möglich. Dies entspricht sechs Indexebenen und einer Wurzelebene mit einer Wurzelseite.

© SAP AG

ADM515

7-7

Nutzung des B*-Baums für Primärschlüssel

SELECT COUNTRY FROM POPULATION WHERE CITY=‘Athens‘ Wurzelebene

N

Durchlaufe Wurzelseite: Ist „Athen“ kleiner als ein Eintrag? Folge der zuletzt ermittelten Verknüpfung.

P

Indexebene

At

Me

...

N

...

Par

Ist „Athen“ < „Me“? Folge der letzten Verknüpfung.

...

Blattebene

Alger, Ankara, Algeria, Turkey, 4.4 Mio. 3.2 Mio.

...

Athens, Greece, 3 Mio.

...

Mexico City, Mexico, 18 Mio.

...

New York, USA, 16 Mio.

...

Durchsuche Seite zeigergesteuert nach Indexübereinstimmung und ermittele Wert für Spalte COUNTRY. © SAP 2008

„

Das Konzept des B*-Baumes lässt sich am Beispiel der obigen SQL-Anweisung „SELECT * FROM POPULATION WHERE...“ erklären:

y MaxDB ermittelt zuerst die Wurzelseite aus der Systemtabelle ROOTS. Dies ist die logische Seite auf der höchsten Wurzelebene, über die jeder Einstieg in die Tabelle erfolgt. y Auf dieser Seite wird verglichen, ob der Wert „Athen“ kleiner ist als die Einträge in der Wurzelseite sind. Sobald ein Eintrag in der Wurzelseite größer ist als der gesuchte Wert aus der WHERE-Bedingung, wird die letzte Zeigeradresse ausgewertet, welche auf eine Seite in der nächsttieferen Ebene zeigt. y Dieser Vorgang wiederholt sich, bis das System auf der untersten Ebene, der Blattebene, angekommen ist. Dort befindet sich der vollständige Inhalt der gesuchten Tabellenzeile. Diese Seite wird aber nicht komplett gelesen, sondern zeigergesteuert nach Indexübereinstimmungen gesucht und es wird direkt an die Stelle der Datenablage gesprungen. „ Für Tabellenfelder vom Typ LONG (Strings variabler Länge) befindet sich auf Blattebene ein Zeiger auf einen weiteren B*-Baum, in dem die dynamisch wachsende Feldinformation gespeichert ist.

© SAP AG

ADM515

7-8

Nutzung des Sekundärschlüssels SELECT * FROM POPULATION WHERE INHABITANTS=‘18 Mio.‘ Wurzelebene

3

Durchlaufe Wurzelseite: Ist „18 Mio.“ kleiner als ein Eintrag? Folge der zuletzt ermittelten Verknüpfung.

4

Indexebene

16

18

2

3

...

4

...

Ist „18 Mio.“ < „2“? Folge der letzten Verknüpfung.

Blattebene

16 Mio., New York

...

18 Mio., Mexico City

3 Mio., Athens

...

CREATE INDEX IDX_Inhabitants ON Population ( INHABITANTS DESC )

3.2 Mio., Ankara ...

4.4 Mio., Alger

...

Durchsuche Seite zeigergesteuert nach Indexübereinstimmung und erhalte Primärschlüssel für den gesuchten Datensatz.

© SAP 2008

Sekundärschlüssel haben im Prinzip den gleichen B*-Baum-Aufbau wie der Primärschlüssel. Auf Blattebene verweisen sie auf Einträge passender Zeilen der Tabelle mit Hilfe des Primärschlüssels. Dies verringert den Reorganisationsbedarf der Sekundärschlüssel bei Änderungen der zugrhörigen Basistabelle „ Wird durch Löschen, Ändern oder Einsetzen die Baumstruktur ungleichmäßig, erkennt die Datenbank dies und organisiert die Seiten so um, dass wieder eine ausbalancierte Verteilung entsteht. Gleichzeitig wird für eine gute Platzausnutzung innerhalb der Seiten gesorgt. „ Dieses Umorganisieren geschieht automatisch. Eine MaxDB-Datenbankinstanz hat deshalb immer eine optimierte Platzausnutzung und eine gute Struktur der B*-Bäume. Administrative Eingriffe und Reorganisation sind nicht notwendig. „

© SAP AG

ADM515

7-9

Inhalt einer Datenseite

Aneby

|.....

Ardwick|.... Apach

Athen |....... Arbon

|. Apensen|.....

|....... Arnh-

em |...

Dateneinträge (unsortiert) Aneby

|.....

Apach

|.

Apensen|.....

111 217 143 169 206 191 81

Arbon

|.......

Ardwick|........

Aneby

.. Athen

Positionsliste (sortiert)

Arnhem |... Athen

|........

© SAP 2008

Die Datensätze liegen unsortiert im Anfangsbereich der Zielseite. „ Im Endbereich der Datenseite gibt es eine Positionsliste, die auf die einzelnen Sätze der Datenseite verweist. Diese Adressliste ist so geordnet, dass bei sequenziellem Zugriff über die Positionsliste die Dateneinträge sortiert gelesen werden können. „ Das Datenbanksystem sucht in den verbleibenden Einträgen und kann schließlich die angeforderte Tabellenzeile liefern. „ Die Positionsliste und die Datensatzeinträge wachsen aufeinander zu. „

© SAP AG

ADM515

7-10

Performance-Tuning und Problemsituationen: Übersichtsdiagramm Performance-Tuning und Problemsituationen Thema 1: B*-Bäume Thema 2: Optimierung Thema 3: Monitore des SAP Netweaver Thema 4: Vermeidbare Probleme Thema 5: Diagnosedateien und Trace-Möglichkeiten Thema 6: Fehlerarten und deren Analyse

© SAP 2008

© SAP AG

ADM515

7-11

Optimierung

Ziel: Minimierung der Kosten für Resourcen wie CPU-Zeit „ I/O-Rate „

Hauptspeicher „ Plattenplatz „

Optimierte SQL-Anweisungen SELECT (Massen-SELECT, SINGLE SELECT) „ UPDATE „

„

DELETE

© SAP 2008

Die Optimierung der SQL-Abfragen versucht besonders die Anzahl der Page-Zugriffe zu minimieren. „ Andere Resourcen (CPU, Speichernutzung) werden als Multiplikatoren im Optimierungsprozess genutzt. „

© SAP AG

ADM515

7-12

Arten von Optimierern

Regelbasierte Optimierer: Die Zugriffsstrategie wird zum Parse-Zeitpunkt durch bestimmte Regeln festgeschrieben. „ unabhängig von den Werten in der WHERE-Bedingung „

„

Die Regel bestimmt, welche Zugriffsart gewählt wird.

Kostenbasierte Optimierer: „

Ermitteln der Zugriffsstrategie anhand „ der Werteausprägungen einer Spalte „

verfügbarer Indizes

Anzahl der Zugriffe u.s.w. „ Die kostengünstigste Strategie wird gewählt. „

MaxDB unterstützt den kostenbasierten Optimierer SQL-Hints stehen in Notfällen zur Verfügung

© SAP 2008

„ „

„ „

„

Die Optimierer der relationalen Datenbanksysteme werden in zwei Typen unterschieden, den regelbasierten und den kostenbasierten Optimierer. Der regelbasierte Optimierer arbeitet nach bestimmen Regeln. Beispiel: Ist ein Index vorhanden, dann wird dieser Index für den Zugriff genutzt - unabhängig von den übergebenen Werten in der WHERE-Bedingung. So wird beim regelbasierten Optimierer schon zum Parse-Zeitpunkt entschieden, welche Strategie zur Abarbeitung des Statements genutzt wird. Kostenbasierte Optimierer ermitteln die günstigste Zugriffsstrategie mit Hilfe von statistischen Informationen über die Größe der Tabelle und Werteausprägungen innerhalb der Tabellenspalten. Es wird ein Kosten-Nutzenplan der unterschiedlichen Zugriffsmöglichkeiten erstellt. Die günstigste Strategie in Abhängigkeit von den vorgegebenen Werten innerhalb der WHERE-Bedingung wird zur Ausführung der Anweisung gewählt. Die endgültige Suchstrategie kann deshalb erst zum Ausführungszeitpunkt bestimmt werden. SQL-Hints sind nur als Zwischenlösung anzusehen, bis der Optimizer mit einem der nächsten Datenbank-Patches korrigiert wird. Siehe auch SAP Hinweis 832544 (FAQ: MaxDB Hints).

© SAP AG

ADM515

7-13

Kostenbasierter Optimierer

Table-Scan Costvalue=5000

Auszuführendes SQL-Statement

Primärschlüssel Costvalue=3000 Index 1 Costvalue=10

Ausführung des optimierten SQL-Statements

Index 2 Costvalue=4000

Kostenbasierter Optimierer Auswirkung: Es gibt keine “falschen” Indizes, wie mit regelbasierten Optimierern

© SAP 2008

Durch neue Daten, Veränderung existierender Daten und durch Löschoperationen sind die Optimiererstatistiken stetigen Veränderungen unterworfen. Deshalb müssen sie in bestimmten Zeitabständen oder nach umfangreichen Änderungen aktualisiert werden. Das Aktualisieren von Statistikinformationen (UPDATE STATISTICS) wird über einen Workprozess initiiert. „ Anhand von vorhandenen Informationen über Größe, Indizes und Werteverteilung innerhalb der indizierten Spalten für jede Tabelle errechnet der kostenbasierte Optimierer, wie viele Zugriffe zur Bestimmung des Ergebnisses erfolgen müssen. Gibt es zu einer Tabelle mehrere Indizes, ermittelt der Optimierer, welcher Index für den Zugriff auf die Daten am günstigsten ist. „

© SAP AG

ADM515

7-14

Beispiel einer Optimierung

SELECT ... FROM population WHERE city = 'Athens'

Anweisung untersuchen (parsen)

DDL-Informationen statistische Informationen der beteiligten Tabellen

bester Zugriffspfad

Abschätzung des Wertebereichs endgültige Strategie

Ausführen der Anweisung

© SAP 2008

„

„ „ „

„

Eine SQL-Anweisung wird zuerst vom Parser bearbeitet. Dieser führt eine syntaktische und semantische Analyse durch. Bei der semantischen Analyse werden Tabellen- und deren Spaltenangaben überprüft. Der Optimierer ermittelt, welche Primär- und Sekundärschlüssel für die Tabelle vorliegen und prüft, ob ein entsprechender Schlüssel für die Suche nach Werten genutzt werden kann. Bei Sekundärschlüsseln spielt die Anzahl unterschiedlicher Werte eine wichtige Rolle. Es macht keinen Sinn, über einen Index zu suchen, wenn es nur einen Sekundärschlüsselwert gibt. Die Anzahl der zu lesenden Seiten im Sekundärschlüssel wird durch Bildung eines Start- und eines Stopkeys ermittelt. Im Verhältnis zur Anzahl der Seiten der Tabelle wird entschieden, ob es sich lohnt, über den Index zu suchen. Die Anzahl der Seiten der Gesamttabelle wird aus den Statistiken ermittelt. Am Ende wird eine Strategie festgelegt, nach der die SQL-Anweisung ausgeführt wird.

© SAP AG

ADM515

7-15

Statistikinformationen aktualisieren: CCMS

DBACOCKPIT

Zwei Möglichkeiten: vollständige Neuerstellung von Optimiererstatistiken (UpdAllStats) „ Zweistufiges Konzept „

„

Überprüfung der Tabellen auf starke Veränderungen der Größe (PrepUpdStat)

„

anschließend Erneuerung der Statistiken für die Tabellen mit großen Änderungen (UpdStats)

© SAP 2008

Der SAP NetWeaver unterstützt die Erstellung von neuen Optimiererstatistiken im Einplanungskalender des Computing Center Management Systems (CCMS, Transaktion DBACOCKPIT). Dabei wird ein zweistufiges Konzept angeboten, das ein zeitoptimiertes Verfahren anwendet: y Im ersten Schritt wird festgestellt, welche Tabellen sich so stark verändert haben, dass neue Statistiken benötigt werden (PrepUpdStats). y Im zweiten Schritt werden die Statistiken für diese Tabellen neu erstellt (UpdStats). „ Desweiteren wird ein Verfahren zur kompletten Neuerstellung von Statistiken angeboten (UpdAllStats). y Diese komplette Neuerstellung von Statistiken ist zeitaufwendig und sollte daher zu lastarmen Zeiten durchgeführt werden. „ Update Statistics auf eine Tabelle: „

y dbmcli –U c -USQL w sql_execute “update statistics <user>.“ y dbmcli –U c -USQL w sql_execute “update statistics * ESTIMATE SAMPLE 1000 ROWS“

y Für spezifische Spalten kann ebenfalls ein Update der Statistiken durchgeführt werden: dbmcli –U c -USQL w sql_execute “update statistics column () for SAP<SID>. ESTIMATE SAMPLE 10 PERCENT“ „

Siehe auch SAP Hinweis 1139904 (FAQ: MaxDB Update Statistics)

© SAP AG

ADM515

7-16

Erläuterung des Zugriffspfads

SQL-Kommando zur Ausführung: EXPLAIN EXPLAIN VIEW Ausgabe: Beschreibung der Optimiererstrategie „

Die EXPLAIN-Anweisung kann nicht bei UPDATE- , DELETE- oder INSERT-Befehlen angewendet werden.

„

EXPLAIN wird für QUERY-Anweisungen, die auf Basistabellen zugreifen, angewendet.

„

EXPLAIN VIEW zeigt die Namen von Tabellen und Indizes, die einer (mehrfachen) (JOIN-) View-Abfrage zugrunde liegen.

„

EXPLAIN führt die angegebene SELECT-Anweisung nicht aus.

© SAP 2008

„

EXPLAIN VIEW ist im SAP NetWeaver über die Transaktion ST05 und über Transaktion DBACOCKPIT oder DB50 im Kommandomonitor verfügbar.

Weitergehende EXPLAINs sind ebenfalls in Form des EXPLAIN JOIN und EXPLAIN SEQUENCE verfügbar. Besonders letzteres kann nur durch die Entwicklung interpretiert werden. Daher benötigt die Entwicklung bei der Analyse von Performanceproblemen mit SQL-Statements die MaxDB Connection (Hinweis 202344) um das Database Studio remote verwenden zu können. Daher ist empfohlen diesen Verbindungstyp vorzubereiten, um ihn kurzfristig im Problemfall bereitstellen zu können. „ Siehe auch SAP-Hinweis 819324 (FAQ: MaxDB SQL-Optimierung) „

© SAP AG

ADM515

7-17

Ermittlung des Zugriffspfads: ST05

Transaktion ST05

© SAP 2008

Die Ausgabe der EXPLAIN-Anweisung zeigt für jede Tabelle in der SELECT-Anweisung einen Informationsblock. „ Die Reihenfolge der Tabellen spiegelt die Abarbeitung der Zugriffstrategie auf die beteiligten Tabellen wider. „ Die Angabe RESULT IS NOT COPIED zeigt, ob eine temporäre Ergebnismenge aufgebaut wurde oder nicht, wie in diesem Beispiel. Bei JOINs (über mehrere Tabellen) werden je nach Abarbeitung (Sorted Merge oder Nested Loop) temporäre Ergebnistabellen aufgebaut „ Die Ausgabe für COSTVALUE IS in der Spalte PAGECOUNT repräsentiert die berechnete Zahl an Seitenzugriffen. Dies entspricht logischen I/O-Zugriffen. „

© SAP AG

ADM515

7-18

Ermittlung von alternativen Zugriffspfaden mit Hints SAP NetWeaver Transaktionen ST05, DB50 und DBACockpit

© SAP 2008

„ „

„ „ „

Mit SAP NetWeaver wird eine Funktionalität angeboten, Datenbank-Hints auch mit MaxDB zu verwenden. Ein Datenbank-Hint ist üblicherweise keine langfristige Lösung, wie es andere Datenbankanbieter oft nutzen. Normalerwiese können Hints sehr schnell kontraproduktiv werden, sobald sich der Datenbestand oder Strukturen in den zugrundeliegenden Tabellen etwas ändern, da sich die DB dann nicht an die neue Situation adaptieren kann, wie es der kostenbasierte Optimizer kann. Das führt dann meist zu Situationen, daß die Zugriffe dann schlechter werden als zuvor. MaxDB bietet Hints nur als intermediäre Lösung zur kurzfristigen Behebung möglicher OptimizerSchwächen, bis diese mit dem nächsten oder folgenden Patch behoben sind. Aber, mit dieser Funktion eröffnen sich neue Möglichkeiten in der Performanceanalyse: Damit ist es möglich den Optimizer bei Explains in eine bestimmte Richtung zu lenken. Der Datenbankadministrator hat damit die Möglichkeit, den Datenzugriff in den Tabellen über verschiedene Wege durchzuführen (Schlüsselfeldzugriff, Indexzugriff). Außerdem kann er speziell die Indizes auf einfache Weise austesten, von denen er meint, sie müßten eigentlich von Optimizer verwendet werden. Üblicherweise wird sich dann schnell zeigen, daß die verschmähten Indizes einen wesentlich höheren Costvalue zeigen.

© SAP AG

ADM515

7-19

Performance-Tuning und Problemsituationen: Übersichtsdiagramm Performance-Tuning und Problemsituationen Thema 1: B*-Bäume Thema 2: Optimierung Thema 3: Monitore des SAP Netweaver Thema 4: Vermeidbare Probleme Thema 5: Diagnosedateien und Trace-Möglichkeiten Thema 6: Fehlerarten und deren Analyse

© SAP 2008

„

Siehe auch SAP Hinweis 990602 (FAQ: CCMS für MaxDB / SAP liveCache Technology)

© SAP AG

ADM515

7-20

CCMS: Datenbankassistent (DBACOCKPIT)

© SAP 2008

Seit SAP NetWeaver 7.0 (2004s) steht im CCMS alternativ das DBA Cockpit zur Verfügung (Transaktion DBACOCKPIT). Es bietet einen bequemen Zugang zu allen, für die Administration wichtigen Datenbankinformationen samt detaillierten Analysen. „ Folgende wichtige Bereiche gibt es im DBA-Cockpit: y Platz zeigt aktuelle Leistungswerte sowie die Konfigurationen der Datenbank an und bietet den Zugriff auf gesammelte Listen von MaxDB- und Tabellengrößeninformationen. Hier müssen zuvor entsprechende Sammelreports eingeplant werden um alle Möglichkeiten auszuschöpfen. y Performance enthält die MaxDB-Werkzeugs Database Analyzser, Resource sowie Kommando Monitor um die Performance der Datenbank zu analysieren und optimieren. y Unter Werkzeuge lassen sich weitere praktische Tools im Umfeld der MaxDB-Administration nutzen, wie z.B. die grafischen Tools oder die Datenbankkonsole, die das MaxDB-Tool x_cons aufruft und die Ausgaben präsentiert. „ Die Transaktion DBACOCKPIT wird kontinuierlich weiterentwickelt und über die Basis-SupportPackages des SAP NetWeaver erneuert. Sie steht auch bei anderen Datenbanksystemen zur Verfügung und kann dann für die Administration der MaxDB genutzt werden, die oft als „BlackBox“ mitinstalliert wird. Einzig das Client-Paket der MaxDB und die DBADASLIB muß dazu zusätzlich auf dem genutzten Applikationsserver lokal installiert werden. „

© SAP AG

ADM515

7-21

CCMS: Alert-Monitore im DBA-Cockpit

© SAP 2008

In dem DBA-Cockpit ist auch der Alert-Monitor in neuer und alter Version integriert. „ Hier wird die neue Version gezeigt. „

© SAP AG

ADM515

7-22

CCMS: alter Alert-Monitor

© SAP 2008

„

Hinter dem Menüeintrag Alert-Monitor (alte Version) im DBA-Cockpit verbirgt sich die bekannte RZ20.

Der Datenbank-Alert-Monitor bietet die Möglichkeit, mit einem Blick alle drohenden Problemsituationen und Engpässe der Datenbank zu erkennen. Das CCMS-Überwachungskonzept erlaubt es, eigene Alert-Monitor-Sichten zu erzeugen. SAP liefert eine Sicht auf die Datenbank aus, die als Vorlage für eigene Sichten dienen kann. „ Grundvoraussetzung dafür ist eine sorgfältige Einstellung der konfigurierbaren Schwellenwerte mit Hilfe der Transaktion RZ20. „

In der Standardsicht werden die Bereiche Space Mangement, Performance, Backup/Restore, Health sowie für Datenbank-Clients auch Probleme mit fehlerhaften ABAP-SQL-Kommandos dargestellt. „ Neuere Entwicklungen des Alert-Monitors sind in Hinweis 545030 beschrieben. „

© SAP AG

ADM515

7-23

CCMS: Datenbankassistent (DB50)

© SAP 2008

Weiterhin besteht im CCMS alternativ der Datenbankassistent zur Verfügung (Transaktion DB50). Er bietet wie das DBA-Cockpit einen bequemen Zugang zu allen für die Administration wichtigen Datenbankinformationen samt detaillierten Analysen. „ Folgende wichtige Bereiche gibt es in der DB50: „

y Aktueller Status zeigt aktuelle Leistungswerte und Konfigurationen der Datenbank an. y Problemanalyse enthält die MaxDB-Werkzeugs Database Analyzser, Resource sowie Kommando Monitor um die Performance der Datenbank zu analysieren und optimieren. y Statistiken bietet den Zugriff auf gesammelte Listen von MaxDB- und Tabellengrößeninformationen. Hier müssen zuvor entsprechende Sammelreports eingeplant werden um alle Möglichkeiten auszuschöpfen. y Unter Tools lassen sich weitere praktische Tools im Umfeld der MaxDB-Administration nutzen, wie z.B. die grafischen Tools oder die Datenbankkonsole, die das MaxDB-Tool x_cons aufruft und die Ausgaben präsentiert. „ Die Transaktion DB50 wird kontinuierlich weiterentwickelt und über die Basis-Support-Packages des SAP NetWeaver erneuert. Sie steht auch bei anderen Datenbanksystemen zur Verfügung und kann dann für die Administration der MaxDB genutzt werden, die oft als „BlackBox“ mitinstalliert wird. Einzig das Client-Paket der MaxDB und die DBADASLIB muß dazu zusätzlich auf dem genutzten Applikationsserver lokal installiert werden.

© SAP AG

ADM515

7-24

CCMS: Datenbank Assistent – Speicherbereiche

© SAP 2008

„ „ „ „

„

In dieser Ausgabe für Platz → Caches werden die wichtigen Zugriffraten (Trefferraten) auf die Hauptspeicherbereiche der Datenbank gezeigt. Der I/O Buffer Cache ist hier nach den enthaltenen Cache-Bereichen aufgeschlüsselt. Der wichtigste Bereich in Bezug auf Performancerelevanz ist der Data-Cache. Die Trefferrate sollte gut über 98% liegen, je mehr desto besser. Bitte beachten Sie, daß es sich bei diesen dargestellten Trefferraten um gemittelte Werte seit dem Start der Datenbank handelt. So können diese Werte hervorragend aussehen, aber in Hochlastzeiten doch Trefferraten unter 95% verstecken. Bitte nutzen Sie den Datenbank Analyzer um diese Trefferraten zeitlich über den Tag aufzuschlüsseln. Lange Listen von performancerelevanten Daten werden im Bereich Expertenanalyse des Datenbank Analyzers angeboten. Der Workshop UMEW60 gibt hier einen Leitfaden, welche Werte wichtig sind.

© SAP AG

ADM515

7-25

CCMS: Datenbank Assistent – Task Manager

Detailierte Zeitmessung aktivierbar

© SAP 2008

„ „

„

„

„

„

Im Bereich des Taskmanagers bietet die Transaktion DB50 viele Funktionen um tiefer in den aktuellen Status der Tasks und Threads zu schauen, die auf der Datenbank aktiv sind. Hier wird auch eine Möglichkeit geboten, eine wesentlich ausführlichere Zeitmessung zu aktivieren. Dabei protokolliert die Datenbank eine große Zahl von Ausführungszeiten für verschiedenste Aktionen. Diese Daten werden dann in internen Tabellen zwischengespeichert und teilweise im Taskmanager angezeigt, oder schlussendlich in den Protokolldateien des Datenbank Analyzer festgehalten. In den Details der markierten Task (hier z.B. der Logwriter) werden auf dem Tabreiter I/O Operations die Schreib- und Lesezeiten angezeigt. Je nachdem, ob der ausgewählte Task durch eigene I/O oder Dev Threads auf die Platten schreibt, befinden sich Zahlenwerte in der Ausgabe links oder rechts. Der Logwriter führt hier die Schreibaktionen selber durch und zeigt eine durchschnittliche Schreibzeit von 8,2 ms seit der Aktivierung der ausführlichen Zeitmessung (11 Schreibaktionen seitdem). Bitte beachten Sie, daß die ausführliche Zeitmessung zusätzliche Performance in der Datenbank konsumiert, dessen Umfang von der Last auf dem System abhängt. Daher sollte sie nur für die Zeit der Analyse aktiviert werden und dort ist sie meist dringend notwendig um die Leistung von Festplattenbereichen (oder Anbindungen dorthin) zu bewerten. Es ist oft auch angeraten, diese Zeitmessung für längere Zeit aktiviert zu lassen um alle Tageszeiten einmal protokolliert zu haben. Sie können außerdem das Kommando x_cons SID show dev_io verwenden um die Schreib- und Lesezeiten auf den Platten bzw. Storagesystemen zu erhalten. Seit MaxDB 7.7 werden diese IO-Zeiten immer auch ohne Aktivierung der ausführlichen Zeitmessung ermittelt, da die Kosten hierfür minimal sind. Die ausführliche Zeitmessung kann ebenfalls von der Konsole mit dbmcli –U c db_execute detailed time measurement ON aktiviert werden.

© SAP AG

ADM515

7-26

Engpassanalyse mit dem Database Analyzer

© SAP 2008

„

„ „

„

„ „

Der Datenbank Analyzer ist ein wichtiges Werkzeug um Daten über den Zustand der Datenbank und teilweise auch des Gesamtsystems zu sammeln. Mit den gesammelten Daten ist es oft im nachhinein möglich Aussagen zu treffen, was zum Zeitpunkt eines Ereignisses auf der Datenbank passiert ist. In der Darstellung sehen Sie die Hauptliste des Datenbank Analyzers in dem umfangreiche Informationen zum Datenbankbetrieb am aktuellen Tag gezeigt werden. Daneben werden wesentlich mehr Werte protokolliert. Diese Infos werden üblicherweise in einer Wiederholung alle 15 Minuten (900s) ermittelt und sind anschließend in ausführlicher Form im Bereich “Expertenanalyse” nach Datumswerten sortiert zu finden. Der Datenbank Analyzer aktiviert sich hier automatisch und sammelt dann die Werte aus den Systemtabellen zusammen, in denen diese Daten durch den Datenbankkern bereits abgelegt wurden. Daher ist der Datenbank Analyzer auch nicht Performance-kritisch und sollte zu jeder Zeit aktiviert sein. Die Performanceanalyse basiert oft stark auf den dort protokollierten und zeitlich aufgeschlüsselten Daten und daher ist es auch dringend empfohlen, darauf zu achten, daß der Datenbank Analyzer immer aktiviert ist. Normalerweise wird er bei der Verwendung von neueren Basis Support Paketen automatisch mit dem Start des SAP NetWeaver Applikationsservers nachgestartet. Um den Datenbank Analyzer z.B. unter Windows betreiben zu können, wird die Microsoft MDAC Version von mindestens 2.7 benötigt. Dies ist üblicherweise bei Windows 2003 und folgende erfüllt. Weitergehende Beschreibungen der Meldungen des Datenbank Analyzers können Sie über http://help.sap.com erhalten (Bitte suchen Sie nach analyzer und charakteristischen Textstücken). Alternativ kann der Datenbank Analyzer auch über die Konsole folgendermaßen gestartet werden: dbanalyser –d <SID> -u sap<sid>,sap –c 1 –t 900 –o

oder einfach dbanalyzer und Sie nutzen anschließend den interaktiven Modus.

© SAP AG

ADM515

7-27

Wartung der Database Analyzer Daten

© SAP 2008

„

„

„ „

„

Nach ein paar Wochen des Betriebs des Datenbank Analyzers legt er eine Menge Verzeichnisse unter RunDirectoryPath/analyzer an, die dann aufgrund der Listenlänge Probleme bereiten können. Um diese Listen verwaltbar zu halten, können Sie die automatische Administration verwenden, wie es hier gezeigt wird. Generell werden pro Tag etwa 100-200 kByte an Daten protokolliert. Die automatischen Funktionen werden jede Nacht um ein Uhr Ortszeit ausgeführt und löschen die Daten in diesem Beispiel aus dem Verzeichnis nach 93 Tagen Verweilzeit. Auch ist es möglich diese Daten in der Datenbank direkt abzulegen und auch dort nach einer definierten Zeit zu löschen. Desweiteren werden Aggregatfunktionen zur Reduktion der Datenmenge angeboten, die eingeschaltet werden sollten, um mit den aggregierten Daten weiter in die Vergangenheit schauen zu können. Sollten Sie kurzfristig ein Löschen von Daten benötigen, verwenden Sie bitte die Funktion auf dem Reiter Manual Admin. Wenn die Listen der Tagesverzeichnisse zu lang werden, kann es passieren, daß im Expertenbereich des Datenbank Analyzers keinerlei Verzeichnisse angezeigt werden, obwohl sie definitiv im Verzeichnis vorhanden sind. Der Datenbank Analyzer kann auch über das dbmcli verwaltet werden. Diese Funktionen werden auch von der DB50 verwendet und bei Problemen mit dem automatischen Start des DBanalyzers lohnt es sich diese unter Tools Ö dbmcli testweise auszuführen: y dbmcli –U c dban_start y dbmcli –U c dban_state y dbmcli –U c dban_stop

© SAP AG

ADM515

7-28

Ermittlung der Quelle von Lastsituationen

© SAP 2008

Mit dem Ressourcenmonitor in der DB50 ist es möglich, SQL-Statements in Klassen unterschiedlicher Statements zu sammeln. Dabei können die Werte, die über die WHERE-Bedingung definiert werden variieren. Diese variierenden Werte werden nicht gesammelt, sondern nur alle RohStatements. Die dazugehörigen Ausführungszeiten und einige andere performancerelevante Werte werden aufaddiert (kummuliert) bzw. Durchschnittswerte ermittelt. Damit zeigt die Liste sofort die lastproduzierenden SQL-Statements an und es können Schritte zur Optimierung vorgenommen werden. „ Die empfohlenen Starteinstellungen werden, wie oben gezeigt, eingestellt. Anschließend muß der Monitor mit den gezeigten Buttons gestartet oder gestoppt werden. „ Mit einem Doppelklick auf eine Zeile der später erscheinenden Liste können Sie die ausgeführten Statements anzeigen lassen. Sie können hier aber kein Explain ausführen lassen, da die Parameterwerte fehlen, die in der WHERE-Bedingung als Variablen eingetragen werden müssen. „ Um den Resourcenmonitor ohne die DB50 starten zu können, verwenden Sie bitte die folgenden Kommandos: „

y dbmcli -U c -USQL DEFAULT sql_execute "diagnose analyze on" y dbmcli -U c -USQL DEFAULT sql_execute "diagnose analyze count on“ „

Die Inhalte der Systemtabellen des Resourcenmonitors können mit dem folgenden Kommando oder einfach mit dem Laden der Systemtabellen gelöscht werden y dbmcli -U c -USQL DEFAULT sql_execute "diagnose analyze clear all"

„

Die entsprechenden Kommandos für den auf der nächsten Seite folgenden Kommandomonitor lauten: y dbmcli -U c -USQL DEFAULT sql_execute "diagnose monitor rowno 9999" y dbmcli -U c -USQL DEFAULT sql_execute "diagnose monitor time 1000" y dbmcli -U c -USQL DEFAULT sql_execute "diagnose monitor data on" y dbmcli -U c -USQL DEFAULT sql_execute "diagnose monitor clear"

© SAP AG

ADM515

7-29

Ermittlung von teuren SQL-Statements

!

© SAP 2008

„ „

„

„

„

„ „

Im Gegensatz zum Resourcenmonitor bietet der Kommandomonitor die Möglichkeit, individuelle SQL-Statements einzufangen, die auf der Datenbank ausgeführt wurden. Dieser Monitor muß ebenfalls manuell mit dem Bleistift-Button eingerichtet und gestartet werden. In dem auftauchenden Popup können Sie, wie oben dargestellt, die empfohlenen Randbedingungen einstellen. Diese Werte reichen im Normalfall aus, um 12 bis 24 Stunden zu protokollieren. Die Ausgabeliste der SQL-Statements kann anschließend wie üblich nach unterschiedlichen Spaltenwerten sortiert werden (standardmäßig ist sie anhand der Laufzeit absteigend sortiert). Die protokollierte Liste ist in der Länge limitiert und arbeitet wie ein FiFo (first in, first out). Nach einiger Zeit werden dadurch frühe Statements aus der Liste verdrängt. In der Liste auf dem Monitor werden sie aber weiterhin bis zum nächsten Auffrischen angezeigt. Mit einem Doppelklick auf die Listeinträge können Sie das Statement mit den dazugehörigen Parametern bzw. Werten der WHERE-Bedingung anzeigen lassen. Da diese Werte im Gegensatz zum Resource Monitor vorhanden sind, kann hier ein Explain ausgegeben werden. Die Ausgabe des EXPLAIN zeigt die Analysedaten in tabellenarischer Form an. Jede Tabelle z.B. in einem analysierten JOIN bekommt einen Block, in dem die verwendeten Komponenten, wie Strategien, Indices oder Schlüsselfelder angezeigt werden. Die Spezifikation RESULT IS NOT COPIED zeigt an, ob eine temporäre Ergebnismenge aufgebaut und dann im Block an die Applikation übermittelt wurde. Die Ausgabe COSTVALUE IS in der Spalte PAGECOUNT zeigt schließlich die berechneten Kosten für die Ausführung dieses Statements an. Diese Berechnung bezieht sich auf logische I/O Zugriffe auf die Tabelle. Alle anderen Zahlenwerte in den Zeilen darüber kommen aus den ermittelten Statistiken der links angezeigten Tabellen oder Indizes.

© SAP AG

ADM515

7-30

Datenbankverbindungen testen

Verbindungstest mit detailierten Log

© SAP 2008

Die Transaktion DB59 bietet einen detaillierten Blick auf alle existierenden MaxDB- und liveCacheVerbindungen. Sie ist dadurch vergleichbar mit der Transaktion SM59 für Netzwerkverbindungen. „ Mit einem Doppelklick auf einen der Listeneinträge startet die entsprechende DB50 (MaxDB) oder LC10 (liveCache) für den ausgewählte Datenbankverbindungstyp. „

In dieser Transaktion können Sie alle wichtigen Verbindungsinformationen wie z.B. Servername, Datenbankname und verwendete Userlogon-Daten finden bzw. ändern. Sollten die Daten geändert werden, denken Sie bitte daran, alle beteiligten Applikationsserver des SAP-Systems durchzustarten – Sie werden auch vom System darauf hingewiesen. Anderenfalls würden diese Applikationsserver weiterhin mit den alten Logon-Daten arbeiten und Verbindungsfehler auftreten. „ Anschließend können Sie Verbindungen oder deren Änderungen mit dem Button “Verbindungstest” überprüfen. Erster Schritt ist, hier zu definieren, von welchem Applikationsserver aus der Test erfolgen soll und mit einem erneuten Auslösen des Buttons Verbindungstest, im zweiten Schritt, den eigentlichen Test durchführen. Die protokollierten Log-Informationen dieses Tests können Sie dann über den Button Log erhalten. Hier können Sie dann auch erkennen, daß vier verschiedene Tests durchgeführt und damit alle Datenbankzugriffe simuliert wurden. „ Wie in der DB59 eine weitere Datenbankverbindung angelegt wird, zeigen die folgenden Seiten. Da die DB50 und DB59 Bestandteil des Basis Support Pakets sind, kann dieses auch auf MaxDBfremden SAP-Systemen eingerichtet werden. Es wird dann nur ein entsprechend installiertes MaxDB-Client-Paket auf dem fremden Datenbankserver benötigt. „

© SAP AG

ADM515

7-31

Management der Datenbankverbindungen: DB59 Integration von anderen MaxDB Instanzen

© SAP 2008

Mit der DB59 ist es möglich, Datenbanken anzusprechen, die gar nicht mit dem lokalen SAP NetWeaver zur Datenablage genutzt werden. Diese Eigenschaft ist besonders interessant bei der Analyse von Altversionen der SAP-Anwendungen, wie 3.1I bis 4.6B. So kann man mit einem adäquaten Satz an Analysetools in der DB50 eine Altversion noch optimieren. Für so einen Einsatz könnten Sie z.B. den Solution Manager als zentrales Informationssystem ihrer SAP-Landschaft nutzen. „ Bitte verwenden Sie den Button Datenbank integrieren um eine neue Datenbankverbindung zu erstellen. Als erstes wird der Name der neuen Datenbankverbindung und der Datenbanktyp dahinter abgefragt. Im anschließenden Schritt definieren Sie dann alle wichtigen Verbindungsinformationen wie z.B. Servername, Datenbankname und verwendete Userlogon-Daten. „ Zusätzlich können Sie über den zweiten Tabreiter Jobs für die SAP Transaktion RZ20 aus dem CCMS-Monitoring verwalten bzw. starten. Desweitern können Sie Datenbankprotokolldateien regelmäßig automatisch löschen lassen. „ Nach dem Speichern der Eingaben werden Sie durch ein Popup daran erinnert, alle beteiligten Applikationsserver des SAP-Systems durchzustarten, falls Sie nachträglich hier noch etwas ändern. Anderenfalls würden diese Applikationsserver weiterhin mit den alten Logon-Daten arbeiten und Verbindungsfehler auftreten. „

© SAP AG

ADM515

7-32

Performance-Tuning und Problemsituationen: Übersichtsdiagramm Performance-Tuning und Problemsituationen Thema 1: B*-Bäume Thema 2: Optimierung Thema 3: Monitore des SAP Netweaver Thema 4: Vermeidbare Probleme Thema 5: Diagnosedateien und Trace-Möglichkeiten Thema 6: Fehlerarten und deren Analyse

© SAP 2008

© SAP AG

ADM515

7-33

Vermeidbare Probleme und ihre Lösungen

LOG FULL Segment 1

Regelmäßige Log-Sicherungen durchführen Segment 2

DATABASE FULL

Log-Bereich

Datenbankinstanz rechtzeitig vergrößern Datenbereich

Schlechte Antwortzeiten

Statistikinformationen aktualisieren

Aktualisierung der Optimiererinformation für SQL-Zugriffe

Ungültige Datensicherungen

Konsistenz der Sicherungen prüfen

Verwendbarkeit und Konsistenzprüfung sollten regelmäßig durchgeführt werden

Weitere Probleme

Anwendung analysieren

DEADLOCK: Sperrsituation durch gegenseitiges Sperren LOCK ESCALATION: Umwandlung von Zeilensperren in eine Tabellensperre, wenn mehr als 20 Prozent der Sperrliste mit Sperren für eine Tabelle & Benutzer belegt ist © SAP 2008

„

„

„

„

„

Neben einem Plattenfehler gibt es zwei weitere Situationen, welche die Verfügbarkeit der Datenbank einschränken können. y LOG FULL: der Log-Bereich ist zu 100 Prozent gefüllt y DATABASE FULL: die Datenbankinstanz ist zu 100 Prozent gefüllt Die Datenbank bleibt für lesende Zugriffe verfügbar. Der Betrieb kann normal weitergehen, sobald der entsprechende Engpass beseitigt ist. Um diese Situationen zu vermeiden, sollten Sie regelmäßig den Füllungsgrad der Datenbank und des Log-Bereichs beobachten und rechtzeitig die Speicherplattenkapazität erweitern bzw. eine manuelle Log-Sicherung starten. Zur Bestimmung der optimalen Zugriffsstrategie benötigt der MaxDB-Optimierer aktuelle Statistikinformationen, die gemäß den Strategien der SAP mittels Planungskalender im DBACockpit zu erstellen sind. Mit dem Prüfen der Volumes (Database Studio: Kontextmenü der Instanz ÖCheck Database Structure…) wird die logische Konsistenz der Datenstrukturen im Betriebszustand ONLINE oder ADMIN überprüft. Nicht belegte Speicherseiten werden der Freispeicherverwaltung zugeführt und, falls vorhanden, inkonsistente interne Baumstrukturen repariert. Wir empfehlen, das Prüfen der Volumes einmal im Monat, z.B. vor einer vollständigen Datensicherung, auszuführen. Sicherungen sollten Sie regelmässig auf Ihre physische Konsistenz überprüfen, z.B. im Database Studio mit dem Kontextmenü ÖCheck Backup….

© SAP AG

ADM515

7-34

Performance-Tuning und Problemsituationen: Übersichtsdiagramm Performance-Tuning und Problemsituationen Thema 1: B*-Bäume Thema 2: Optimierung Thema 3: Monitore des SAP Netweaver Thema 4: Vermeidbare Probleme Thema 5: Diagnosedateien und Trace-Möglichkeiten Thema 6: Fehlerarten und deren Analyse

© SAP 2008

© SAP AG

ADM515

7-35

Diagnosedateien: Übersicht

Global Memory

Anwendung

appldiag

SQL-Traces

X-Server

Xserver_hostname.prt

MaxDBLaufzeitumgebung

rtedump knltrace

knlMsg

MaxDB-Kern

knldump

Betriebssystem

core / drwtsn32.log

© SAP 2008

„

appldiag: Treten Fehler zwischen Laufzeitumgebung und Kern auf, werden diese in die Datei appldiag eingetragen. Eine entsprechende Datei wird für jeden Betriebssystembenutzer angelegt.

„

SQL-Traces: Besonders bei Fehlern im Zugriff auf SQL-Daten können SQL-Traces auf Applikationsbasis (ST05) oder ein Precompiler-Trace (dbslada.pct) aktiviert werden.

„

xserver_.prt: Treten Fehler bei der Kommunikation über den X-Server auf, werden diese in die Datei xserver_.prt eingetragen.

„

rtedump: Bei einem Absturz schreibt die Laufzeitumgebung ihren Status in die Datei rtedump. Es handelt sich um eine ASCII-Ausgabe des Kommandos x_cons <SERVERDB> show all.

„

knlMsg: Die Datei knlMsg wird vom Kern mit Informationen und Meldungen beschrieben. Sie hat eine feste Größe und wird zyklisch überschrieben. Nach einem Absturz ist in dieser Datei auch der Backtrace enthalten. Sie ist im XML-Format aufgesetzt. knltrace: Die Datei knltrace wird vom Kern bei eingeschaltetem Vtrace und bei Abstürzen geschrieben. Sie hat eine vordefinierte feste Länge. knldump: Während eines Emergency Shutdown wird das Global Memory in die Datei knldump geschrieben. Das entsprechende Dateisystem sollte groß genug sein. In den aktuellen Releases der MaxDB wird die Erzeugung dieser oft riesigen Datei aktiv unterdrückt und ein Schreiben muß erst freigeschaltet werden. core: Stürzt ein UNIX-Prozess ab, schreibt das Betriebssystem einen Core. Dieser enthält einen Speicherauszug des Prozesses. Auch die Erzeugung der Cores wird von MaxDB verhindet, bis es freigeschaltet wird. drwtsn32.log: Stürzt die Datenbank unter Windows ab, wird der Stack-Backtrace in die Datei DrWtsn32.log geschrieben, sofern dieser als Systemdebugger eingetragen ist. Informationen dazu enthält der Hinweis 49776.

„ „

„

„

© SAP AG

ADM515

7-36

Ablage der Diagnosedateien

Alle Diagnosedateien bis auf die Dateien appldiag und xserver_.prt liegen im Arbeitsverzeichnis „

Datenbankparameter RUNDIRECTORY

„

Default: /wrk/<SID>

Die Datei appldiag steht im Verzeichnis „ /wrk/
user>

(UNIX) „ \wrk

(NT, wenn DIAGFILE=yes gesetzt ist) „ im

Arbeitsverzeichnis der SAP Netweaver-Instanz

Die Datei xserver_.prt steht im Verzeichnis „ /wrk

© SAP 2008

„

lässt sich mit dem Database Manager CLI über folgendes Kommando ermitteln: dbmcli –d <SID> -u ,<password> dbm_getpath indepdatapath

„

Folgende Dateien werden nach einem Absturz automatisch in ein Sicherungsverzeichnis kopiert: knlMsg, knltrace, knldump, rtedump, *.dmp, *.buf, *.stm

„

Wird beim Neustart erkannt, dass die Datenbank zuletzt abgestürzt ist, so werden die zu sichernden Dateien in ein Verzeichnis mit folgender Namenskonvention gesichert: __, z.B. DEV_20081114_12-09-45

Im Ursprungsverzeichnis werden die gesicherten Diagnosedateien gelöscht. „ Das Sicherungsverzeichnis befindet sich unter dem zu konfigurierenden Verzeichnis im MaxDBParameter DiagnoseHistoryPath. „ Die Anzahl der Analysegenerationen lässt sich ebenfalls über den MaxDB-Parameter DiagnoseHistoryCount konfigurieren. Ist die maximale Anzahl der Historien erreicht, wird bei einem erneuten Auftreten des Problems die jeweils älteste Analysegeneration gelöscht. „ Kann eine Verwahrung der Analysegeneration nicht ordnungsgemäß durchgeführt werden, beeinflusst dies nicht den weiteren Neustart der Datenbank. „

© SAP AG

ADM515

7-37

Beispiel für eine appldiag-Datei

Beispiel: 06.01 06.01 06.01 07.01 07.01 08.02 08.29

12:53:46 12:58:25 18:46:23 11:47:37 11:47:59 13:11:07 13:13:13

18286 18286 19025 10959 12031 18899 11199

-11205 -11205 -11109 -11987 -11987 -11987 -11987

sqlexec: system error, not enough space sqlexec: system error, not enough space database ‘S10’ is not running sql33_con_msl: task limit sql33_request: connection broken, kernel cleared connection closed by communication partner comseg given away, assuming timeout

ID des verursachenden Prozesses

© SAP 2008

„

Die Dateien appldiag steht im Verzeichnis y /wrk/ (UNIX) y \wrk (Windows, wenn DIAGFILE=yes gesetzt ist) y im Arbeitsverzeichnis der SAP Netweaver-Instanz

© SAP AG

ADM515

7-38

Die Struktur der knlMsg Datei

knlMsg Zeitstempel

Kopf

SERVERDB is ready (→ ADMIN) Zeitstempel

Rumpf

RESTART LOCAL: ready (→ ONLINE) --- current write position ---

Enthält alle protokollierten Informationen des Datenbankkerns seit dem Start Größe: üblicherweise 800 kB (KernelMessageFileSize), bei neueren Installationen 3 MB Format: XML Umbenennung bei jedem Neustart der Datenbank in knlMsg.old Zyklischer Schreibmodus Aktuelle Schreibposition per Suche nach “current” Kopf des knlMsg enthält wichtige Informationen in welcher Betriebssystemumgebung der Datenbankkern gestartet wurde „ „

Ein kompletter Parametersatz der Datenbankinstanz Hardware- und Betriebssystemparameter zu Limits, phys. Speicher, Anzahl der CPUs, diverse Versionsnummern usw.

© SAP 2008

„

Die Diagnosedatei knlMsg stellt die wichtigste Informationsquelle bei Datenbankproblemen dar. y In der Datei werden die Meldungen protokolliert, die in der Kommunikation zwischen der Laufzeitumgebung der MaxDB und dem Datenbankkern auftreten. y Diese Datei wird bei jedem Start des Datenbankkerns neu angelegt und die bereits vorhandene unter dem Namen knlMsg.old gesichert.

y In neueren Releases wird die Datei knlMsg nach einem Datenbankabsturz ebenfalls in dem Verzeichnis DIAGHISTORY (definiert über den DB-Parameter DiagnoseHistoryPath ) unterhalb des RunDirectoryPath gesichert, damit nach zwei Restart-Versuchen die Information, die zum Datenbankabsturz geführt hat, nicht verloren ist. Es werden üblicherweise die zwei letzten Dateien von Abstürzen gesichert (konfigurierbar über DB-Parameter DiagnoseHistoryCount ). y Fehler werden zusätzlich auch in knlMsg.err protokolliert. Diese Datei wird nicht überschrieben und kann bei großem Dateiwachstum archiviert und anschliessend gelöscht werden. Sie wird dann automatisch wieder neu angelegt. „ Unter Unix können die Fehlerkanäle des Datenbankkerns (einstellbar über Parameter MessageOutputDevice1 und MessageOutputDevice2) genutzt werden, um Meldungen per Pipe zur Weiterverarbeitung zu verschicken. Hiermit könnte man Warnungen der Datenbank per Mail weiterverteilen. „ Mit dem mitgelieferten MaxDB-Tool protconv können die XML-Dateien per Kommandozeile in ASCII umgesetzt werden.

© SAP AG

ADM515

7-39

Beispiel für knlMsg im Database Studio

© SAP 2008

„

Am Beginn der Datei Database Messages finden Sie im Headerbereich immer einen kompletten Satz an Datenbankparametern aufgelistet. Anschließend folgen weitere Infos zum Betriebssystem, evt. vorhandene Limitierungen, usw.

© SAP AG

ADM515

7-40

Beispiel für eine knlMsg-Datei (DBA-Cockpit)

© SAP 2008

Der Dateien knlMsg und knlMsg.old werden zyklisch geschrieben. Die Größe (Parameter: KernelMessageFileSize) ist meist auf 800 kByte eingestellt, in neueren Releases auch größer. „ In diesem Bereich des DBA-Cockpits werden die Diagnosedateien entsprechend aufgearbeitet und wichtige Meldungen hervorgehoben. „

© SAP AG

ADM515

7-41

Zusammenstellung von BetriebssystemLibraries MaxDB Kommando:

[System name] twdf1915

sdbinfo [OS name] Windows NT [Version] 5.2 [Patch level] Build 3790 [Processor type] [Processors online] 4 [Processor info] AMD64 Family 15 Model 65 Stepping 2, AuthenticAMD [C++ run-time library] 5.2.3790.1830 msvcirt.dll Microsoft Windows Operating System runtime 6.1.8638.1830 msvcp60.dll Microsoft Windows Operating System runtime 7.10.3077.0 msvcp71.dll Microsoft Visual Studio .NET runtime 7.0.9466.0 msvcr70.dll Microsoft Visual Studio .NET runtime 7.10.3052.4 msvcr71.dll Microsoft Visual Studio .NET runtime 6.1.8638.3959 msvcrt.dll Microsoft Windows Operating System runtime System information saved in G:\sapdb\data\wrk\SDBINFO.PRT

© SAP 2008

„

Mit dem Kommando sdbinfo können Sie betriebssystemseitige Informationen, die die Datenbanksoftware ebenfalls betreffen, sammeln. Gerade unter Unix, aber auch Windows ist das sammeln dieser Versionsinformationen oft sehr mühsam. Bitte stellen Sie diese Informationen ebenfalls bei Supportfällen bereit.

© SAP AG

ADM515

7-42

SQL-Trace

SQL-Trace

R/3 ST05

(verfügbar innerhalb des SAP-Systems)

Auftragsschnittstelle (Precompiler)

SQL-Trace (als Trace-Datei verfügbar)

MaxDB-Kern

© SAP 2008

Im SAP NetWeaver wird mit der Transaktion ST05 der SQL-Trace eingeschaltet. Das Protokoll wird von der Datenbankschnittstelle geschrieben. Mit den einzelnen Anweisungen sind die Variablen, deren Werte und die Laufzeiten angegeben. Die Transaktion ST05 bietet mit EXPLAIN auch die Möglichkeit, die Optimiererstrategie der Datenbank für die Anweisung anzuzeigen. „ Auch die Auftragsschnittstelle der Datenbankinstanz schreibt einen SQL-Trace (auch PrecompilerTrace genannt). Hier wird angezeigt, welche Kommandos an dieser Schnittstelle ankommen und welche Daten an den Client übergeben werden. „

© SAP AG

ADM515

7-43

Aktivierung des SQL-Trace

SQL-Trace der Auftragsschnittstelle (Precompiler-Trace): Profilparameter des SAP Netweaver „

dbs/ada/sql_trace = 0 1 2

kein Trace kurzer Trace langer Trace

Umgebungsvariable auf Betriebssystemebene „

SQLOPT = -F -T -X

Trace in Datei kurzer Trace langer Trace

Aktivierung von außen: IRTRACE irtrace –p all –t „ irtrace –p -t „

© SAP 2008

„

Der Trace der Auftragschnittstelle wird für den SAP NetWeaver über einen Profilparameter eingestellt. Nach Änderung des Profilparameters muss bei Windows-Systemen nur der Workprozess neu gestartet werden. Bei UNIX-Systemen ist das SAP-System bzw. der betroffene Applikationsserver neu zu starten. Die Trace-Dateien stehen im Arbeitsverzeichnis der SAP-Instanz. Ihr Name setzt sich aus der Prozess-ID des Workprozesses und der Endung .pct zusammen.

„

Andere Datenbankwerkzeuge oder SAP-Tools (R3trans, tp, saplicense usw.), die auf die Auftragschnittstelle aufsetzen und über die Konsole bzw. DOS-Box gestartet werden, lesen die Umgebungsvariable SQLOPT. Wenn nicht anders mit der Option -F angegeben, wird die TraceDatei in das aktuelle Verzeichnis geschrieben. Der Name setzt sich aus dem Namen des entsprechenden C-Moduls (z.B. dbslada) und der Endung .pct zusammen.

Sie können den Trace mit irtrace auch einschalten, OHNE das System/den Applikationsserver durchstarten zu müssen. „ Das Tool bietet folgende Möglichkeiten zur Änderung des Trace-Verhaltens: y Ein-/Aus-/Umschalten des Trace für einen bestimmten Prozess: irtrace –p <prozess-id> –t „

y Folgende Trace-Arten stehen hierbei zur Verfügung: long : langer Trace, short :kurzer Trace und off : Trace abschalten. y Ein-/Ausschalten des Trace für ALLE Interface-Prozesse auf dem Applikationsserver: irtrace –p all –t

© SAP AG

ADM515

7-44

SQL-Trace: Beispiel für PreCompiler Trace

SAPDB_.pct: PRODUCT : SAP DB C-PreComp Runtime DRIVER : G:/sapdb/programs/runtime/7403\pgm\libpcr PRECOMPILER : 7.4.3 005 LIBRARY : 7.4.3 039 BUILD : 039-123-092-249 version :P_1, SQL STATEMENT Statement Name OUTPUT : LZU OUTPUT : PCR START : DATE END : DATE OPTION :

P_2 : FROM MODULE : dbadautl AT LINE : 644 : :0x000010 : W32/INTEL 7.4.3 Build 039-123-092-249 : C-PreComp 7.4.3 Build 039-123-092-249 : 2005-11-23 TIME : 0020:30:55 : 2005-11-23 TIME : 0020:30:55

PARSEINFOCACHE=OFF

SESSION : 1; Xuser Data DATABASE : DB_000 USERKEY : DEFAULT SQLMODE : SAPR3 SERVERDB : DEV SERVERNODE: twdf0736 CONNECT "SAPDEV " IDENTIFIED BY :A SQLMODE SAPR3 ISOLATION LEVEL 0 TIMEOUT 0 SQL STATEMENT : FROM MODULE : dbadautl AT LINE : 92 Statement Name : :0x000001 START : DATE : 2005-11-23 TIME : 0020:30:55 END : DATE : 2005-11-23 TIME : 0020:30:55 DB_000: MASS STATEMENT : SELECT KERNEL INTO :P_1 FROM DOMAIN.VERSIONS SQL STATEMENT : FROM MODULE : dbadautl AT LINE : 713 Statement Name : :0x000011 PARSEID: OUTPUT: 0008C0A0 00000301 3C000000 01000000 PARSEID: INPUT : 0008C0A0 00000301 3C000000 01000000 OUTPUT : 1: PARAMETER : Kernel 7.5.0 SQLERRD(INDEX_3) : 1 START : DATE : 2005-11-23 TIME : 0020:30:55 END : DATE : 2005-11-23 TIME : 0020:30:55

Build 029-121-099-958

© SAP 2008

Der Ausschnitt des Precompiler-Trace zeigt, dass die Datei mit wichtigen Versionsinformationen beginnt (wichtig, falls die falschen Bibliotheken geladen wurden). „ Desweiteren werden alle Zugriffe (Benutzername, Datenbankrechner und Datenbankinstanz) protokolliert. „ Der Precompiler-Trace hilft oft, wenn Verbindungsprobleme von einem Datenbank-Client, z.B. dem Applikationsrechner, auftreten (Fehlermeldung -709). „

© SAP AG

ADM515

7-45

Datenbank-Trace

Kern

SQL-Manager (historisch: AK)

Data Access Manager (historisch: KB, BD)

Lesbare Ausgabedatei <SID>.prt

KernelTrace ON KernelTrace Flush

Binärdatei: knltrace bzw. knltrace.dat

Auswertungstool: xkernprot

© SAP 2008

Der Datenbank-Trace (Kernel Trace, Vtrace) dient zur serverseitigen Analyse ausgeführter SQLAnweisungen. „ Der Datenbankkern besteht aus zwei logischen Bereichen, die früher historisch bedingt in weitere Bereiche (AK, KB und BD) untergliedert waren. Diese Unterscheidung findet sich teilweise noch in den Kommandos. „ Beim Einschalten des Datenbank-Trace wird angegeben, aus welchen Bereichen des Kerns in Puffern wichtige Betriebsdaten gesammelt werden. Nach dem Einfangen der problematischen Situation werden diese Informationen in die Datei knltrace geschrieben. Im Allgemeinen wird dabei mit der Angabe default gearbeitet. „

„

Zur Ausgabe des Datenbank-Trace wird angegeben, für welche Schichten bzw. Module des Kerns die Protokolle zu extrahieren sind. Dieses kann mit den Werkzeugen Database Studio, xkernprot oder Transaktion DB50/DBACOCKPIT erfolgen.

Daten zu Strategien und Zeiten werden nur dann ausgegeben, wenn die Optionen OPTIMIZER bzw. TIME für den Datenbank-Trace eingeschaltet waren. „ Die SWITCH-Ausgabe enthält Daten aus dem Trace eines sog. Slow-Kern. Der Slow-Kern ist ein spezieller Debug-Kern. Er wird nur auf besondere Anforderung durch die Entwicklung bzw. den Support benutzt. „ Bei normalen Datenbank-Shutdowns und unerwarteten Abstürzen wird die Datei knltrace automatisch geschrieben. „ Siehe auch SAP Hinweis 1020175 (FAQ: MaxDB Datenbank-Trace (VTRACE)) „

© SAP AG

ADM515

7-46

Datenbank-Trace: Vorgehensweise

1. Datenbank-Trace einschalten 2. Datenbankaktion durchführen (möglichst als alleiniger Datenbankbenutzer) 3. Flush des Datenbank-Trace 4. Datenbank-Trace ausschalten 5. Extrahieren der problembezogenen Daten aus der Binärdatei in eine lesbare Form

© SAP 2008

„

Das Ein- und Ausschalten sowie Flush des Datenbank-Trace kann mit dem Database Studio, dem Database Manager CLI und im CCMS (Transaktion DB50) geschehen.

Flush des Datenbank-Trace kann zusätzlich mit dem SQL Studio durchgeführt werden. „ Kommandos im Database Manager CLI (Ausführung im Betriebszustand ADMIN oder ONLINE: Einschalten: dbmcli –U c -UUTL c util_execute diagnose vtrace default on „

Flush, Betriebszustand ONLINE: dbmcli –U c -USQL w sql_execute vtrace Flush, Betriebszustand ADMIN: dbmcli –U c -UUTL c util_execute vtrace Ausschalten: dbmcli –U c -UUTL c util_execute diagnose vtrace default off Auswerten: xkernprot –d <SID> • Ausführung auch im Betriebszustand OFFLINE möglich • bezeichnet die Schichten, die ausgewertet werden sollten (z.B. akbnx): a AK-Schicht m message buffer, sql_packet b BD-Schicht n net (distribution) k KB-Schicht t time vtrace s Strategie x switch output (slow kernel) (Bzgl. der Optionen TIME und SWITCH bitte vorherige Seite beachten)

© SAP AG

ADM515

7-47

Datenbank-Trace: Database Studio

© SAP 2008

Unter Database Trace Ö Options… erhalten Sie die Möglichkeit den Trace-Rahmen zu definieren, wie tief dieser Trace stattfindet. Wählen Sie bitte TraceDefault für einen allgemeinen Trace aus. „ Wenn nicht anders von der Entwicklung oder dem Support angegeben, ist der standardmäßige Datenbank-Trace ausreichend. „ Zusätzlich können Informationen für DELETE-, INSERT-, UPDATE-, SELECT- und OptimiererOperationen usw. aktiviert werden. „ Unter Advanced sind zwei nützliche Erweiterungen verfügbar: y Trace Session Der Datenbank-Trace läßt sich für bestimmte Datenbanksitzungen einschalten. Dazu muss die Datenbanksitzung jedoch bekannt sein. Die Ausgaben von x_cons <SID> show active und dbmcli –U c –USQL DEFAULT sql_execute “SELECT * FROM TRANSACTIONS“ helfen dabei weiter. y Stop on Error Sie können den Datenbank-Trace so einstellen, dass er beim Auftreten eines bestimmten Fehlers automatisch ausgeschaltet wird. Dies ist nützlich, wenn ein bestimmtes Problem reproduziert werden soll und Sie wissen, welcher Fehler auftreten wird. Durch diese Funktion verhindern Sie, dass die relevanten Informationen in der Trace-Datei überschrieben werden. „

© SAP AG

ADM515

7-48

Datenbank-Trace: Erzeugen des Protokolls

© SAP 2008

„

Unter Generate… können Sie die Information aus der Datei knltrace sortieren und für die gewünschten Teilbereiche in eine ASCII-Datei <SID>.prt extrahieren.

„

Geben Sie an, für welche Schichten bzw. Module des Kerns die Trace-Ausgaben extrahiert werden sollen. Der Vorschlagswert ist abkmx.

Daten zu Strategien und Zeiten werden nur ausgegeben, wenn die Optionen OPTIMIZER und TIME eingeschaltet waren. „ Mit den unteren Checkboxen besteht die Möglichkeit, alle Schritte zur Darstellung der lesbaren Traceinformationen zu automatisieren: y Flushen der Trace-Informationen y Öffnen der lesbaren Trace-Datei y Beenden des laufenden Traces „

© SAP AG

ADM515

7-49

Datenbank-Trace: Anzeigen des Protokolls

© SAP 2008

Hier eine beispielhafte Ausgabe der Protokolldatei. „ Um sich auch später im Database Studio den Inhalt des Trace-Protokolls anzeigen zu lassen, wählen Sie innerhalb der Diagnosedateien den Eintrag Database Trace (readable) aus und öffnen ihn. „

© SAP AG

ADM515

7-50

Datenbank-Trace: spezielle Trace-Optionen

© SAP 2008

Nach Abschluss der Aktionen, von denen Sie einen Trace erzeugen wollen, müssen die TraceInformationen aus dem Speicher in die Datei knltrace geschrieben werden. Wählen Sie Database Trace ÖFlush um diese Aktion unabhängig auszuführen. „ Mit dem Menüpunkt Database Trace ÖClear können die Trace-Infos gelöscht werden. Dabei gehen alle Informationen aus dem Trace verloren. „

© SAP AG

ADM515

7-51

Kerneltrace im DBA-Cockpit

© SAP 2008

„

Alle Funktionen des Database Studios im Zusammenhang des Kerneltraces können ebenfalls über die DB50 ausgeführt werden.

© SAP AG

ADM515

7-52

Speicherauszug der MaxDB: Datei knldump

Enthält das globale Memory, u.a.: Sperrlisten, Data-Cache, Rollback-Cache, Catalog-Cache, ... „ Verwaltungsstrukturen für diese Caches „

Diese Datei wird auf folgende Art erzeugt: „

im Database Manager CLI z.B. beim Stoppen der Datenbank db_stop –dump

„

bei einem Datenbankabsturz

Die Datei knldump kann sehr groß werden. Sie wird im Binärformat erzeugt und lässt sich nur mittels interner Diagnosewerkzeuge lesen.

© SAP 2008

UNIX: Es wird kein Dump geschrieben, wenn die Datenbank durch ein UNIX-Signal abstürzt. „ Zur Analyse müssen die Betriebssystemtools (debugger) zusätzlich installiert sein. „

© SAP AG

ADM515

7-53

Performance-Tuning und Problemsituationen: Übersichtsdiagramm Performance-Tuning und Problemsituationen Thema 1: B*-Bäume Thema 2: Optimierung Thema 3: Monitore des SAP Netweaver Thema 4: Vermeidbare Probleme Thema 5: Diagnosedateien und Trace-Möglichkeiten Thema 6: Fehlerarten und deren Analyse

© SAP 2008

© SAP AG

ADM515

7-54

Häufige Fehler

Probleme beim Verbindungsaufbau SQL-Fehler (z.B. falsche Ergebnismengen) „

reproduzierbarer Effekt?

Systemfehler (Fehlernummern -10000 bis -9000) „

mit oder ohne Absturz, reproduzierbar?

Hardwarefehler Sicherungs-/Wiederherstellungsfehler „

Sicherung überprüfen

Konfigurationsfehler „

Help-Portal (http://help.sap.com)

© SAP 2008

In der Regel brechen Transaktionen bei einem SQL-Fehler mit einem Kurz-Dump ab (Transaktion ST22). Weitere Informationen erhalten Sie mit Hilfe der Transaktionen ST05 und SM21. Ebenso können die Datenbank-Diagnosedateien weiterhelfen (DB50: Problemanalyse → Meldungen). Ggfs. müssen Traces (Precompiler-Trace oder/und Datenbank-Trace) eingeschaltet und analysiert werden. „ Die Systemfehler sind schwerwiegende Fehler und werden in den Transaktionen SM21 und ST22 oft als Fehler –602 protokolliert. Die eindeutige Fehlernummer ist in der Datei knlMsg zu finden. „

Wenn Sie Probleme beim Sichern oder Wiederherstellen haben, dann analysieren Sie die Protokolle des Database Manager, z. B. mit dem Database Studio oder im CCMS (Transaktion DB50, Problemanalyse → Protokolle). „ Zusätzlich zu den Diagnosedateien sollten dem Support auch Informationen über weitere Aktionen, wie z.B. durchgeführte Releasewechsel, das Einspielen neuer Software, Betriebssystemwechsel etc. zur Verfügung gestellt werden. „ Vorsicht! Das Konzept der Ablage und Einstellung der MaxDB für das SAP Umfeld (z.B. SAP Netweaver, Contentserver u.v.m.) sieht im Einzelnen sehr verschieden zu dem aus, was auf manchen MaxDB-Webseiten angegeben ist (andere Verzeichnisse, andere Datenbankbenutzer). Dieses ist hauptsächlich mit den Standardisierungsbemühungen im United Linux und in der Linux Standard Base begründet. Daher bei Konfigurationsfragen bitte zuerst die Installationsleitfäden bzw. das SAP Hilfesystem beachten (u.a. Hinweis 327578). „

© SAP AG

ADM515

7-55

Fehlersituation: Verbindungsaufbau

Datenbank nicht aktiv oder nicht im entsprechenden Betriebszustand oder X-Server nicht aktiv „

Meldung:

„

Neustart der Datenbank

„

Start des X-Server (unter Windows NT wird er als Service automatisch gestartet)

-807: CONNECTION DOWN, SESSION RELEASED -709: CONNECT FAILED, CHECK SERVERDB

XUSER-Einträge überprüfen (Hinweis 39439) Test der Korrekturen durch Verbindungsaufbau Erstellen eines Precompiler-Traces bei weiterhin bestehendem Fehler Auswertung

© SAP 2008

„

Wenn Probleme bei der Verbindung des SAP-Systems zur Datenbankinstanz auftreten, dann sollten Sie auf jeden Fall einen Blick in die DEV-Protokolle werfen (die Dateien dev_w* aus dem Arbeitsverzeichnis des SAP Netweavers). Wenn die dort zu findenden Informationen nicht zur Fehlerbehebung ausreichen, kann ein Test der folgenden Tools (ggfs. mit Precompiler-Trace über SQLOPT) und der dabei erzeugten Log-Dateien (trans.log bzw. dbslada.pct) weiterhelfen: set SQLOPT=-X R3trans –x tp connect <SAPSID> []

„

Weiterhin sind die XUSER-Daten zu prüfen. Informationen dazu sind im Hinweis 39439 enthalten.

© SAP AG

ADM515

7-56

Problemanalyse (Systemfehler)

Diagnose bei schweren Fehlern (Fehlernummer -10000 bis -9000) teilweise mit Datenbankabbruch verbunden 1. vor Start der Datenbank Diagnosedateien sichern: „

knltrace, knlMsg

„

falls vorhanden: knldump, rtedump, core

2. nach Absturz versuchen, die Datenbank mit Datenbank-Trace zu starten 3. Prüfen, ob der Fehler mit Datenbank-Trace reproduzierbar ist 4. Support informieren – OSS-Meldung öffnen

© SAP 2008

„

Die Diagnosedateien müssen nur explizit gesichert werden, wenn sie nicht automatisch in das Verzeichns des MaxDB-Parameters DiagnoseHistoryPath kopiert wurden.

© SAP AG

ADM515

7-57

Fehlersituation: Hardware

Meldungen in Datei knlMsg -902 I/O Error „ -9026 Bad Datapage „

Fehlernummern -10000 bis -9000: „

Support informieren – OSS-Meldung öffnen

Überprüfen der Protokolle von Festplatten-Subsystemen usw. Ist der Log- oder Data-Volume korrupt ? Ersatz der defekten Festplatte Wiederherstellen der Plattenbereiche Abschließende Konsistenzprüfung einplanen „ „

Konsistenz der B*-Bäume überprüfen Auführung kann mit CCMS (DB13) eingeplant werden oder mit dem Database Studio interaktiv erfolgen

© SAP 2008

„

Siehe auch SAP Hinweis 839333 (FAQ: MaxDB Fehler-Diagnose-> korrupte Daten-Pages)

© SAP AG

ADM515

7-58

Performance-Tuning und Problemsituationen: Zusammenfassung

Sie können nun: „

Die Struktur der Tabellen und Indexe in der MaxDB beschreiben

Problemsituationen erkennen und beheben „ MaxDB Performance analysieren „

© SAP 2008

© SAP AG

ADM515

7-59

© SAP AG

ADM515

7-60

Übungen Kapitel: 6 Thema: Problemsituationen und Performance-Tuning Am Ende dieser Übungen können Sie: • Informationen über die Ablage von Daten in der MaxDB erhalten • Die Statistiken der Datenbank auf den aktuellen Stand bringen • Indices erzeugen und Diagnosen zu Performanceproblemen durchführen Um Performanceprobleme frühzeitig zu erkennen, werden in den Übungen die Tools praktisch vorgestellt. Damit kann schon bei der Entwicklung von Eigenanwendungen als auch bei der späteren Optimierung auf die Eigenschaften der MaxDB eingegangen werden.

6-2

6-1

Update Statistics

6-1-1

Überprüfen Sie den Status der aktuellen Statistiken mit Hilfe des Kommandos dbmcli -U c –uSQL –c INFO UPDSTAT (Vergleichen Sie diese Angaben am Ende dieser Übung)

6-1-2

Die Funktion eines Updates der Tabellenstatistiken einer einzelnen Tabelle können Sie über folgendes dbmcli-Kommando ausführen: dbmcli -U c sql_updatestat estimate sample 1000 rows Aktualisieren Sie die Statistiken der Tabelle POPULATION. Bitte vergleichen Sie dieses mit der Protokolldatei des Database Manager (dbm.prt) im Arbeitsverzeichnis (Parameter: RUNDIRECTORY) .

6-1-3

Kontrollieren Sie nun anhand der Zeitstempel im dbmcli -U c –uSQL –c INFO UPDSTAT ob der Update Statisitics für alle Tabellen ausgeführt wurde.

Optional: Analyse des Baums der Tabelle Population 6-2-1

© SAP AG

Mit dem folgenden SQL-Kommando können Sie Informationen über die Tabelle Population und deren Primärschlüssel ermitteln: SELECT description, numeric_value FROM tablestatistics WHERE owner=’SAPR3’ AND tablename=’POPULATION’

ADM515

7-61

6-2-2

6-3

Optional: Ermittlung eines Explains 6-3-1

6-4

6-5

Die Informationen über den Sekundärindex können Sie mit dem SQLKommando SELECT description, numeric_value FROM indexstatistics WHERE owner=’SAPR3’ AND tablename=’POPULATION’ erhalten. Sollte noch kein Sekundärindex auf der Tabelle existieren, legen Sie ihn mit dem SQL-Statement aus den Unterlagen an.

Bitte führen Sie im SQL-Editor im Database Studio für die bestehende Tabelle Population SQL-Statements aus, für die Sie anschließend ein Explain ermitteln, z.B.: EXPLAIN SELECT * FROM population WHERE city LIKE ’A%’ Vergleichen Sie bitte die Ausgabe mit der in den Unterlagen zur Transaktion ST05.

Resource und Kommando Monitor 6-4-1

Binden Sie Ihre Testdatenbank T<xx> mit Hilfe der DB59 in den WebAS ein und testen die Verbindung mit dem dort angebotenen Verbindungstest. Per Doppelklick auf den neuen, von Ihnen angelegten Eintrag in der DB59 können Sie die DB50 „MaxDB Datenbankassistent“ für Ihre Instanz starten.

6-4-2

Starten Sie bitte den Resource und Kommando Monitor über die Transaktion DB50 „MaxDB Datenbankassistent“ für Ihre Instanz wie in den Unterlagen beschrieben. Beim Resource Monitor muß dieser explizit mit einem Button gestartet werden, während der Kommando Monitor implizit beim Bestätigen der Parameterbox gestartet wird.

6-4-3

Führen Sie einige ihrer filldb.py wie aus den letzten Übungen bekannt aus, und beobachten die Protokollierungen im Kommando und Resource Monitor

6-4-4

Kontrollieren Sie bitte, welche Statements, bei diesen Zugriffen ausgeführt werden und ob diese evt. optimierbar sind.

MaxDB Datenbank Analyzer Der MaxDB Datenbank Analyzer ist auf Ihrer Testdatenbank installiert. 6-5-1

© SAP AG

Sie können ihn mit der Transaktion DB50 für Ihre Datenbank T aktivieren oder über das Database Studio direkt aktivieren. Alternativ können Sie den DBanalyzer auch ohne explizite Angabe von User und Paßwortinformationen über dbmcli –U c dban_start starten, wie es in den Unterlagen beschrieben ist. Weitere Infos dazu auch unter http://help.sap.com

ADM515

7-62

6-6

© SAP AG

6-5-2

Wenn genügend Daten gesammelt wurden, können Sie den DBanalyzer mit dem Kommando dbanalyzer –d <SID> -u superdba,admin –o -stop beenden. Bitte schauen Sie durch das Protokollverzeichnis, daß Sie beim Start des DBanalyzers angegeben haben. Sie werden dort eine Menge Dateien zu verschiedene Themen wie Zugriffen, Verbrauch und Performance finden, die in einem Format vorliegen, das leicht mit Ihrem Kalkulationsprogramm graphisch aufgearbeitet werden kann.

6-5-3

Optional: Zusätzlich können Sie vom Schulungssystem DEV zu Ihrer Schulungsdatenbank T die DB50 nutzen, um Ihre DB zu administrieren. Damit können Sie auch die Funktionen des DBanalyzers von dort aus nutzen und auswerten.

Optional: Trace des Datenbankkern starten 6-6-1

Starten Sie Ihre Datenbank in Admin und aktivieren den Kerneltrace wie in den Unterlagen beschrieben.

6-6-2

Wechseln Sie nun den Betriebszustand der Datenbank nach Online und führen die Abschlußarbeiten für einen Kerneltrace (Flush) durch. Werten Sie den binären Kerneltrace aus.

6-6-3

Vergewissern Sie sich, daß die Tracedateien geschrieben wurden. Welche Dateien sind für den SAP Support interessant.

6-6-4

Optional: Erstellen Sie einen Datenbanktrace einer Ausführung von SQLStatements auf Ihrer persönlichen Datenbank (evt. mit filldb.py) unter Verwendung der DB50 und den dort enthaltenen Funktionen zum Datenbanktrace.

ADM515

7-63

© SAP AG

ADM515

7-64

Lösungen Kapitel: 6 Thema: Problemsituationen und Performance-Tuning

6-1

6-2

6-3

Update Statistics 6-1-1

Ebenso können Sie im SQL Studio die Tabelle/View INFO_UPDSTAT unterhalb des Users Domain einsehen. Dies empfiehlt sich besonders, wenn die Anzahl der Tabellen sehr hoch ist, wie z.B. in einer vom R/3 genutzten Datenbank: Anmeldung an dbmcli in einer SQL-Session: dbmcli -U c –uSQL Ausführung des SQL-Statements am Prompt des dbmcli (z.B. dbmcli on T): sql_execute select * from INFO_UPDSTAT where “Table Name“=’’ Desweiteren bleibt auch immer die Möglichkeit, direkt in die Tabelle „TABLES“ zu schauen und dort diese Angaben zu ermitteln.

6-1-2

Das Database Manager Protokoll ist im Instanzbaum unter dem CONTROL-User über Database Server → Diagnosis Files → Database Manager Protocol leicht erreichbar.

6-1-3

Ermitteln Sie diese Informationen für die Tabellen erneut und vergleichen die Ausgaben.

Optional: Analyse des Baums der Tabelle Population 6-2-1

Das Kommando können Sie über dbmcli oder dem SQL-Editor im Database Studio absetzen.

6-2-2

Der Sekundärindex kann mit dem SQL-Kommando CREATE INDEX IDX_Inhabitants ON Population (INHABITANTS DESC) erstellt werden.

Optional: Ermittlung eines Explains 6-3-1

6-4

© SAP AG

Die Ausgabe entspricht der Anzeige in der Transaktion ST05.

Kommando und Resource Monitor 6-4-1

Bitte gehen Sie entsprechend der Beschreibung in den Unterlagen (Kapitel 6) vor und binden Ihre Datenbankinstanz T in der DB59 ein.

6-4-2

Es ist wichtig, den Einstieg über die DB59 zu verwenden, damit Sie auch Ihre private Testdatenbank administrieren. Ansonsten landen Sie auf der Datenbank DEV, der Netweaver-eigenen Datenbank..

ADM515

7-65

6-5

6-4-3

Mit dem Laden der Daten werden SQL-Statements ausgeführt, die viele Aktionen auf der DB ausführen. Wir hoffen, diese Statements in den Monitoren einfangen zu können.

6-4-4

Ein Doppelklick auf ein Tabelleneintrag in Kommando und Resource Monitor ermöglicht uns, diese Statements zu analysieren. Es werden dort Absprünge in Tabellendaten und ABAP-Coding angeboten.. Nur mit dem Kommando Monitor und den dort angezeigten Statements können Sie ein Explain des SQL Statements erstellen. Bewerten Sie die gesammelten Informationen.

MaxDB Datenbank Analyzer MaxDB bietet mit dem Database Analyzer einen umfangreichere Datensammlung und einen sicheren Betrieb dieser Analysemethode.

6-6

© SAP AG

Optional: Trace des Datenbankkern starten 6-6-1

Gehen Sie entsprechend der Unterlagen vor: Starten der Datenbank nach Admin mit Set State → Admin. Aktivieren des Trace im Kontextmenü Ihrer Datenbankinstanz unter → Database Trace. Anschließend werden die entsprechenden Optionen gesetzt.

6-6-2

Starten der Datenbank nach Online mit Set state → Online. Damit wird die Aktivitäten beim Start der Datenbank überwacht und protokolliert. Anschließend müssen diese Daten per Flush in den binären Datenbank-Trace geschrieben werden und mit → Database Trace und dann → Generate Ausgabeoptionen setzen und auswerten.

6-6-3

Anschließend sollten Sie eine Datei <SID>.prt im Verzeichnis G:\sapdb\data\wrk\<SID>\ finden. Die Analyse der Ausgabedateien erfolgt üblicherweise durch den SAP Support. Unterstützen Sie bitte den SAP Support indem Sie es ermöglichen, daß eine Remoteverbindung zu Ihrer Datenbank möglich ist. Dieses beschleunigt die Fehlersuchen grundsätzlich.

6-6-4

Diese Funktion in der DB50 ermöglicht es uns im laufenden Betrieb der Datenbank von remote wichtige Traces komfortable anzulegen und gleich auswerten zu können.

ADM515

7-66

Ausblick auf MaxDB 7.8

Inhalt: „

Ein Ausblick auf die aktuelle Planung für die nächste Version MaxDB 7.8

© SAP 2008

© SAP AG

ADM515

8-1

Ausblick auf MaxDB 7.8: Lernziele

Am Ende dieses Kapitels können Sie: „

Einen Überblick über die neuen geplanten Funktionen der MaxDB 7.8 geben.

© SAP 2008

© SAP AG

ADM515

8-2

Agenda I

1. Der erste Kontakt 1.1. 1.2. 1.3. 1.4. 1.5. 1.6.

3. MaxDB-Interna

Einführung Werkzeuge und Schnittstellen Architektur und Betriebszustände MaxDB und SAP NetWeaver Integration mit SAP NetWeaver Serverlandschaft der Schulung

3.1. 3.2. 3.3. 3.4. 3.5.

4. Datenbanksicherung und -wiederherstellung

2. MaxDB betreiben 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8.

Prozesse Sperren Speicherbereiche Plattenbereiche Logging

Überblick Database Studio Wichtige Informationsquellen im Database Studio Benutzer der MaxDB im SAP-Umfeld Plattenbereiche für Daten und Log Konfigurationsänderungen DBFULL und LOGFULL Situationen Parameter Übungswerkzeug

4.1. 4.2. 4.3. 4.4. 4.5. 4.6. 4.7. 4.8. 4.9.

Vollständige Datensicherung Inkrementelle Datensicherungen MaxDB Snapshots Log-Sicherungen Automatische Log-Sicherung Überprüfen der Sicherungen Sicherungsstrategie Externe Sicherungstools Wiederherstellungen

© SAP 2008 / Page 1

© SAP AG

ADM515

8-3

Agenda II

5.

Weitere Administrationsthemen 5.1. 5.2. 5.3. 5.4. 5.5. 5.6. 5.7.

7.

Prüfen der Datenbank Erstellen einer Datenbankinstanz Neuinitialisierung einer Datenbankinstanz Installation eines Patches (Releasewechsel) Migration zur MaxDB Hochverfügbarkeit MCOD

Ausblick auf MaxDB 7.8 7.1. 7.2. 7.3. 7.4. 7.5.

Übersicht Änderungen des Datenbankkerns Neue administrative Funktionen Setup und Infrastruktur Interface & User

6. Performance-Tuning und Problemsituationen 6.1. 6.2. 6.3. 6.4. 6.5. 6.6.

B*-Bäume Optimierung Monitore des SAP NetWeaver Vermeidbare Probleme Diagnosedateien und TraceMöglichkeiten Fehlerarten und deren Analyse

© SAP 2008

© SAP AG

ADM515

8-4

Ausblick auf MaxDB 7.8: Übersichtsdiagramm

Ausblick auf MaxDB 7.8 Thema 1: Übersicht Thema 2: Änderungen des Datenbankkerns Thema 3: Neue administrative Funktionen Thema 4: Setup und Infrastruktur Thema 5: Interface & User

© SAP 2008

© SAP AG

ADM515

8-5

Haftungsausschluß

„ Der

in diesem Kapitel gegebene Ausblick auf neue Funktionen zukünftiger MaxDB-Versionen entspricht dem aktuellen Planungsstand und unterliegt evt. notwendigen zukünftigen Anpassungen. Daher kann es u.U. passieren, daß hier beschriebene Funktionen auf unbestimmte Zeit verschoben werden.

© SAP 2008

© SAP AG

ADM515

8-6

Übersicht

Änderungen des Datenbankkerns MVCC (Multiversion Concurrency Control) „ XA-Interface für verteilte Java-Transaktionen „ Neue B*-Baumstrukturen „ Automatisierung der Clusterung „ Ausgleichsfunktionen zwischen Daten-Volumes „ Änderungen von Parametern „

Neue administrative Funktionen Check Data auf Snapshots mit anschließender Sicherung „ Komprimierung und Verschlüsselung von Sicherungen „ Externe Snapshots in Sicherungshistorie „

Setup & Infrastruktur „

Isolierte Installation

Interface & User „

Database Studio mit vollem Funktionsumfang

© SAP 2008 / Page 1

© SAP AG

ADM515

8-7

Verfügbarkeit

MaxDB 7.8, wird im OLTP Umfeld für 2009 erwartet Zusammen mit dem Netweaver 7.2 „ Generelle Verfügbarkeit für 2009 erwartet „

„

Freigabe der MaxDB 7.8 für ältere Releases des SAP Netweaver wird später wahrscheinlich erfolgen (bis zurück zum SAP Kernel 6.40_EX2)

© SAP 2008 / Page 1

© SAP AG

ADM515

8-8

Ausblick auf MaxDB 7.8: Übersichtsdiagramm

Ausblick auf MaxDB 7.8 Thema 1: Übersicht Thema 2: Änderungen des Datenbankkerns Thema 3: Neue administrative Funktionen Thema 4: Setup und Infrastruktur Thema 5: Interface & User

© SAP 2008

© SAP AG

ADM515

8-9

Multiversion Concurrent Commit (MVCC)

Technik seit Jahren genutzt im Umfeld SCM mit dem SAP liveCache (MaxDB) Dort bisher für Objekte implementiert Ab MaxDB 7.8 gibt es diese Technik der konsistenten Sichten auch für OLTP Vorteil: „

Sperrsituationen können vermieden werden

„

Bisher wurde mit Sperren gearbeitet, um eine vergleichbare Funktion zu erhalten

Nachteil: „

Höherer Verwaltungsaufwand für gleichzeitig laufende Transaktionen bzw. SQL-Statements

„

Garbage Collector muß obsolete Daten erkennen und löschen

Implementierung im Umfeld des SAP Netweaver: „ „

Isolation Level 50 Ö Konsistente Sichten nur für den gleichen Cursor (SQL-Statement) Reduziert Aufwand für Historie

Alternative Implementierungen: „

Isolation Level 60 Ö Konsistente Sichten ab erstem SQL-Statement in Transaktionen

„

Viel Historie bei vielen Transaktionen. Selbst inaktive Transaktionen können viel Historie “festhalten”

© SAP 2008

© SAP AG

ADM515

8-10

MVCC – konsistente Sichten

Alle Lesezugriffe liefern die Darstellung eines Datensatzes, die zu einem bestimmten Zeitpunkt festgeschrieben (committed) wurde. Dieser Zeitpunkt ist identisch für alle Datenzugriffe einer Transaktion oder SQLStatements. Beispiel für das Lesen mit impliziten konsistenten Sichten: T1

T3

Setzt s=3 Commit

Setzt s=7 Commit

T4

Erstes Lesen

Liest s s=3

T2

Erstes Lesen

Liest s s=7

T5

Liest s s=7

Zeit © SAP 2008

© SAP AG

ADM515

8-11

MVCC – konsistentes Lesen mit HistoryDateien T2

Setzt s=15 Commit

T3

Setzt s=3

T4

Commit

T5

Setzt s=7 Commit

T6

Setzt s=8

Liest s

Erstes Lesen

s= 15

History-Dateien T3 s (15)

Tabelle

T4

T5 ss (15) (8)

s (3)

T6 s (7)

© SAP 2008 / Page 1

© SAP AG

ADM515

8-12

XA-Interface für verteilte Java-Transaktionen

Neue Funktion für Java-Umgebungen: XA-Interface wird als Standard unterstützt MaxDB stellt two-phase COMMIT für die Ausführung von verteilten Transaktionen bereit Transaktion Manager (Java)

Aktuell keine Kombination von XA und MVCC möglich, zukünftig ja

Applikation (Java)

XAInterface

XAInterface

Resource Manager

MaxDB

© SAP 2008 / Page 1

© SAP AG

ADM515

8-13

Neue B*-Baumstrukturen

Zuerst für temporäre Daten Teile des neuen B*-Baumes können auf Datenplatten ausgelagert werden und in anderen Teilbäumen weiterwachsen. Geändertes Sperrverhalten: Bietet dort auch Sperren auf Unterbäumen Variable Ablage In Zukunft weitere Überarbeitungen in allen Bereichen der MaxDB

© SAP 2008 / Page 1

© SAP AG

ADM515

8-14

Automatisierung der Page-Clusterung

Ziel: Page-Clusterung erfolgt automatisch mit Wechsel auf neuen Patch im Hintergrund. „ Eine aktive Umsetzung von Tabellen auf Page-Clusterung wird nicht mehr nötig sein. „

Die Page-Clusterung wird Standardeinstellung. „ Sekundärindexe werden ebenfalls automatisch auf Page-Clusterung umgestellt „

Vorgehensweise: „

Während Scans auf den Tabellen oder Sekundärindexen laufen, erkennt die MaxDB Datenstrukturen mit schlechter Page-Clusterung und wird aktiv. Sie markiert diese Pages und wird beim nächsten SAVEPOINT den zugehörigen Page-Cluster neu erstellen und auf die Daten-Volumes schreiben.

© SAP 2008 / Page 1

© SAP AG

ADM515

8-15

Änderungen im Bereich Volume und Sicherung

MaxDB-Parameter MaxVolumes wird ausrangiert MaxDB-Parameter MaxDataVolumes wird default auf 255 (READ ONLY) gesetzt. „

Schon in 7.7 und dem neuen IO-Konzept ist der Speicherbedarf im IO-Management nicht mehr von der Anzahl der Daten-Volumes abhängig.

„

Daher kann ab 7.7.04 der MaxDB-Parameter MaxDataVolumes schon problemlos auf 255 gestellt werden, ohne überflüssigen Speicherbedarf.

MaxDB-Parameter MaxBackupMedia wird per default auf 8 Geräte erweitert

© SAP 2008 / Page 1

„

„

Durch die Erhöhung des Parameters MaxDataVolumes wird ab MaxDB 7.7.04 nicht mehr unmäßig Speicher für ungenutzte DEV-Prozesse verschwendet. (Mit den DEV-Prozessen wurde pro DEVProzeß 1 MB verbraucht und mit vielen Daten-Volumes kam es zu einer enormen Vervielfältigung des Speicherbedarfs.) Da der MaxDB-Parameter MaxBackupMedia nicht im Betriebsmodus Online geändert werden kann, wird er mit MaxDB 7.8 auf den Vorgabewert 8 (zuvor 2) erhöht. Damit sollte die Notwendigkeit der Erhöhung diese Parameters nur noch in Ausnahmefällen auftreten.

© SAP AG

ADM515

8-16

Ausblick auf MaxDB 7.8: Übersichtsdiagramm

Ausblick auf MaxDB 7.8 Thema 1: Übersicht Thema 2: Änderungen des Datenbankkerns Thema 3: Neue administrative Funktionen Thema 4: Setup und Infrastruktur Thema 5: Interface & User

© SAP 2008

© SAP AG

ADM515

8-17

Check Data auf MaxDB-internen Snapshots

Ein Check Data erzeugt bis inklusive MaxDB 7.7 Sperren auf der aktuell untersuchten Tabelle Mit weiterem produktiven Betrieb kann es daher Sperrkollisionen geben Ansatz um eine Sperre zu vermeiden ist, einen ONLINE-Snapshot innerhalb der MaxDB zu verwenden Der Snapshot friert den Datenbestand zu einem bestimmten Zeitpunkt ein und eine Sperre ist nicht mehr notwendig Als Bonus wird anschließend noch die Option angeboten, den überprüften Snapshot direkt zu sichern.

© SAP 2008

Empfehlung bis MaxDB 7.7 zur Umgehung dieser Sperren ist, ein Check Data auf dem entsprechenden Q-System nach einem Restore einer Sicherung vom Produktivsystem durchzuführen. Nach erfolgreichem Durchlauf kann im Rückschluß bestätigt werden, daß auch das Originalsystem fehlerfrei ist. „ Alternativ kann auch ein Split-Mirror-Setup genutzt werden, um auf einem ausgegliederten Spiegel einen Check Data auszuführen, der das Business dann nicht stören kann. „

© SAP AG

ADM515

8-18

Komprimierung und Verschlüsselung von Sicherungen Erste Implementierungsschritte auf der Ebene des Datenbankkerns sind durchgeführt Unterstützung auf Client-Seite folgt, um Komprimierung und Verschlüsselung innerhalb der Sicherungstemplates definieren zu können Die oft CPU-lastige Komprimierung und Verschlüsselung findet pro Sicherungsstrom auf einer CPU statt. Daher muß diese Funktion mit Bedacht gewählt werden, damit eine Sicherung auf ein achtfaches Sicherungstemplate nicht ein acht-CPU-System lahm legt.

© SAP 2008

© SAP AG

ADM515

8-19

Ausblick auf MaxDB 7.8: Übersichtsdiagramm

Ausblick auf MaxDB 7.8 Thema 1: Übersicht Thema 2: Änderungen des Datenbankkerns Thema 3: Neue administrative Funktionen Thema 4: Setup und Infrastruktur Thema 5: Interface & User

© SAP 2008

© SAP AG

ADM515

8-20

Isolierte Installation – Funktionsweise

Datenbankserver Alter Client, alte Datenbank -d DB76 –n server

Neuer Client, Datenbank 7.8 -d DB7801 –n server

7210

„nutze 7203“

connect

Neuer Client, Datenbank 7.8 -d DB7800 –n server:7206

connect

DB76

Datenbankserver

7210

Globaler X-Server 7.8 (independent)

7203

X-Server (7.8.01)

DB7801

7206

X-Server (7.8.00)

DB7800

Interner Reconnect: -d DB7801 –n server:7203

Neuer Client, Datenbank 7.8 -d DB7801 –n server:7203

Globaler X-Server 7.8 (independent)

© SAP 2008

„ „ „

„ „

„ „

Mit der Isolierten Installation ab 7.8 werden Datenbankinstallation ab dieser Version als eigentständige Datenbanken installiert. Es erfolgt ein kompletter Wechsel der Methodik. Um spezielle Konfigurationsdateien für die Einführung dieser Isolierten Installation überflüssig zu machen, wird ein globaler X-Server genutzt, der die separaten MaxDB-Instanzen und deren Port kennt. Ältere Datenbanken werden weiterhin den globalen X-Server, wie bisher den X-Server, nutzen und die Kommunikation über den Port 7210/tcp betreiben. Mit neueren Clients wird ein Portmapping in der Form betrieben, daß der globale X-Server dem Client mitteilt, auf welchem Port die gewünschte Datenbank läuft. Der Client führt dann einen erneuten Connect auf die gewünschte Datenbank und den dafür erhaltenen Port durch. Das Portmapping-Protokoll wird schon von Clients ab MaxDB-Version 7.6.05 verstanden. Auch kann sich der Client sofort mit dem dedizierten Port der gewünschten Datenbank verbinden, wenn er diesen aus vorherigen Verbindungen kennt.

© SAP AG

ADM515

8-21

Isolierte Installation – Umsetzung

Globaler X-Server muß alle lokalen Datenbankinstallationen und deren Ports kennen X-Server der lokalen Installationen werden vom globalen X-Server gestartet Es wird verschiedene Installationstypen geben (z.B. versteckte Installation) Installationskommentare sind möglich

© SAP 2008

Da der globale X-Server hier der Dreh- und Angelpunkt ist, muß er über die lokalen Datenbanken informiert sein. „ Dieses wird über die Installationssoftware SDBINST sichergestellt. „ Die lokalen X-Server werden von dem globalen X-Server gestartet. „ Um die versionspezifischen Programme der anvisierten Datenbank nutzen zu können, muß das Environmentvariable PATH des Administrators der Datenbank erweitert werden. Daher muß es pro isolierter Datenbankinstanz einen Administrator geben. Ein Mischbetrieb wie früher (ein <sid>adm kann viele MaxDB-Instanzen administrieren) ist damit nicht mehr möglich. „

© SAP AG

ADM515

8-22

Ausblick auf MaxDB 7.8: Übersichtsdiagramm

Ausblick auf MaxDB 7.8 Thema 1: Übersicht Thema 2: Änderungen des Datenbankkerns Thema 3: Neue administrative Funktionen Thema 4: Setup und Infrastruktur Thema 5: Interface & User

© SAP 2008

© SAP AG

ADM515

8-23

Database Studio mit vollem Funktionsumfang

© SAP 2008

© SAP AG

ADM515

8-24

Ausblick auf MaxDB 7.8: Zusammenfassung

Sie können nun: „

Einen Überblick über die neuen geplanten Funktionen der MaxDB 7.8 geben.

© SAP 2008

© SAP AG

ADM515

8-25

---

More Documents from "Tomek Borowski"

Adm515_de_col63_fv

March 2021 0

Nx Mold Wizard Preview

March 2021 0

Copyright © 2024 VBOOK.PUB.