Hochverfuegbarkeit

Herrmann & Lenz
Services GmbH
Hochverfügbarkeit
Johannes Ahrends
Fragen:
1. Welche Ausfallzeiten können Sie tolerieren?
•
Bedenken Sie: Es handelt sich womöglich um den Zeitpunkt, an
dem die Hauptlast erzeugt wird
(z.B. Handel: Samstagmittag in der Weihnachtszeit)
2. Welchen Datenverlust können Sie tolerieren?
•
Gar keinen – ist kaum realisierbar!
Hochverfügbarkeit
Herrmann & Lenz Services
2
Agenda
 Einschränkung der Verfügbarkeit
• Hardwarefehler
• Softwarefehler
• Maintenance
 Lösungen
• Oracle Lösungen
• Quest Shareplex
• Libelle DBShadow
Hochverfügbarkeit
Herrmann & Lenz Services
3
Einschränkung der
Verfügbarkeit
 Hardwarefehler
• Ausfall einer Komponente (CPU, Memory, Controller)
• Ausfall einer Festplatte
• Ausfall eines Rechners
• Ausfall eines Plattensystems
• Ausfall des Rechenzentrums
Hochverfügbarkeit
Herrmann & Lenz Services
4
Einschränkung der
Verfügbarkeit
 Softwarefehler
• Betriebssystemfehler
• Absturz der Anwendung
• Absturz der Datenbank
• Fehler in der Anwendung
• Fehler in der Datenbank
• Anwenderfehler
Hochverfügbarkeit
Herrmann & Lenz Services
5
Einschränkung der
Verfügbarkeit
 Maintenance
• Betriebssystemänderungen
• Anwendungsänderungen
• Oracle Software Änderungen
• Einbau neuer Hardwarekomponenten
• Umzug des Rechners
Hochverfügbarkeit
Herrmann & Lenz Services
6
Hardwarefehler
 Ausfall einer Komponente
• Kein Problem: Fehlertolerantes System
• System läuft ohne bzw. mit minimaler Einschränkung weiter
• Fehlerhafte Komponente wird im laufenden Betrieb getauscht
 Beispiel:
• Oracle 8.1.7 auf Stratus mit HP/UX 11.0
• Erstellung einer Datenbank dauert ca. 4 Stunden
• Ursache: I/O-Durchsatz ca. 2MB/s !!!
Hochverfügbarkeit
Herrmann & Lenz Services
7
Hardwarefehler
 Ausfall einer Festplatte
• Kein Problem: Raid-System
• System läuft (ev. mit geringerer Performance) weiter
• Festplatte Hot-Plugable
 Beispiel
• Oracle 8.1.7 auf Compaq Rechner mit Windows 2000
• Ausfall einer Festplatte in einem Raid-1 System
• Techniker wechselt Platte im laufenden Betrieb
• Beim Einschalten der Spiegelung wird die neue Festplatte auf die
alte kopiert!!!
Hochverfügbarkeit
Herrmann & Lenz Services
8
Hardwarefehler
 Ausfall des Plattensystems
• Kein Problem: Regelmäßiges Backup
• Einspielen des Backups vom letzten Tag
• Einspielen aller verfügbaren archivierten Redolog-Dateien
 Beispiel:
• Ausfall eines Plattensystems unter Windows 2000 mit Oracle
8.1.7
• Beim Einspielen des Backups wurde festgestellt, dass ein Datafile
des System-Tablespaces fehlt, weil es nicht im
Standardverzeichnis lag!!!
=> Oracle Support konnte ca. 90% der Daten wieder herstellen
über ein Tool "orapatch" (liest die Datenbank-Dateien offline)
Hochverfügbarkeit
Herrmann & Lenz Services
9
Hardwarefehler
 Ausfall eines Rechners
• Kein Problem: Oracle Parallel Server
• Die Benutzer melden sich wieder an und werden automatisch auf
einen der verblieblenen Knoten umgeleitet
 Beispiel:
• Oracle Parallel Server 7.3.4 auf 3 x Siemens RM-600
• Ausfall eines Knotens
=> Benutzer werden umgeleitet auf die verbliebenen Knoten
=> 2. Knoten wird zu stark belastet und stürzt ab
=> 3. Knoten soll alle Benutzer übernehmen
=> 3. Knoten stürzt ab
Hochverfügbarkeit
Herrmann & Lenz Services
10
Hardwarefehler
 Ausfall des Rechenzentrums
