Data Guard - Failed Primary

Prior to Oracle 10g, after a failover occurs, it was impossible to bring the original primary database back into Data Guard configuration as a new physical standby without restoring it. To avoid this restore, the flashback logging must have been enabled or the guaranteed restore point must have been created in the original primary database to allow flashback database to a state prior to its failure. 

Setup a job to create GRP daily and drop GRP of the previous day. See my blog at http://anandbitra.blogspot.com/2011/05/guaranteed-restore-point.html for more info on GRP.

FAILOVER TO PHYSICAL STANDBY

1. Identify any gaps on standby.

SQL> select thread#, low_sequence#, high_sequence# from v$archive_gap;

2. If primary host is accessible, copy missing logs and register on standby.

SQL> alter database register physical logfile 'path';

3. Initiate failover on standby. Force terminates active RFS process.

SQL> recover managed standby database finish force;

4. Convert the standby to primary.

SQL> alter database commit to switchover to primary;

5. Open this new primary database.

SQL> shutdown immediate

SQL> startup

6. Stop redo transport to failed primary.

SQL> alter system set log_archive_dest_state_2='defer';

CONVERT FAILED PRIMARY TO PHYSICAL STANDBY

1. Determine SCN at which old standby became primary.

SQL> select to_char(standby_became_primary_scn) from v$database;

2. On failed primary, flashback to GRP.

SQL> startup mount

SQL> flashback database to restore point <before_failure>;

3. Recover database until SCN.

SQL> recover database until change <standby_became_primary_scn>;

4. Convert to physical standby.

SQL> alter database convert to physical standby;

5. Mount the database.

SQL> shutdown immediate

SQL> startup mount

6. Start redo apply on this new standby. 

SQL> recover managed standby database disconnect from session;

7. Start redo transport on primary.

SQL> alter system set log_archive_dest_state_2='enable'; 

SWITCHOVER TO ORIGINAL PRIMARY (CURRENTLY PHYSICAL STANDBY)

1.  On primary, switchover to physical standby.

SQL> alter database commit to switchover to physical standby with session shutdown;

2. Mount the database.

SQL> shutdown immediate

SQL> startup mount

3. Start Redo apply.

SQL> recover managed standby database disconnect from session;

4. On standby, switchover to primary.

SQL> alter database commit to switchover to primary;

5. Open the database.

SQL> shutdown immediate

SQL> startup

 

Guaranteed Restore Point

A Guaranteed Restore Point ensures that the database can be reverted back to its state at the restore point SCN regardless of the DB_FLASHBACK_RETENTION_TARGET initialization parameter setting. As it is always preserved, it must be dropped explicitly. The disk space usage and the performance overhead of logging for GRP is lower than normal flashback database logging because the database stores the before image of the first time modified block in flashback logs. Any subsequent modifications to the same block do not cause the contents to be logged.

Requirements:
1. The database must be running in ARCHIVELOG mode. 
2. The fast recovery area must be configured. See my blog at http://anandbitra.blogspot.com/2011/04/fast-recovery-area.html
3. If the flashback logging is not enabled, the database must be mounted to create the first GRP or if all previously created GRPs have been dropped.

Create GRP
SQL> create restore point before_app_upgrade guarantee flashback database;

Drop GRP
SQL> drop restore point before_app_upgrade;

List Restore Points
SQL> select name,scn,time,database_incarnation#,guarantee_flashback_database,storage_size from v$restore_point;

Considerations:
Dropping a tablespace or shrining a datafile can prevent flashback the affected datafiles to GRP. However, the shrunken file can be taken offline to flashback the rest of the database and then the shrunken datafile can be restored and recovered later.