合 DG参数 LOG_ARCHIVE_DEST_n

This chapter provides reference information for the attributes of the LOG_ARCHIVEDESTn initialization parameter. The following list shows the attributes:

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

Each LOG_ARCHIVEDESTn destination must contain either a LOCATION or SERVICE attribute to specify a local disk directory or a remotely accessed database, respectively. All other attributes are optional.

Note:

Several attributes of the LOG_ARCHIVEDESTn initialization parameter have been deprecated. These attributes are supported for backward compatibility only and are documented in theOracle Database Reference.

See Also:

Chapter 6 for more information about defining LOG_ARCHIVEDESTn destinations and setting up redo transport services

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.

Usage Notes

• 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.
• Specification of the AFFIRM attribute without the SYNC attribute is deprecated and will not be supported in future releases.

See also:

SYNC and ASYNC attributes

Examples

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

ALTERNATE

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

Footnote 1 If the REOPEN attribute is specified with a nonzero value, the ALTERNATE attribute is ignored. If the MAX_FAILURE attribute is also specified with a nonzero value, and the failure count exceeds the specified failure threshold, the ALTERNATE destination is enabled. Therefore, the ALTERNATE attribute does not conflict with a nonzero REOPEN attribute value.

Usage Notes

• 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_ARCHIVEDESTn parameter, but several enabled destinations can share the same alternate destination.
• Ideally, an alternate destination should specify either:
  • A different disk location on the same local standby database system (shown in Example 15-1)
  • A different network route to the same standby database system (shown in Example 15-2)
  • A remote standby database system that closely mirrors that of the enabled destination
• If no enabled destinations reference an alternate destination, the alternate destination is implied to be deferred, because there is no automatic method of enabling the alternate destination. However, you can enable (or defer) alternate destinations at runtime using either ALTER SYSTEM.
• 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.
• Increasing the number of enabled destinations decreases the number of available alternate archiving destinations.
• When a destination fails, its alternate destination is enabled on the next archival operation. There is no support for enabling the alternate destination in the middle of the archival operation because that would require rereading already processed blocks. This is identical to the REOPEN attribute behavior.
• If the REOPEN attribute is specified with a nonzero value, the ALTERNATE attribute is ignored unless the MAX_FAILURE attribute has a nonzero value. If the MAX_FAILURE and REOPEN attributes have nonzero values and the failure count exceeds the specified failure threshold, the ALTERNATE destination is enabled. Therefore, the ALTERNATE attribute does not conflict with a nonzero REOPENattribute value.

Examples

In the sample initialization parameter file in Example 15-1, 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 15-1 Automatically Failing Over to an Alternate Destination

Notice in the example that a destination can also be in the ALTERNATE state, as specified with the LOG_ARCHIVE_DESTSTATEn initialization parameter. The ALTERNATE state defers redo transport services from transmitting redo data to this destination until such time as another destination failure automatically enables this destination.

Example 15-2 Defining an Alternate Oracle Net Service Name to the Same Standby Database

This example shows how to define an alternate Oracle Net service name to the same standby database.

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.

Note:

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.

Usage Notes

• The COMPRESSION attribute is optional. If it is not specified, the default compression behavior is DISABLE.

Example

The following example shows the COMPRESSION attribute with the LOG_ARCHIVEDESTn parameter.

DB_UNIQUE_NAME

Specifies a unique name for the database at this destination.

Usage Notes

• This attribute is optional if:
  • The LOG_ARCHIVE_CONFIG=DG_CONFIG initialization parameter is not specified.
  • This is a local destination (specified with the LOCATION attribute).
• This attributes is required if the LOG_ARCHIVE_CONFIG=DG_CONFIG initialization parameter is specified and if this is a remote destination (specified with the SERVICE attribute).
• Use the DB_UNIQUE_NAME attribute to clearly identify the relationship between a primary and standby databases. This attribute is particularly helpful if there are multiple standby databases in the Data Guard configuration.
• The name specified by the DB_UNIQUE_NAME must match one of the DB_UNIQUE_NAME values in the DG_CONFIG list. Redo transport services validate that the DB_UNIQUE_NAME attribute of the database at the specified destination matches the DB_UNIQUE_NAME attribute or the connection to that destination is refused.
• The name specified by the DB_UNIQUE_NAME attribute must match the name specified by the DB_UNIQUE_NAME initialization parameter of the database identified by the destination.

Example

