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?
Dierk Lenz
DOAG 2013 Konferenz
21. November 2013
Herrmann & Lenz Services GmbH
Herrmann & Lenz Solutions GmbH
• Erfolgreich seit 1996 am Markt
• Firmensitz: Burscheid (bei...
Oracle Data Guard Key Facts
• Automatisierung aller notwendigen
Funktionen für eine Standby-Datenbank
• Bestandteil des Or...
Log Apply

SQL Apply

• Basistechnologie:
Physische Sicherung,
Roll Forward Recovery
• Ausgereift, integriert,
….

• Rekon...
Oracle Data Guard

Primär-DB

Log Transport
& Apply

Standby-DB

5
RAC vs. Data Guard?
RAC

Data Guard

Infrastruktur

Datenbank

Rechner

Korruptionen

6
“Must Have” Konfigurationen
• FORCE LOGGING
– Ansonsten “schwarze Löcher” in der Standby-DB
durch NOLOGGING-Operationen

•...
“Nice to Have” Konfigurationen
• Standby Redologs
– “Ziel”-Redologs für Real Time Apply
– Größe entspricht Redologs; Anzah...
Data Guard “Optionen”
• Real Time Apply
– Log Transport durch LGWR statt ARCH
– Kein Warten auf den Log Switch

• Apply De...
Data Guard
• Primär- und Standby-DBs physisch identisch:
– DB_NAME identisch
– Unterschiedliche DB_UNIQUE_NAMEs!
– Präfixe...
Data Guard Broker
• In DB-Server integriert:
– Aktivierung mit dg_broker_start = TRUE
– Hintergrundprozess DMON

• Konfigu...
Broker Konfiguration Beispiel
CREATE CONFIGURATION 'DGConfig' AS
PRIMARY DATABASE IS 'TESTA'
CONNECT IDENTIFIER IS TESTA;
...
Broker Regel Nr. 1
• Wenn Broker, dann ausschließlich Broker!
– Keine manuellen Parameteränderungen!

13
Broker Manuell oder mit EM?
Broker mit EM
• Wizards
• Keine manuelle
Vorarbeit
• Komplexität trotzdem
vorhanden

Broker Ma...
Switchover und Failover

Broker

Manuell

• Eine Zeile
• Schnell in
kritischen
Situationen

• Mehrere Schritte
• Abwechsel...
Failover mit Broker
• Reinstate der „failed Primary“ zur sofortigen
Verwendung als neue Standby möglich
• Setzt Flashback ...
Fast-Start Failover (FSF)
• Unter gewissen Bedingungen:
– Automatischer Failover
– Auto-Reinstate

• Ausschließlich mit Br...
FSF Diskussion
• Zwingend notwendig: Client-Konfiguration
(Connect Time Failover)
• Ausschluss von Transaktionsverlust nur...
Data Guard
Manuell

Broker
Enterprise
Manager

Observer
Fast-Start
Failover
19
Vielen Dank für Ihre
Aufmerksamkeit!
E-Mail dierk.lenz@hl-services.de
Twitter @ora1578
http://blog.hl-services.de

20
Nächste SlideShare
Wird geladen in …5
×

Oracle Data Guard: Mit oder ohne Broker?

582 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

×