Forcing a Takeover on Systems That Use Oracle Data Guard

You perform a takeover when applications need to be brought online on the standby cluster, regardless of whether the data is completely consistent between the primary database and the standby database. In this section, it is assumed that the protection group has been started.

The following operations occur after you initiate a takeover:

If the former primary cluster, cluster-paris, can be reached and the protection group is not locked for notification handling or some other reason, the protection group is deactivated.

For a reminder of which cluster is cluster-paris, see Example Geographic Edition Cluster Configuration in Oracle Solaris Cluster Geographic Edition System Administration Guide.
Databases replicated in the Oracle Data Guard Broker configurations, which are present in the protection group that is being taken over from the former primary cluster cluster-paris, are taken over by the new primary cluster cluster-newyork.

Note - This data might not be consistent with the original databases. Data replication from the new primary cluster, cluster-newyork, to the former primary cluster, cluster-paris, is stopped.
The protection group is activated without data replication enabled. The former primary databases in each of the Oracle Data Guard Broker configurations that are taken over are placed in a disabled, recovery required, state.

For details about the possible conditions of the primary and standby clusters before and after a takeover, see Appendix D, Takeover Postconditions, in Oracle Solaris Cluster Geographic Edition System Administration Guide.

This section provides the following information:

How to Force Immediate Takeover of Oracle Data Guard Services by a Standby Cluster
Actions Performed by the Geographic Edition Software During a Takeover

How to Force Immediate Takeover of Oracle Data Guard Services by a Standby Cluster

Perform this procedure from a node in the standby cluster.

Before You Begin

Before you force the standby cluster to assume the activity of the primary cluster, ensure that the following conditions are met:

Geographic Edition software is up and running on the cluster.
The cluster is a member of a partnership.

Become superuser or assume a role that is assigned the Geo Management RBAC rights profile.
For more information about RBAC, see Geographic Edition Software and RBAC in Oracle Solaris Cluster Geographic Edition System Administration Guide.
Note - If you use a role with Geo Management RBAC rights, ensure that the /var/cluster/geo ACLs are correct on each node of both partner clusters. If necessary, become superuser on the cluster node and set the correct ACLs.
```
# chmod A+user:username:rwx:allow /var/cluster/geo
```
The /var/cluster/geo directory must have the correct access control lists (ACL) applied for compatibility between the Geo Management RBAC rights profile and Oracle Data Guard.
Initiate the takeover.
```
phys-node-n# geopg takeover [-f] protectiongroupname
```
-f

Forces the command to perform the operation without your confirmation.

protectiongroupname

Specifies the name of the protection group.

Example 3-2 Forcing a Takeover by a Standby Cluster

This example shows how to force the takeover of sales-pg by the standby cluster cluster-newyork.

The node phys-newyork-1 is the first node of the standby cluster. For a reminder of which node is phys-newyork-1, see Example Geographic Edition Cluster Configuration in Oracle Solaris Cluster Geographic Edition System Administration Guide.

phys-newyork-1# geopg takeover -f sales-pg

Next Steps

For information about the state of the primary and the standby clusters after a takeover, see Appendix D, Takeover Postconditions, in Oracle Solaris Cluster Geographic Edition System Administration Guide.

Actions Performed by the Geographic Edition Software During a Takeover

When you run the geopg takeover command, the software confirms that databases in the Oracle Data Guard Broker configuration on the standby cluster, that is, the future primary, are enabled (as you cannot perform a takeover to a disabled database). The software also confirms that the Oracle Data Guard command-line interface show configuration command shows one of the following states:

A SUCCESS state
Busy performing a health check (ORA-16610)
The remote database is unreachable (ORA-16625)
The show configuration command times out

If the show configuration command returns any other Oracle error code, the takeover fails.

If the original primary cluster, cluster-paris, can be reached, the software takes offline the application resource groups in the protection group and places them in an Unmanaged state.

On the original standby cluster, cluster-newyork, the software performs the following operations:

Runs the Oracle Data Guard command line interface failover to standby-database-name immediate command. If this command fails and the system remains a standby, the failover to standby-database-name immediate command is run.
Runs the script that is specified by the RoleChange_ActionCmd property.
If the protection group was active on the original standby cluster before the takeover, brings online all shadow Oracle database-server resource groups and application resource groups in the protection group. For HA for Oracle configurations, the dataguard_role resource property is also updated to reflect the new primary and standby clusters.

If the command completes successfully, the standby cluster, cluster-newyork, becomes the new primary cluster for the protection group. Databases that are associated with the Oracle Data Guard Broker configurations of the protection group have their role reversed according to the role of the protection group on the local cluster. The shadow Oracle database-server resource group and any other application resource group in the protection group are online on the new primary cluster. If the original primary cluster can be reached, it becomes the new standby cluster of the protection group. Replication of all databases that are associated with the Oracle Data Guard Broker configurations of the protection group are stopped.

Caution - After a successful takeover, data replication is stopped. If you want to continue to suspend replication, specify the -n option when you use the geopg start command. This option prevents the start of data replication from the new primary cluster to the new standby cluster.

If a previous operation fails, this command returns an error. Use the geoadm status command to view the status of each component. For example, the Configuration status of the protection group might be set to an Error state, depending on the cause of the failure. The protection group might be activated or deactivated.

If the Configuration status of the protection group is set to the Error state, revalidate the protection group by using the procedures that are described in How to Validate an Oracle Data Guard Protection Group.

If the configuration of the protection group is not the same on each partner cluster, you need to resynchronize the configuration by using the procedures described in How to Resynchronize an Oracle Data Guard Protection Group.

Skip Navigation Links
Exit Print View
	Oracle Solaris Cluster Geographic Edition Data Replication Guide for Oracle Data Guard Oracle Solaris Cluster 4.0