Your SlideShare is downloading. ×
Oracle Data Guard: Mit oder ohne Broker?
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Oracle Data Guard: Mit oder ohne Broker?

163

Published on

Mein Vortrag zur DOAG 2013 Konferenz

Mein Vortrag zur DOAG 2013 Konferenz

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
163
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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
  • 19. Data Guard Manuell Broker Enterprise Manager Observer Fast-Start Failover 19
  • 20. Vielen Dank für Ihre Aufmerksamkeit! E-Mail dierk.lenz@hl-services.de Twitter @ora1578 http://blog.hl-services.de 20

×