Tales From A Lazy Fat DBA

Den of an Oracle DB Performance freak & a fan of PostgreSQL & Cassandra …. \,,/

  • Likes

    • 148,962
  • Archives

  • Categories

  • Subscribe

  • Advertisements

Data Guard Configuration Attributes (LOG_ARCHIVE_DEST_n)

Posted by FatDBA on January 29, 2013

Today i will try to explain some of the Data Guard Configuration attributes that we use along with LOG_ARCHIVE_DEST_n parameter or entry:

AFFIRM and NOAFFIRM  |    ALTERNATE    |    COMPRESSION    |     DELAY        |       LOCATION and SERVICE         |          MANDATORY       |        MAX_CONNECTIONS        |         MAX_FAILURE       |        REOPEN       |        SYNC and ASYNC         |         VALID_FOR       |      NOREGISTER

AFFIRM and NOAFFIRM

Controls whether a redo transport destination acknowledges received redo data before or after writing it to the standby redo log:

AFFIRM—specifies that a redo transport destination acknowledges received redo data after writing it to the standby redo log.
NOAFFIRM—specifies that a redo transport destination acknowledges received redo data before writing it to the standby redo log.

  •  If neither the AFFIRM nor the NOAFFIRM attribute is specified, the default is AFFIRM when the SYNC attribute is specified and NOAFFIRM when the ASYNC attribute is specified.

Examples
The following example shows the AFFIRM attribute for a remote destination.

LOG_ARCHIVE_DEST_3=’SERVICE=stby1 SYNC AFFIRM’
LOG_ARCHIVE_DEST_STATE_3=ENABLE

ALTERNATE
Specifies an alternate archiving destination to be used when the original destination fails.

  • The ALTERNATE attribute is optional. If an alternate destination is not specified, then redo transport services do not automatically change to another destination if the original destination fails.
  • You can specify only one alternate destination for each LOG_ARCHIVE_DEST_n parameter, but several enabled destinations can share the same alternate destination.
  • Any destination can be designated as an alternate destination, given the following restrictions:

– At least one local mandatory destination is enabled.
– The number of enabled destinations must meet the defined LOG_ARCHIVE_MIN_SUCCEED_DEST parameter value.

  • A destination cannot be its own alternate.

Examples
In the sample initialization parameter file, LOG_ARCHIVE_DEST_1 automatically fails over to LOG_ARCHIVE_DEST_2 on the next archival operation if an error occurs or the device becomes full.

Example –  Automatically Failing Over to an Alternate Destination

LOG_ARCHIVE_DEST_1=’LOCATION=/disk1 MANDATORY ALTERNATE=LOG_ARCHIVE_DEST_2′
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_2=’LOCATION=/disk2 MANDATORY’
LOG_ARCHIVE_DEST_STATE_2=ALTERNATE

COMPRESSION
The COMPRESSION attribute is used to specify whether redo data is transmitted to a redo transport destination in compressed form or uncompressed form when resolving redo data gaps.
* Redo transport compression is a feature of the Oracle Advanced Compression option. You must purchase a license for this option before using the redo transport compression feature.
The following example shows the COMPRESSION attribute with the LOG_ARCHIVE_DEST_n parameter.
LOG_ARCHIVE_DEST_3=’SERVICE=denver SYNC COMPRESSION=ENABLE’
LOG_ARCHIVE_DEST_STATE_3=ENABLE

DELAY
Specifies a time lag between when redo data is archived on a standby site and when the archived redo log file is applied to the standby database.

Valid values     >=0 minutes
Default Value 30 minutes
Requires attributes      SERVICE

  •  The DELAY attribute indicates the archived redo log files at the standby destination are not available for recovery until the specified time interval has expired. The time interval is expressed in minutes, and it starts when the redo data is successfully transmitted to, and archived at, the standby site.
  • The DELAY attribute may be used to protect a standby database from corrupted or erroneous primary data. However, there is a tradeoff because during failover it takes more time to apply all of the redo up to the point of corruption.
  • If you have real-time apply enabled, any delay that you set will be ignored.
  • You can override the specified delay interval at the standby site, as follows:

