Oracle Data Guard: Mit oder ohne Broker?
Als PPTX, PDF herunterladen0 gefällt mir814 aufrufe
Das Dokument behandelt Oracle Data Guard und die Vor- und Nachteile der Verwendung eines Brokers für hochverfügbare Datenbanken. Es hebt die wichtigen Konfigurationen und Optionen hervor, die für die Implementierung erforderlich sind, und vergleicht manuelle vs. automatisierte Ansätze. Zudem wird auf die Funktionen des Brokers, einschließlich der Überwachung und automatischen Wiederherstellung bei Ausfällen, eingegangen.
Oracle Data Guard: Mit oder ohne Broker?
- 1. Oracle Data Guard: Mit oder ohne Broker? Dierk Lenz DOAG 2013 Konferenz 21. November 2013
- 2. Herrmann & Lenz Services GmbH Herrmann & Lenz Solutions GmbH • Erfolgreich seit 1996 am Markt • Firmensitz: Burscheid (bei Leverkusen) • Beratung, Schulung und Betrieb/Fernwartung rund um das Thema Oracle Datenbanken • Schwerpunktthemen: Hochverfügbarkeit, Tuning, Migrationen und Troubleshooting • Herrmann & Lenz Solutions GmbH – Produkt: Monitoring Module – Stand auf Ebene 2 2
- 3. Oracle Data Guard Key Facts • Automatisierung aller notwendigen Funktionen für eine Standby-Datenbank • Bestandteil des Oracle-Konzepts für Hochverfügbarkeit • Grundfunktionen enthalten in Enterprise Edition 3
- 4. Log Apply SQL Apply • Basistechnologie: Physische Sicherung, Roll Forward Recovery • Ausgereift, integriert, …. • Rekonstruktion von SQLs aus den Redologs • Einschränkung bzgl. Datentypen • Konkurrenz im eigenen Haus, z.B. Streams, GoldenGate 4
- 5. Oracle Data Guard Primär-DB Log Transport & Apply Standby-DB 5
- 6. RAC vs. Data Guard? RAC Data Guard Infrastruktur Datenbank Rechner Korruptionen 6
- 7. “Must Have” Konfigurationen • FORCE LOGGING – Ansonsten “schwarze Löcher” in der Standby-DB durch NOLOGGING-Operationen • Oracle Net Client-Konfiguration für Primärund Standby-DB – Wird oft vergessen – Aber: Client-Verbindungen nach Switchover oder Failover? 7
- 8. “Nice to Have” Konfigurationen • Standby Redologs – “Ziel”-Redologs für Real Time Apply – Größe entspricht Redologs; Anzahl der Gruppen “+1” • Flashback Database – Zusätzliche Möglichkeiten, z.B. Standby-DB als Test-DB – Voraussetzung für Fast-Start Failover – Benötigt Fast Recovery Area 8
- 9. Data Guard “Optionen” • Real Time Apply – Log Transport durch LGWR statt ARCH – Kein Warten auf den Log Switch • Apply Delta – Vorgegebener Zeitversatz – Ermöglicht Reaktion auf “Logische Fehler” (TRUNCATE TABLE…) 9
- 10. Data Guard • Primär- und Standby-DBs physisch identisch: – DB_NAME identisch – Unterschiedliche DB_UNIQUE_NAMEs! – Präfixe PRIM/STBY und ähnliche ungünstig (weil falsch nach Switchover/Failover) • Erreichbarkeit auf Server-Ebene mit Oracle Net erforderlich – Statische Listener-Einträge empfehlenswert (sowohl für RMAN als auch für Data Guard) 10
- 11. Data Guard Broker • In DB-Server integriert: – Aktivierung mit dg_broker_start = TRUE – Hintergrundprozess DMON • Konfiguration, Überwachung und Automatisierung • Administration mit Kommandozeile (DGMGRL) oder Enterprise Manager Cloud Control • DGMGRL: eigene Syntax! • Startet Managed Recovery nach MOUNT der Standby-DB 11
- 12. Broker Konfiguration Beispiel CREATE CONFIGURATION 'DGConfig' AS PRIMARY DATABASE IS 'TESTA' CONNECT IDENTIFIER IS TESTA; 12
- 13. Broker Regel Nr. 1 • Wenn Broker, dann ausschließlich Broker! – Keine manuellen Parameteränderungen! 13
- 14. Broker Manuell oder mit EM? Broker mit EM • Wizards • Keine manuelle Vorarbeit • Komplexität trotzdem vorhanden Broker Manuell • Mehr Konfigurationsaufwand • Mehr Kontrolle 14
- 15. Switchover und Failover Broker Manuell • Eine Zeile • Schnell in kritischen Situationen • Mehrere Schritte • Abwechselnd Kommandos auf diversen Systemen 15
- 16. Failover mit Broker • Reinstate der „failed Primary“ zur sofortigen Verwendung als neue Standby möglich • Setzt Flashback Database voraus 16
- 17. Fast-Start Failover (FSF) • Unter gewissen Bedingungen: – Automatischer Failover – Auto-Reinstate • Ausschließlich mit Broker • Zusätzliche Komponente auf eigener Maschine: Observer – Integriert in DGMGRL: START OBSERVER; 17
- 18. FSF Diskussion • Zwingend notwendig: Client-Konfiguration (Connect Time Failover) • Ausschluss von Transaktionsverlust nur bei „Zero Data Loss“ Konfiguration • Standortwahl für Observer – Am besten: RZ #3 18
- 20. Vielen Dank für Ihre Aufmerksamkeit! E-Mail dierk.lenz@hl-services.de Twitter @ora1578 http://blog.hl-services.de 20