Oracle Data Guard: Mit oder ohne Broker?

476 Aufrufe

Veröffentlicht am

Mein Vortrag zur DOAG 2013 Konferenz

Veröffentlicht in: Technologie
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
476
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
1
Aktionen
Geteilt
0
Downloads
3
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Oracle Data Guard: Mit oder ohne Broker?

  1. 1. Oracle Data Guard: Mit oder ohne Broker? Dierk Lenz DOAG 2013 Konferenz 21. November 2013
  2. 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. 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. 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. 5. Oracle Data Guard Primär-DB Log Transport & Apply Standby-DB 5
  6. 6. RAC vs. Data Guard? RAC Data Guard Infrastruktur Datenbank Rechner Korruptionen 6
  7. 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. 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. 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. 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. 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. 12. Broker Konfiguration Beispiel CREATE CONFIGURATION 'DGConfig' AS PRIMARY DATABASE IS 'TESTA' CONNECT IDENTIFIER IS TESTA; 12
  13. 13. Broker Regel Nr. 1 • Wenn Broker, dann ausschließlich Broker! – Keine manuellen Parameteränderungen! 13
  14. 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. 15. Switchover und Failover Broker Manuell • Eine Zeile • Schnell in kritischen Situationen • Mehrere Schritte • Abwechselnd Kommandos auf diversen Systemen 15
  16. 16. Failover mit Broker • Reinstate der „failed Primary“ zur sofortigen Verwendung als neue Standby möglich • Setzt Flashback Database voraus 16
  17. 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. 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
  19. 19. Data Guard Manuell Broker Enterprise Manager Observer Fast-Start Failover 19
  20. 20. Vielen Dank für Ihre Aufmerksamkeit! E-Mail dierk.lenz@hl-services.de Twitter @ora1578 http://blog.hl-services.de 20

×