Flashback and Data Guard :

You can enable flashback on the primary database, on one or more standby databases or on any combination of the two. You can use flashback in the following circumstances
On the primary database     to recover data in lieu of a delay on the apply processing.
On a physical standby database     to open a physical standby database in snapshot mode (read-write for test). Data Guard uses a guaranteed restore point (GRP) before opening the physical standby in read-write mode. The retention period is also not needed as the flashback logs will be maintained as long as necessary. Make sure that you size the flash area accordingly as this could stop the redo processing.
On the primary and all standby databases     If you want to flashback primary database, you must enable it on all standby databases as well. The retention period must be the same across all databases. If you perform a flashback recovery on the primary, you must stop the apply process on all standbys, when the open resetlogs has been executed, you must flashback each standby to a point in time prior to the primary. When the redo starts to be transmitted again the standby will recognize the change and recover the standby up to the point of the flashback and then start processing the new redo stream.
On the primary but after a failover     to be able to recover the database after a failover. Data Guard needs only a little bit of flashback log to move the failed primary back in time so that it can be converted to a standby database and resynchronized with the primary.

Physical Switchover

In this section we will perform a switchover, we will perform some checks before the switchover, then switchover. I will discuss the switchover using SQLPlus then how to do it using the Broker, learning the SQLPlus will give you a good understanding on how the whole processes works and what the broker does in the background.

To start with the check that you must do are the following

    Make sure that all of the necessary Data Guard parameters have been configured
    Make sure that the SRL files have been configured
    Make sure that you have a temporary data file defined
    Make sure that Flashback has been enabled (optional)

The reason for the checks is that if it all goes wrong it would easy be able to switchback to the primary.

First we verify that the standby has received all the redo
check redo has been received    

## check the syn status, it should say yes (run on the standby)
select db_unique_name, protection_mode, synchronization_status, synchronized from v$archive_dest_status;

## if it says NO then lets make further checks (run on the standby)
select client_process, process, sequence#, status from v$managed_standby;

## now check on the primary we should be one in front (run on the primary)
select thread#, sequence#, status from v$log;

Note: if using a RAC environment make sure you check each instance

Once you have determined that the redo stream is current, we need to check that the redo has been applied
check that redo has been applied (physical)    

## check that MRP (applying_log) matches the RFS process, if the MRP line is missing then you need to
## start the apply process, you also may see the status of wait_for_gap so wait until the gap have been
## resolved first

select client_process, process, sequence#, status from v$managed_standby;

check that redo has been applied (logical)     ## if you are using a logical standby then you need to check the following to confirm the redo has been
## applied

select applied_scn, latest_scn, mining_scn from v$logstdby_progress;

## if the mining scn is behind you may have a gap check this by using the following

select status from v$logstdby_process where type = 'READER';

Finally you must cancel any jobs and backups that are running, however there should be none as you will probably be performing the switchover during a quiet period
show any running jobs or backups    

select process, operation, r.status, mbytes_processed pct, s.status from v$rman_status r, v$session s where r.sid=s.sid;

Once the checks have been carried out you are ready to perform the switchover, you may want to tail the alert logs as it will give you an idea on what is going in the background and you can formularize yourself with the messages that are displayed, you can increase the level of messaging for diagnostic purposes
increase logging level     alter system set log_archive_trace=8129;

## to turn it off again
alter system set log_archive_trace=0;

One point to make is that if you are using flashback make sure that you drop the GRP restore point on all databases after the switchover is complete, otherwise you will be generating permanent flashback database logs forever.

If you are running a Oracle RAC then you need to bring the RAC down to a single instance, because this is a planned it may be worth using shutdown immediate and try not you use shutdown abort, as oracle will have to recover first. You can check the session by running the below command
check active sessions    
 select switchover_status from v$database;

check the switchover status    
 select switchover_status from v$database;

Now it it is time to switchover
switchover     ## on the primary

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

keep an eye on your alert logs, then check that first part of the switchover has completed
check the switchover status      
select switchover_status from v$database;

to finish off the switchover
complete the switchover    
alter database commit to switchover to primary with session shutdown;

open the new primary database
open the new primary    
alter database open;

finish off the old primary and start it up as a standby
finish off the old primary    
shutdown immediate;
startup mount;
alter database recover managed standby database using current logfile disconnect;

You can now startup auxiliary RAC instances on the primary and standby databases if you are using RAC.