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 -U -d -n -i -uUTL -uSQL -uSRV
Beispiel für einen Aufruf des Database Manager CLI: dbmcli –n -d -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 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 [] [] Optionen:
-h -u -U -d -n -S -i
SQLMODE
Beispiel für einen Aufruf des Database Manager CLI: sqlcli -n -d -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 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. 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 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 1-1-4 Öffnen Sie die Administrationanzeige des Database Studio im Kontextmenü Ihrer Testdatenbank. 1-1-5 Bringen Sie die Datenbank mit dem Database Studio in den Betriebszustand ONLINE 1-1-6 Wechseln Sie den Betriebszustand der Datenbank 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 -u control,control help aus. Verwenden Sie dabei den Administrationsuser 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 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 -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 -u control,control db_online gestartet und mit dbmcli –d -u control,control db_offline gestoppt werden. Den Administrationsmodus Admin erreicht man per dbmcli –d -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 -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 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//db
adm
SAP NetWeaver-Administration
sapsys,sdba
freie Wahl
adm
SAP NetWeaver-Administration
Administratoren
freie Wahl
SAPservice
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 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 adm sowohl zur Installation als auch zur Administration berechtigt. adm ist der Eigentümer aller SAP NetWeaver-Programmdateien. Im UNIX-Umfeld sollten alle Aktivitäten auf Betriebssystemebene mit 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. 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/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 (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 • adm • SAPservice Datenbankadministration • control
Xuser data
SQL-User Bereich • superdba • domain • sap
• 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 .upc im Config-Verzeichnis sowie dbm.upc im RUNDIRECTORY der DB-Instanz gehalten. Die Registrierungen dieser Administratoren liegen in der Datei .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 ), 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 *** *** 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. 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 (). 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,passwd –d -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 adm IDENTIFIED EXTERNALLY AS ‘adm’ sqlcli -d -u adm “select * from users”
ALTER USER sap IDENTIFIED EXTERNALLY AS ‘adm’ sqlcli -d -u sap “select * from users”
ALTER USER sap DISABLE CONNECT sqlcli -d -u sap “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 show tasks bzw. x_cons 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 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 –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 [] [] ::= -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 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\\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 -u , -data x_python filldb.py -d -u , -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 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
sap
T
SAPR3
c
CONTROL
control
T
INTERNAL
w
SUPERDBA
admin
T
INTERNAL
domain
DOMAIN
domain
T
INTERNAL
SAP
sap
T
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 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 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 umzubenennen. Melden Sie sich dazu mit dem superdba-User an.
2-3-2
Benennen Sie den User SAP zuerst mit dem Kommando rename user sapt to sapr3 um.
2-3-3
Alternativ: Benennen Sie den User per dbmcli um dbmcli -U c –USQL w sql_execute ““
2-3-4
Machen Sie Ihre Änderungen wieder rückgängig rename user sapr3 to sapt dbmcli -U c –USQL w sql_execute ““ 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 2-4-1
Melden Sie sich als User SAP am SQL Editor des Database Studios an. Ändern Sie das Paßwort des Users SAP mit dem SQL-Kommando alter password 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 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 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 -u sarp,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 -u sarp,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 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 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 to sapr3“
2-3-4
Machen Sie Ihre Änderungen mit dem Kommando rename user sapr3 to sap wieder rückgängig.
Die Xuser-Funktionalität nach Änderung des Paßwort vom User SAP 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. Führen Sie das SQLKommando unter dem User SAP alter password to aus. Alternativ können Sie auch das dbmcli-Kommando dbmcli -U c –USQL DEFAULT sql_execute “alter password 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 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 2-6-1
Daten-Volumes: Log-Volumes:
G:\sapdb\\sapdata\... G:\sapdb\\saplog\...
2-6-2
Instanzabhängige Software: Instanzunabhängige Software:
G:\sapdb\\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\\... 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 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\\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 show rte
y oder dbmcli –d -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 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\\db\bin Laufwerk:\sapdb\\db\pgm Laufwerk:\sapdb\\db\sap
Unter UNIX sollten die Pfadinformationen angepasst und im dbenv_. des Datenbankadministrators 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
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//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 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 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/
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/) 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
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 [] [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 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 [VERIFY|NOVERIFY] [REMOVE|KEEP] [FileNumberList|FNL ] Parameter: 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
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 [VERIFY|NOVERIFY] [REMOVE|KEEP] Parameters:
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/
Aktionen der Utility-Task
dbm.utl
/sapdb/data/wrk/
Protokoll der Client-Kommandos
dbm.prt
/sapdb/data/wrk/
/sapdb/data/wrk/
© 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 ..