• Problem: Anwender können nicht arbeiten
• Kein Eingriff durch Administratoren nötig, Systeme fahren
automatisch wieder hoch
 Beispiel:
• 2 x SUN E 6800 mit Oracle 8.1.7 (Replikationslösung)
• Ca. 450 GByte Plattenkapazität
• Beide Rechner an der gleichen Stromversorgung!!!
• Ca. 6 Stunden für den Filesystem-Check!!!
Hochverfügbarkeit
Herrmann & Lenz Services
11
Softwarefehler
 Absturz der Datenbankinstanz
• Geringes Problem: Instanz wird wieder gestartet
• Recovery wird automatisch durchgeführt
• Keine weiteren Aktionen nötig
 Beispiel
• Nach Upgrade von Oracle 8.0.5 auf 8.1.7.3 auf HP/UX 11.0
• Instanz bleibt bei Hochlast stehen (keine Fehlermeldungen)
• Ursache: SHARED_POOL zu klein
• Dauer bis zur Fehlerbehebung: 1 Woche!!!
Hochverfügbarkeit
Herrmann & Lenz Services
12
Softwarefehler
 Fehler in der Anwendung
• Kein Problem: regelmäßiger Export durchgeführt
• Im Fehlerfall werden die entsprechenden Tabellen wieder importiert.
• Wird bei Batch-Operationen genutzt
 Beispiel:
• Euro-Test unter Windows NT mit Oracle 8.0.5
• Vorher: Export des entsprechenden Benutzers
• Nach Tests: Löschen aller Tabellen und Import des Benutzers
=> ORA-01658: unable to create INITIAL extent ...
Warum? Export wurde mit COMPRESS=Y durchgeführt!!!
Hochverfügbarkeit
Herrmann & Lenz Services
13
Softwarefehler
 Anwenderfehler
• Kein Problem: "Kann bei uns nicht vorkommen, die Anwendung
ist ausgetestet!
 Beispiel:
• Frage: Wer hat SQL*Plus auf dem Rechner installiert?
• Antwort: Alle, sonst könnten wir die SQL*Net-Zugriffe nicht testen
Hochverfügbarkeit
Herrmann & Lenz Services
14
Maintenance
 Betriebssystemupgrade
• Kein Problem: Oracle Parallel Server
• Umschalten auf den zweiten Rechner während des Upgrades des
ersten (sog. Rolling Upgrade)
• Wird von Oracle immer noch nicht supportet!!!
 Beispiel
• Betriebssystemupgrade HP/UX 10.20 auf 11.0 (Oracle 7.3.4)
• 7.3.4 unter HP/UX 11.0 64bit nicht supportet
=> Upgrade von 7.3.4 nach 8.0.5 erforderlich incl. DLM-Upgrade
• Kann nur auf beiden Maschinen gleichzeitig durchgeführt werden!
• Dauer: ca. 2 Tage
Hochverfügbarkeit
Herrmann & Lenz Services
15
Maintenance
 Oracle Upgrade
•
Kein Problem: Standby-Datenbank
1. Umschalten auf die Standby-Datenbank
2. Upgrade des Produktionsrechners
3. Standby-Funktionalität umgekehrt aktivieren
4. Umschalten auf das Produktionssystem
5. Ursprüngliche Standby-Funktionalität aktivieren
NICHT MÖGLICH, DA BEIDE SYSTEME FÜR
STANDBY DEN GLEICHEN STAND HABEN
MÜSSEN!!!
Hochverfügbarkeit
Herrmann & Lenz Services
16
Maintenance
 Neues Anwendungsrelease
• Kein Problem: Geplante Auszeit
• Backup des alten Standes
• Einspielen der entsprechenden Upgrade-Skripte
• Testen der Anwendung
• Produktionsstart
 Beispiel:
