合 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.
| Category | AFFIRM | NOAFFIRM |
|---|---|---|
| Data type | Keyword | Keyword |
| Valid values | Not applicable | Not applicable |
| Default Value | Not applicable | Not applicable |
| Requires attributes | SERVICE | SERVICE |
| Conflicts with attributes | NOAFFIRM | AFFIRM |
| Corresponds to | AFFIRM column of the V$ARCHIVE_DEST view | AFFIRM column of the V$ARCHIVE_DEST view |
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.
1 2 | 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.
| Category | ALTERNATE=LOG_ARCHIVEDESTn |
|---|---|
| Data Type | String |
| Valid Value | A LOG_ARCHIVEDESTn destination |
| Default Value | None. If an alternate destination is not specified, then redo transport services do not automatically change to another destination. |
| Requires attributes | Not applicable |
| Conflicts with attributes | None Foot 1 |
| Corresponds to | ALTERNATE and STATUS columns of the V$ARCHIVE_DEST view |
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
1 2 3 4 | 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 |
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.
1 2 3 4 5 6 | LOG_ARCHIVE_DEST_1='LOCATION=/disk1 MANDATORY' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_2='SERVICE=stby1_path1 ALTERNATE=LOG_ARCHIVE_DEST_3' LOG_ARCHIVE_DEST_STATE_2=ENABLE LOG_ARCHIVE_DEST_3='SERVICE=stby1_path2' LOG_ARCHIVE_DEST_STATE_3=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.
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.
| Category | COMPRESSION=ENABLE or DISABLE |
|---|---|
| Data Type | Boolean |
| Valid values | ENABLE or DISABLE |
| Default value | DISABLE |
| Requires attributes | None |
| Conflicts with attributes | None |
| Corresponds to | COMPRESSION column of the V$ARCHIVE_DEST view |
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.
1 2 | LOG_ARCHIVE_DEST_3='SERVICE=denver SYNC COMPRESSION=ENABLE' LOG_ARCHIVE_DEST_STATE_3=ENABLE |
DB_UNIQUE_NAME
Specifies a unique name for the database at this destination.
| Category | DB_UNIQUE_NAME=name |
|---|---|
| Data Type | String |
| Valid values | The name must match the value that was defined for this database with theDB_UNIQUE_NAME parameter. |
| Default value | None |
| Requires attributes | None |
| Conflicts with attributes | None |
| Corresponds to | DB_UNIQUE_NAME column of the V$ARCHIVE_DEST view |
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.
1 2 3 4 5 6 7 8 | DB_UNIQUE_NAME=boston LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston,denver)' LOG_ARCHIVE_DEST_1='LOCATION=/arch1/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston' LOG_ARCHIVE_DEST_2='SERVICE=Sales_DR VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicago' |
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.
| Category | DELAY[=minutes] |
|---|---|
| Data Type | Numeric |
| Valid values | >=0 minutes |
| Default Value | 30 minutes |
| Requires attributes | SERVICE |
| Conflicts with attributes | LOCATION |
| Corresponds to | DELAY_MINS and DESTINATION columns of the V$ARCHIVE_DEST view |
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:
1SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;- For a logical standby database:
1SQL> 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:
1 2 3 4 5 6 | 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 |
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.
| Category | LOCATION=local_disk_directory orUSE_DB_RECOVERY_FILE_DEST | SERVICE=net_service_name |
|---|---|---|
| Data type | String value | String value |
| Valid values | Not applicable | Not applicable |
| Default Value | None | None |
| Requires attributes | Not applicable | Not applicable |
| Conflicts with attributes | SERVICE, DELAY, NOREGISTER, SYNC, ASYNC, NET_TIMEOUT, AFFIRM,NOAFFIRM, COMPRESSION, MAX_CONNECTIONS | LOCATION |
| Corresponds to | DESTINATION and TARGET columns of theV$ARCHIVE_DEST view | DESTINATION and TARGET columns of theV$ARCHIVE_DEST view |
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，谢谢！
