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 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

486 Aufrufe

Veröffentlicht am

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

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

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

×