Which three will be true after a successful failover to…

sorry, it is not switchover, it is failover, so B,C,D is more correct

Oracle® Data Guard Broker – 12c Release 1 (12.1) – E48241-08
5.4.2 Performing a Manual Failover Operation
After determining that there is no possibility of recovering the primary database in a timely manner, ensure that the primary database is shut down and then begin the failover operation.

The steps in this section describe how to perform a manual failover. Depending on the failover and the types of standby databases involved, some of the databases may need to be reinstated or re-created. The instructions guide you through the appropriate steps for each type of situation.

Step 1 Determine which of the available standby databases is the best target for the failover.
Follow the guidelines described in Section 5.2, “Choosing a Target Standby Database”.

Step 2 Start the failover.
Using Cloud Control or DGMGRL, perform either a complete (recommended) or an immediate failover.

Manual Failover Using Cloud Control:
On the Oracle Data Guard Overview page in Cloud Control, select the standby database that you want to change to the primary role and click Failover. Then, on the Failover Confirmation page, click Yes to invoke the default Complete failover option.

Manual Failover Using DGMGRL:
On the target standby database, issue the FAILOVER command to perform a failover, specifying the name of the standby database that you want to become the primary database:

DGMGRL> FAILOVER TO database-name;

Specify the optional IMMEDIATE clause to perform an immediate failover if any of the following conditions are true:
■ An ORA-752 error has occurred at the standby database
■ An ORA-600 [3020] error has occurred at the standby database and Oracle support has determined that it was caused by a lost write at the primary database
■ A complete failover is not possible

DGMGRL> FAILOVER TO database-name IMMEDIATE;

See Also:
■ FAILOVER on page 7-45

Step 3 Reset the protection mode.
After a manual failover (complete or immediate), the overall Oracle Data Guard protection mode is handled as follows:
■ If the protection mode was at maximum protection, it is reset to maximum performance. You can upgrade the protection mode later, if necessary, as described in Section 4.6.1.
■ If the protection mode was at maximum availability or maximum performance, it remains unchanged.

Note:
If you perform a manual failover when fast-start failover is enabled:
■ The failover can only be performed to the pre-selected target standby database.
■ The broker preserves the protection mode that was in effect prior to the failover.

Step 4 Re-establish a disaster-recovery configuration.
To maintain a viable disaster-recovery solution in the event of another disaster, you may need to perform the additional steps described in Section 5.4.3 to:
■ Reinstate the original primary database to act as a standby database in the new configuration.

Caution:
Do not attempt to reinstate the old primary database if an ORA-752 or ORA-600 [3020] error has occurred at the failover target, because doing so may lead to data loss. Instead, the old primary database must be re-created as a standby from a backup of the new primary using the procedure described in Section 5.4.3.2.

Reinstate or re-create standby databases in the configuration that were disabled by the broker.
After a complete failover finishes, any bystander standby database that is not viable as a standby for the new primary database will be disabled by the broker. This can happen for either of the following reasons:
– A bystander standby database has applied more redo data than the new primary database itself had applied when it was a standby database. The standby database must be re-created or reinstated before it can serve as a standby for the new primary database.
– The failover was to a logical standby database. The broker disables all of the physical and snapshot standby databases in the configuration. They must be re-created before they can serve as standby to the new primary database.

5.4.2.1 How the Broker Performs a Complete Failover Operation
Once you start a complete failover, the broker:
1.Verifies that the target standby database is enabled. If the database is not enabled, you will not be able to perform a failover to this database.
2.Waits for the target standby database to finish applying any unapplied redo data before stopping Redo Apply (if the target is a physical standby database) or SQL Apply (if the target is a logical standby database).
If the target is a snapshot standby database, the broker first converts the database back to a physical standby and then starts Redo Apply to apply all the accumulated redo before completing the failover and opening the database as a primary database.
3.Transitions the target standby database into the primary database role, as follows:
a.Changes the role of the database from standby to primary.
b.Opens the new primary database in read/write mode.
c.Determines whether or not any standby databases that did not participate in the failover operation have applied redo data beyond the new primary database, and thus need to be disabled.
If a bystander standby database is not disabled by the broker during this failover, it will remain in the state it was in before the failover. For example, if a physical standby database was in the APPLY-OFF state, it will remain in the APPLY-OFF state.
By default, the broker always determines whether bystander standby databases will be viable standby databases for the new primary when performing a complete failover. If you want the broker to skip this viability check of bystander standby databases during a complete failover, thus decreasing the overall failover time, set the BystandersFollowRoleChange configuration property to NONE.
When this property is set to NONE, the broker will disable all bystander standby databases without checking whether they have applied more redo data than the new primary database. You will have to reinstate or re-create (see Section 5.4.3) the standby databases after failover has completed. The SHOW CONFIGURATION command will show you which databases can be reinstated and which databases must be re-created. Use the SHOW CONFIGURATION BystandersFollowRoleChange command to see the value of this property. The default value is ALL.
This property also affects whether the broker skips viability checks of bystander standby databases when a fast-start failover occurs.
d.Starts redo transport services to begin transmitting redo data to all bystander standby databases that were not disabled.

Note:
Bystander standby databases may be disabled by the broker during the failover, and they must be reinstated or re-created before they can serve as standby databases to the new primary database. Oracle recommends configuring Flashback Database on every database so that if failover occurs to a physical standby database, you can more easily reinstate any disabled standby databases. If failover occurs to a logical standby database, all physical and snapshot standby databases will be disabled by the broker. In this case, Flashback Database cannot be used to reinstate databases. They must be re-created from a copy of the new primary database. Logical standby databases that are disabled during failover can be reinstated.

4. If the failover target database is an Oracle RAC physical or snapshot standby database, the broker directs Oracle Clusterware to restart all instances that may have been shut down prior to the failover.

The broker allows the failover to proceed as long as there are no errors for the standby database that you selected to participate in the failover. Errors occurring for any bystander standby databases will not stop the failover. If you initiated a complete failover and it fails, you might need to use immediate failover.