Which statement is true regarding Oracle Net connectivity for a Data Guard Broker configuration?
A.
To start SQL apply on a logical standby database, a TNS entry enabling connectivity to the primary database instance must be defined on the logical standby database host.
B.
the LOCALJJSTERNER initialization parameter must be set to the listener used to register theprimary database instance.
C.
To enable Reatime Query on a physical standby database, a TNS entry enabling connectivity to the standby database instance must be defined on the primary database host.
D.
A TNS enabling connectivity to the primary database instance must be defined on each of the standby database hosts.
E.
A TNS entry or entries enabling connectivity to standby database instance(s) must be defined on the primary database host.
E??
primary must have a connection to its standbys to send redo?
A standby does not need to have contact with the primary?
Well, bare minimum is “E” i.e. primary must send redo/archivelogs to standby.
I think that is:
Prerequisites
The following conditions must be met before you can use the broker:
The primary and standby databases must be using the same version of Oracle Database and each can be installed in either a single-instance or multi-instance environment. The database must be licensed for Oracle Enterprise Edition or Personal Edition.
You must use a server parameter file (SPFILE) to ensure the broker can persistently reconcile values between broker properties and any related initialization parameter values. See Section 4.3.2 for more information.
If any of the databases in the configuration is an Oracle RAC database, you must configure the server parameter file (SPFILE) appropriately for use in an Oracle RAC environment.
See Also: Oracle Real Application Clusters Administration and Deployment Guide for information about initialization files in an Oracle RAC
The value of the DG_BROKER_START initialization parameter must be set to TRUE.
See Section 3.4 for more information. (Cloud Control sets this parameter automatically.)
If any of the databases in the configuration is an Oracle RAC database, you must set up the DG_BROKER_CONPIG_FILEn initialization parameters for that database such that they point to the same shared files for all instances of that database. The shared files could be files on a cluster file system, if available, or stored using Oracle Automatic Storage Management (Oracle ASM).
Oracle Net Services network configuration files must be set up on the primary database and on the standby database if you configure an existing standby database into the broker configuration. Cloud Control can assist you in creating the configuration files when creating a standby database.
See Also: Oracle Database Net Services Administrator’s Guide for more information about network configuration files
In a broker configuration, you use the DGConnectldentifer property to specify a connect identifier for each database. The connect identifier for a database must:
— Allow all other databases in the configuration to reach it.
— Allow all instances of an Oracle RAC database to be reached.
— Specify a service that all instances dynamically register with the listeners so that connect-time failover on an Oracle RAC database is possible.
— Have failover attributes set to allow the primary database’s Redo Transport Services to continue shipping redo data to an Oracle RAC standby database, even if the receiving instance of that standby database has failed.
See Also: Oracle Database Net Services Administrator’s Guide for more information about connect identifiers
To enable DGMGRL to restart instances during the course of broker operations, a static service must be registered with the local listener of each instance. A static service registration is also required to enable the observer to restart instances as part of automatic reinstatement of the old primary database after a fast-start failover has occurred. A static service needs to be defined and registered only if Oracle Clusterware or Oracle Restart is not being used.
By default, the broker assumes a static service name of db_unique_nante_DGMGRL.db_domain and expects the listener has been started with the following content in the listener.ora file:
LISTENER (DESCRIPTION =
(ADDRESS_LIST= (ADDRESS=(PROTOCOL=tcp) (HOST=host_name)
(PORT=port_nurn))))
SID_LIST_LISTENER= (SID_LIST= (SID_DESC= (SID_NANE=sid_name)
(GLOBAL_DBNAME=db_unique_name_DGMGRL . dk_domain)
(ORACLE_HOME=oracle_home)
(ENVS=”TNS_ADMIN=oracle_home/network/admin”)))
Alternatively, you can use a different static service name. If you do, be sure to modify the StaticConnectldentifier instance-specific property to reflect the static service that has been registered.
See Also:
. See Oracle Database Net Services Administrator’s Guide for more information about configuring static services
. See the My Oracle Support Note 1387859.1 at http://support.oracle.com for additional information about using static services and the StaticConnectldentifier configurable property
The primary database must be opened in ARCHIVELOG mode.
You must set the COMPATIBLE initialization parameter to 11.2 or higher for both the primary and standby databases. However, if you want to take advantage of new Oracle Database 12c Release 1 (12.1) features, then set the COMPATIBLE parameter to 12.1 on all databases within the Oracle Data Guard configuration.
For the broker to work, the COMPATIBLE initialization parameter must be set to the same value on both the primary and standby databases. If the values differ, redo transport services may be unable to transmit redo data from the primary database to the standby databases.
Select and configure a redo transport authentication method, as described in Oracle Data Guard Concepts and Administration.
As of Oracle Database 12c Release 1 (12.1), for all databases to be added to a broker configuration, any LOG_ARCHIVE_DEST_n parameters that have the SERVICE attribute set, but not the NOREGISTER attribute, must be cleared.
See Also:
. Section 3.4 for more information about preparing and starting Oracle Data Guard broker
StaticConnectidentifier
The StaticConnectIdentifier configurable instance-specific property specifies the connection identifier that the DGMGRL. client will use when starting database instances. If this property has a null value, then the DGConnectldentifier value is used for operations that involve shutting down and starting up the instance.
Connect descriptor that is the concatenation of:
. The ADDRESS attribute value of the listener that is specified for the LOCAL_LISTER initialization parameter
. The value for the SERVICE_NANE attribute will be set to a concatenation of db_unique_narne_DGNGRL.db_domain
If the instance specified by the SidName property is started on a different host (read from the HOST_NAME column of the V$INSTANCE view) than the host on which it had been previously started, the broker automatically updates the default value of the StaticConnectIdentifier property to incorporate the current ADDRESS attribute of the listener that is specified for the LOCAL_LISTENER initialization parameter.
A – It’s wrong! This is about SQL Apply, not about DG Broker configuration
B – It’s right!
C – It’s wrong! This is about Real Time Query, not about DG Broker configuration
D – It’s wrong! This is necessary to Data Guard configuration not DG Broker configuration.
E – It’s wrong! This is necessary to Data Guard configuration not DG Broker configuration.
According to MOS Note 1387859.1
Seems “B” is right. D & E can be achieved without a TNS entry and by giving full DESCRIPTION in the DG configuration.
StaticConnectIdentifier and LOCAL_LISTENER
If the user modifies the Broker StaticConnectIdentifier property default value, then the Broker assumes that the user will from this point forward continue to maintain the value. If an instance is started on a different host than the static entry is configured for, the Broker will not be able to connect to the instance when it is shut down.
Similarly, once the database LOCAL_LISTENER initialization parameter has been modified by the user, it will no longer automatically be updated by Oracle Clusterware and will contain an incorrect value if a database instance is relocated to a new host system.
In addition, if the LOCAL_LISTENER initialization parameter for a database is modified by the user after the database has been added to a Data Guard Broker configuration, the existing StaticConnectIdentifier property value does not automatically change to reflect the new LOCAL_LISTENER value.
Note that as a best practice, users should not change the default values assigned to the Broker StaticConnectIdentifier property or to the database LOCAL_LISTENER initialization parameter.
If there is a requirement that the LOCAL_LISTENER parameter be changed then the Broker configuration needs to be manually updated as follows to restore automatic Broker updates of the StaticConnectIdentifier property values for a database instance.