IT-Symposium Mike Dietrich. BU Database Technologies ORACLE Deutschland GmbH. Page 1. 1

Transkript

1 Mike Dietrich BU Database Technologies ORACLE Deutschland GmbH Page 1 1

2 Total synchron Daten retten ohne Downtime?! Oracle DataGuard und Agenda Oracle DataGuard Daten retten ohne Downtime Zusatznutzen Page 2 2

3 Einführung Die Kardinal-Fragen: Was kostet ein Ausfall pro Minute/Stunde/Tag? Was kostet Datenverlust? Wie sichtbar ist ein Ausfall? Wieviel Downtime ist gestattet? Wie stark sind die Nerven der DBA's? Einführung Wie...??? Batch-Job... Daten gelöscht... aus Versehen...?!? Page 3 3

4 Agenda Oracle DataGuard Daten retten ohne Downtime Zusatznutzen Oracle DataGuard Desaster Recovery Lösung für Oracle DB's Kostenfreies Feature der Oracle Enterprise Edition Automatisiert das Anlegen und den Betrieb einer oder mehrerer Standby-Datenbanken Ausfall der Produktionsdatenbank Standby-Datenbank übernimmt x1000km Entfernung möglich Page 4 4

5 DIGITAL DATA STORAGE IT-Symposium 2005 Oracle DataGuard Datenbank-Releases gleicher Release-Stand gleiche Bit-ness Betriebssystem-Releases gleiches OS unterschiedliche Bit-ness möglich, aber nicht empfohlen unterschiedliche Release-Stände möglich, aber nicht empf. Empfehlung: identische Hardware, identische Betriebssysteme, identische Patchlevel, identische Oracle-Patches Oracle DataGuard Clients Primary Site Standby Site Clients Backup Failover/Switchover Log Informationen Gap Detection No Data Loss Protection Modes Broker Agent Broker Agent Data Guard Broker Page 5 5

6 Oracle DataGuard? 2 Typen von Standby-Datenbanken Physical Standby Redolog-Dateien werden recovert Entweder Recovery Modus oder Read-Only Blockidentische Kopie der Produktionsdatenbank Desaster Recovery (Failover) Logical Standby Redolog-Dateien werden extrahiert SQL-Statements werden auf die Standby angewendet Logische Kopie der Produktionsdatenbank Online Reporting, Rolling Upgrades Oracle DataGuard 3 Möglichkeiten zur Administration Pures SQL DataGuard Broker und DGMGRL DataGuard Broker und EM GridControl Page 6 6

7 Oracle DataGuard - 10g New Features init-parameter LOG_ARCHIVE_DEST_n: VALID_FOR-Attribute erlaubt eine init.ora für alle Rollen kein Tauschen der Init-Dateinen mehr nach Failover oder Switchover Beispiel: *.log_archive_dest_2= 'SERVICE=phys LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES, ALL_ROLES) DB_UNIQUE_NAME=PHYS' Oracle DataGuard - 10g New Features Clients Primary Site Standby Site REAL TIME APPLY Redo-Records werden sofort angewendet kein Warten auf ARCH Broker Agent Broker Agent Data Guard Broker Page 7 7

8 Oracle DataGuard - 10g New Features Transaktionen Oracle Net Up-to-date Standby DB LGWR RFS MRP/ LSP Primär Datenbank Online Redo Logs Standby Redo Logs ARCH Real Time Apply ARCH Archivierte Redo Logs Archivierte Redo Logs Oracle DataGuard - 10g New Features Engere Synchronisation der Standby mit der Poduktivdatenbank Up-to-Date Echt-Zeit-Reporting Schnelles Switchover und Failover Verringert geplante und ungeplante Ausfallzeiten Bessere Recovery Time Objective (RTO) beim Desaster Recovery Kein Delay!!! SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE; Physical Standby SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Logical Standby Page 8 8

9 Agenda Oracle DataGuard Daten retten ohne Downtime Zusatznutzen Logische Korruptionen, die durch Benutzerfehler entstehen, sind für ca. 40% aller Ausfälle verantwortlich!!! Benutzer- Fehler Andere Ursachen für Ausfälle Page 9 9

10 Traditioneller Ansatz: Backup vom Tape einspielen Recovery mit archivierten Logfiles + Online Redologs Fehler F e h l e r b e h e b u n g t Mit : Einfach die Daten zum Zeitpunkt X aus dem -Log wiederherstellen - ein Kommando!!! Fehler Fehlerbehebung t 3 Ausprägungen von FLASHBACK Query Versions Query Transaction Query Undo Segmente Table / Drop Recycle Bin Database Point-In-Time-Recovery Kein Restore des Backups Nahtlose Integration in den RMAN Logs Page

11 Disk Write geänderter Block Blockinhalt - vorherige Versionen Rückspulknopf in der Datenbank Log Enthält vorherige Blockinhalte Konfiguration: Log Flash Recovery Area SQL> ALTER DATABASE FLASHBACK ON; Festlegen der Vorhaltezeit Initialisierungsparameter (init.ora / spfile) db_recovery_file_dest db_recovery_file_dest_size db_flashback_retention_target [Default: 1440] Page

12 Agenda Oracle DataGuard Daten retten ohne Downtime Zusatznutzen DataGuard und Real Time Apply FLASHBACK ON FLASHBACK ON Page

13 Szenarien DataGuard und I. auf PHYS Standby Ziel: Wiederherstellen von Daten II. auf PROD Ziel: PITR auf Produktion ohne Verlust der Standby III. nach Failover zu PHYS Ziel: kein Neuaufbau der Standby nach Failover I. auf PHYS Ausgangspunkt: TRUNCATE TABLE TRUNCATE TABLE Ziel: Daten wiederherstellen, keine Downtime auf PROD Vorgehensweise: 1) PHYS mit FLASHBACK STANDBY DATABASE zurückfahren 2) PHYS read-only öffnen 3) Benötigte Daten exportieren 4) Automatische Resynchronisation der Standby 5) Daten auf PROD wieder einspielen Page