For a physical standby database:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;

For a logical standby database:
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY;

The following example shows how to specify the DELAY attribute for this configuration:
LOG_ARCHIVE_DEST_1=’LOCATION=/oracle/dbs/’
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_2=’SERVICE=stbyB SYNC AFFIRM’
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_DEST_3=’SERVICE=stbyC DELAY=120′
LOG_ARCHIVE_DEST_STATE_3=ENABLE

LOCATION and SERVICE
Each destination must specify either the LOCATION or the SERVICE attribute to identify either a local disk directory or a remote database destination where redo transport services can transmit redo data.

  • Either the LOCATION or the SERVICE attribute must be specified. There is no default.
  • You can specify up to nine additional local or remote destinations.
  • For the LOCATION attribute, you can specify one of the following:

LOCATION=local_disk_directory

This specifies a unique directory path name for a disk directory on the system that hosts the database. This is the local destination for archived redo log files.
LOCATION=USE_DB_RECOVERY_FILE_DEST

  • When you specify a SERVICE attribute:

You identify remote destinations by specifying the SERVICE attribute with a valid Oracle Net service name (SERVICE=net_service_name) that identifies the remote Oracle database instance to which the redo data will be sent.

Example 1   Specifying the LOCATION Attribute

LOG_ARCHIVE_DEST_2=’LOCATION=/disk1/oracle/oradata/payroll/arch/’
LOG_ARCHIVE_DEST_STATE_2=ENABLE

Example 2   Specifying the SERVICE Attribute

LOG_ARCHIVE_DEST_3=’SERVICE=stby1′
LOG_ARCHIVE_DEST_STATE_3=ENABLE

MANDATORY
Specifies that filled online log files must be successfully archived to the destination before they can be reused.

  • The LOG_ARCHIVE_MIN_SUCCEED_DEST=n parameter (where n is an integer from 1 to 10) specifies the number of destinations that must archive successfully before online redo log files can be overwritten.
  • You must have at least one local destination, which you can declare MANDATORY or leave as optional.
  • At least one local destination is operationally treated as mandatory, because the minimum value for the LOG_ARCHIVE_MIN_SUCCEED_DEST parameter is 1.

Examples
The following example shows the MANDATORY attribute:

LOG_ARCHIVE_DEST_1=’LOCATION=/arch/dest MANDATORY
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_3=’SERVICE=denver MANDATORY’
LOG_ARCHIVE_DEST_STATE_3=ENABLE

MAX_CONNECTIONS
Enables multiple network connections to be used when sending an archived redo log file to a redo transport destination. Using multiple network connections can improve redo transport performance over high-latency network links.

Valid values     1 to
Default value   1

  • The MAX_CONNECTIONS attribute is optional. If it is specified, it is only used when redo transport services use ARCn processes for archival.
  • If MAX_CONNECTIONS is set to 1 (the default), redo transport services use a single ARCn process to transmit redo data to the remote destination.
  • If MAX_CONNECTIONS is set to a value greater than 1, redo transport services use multiple ARCn processes to transmit redo in parallel to archived redo log files at the remote destination. Each archiver (ARCn) process uses a separate network connection.
  • With multiple ARCn processes, redo transmission occurs in parallel, thus increasing the speed at which redo is transmitted to the remote destination.
  • Any standby database using archiver (ARCn) processes will not use standby redo logs if the MAX_CONNECTIONS attribute is specified. Thus, such destinations:

–  Cannot use real-time apply
– Cannot be configured as a redo forwarding destination

Example:

LOG_ARCHIVE_DEST_3=’SERVICE=denver MAX_CONNECTIONS=3′
LOG_ARCHIVE_DEST_STATE_3=ENABLE

