Implementing Data Guard - Expert Consolidation in Oracle Database 12c - page 352

Completely removing the Broker configuration
Sometimes it is necessary to completely remove a Data Guard Broker configuration. The main reason for having to
remove the Broker configuration is a completely failed role transition paired with a network problem or some other
hard-to-explain weirdness. In some rare circumstances the switchover succeeds, but the Broker is unaware that it did.
To remove the configuration you need to stop the Broker on each database in the broker configuration. If your
configuration is not entirely broken then you might be lucky and query which databases are currently part of the
configuration:
SQL> select DB_UNIQUE_NAME,PARENT_DBUN,DEST_ROLE from V$DATAGUARD_CONFIG;
DB_UNIQUE_NAME PARENT_DBUN DEST_ROLE
------------------------------ ------------------------------ -----------------
CDB1DCA NONE PRIMARY DATABASE
CDB1DCB CDB1DCA PHYSICAL STANDBY
CDB1DCC CDB1DCA PHYSICAL STANDBY
In our scenario, there are three databases in the configuration: CDB1DCA, CDB1DCB, and CDB1DCC. The first
step in removing the broker configuration is to stop the Broker processes. On each database, issue this command:
SQL> alter system set dg_broker_start = false;
Then you need to remove the Broker configuration files. Their location is stored in the initialization parameters
dg_broker_config_file1 and dg_broker_config_file2 respectively. After the Broker services are stopped, move
these files to a different location. Now start the Broker on each database, the missing broker configuration files will be
created as part of the process.
Performing a graceful switchover operation
Regular disaster recovery tests are essential in spreading confidence in the procedure and to detect changes to
the setup that require either fixing or updating of the documentation. Very often it is not the database that causes
problems—Data Guard is very reliable—but hard-coded connection strings in applications. These problems can
easily be identified by regular switchover exercises.
With the Broker configuration in place it is very simple to perform the switchover. A first check should be the
switchover readiness of the database you want to switch to. In a multi-standby scenario you should switch over to the
database that is most in sync with production. Technically speaking there is nothing wrong with switching over to a
database that is hours behind the primary, but to save time and nerves it is not recommended to send all that redo
over to it before the switchover can actually occur. If you are unsure about transport and apply lags you can query the
standby databases in your configuration as shown here:
[oracle@server2 ~]$ dgmgrl /@cdbfsdcb
DGMGRL for Linux: Version 12.1.0.1.0 - 64bit Production
Copyright (c) 2000, 2012, Oracle. All rights reserved.
Welcome to DGMGRL, type "help" for information.
Connected as SYSDBA.
DGMGRL> show database "CDBFSDCB"
Database - CDBFSDCB