Oracle Dataguard

<Insert Picture Here>
Oracle Dataguard
Harald Wolf, Sales Consulting, Nürnberg
Architektur der Exadata Database Machine
Ein komplettes System: rechnen, speichern, vernetzen
• Datenbank Server (Grid/RAC)
– Datenbank Server mit Intel-Techn.
– Oracle Linux
– Oracle Datenbank 11g und 12c
– 10 Gb Ethernet (zum RZ)
• Exadata Storage Server (Grid)
– Platten Server mit Intel-Techn.
– bis zu 1344 TB Plattenkapazität
(brutto)
– bis zu 89,6 TB High Speed Flash
– Exadata Storage Server Software
• InfiniBand Netzwerk
– internes aktiv-aktiv Netz (2x40 Gb/s)
2
Agenda
Oracle DataGuard Kurzüberblick
Snapshot Standby
Standby aufbauen mit RMAN
Active Dataguard
Rolling Upgrades mit Transient Logical Standby
Vermischtes
Oracle Database 11g Data Guard
• “Active Data Guard” Fundamentally
changes the value of redundant infrastructure
• Can now use “Physical Standby” for:
Off-Site
DR-RO
Queries
Sync or Async
Redo Shipping
• Reporting
Production
Database
• Read only Physical Standby
• Online Upgrades
Production
• Transient Logical Standby
• Testing
• Snapshot Standby
• Backups
• Fast incremental backups (Change Tracking)
Network
• Major performance enhancements too
Physical Standby
Database
Backup
Redo Apply
DIGITAL DAT A S TORAGE
DIGIT AL DAT A ST ORAGE
Broker
Additional
Reporting
Logical Standby Indexes &
Materialized Views
Database
Transform
Redo to SQL
Open for
Reports
SQL
Apply
QA - Test
Transform
Redo to SQL
Physical/ Snapshot Standby
Database
Open for
Testing
SQL
Apply
Changes
queued
Vorteile von Data Guard
• Physikalische “Langstrecken”-Redundanz der Datenbank
• Trennung (“Optokoppler”) von Primary und Standby
• Korrupte DB-Blöcke werden auf der Standby DB (STBY) sofort
entdeckt.
• Es wird permanent der RESTORE der DB getestet (implizit die
Komplettheit des Backups).
• Die Standby DB ist im laufenden Betrieb (online) aufsetzbar.
• Keinerlei Rückwirkungen auf die Primary DB (PRIM) bei Max
Performance Mode (ASYNC NOAFFIRM)
• Trotzdem nur minimaler Datenverlust (1 Tx) bei Verwendung
von Standby Redolog-Files (SRL) und Realtime Apply
Vorteile von Data Guard (Forts.)
•
•
•
•
•
•
•
24x365 Betrieb – Nahezu Unterbrechungsfrei
Sicherung auf Standby-System – Entlastung des Primary
Einfacher Betrieb
Einfaches Monitoring (1 View: V$_DATAGUARD_STATS)
Automatic Block Repair (ADG)
Patch Standby First: PSU zuerst auf STBY Test
Z.Zt. Einzige HA-Lösung für Exadata
• Aus geg. Anlaß: Gleiche oder unterschiedlich SIDs möglich
Data Guard Enhancements in 11g
• Bessere Ressourcen Ausnutzung auf der
Standby-Seite Reporting / Incr. Backup
• Erhöhte High Availability (HA) /
Disaster Recovery (DR) Funktionalität
• Administrierbarkeit verbessert
Data Guard wird ein integraler Bestandteil im High End
Oracle RZ
• 50 DG Inst. in den letzten 2 Jahren (meine Kd.)
• Data Guard vs. HA auf SAN-Ebene (Disk-Mirr.)
DG macht Sinn, wenn reiner Oracle DB-Server
Oracle Data Guard
Zero Data Loss über lange Distanzen
• Die verwendete Netzwerkbandbreite von Data Guard Redo
Transport ist viel geringer, als bei System auf Basis reiner
Plattenspiegelung
Data Guard: Synchrones Redo Shipping
Data Guard DR
Sweet Spot
Synchrone
Plattenspiegelung
150 km
300 km
450+ km
• Weit genug weg für Regionales Desaster
• Nah genug für Zero Data Loss
Oracle DataGuard - Redo Transport
Transactions
Standby
Production
LGWR
LNS
LGWR SYNC
RFS
Production
Database
Standby
Redo
Logs!!!
Online
Redo
Logs
LNS
LGWR ASYNC
RFS
ARCH
Gap Resolution
ARCH
Archived
Redo Logs
RFS
Archived
Redo Logs
Oracle DataGuard - Apply Services
Standby
Redo
Data
From
Site A
Standby
Redo Logs
Physical
(Redo Apply)
RFS
Apply
Logical
(SQL Apply)
ARCH
Archived
Redo Logs
Standby
Database
Oracle DataGuard Überblick
• 3 Möglichkeiten zur Administration
• Pures SQL (SQL*Plus, o.a.)
• DataGuard Broker und DGMGRL (spfile erforderlich)
• DataGuard Broker und EM GridControl/Cloud Control
Oracle DataGuard Überblick
• Dokumentation
Agenda
Oracle DataGuard Kurzüberblick
Snapshot Standby
Standby aufbauen mit RMAN
Active Dataguard
Rolling Upgrades mit Transient Logical Standby
Vermischtes
Snapshot Standby
• Was sagt die Dokumentation?
Snapshot Standby Database
A snapshot standby database is a fully updatable
standby database that is created by converting a
physical standby database into a snapshot standby
database. Like a physical or logical standby database, a
snapshot standby database receives and archives redo
data from a primary database. Unlike a physical or logical
standby database, a snapshot standby database does
not apply the redo data that it receives.
Snapshot Standby
• Physical Standby Read/Write öffnen, Testen, Daten ändern
- und danach einfach auf Knopfdruck wieder zurückstellen
und synchronisieren
• Einsatz: Testdatenbank, Entwicklungssystem, P
Updates
Primary
Database
Queries
Updates
Physical Standby
Snapshot
Database
Database
Snapshot Standby
• Physical Standby als Snapshot Standby öffnen:
• SQL> ALTER DATABASE
CONVERT TO SNAPSHOT STANDBY;
• Redo-Transport läuft weiter
• Alternativ im DGMGRL:
DGMGRL> CONVERT DATABASE stby TO SNAPSHOT STANDBY;
• Wichtige Anmerkung: Man muss mit User/Pw@connect auf der Primary-DB eingeloggt sein
• Wieder zurück:
SQL> ALTER DATABASE
CONVERT TO PHYSICAL STANDBY;
• Alternativ im DGMGRL:
DGMGRL> CONVERT DATABASE stby TO PHYSICAL STANDBY;
Snapshot Standby
• Anmerkungen:
• Wesentlich weniger Schritte notwendig, als in 10gR2
• Der Redo-Transport läuft im Hintergrund weiter
• Zero Data Loss möglich!!!
• Nach dem Rückkonvertieren in eine Physical Standby werden
die aufgelaufenen Logdateien nachgefahren
• Im Standby-RAC darf nur eine Apply-Instanz gestartet sein
• Funktioniert nicht, wenn:
• Max-Protection-Mode eingestellt wurde und nur eine
Standby vorhanden ist
• Wenn die Standby das Ziel bei Fast-Start-Failover ist
Agenda
Oracle DataGuard Kurzüberblick
Snapshot Standby
Standby aufbauen mit RMAN
Active Dataguard
Rolling Upgrades mit Transient Logical Standby
Vermischtes
Standby aufbauen mit RMAN
•
Wer
hat
Angst
vorm R
•
MAN??
"Duplicate Standby" nun auch über das Netzwerk und
ohne vorheriges Backup möglich
•
•
•
RMAN-Klausel: ... FROM ACTIVE DATABASE
SQL*Net muss vorab konfiguriert und getestet !!! werden
SPFILE kann „on-the-fly“ angepasst werden
Standby aufbauen mit RMAN
•
Ohne Backup eine Standby aufbauen (RMAN Duplicate)
Vorgehen:
1. PRIM-Datenbank im Archivelogmode?
2. Standby-Redologs anlegen (auf der Primary)
3. Force Logging einschalten
4. Optional Flashback Logging einschalten (für Reinstantiate)
5. Listener/TNS-Konfiguration vornehmen
• Listener sollte Kenntnis von der zu erzeugenden
Zieldatenbank haben (statischer Eintrag)
6. Password-File mit orapwd anlegen (auf Standby)
7. Zieldatenbank (-Instanz) in den NOMOUNT-Status fahren
• Beim Ziel eine Mini init.ora für den rman clone
Standby aufbauen mit RMAN
•
Ohne Backup eine Standby aufbauen
7. RMAN-Skript ablaufen lassen:
$ rman target / auxiliary sys/oracle@stby
run {
DUPLICATE TARGET DATABASE
FOR STANDBY
FROM ACTIVE DATABASE
DORECOVER
SPFILE PARAMETER_VALUE_CONVERT '+DATA_EXA1','+DATA_EXA2'
SET DB_UNIQUE_NAME='STBY'
SET SGA_TARGET=100G
SET LOG_FILE_NAME_CONVERT='+DATA_EXA1','+DATA_EXA2'
SET DB_FILE_NAME_CONVERT='+DATA_EXA1','+DATA_EXA2'
NOFILENAMECHECK;
}
Standby aufbauen mit RMAN
•
Ohne Backup eine Standby aufbauen
8. Dataguard konfigurieren
• Entweder manuell eintragen (init.ora):
•
•
•
•
FAL_SERVER, FAL_CLIENT, DG_CONFIG
LOG_ARCHIVE_DEST_n
STANDBY_FILE_MANAGEMENT
Oder besser:
Mit DGMGRL konfigurieren lassen
• SPFILE ist Vorraussetzung
• DG_BROKER_START=TRUE ins SPFILE
übernehmen:
alter system set DG_BROKER_START=TRUE....
Standby aufbauen mit RMAN
• DGMGRL - Konfiguration
a.
CREATE CONFIGURATION DG_ENV
AS PRIMARY DATABASE IS orcl
CONNECT IDENTIFIER IS orcl;
b.
ADD DATABASE stby AS CONNECT IDENTIFIER IS stby;
c.
EDIT DATABASE stby SET PROPERTY
'StandbyArchiveLocation'='/archfs/arch/';
EDIT DATABASE stby SET PROPERTY
'StandbyFileManagement'='AUTO';
d.
ENABLE CONFIGURATION;
e. Bei Problemen:
SHOW DATABASE stby InconsistentProperties;
Standby aufbauen mit RMAN
• Fazit:
• Eine Standby ohne vorheriges Backup direkt
aufbauen zu lassen, ist sehr effizient
• Deutliche Verfahrensvereinfachung, falls kein Grid
Control (OEM) im Einsatz ist
Agenda
Oracle DataGuard Kurzüberblick
Snapshot Standby
Standby aufbauen mit RMAN
Active Dataguard
Rolling Upgrades mit Transient Logical Standby
Vermischtes
Active Dataguard
• Vor 11g:
• Physical Standby Read-Only öffnen und Abfragen ausführen
• Währenddessen werden Redologs zwar transportiert, aber
nicht angewendet (applied)
• Daraus resultieren beim Failover/Switchover längere
Umschaltzeiten + Standby gibt "veraltete" Daten zurück
Read-Only
Redo Shipping
PROD
aber: kein Apply
Physical STBY
Active Dataguard (Option)
• Ab11g:
• Physical Standby Read-Only öffnen und Abfragen ausführen
• Währenddessen werden Redologs transportiert und sofort
angewendet (Real-Time-Apply)
• Alle Datentypen werden unterstützt
• Konsistente Leseergebnisse
Read-Only
Redo Shipping
PROD
und Redo Apply
Physical STBY
Active Dataguard
•
•
Vorgehensweise:
1.
ALTER DATABASE
RECOVER MANAGED STANDBY DATABASE CANCEL;
3.
ALTER DATABASE OPEN;
4.
ALTER DATABASE
RECOVER MANAGED STANDBY DATABASE
USING CURRENT LOGFILE DISCONNECT;
Wieder zurück:
1.
2.
ALTER DATABASE CLOSE;
(oder Restart)
ALTER DATABASE
RECOVER MANAGED STANDBY DATABASE
USING CURRENT LOGFILE DISCONNECT;
Lese-Farmen mit Active Dataguard
• Praktisches Anwendungsszenario: Auktionsplattform
Open
Read-Only
Lese-DBs
Updates
Redo Shipping
PrimärDatenbank
Standby Datenbank:
Lese-DB und Fast-Start
Failover Target
Mount-Status
Agenda
Oracle DataGuard Kurzüberblick
Snapshot Standby
Standby aufbauen mit RMAN
Active Dataguard
Rolling Upgrades mit Transient Logical Standby
Vermischtes
Rolling Upgrades (Near Zero-Downtime)
• Rolling Upgrades ab 10.1.0.3
• Mit Transient Logical Standby Datenbank
Rolling Upgrades 11g
• Transient Logical Standby bedeutet:
1.
2.
3.
4.
5.
6.
Restore Point anlegen, Physical Standby Controlfile anlegen
Existierende Physical Standby Datenbank
Umwandlung in eine Logical Standby
Upgrade/Patching der Logical Standby
Rollentausch - Standby wird zur Produktions-DB
Zurücksetzen der ehemaligen Produktions-DB auf einen
garantierten Restore Point
7. Einspielen eines Physical Standby Controlfiles
•
Damit wird die ehemalige Produktions-DB zur Physical Standby
8. Starten in der neuen SW-Umgebung
9. Nachfahren der Redolog-Informationen
10. Kontrollierter Rollentausch zurück
Rolling Upgrades
• Fazit:
• Ein sehr schneller Weg für ein Rolling Upgrade
• Downtime < 1min durchaus erreichbar
• Bei Hardware-identischen Systemen sehr verlockend, da evtl. nur
ein einziger Switchover (also nur 1x Downtime) notwendig ist
Agenda
Oracle DataGuard Kurzüberblick
Snapshot Standby
Standby aufbauen mit RMAN
Real-Time-Query
Rolling Upgrades mit Transient Logical Standby
Vermischtes
Vermischtes
Larry Carpenter: Alert.log is admin‘s Friend
Fast Start Failover:
•
•
Nun auch LGWR ASYNC erlaubt (MaxPerformance/MaxAvailability)
User-defined Failover-Kriterien
Clients
PROD
STANDBY
LGWR ASYNC
Data Guard Broker
Broker Agent
Broker Agent
•
Vermischtes
•
RMAN und Dataguard
•
Block Change Tracking nun auch auf der Physical Standby
zuschaltbar für Fast Incremental Backups (ADG)
• Archive Log Deletion Policy
• Nun auch "Shipped" konfigurierbar
• "Applied On Standby" gilt nun für alle Destinations
• Transparentes Backup, Restore & Recovery mit allen
Datenbanken in der Konfiguration
Vermischtes
•
•
•
•
White Paper, Oracle Data Guard 11g:
The Next Era in Data Protection and Availability
Data Protection and Availability for Oracle Database
Standby-Tuning: Note:387343.1 - MAA Redo Apply BP
DG im RAC-Umfeld
11gR2 RAC to RAC Dataguard with Dataguard
Broker MAA
http://www.oracledba.org/11gR2/dr/11gR2_dataguard_
RAC_to_RAC.html
....
Sehr gute Anleitung:
Google: Standby Datenbank in "5 Minuten„
Fazit
•
Oracle Dataguard ist:
Sagt unser Dataguard Produkt-Manager - Eine „Saubere“ Sache sage ich
Fragen, Anregungen?