MAX_FAILURE
Controls the consecutive number of times redo transport services attempt to reestablish communication and transmit redo data to a failed destination before the primary database gives up on the destination.

  •  The MAX_FAILURE attribute is optional. By default, there are an unlimited number of archival attempts to the failed destination.
  • This attribute is useful for providing failure resolution for destinations to which you want to retry transmitting redo data after a failure, but not retry indefinitely.
  • When you specify the MAX_FAILURE attribute, you must also set the REOPEN attribute. Once the specified number of consecutive attempts is exceeded, the destination is treated as if the REOPEN attribute was not specified.
  • Once the failure count is greater than or equal to the value set for the MAX_FAILURE attribute, the REOPEN attribute value is implicitly set to zero, which causes redo transport services to transport redo data to an alternate destination (defined with the ALTERNATE attribute) on the next archival operation.

The following example allows redo transport services up to three consecutive archival attempts, tried every 5 seconds, to the arc_dest destination. If the archival operation fails after the third attempt, the destination is treated as if the REOPEN attribute was not specified.

LOG_ARCHIVE_DEST_1=’LOCATION=/arc_dest REOPEN=5 MAX_FAILURE=3′
LOG_ARCHIVE_DEST_STATE_1=ENABLE

REOPEN
Specifies the minimum number of seconds before redo transport services should try to reopen a failed destination.

  • Default Value 300 seconds
  • The REOPEN attribute is optional.
  • Redo transport services attempt to reopen failed destinations at log switch time.
  • Redo transport services check if the time of the last error plus the REOPEN interval is less than the current time. If it is, redo transport services attempt to reopen the destination.
  • REOPEN applies to all errors, not just connection failures. These errors include, but are not limited to, network failures, disk errors, and quota exceptions.

Example:

LOG_ARCHIVE_DEST_3=’SERVICE=stby1 MANDATORY REOPEN=60′
LOG_ARCHIVE_DEST_STATE_3=ENABLE

VALID_FOR
Specifies whether redo data will be written to a destination, based on the following factors:
–   Whether the database is currently running in the primary or the standby role
–   Whether online redo log files, standby redo log files, or both are currently being archived on the database at this destination

  •  Default Value VALID_FOR=(ALL_LOGFILES, ALL_ROLES)
  • The VALID_FOR attribute is optional. However, Oracle recommends that the VALID_FOR attribute be specified for each redo transport destination at each database in a Data Guard configuration so that redo transport continues after a role transition to any standby database in the configuration.
  • To configure these factors for each LOG_ARCHIVE_DEST_n destination, you specify this attribute with a pair of keywords: VALID_FOR=(redo_log_type,database_role):

The redo_log_type keyword identifies the destination as valid for archiving one of the following:

ONLINE_LOGFILE—This destination is valid only when archiving online redo log files.
STANDBY_LOGFILE—This destination is valid only when archiving standby redo log files.
ALL_LOGFILES— This destination is valid when archiving either online redo log files or standby redo log files.
The database_role keyword identifies the role in which this destination is valid for archiving:

PRIMARY_ROLE—This destination is valid only when the database is running in the primary role.
STANDBY_ROLE—This destination is valid only when the database is running in the standby role.
ALL_ROLES—This destination is valid when the database is running in either the primary or the standby role.

LOG_ARCHIVE_DEST_1=’LOCATION=/disk1/oracle/oradata VALID_FOR=(ALL_LOGFILES, ALL_ROLES)’

NOREGISTER
Indicates that the location of the archived redo log file should not be recorded at the corresponding destination.

  • The NOREGISTER attribute is optional if the standby database destination is a part of a Data Guard configuration.
  • The NOREGISTER attribute is required if the destination is not part of a Data Guard configuration.

LOG_ARCHIVE_DEST_5=’NOREGISTER’

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

 
%d bloggers like this: