Thomas Tretter, 14. November 2002HA Lösungen1 HA Lösungen im Praxisvergleich 14. November 2002

Thomas Tretter, 14. November 2002HA Lösungen2 Zur Person Thomas Tretter – über 13 Jahre Erfahrung mit Oracle – als Berater und DBA u.a. bei Bosch, Arcor, Lufthansa Systems und Colt Telecom –DOAG Regioleiter Rhein/Main –Oracle Certified Professional (DBA)

Thomas Tretter, 14. November 2002HA Lösungen3 Gliederung des Vortrags Überblick, Oracle Server in HA Umgebungen Single Instance Cluster Lösung Standby Database/Data Guard OPS/RAC Vergleich

Thomas Tretter, 14. November 2002HA Lösungen4 Überblick Einsatz von Oracle Server in HA Umgebungen unter den Gesichtspunkten –Nutzungsmöglichkeiten –Betriebsaspekte –Backup/Restore –Softwareupdates Praxiserfahrungen Vor- und Nachteile Auswahlhilfe, weniger Konfigurationsdetails

Thomas Tretter, 14. November 2002HA Lösungen5 Vorüberlegungen folgende Punkte sind zu berücksichtigen: tolerierbare Ausfallzeit zur Verfügung stehende Resourcen bereitstehendes Budget Umschaltzeit auf Ersatzsystem akzeptierbarer Datenverlust

Thomas Tretter, 14. November 2002HA Lösungen6 Single Instance Rechner Oracle Instance M Plattensubsystem Mount der zugehörenden Platten (M=mirror disk) Klassische Variante Ausfallsicherheit durch redundante Auslegung von HW: Plattensubsystem (Mirror, RAID, Hot Spare ) andere HW Komponenten (Power Supply, Controller) Netzwerk Redundanz Datensicherheit durch Online Backup, Archive-Mode Crash Recovery von Oracle Recovery betrifft u.U. nur Teile der Datenbank Restore aller Daten evtl. sehr zeitaufwändig Teilweise unterstützt durch Tools (z.B. OEM)

Thomas Tretter, 14. November 2002HA Lösungen7 CRASH NODE B Interconnect Heartbeat Clusternode BClusternode A Package ‘Prod’ DB Instance log. IP-Addr Prod- Mounts M Plattensubsystem Package-Switch Mount der zugehörenden Platten (M = mirror disk) Architektur Clusterlösung Package / Servicegroup auf einem Knoten verfügbar Im Crash-Fall: Switch d.h.: Filesysteme mounten log. IP übernehmen DB-Instance hochfahren Listener starten,.....

Thomas Tretter, 14. November 2002HA Lösungen8 Clusterlösung: Nutzungsmöglichkeiten Ausfallsicherheit durch Hardware-Redundanz HW und OS-Fehler sind leicht zu handeln (switch) DB-Corruption, logische Fehler nicht abdeckbar viele DBs auf mehreren Clusternodes kombinierbar Mehraufwand: Clusteradministration / Lizenzkosten

Thomas Tretter, 14. November 2002HA Lösungen9 Clusterlösung: Installation lokal Software wird einmal auf jedem Knoten installiert Fehlerquelle: Parameterfile und Net-Konfiguration –Listener sollte auf logischer IP hören, die aber nicht unbedingt immer dort verfügbar ist –TNS_ADMIN Directory mit der DB switchen (Nachteil bei weiteren DBs) –Parameteränderungen je nach Lage evtl. 2 x nötig –besser: symbolic links verwenden, init.ora mit DB switchen Vorteil bei Patch-Install –inaktiven Knoten patchen, dann switchen und nötige SQL-Aktionen ausführen (Nachteil: Abhängigkeit von anderen DBs)

Thomas Tretter, 14. November 2002HA Lösungen10 Clusterlösung: Installation in Servicegroup/Package Software wird einmal in jedes Package installiert –dadurch kann die gleiche Version mehrfach auf einem Knoten vorhanden sein, wenn mehrere Packages auf diesem laufen Software und Datenbank switchen immer gemeinsam völlige Unabhängigkeit von anderen DBs (z.B. Patches) Listener wird auf logischer IP konfiguriert –kann nur dort vorhanden sein, wo auch das Package läuft eigene Owner der Installationen für jedes Package –unabhängige Umgebung –keine Protection-Probleme oder falsche Zugriffe –profile switcht mit

Thomas Tretter, 14. November 2002HA Lösungen11 Clusterlösung: Backup/Restore - Updates Backup von einem Node / Restore zum anderen Clusternode –je nach Backup-Subsystem evtl. problematisch –z.B. RMAN mit Veritas: benötigt Konfiguration mit alternate Clients –unbedingt Restore-Test auf anderen Knoten durchführen Updates durchführen, wie auf single Nodes –generell neue Versionen in parallele Verzeichnisse –mehrere Versionen / Datenbanken im Package möglich

Thomas Tretter, 14. November 2002HA Lösungen12 Clusterlösung : Beispiel HP- Serviceguard 5 Clusternodes n Packages n log. IP- Addressen n Listener Auszeit für Wartung oder beim Crash: Min Cl -Node 1 Cl -Node 3 Cl -Node 5Cl -Node 4 Cl -Node 2 DB Pack. D DB Pack. G DB Pack. A DB Pack. C DB Pack. F DB Pack. E DB Pack. H DB Pack. B

Thomas Tretter, 14. November 2002HA Lösungen13 Architektur Standby Database

Thomas Tretter, 14. November 2002HA Lösungen14 Nutzungsmöglichkeiten Standby Database Gute Möglichkeit des Disaster Recovery bei physischer Trennung der Datenbanken Bei schneller Übertragung der ausstehenden Logfiles kurze MTTR Keine Performance Beeinträchtigung der Primary Database Standby Database kann im Read Only Modus betrieben werden (8i) Eine Standby Database ist einfacher zu administrieren, als andere Replikationsmechanismen Low Cost Lösung

Thomas Tretter, 14. November 2002HA Lösungen15 Konzept Standby Database (1) Gleiche Oracle Version Aufbau der Filesysteme /oradata1/primary->/oradata1/standby /oradata2/primary->/oradata2/standby Übertragung der Log Dateien Netzwerk Spiegelung Synchron/asynchron Switchover automatisch / transparent ? Konfiguration über Net8

Thomas Tretter, 14. November 2002HA Lösungen16 Konzept Standby Database (2) Fehlererkennung und –behebung für folgende Situationen: Änderung der physischen Datenbankstruktur Create tablespace... Alter tablespace add datafile... Ausfall der Primary Database Backup Statements mit NOLOGGING Option ?

Thomas Tretter, 14. November 2002HA Lösungen17 Einsatz mit Oracle 8i Seit Version 7.3 ständige Verbesserungen: Oracle Managed Recovery recover managed standby database [timeout 20]; Remote Archive Destination direkte Übertragung zur Standby Side Read Only Modus der Standby Database Praktisches Beispiel: Standby Database für Reports zur Verfügung stellen

Thomas Tretter, 14. November 2002HA Lösungen18 Einsatz mit Oracle 9i (1) Graceful switch Data Guard Broker + Data Guard Manager No Data Loss Funktion (guaranteed protection mode) Data Divergence (nur im asynch. mode) Oracle Managed Recovery jetzt im Hintergrund möglich physische DB Änderungen können teilweise nachgezogen werden (STANDBY_FILE_MANAGEMENT = auto, DB_FILE_NAME_CONVERT=(...)

Thomas Tretter, 14. November 2002HA Lösungen19 Einsatz mit Oracle 9i (2) nologging / unrecoverable operations kann durch Konfiguration verhindert werden automatische Zeitverzögerung LOG_ARCHIVE_DEST_2 DELAY=240 Einbindung in OEM (Data Guard Manager) Voraussetzung hierfür ist jedoch ein komplett funktionsfähiges OEM Framework 9i (OEM, OMS, Agent)! Integration von RMAN für Backup/Recovery

Thomas Tretter, 14. November 2002HA Lösungen20 Administration

Thomas Tretter, 14. November 2002HA Lösungen21 Praxisbeispiele (1) Was passiert bei Oracle Upgrade –DB beim Upgrade nicht verfügbar –Standby DB readonly nutzen –Upgrade der Standby Database über Logs

Thomas Tretter, 14. November 2002HA Lösungen22 Praxisbeispiele (2) Verhalten aus Sicht des Client/Application –Konfiguration über Net8 –Namensauflösung über SERVICE_NAME, statt SID

Thomas Tretter, 14. November 2002HA Lösungen23 Praxisbeispiele (3) # Connect String for Production GERTEST1_PRIMARY.WORLD = (DESCRIPTION= (FAILOVER=ON) (LOAD_BALANCE=OFF) (ADDRESS=(COMMUNITY=TCP.world)(PROTOCOL=TCP)(Host=gertest1)(Port=1522)) (ADDRESS=(COMMUNITY=TCP.world)(PROTOCOL=TCP)(Host=gertest1)(Port=1523)) (CONNECT_DATA= (SERVICE_NAME=PROD) (FAILOVER_MODE=(TYPE=SESSION)(METHOD=BASIC)(BACKUP=GERTEST1_FAIL)) ) # Connect String for Production (Failover -> Standby) GERTEST1_FAIL.WORLD = (DESCRIPTION= (ADDRESS=(COMMUNITY=TCP.world)(PROTOCOL=TCP)(Host=gertest1)(Port=1523)) (CONNECT_DATA=(SERVICE_NAME=PROD)) ) # Connect String for Standby GERTEST1_STANDBY.WORLD = (DESCRIPTION= (ADDRESS=(COMMUNITY=TCP.world)(PROTOCOL=TCP)(Host=gertest1)(Port=1523)) (CONNECT_DATA=(SID=STANDBY)) )

Thomas Tretter, 14. November 2002HA Lösungen24 CRASH NODE B Interconnect Heartbeat Clusternode B Clusternode A DB Instance 2 Plattensubsystem OPS / RAC Kommunikation Zugriff auf die shared Volumes ( Raw Devices) Architektur OPS/RAC OPS / RAC Betrieb: 2 oder mehr Instancen mounten die gleiche DB Alle Instancen sind verfügbar gegenseitiges Instance-Recovery DB Instance 1 Daten / Controlfiles Redo Instance 1 Redo Instance 2

Thomas Tretter, 14. November 2002HA Lösungen25 OPS/RAC: Nutzungmöglichkeiten Besonders hohe Verfügbarkeit, da 2. Instance online ist Performance –bis 8i Einbußen bei konkurrierend schreibenden Zugriffen –ab 9i ist Gesamtsystem durch Cache Fusion Funktionalität skalierbar DB-Corruption / logische Fehler auch hier nicht abdeckbar hohe Lizenzkosten Administrationsmehraufwand

Thomas Tretter, 14. November 2002HA Lösungen26 OPS/RAC: Betrieb Primary / Secondary Konfiguration –erste Instance ist die zu verbindende (Listener) –im Crash-Fall wird jeweils verbleibende Instance zur Primary –Parameter active_instance_count = 1 Primary / Primary Konfiguration –beide Instances sind gleichberechtigt zu connecten –im Crashfall wird von verbleibender Instance im Betrieb das Recovery durchgeführt

Thomas Tretter, 14. November 2002HA Lösungen27 OPS/RAC: Betrieb Bestimmte Aktionen bedingen Downtime aller Instances –Statusänderungen (Archiving) –Recovery –Patchinstall Backup (online) benötigt die Archive-Files aller Instancen –alle Instancen haben eigene Redofiles und schreiben Archives –diese werden im Crashfall alle für ein Recovery benötigt

Thomas Tretter, 14. November 2002HA Lösungen28 Vergleichmatrix (1) AnforderungSingle InstanceClusterStandbyOPS/RAC Disaster Recoverynicht möglichdurch enge Verbindung der Knoten eingeschränkt sehr gut, wenn die Standby Site physikalisch weit getrennt ist durch enge Verbindung der Knoten eingeschränkt Failover bei HW Defektnicht möglichautomatisch, schnell, Verbindungsabbruch, Reconnect erst nach Instance Recovery möglich manuell, eher langsamautomatisch, schnell, bei TAF kein Verbindungsabbruch, Reconnect sofort möglich Verlust des online Log (current) Datenverlust, Wiederherstellung nur durch PITR kann durch Konfiguration vermieden werden Datenverlust, Wiederherstellung nur durch PITR kurze MTTR bei Datenfileverlust Restore + Recover je nach Netzwerk und Time Delay sehr schnell Restore + Recover Skalierbarkeitnicht skalierbar gut skalierbar Performanceeinfluss auf Primary DB n/anur eine Instanceje nach Konfiguration u.U. erheblich bei OPS spürbar, bei RAC wesentlich besser

Thomas Tretter, 14. November 2002HA Lösungen29 Vergleichmatrix (2) AnforderungSingle InstanceClusterStandbyOPS/RAC zweite DB/Instance nutzbar n/a nur Read OnlyLoad Balancing, Standby Instance einstellbar planbare Wartung (HW / DB Update) TotalausfallHW gut, DB TotalausfallHW gut, DB Read Only Mode HW gut, DB Totalausfall Fallback Möglichkeiten (logische Datenänderungen) keine bis 8 begrenzt (resetlogs), ab 9 besser keine Kostennormaldoppelte HW, Cluster, keine Oracle Zusatzkosten asymetrische HW möglich, geringe Oracle Zusatzkosten doppelte HW + Cluster, erhebliche Oracle Zusatzkosten Failover Kontrollen/aautomatisch durch Clusterfunktionalität manuell durch DBAautomatisch durch Oracle Server Überwachungsaufwand im Betrieb normal erhöht (Datentransfer zur Standby Site) erhöht (2. Instance) AdministrationsaufwandnormalOS und DB Setup höher DB je nach Konfiguration mittel bis hoch OS und DB hoch