In the following example, the DB_UNIQUE_NAME parameter specifies boston (DB_UNIQUE_NAME=boston), which is also specified with the DB_UNIQUE_NAME attribute on the LOG_ARCHIVE_DEST_1parameter. The DB_UNIQUE_NAME attribute on the LOG_ARCHIVE_DEST_2 parameter specifies the chicago destination. Both boston and chicago are listed in the LOG_ARCHIVE_CONFIG=DG_CONFIGparameter.

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.

Usage Notes

• The DELAY attribute is optional. By default there is no delay.

• 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.

• The DELAY attribute does not affect the transmittal of redo data to a standby destination.

• If you have real-time apply enabled, any delay that you set will be ignored.

• Changes to the DELAY attribute take effect the next time redo data is archived (after a log switch). In-progress archiving is not affected.

• 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;

  1	SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;

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

  1	SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY;

See Also:

Oracle Database SQL Language Reference for more information about these ALTER DATABASE statements

Examples

You can use the DELAY attribute to set up a configuration where multiple standby databases are maintained in varying degrees of synchronization with the primary database. However, this protection incurs some overhead during failover, because it takes Redo Apply more time to apply all the redo up to the corruption point.

For example, assume primary database A has standby databases B and C. Standby database B is set up as the disaster recovery database and therefore has no time lag. Standby database C is set up with a 2-hour delay, which is enough time to allow user errors to be discovered before they are propagated to the standby database.

The following example shows how to specify the DELAY attribute for this configuration:

Note:

Alternatively, you can use Flashback Database to revert the database to a point-in-time or SCN in a different database incarnation as long as there is sufficient flashback log data. Using Flashback Database is described in Oracle Database Backup and Recovery User's Guide.

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.

Usage Notes

• Either the LOCATION or the SERVICE attribute must be specified. There is no default.

• If you are specifying multiple attributes, specify the LOCATION or SERVICE attribute first in the list of attributes.

• You must specify at least one local disk directory with the LOCATION attribute. This ensures that local archived redo log files are accessible should media recovery of a database be necessary. 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

  To configure a flash recovery area, specify the directory or Oracle Storage Manager disk group that will serve as the flash recovery area using the DB_RECOVERY_FILE_DEST initialization parameter. For more information about flash recovery areas, see Oracle Database Backup and Recovery User's Guide.

• 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.

  The Oracle Net service name that you specify with the SERVICE attribute is translated into a connection descriptor that contains the information necessary for connecting to the remote database.

  See Also:

  本人提供Oracle(OCP、OCM)、MySQL(OCP)、PostgreSQL(PGCA、PGCE、PGCM)等数据库的培训和考证业务，私聊QQ646634621或微信dbaup66，谢谢！
  后续精彩内容已被站长无情隐藏，请输入验证码解锁本文！

  验证码：

  获取验证码： 请先关注本站微信公众号，然后回复“验证码”，获取验证码。在微信里搜索“AiDBA”或者“dbaup6”或者微信扫描右侧二维码都可以关注本站微信公众号。

  相关文章

  • 在物理 standby 数据库上如何解决 MRP 进程卡住的问题？ (Doc ID 2331842.1)(Doc ID 1221163.1)
  • DGMGRL ADD DATABASE Failing with ORA-16191 (Doc ID 3013838.1)
  • ORA-16191 and ORA-1017 reported for Log Transport to Standby when using redo_transport_user (Doc ID 2848435.1)
  • Oracle 12c的DG自动同步密码文件--ASM 新特性：共享密码文件
  • Oracle DG中日志不同步的ORA-16191错误解决整理
  • Oracle的DG环境中由于配置了登陆触发器导致日志不能同步报错ORA-16191的实验
  • 在Oracle的DG环境中，主库新增数据文件的过程
  • Oracle DG环境中的gap处理办法总结
  • 备库数据文件异常，物理DG如何恢复？
  • 在DG环境中，主库丢失归档，对主库进行基于SCN的增量备份来恢复物理DG环境
  • Oracle中的DG日常维护SQL脚本整理（持续更新）
  • 物理DG中主库的LNSn、NSS、NSA进程的比较
  • DG环境主库丢失归档情况下数据文件的恢复
  • 物理DG在主库丢失归档文件的情况下的恢复
  • 物理DG的switchover和failover切换过程
  • 单实例物理DG配置客户端无缝切换的详细过程
  • Oracle利用闪回数据库（flashback）功能修复Failover后的DG环境
  • 一步一步在RHEL6.5+VMware Workstation 10上搭建 oracle 11gR2 rac + dg
  • Oracle 主库rac + 备库rac 11.2.0.4的DG环境部署
  • Oracle DG环境的日常巡检
  打赏赞(1)分享