Lenz_Oracle_Hochverfügbarkeit

Überblick über Oracle Technologie
im Bereich Hochverfügbarkeit
Tage der Datenbanken
FH Köln – Campus Gummersbach
20. Juni 2013
Dierk Lenz
Herrmann & Lenz Services 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
2
Inhalt
•
•
•
•
Wozu Hochverfügbarkeit?
Konfiguration eines Oracle Servers
Real Application Clusters
Data Guard
3
Wozu Hochverfügbarkeit?
4
Einsatz von Datenbanken (u.a. Oracle)
für…
• Geschäftskritische Anwendungen in allen
Unternehmensgrößen
• Abrechnungssysteme, z.B. im Mobilfunk
• Internetplattformen (Auskunftssysteme,
Online Shopping, …)
5
Warum eigentlich Oracle?
• Sprachen, APIs, Schnittstellen in großer Zahl
bekannt, well known, verfügbar
• Kombination aus diversen Eigenschaften
– Flexibilität
– Plattformunabhängigkeit
– Performance
– Hochverfügbarkeit
• Nah an der „Eierlegenden Wollmilchsau“
6
Eigenschaften vieler Systeme
• Auszeiten sind „teuer“ – egal wann!
• „System steht nicht zur Verfügung“ 
Unzufriedenheit der Kunden
• Wartungsfenster nur schwer zu finden
7
Hochverfügbarkeit
• Zentrale Forderung für viele neue Systeme
• Vielfältige Möglichkeiten
• Welche ist die richtige?
8
Konfiguration eines Oracle Servers
9
Redundanz zur Steigerung der
Verfügbarkeit
• Netzwerkschnittstellen (Bonding, Teaming, …)
• Redundante Stromversorgung
• Viele Möglichkeiten für das IO-Subsystem
– RAID-Verfahren
– Spiegelung zwischen Storage-Einheiten
– Software-Spiegelung (LVMs, Oracle ASM, …)
– Storage-Virtualisierung
10
Abstimmung verschiedener Ziele
• Beispiel Disk-Redundanz
– Hohe Verfügbarkeit  Einsatz von RAIDTechnologie
– Günstiger Preis  RAID-5
– Gute Performance  OK – doch kein RAID-5…
http://www.baarf.com
11
Sicherung von Datenbanken
• Offline-Sicherung nicht mehr möglich  s.o.
• Online-Sicherung kein Problem bei Oracle DBs
– Archivelog-Modus notwendig (lückenlose Kette von
Transaktions-Logs bzw. Redologs)
– Mitgeliefertes Werkzeug: Recovery Manager (RMAN)
– Parallelvortrag
• Wichtig für später:
– RMAN-Sicherung heißt: Physische Kopie (kein Export)
– Wiederherstellung eines beliebigen Zeitpunkts mit
Hilfe der Archivelogs/Redologs
12
Real Application Clusters
13
Standard-Konfiguration Oracle
SGA
DB
14
Real Application Clusters
SGA
SGA
SGA
DB
15
Real Application Clusters
• Betrieb einer Datenbank mit einem Cluster von
Rechnern
• Aktiv/Aktiv-Cluster (im Gegensatz zu Aktiv/Passiv
bei vielen bekannten Systemen)
• Beliebige Zahl von Rechnern
(OK, heute keine Diskussion der Lizenzkosten!)
• Basiert auf Clusterware und Grid Infrastructure
• „Privates“ Netzwerk für Heartbeat, Blocktransfer,
…
16
Vorteile von RAC
• Skalierbarkeit
– Steigerung der Leistung durch Hinzufügen von
Knoten
– In viele andere Oracle Technologien integriert
• Z.B. parallele Ausführung von Abfragen im Cluster
• Und Hochverfügbarkeit
– Ausfall eines Knotens führt nicht zum Ausfall des
DB-Service
17
Data Guard
18
Was fehlt noch?
• RAC liefert Hochverfügbarkeit in Bezug auf
Hardware-Probleme
– CPU, Memory Board, … defekt
• Was ist mit der Datenbank selbst?
– Storage ist redundant!
– Aber: Korruptionen oder logische Fehler werden
ebenfalls redundant gespeichert!
– Sicherung zurückspielen!
• Dauert zu lange bei wichtigen Systemen
19
Data Guard
SGA
DB
SGA
Kopie der Redologs
DB
20
Data Guard-Technik ist StandardWiederherstellungstechnik
• Erzeugen der Standby-Datenbank aus
Primärdatenbank durch physische Kopie
(RMAN!)
• Transfer der Redologs vom Primär- zum
Standby-Server
• Synchronisation durch permanente
Wiederherstellung (Managed Recovery)
• Primär- und Standby-DBs können RACs sein!
21
Umschalten
• Switchover: kontrollierter Rollenwechsel
(Primär-DB  Standby-DB)
• Failover: In Fehlersituation „hartes“ Aktivieren
der Standby-DB als Primär-DB
– Ggfs. Verlust von Transaktionen
22
Möglichkeiten
• Bis zu 30 Standby-Datenbanken
• Direktes Apply der Redologs oder Delay (in
Minuten)
– Für logische Fehler (DROP TABLE…)
23
Protection Modes
• Maximum Performance
– Asynchrone Übertragung des Redolog-Stroms so schnell
wie möglich
– Geringe Auswirkungen auf Primär-DB
• Maximum Protection
– Synchronre Übertragung des Redolog-Stroms inkl.
Bestätigung des Remote Writes vor lokalem Write
– Bei Störung der Standby-DB: keine lokalen Transaktionen!
• Maximum Availability
– Wie Maximum Protection
– Fallback auf Maximum Performance
24
Zusammenfassung
25
Zusammenfassung
• Hochverfügbarkeit kein „An-/Aus-Schalter“
• Wichtige Oracle-Bausteine
– RAC
– Data Guard
• To be continued…
– Infrastruktur (Netzwerk usw.)
– Connectivity der Anwendungen
26
Vielen Dank für Ihre Aufmerksamkeit!
27
Kontaktinfo
• E-Mail: [email protected]
• Web: http://www.hl-services.de
• OraInfo: http://www.orainfo.de
28