Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Oracle Data Guard: Mit oder ohne Broker?

600 Aufrufe

Veröffentlicht am

Mein Vortrag zur DOAG 2013 Konferenz

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

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

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

×