Skip Headers

Oracle Data Guard Concepts and Administration
Release 2 (9.2)

Part Number A96653-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Feedback

Go to previous page Go to next page
View PDF

12
LOG_ARCHIVE_DEST_n Parameter Attributes

This chapter provides syntax, values, and information on validity for the archival attributes of the LOG_ARCHIVE_DEST_n initialization parameter. These attributes include:

AFFIRM and NOAFFIRM
ALTERNATE and NOALTERNATE
ARCH and LGWR
DELAY and NODELAY
DEPENDENCY and NODEPENDENCY
LOCATION and SERVICE
MANDATORY and OPTIONAL
MAX_FAILURE and NOMAX_FAILURE
NET_TIMEOUT and NONET_TIMEOUT
QUOTA_SIZE and NOQUOTA_SIZE
QUOTA_USED and NOQUOTA_USED
REGISTER and NOREGISTER
REGISTER=location_format
REOPEN and NOREOPEN
SYNC and ASYNC
TEMPLATE and NOTEMPLATE

In addition, this chapter includes the following topics:

12.1 About LOG_ARCHIVE_DEST_n Parameter Attributes

You should specify at least two LOG_ARCHIVE_DEST_n (where n is an integer from 1 to 10) parameters: one for the required local destination and another for a local or remote destination.

The following sections describe the attributes of the LOG_ARCHIVE_DEST_n initialization parameter. See Chapter 5 for additional information.

All LOG_ARCHIVE_DEST_n parameters must contain, at a minimum, either a LOCATION or SERVICE attribute. In addition, you must have a LOG_ARCHIVE_DEST_STATE_n parameter for each defined destination.

The LOG_ARCHIVE_DEST_STATE_n (where n is an integer from 1 to 10) initialization parameter specifies the state of the corresponding destination indicated by the LOG_ARCHIVE_DEST_n initialization parameter. For example, the LOG_ARCHIVE_DEST_STATE_3 parameter specifies the state of the LOG_ARCHIVE_DEST_3 destination.

12.2 Changing Destination Attributes Using SQL Statements

Table 12-1 lists the attributes that can be set for the LOG_ARCHIVE_DEST_n initialization parameter and indicates if the attribute can be changed using an ALTER SYSTEM or ALTER SESSION statement.

Table 12-1 Changing Destination Attributes Using SQL
Attribute ALTER SYSTEM ALTER SESSION

[NO]AFFIRM

Yes

Yes

[NO]ALTERNATE=destination

Yes

Yes

ARCH

Yes

Yes

ASYNC[=blocks]

Yes

No

[NO]DELAY

Yes

Yes

[NO]DEPENDENCY=destination

Yes

No

LGWR

Yes

No

LOCATION=local_disk_directory

Yes

Yes

MANDATORY

Yes

Yes

[NO]MAX_FAILURE=count

Yes

No

OPTIONAL

Yes

Yes

[NO]NET_TIMEOUT[=seconds]

Yes

No

[NO]QUOTA_SIZE=blocks

Yes

No

[NO]QUOTA_USED=blocks

Yes

No

[NO]REGISTER

Yes

Yes

REGISTER=location_format

Yes

Yes

[NO]REOPEN[=seconds]

Yes

Yes

SERVICE=net_service_name

Yes

Yes

SYNC[=PARALLEL|NOPARALLEL]

Yes

Yes

[NO]TEMPLATE=filename_template

Yes

Yes

12.3 Incrementally Changing LOG_ARCHIVE_DEST_n Parameter Settings

The log transport services LOG_ARCHIVE_DEST_n destination initialization parameters are unique in that they contain multiple values known as attributes. Except for the LOCATION and SERVICE attributes, all attributes are optional and have a default value.


Note:

When using a traditional text initialization parameter file, the LOG_ARCHIVE_DEST_n parameters can also be specified incrementally at runtime so that you can replace one or more specific attributes without having to re-specify the entire parameter value. See Section 5.8.1 for examples that show incremental changes to a traditional text initialization parameter file.


