Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Herrmann & Lenz Services GmbH Hochverfügbarkeit Johannes Ahrends.

Ähnliche Präsentationen


Präsentation zum Thema: "Herrmann & Lenz Services GmbH Hochverfügbarkeit Johannes Ahrends."—  Präsentation transkript:

1 Herrmann & Lenz Services GmbH Hochverfügbarkeit Johannes Ahrends

2 HochverfügbarkeitHerrmann & Lenz Services2 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) 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! 2.Welchen Datenverlust können Sie tolerieren? Gar keinen – ist kaum realisierbar!

3 HochverfügbarkeitHerrmann & Lenz Services3 Agenda  Einschränkung der Verfügbarkeit Hardwarefehler Softwarefehler Maintenance  Lösungen Oracle Lösungen Quest Shareplex Libelle DBShadow

4 HochverfügbarkeitHerrmann & Lenz Services4 Einschränkung der Verfügbarkeit  Hardwarefehler Ausfall einer Komponente (CPU, Memory, Controller) Ausfall einer Festplatte Ausfall eines Rechners Ausfall eines Plattensystems Ausfall des Rechenzentrums

5 HochverfügbarkeitHerrmann & Lenz Services5 Einschränkung der Verfügbarkeit  Softwarefehler Betriebssystemfehler Absturz der Anwendung Absturz der Datenbank Fehler in der Anwendung Fehler in der Datenbank Anwenderfehler

6 HochverfügbarkeitHerrmann & Lenz Services6 Einschränkung der Verfügbarkeit  Maintenance Betriebssystemänderungen Anwendungsänderungen Oracle Software Änderungen Einbau neuer Hardwarekomponenten Umzug des Rechners

7 HochverfügbarkeitHerrmann & Lenz Services7 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 !!!

8 HochverfügbarkeitHerrmann & Lenz Services8 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!!!

9 HochverfügbarkeitHerrmann & Lenz Services9 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)

10 HochverfügbarkeitHerrmann & Lenz Services10 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

11 HochverfügbarkeitHerrmann & Lenz Services11 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!!!

12 HochverfügbarkeitHerrmann & Lenz Services12 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!!!

13 HochverfügbarkeitHerrmann & Lenz Services13 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!!!

14 HochverfügbarkeitHerrmann & Lenz Services14 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

15 HochverfügbarkeitHerrmann & Lenz Services15 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

16 HochverfügbarkeitHerrmann & Lenz Services16 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!!!

17 HochverfügbarkeitHerrmann & Lenz Services17 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!!!

18 HochverfügbarkeitHerrmann & Lenz Services18 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

19 HochverfügbarkeitHerrmann & Lenz Services19 Lösungsvorschläge  Softwarefehler Oracle Data Guard Oracle Replikation Quest Shareplex Libelle DBShadow EMC2 BCV

20 HochverfügbarkeitHerrmann & Lenz Services20 Lösungsvorschläge  Maintenance Oracle Replikation Quest Shareplex

21 HochverfügbarkeitHerrmann & Lenz Services21 ES GIBT NICHT DIE LÖSUNG FÜR ALLE PROBLEME!!!

22 HochverfügbarkeitHerrmann & Lenz Services22 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 target=system/manager@SUNDB RMAN> CONFIGURE DEFAULT DEVICE TYPE TO DISK; RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 3; RMAN> 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';

23 HochverfügbarkeitHerrmann & Lenz Services23 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";

24 HochverfügbarkeitHerrmann & Lenz Services24 Lösungsvorschläge (Beispiele)  Oracle Real Application Cluster  Standby Datenbank  Libelle Informatic DBShadow  No-Data-Loss  Quest Shareplex

25 HochverfügbarkeitHerrmann & Lenz Services25 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

26 HochverfügbarkeitHerrmann & Lenz Services26 Real Application Cluster Datenbank Redolog Thread 1 Redolog Thread 2 Instanz A Instanz B DLM

27 HochverfügbarkeitHerrmann & Lenz Services27 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

28 HochverfügbarkeitHerrmann & Lenz Services28 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!

29 HochverfügbarkeitHerrmann & Lenz Services29 Standby-Datenbank Datenbank Redologs Datenbank LGWR ARC0 Recovery Copy Primäre Datenbank Sekundäre Datenbank oder Schattendatenbank

30 HochverfügbarkeitHerrmann & Lenz Services30 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

31 HochverfügbarkeitHerrmann & Lenz Services31 Data Guard  Oracle Software für das Einrichten und die Pflege von Standby Datenbanken  Wizard-basierte Konfiguration von Standby- Datenbanken  Automatische Übertragung der Redolog-Dateien  Alert-System über Oracle Enterprise Manager Advanced Events  Nur für Enterprise Edition

32 HochverfügbarkeitHerrmann & Lenz Services32 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!

33 HochverfügbarkeitHerrmann & Lenz Services33

34 HochverfügbarkeitHerrmann & Lenz Services34 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

35 HochverfügbarkeitHerrmann & Lenz Services35 Quest Shareplex  Voraussetzungen Zwei (oder mehr) Datenbanken mit Schemaobjekten  Implementierung Replikation von Tabellen und Sequences auf Basis der Redolog- Informationen 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

36 HochverfügbarkeitHerrmann & Lenz Services36 Quest Shareplex Datenbank Redologs LGWR Datenbank Redologs LGWR Capture Reader ExportImport Post PrimärdatenbankSekundärdatenbank SELECTDML

37 HochverfügbarkeitHerrmann & Lenz Services37 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)

38 HochverfügbarkeitHerrmann & Lenz Services38 Weitere Informationen  www.hl-services.de  info@hl-services.de  Schulung: Oracle9i Datenbank-Administration Kompaktkurs


Herunterladen ppt "Herrmann & Lenz Services GmbH Hochverfügbarkeit Johannes Ahrends."

Ähnliche Präsentationen


Google-Anzeigen