This paper talks about the various technologies associated with the Oracle flashback database features in a dataguard broker configuration where multiple standby databases are replicated from a primary database.
The objective, which came out from a client demand where the conversion to a snapshot physical standby was discarded,  is to provide a scenario to test a disaster recovery plan in regards to the behavior of the chain of all components linked to but outside the database infrastructure (application servers, network connectivity and so on residing on the secondary site). In clear, what will really happen the day when a failover will occur. Afterwards, we will revert to the set up where each database participants will recover their initial respective role and rollback the data changes as it is expected that data changes will have taken place on the secondary site.
Briefly, this procedure makes use of guaranteed restore point and switchover through Dataguard Broker: « dgmgrl » commands.
Flashback limitation:  You cannot use Flashback Database to undo a shrink data file operation. However, you can take the shrunken file offline, flash back the rest of the database, and then later restore and recover the shrunken data file.
Used software releases: Oracle Database Enterprise Edition (11.2.0.3.5), Oracle Enterprise Linux 6, virtual machines built with VMware Sphere v5.1.
Initial Dataguard Configuration: A primary database, vdoc, is replicated in maximum performance mode on two standby databases, vdocsby01 and vdocsby02. The configuration is managed via the Dataguard Broker.
1 – Pre-requisites
The databases should be synchronized,  the broker configuration enabled and the flashback recovery area be configured.
Even though flashback database features will be used it won’t be required to put the databases in flashback mode unless the current Oracle database release is lower than 10.2.0.5 or 11.1.0.7.
–       Check the dataguard configuration through the broker dgmgrl command (line 10 must indicate “SUCCESS”):
 
–       set the flashback recovery area if not already done:
Ensure the fast recovery area has allocated sufficient space to accommodate flashback logs for the target retention size and for peak batch rates: use the following conservative formula and approach
DB_RECOVERY_FILE_DEST_SIZE= Current FRA + DB_FLASHBACK_RETENTION_TARGET x 60 x Peak Redo Rate (MB/sec):
 
However, in this procedure only guaranteed flashback logs and « residual » archived redo logs will be required.  If archivelogs fill up the FRA , RMAN backup can be taken which can be used to satisfy the specified guaranteed restore point when using the the RMAN FLASHBACK DATABASE command ( see below).
2 – Backup/purge archivelogs with RMAN on the primary database
 
3 – Create Guaranteed Restore Point on each database.
This step must be first performed on the physically farthest standby database and lastly on the primary database.
–       On standby databases, the recover process must be disable before creating the restore point:
 
Afterwards create the named guaranteed restore point “bswitch_standby”:
 
Once done, enable back the recover process:
 
Execute the same ordered steps on the other standby.
 
–       On the primary database,
Create the named guaranteed restore point “bswitch_primary”:
 
 
4 – Switchover to one of the secondary site
 
Check the new configuration:
 
 
5 – Work on the secondary site.
Now, checks can be performed on the secondary site, end users can play on the database.
 
6 – Switch back to the old primary
This is the first step to return the dataguard configuration to its initial state where the current vdoc standby database was the primary by executing the next switchover on it:
 
Here, the vdoc database has become a primary database again but there is unwanted data generated during the test phase (section § 5). So, the “new” primary is restored to the guaranteed restore point created earlier with RMAN. Connect to primary database with RMAN and execute the indicated commands:
 
 
7 – Recover standby databases
But now, the standby databases are not in a really good state:
 
With the dgmgrl command « SHOW DATABASE VERBOSE <standby_unique_name>; » the following error messages are displayed:
ORA-16700: the standby database has diverged from the primary database
ORA-16766: Redo Apply is stopped
This divergence is the result of the primary database restore and of the open resetlogs.
But restore points are available and usable for restore to a time before the current primary SCN:
 
Re-enable the recovery process on each standby database:
 
 
8 – Drop Restore Points
If everything ends up to the expected state, restore point can be dropped :

On standby databases:

Eventually, databases should be backed up.
Conclusion
This scenario, is a little heavy in comparison to a straight snapshot database conversion approach, We could have also used a direct FAILOVER method on one of the standby while disrupting the connectivity between the initial primary and the target standby database but the broker configuration could have been messed up and would have to be reconfigured.
However as long restore points and a small subset of archivelogs are available this scenario is viable.