Manual Performing a Failover to a Physical Standby Database

os: centos 7.6
db: oracle 19.3

primary DB_UNIQUE_NAME: BOSTON
standby DB_UNIQUE_NAME: CHICAGO

如果使用了 dgmgrl 配置的,就使用 dgmgrl 执行 failover 操作
如果使用了 sqlplus 配置的,就执行如下命令.12c 比之前的命令有所简化.

执行 failover 说明很大概率 primary 已经不可用了,如果是 async 方式,丢数据几乎是必然.
failover 的手动操作过程稍微复杂了一些.

1. If the primary database can be mounted, then flush any unsent archived

If the primary database can be mounted, then flush any unsent archived and current redo from the primary database to the standby database. If this operation
is successful, a zero data loss failover is possible even if the primary database is
not in a zero data loss data protection mode.

First, ensure that Redo Apply is active at the target standby database. Then mount, but do not open the primary database. If the primary database cannot be
mounted, go to Step 2.

Also,ensure that the primary can connect to the target destination by verifying that the
NET_ALIAS_TARGET_DB_NAME is valid and properly established.

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_6='SERVICE=NET_ALIAS_TARGET_DB_NAME ASYNC VALID_FOR=(online_logfile, primary_role) DB_UNIQUE_NAME="target_db_unique_name"' SCOPE=memory;
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_6=ENABLE;

Issue the following SQL statement at the primary database:

SQL> ALTER SYSTEM FLUSH REDO TO target_db_unique_name;

This statement flushes any unsent redo from the primary database to the standby
database, and waits for that redo to be applied to the standby database.
If this statement completes without any errors, go to Step 5.
If the statementcompletes with any error, or if it must be stopped because you cannot wait anylonger for the statement to complete, continue with Step 2.

2. Query the V$ARCHIVED_LOG view on the target standby database

to obtain the highest log sequence number for each redo thread.

SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG;

    THREAD	 LAST
---------- ----------
	 1	 2034
	 2	 1845

If possible, copy the most recently archived redo log file for each primary database
redo thread to the standby database if it does not exist there, and register it. This
must be done for each redo thread.
For example:

SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';

3. Query the V$ARCHIVE_GAP view on the target standby database to determine

if there are any redo gaps on the target standby database.
For example:

SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
---------- ------------- --------------
1 90 92

In this example, the gap comprises archived redo log files with sequence numbers
90, 91, and 92 for thread 1.

If possible, copy any missing archived redo log files to the target standby database
from the primary database and register them at the target standby database. This
must be done for each redo thread.
For example:

SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';

4. After resolving a gap, you must repeat the query until no more rows are returned

SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;

no rows selected

5. Issue the following SQL statement on the target standby database:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

6.Issue the following SQL statement on the target standby database

SQL> ALTER DATABASE FAILOVER TO target_db_name;

For example, suppose the target standby database is named CHICAGO:

SQL> ALTER DATABASE FAILOVER TO CHICAGO;

If this statement completes without any errors, proceed to Step 10.
If there are errors, go to Step 7.

7.If an error occurs, try to resolve the cause of the error and then reissue the statement.

• If successful, go to Step 10.
• If the error still occurs and it involves a far sync instance, go to Step 8.
• If the error still occurs and there is no far sync instance involved, go to Step 9.

8.use the FORCE option

SQL> ALTER DATABASE FAILVOVER TO CHICAGO FORCE;

If the FORCE option is successful, go to Step 10.
If the FORCE option is unsuccessful, go to Step 9.

9.Perform a data loss failover.

If an error condition cannot be resolved, a failover can still be performed (with
some data loss) by issuing the following SQL statement on the target standby
database:

SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;

In the following example, the failover operation fails with an ORA-16472 error. That
error means the database is configured in MaxAvailability or MaxProtection mode
but data loss is detected during failover.

SQL> ALTER DATABASE FAILOVER TO CHICAGO;
ERROR at line 1:
ORA-16472: failover failed due to data loss
You can complete the data loss failover by issuing the following SQL statement:

SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;
Database altered.

10.Open the new primary database:

SQL> ALTER DATABASE OPEN;

11.Oracle recommends that you perform a full backup of the new primary database.

12.restart Redo Apply on the other physical standby databases

If Redo Apply has stopped at any of the other physical standby databases in your
Data Guard configuration, then restart it. For example:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

13.the original primary database can be converted into a physical standby database

After a failover, the original primary database can be converted into a physical standby database of the new primary database using the method described in
Converting a Failed Primary Into a Standby Database Using Flashback Database
or Converting a Failed Primary into a Standby Database Using RMAN Backups, or
it can be re-created as a physical standby database from a backup of the new
primary database using the method described in Step-by-Step Instructions for
Creating a Physical Standby Database.
Once the original primary database is running in the standby role, a switchover
can be performed to restore it to the primary role.

参考:
https://docs.oracle.com/en/database/oracle/oracle-database/19/dgbkr/using-data-guard-broker-to-manage-switchovers-failovers.html#GUID-9A988501-7E18-4A62-8CD6-4BDDFA355C98
https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/managing-oracle-data-guard-role-transitions.html#GUID-1496944D-3089-4A56-A518-5F9FBF82D2C6