We have 3 node RAC 22.214.171.124 Primary database data guarded to a 3 node RAC 126.96.36.199 Standby database. There is an activity scheduled to perform some of order extracts in the database which is going to result in a lot of changes. Currently the discussion is on whether what should be the quickest way to go back to a point in time before the extract process starts in case of any issues. The options that we are looking at are:
1) Create a guaranteed restore point on both the Primary and Standby and use this to flashback the database (Quick but we have had issues where in the guaranteed restore point still does not guarantee the availability of the flashback logs) - Tested
2) Use RMAN backup from a day before to restore and recover to point in time before the extract process began (Time consuming) - Tested
3) Use export backup to perform a redirected restore i.e import the data from before the extract process (Time consuming) - Tested
4) Create a guaranteed restore point on both Primary and Standby, stop the Redo Apply/Ship at the time we create the guaranteed restore point and at a point we face some issue and need to go back, simply failover to the physical standby database and then reinstate the new standby database - This has not been tested yet but seems a viable option
With regard to the point 4, note that we are not concerned about data loss as the whole point of stopping the redo apply is to prevent the standby to be caught up with Primary during the run of the extract process. The question is whether the dataguard broker will allow failover of the primary to standby, in a situation described in bullet point 4). Please advice.
Yes, point 4 is a feasible option.
Stop redo apply from the point you start extract. If the process is a success, just turn on media recovery or MRP. Else you can assume that primary is destroyed and perform the failover of standby as primary and rebuild the standby.