14 I. auf PHYS PROD: SQL> select current_scn from SQL> v$database; select SQL> truncate table scott.emp; SQL> SQL> select truncate v$database; oldest_flashback_scn table from v$flashback_database_log; $> imp scott/tiger tiger file=exp.dmp ** Daten stehen wieder zur Verfügung ** ** Keine Downtime auf der logfile PROD-DB ** PHYS: select current_scn from table scott.emp; SQL> select oldest_flashback_scn from v$flashback_database_log; SQL> shutdown SQL> shutdown immediate; SQL> startup mount; shutdown immediate; SQL> flashback standby database SQL> to scn startup <CURRENT_SCN mount; von PROD>; SQL> standby alter database open read only; $> exp scott/tiger tiger tables=emp SQL> shutdown openimmediate; read only; SQL> startup tiger mount; tables=emp SQL> shutdown alter database immediate; recover managed standby database using current startup logfile recover disconnect; mount; managed ** automatische Synchronisation ** SQL> flashback standby SQL> alter to scn database <CURRENT_SCN open von PROD>; $> exp scott/tiger SQL> shutdown SQL> alter database SQL> startup recover $> imp scott/tiger standby tiger database file=exp.dmp using current ** Daten stehen logfile wieder disconnect; zur Verfügung ** ** Keine ** Downtime automatische auf der Synchronisation PROD-DB ** ** Agenda Oracle DataGuard Daten retten ohne Downtime Zusatznutzen Page

15 II. auf PROD Ausgangspunkt: Point-In-Time-Recovery der PROD-Datenbank notwendig Ziel: Erhalt der Standby trotz RESETLOGS auf PROD PITR Vorgehensweise: 1) Database auf PROD als PITR 2) Öffnen der PROD mit OPEN RESETLOGS 3) RESETLOGS_CHANGE#-2 auslesen 4) FLASHBACK STANDBY DATABASE auf PHYS durchführen 5) Automatische Resynchronisation von PHYS II. auf PROD PROD: SQL> select current_scn from v$database; SQL> update emp set sal=1; SQL> commit; SQL> shutdown v$database; abort; SQL> startup mount; SQL> flashback database to scn SQL> <CURRENT_SCN commit; von oben>; SQL> alter database open resetlogs; SQL> select resetlogs_change#-2 from v$database; SQL> SQL> select startup sal from scott.emp; mount; ** Daten stehen wieder zur Verfügung ** PHYS: SQL> select current_scn from SQL> update emp set sal=1; SQL> flashback database to scn SQL> shutdown abort; <CURRENT_SCN von oben>; SQL> alter database SQL> open shutdown resetlogs; immediate; SQL> select resetlogs_change#-2 SQL> startup mount; SQL> SQL> from flashback shutdown v$database; standby immediate; database SQL> SQL> select to startup scn sal <RESETLOGS_CHANGE# < from RESETLOGS_CHANGE#-2 mount; scott.emp; Prod ** Daten SQL> stehen alter database wieder zur recover Verfügung managed ** standby database ** automatische using Synchronisation current ** logfile disconnect; ** automatische Synchronisation ** SQL> shutdown immediate; SQL> startup mount; SQL> flashback standby database to scn <RESETLOGS_CHANGE# < RESETLOGS_CHANGE#-2 P>; SQL> shutdown immediate; SQL> startup mount; SQL> alter database recover Prod>; managed standby database using current logfile disconnect; Page

16 III. nach Failover Ausgangspunkt: Failover von PROD nach PHYS ist erfolgt Ziel: Neuaufbau der Standby-Datenbank umgehen Vorgehensweise: 1) Failover von PROD nach PHYS ist erfolgt - PHYS alt ist PROD neu 2) der PROD problem bis STANDBY_BECAME_PRIMARY_SCN 3) Logs bereinigen 4) Standby-Controlfile anlegen 5) Log-Transport wiedereinschalten und ggf. Switchover III. nach Failover ex-prod/new PROD/new-PHYS: PHYS: SQL> shutdown immediate; SQL> startup mount; SQL> flashback database to scn <STANDBY_BECAME_PRIMARY_SCN>; SQL> alter database flashback off; SQL> alter database create standby controlfile as <filename> name>; SQL> shutdown immediate; SQL> startup mount SQL> alter database flashback on; SQL> alter database recover managed standby database using current logfile disconnect; ** Jetzt kontrollierter Rollentausch ** ** (Switchover) möglich, um zur ** ** Ausgangssituation zurückzukehren ** ex-phys/new PHYS/new-Prod: Prod: SQL> select standby_became_primary_scn from v$database; SQL> select standby_became_primary_scn SQL> shutdown from immediate; v$database; SQL> startup flashback mount; database to scn <STANDBY_BECAME_PRIMARY_SCN>; SQL> alter database flashback off; SQL> alter database create standby controlfile SQL> alter system as <filename> set name>; shutdown log_archive_dest_state_2=enable; SQL> alter database immediate; recover managed SQL> startup standby mount database using current SQL> alter logfile database disconnect; flashback on; SQL> alter system set log_archive_dest_state_2=enable; ** Jetzt kontrollierter Rollentausch ** ** (Switchover) möglich, um zur ** ** Ausgangssituation zurückzukehren ** Page

17 Ende gut, alles gut... :-) Q U E S T I O N S A N S W E R S Page

18 Page