Transcript
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