To specify network service names that use embedded characters, such as equal signs (=) and spaces, enclose the service name in quotation marks (").

Example 12-1 shows how to replace the initial specification of the LOG_ARCHIVE_DEST_1 parameter.

Example 12-1 Replacing a Destination Specification

LOG_ARCHIVE_DEST_1='LOCATION=/disk1/oracle/oradata/payroll'
LOG_ARCHIVE_DEST_2='SERVICE=stdby REOPEN=60'
LOG_ARCHIVE_DEST_1='LOCATION=/disk3/oracle/oradata/payroll MANDATORY'

When using a traditional text initialization parameter file, the LOG_ARCHIVE_DEST_n initialization parameters can be changed incrementally at run-time using the ALTER SYSTEM SET statement. This means that you are able to change one or more specific attributes without having to re-specify the entire parameter value. Specifying any attribute except the LOCATION or SERVICE attributes is valid for an incremental change.


Note:

You cannot make incremental changes to parameters in a server parameter file (SPFILE). You must convert the SPFILE to a traditional text initialization parameter file (PFILE) and edit the initialization parameters, then convert the PFILE back to a SPFILE.


Example 12-2 shows how to set multiple attributes incrementally on separate lines. Specify the SERVICE or LOCATION attribute on the first line.

Example 12-2 Specifying Multiple Attributes Incrementally

ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/disk1/oracle/oradata/payroll';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='OPTIONAL';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='REOPEN=5';

Example 12-3 shows how to specify attributes for multiple destinations. Incremental parameters such as the LOG_ARCHIVE_DEST_n initialization parameter do not have to immediately follow each other.

Example 12-3 Specifying Multiple Attributes for Multiple Destinations

ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/disk1/oracle/oradata/payroll';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=stdby REOPEN=60';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1= OPTIONAL';

Specifying the LOCATION or SERVICE attribute causes the destination initialization parameter to be reset to its default values. Example 12-4 shows an entry for LOG_ARCHIVE_DEST_1 that is not considered an incremental change:

Example 12-4 Replaced Destination Specification

ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/disk1/oracle/oradata/payroll 
REOPEN=60';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/disk1/oracle/oradata/payroll';

A string containing a null value for parameter attributes clears a previously entered destination specification. Example 12-5 shows how to clear the definition of LOG_ARCHIVE_DEST_1.

Example 12-5 Clearing a Destination Specification

LOG_ARCHIVE_DEST_1='LOCATION=/disk1/oracle/oradata/payroll'
LOG_ARCHIVE_DEST_2='SERVICE=stdby REOPEN=60'
LOG_ARCHIVE_DEST_1=''

12.3.1 Viewing Current Settings of Destination Initialization Parameters

You can use SQL to query fixed views such as V$ARCHIVE_DEST to see current LOG_ARCHIVE_DEST_n initialization parameter settings. For example, to view current destination settings on the primary database, enter the following statement:

SQL> SELECT DESTINATION FROM V$ARCHIVE_DEST;

Note:

Do not use the V$PARAMETER view to determine the value of the LOG_ARCHIVE_DEST_n initialization parameters. The V$PARAMETER view shows only the last specified value for each parameter, which in the case of an incremental modification is not representative of the actual LOG_ARCHIVE_DEST_n parameter value.



AFFIRM and NOAFFIRM

Category AFFIRM NOAFFIRM

Datatype of the attribute

Keyword

Keyword

Minimum value

Not applicable

Not applicable

Maximum value

Not applicable

Not applicable

Default value

Not applicable

Not applicable

Requires attributes ...

Not applicable

Not applicable

Conflicts with attributes ...

NOAFFIRM

AFFIRM

Attribute class

ALTER SESSION and ALTER SYSTEM

ALTER SESSION and ALTER SYSTEM

Corresponding V$ARCHIVE_DEST column

AFFIRM

AFFIRM

Related V$ARCHIVE_DEST column

ASYNC_BLOCKS

ASYNC_BLOCKS

Purpose

Use the AFFIRM and the NOAFFIRM attributes to ensure that archived redo log contents were successfully written to disk. This applies to both local and remote destinations.

Defaults

If the AFFIRM or the NOAFFIRM attribute is not specified with the
LOG_ARCHIVE_DEST_n parameter, the default is NOAFFIRM.

Attributes

AFFIRM

The AFFIRM attribute indicates that all archived redo log I/O operations are to be performed synchronously, even on a remote standby database. This attribute has the potential to affect primary database performance. When you use the LGWR and AFFIRM attributes to indicate that the log writer process synchronously writes the locally archived redo log contents to disk, control is not returned to the users and does not continue until the disk I/O operation has completed. When you use the ARCH and AFFIRM attributes to indicate that the ARCn process will synchronously write the archived redo logs to disk, the archival operation might take longer, and online redo logs might not be reusable until archiving is complete.

Using the AFFIRM attribute does not affect performance when you use the ASYNC attribute.

Query the AFFIRM column of the V$ARCHIVE_DEST fixed view to see whether or not the AFFIRM attribute is being used for the associated destination.

The following table identifies the various combinations of these attributes and their potential for affecting primary database performance and data availability. For example, the AFFIRM attribute used in conjunction with the SYNC and ASYNC attributes provides the highest degree of data protection but results in negative performance on the primary database.

Network I/O Attribute Archived Redo Log Disk I/O Attribute Potential Primary Database Performance Standby Database Data Protection

SYNC

AFFIRM

Lowest

Highest

SYNC

NOAFFIRM

Low

High

ASYNC

AFFIRM

High

Low

ASYNC

NOAFFIRM

Highest

Lowest

The highest degree of data availability also has the potential for the lowest primary database performance.


Note:

When the primary database is in the MAXIMIZE PROTECTION or MAXIMIZE AVAILABILITY mode, redo log archiving destinations using the log writer process are also automatically placed in AFFIRM mode.


See Also:

SYNC and ASYNC

NOAFFIRM

The NOAFFIRM attribute indicates that all archived redo log disk I/O operations are to be performed asynchronously; the log writer process does not wait until the disk I/O has completed before continuing.

Examples

The following example shows the AFFIRM attribute with the
LOG_ARCHIVE_DEST_n parameter.

LOG_ARCHIVE_DEST_3='SERVICE=stby1 LGWR SYNC AFFIRM'
LOG_ARCHIVE_DEST_STATE_3=ENABLE


ALTERNATE and NOALTERNATE

Category ALTERNATE=destination NOALTERNATE

Datatype of the attribute

String value

Keyword

Minimum value

Not applicable

Not applicable

Maximum value

Not applicable

Not applicable

Default value

NoneFoot 1

Not applicable

Requires attributes ...

Not applicable

Not applicable

Conflicts with attributes ...

NOALTERNATE

ALTERNATE

Attribute class

ALTER SYSTEM

ALTER SESSION and ALTER SYSTEM

Corresponding V$ARCHIVE_DEST column

ALTERNATE

ALTERNATE

Related V$ARCHIVE_DEST column

STATUS

STATUS

1 If the NOALTERNATE attribute is specified, or if no alternate destination is specified, the destination does not automatically change to another destination upon failure.

Purpose

The ALTERNATE and the NOALTERNATE attributes of the LOG_ARCHIVE_DEST_n parameter define an alternate archiving destination or prevent archiving to an alternate destination when the original archiving destination fails.

Defaults

If the ALTERNATE or the NOALTERNATE attribute is not specified with the LOG_ARCHIVE_DEST_n parameter, the default is NOALTERNATE.

Attributes

ALTERNATE=destination

Use the ALTERNATE attribute of the LOG_ARCHIVE_DEST_n parameter to define an alternate archiving destination to be used if archiving to the original archiving destination fails.

An archiving destination can have a maximum of one alternate destination specified. An alternate destination is used when the transmission of an online redo log from the primary site to the standby site fails. If archiving fails and the REOPEN attribute is specified with a value of zero (0), or NOREOPEN is specified, the Oracle database server attempts to archive online redo logs to the alternate destination on the next archival operation.

An alternate destination can reference a local or remote archiving destination. An alternate destination cannot be self-referencing.

A destination can also be in the ALTERNATE state; this state is specified using the LOG_ARCHIVE_DEST_STATE_n initialization parameter. The ALTERNATE state defers processing of the destination until such time as another destination failure automatically enables this destination, if the alternate destination attributes are valid. See Section 5.4 for more details about the LOG_ARCHIVE_DEST_STATE_n parameter.

The ALTERNATE attribute cannot be modified at the session level.

In the following example, if the LOG_ARCHIVE_DEST_1 destination fails, the archiving process automatically switches to the LOG_ARCHIVE_DEST_2 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

Figure 12-1 shows a scenario where online redo logs are archived to a local disk device. If the original destination device becomes full or unavailable, the archival operation is automatically redirected to the alternate destination device.

Figure 12-1 Archiving Operation to an Alternate Destination Device

Text description of archloc1.gif follows.

Text description of the illustration archloc1.gif

The REOPEN attribute takes precedence over the ALTERNATE attribute. The alternate destination is used only if one of the following is true:

The ALTERNATE attribute takes precedence over the MANDATORY attribute. This means that a destination fails over to a valid alternate destination even if the current destination is mandatory.

The following is the archived redo log destination attribute precedence table:

PrecedenceFoot 1 Attribute

1

MAX_FAILURE

2

REOPEN

3

ALTERNATE

4

MANDATORY

1 1 indicates highest; 4 indicates lowest.

The use of a standby database as the target of an alternate destination should be carefully handled. Ideally, a standby alternate destination should only be used to specify a different network route to the same standby database system.

If no enabled destination references the alternate destination, the alternate destination is implied to be deferred, because there is no automatic method of enabling the alternate destination.

An alternate destination can be manually enabled at runtime. Conversely, an alternate destination can be manually deferred at runtime. See Section 5.8.1.2 for more information about changing initialization parameter settings using SQL at runtime.

There is no general pool of alternate archived redo log destinations. Ideally, for any enabled destination, the database administrator should choose an alternate destination that closely mirrors that of the referencing destination, although that is not required.

Each enabled destination can have its own alternate destination. Conversely, several enabled destinations can share the same alternate destination. This is known as an overlapping set of destinations. Enabling the alternate destination determines the set to which the destination belongs.

Increasing the number of enabled destinations decreases the number of available alternate redo log archiving destinations.


Note:

An alternate destination is enabled for 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, and so forth. This is identical to the REOPEN attribute behavior.


Any destination can be designated as an alternate given the following restrictions:

Destinations defined using the SQL ALTER SESSION statement do not activate an alternate destination defined at the system level. Conversely, system-defined destinations do not activate an alternate destination defined at the session level.

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.

NOALTERNATE

Use the NOALTERNATE attribute of the LOG_ARCHIVE_DEST_n parameter to prevent the original destination from automatically changing to an alternate destination when the original destination fails.

Examples

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

LOG_ARCHIVE_DEST_1=
'LOCATION=/disk1 MANDATORY NOREOPEN ALTERNATE=LOG_ARCHIVE_DEST_2'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_2='LOCATION=/disk2 MANDATORY'
LOG_ARCHIVE_DEST_STATE_2=ALTERNATE

The sample initialization parameter file in Example 12-7 shows how to define an alternate Oracle Net service name to the same standby database.

Example 12-7 Defining an Alternate Oracle Net Service Name to the Same Standby Database

LOG_ARCHIVE_DEST_1='LOCATION=/disk1 MANDATORY'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_2='SERVICE=stby1_path1 NOREOPEN OPTIONAL ALTERNATE=LOG_ARCHIVE_DEST_3'
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_DEST_3='SERVICE=stby1_path2 NOREOPEN OPTIONAL'
LOG_ARCHIVE_DEST_STATE_3=ALTERNATE


ARCH and LGWR

Category ARCH LGWR

Datatype of the attribute

Keyword

Keyword

Minimum value

Not applicable

Not applicable

Maximum value

Not applicable

Not applicable

Default value

Not applicable

Not applicable

Requires attributes ...

Not applicable

Not applicable

Conflicts with attributes ...

LGWR, ASYNC,
NET_TIMEOUT

ARCH

Attribute class

ALTER SESSION and ALTER SYSTEM

ALTER SYSTEM only

Corresponding V$ARCHIVE_DEST column

ARCHIVER

ARCHIVER

Related V$ARCHIVE_DEST columns

PROCESS, SCHEDULE

PROCESS, SCHEDULE

Purpose

The optional ARCH and LGWR attributes are used to specify that either the archiver or log writer process is responsible for transmitting online redo logs to local and remote archival destinations.

When you change the archiving process from the ARCn process to the LGWR process using the ARCH and LGWR attributes for an archive destination, the LGWR process does not start archiving until the next log switch operation. Conversely, when you change the archiving process from the LGWR process to the ARCn process, the LGWR process continues to archive until the next log switch operation.

Defaults

If the ARCH or the LGWR attribute is not specified with the LOG_ARCHIVE_DEST_n parameter, the default is ARCH.

Attributes

ARCH

The ARCH attribute indicates that redo logs are transmitted to the destination during an archival operation. The background archiver processes (ARCn) or a foreground archival operation serves as the redo log transport service.

LGWR

The LGWR attribute indicates that redo logs are transmitted to the destination concurrently as the online redo log is populated. The background log writer process (LGWR) serves as the redo log transport service. When transmitting redo logs to remote destinations, the LGWR process establishes a network connection to the destination instance. Because the redo logs are transmitted concurrently, they are not retransmitted to the corresponding destination during the archival operation. If a LGWR destination fails, the destination automatically reverts to using the archiver (ARCn) process until the error is corrected.

Examples

The following example shows the LGWR attribute with the LOG_ARCHIVE_DEST_n parameter.

LOG_ARCHIVE_DEST_3='SERVICE=stby1 LGWR'
LOG_ARCHIVE_DEST_STATE_3=ENABLE


DELAY and NODELAY

Category DELAY[=minutes] NODELAY

Datatype of the attribute

Numeric

Keyword

Minimum value

0 minutes

Not applicable

Maximum value

Unlimited

Not applicable

Default value

30 minutes

Not applicable

Requires attributes ...

SERVICE

Not applicable

Conflicts with attributes ...

LOCATION, NODELAY

DELAY

Attribute class

ALTER SESSION and ALTER SYSTEM

ALTER SESSION and ALTER SYSTEM

Corresponding V$ARCHIVE_DEST column

DELAY_MINS

DELAY_MINS

Related V$ARCHIVE_DEST column

DESTINATION

DESTINATION

Purpose

When the standby database is in managed recovery mode, redo logs are automatically applied when they arrive from the primary database. However, to protect against the transfer of corrupted or erroneous data from the primary site to the standby site, you might want to create a time lag between archiving a redo log at the primary site and applying that archived redo log at the standby site.

Defaults

In managed recovery mode, if the DELAY or the NODELAY attribute is not specified with the LOG_ARCHIVE_DEST_n parameter, the default is NODELAY.

If the DELAY attribute is specified without a time interval, the default time interval is 30 minutes.

Attributes

DELAY[=minutes]

Use the DELAY attribute of the LOG_ARCHIVE_DEST_n initialization parameter to specify a time lag for the application of redo logs at the standby site. The DELAY attribute does not affect the transmittal of redo logs to the standby site.


Note:

Changes to the DELAY attribute take effect on the next archival operation. In-progress archival operations are not affected.


The DELAY attribute indicates that the archived redo logs at the standby site 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 log is successfully transmitted and archived at the standby site.

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. For example, assume primary database A supports standby databases B, C, and D. Standby database B is set up as the disaster recovery database and therefore has no time lag. Standby database C is set up to protect against logical or physical corruption, and is maintained with a 2-hour delay. Standby database D is maintained with a 4-hour delay and protects against further corruption.

You can override the specified delay interval at the standby site. To immediately apply an archived redo log to the standby database before the time interval expires, use the NODELAY keyword of the RECOVER MANAGED STANDBY DATABASE clause; for example:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;
NODELAY

When you specify the NODELAY attribute and the standby database is in managed recovery mode, redo logs are automatically applied when they arrive from the primary database.

See Also:

Chapter 13, "SQL Statements"

Examples

The following example shows the DELAY attribute with the LOG_ARCHIVE_DEST_n parameter.

LOG_ARCHIVE_DEST_3='SERVICE=stby1 DELAY=240'
LOG_ARCHIVE_DEST_STATE_3=ENABLE

DEPENDENCY and NODEPENDENCY

Category DEPENDENCY=destination NODEPENDENCY

Datatype of the attribute

String value

Keyword

Minimum value

Not applicable

Not applicable

Maximum value

Not applicable

Not applicable

Default value

Not applicable

Not applicable

Requires attributes ...

SERVICE, REGISTER

Not applicable

Conflicts with attributes ...

NODEPENDENCY, LOCATION, NOREGISTER, QUOTA_SIZE, QUOTA_USED

DEPENDENCY

Attribute class

ALTER SYSTEM only

ALTER SYSTEM only

Corresponding V$ARCHIVE_DEST column

DEPENDENCY

DEPENDENCY

Related V$ARCHIVE_DEST columns

Not applicable

Not applicable

Purpose

Archiving redo logs to a remote database can be defined as being dependent upon the success or failure of an archival operation to another destination. The dependent destination is known as the child destination. The destination on which the child depends is known as the parent destination. Specify the DEPENDENCY attribute with the LOG_ARCHIVE_DEST_n parameter to define a local destination, physical standby database, or logical standby database.

Defaults

If the DEPENDENCY or the NODEPENDENCY attribute is not specified with the
LOG_ARCHIVE_DEST_n parameter, the default is NODEPENDENCY.

Attributes

DEPENDENCY=destination

Specifying a destination dependency can be useful in the following configurations:

In these situations, although a physical archival operation does not occur for the dependent destination, the standby database needs to know the location of the archived redo logs. This allows the standby database to access the archived redo logs when they become available for managed recovery. The DBA must specify a destination as being dependent on the success or failure of a parent destination.

Consider the case of a two-node cluster where a primary node shares access to the destination with the standby node through a mirrored disk device. This configuration, where you maintain a local standby database, is useful for off-loading ad hoc queries and reporting functions.

The primary database archives a redo log locally and, upon successful completion, the archived redo log is immediately available to the standby database for managed recovery. This does not require a physical remote archival operation for the standby destination. In this case, two destinations are used: one for local archiving and another for archiving at the standby site. The standby destination is not valid unless the primary destination succeeds. Therefore, the standby destination has a dependency upon the success or failure of the local destination.

The DEPENDENCY attribute has the following restrictions:

When one or more destinations are dependent upon the same parent destination, all attributes of the dependent destinations still apply to that destination. It appears as if the archival operation was performed for each destination, when only one archival operation actually occurred.

Consider, for example, that two standby databases are dependent upon the archived redo log of a parent destination. You can specify different DELAY attributes for each destination, which allows you to maintain a staggered time lag between the primary database and each standby database.

Similarly, a dependent destination can specify an alternate destination, which itself might or might not be dependent on the same parent destination.


Note:

Dependent destinations do not participate in a standby no-data-loss environment.


NODEPENDENCY

Specifies that there is no dependency on the success or failure of an archival operation to another destination.

Examples

One reason to use the DEPENDENCY attribute is if the standby database is on the same site as the primary database. Using this configuration, you only need to archive the redo logs once and, because the standby database resides on the local system, it can access the same redo logs. The following is an example of the LOG_ARCHIVE_DEST_n parameters in this scenario:

# Set up the mandatory local destination:
#
LOG_ARCHIVE_DEST_1='LOCATION=/oracle/dbs/ MANDATORY'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
#
# Set up the dependent standby database that resides on the local system:
#
LOG_ARCHIVE_DEST_2='SERVICE=dest2 DEPENDENCY=LOG_ARCHIVE_DEST_1 OPTIONAL'
LOG_ARCHIVE_DEST_STATE_2=ENABLE

Another reason to use the DEPENDENCY attribute is if two standby databases reside on the same system. The parent and child standby databases can be any mix of physical and logical standby databases. The following is an example of this scenario:

# Set up the mandatory local destination:
#
LOG_ARCHIVE_DEST_1='LOCATION=/oracle/dbs/ MANDATORY'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
#
# Set up the remote standby database that will receive the logs:
#
LOG_ARCHIVE_DEST_2='SERVICE=dest2 OPTIONAL'
LOG_ARCHIVE_DEST_STATE_2=ENABLE
#
# Set up the remote standby database that resides on the same system as, and is
# dependent on, the first standby database:
#
LOG_ARCHIVE_DEST_3='SERVICE=dest3 DEPENDENCY=LOG_ARCHIVE_DEST_2 OPTIONAL'
LOG_ARCHIVE_DEST_STATE_3=ENABLE

LOCATION and SERVICE

Category LOCATION=local_disk_directory SERVICE=net_service_name

Datatype of the attribute

String value

String value

Minimum value

Not applicable

Not applicable

Maximum value

Not applicable

Not applicable

Default value

Not applicable

Not applicable

Requires attributes...

Not applicable

Not applicable

Conflicts with attributes ...

SERVICE, DELAY, DEPENDENCY, REGISTER=location_format, NOREGISTER, ASYNC, TEMPLATE, NET_TIMEOUT

LOCATION, QUOTA_USED, QUOTA_SIZE

Attribute class

ALTER SESSION and ALTER SYSTEM

ALTER SESSION and ALTER SYSTEM

Corresponding V$ARCHIVE_DEST column

DESTINATION

DESTINATION

Related V$ARCHIVE_DEST column

TARGET

TARGET

Purpose

Each destination must either identify a local disk directory or a remotely accessed database.

Use either the LOCATION or the SERVICE attribute to specify a destination where log transport services archive redo logs. For each Data Guard configuration, you must identify at least one local disk directory (LOCATION=local_disk_directory) where redo logs are archived. You can specify up to nine additional local or remote destinations. You identify remote destinations by specifying a valid Oracle Net service name (SERVICE=net_service_name).


Note:

If you are specifying multiple attributes, specify either the LOCATION or SERVICE attribute on the first line of the initialization parameter file.


Use remote archived redo logs to maintain a transactionally consistent copy of the primary database. Do not use locally archived redo logs to maintain a transactionally consistent standby database. However, when you configure log transport services, you must specify at least one local destination. This ensures that the locally archived redo logs are accessible should manual recovery of the primary database be necessary.

To verify the current settings, query the V$ARCHIVE_DEST fixed view:

Defaults

One of these attributes must be specified. There is no default.


Note:

When changing incremental parameters, there are no default attribute values assumed. For example, LOG_ARCHIVE_DEST_1='SERVICE=stby1 LGWR' assumes the SYNC=PARALLEL option. LOG_ARCHIVE_DEST_1='ARCH' fails because SYNC=PARALLEL conflicts with ARCH even though the default for ARCH is SYNC=NOPARALLEL.


Attributes

LOCATION=local_disk_directory

If you use the LOCATION attribute, specify a valid path name for a disk directory on the system that hosts the primary database. Each destination that specifies the LOCATION attribute must identify a unique directory path name. This is the local destination for archiving redo logs.

Local destinations indicate that the archived redo logs are to reside within the file system that is accessible to the primary database. Locally archived redo logs remain physically within the primary database namespace. The destination parameter value specifies the local file system directory path to where the archived redo logs are copied.

SERVICE=network_service_name

If you specify the SERVICE attribute, specify a valid Oracle Net service name.

Archiving redo logs to a remote destination requires a network connection and an Oracle database instance associated with the remote destination to receive the incoming archived redo logs.

The destination parameter value specifies the Oracle Net service name identifying the remote Oracle instance to which the archived redo logs are copied.

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:

Oracle9i Net Services Administrator's Guide for details about setting up Oracle Net service names

Examples

The following example shows the LOCATION attribute with the LOG_ARCHIVE_DEST_n parameter:

LOG_ARCHIVE_DEST_2='LOCATION=/arc_dest'
LOG_ARCHIVE_DEST_STATE_2=ENABLE

The following example shows the SERVICE attribute with the LOG_ARCHIVE_DEST_n parameter:

LOG_ARCHIVE_DEST_3='SERVICE=stby1'
LOG_ARCHIVE_DEST_STATE_3=ENABLE

MANDATORY and OPTIONAL

Category MANDATORY OPTIONAL

Datatype of the attribute

Keyword

Keyword

Minimum value

Not applicable

Not applicable

Maximum value

Not applicable

Not applicable

Default value

Not applicable

Not applicable

Requires attributes ...

Not applicable

Not applicable

Conflicts with attributes ...

OPTIONAL

MANDATORY

Attribute class

ALTER SESSION and ALTER SYSTEM

ALTER SESSION and ALTER SYSTEM

Corresponding V$ARCHIVE_DEST column

BINDING

BINDING

Related V$ARCHIVE_DEST columns

Not applicable

Not applicable

Purpose

You can specify a policy for reuse of online redo logs using the attributes OPTIONAL or MANDATORY with the LOG_ARCHIVE_DEST_n parameter. The archival operation of an optional destination can fail, and the online redo logs are overwritten. If the archival operation of a mandatory destination fails, online redo logs are not overwritten.

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 the log writer process can overwrite the online redo logs. All mandatory destinations and non-standby optional destinations contribute to satisfying the LOG_ARCHIVE_MIN_SUCCEED_DEST=n count. For example, you can set the parameter as follows:

# Database must archive to at least two locations before 
# overwriting the online redo logs.
LOG_ARCHIVE_MIN_SUCCEED_DEST = 2 

When determining how to set your parameters, note that:

The BINDING column of the V$ARCHIVE_DEST fixed view specifies how failure affects the archival operation.

Defaults

If the MANDATORY or the OPTIONAL attribute is not specified with the
LOG_ARCHIVE_DEST_n parameter, the default is OPTIONAL.

At least, one destination must succeed even if all destinations are designated to be optional.

Attributes

MANDATORY

Specifies that archiving to the destination must succeed before the redo log can be made available for reuse.

OPTIONAL

Specifies that successful archiving to the destination is not required before the redo log can be made available for reuse. If the "must succeed count" set with the LOG_ARCHIVE_MIN_SUCCEED_DEST parameter is met, the redo log is marked for reuse.

Examples

The following example shows the MANDATORY attribute with the LOG_ARCHIVE_DEST_n parameter.

LOG_ARCHIVE_DEST_1='LOCATION=/arc/dest MANDATORY'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_3='SERVICE=stby1 MANDATORY'
LOG_ARCHIVE_DEST_STATE_3=ENABLE

MAX_FAILURE and NOMAX_FAILURE

Category MAX_FAILURE=count NOMAX_FAILURE

Datatype of the attribute

Numeric

Keyword

Minimum value

0

Not applicable

Maximum value

None

Not applicable

Default value

None

Not applicable

Requires attributes ...

REOPEN

Not applicable

Conflicts with attributes ...

NOMAX_FAILURE

MAX_FAILURE

Dynamically changed by SQL statement . . .

ALTER SYSTEM

ALTER SYSTEM

Corresponding V$ARCHIVE_DEST column

MAX_FAILURE

Not applicable

Related V$ARCHIVE_DEST columns

FAILURE_COUNT, REOPEN_SECS

Not applicable

Purpose

The MAX_FAILURE and the NOMAX_FAILURE attributes allow you to control the number of times log transport services attempts to reestablish communication and resume archival operations with a failed destination.

Defaults

If you do not specify either the MAX_FAILURE or the NOMAX_FAILURE attribute, the default is NOMAX_FAILURE, which allows an unlimited number of consecutive attempts to transport archived redo logs to the failed destination.

Attributes

MAX_FAILURE=count

The MAX_FAILURE attribute specifies the maximum number of consecutive times that log transport services attempts archival operations to a failed destination. Using this attribute, you can provide failure resolution for archiving destinations to which you want to retry archival operations after a failure, but not retry indefinitely. When you specify the MAX_FAILURE attribute, you must also set the REOPEN attribute to specify how often archival operations are retried to the particular destination.

To Limit the Number of Archival Attempts

If you set both the MAX_FAILURE and REOPEN attributes to nonzero values, log transport services limits the number of archival attempts to the number of times specified by the MAX_FAILURE attribute. Each destination contains an internal failure counter that tracks the number of consecutive archival failures that have occurred. You can view the failure count in the FAILURE_COUNT column of the V$ARCHIVE_DEST fixed view. The related column REOPEN_SECS identifies the REOPEN attribute value.

If an archival operation fails for any reason, the failure count is incremented until:

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 the value zero (0), which causes log transport services to transport archived redo logs to an alternate destination (defined with the ALTERNATE attribute) on the next archival operation.

To Attempt Archival Operations Indefinitely

Log transport services attempt to archive to the failed destination indefinitely if you do not specify the MAX_FAILURE attribute (or if you specify MAX_FAILURE=0 or the NOMAX_FAILURE attribute), and you specify a nonzero value for the REOPEN attribute. If the destination has the MANDATORY attribute, the online redo log is not reclaimable in the event of a repeated failure.

NOMAX_FAILURE

Specify the NOMAX_FAILURE attribute to allow an unlimited number of archival attempts to the failed destination.

The NOMAX_FAILURE attribute is equivalent to specifying MAX_FAILURE=0.

Examples

The following example allows log 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 NOREOPEN attribute was specified.

LOG_ARCHIVE_DEST_1='LOCATION=/arc_dest REOPEN=5 MAX_FAILURE=3'
LOG_ARCHIVE_DEST_STATE_1=ENABLE

NET_TIMEOUT and NONET_TIMEOUT

Category NET_TIMEOUT=seconds NONET_TIMEOUT

Datatype of the attribute

Numeric

Not applicable

Minimum value

15

Not applicable

Maximum value

1200

Not applicable

Default value

Not applicable

Not applicable

Requires attributes ...

LGWR with SYNC=PARALLEL
or
LGWR with ASYNC > 0

Not applicable

Conflicts with attributes ...

ARCH,
LOCATION,
NONET_TIMEOUT,
LGWR with SYNC=NOPARALLEL, LGWR with ASYNC=0

NET_TIMEOUT

Attribute class

ALTER SYSTEM

ALTER SYSTEM

Corresponding V$ARCHIVE_DEST column

NET_TIMEOUT

NET_TIMEOUT

Related V$ARCHIVE_DEST column

Not applicable

Not applicable

Purpose

The NET_TIMEOUT attribute of the LOG_ARCHIVE_DEST_n parameter specifies the number of seconds the log writer process on the primary system waits for status from the network server process before terminating the network connection. The NONET_TIMEOUT attribute reverses or undoes the timeout value that you previously specified with the NET_TIMEOUT attribute.

If you do not specify the NET_TIMEOUT attribute (or if you specify the NONET_TIMEOUT attribute, the primary database can potentially stall. To avoid this situation, specify a small, nonzero value for the NET_TIMEOUT attribute so the primary database can continue operation after the user-specified timeout interval expires when waiting for status from the network server.

Defaults

If the NET_TIMEOUT or the NONET_TIMEOUT attribute is not specified with the LOG_ARCHIVE_DEST_n parameter, the default is NONET_TIMEOUT.

Attributes

NET_TIMEOUT=seconds

The NET_TIMEOUT attribute is used only when the log writer process archives logs using a network server process and when either the ASYNC or the SYNC=PARALLEL attribute is specified. The log writer process waits for the specified amount of time to receive status from the network I/O operation. If the log writer process does not receive acknowledgment within the specified interval, the primary database network connection will be terminated.

In a Data Guard configuration, there are timers that need to be set similarly for each primary-to-standby network connection:

Even though the network connection might be terminated on the primary database, the network connection remains active on the standby database until the corresponding TCP/IP network timers expire. For this reason, you need to set the timers comparably on both sides of the network. If the network timers are not set up properly, subsequent attempts by the logwriter process on the primary database to attach to the standby database will fail because the standby database has not yet timed out and the broken network connection still appears to be valid.


Note:

In general, you should set network timer parameters on the standby system to expire before the timeout period specified by the NET_TIMEOUT attribute on the primary system. For example:

  • Set TCP/IP network timers on the standby system, such as the keepalive parameter, lower than the corresponding value set for the NET_TIMEOUT attribute.
  • Set the Oracle Net EXPIRE_TIME parameter on the standby system lower than the corresponding value that you set for the NET_TIMEOUT attribute. The EXPIRE_TIME parameter is expressed in minutes.

Without careful coordination of the timeout parameter values on the primary and standby systems, it is possible that the primary system might detect a network problem and disconnect, while the standby database might not recognize the network disconnection if its default network timeout values are too high.


See Also:

Oracle9i Net Services Administrator's Guide

If the log writer process detects a network disconnection, even one that was terminated due to a network timeout, the log writer process automatically tries to reconnect to the standby database. The log writer process does this to resolve network brownouts and false network terminations. In most cases, except when the network is physically broken, the log writer process is able to automatically reconnect to the network.

The log writer process continually attempts to reconnect to the standby database for a period of time that depends on the data protection mode currently set for the primary database. Use the following time estimates as a guideline for how long the log writer process will try to reconnect to the standby database:

The actual time the log writer process tries to reconnect depends on the following factors:

For example, a primary database operating in the maximum availability protection mode with a NET_TIMEOUT attribute value set to 60 seconds and an EXPIRE_TIME of 1 minute could actually take a minimum of 1 minute to connect or up to 3 minutes to terminate the connection to the standby database.

NONET_TIMEOUT

The NONET_TIMEOUT attribute implies that the log writer process waits for the default network timeout interval established for the system. The default network timeout interval differs from system to system. On some systems, the default TCP/IP network timeout can be between 10 and 15 minutes.

Examples

The following example shows how to specify a 40-second network timeout value on the primary database with the NET_TIMEOUT attribute.

LOG_ARCHIVE_DEST_2='SERVICE=stby1 LGWR NET_TIMEOUT=40 SYNC=PARALLEL'
LOG_ARCHIVE_DEST_STATE_2=ENABLE

QUOTA_SIZE and NOQUOTA_SIZE

Category QUOTA_SIZE=blocks NOQUOTA_SIZE

Datatype of the attribute

Numeric

Keyword

Minimum value

0 blocks

Not applicable

Maximum value

Unlimited blocks

Not applicable

Default value

Not applicable

Not applicable

Requires attributes ...

LOCATION

Not applicable

Conflicts with attributes ...

NOQUOTA_SIZE, DEPENDENCY, SERVICE

QUOTA_SIZE

Attribute class

ALTER SYSTEM only

ALTER SYSTEM only

Corresponding V$ARCHIVE_DEST column

QUOTA_SIZE

QUOTA_SIZE

Related V$ARCHIVE_DEST column

QUOTA_USED

QUOTA_USED

Purpose

The QUOTA_SIZE and the NOQUOTA_SIZE attributes of the LOG_ARCHIVE_DEST_n parameter indicate the maximum number of 512-byte blocks of physical storage on a disk device that can be used by a local destination.

Defaults

If the QUOTA_SIZE or the NOQUOTA_SIZE attribute is not specified with the LOG_ARCHIVE_DEST_n parameter, the default is NOQUOTA_SIZE.

Attributes

QUOTA_SIZE=blocks

The QUOTA_SIZE attribute indicates the maximum number of 512-byte blocks of physical storage on a disk device that might be used by a local destination. The value is specified in 512-byte blocks even if the physical device uses a different block size. The optional suffix values K, M, and G represent thousand, million, and billion, respectively (the value 1K means 1,000 512-byte blocks).

A local archiving destination can be designated as being able to occupy all or some portion of the physical disk. For example, in a Real Application Clusters environment, a physical archived redo log disk device might be shared by two or more separate nodes (through a clustered file system, such as is available with Sun Clusters). As there is no cross-instance initialization parameter knowledge, none of the Real Application Clusters nodes is aware that the archived redo log physical disk device is shared with other instances. This can lead to significant problems when the destination disk device becomes full; the error is not detected until every instance tries to archive to the already full device. This seriously affects database availability.

For example, consider an 8-gigabyte (GB) disk device /dev/arc_dest that is further subdivided into node-specific directories node_a, node_b, and node_c. The DBA could designate that each of these instances is allowed to use a maximum of 2 GB, which would allow an additional 2 GB for other purposes. This scenario is shown in Figure 12-2.

Figure 12-2 Specifying Disk Quota for a Destination

Text description of quotasiz.gif follows.

Text description of the illustration quotasiz.gif

No instance uses more than its allotted quota.

The quota is common to all users of the destination, including foreground archival operations, the archiver process, and even the log writer process.

Oracle Corporation highly recommends that the ALTERNATE attribute be used in conjunction with the QUOTA_SIZE attribute. However, this is not required.

See Also:

ALTERNATE and NOALTERNATE

NOQUOTA_SIZE

Use of the NOQUOTA_SIZE attribute, or the QUOTA_SIZE attribute with a value of zero (0), indicates that there is unlimited use of the disk device by this destination; this is the default behavior.

Examples

The following example shows the QUOTA_SIZE attribute with the LOG_ARCHIVE_DEST_n parameter.

LOG_ARCHIVE_DEST_4='QUOTA_SIZE=100K'

QUOTA_USED and NOQUOTA_USED

Category QUOTA_USED=blocks NOQUOTA_USED

Datatype of the attribute

Numeric

Keyword

Minimum value

0 blocks

Not applicable

Maximum value

Unlimited blocks

Not applicable

Default value

Not applicable

Not applicable

Requires attributes ...

LOCATION

Not applicable

Conflicts with attributes ...

NOQUOTA_USED, DEPENDENCY, SERVICE

QUOTA_USED

Attribute class

ALTER SYSTEM only

ALTER SYSTEM only

Corresponding V$ARCHIVE_DEST column

QUOTA_USED

QUOTA_USED

Related V$ARCHIVE_DEST column

QUOTA_SIZE

QUOTA_SIZE

Purpose

The QUOTA_USED and the NOQUOTA_USED attributes of the LOG_ARCHIVE_DEST_n parameter identify the number of 512-byte blocks of data that were archived on a specified destination.

Defaults

If the QUOTA_USED or the NOQUOTA_USED attribute is not specified with the LOG_ARCHIVE_DEST_n parameter, the default is NOQUOTA_USED.

The QUOTA_USED attribute has a default value of zero (0) for remote archiving destinations.

Attributes

QUOTA_USED=blocks

The QUOTA_USED attribute identifies the number of 512-byte blocks of data that were archived on the specified local destination. The value is specified in 512-byte blocks even if the physical device uses a different block size. The optional suffix values K, M, and G represent thousand, million, and billion, respectively (the value 1K means 1,000 512-byte blocks).

This attribute cannot be modified at the session level.

If you specify a QUOTA_SIZE attribute value greater than zero (0) for a destination, but do not specify a QUOTA_USED attribute value in the database initialization parameter file, the QUOTA_USED attribute value is automatically determined when the database is initially mounted. The QUOTA_USED attribute value defaults to the actual number of blocks residing on the local archiving destination device. If the calculated QUOTA_USED attribute value exceeds the QUOTA_SIZE attribute value, the QUOTA_SIZE attribute value is automatically adjusted to reflect the actual storage used.

This automatic calculation of the QUOTA_USED value applies only to local archiving destinations.


Note:

The runtime value of the QUOTA_USED attribute changes automatically as online redo log archival operations are started. The QUOTA_USED attribute value is automatically pre-allocated against the destination quota size. You do not need to change the value of this attribute.


If, at runtime, you dynamically modify the QUOTA_SIZE attribute value, but not the QUOTA_USED attribute value, the QUOTA_USED attribute value is not automatically recalculated.

For local destinations, the QUOTA_USED attribute value is incremented at the start of an archival operation. If the resulting value is greater than the QUOTA_SIZE attribute value, the destination status is changed to FULL, and the destination is rejected before the archival operation begins.

The QUOTA_SIZE and QUOTA_USED attributes are very important because they can be used together to detect a lack of disk space before the archival operation begins.

Consider the case where the QUOTA_SIZE attribute value is 100K and the QUOTA_USED attribute value is 100K also. The destination status is VALID at this point. However, an attempt to archive 1 block results in the QUOTA_USED attribute value being changed to 101K, which exceeds the QUOTA_SIZE attribute value. Therefore, the destination status is changed to FULL, and the destination is rejected before the archival operation begins.

NOQUOTA_USED

Specifies that an unlimited number of blocks of data can be archived on a specified destination.

Examples

Data Guard automatically sets this value. You do not need to change the value of the QUOTA_USED and the NOQUOTA_USED attributes.


REGISTER and NOREGISTER

Category REGISTER NOREGISTER

Datatype of the attribute

Keyword

Keyword

Minimum value

Not applicable

Not applicable

Maximum value

Not applicable

Not applicable

Default value

Not applicable

Not applicable

Requires attributes ...

Not applicable

SERVICE

Conflicts with attributes ...

NOREGISTER, NOALTERNATE

REGISTER, LOCATION

Attribute class

ALTER SESSION and ALTER SYSTEM

ALTER SESSION and ALTER SYSTEM

Corresponding V$ARCHIVE_DEST column

DESTINATION

DESTINATION

Related $ARCHIVE_DEST column

TARGET

TARGET

Purpose

The REGISTER and the NOREGISTER attributes of the LOG_ARCHIVE_DEST_n parameter indicate if the location of the archived redo log is to be recorded at the destination site.

Defaults

If the REGISTER or the NOREGISTER attribute is not specified with the LOG_ARCHIVE_DEST_n parameter, the default is REGISTER.

Attributes

REGISTER

The REGISTER attribute indicates that the location of the archived redo log is to be recorded at the corresponding destination.

For a physical standby destination, the archived redo log filename is recorded in the destination database control file, which is then used by the managed recovery operation.

For a logical standby database, the archived redo log filename is recorded in the tablespace maintained by the logical standby database control file which is then used by SQL apply operations.

The REGISTER attribute implies that the destination is a Data Guard standby database.

By default, the location of the archived redo log, at a remote destination site, is derived from the destination instance initialization parameters STANDBY_ARCHIVE_DEST and LOG_ARCHIVE_FORMAT.


Note:

You can also set the REGISTER attribute by executing the SQL ALTER DATABASE REGISTER LOGFILE filespec statement on each standby database. See Section 7.2.2.1 for an example of this SQL statement.


NOREGISTER

The optional NOREGISTER attribute indicates that the location of the archived redo log is not to be recorded at the corresponding destination. This setting pertains to remote destinations only. The location of each archived redo log is always recorded in the primary database control file.

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

Examples

The following example shows the REGISTER attribute with the LOG_ARCHIVE_DEST_n parameter.

LOG_ARCHIVE_DEST_5='REGISTER'

REGISTER=location_format

Category REGISTER=location_format

Datatype of the attribute

String value

Minimum value

Not applicable

Maximum value

Not applicable

Default value

Not applicable

Requires attributes ...

DEPENDENCY

Conflicts with attributes ...

NOREGISTER, LOCATION, TEMPLATE

Attribute class

ALTER SESSION and ALTER SYSTEM

Corresponding V$ARCHIVE_DEST column

DESTINATION

Related V$ARCHIVE_DEST column

TARGET

Purpose

The optional REGISTER=location_format attribute is used to specify a filename format template for archived redo logs that is different from the default filename format template defined in the primary and standby database initialization parameter files.

This attribute is for use on physical standby databases only.

Defaults

There is no default for this attribute.

Attributes

REGISTER=location_format

The optional REGISTER=location_format attribute is used to specify a fully-qualified filename format template for archived redo logs that is different from the default filename format template defined in the primary and standby database initialization parameter files. The default filename format template is a combination of the database initialization parameters STANDBY_ARCHIVE_DEST and LOG_ARCHIVE_FORMAT.

See Also:

REGISTER and NOREGISTER

The REGISTER=location_format attribute is valid with remote destinations only.

Examples

The following example shows the REGISTER=location_format attribute with the LOG_ARCHIVE_DEST_n parameter.

LOG_ARCHIVE_DEST_4='REGISTER=/disk1/oracle/oradata/payroll/arc%d_%t_%s.arc'

REOPEN and NOREOPEN

Category REOPEN [=seconds] NOREOPEN

Datatype of the attribute

Numeric

Keyword

Minimum value

0 seconds

Not applicable

Maximum value

Unlimited seconds

Not applicable

Default value

300 seconds

Not applicable

Requires attributes ...

Not applicable

Not applicable

Conflicts with attributes ...

NOREOPEN

REOPEN

Attribute class

ALTER SESSION and ALTER SYSTEM

ALTER SESSION and ALTER SYSTEM

Corresponding V$ARCHIVE_DEST column

REOPEN_SECS

REOPEN_SECS

Related V$ARCHIVE_DEST column

MAX_FAILURE

MAX_FAILURE

Purpose

The REOPEN and the NOREOPEN attributes of the LOG_ARCHIVE_DEST_n parameter specify the minimum number of seconds before the archiver process (ARCn, foreground, or log writer process) should try again to access a previously failed destination. You can turn off the attribute by specifying NOREOPEN.

Defaults

If the REOPEN or the NOREOPEN attribute is not specified with the
LOG_ARCHIVE_DEST_n parameter, the default is REOPEN. If the REOPEN attribute is specified without an integer value, the default is 300 seconds.

Attributes

REOPEN[=seconds]

REOPEN applies to all errors, not just connection failures. These errors include, but are not limited to, network failures, disk errors, and quota exceptions.

If you specify REOPEN for an OPTIONAL destination, it is still possible for the Oracle database server to overwrite online redo logs even if there is an error. If you specify REOPEN for a MANDATORY destination, log transport services stall the primary database when they cannot successfully archive redo logs. When this situation occurs, consider the following options:

When you use the REOPEN attribute, note that:

NOREOPEN

If you specify NOREOPEN, the failed destination remains disabled until:

Examples

The following example shows the REOPEN attribute with the
LOG_ARCHIVE_DEST_n parameter.

LOG_ARCHIVE_DEST_3='SERVICE=stby1 MANDATORY REOPEN=60'
LOG_ARCHIVE_DEST_STATE_3=ENABLE

SYNC and ASYNC

Category SYNC[=parallel_option] ASYNC[=blocks]

Datatype of the attribute

Keyword

Numeric

Minimum value

Not applicable

0 blocks

Maximum value

Not applicable

20,480 blocks

Default value

Not applicable

2,048

Requires attributes ...

Not applicable

LGWR

Conflicts with attributes ...

ASYNC

SYNC, LOCATION, ARCH

Attribute class

ALTER SESSION and ALTER SYSTEM

ALTER SYSTEM only

Corresponding V$ARCHIVE_DEST column

TRANSMIT_MODE

TRANSMIT_MODE

Related V$ARCHIVE_DEST column

Not applicable

ASYNC_BLOCKS

Purpose

The SYNC and the ASYNC attributes of the LOG_ARCHIVE_DEST_n parameter specify that network I/O operations are to be done synchronously or asynchronously when using the log writer process (LGWR).


Note:

When the primary database is in one of the three protection modes, standby redo log archiving destinations using the log writer process are automatically placed in SYNC mode.


Defaults

If the SYNC or ASYNC attribute is not specified, the default is SYNC. If the destination defaults to SYNC, or the SYNC attribute is specified without specifying the PARALLEL qualifier, the default for the PARALLEL qualifier depends on which transmitter process is chosen for the destination. When you specify the LGWR attribute, the default parallel qualifier is PARALLEL. Because the PARALLEL qualifier is not allowed with the ARCH attribute, when you specify the ARCH attribute, the default parallel qualifier is NOPARALLEL.

If the ASYNC attribute is specified without an integer value, the default is 2048 blocks.

Attributes

SYNC=PARALLEL
SYNC=NOPARALLEL

The SYNC attribute specifies that network I/O is to be performed synchronously for the destination, which means that once the I/O is initiated, the archiving process waits for the I/O to complete before continuing. The SYNC attribute is one requirement for setting up a no-data-loss environment, because it ensures that the redo records were successfully transmitted to the standby site before continuing.

If the log writer process is defined to be the transmitter to multiple standby destinations that use the SYNC attribute, the user has the option of specifying SYNC=PARALLEL or SYNC=NOPARALLEL for each of those destinations.

Because the PARALLEL and NOPARALLEL qualifiers only make a difference if multiple destinations are involved, Oracle Corporation recommends that all destinations use the same value.

ASYNC[=blocks]

The ASYNC attribute specifies that network I/O is to be performed asynchronously for the destination. Once the I/O is initiated, the log writer continues processing the next request without waiting for the I/O to complete and without checking the completion status of the I/O. Use of the ASYNC attribute allows standby environments to be maintained with little or no performance effect on the primary database. The optional block count determines the size of the SGA network buffer to be used. In general, the slower the network connection, the larger the block count should be. Also, specifying the ASYNC=0 attribute is the same as specifying the SYNC=NOPARALLEL attribute.

When you use the ASYNC attribute, there are several events that cause the network I/O to be initiated:

Examples

The following example shows the SYNC attribute with the LOG_ARCHIVE_DEST_n parameter.

LOG_ARCHIVE_DEST_3='SERVICE=stby1 LGWR SYNC'
LOG_ARCHIVE_DEST_STATE_3=ENABLE

TEMPLATE and NOTEMPLATE

Category TEMPLATE=filename_template NOTEMPLATE

Datatype of the attribute

String value

Not applicable

Minimum value

Not applicable

Not applicable

Maximum value

Not applicable

Not applicable

Default value

Not applicable

Not applicable

Requires attributes ...

SERVICE

Not applicable

Conflicts with attributes ...

NOTEMPLATE, LOCATION, REGISTER=location_format

TEMPLATE

Attribute class

ALTER SESSION and ALTER SYSTEM

ALTER SESSION and ALTER SYSTEM

Corresponding
V$ARCHIVE_DEST column

REMOTE_TEMPLATE

REMOTE_TEMPLATE

Related V$ARCHIVE_DEST column

REGISTER

REGISTER

Purpose

The TEMPLATE and the NOTEMPLATE attributes of the LOG_ARCHIVE_DEST_n parameter define a directory specification and format template for archived redo logs at the standby destination. You can specify this attribute in either the primary or standby initialization parameter file, but the attribute applies only to the database role that is archiving.

The TEMPLATE attribute overrides the STANDBY_ARCHIVE_DEST and LOG_ARCHIVE_FORMAT initialization parameter settings at the remote archive destination.

The TEMPLATE and NOTEMPLATE attributes are valid only with remote destinations.


Note:

If used on a LGWR destination, rearchival by the ARCn process does not use the TEMPLATE specification. This is important for protected destinations.


Defaults

There is no default for this attribute.

Attributes

TEMPLATE=filename_template

Use the optional TEMPLATE attribute to define a directory specification and format for archived redo logs at the standby destination. The definition is used to generate a filename that is different from the default filename format defined by the STANDBY_ARCHIVE_DEST and LOG_ARCHIVE_FORMAT initialization parameters at the standby destination.

The filename_template value of the TEMPLATE attribute must contain a thread or sequence number directive. The following table provides a definition for each directive.

Thread or Sequence Number Directive Description

%a

Substitute the database activation ID.

%A

Substitute the database activation ID zero-filled.

%d

Substitute the database ID.

%D

Substitute the database ID zero-filled.

%t

Substitute the instance thread number.

%T

Substitute the instance thread number zero-filled.

%s

Substitute the log file sequence number.

%S

Substitute the log file sequence number zero-filled.

The filename_template value is transmitted to the standby destination, where it is translated and validated before creating the filename.

If you do not specify the TEMPLATE attribute, the setting is the same as REGISTER.

NOTEMPLATE

Use the optional NOTEMPLATE attribute to allow the filename format template defined by the STANDBY_ARCHIVE_DEST and LOG_ARCHIVE_FORMAT initialization parameters to take effect.

Examples

The following example shows the TEMPLATE attribute with the LOG_ARCHIVE_DEST_n parameter.

LOG_ARCHIVE_DEST_1='SERVICE=stby1 MANDATORY REOPEN=5
    TEMPLATE=/usr/oracle/prmy1/p1_%t_%s.dbf'
LOG_ARCHIVE_DEST_STATE_1=ENABLE

prmy1 archives redo logs at the remote destination. stby1 is located in the directory /usr/oracle/prmy1 with the filename format of p1_<thread#>_<sequence#>.dbf.

12.4 Attribute Compatibility for Archive Destinations

The LOG_ARCHIVE_DEST_n initialization parameter has many attributes. Some of these attributes conflict with each other. Some of the attributes require that other attributes are also defined. Table 12-2 lists the supported attributes and the requirements associated with each one.

Table 12-2 LOG_ARCHIVE_DEST_n Attribute Compatibility
Attribute Requires... Conflicts with...

AFFIRM

Not applicable

NOAFFIRM

NOAFFIRM

Not applicable

AFFIRM

ALTERNATE=
destination

Not applicable

NOALTERNATE

NOALTERNATE

Not applicable

ALTERNATE

ARCH

Not applicable

LGWR
ASYNC
NET_TIMEOUT

ASYNC[=blocks]

LGWR

SYNC
LOCATION
ARCH

DELAY

SERVICE

LOCATION
NODELAY

NODELAY

Not applicable

DELAY

DEPENDENCY

SERVICE
REGISTER

LOCATION
NODEPENDENCY
NOREGISTER
QUOTA_SIZE
QUOTA_USED

NODEPENDENCY

Not applicable

DEPENDENCY

LGWR

Not applicable

ARCH

LOCATION

Not applicable

SERVICE
DEPENDENCY
REGISTER=
location_format
NOREGISTER
DELAY
ASYNC
NET_TIMEOUT
TEMPLATE

MANDATORY

Not applicable

OPTIONAL

MAX_FAILURE

REOPEN

NOMAX_FAILURE

NOMAX_FAILURE

Not applicable

MAX_FAILURE

NET_TIMEOUT

LGWR with SYNC=PARALLEL or
LGWR with ASYNC > 0

ARCH
LOCATION
NONET_TIMEOUT
LGWR
with SYNC=NOPARALLEL
LGWR
with ASYNC=0

NONET_TIMEOUT

Not applicable

NET_TIMEOUT

OPTIONAL

Not applicable

MANDATORY

QUOTA_SIZE

LOCATION

DEPENDENCY
SERVICE
NOQUOTA_SIZE

NOQUOTA_SIZE

Not applicable

QUOTA_SIZE

QUOTA_USED

LOCATION

DEPENDENCY
SERVICE
NOQUOTA_USED

NOQUOTA_USED

Not applicable

QUOTA_USED

REGISTER

Not applicable

NOALTERNATE
NOREGISTER

NOREGISTER

SERVICE

LOCATION
REGISTER

REGISTER=
location_format

DEPENDENCY

LOCATION
NOREGISTER
TEMPLATE

REOPEN

Not applicable

NOREOPEN

NOREOPEN

Not applicable

REOPEN

SERVICE

Not applicable

LOCATION
QUOTA_USED
QUOTA_SIZE

SYNC[=
parallel_option]

Not applicable

ASYNC

TEMPLATE

SERVICE

NOTEMPLATE
LOCATION
REGISTER=
location_format

NOTEMPLATE

Not applicable

TEMPLATE