• Neues Release unter Compaq True64 und Oracle 7.3.4
• Größe der Datenbank: ca. 300 GByte
Geplante Auszeit: 48 Stunden
• Am Schluss noch eine kosmetische Korrektur (Wert für "ungültig" von
NULL auf 9999 gesetzt
=> WHERE-Klausel im Update-Skript vergessen!!!
Hochverfügbarkeit
Herrmann & Lenz Services
17
Lösungsvorschläge
 Hardwarefehler
• High-Availability Lösungen
• Oracle Parallel Server / Real Application Cluster
• Oracle Data Guard
• Oracle Replikation
• Quest Shareplex
• Libelle DBShadow
• EMC2 SRDF
Hochverfügbarkeit
Herrmann & Lenz Services
18
Lösungsvorschläge
 Softwarefehler
• Oracle Data Guard
• Oracle Replikation
• Quest Shareplex
• Libelle DBShadow
• EMC2 BCV
Hochverfügbarkeit
Herrmann & Lenz Services
19
Lösungsvorschläge
 Maintenance
• Oracle Replikation
• Quest Shareplex
Hochverfügbarkeit
Herrmann & Lenz Services
20
ES GIBT NICHT DIE
LÖSUNG FÜR ALLE
PROBLEME!!!
Hochverfügbarkeit
Herrmann & Lenz Services
21
Grundregel
 Regelmäßiges Backup der Datenbank
 Verwendung des Oracle Recovery Managers
• Mit dem Recovery Manager kann man innerhalb weniger Minuten
ein Backup – und Recovery Skript aufsetzen.
Vorbereitungen fürs Backup:
% rman
RMAN>
RMAN>
RMAN>
target=system/manager@SUNDB
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE DEVICE TYPE DISK PARALLELISM 3;
CONFIGURE CHANNEL DEVICE TYPE DISK
FORMAT ="/oradata2/backup/%d_%s_%T";
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR
DEVICE TYPE DISK TO '/backup/%F.ctl';
Hochverfügbarkeit
Herrmann & Lenz Services
22
Grundregel
Befehl für das Backup:
RMAN> BACKUP DATABASE PLUS ARCHIVELOG;
Befehl für das Recovery eines Tablespaces:
RMAN> RESTORE TABLESPACE TOOLS;
RMAN> RECOVER TABLESPACE TOOLS;
RMAN> SQL "ALTER TABLESPACE TOOLS ONLINE";
Hochverfügbarkeit
Herrmann & Lenz Services
23
Lösungsvorschläge (Beispiele)
 Oracle Real Application Cluster
 Standby Datenbank
 Libelle Informatic DBShadow
 No-Data-Loss
 Quest Shareplex
Hochverfügbarkeit
Herrmann & Lenz Services
24
Oracle Real Application Cluster
 Voraussetzungen:
• Identische Hardware (bis auf Anzahl MEM, CPU)
• Identische Oracle Versionen auf den beteiligten Systemen
• Spezielle Betriebssystemkomponente (Clustersoftware)
 Implementierung:
• Gleichberechtigter Zugriff von den beteiligten Rechnern auf eine
Datenbank
• Datenbank muss in der Regel auf sog. Raw-Devices installiert
werden
• Über Oracle Net ist Load-Balancing und Transparent Application
Failover möglich
Hochverfügbarkeit
Herrmann & Lenz Services
25
Real Application Cluster
Instanz A
Redolog
Thread 1
Hochverfügbarkeit
DLM
Datenbank
Herrmann & Lenz Services
Instanz B
Redolog
Thread 2
26
Oracle Real Application Cluster
 Vorteil:
• Kombination von Hardware-Fehlertoleranz und Skalierbarkeit
• Vorhandene Anwendungen können weiter verwendet werden
• Schnelle Umschaltungen auf verbleibende Systeme möglich
 Nachteil:
• Kosten
(spezielle Hardware, Betriebssystem und Oracle Lizenzen)
• Kein Schutz bei Plattenfehlern
• Kein Schutz bei Rechenzentrumsausfall
• Kein Schutz vor Software bzw. Anwendungsfehler
• Keine Rolling-Upgrades möglich
Hochverfügbarkeit
Herrmann & Lenz Services
27
Standby Datenbank
 Voraussetzungen:
• Identische Hardware (bis auf Anzahl MEM, CPU)
• Identische Oracle Versionen auf den beteiligten Systemen
 Implementierung:
• Auf einem zweiten System (Schattendatenbank) wird eine Kopie
der Produktionsdatenbank aufgebaut
• Alle archivierten Redolog-Dateien werden auf die
Schattendatenbank übertragen und dort "recovered"
• Schattendatenbank kann für lesenden Zugriff geöffnet werden,
dann erfolgt aber kein Recovery!
Hochverfügbarkeit
Herrmann & Lenz Services
28
Standby-Datenbank
Copy
LGWR
Recovery
ARC0
Datenbank
Datenbank
Redologs
Sekundäre Datenbank
oder
Schattendatenbank
Primäre Datenbank
Hochverfügbarkeit
Herrmann & Lenz Services
29
Standby-Datenbank
 Vorteil:
• Durch zeitversetzte Übertragung Eliminierung von
Anwendungsfehlern
• Räumliche Trennung auch über Kilometer
• Kostengünstig (?)
 Nachteil:
• Aufwendiger Umschaltvorgang
• Keine Übertragung von Strukturänderungen
• Zweites System kann nicht produktiv genutzt werden
• Keine Rolling-Upgrades möglich
Hochverfügbarkeit
Herrmann & Lenz Services
30
Data Guard
 Oracle Software für das Einrichten und die Pflege von
Standby Datenbanken
 Wizard-basierte Konfiguration von StandbyDatenbanken
 Automatische Übertragung der Redolog-Dateien
 Alert-System über Oracle Enterprise Manager
Advanced Events
 Nur für Enterprise Edition
Hochverfügbarkeit
Herrmann & Lenz Services
31
Libelle DBShadow
 Automatische Konfiguration der Standby-Datenbank
 Automatische Übertragung von Stukturänderungen
 Einfache Umschaltmechanismen
 Eigene Agenten überwachen die Produktion und die
Standby Datenbank
 Unterschiedliche Verzögerungen für bestimmte Zeiten
möglich
 Möglichkeit, Online-Redolog-Dateien nachzupflegen!
Hochverfügbarkeit
Herrmann & Lenz Services
32
Hochverfügbarkeit
Herrmann & Lenz Services
33
No-Data-Loss
 No-Data-Loss Konfiguration (ab Version 9.0)
• Jede Transaktion wird lokal und Remote eingetragen
• Kein Transaktionsverlust
 Vorteil (gegenüber Standby):
• Einzige Software-Lösung ohne Datenverlust!
 Nachteil (gegenüber Standby):
• Die Gesamtverfügbarkeit hängt jetzt von der Verfügbarkeit der
Einzelkomponenten (beide Rechner + Netzwerk) ab
• Nur Enterprise Edition
Hochverfügbarkeit
Herrmann & Lenz Services
34
Quest Shareplex
 Voraussetzungen
• Zwei (oder mehr) Datenbanken mit Schemaobjekten
 Implementierung
• Replikation von Tabellen und Sequences auf Basis der RedologInformationen
• Capture-Prozess liest auf Basis einer Konfigurationsdatei die
entsprechenden DML-Operationen aus den Redolog-Dateien
• Reader-Prozess übernimmt diese Informationen und liest dann die
entsprechenden Datensätze aus der Primärdatenbank aus
• Export – Import übertragen die Datensätze auf die
Sekundärdatenbank
• Post-Prozess führt die entsprechende DML-Operation auf der
Sekundärdatenbank aus
Hochverfügbarkeit
Herrmann & Lenz Services
35
Quest Shareplex
SELECT
LGWR
Export
Import
Reader
Post
Capture
Datenbank
LGWR
Datenbank
Redologs
Redologs
Primärdatenbank
Hochverfügbarkeit
DML
Sekundärdatenbank
Herrmann & Lenz Services
36
Quest Shareplex
 Vorteil:
• Zwei unabhängige Datenbanken
• Rolling Upgrades möglich
• Räumliche Trennung auch über Kilometer
• Zeitversetztes Nachpflegen der Änderungen möglich
 Nachteil:
• Objekte (Tabellen, Sequences) müssen einzeln verwaltet werden
• Keine Übernahme von Strukturänderungen
• Datenverlust möglich (letzten n Transaktionen)
• Kosten (muss für jeden Rechner lizenziert werden)
Hochverfügbarkeit
Herrmann & Lenz Services
37
Weitere Informationen
 www.hl-services.de
 [email protected]
 Schulung:
Oracle9i Datenbank-Administration Kompaktkurs
Hochverfügbarkeit
Herrmann & Lenz Services
38