Oracle und Hochverfügbarkeit –
Verschiedene Ansätze im Vergleich
Dierk Lenz
Herrmann & Lenz Services GmbH
DOAG Regio Münch...
Herrmann & Lenz Services GmbH
Herrmann & Lenz Solutions GmbH
• Erfolgreich seit 1996 am Markt
• Firmensitz: Burscheid (bei...
Inhalt
• Anforderungen
• Hochverfügbarkeit der Infrastruktur
• Hochverfügbarkeit der Datenbank
• Betrieb mit mehreren RZs
3
Anforderungen
4
Je höher die Management-Ebene…
• Es darf nichts ausfallen!
• Fehler dürfen nicht beim Anwender bemerkt
werden!
• Ohne Admi...
Realistisch…
• Durch Compliance-Anforderungen u.ä.
bekommt das Thema Hochverfügbarkeit mehr
Aufmerksamkeit
• Begriffe und ...
Aspekte
• Hochverfügbarkeit auf einer Ebene nützt gar
nichts…
– „RAC-in-a-Box“
– DB hochverfügbar; aber Zugriff über einen...
Wichtige Zutaten
• Anforderungsanalyse
• Konzept zur Hochverfügbarkeit auf allen
Infrastrukturebenen
• Checklisten für den...
Hochverfügbarkeit der Infrastruktur
9
Was ist gemeint?
• Verlust von „Kisten“
• Kein Datenverlust
– Annahme: hier greift ein redundantes
Speicherverfahren
10
Zwei Standards im Markt
RAC
• Oracle-Architektur
• Aktiv/Aktiv-Technologie
• Skalierbarkeit UND
• Hochverfügbarkeit
Virtua...
RAC
Vorteile
• Bewährte Oracle-
Technologie
• Bei Standard Edition
kostenlos
Nachteile
• Nicht jede Anwendung
skaliert
• S...
VMWare
Vorteile
• In vielen Unternehmen
vorhanden
• Bewährte Technologie
Nachteile
• Komplett „extern“: Oracle
hat keine K...
Weitere Alternativen
• Oracle VM
– Nicht oft eingesetzt
– Hardware Partitioning möglich: „Teile“ der
Maschine lizenzierbar...
Hochverfügbarkeit der Datenbank
15
Was fehlt denn noch?
• Annahme aller besprochenen Konzepte
Die Datenbank ist und bleibt unbeschädigt!
• Wenn dieser Fall d...
Konzept: Physische Standby-
Datenbank
• Physische Kopie der primären Datenbank
• Versorgung mit Redolog-Strom der primären...
Und die Logische Standby-Datenbank?
• Unterschied zur physischen Standby-DB:
– Generierung von SQL aus dem Redolog-Strom
–...
Einsatz von Standby-Datenbanken
• Erforderlich, wenn Rücksicherung zu lange
dauert (meist ab ca. TB-Größe)
• Diverse Produ...
Betrieb mit mehreren RZs
20
Absicherung von „Komplettes RZ fällt
aus“
• Generell extrem komplex, z.B. aufgrund von
Netzwerkproblematiken
• Anforderung...
Eigentlich kein Problem, aber…
• Geteiltes RAC („Stretched Cluster“) ggfs.
problematisch aufgrund der
Netzwerkanbindung
– ...
Hier insbesondere
• Anforderungen genau klären
• Mechanismen so gut es geht testen
• Ggfs. weitere Komponenten in Erwägung...
24
Vielen Dank für Ihre
Aufmerksamkeit!
E-Mail dierk.lenz@hl-services.de
Twitter @ora1578
http://blog.hl-services.de
Nächste SlideShare
Wird geladen in …5
×

Oracle und Hochverfügbarkeit – Verschiedene Ansätze im Vergleich

387 Aufrufe

Veröffentlicht am

Veröffentlicht in: Software
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
387
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
7
Aktionen
Geteilt
0
Downloads
2
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Oracle und Hochverfügbarkeit – Verschiedene Ansätze im Vergleich

  1. 1. Oracle und Hochverfügbarkeit – Verschiedene Ansätze im Vergleich Dierk Lenz Herrmann & Lenz Services GmbH DOAG Regio München/Südbayern 14. April 2014
  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 22
  3. 3. Inhalt • Anforderungen • Hochverfügbarkeit der Infrastruktur • Hochverfügbarkeit der Datenbank • Betrieb mit mehreren RZs 3
  4. 4. Anforderungen 4
  5. 5. Je höher die Management-Ebene… • Es darf nichts ausfallen! • Fehler dürfen nicht beim Anwender bemerkt werden! • Ohne Administrationsaufwand! • Keine Zusatzkosten! 5
  6. 6. Realistisch… • Durch Compliance-Anforderungen u.ä. bekommt das Thema Hochverfügbarkeit mehr Aufmerksamkeit • Begriffe und Bedeutung nach wie vor oft unklar – „Bei Oracle ist RAC doch Hochverfügbarkeit!“ 6
  7. 7. Aspekte • Hochverfügbarkeit auf einer Ebene nützt gar nichts… – „RAC-in-a-Box“ – DB hochverfügbar; aber Zugriff über einen zentralen Switch – Standby DB; aber Clients ohne TNS-Informationen hierzu 7
  8. 8. Wichtige Zutaten • Anforderungsanalyse • Konzept zur Hochverfügbarkeit auf allen Infrastrukturebenen • Checklisten für den Notfall („Betriebshandbuch“) • Regelmäßige Übungen • Hochverfügbarkeit kostet Geld! – Hardware – Software – Know How (!!!) 8
  9. 9. Hochverfügbarkeit der Infrastruktur 9
  10. 10. Was ist gemeint? • Verlust von „Kisten“ • Kein Datenverlust – Annahme: hier greift ein redundantes Speicherverfahren 10
  11. 11. Zwei Standards im Markt RAC • Oracle-Architektur • Aktiv/Aktiv-Technologie • Skalierbarkeit UND • Hochverfügbarkeit Virtualisierung (VMWare) • Virtualisierungs-Cluster • Storage für virtuelle Maschinen nicht lokal • Virtuelle Maschinen können „geschwenkt“ werden 11
  12. 12. RAC Vorteile • Bewährte Oracle- Technologie • Bei Standard Edition kostenlos Nachteile • Nicht jede Anwendung skaliert • Spezial Know-How erforderlich 12
  13. 13. VMWare Vorteile • In vielen Unternehmen vorhanden • Bewährte Technologie Nachteile • Komplett „extern“: Oracle hat keine Kenntnis von VMWare • Lizenzierung: Oracle „sieht“ VMWare nicht • Support: keine direkte Unterstützung von Oracle • Performance-Einfluss 13
  14. 14. Weitere Alternativen • Oracle VM – Nicht oft eingesetzt – Hardware Partitioning möglich: „Teile“ der Maschine lizenzierbar • Kombinationen – RAC mit Virtualisierung – Sehr komplex, insbesondere in der Betrachtung möglicher Störungen 14
  15. 15. Hochverfügbarkeit der Datenbank 15
  16. 16. Was fehlt denn noch? • Annahme aller besprochenen Konzepte Die Datenbank ist und bleibt unbeschädigt! • Wenn dieser Fall doch eintritt: – Rücksicherung/Wiederherstellung notwendig – Je nach Infrastruktur, DB Größe, Wiederherstellungsaufwand: Zeitaufwändig! 16
  17. 17. Konzept: Physische Standby- Datenbank • Physische Kopie der primären Datenbank • Versorgung mit Redolog-Strom der primären Datenbank • Durch permanente Widerherstellung „auf dem aktuellen Stand“ 17
  18. 18. Und die Logische Standby-Datenbank? • Unterschied zur physischen Standby-DB: – Generierung von SQL aus dem Redolog-Strom – Anwendung des SQL stat Wiederherstellung • Erfahrung: Kann bzgl. Robustheit und Vollständigkeit nicht mit physischer Standby- DB mithalten • Besser geeignet für Migrationen oder Spezialaufgaben (Warehouse-Versorgung usw.) 18
  19. 19. Einsatz von Standby-Datenbanken • Erforderlich, wenn Rücksicherung zu lange dauert (meist ab ca. TB-Größe) • Diverse Produkte – Oracle Data Guard (Enterprise Edition) – Dbvisit Standby – … • Spezial Know-How erforderlich 19
  20. 20. Betrieb mit mehreren RZs 20
  21. 21. Absicherung von „Komplettes RZ fällt aus“ • Generell extrem komplex, z.B. aufgrund von Netzwerkproblematiken • Anforderungen von „Vorhandene Sicherung im zweiten RZ reicht“… • bis „Automatische Übernahme aller Funktionen“ 21
  22. 22. Eigentlich kein Problem, aber… • Geteiltes RAC („Stretched Cluster“) ggfs. problematisch aufgrund der Netzwerkanbindung – Latenz problematisch für Interconnect • Standby-DB möglich, aber Eingriff für Failover notwendig – Auch Fast-Start Failover bei Data Guard… 22
  23. 23. Hier insbesondere • Anforderungen genau klären • Mechanismen so gut es geht testen • Ggfs. weitere Komponenten in Erwägung ziehen, Z.B. RAC One Node 23
  24. 24. 24 Vielen Dank für Ihre Aufmerksamkeit! E-Mail dierk.lenz@hl-services.de Twitter @ora1578 http://blog.hl-services.de

×