Überblick Oracle Datenbank Hochverfügbarkeit

<Insert Picture Here>

Überblick Datenbank Hochverfügbarkeit

Ileana Someşan, Systemberaterin ORACLE Deutschland

Agenda

• Nichtverfügbarkeit
• Clustering Lösungen
• Standby Datenbanken
• Andere Technologien für Hochverfügbarkeit
• Komplettsysteme
• Weitere Infos, Q&A

© 2012 Oracle Corporation Ileana.somesan@oracle.com 3

Planung einer Ausfallsicherheitslösung

• Wieviel Ausfallzeit kann man tolerieren?

• Investitionsbereitschaft, internes Knowhow?

• Aktive Nutzung der Ausfallsicherheitslösung?

Ileana.somesan@oracle.com 4

Ausfallzeiten auf DB-Ebene

Systemfehler Server-Ausfall, OS-Crash
Datenbankinstanzfehler..

Ungeplante Datenfehler Storage-Fehler, Datenkorruption
Ausfallzeiten & Desaster Standortausfall (Brand, Stromausfall..)

Nutzerfehler Versehentliches Löschen von
Daten/Datenbankobjekten..

Migration Migration (DB, Plattform..)
Geplante
Ausfallzeiten Patches und Versionsupgrade
Wartung (Hardware, OS, DB)
Schema Anpassungen ..

Tel. +41 56 483 3300

Oracle Lösungen

Systemfehler Real Application Clusters (RAC),
RAC One Node

Ungeplante Datenfehler (Active) Data Guard
Ausfallzeiten & Desaster Recovery Manager (RMAN), ASM

Nutzerfehler Flashback Technologien

Migration GoldenGate
Geplante
Ausfallzeiten RAC, RAC One Node
Wartung Data Guard, GoldeGate
Edition Based Redefinition

Tel. +41 56 483 3300

Agenda

• Komplettsysteme


Problem: DB-Server als Single Point of Failure

Single Instance DB

DB Server

Storage

Ausfall des DB-Servers
Fehler der DB-Instanz  DB Nicht-Verfügbarkeit


Lösung 1: Herkömmliches Clustering
Veritas Cluster, IBM HACMP, MSCS, HP ServiceGuard, …
Cold Failover Cluster

DB Server 1 DB Server 2

Shared Storage

• Aktiv-passiv Cluster: die Oracle DB läuft zu einem Zeitpunkt auf einem Knoten
• Bei Ausfall:
– Ressourcen starten, Verbindungen aufbauen
– Datenbankinstanz nicht „warm“
– Umschaltzeit: 10-30 Minuten
• Probleme:
– lange Umschaltzeiten
– ungenutzte Redundanz beim Schutz einer Datenbank


Besser: Real Application Clusters (RAC)
Hochverfügbarkeit und mehr

Alleinstellungsmerkmal der
RAC Oracle DB

DB Server 1 DB Server 2 DB Server 3

Shared Storage

• Aktiv-aktiv Cluster: die Oracle Datenbank läuft auf 2+ Knoten gleichzeitig
• Bei Ausfall eines Servers:
– Die Datenbank läuft auf den überlebenden Knoten weiter
– Umschaltzeit ~ wenige Sekunden
• Maximale Ressourcenausnutzung + Flexibilität
• Lastverteilung, Skalierung durch Hinzufügen von Servern im laufenden Betrieb


RAC-Infrastuktur (1/2)
Oracle Clusterware

Server 1 Server 2 Server 3 Server 4

SAP Enqueue SAP Replication
Service Service

RAC Instanz RAC Instanz SAP R/3 Instanz SAP R/3 Instanz

Oracle Clusterware
Optional 3rd party Clusterware

• Absicherung für:
• die Oracle Datenbank
• 3rd Party Anwendungen:
– z.B.Vorkonfigurierte Agenten für SAP Ressourcen
(SAP Enqueue Service, SAP Replication Service)
• Kostenlos


RAC-Infrastuktur (2/2)
Cluster File System oder ASM

Server 1 Server 2 Server 3 Server 4

SAP Enqueue SAP Replication
Service Service

RAC Instanz RAC Instanz SAP R/3 Instanz SAP R/3 Instanz

Oracle Clusterware
Optional 3rd party Clusterware

3rd party Oder
Cluster File System Automatic Storage Management (ASM)
ASM Cluster File System (ACFS)


Automatic Storage Management (ASM) und ACFS

• ASM ist der bevorzugte Storage Manager und Dateisystem für Oracle
Datenbankdateien (RAC und Non-RAC)
- Alternative zu konventionellen Dateisystemen, Volume Manager, Raw Devices
- Gleichmäßige Verteilung der Daten über alle Festplatten der Diskgruppe
 I/O Performance vergleichbar mit RAW Devices
- Online Hinzufügen/Entfernen von Platten
- Optionale Spiegelung
 Schutz
- Automatisches Erzeugen/Benennen/Löschen von Datenbankdateien
 vereinfachte Verwaltung
- Kostenlos

• ACFS ist Storage Manager und Allzweck-Cluster File System (z.B. Oracle
Binaries, SAP Binaries)
- Funktionen: Snapshots, Tagging, Replication, Security, Encryption

© 2012 Oracle Corporation Ileana.somesan@oracle.com
1/3
13

RAC One Node
Die Single Instance RAC-Datenbank
A B

• Schutz vor Ausfall des DB Servers
Rechenzentrum A
und/oder der DB-Instanz
Cold Failover Cluster
• Aktiv-passiv Cluster
• eine DB-Instanz pro Oracle DB
• eingebaute Failover-Technologie
• Reduzierung von Ausfallzeiten bei
DB Server 1 DB Server 2 Wartungsarbeiten
• Online Database Relocation
• Andere:
• Server-Konsolidierung
DB-Storage • online Upgrade von RAC One Node zu
RAC


RAC One Node
Online Database Relocation

Client Connections

Server A Server B

• Mehr-Instanzen Betrieb für
max. 12 Stunden
DBa DBb DBb DBc • Verlagerung der User
Sessions auf den neuen Knoten

Shared Storage

Single Cluster

• Verbesserter aktiv-passiv Cluster:
Datenbankschutz + Verringerung Ausfallzeiten bei Wartungsarbeiten
• Online Upgrade von RAC One Node zu RAC


Zusammenfassung Clustering Lösungen




Geplante

Tel. +41 56 483 3300

Problem: Datenfehler und Desaster

Rechenzentrum
DB-Cluster

DB-Server

Shared Storage Storage

• Clustering ≠ Schutz vor Datenfehler ≠ Disaster Recovery
• Clustering ≠ Schutz vor menschlichen (logischen) Fehlern
Ein Ausfallsicherheitskonzept muss mehr berücksichtigen
als nur Server und Instanzfehler!


Agenda

• Komplettsysteme


Standby Datenbank

Failover

Rechenzentrum A Rechenzentrum B

DB-Server 1 DB-Server 2
Standby DB

DB-Storage 1 DB-Storage 2

Kopie der Produktionsdatenbank auf
separater Hardware
(Server/Storage), u.U. in anderen
Gefahrenzone


Storage Replikation
eingeschränkter Schutz, ungenutzte Redundanz

 Keine produktive Nutzung

Rechenzentrum A Rechenzentrum B

DB-Server 1 DB-Server 2
Standby DB

Storage Replikation
DB-Storage 1 Entsprechendes DB-Storage 2

DB-Datei versehentlich gelöscht

Fehler wird propagiert
ORA-01578:
Datenblock beschädigt


Oracle Data Guard

Laufender, automatischer
Abgleich der Standby-DB
mit der Produktions-DB

Produktions- Physikalische Standby
Datenbank Datenbank

• Automatischer Rollentausch (Primary/Standby) im Fehlerfall
– Fast Start Failover
• Robust gegen Netzwerkausfälle (Gap Detection)


Oracle Data Guard: Redo Transport Services
Transaktionen
Primary DB Standby DB

LGWR
SYNC
LNS  Maximum RFS
Production Protection Standby
Database Redo
Logs
Online ASYNC
Redo LNS RFS
Logs Maximum
Performance

ARCH
Automatic Gap Resolution
ARCH bei Netzunterbrechungen RFS

Archived Archived
Redo Logs Redo
Logs


Oracle Data Guard: Apply Services

Standby DB

Standby Redo Apply  Physical Standby DB
Redo Logs
Redo Data
von RFS
Apply
Produktion

SQL Apply  Logical Standby DB
ARCH

Archived
Redo
Logs


Anwendungsfälle von Data Guard
mehr als nur Disaster Recovery

• Backup von der Standby Datenbank anstelle der Produktions-DB
Standby Datenbank: identische Kopie der Produktionsdatenbank
Vorteil: Backups erzeugen keine Last auf dem Produktionssystem

• Standby Datenbank als Testsystem nutzen (11g)
• Temporäre Snapshot Standby Datenbank erzeugen
• Testen (Lesend/Schreibend): Transport der Transaktionslogs läuft im
Hintergrund weiter
• Auf Knopfdruck zurückstellen: die aufgelaufenen Logdateien werden
nachgefahren, Synchronbetrieb
Vorteil: Testen mit echten Produktionsdaten
 Vorteil: weiterhin Schutz vor Datenverlust


Active Data Guard (seit 11g)

Physical Standby DB Backup von Standby-DB

Physical Standby DB
Testsystem
(Snapshot Standby)

Oracle Data
Guard Query Offloading,
Produktion-DB Echtzeit-Reporting

Fast incremental Backup
Active Data Guard
bis zu 20x schneller

Automatische Korrektur
beschädigter
Datenblöcke


Zusammenfassung Standby Lösungen




Geplante

Tel. +41 56 483 3300

Agenda

• Komplettsysteme


Menschliches Versagen




Geplante

Tel. +41 56 483 3300

Flashback Technologien
Die Zeitmaschine in der Datenbank

• Flashback Query
• Flashback Versions Query
• Flashback Transaction Query
• Flashback Table
• Flashback Transaction – neu 11g
• Flashback Drop
• Flashback Database

Funktionalität der Oracle DB Enterprise Edition, um den Zustand
eines Datensatzes, einer Tabelle oder der gesamten sehr schnell
Datenbank wiederherzustellen.


Oracle GoldenGate
Oracles strategische Replikationslösung

Oracle
Oracle
DB2
Beliebige DB2
MS SQL Server
Entfernung MS SQL Server
Sybase ASE
Sybase ASE
Teradata,
LAN/WAN Teradata,
MySQL
u.a. Ziel MySQL
u.a.
GoldenGate

• Minimierung von geplanten Ausfallzeiten
– Datenbank-Upgrade 8i/9i/10g auf 11g
– Plattformwechsel, Migration auf die Oracle DB
– Fallback verringert das Risiko
• Bidirektionale/Multi-Master Replikation
– Synchronisation zwischen Standorten in Echtzeit
• Heterogene Umgebungen


Upgrade/Migration fast ohne Downtime

OLTP Nutzer

Oracle 10g Oracle 11g

Aufsetzen des neuen Systems (hier 11g), ggf. Konfiguration neuer
Datenabankfeatures


Upgrade/Migration fast ohne Downtim

OLTP Nutzer

Initiale Instantiierung

Starte GoldenGate auf dem Quellsystem. GoldenGate protokolliert alle
nachträglichen Änderungen.
Initiales Laden der Daten in die neue Datenbank ohne Unterbrechung des
Geschäftsbetriebs (Nutzer arbeiten weiter mit dem bestehenden System)

Initialer Abgleich der 2 Datenbanken mit GoldenGate
Synchronbetrieb zwichen Alt- und Neusystem.



OLTP Nutzer Tester


Synchronbetrieb für die Dauer der Tests



OLTP Nutzer


Umschaltung der Nutzer auf das neue System
Rückfall auf das alte System, wenn nötig


Zusammenspiel der HA-Lösungen
Schutz, Integration, Verwendung der Kapazität

Rechenzentrum A Rechenzentrum B Operatives
Produktionsdatenbank Aktive Standby Datenbank Reporting
Flashback
RAC RAC
Active Data Guard
GoldenGate

DB Server 1 DB Server 2 DB Server 1 DB Server 2
Automatic Storage Management (ASM) Automatic Storage Management (ASM)

DB-Storage DB-Storage

Recovery Manager (RMAN)
Secure Backup


Agenda

• Komplettsysteme


Komplettsysteme für die Oracle DB 11g
Ein Paradigmenwechsel

Oracle Database
Appliance Full Rack

Half Rack

Quarter Rack Oracle Exadata
Database Machine


Oracle Database Appliance
Der Einstieg in die Familie von Komplettsystemens

• Einfach
• schnelle Installation, einfache Verwaltung und Support

verfügbar seit
September 2011

• Komplettsystem
• Hard + Software voll integriert, aufeinander optimiert
• Hochverfügbare Datenbanklösung
• für selbstentwickelte und Standard OLTP- und DW-Anwendungen


Standardkomponenten

NEU: Integriert, Optimiert,
Intel Prozessoren Getestet, Automatisiert
+
SAS/SATA HDD
SAS SSD Storage
+
Standard Schnittstellen
= Oracle DB
USB 2.0, 1 GbE, 10 GbE
+ Appliance
Linux x86_64
+
Oracle Database 11g
+
Oracle RAC


Komplett redundante Hardware

Sicht von vorne Sicht von hinten

2 x Serverknoten 24 Prozessorkerne aktiviert bei Bedarf
Pro Server: 192 GB Hauptspeicher
• 2 x CPU 6-Core Intel Xeon X5675 4 TB Shared Storage
• 96 GB Hauptspeicher
Netzwerk/Schnittstellen
Storage
GbE Interconnect für Clusterkommunikation
SAS HDD:
GbE ,10 GbE für externe Kommunikation
• Insgesamt 12 TB dreifach gespiegelt
• Nutzbar 4 TB für die DB Redundante Komponenten
SAS SSD: 292 GB für Redo Logs Storage, Netzwerk, Netzteile und Lüfter
dreifach gespiegelt


Ausfallsicherer Software-Stack

Oracle Enterprise Manager Database Control
Oracle Database EE Options & Management Packs
Single Instance RAC One Node Real Application
Clusters (RAC) separat
Oracle Database 11.2.0.2 Enterprise Edition
Oracle Grid Infrastructure 11.2.0.2
• Automatic Storage Management (ASM)
• Oracle Clusterware

Oracle Appliance Manager
vorinstalliert
Oracle Linux 5.5

Wahl zwischen Single Instance DB ODER RAC One Node ODER RAC


Schnelle Installation

• Auspacken

• Stromkabel anschließen

• Netzwerkkabel anschließen

• End-User Packages herunterladen/kopieren

• Wizard-geführte Installation und Konfiguration: Dauer ~ 2 Stunden


Einfache Administration
Oracle Appliance Manager

• Patchen des gesamten Systems mit einem Befehl
• Firmware, Betriebssystem, Clusterware, Datenbanksystem

• Storage-Selbstverwaltung
• Automatic Storage Management (ASM)
• Automatische Identifikation und Korrektur von Plattenfehlern

• Schnelle Diagnose
• Automatic Service Request (Phone Home)
• Log-Sammlung und -Bündelung für Oracle Support

• Ein Ansprechpartner für alle Support Angelegenheiten


Pay-as-you-Grow Lizenzmodell
Erschwingliche Hochverfügbarkeit

• Eine einzige Hardware-Konfiguration beschaffen
• Anzahl der benötigten (aktiven) Prozessorkerne und der
Datenbank-Lizenzen bestimmen

• Bei steigender Rechenkapazität keine Hardwareänderung
erforderlich
• zusätzliche Prozessorkerne werden aktiviert und lizenziert
• 4 bis 24 Prozessorkerne aktivieren
• 2 bis 24 Prozessorkerne lizenzieren


Zu beachten

• HW: nicht erweiterbar, nicht änderbar
• Reine DB-Maschine
• Datenmenge auf 4 TB begrenzt
 Oracle Advanced Compression zwecks Plattenplatzeinsparung
• DB Version 11.2.0.2, Linux


Vorteile für Abteilungen,
kleine und mittelständische Unternehmen

• Schnelle, einfache Inbetriebnahme

• Skalierbares Lizenzmodell

• Performance-Steigerung ohne Hardware-Austausch

• Erweiterte Wartbarkeit

• Höchste Verfügbarkeit für diese Konfiguration

• Validierte (nicht einmalige) Konfiguration


Ausblick Zusammenspiel der HA-Lösungen
Oracle Database Appliance

Rechenzentrum A Rechenzentrum B Operatives
Produktionsdatenbank Aktive Standby Datenbank Reporting

Flashback Active Data Guard GoldenGate

RAC RAC

ASM ASM

DB-Storage

Recovery Manager (RMAN)
Secure Backup


Links und Kontaktdaten

• Weitere Informationen DB High Availability
http://www.oracle.com/technetwork/database/features/availability

• Oracle RAC Home
http://www.oracle.com/goto/rac

• Oracle Data Guard
http://www.oracle.com/goto/dataguard

• Oracle Database Appliance
http://oracle.com/goto/databaseappliance
http://bit.ly/oracle-db-appliance
Deutsches FAQ zur Oracle DB Appliance

• Ansprechpartner
– Ihr Oracle Vertriebsbeauftragter
– Ihr Oracle Systemberater


Überblick Oracle Datenbank Hochverfügbarkeit

Weitere ähnliche Inhalte

Was ist angesagt?

Andere mochten auch

Ähnlich wie Überblick Oracle Datenbank Hochverfügbarkeit

Überblick Oracle Datenbank Hochverfügbarkeit