In the primary database, there are some parameters that are related to the Data Guard configuration and need to be verified or modified. Now we're going to look into the details of these parameters.

The DB_NAME parameter specifies the database identifier up to eight characters. This parameter must be the same in all the instances of the RAC database and also in the physical standby database. This parameter is validated at MOUNT status when the instance reads the control file; if the DB_NAME parameter does not match the name of the database mentioned in the control file, you will get the following error:

"ORA-01504: database name 'Dummy' does not match parameter db_name 'orcl'"

You don't need to configure or change this parameter in the Data Guard physical standby configuration.

This parameter specifies a unique name for each database having the same DB_NAME parameter. This parameter must be different on the primary, standby, or logical standby database. The DB_UNIQUE_NAME parameter is limited to 30 characters. It can contain alphanumeric, underscore (_), dollar ($), and pound (#) characters but must begin with an alphabetic character. This parameter is static, so it requires bouncing the database in order to change this parameter. If this parameter is not set explicitly, its value will be the same as that of the DB_NAME parameter. You can use the following statement to change the value of the DB_UNIQUE_NAME parameter:

SQL> alter system set db_unique_name='turkey_un' scope=spfile; 

The following table shows the naming format that we're going to use for the physical standby Data Guard configuration example:

Using this parameter, you can enable or disable sending/receiving redo logs to/from databases. You also specify the list of the DB_UNIQUE_NAME parameter of each database in the Data Guard configuration with this parameter.

Use the following syntax to change this parameter:

LOG_ARCHIVE_CONFIG =
{
 [ SEND | NOSEND ]
 [ RECEIVE | NORECEIVE ]
 [ DG_CONFIG=(remote_db_unique_name1, ... remote_db_unique_name9) | NODG_CONFIG ]
 }

Its default value is SEND, RECEIVE, NODG_CONFIG and we only need to update the DG_CONFIG part as follows:

SQL> alter system set log_archive_config= 'DG_CONFIG=(turkey_un,india_un)' scope=both;

This is a dynamic parameter in which you can add or remove the DB_UNIQUE_NAME parameters from the configuration. It's mandatory to set this parameter for RAC databases in Data Guard. However, it's also recommended to set this for single-instance databases. The order of unique names doesn't matter and all unique names in the Data Guard configuration should be included.

This parameter specifies the number of archiver processes in a database. In Data Guard, it's important to have enough archiver processes on the primary database. Think of the value of this parameter as the number of channels where redo can be transferred to the standby database. In peak database times and in gap resolution, if the number of the LOG_ARCHIVE_MAX_PROCESSES value is not sufficient on the primary database, redo shipping may suffer.

Its default value is 2 in 10g (which is generally not sufficient in Data Guard) and 4 in 11g. Depending on the number of remote destinations and redo activity on the primary database, you may need to increase the value. Keep in mind that increasing the value means more resource usage and database start/stop times will also be affected.

These parameters, where n is from 1 to 31 in 11g R2, are used to define destinations to the archive redo data. The LOCATION or SERVICE attribute must be defined with this parameter and indicates a local disk destination and remote database destination respectively. It's an important part of the Data Guard configuration and shows the redo transport flow and its properties.

There are many attributes of the LOG_ARCHIVE_DEST_n parameter and we'll learn most of the important ones in the following sections. Keep in mind that the destination must contain either a LOCATION or SERVICE attribute; the other attributes are optional.

As mentioned earlier, each destination must specify a valid attribute, either of LOCATION or SERVICE, to identify either a local location or a remote destination where redo transport services will send redo data.

The destinations from LOG_ARCHIVE_DEST_1 through LOG_ARCHIVE_DEST_10 can contain either the LOCATION or SERVICE attribute, while destinations from LOG_ARCHIVE_DEST_11 through LOG_ARCHIVE_DEST_31 can contain only the SERVICE attribute, which does not support the LOCAL destination. For the LOCAL destination, you can specify a disk location or FRA. When specifying the SERVICE attribute, a valid Oracle Net Service name that identifies the remote Oracle database instance is used, where the redo data will be sent.

The following is the example for the LOCATION attribute:

SQL> alter system set log_archive_dest_1='LOCATION=/u01/app/oracle/oraarch';

If you are using FRA, it will be as follows:

SQL> alter system set log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST';

The following is an example for the SERVICE attribute:

SQL> alter system set log_archive_dest_2='SERVICE=india db_unique_name=india_un';

This attribute specifies in which states the destination will be valid. It's optional when setting the LOG_ARCHIVE_DEST_n parameter but has to be specified for each redo transport destination of the Data Guard databases so that the redo transport continues after a role transition. This attribute works with two pair of keywords, which are REDO_LOG_TYPE and DATABASE_ROLE.

REDO_LOG_TYPE can be set to the following values:

DATABASE_ROLE can be set to the following values:

When the VALID_FOR attribute is not specified, online redo logfiles and standby redo logfiles will be archived depending on the role of the database. The destination will be enabled even if the role is primary or standby. This is equivalent to the ALL_LOGFILES,ALL_ROLES setting on the VALID_FOR attribute.

Remember that synchronous and asynchronous redo transport modes were covered in Chapter 1, Getting Started. The SYNC and ASYNC keywords are used to specify whether the redo transport mode will be synchronous or asynchronous.

SYNC will be specified when you want to send redo using the synchronous method. In order to commit a transaction on the primary database, related redo data needs to be received by all the destinations that are set with the SYNC attribute. This protection mode is used in either Maximum Protection or Maximum Availability mode. The SYNC attribute does not support destinations from LOG_ARCHIVE_DEST_11 through LOG_ARCHIVE_DEST_31. The SYNC attribute example is shown as follows:

SQL> alter system set log_archive_dest_2='SERVICE=india LGWR SYNC db_unique_name=india_un';

The redo data generated by a transaction doesn't need to be received by a destination that has the ASYNC attribute before that transaction can commit. This attribute will be selected by default if you do not specify either the SYNC or ASYNC keyword. This method is used in the Maximum Performance mode:

SQL> alter system set log_archive_dest_2='SERVICE=india LGWR ASYNC db_unique_name=india_un';

These attributes control when the destination database acknowledges received redo data. Two options are before and after writing to the standby redo log. The AFFIRM attribute ensures that a redo transport destination will send an acknowledgment after writing it to the standby redo logfiles; NOAFFIRM ensures that the redo transport destination will send an acknowledgment before writing it to the standby redo log. This attribute is used with the SERVICE attribute when specifying remote destinations. To view the attribute configuration, you can use the v$archive_dest view with the AFFIRM column.

If both AFFIRM and NOAFFIRM are not specified, it defaults to AFFIRM when the SYNC attribute is specified and NOAFFIRM when the ASYNC attribute is specified.

SQL> alter system set log_archive_dest_2='SERVICE=india SYNC AFFIRM DB_UNIQUE_NAME=india_un';
System altered.

SQL> select affirm from v$archive_dest where dest_id=2;
AFF
---
YES

This attribute is used to specify whether redo data is compressed before transmission. Compression of redo is useful when there is a bandwidth issue in the network between primary and standby databases. The amount of redo data passing over the network decreases, which improves redo transport performance.

You should remember that compression is a CPU-intensive operation and this compression is an option of Oracle Advanced Compression; so, in order to enhance this feature you must purchase a license. The COMPRESSION attribute example is as shown follows:

SQL> alter system set log_archive_dest_2='SERVICE=india COMPRESSION=ENABLE DB_UNIQUE_NAME=INDIA_UN';

This specifies the number of connections to the redo destination when sending archived redo logfiles. MAX_CONNECTIONS will be used only if the redo transport services use ARCH. You can set the MAX_CONNECTIONS value from 1 through 5. However, it's limited with the number of ARCn processes that is specified with LOG_ARCHIVE_MAX_PROCESSES.

Any standby database using ARCn processes will not use standby redo logs if the MAX_CONNECIONS attribute is specified. So we cannot use real-time Redo Apply with MAX_CONNECTIONS.

SQL> alter system set log_archive_dest_2='SERVICE=india MAX_CONNECTIONS=3 db_unique_name=india_un';

SQL> select MAX_CONNECTIONS from v$archive_dest where dest_id=2;
MAX_CONNECTIONS
---------------
              3

This attribute defines how many times the database will attempt to reconnect to a failed standby database before giving up. When you set the MAX_FAILURE attribute, you also have to set the REOPEN attribute. Once the failure count is greater than or equal to the value you specified, the REOPEN attribute value will set to zero internally. This will cause the database to transport redo data to an alternate destination corresponding to the ALTERNATE attribute.

SQL> alter system set log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST REOPEN=8 MAX_FAILURE=4';
System altered.

SQL> select MAX_FAILURE,FAILURE_COUNT,REOPEN_SECS from v$archive_dest where dest_id=1;
MAX_FAILURE FAILURE_COUNT REOPEN_SECS
----------- ------------- -----------
          4             0           8

The redo transport services will try to reopen the failed remote destination after a specified number of seconds. By default, the database attempts to reopen failed destinations at the set log-switch time. You can use this attribute to shorten the interval of redo transport reconnect attempts.

SQL> alter system set log_archive_dest_2='SERVICE=INDIA reopen=90 db_unique_name=INDIA_UN';
System altered.

SQL> select reopen_secs,max_failure from v$archive_dest where dest_id=2;
REOPEN_SECS MAX_FAILURE
----------- -----------
         90           0

This attribute is used only with the SYNC redo transport mode. Depending on the value of the NET_TIMEOUT attribute, the LGWR process will block and wait for acknowledgment from a redo transport destination. If the acknowledgment is not received within the time specified, an error will be logged and the transport session to that destination is terminated. If not set, its default value is 30 seconds.

Before setting this attribute, consider your network bandwidth. If you specify lower values such as 1 to 5 seconds, the primary database may often disconnect from the standby database due to transient network errors. A minimum value of 10 should be considered.

SQL> alter system set log_archive_dest_2='SERVICE=INDIA SYNC NET_TIMEOUT=20 db_unique_name=india_un';
System altered.

SQL> select net_timeout from v$archive_dest where dest_id=2;
NET_TIMEOUT
-----------
         20

This attribute is used to set a delay between the primary and standby databases. When DELAY is used, redo is sent to the standby database with no delay but Redo Apply waits for the delay time before applying the archived log.

SQL> alter system set log_archive_dest_2='SERVICE=india delay=10 db_unique_name=india_un';
System altered.

SQL>  selectdelay_mins,destination from v$archive_dest where dest_id=2;
DELAY_MINS DESTINAT
---------- --------
        10 india

If real-time apply is used on the standby database, this attribute will be ignored even if you specify it. You can also override this parameter by using the NODELAY option in the managed recovery command.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;

These parameters, where n is from 1 to 31, indicate the state of the related redo log destination configured by the LOG_ARCHIVE_DEST_n parameter. The default value is ENABLE, which means the redo destination is active. If you want to make the destination inactive, you can set the LOG_ARCHIVE_DEST_STATE_n parameter to DEFER. This destination will be excluded until it is reenabled. If any log archive destination has been configured as a failover archive location, the LOG_ARCHIVE_DEST_STATE_n status will be ALTERNATE.

SQL> alter system set log_archive_dest_state_2='defer';
System altered.
SQL> show parameter log_archive_dest_state_2
NAME                          TYPE        VALUE
----------------------------- ----------- -------
log_archive_dest_state_2      string      defer