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. 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. Inhalt
• Anforderungen
• Hochverfügbarkeit der Infrastruktur
• Hochverfügbarkeit der Datenbank
• Betrieb mit mehreren RZs
3

4. Anforderungen
4

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. 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. 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. 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. Hochverfügbarkeit der Infrastruktur
9

10. Was ist gemeint?
• Verlust von „Kisten“
• Kein Datenverlust
– Annahme: hier greift ein redundantes
Speicherverfahren
10

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. RAC
Vorteile
• Bewährte Oracle-
Technologie
• Bei Standard Edition
kostenlos
Nachteile
• Nicht jede Anwendung
skaliert
• Spezial Know-How
erforderlich
12

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. 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. Hochverfügbarkeit der Datenbank
15

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. 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. 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. 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. Betrieb mit mehreren RZs
20

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. 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. 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
Vielen Dank für Ihre
Aufmerksamkeit!
E-Mail dierk.lenz@hl-services.de
Twitter @ora1578
http://blog.hl-services.de