When you verify that if the primary cluster can be switched to a standby cluster, or the other way around, you need to check the value of the SWITCHOVER_INFO field in the V$OB_CLUSTER view. This topic describes the meanings of the different values of this field and how to fix the error.
Value 1: CHECK PRIMARY CLUSTER SERVER STATUS
Description
Some OBServers may be inactive. You must check the state of OBServers in the primary cluster.
Solution
Run the following command to query the state of OBServers in the primary or standby cluster. If STATUS is not ACTIVE, the OBServer is not active and you need to restore it.
obclient> SELECT SVR_IP, STATUS FROM __ALL_SERVER WHERE STATUS != 'ACTIVE';
Value 2: CHECK MERGE STATUS
Description
You need to check the merge task for errors.
Solution
Run the following command on the current cluster to query the state of the merge task. If an error occurs, contact technical support.
obclient> SELECT ZONE, NAME, INFO FROM __ALL_ZONE WHERE NAME ='MERGE_STATUS';
Value 3: NONE SYNCED STANDBY CLUSTER
Description
You cannot switch the primary cluster to a standby as no synchronized standby cluster is available.
Solution
On the primary cluster, run the following command to query synchronization details of standby clusters and causes of asynchronization.
obclient> SELECT CLUSTER_ID, SYNCHRONIZATION_STATUS FROM V$OB_STANDBY_STATUS;
Value 4: CHECK SYS SCHEMA SYNC STATUS
Description
Schemas are not synchronized. You need to ensure that the schemas of the system tenant in the standby cluster are synchronized.
Solution
Run the following command on the primary and standby clusters to query the tenant_id with asynchronous schemas. You need to wait until schemas of the tenant are synchronized. If the synchronization is stuck, contact technical support.
obclient> SELECT *, USEC_TO_TIME(MIN_SYS_TABLE_SCN), USEC_TO_TIME(MIN_USER_TABLE_SCN) FROM V$OB_CLUSTER_STATS;
Value 5: CHECK USER SCHEMA SYNC STATUS
Description
Schemas are not synchronized. You need to ensure that the schemas of the common tenant in the standby cluster are synchronized.
Solution
Run the following command on the primary and standby clusters to query the tenant_id with asynchronous schemas. You need to wait until schemas of the tenant are synchronized. If the synchronization is stuck, contact technical support.
obclient> SELECT *, USEC_TO_TIME(MIN_SYS_TABLE_SCN), USEC_TO_TIME(MIN_USER_TABLE_SCN) FROM V$OB_CLUSTER_STATS;
Value 6: CHECK FREEZE INFO SYNC STATUS
Description
The frozen information is not synchronized. You need to ensure that the frozen information of the standby cluster is synchronized.
Solution
Run the following command on the primary and standby clusters to query the asynchronous frozen information. You need to wait until the frozen information is synchronized. If the synchronization is stuck, contact technical support.
obclient> SELECT * FROM __ALL_VIRTUAL_FREEZE_INFO;
Value 7: CHECK ENOUGH REPLICA
Description
You need to check whether the standby cluster has sufficient replicas.
Solution
Insufficient replicas mean that the number of active replicas is not enough to constitute a majority. This is probably caused by a failure of the OBServer or network isolation. You can check the state of all OBServers in the standby cluster to verify whether each partition has sufficient active replicas by using the following SQL statement:
obclient> SELECT SVR_IP, STATUS FROM __ALL_SERVER WHERE STATUS != 'ACTIVE';
Value 8: CHECK REDO LOG SYNC STATUS
Description
REDO logs are not synchronized. You need to ensure that the REDO logs of the standby cluster are synchronized.
Solution
Run the following command on the standby cluster to check for replicas with failed log synchronization.
obclient> SELECT * FROM __ALL_VIRTUAL_CLOG_STAT WHERE IS_IN_SYNC=0;
If you find replicas with unfinished log synchronization, wait until the logs are synchronized. If the log synchronization keeps lagging behind or gets stuck, contact technical support.
Value 9: CAN NOT ACCESS CLUSTERS: cluster1, cluster2
Description
You cannot access some standby clusters, and must verify their state.
Solution
On the primary cluster, run the following command to query the synchronization details of standby clusters.
obclient> SELECT CLUSTER_ID, SYNCHRONIZATION_STATUS FROM V$OB_STANDBY_STATUS;Check the value of the
SYNCHRONIZATION_STATUSfield and take corresponding actions.
Value 10: NO CLUSTER IN SWITCHING
Description
You cannot switch a standby cluster to the primary cluster as no cluster is in the SWITCHING state. This error may occur when the standby cluster is in the NOT ALLOWED state.
Solution
Run the following command on the primary cluster to query the state of standby clusters and check for the record of previous successful switchover operations.
obclient> SELECT SWITCHOVER_STATUS FROM V$OB_CLUSTER;
Value 11: PRIMARY CLUSTER NOT IN SYNC MODE
Description
The log transfer mode is not set to SYNC mode.
In Maximum Protection and Maximum Availability modes, the log transfer mode of the primary cluster must be set to SYNC. After the switchover, the protection mode remains unchanged and the original primary cluster becomes a synchronous standby cluster.
Solution
Log on to the primary cluster and set its log transfer mode to SYNC. For more information, see Configure log transfer parameters for a standby cluster.
Value 12: STANDBY CLUSTER NOT IN SYNC MODE
Description
The log transfer mode is not set to SYNC mode.
In Maximum Protection and Maximum Availability modes, you can only switch a standby cluster in SYNC mode to the primary cluster. The log transfer parameter of the standby cluster is not set to SYNC, so you cannot switch it to the primary cluster.
Solution
Select a standby cluster in SYNC mode and switch it to the primary cluster.
Value 13: PRIMARY CLUSTER HAS REPLICA IN RESTORE
Description
Switchover is not allowed because some replicas on the primary cluster are not restored.
Solution
You must delete these unrestored replicas to carry on the role switchover.
Methods to query the state of replicas on the primary cluster:
Check the state of the system table replica being restored
obclient> SELECT * FROM __ALL_ROOT_TABLE WHERE IS_RESTORE != 0;Check the state of the user table replica being restored
obclient> SELECT * FROM __ALL_VIRTUAL_META_TABLE WHERE IS_RESTORE != 0;
Value 14: STANDBY CLUSTER HAS REPLICA IN RESTORE
Description
Switchover is not allowed because some replicas on the standby cluster are not restored.
Solution
You can continue the role switching only after replicas in the standby cluster are restored.
Run the following command on the standby cluster to check the replica state:
Check the state of the system table replica being restored
obclient> SELECT * FROM __ALL_ROOT_TABLE WHERE IS_RESTORE != 0;Check the state of the user table replica being restored
obclient> SELECT * FROM __ALL_VIRTUAL_META_TABLE WHERE IS_RESTORE != 0;
Value 15: PRIMARY CLUSTER DOING BACKUP
Description
The switchover is not allowed as the primary cluster is in the process of backup. Backup is not supported for standby clusters, so you must stop the backup task first.
Solution
Run the following command to stop backing up the primary cluster.
obclient> ALTER SYSTEM CANCEL BACKUP;
Value 16: CHECK OTHER PRIMARY CLUSTER
Description
Due to the existence of another primary cluster, the switchover is not allowed to avoid the circumstance of two primary clusters.
Solution
Run the following command on the current cluster to query information of other clusters. Confirm the cluster state and select the correct cluster.
obclient> SELECT * FROM V$OB_STANDBY_STATUS;
Value 17: INNER ERROR
Description
An internal error occurred.
Solution
Contact technical support.