Release 1 (9.0.1)
Part Number A88808-01
 Home |
 Book List |
 Contents |
 Index |  Master Index |  Feedback |
| Oracle9i Data Guard Concepts and Administration Release 1 (9.0.1) Part Number A88808-01 |
|
This chapter provides syntax, values, and information on validity for attributes of the LOG_ARCHIVE_DEST_n initialization parameters. These attributes include:
In addition, this chapter includes the following topics:
Each LOG_ARCHIVE_DEST_n (where n is an integer from 1 to 10) initialization parameter allows you to specify redo log archive destinations, including one required local destination and up to nine additional local or remote destinations. These parameters also allow you to set a number of archival options for each destination. See Chapter 3 for additional information.
AFFIRM NOAFFIRM
Use this option to ensure that archived redo log contents have been successfully written to disk and are immediately available for database recovery. The AFFIRM attribute indicates that all archived redo log I/O operations are to be performed synchronously. The NOAFFIRM attribute indicates that all archived redo log disk I/O operations are to be performed asynchronously.
The AFFIRM attribute has the potential to affect primary database performance. When you use the LGWR and AFFIRM attributes to indicate that the log writer process will synchronously write the locally archived redo log contents to disk, control is not returned to the users 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 may take longer, and online redo logs may not be reusable.
Using the AFFIRM attribute does not affect performance when using the ASYNC attribute.
The AFFIRM column of the V$ARCHIVE_DEST fixed view indicates whether or not the AFFIRM attribute is being used for the associated destination.
The AFFIRM attribute is best used in conjunction with the SYNC and ASYNC attributes to provide the highest degree of control over negative performance effects on the primary database. The following table identifies the various combinations of these attributes and their potential for affecting primary database performance and data availability.
The highest degree of data availability also has the potential for the lowest primary database performance.
ALTERNATE=LOG_ARCHIVE_DEST_1 NOALTERNATE
Use the ALTERNATE attribute of the LOG_ARCHIVE_DEST_n parameters 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 will be 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 will attempt to archive online redo logs to the alternate destination on the next archival operation.
Use the NOALTERNATE attribute of the LOG_ARCHIVE_DEST_n parameters to prevent the original destination from automatically changing to an alternate destination when the original destination fails.
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 parameters. 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 3.3.1.2 for more details about the LOG_ARCHIVE_DEST_STATE_n parameters.
The ALTERNATE attribute cannot be modified at the session level.
In the sample initialization parameter file in Example 8-1, LOG_ARCHIVE_DEST_1 will automatically fail over to LOG_ARCHIVE_DEST_2 on the next archival operation if an error occurs or the device becomes full.
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 8-2 shows how to define 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
Figure 8-1 shows a scenario where online log files are archived to a local disk device.
If the original destination device becomes full or unavailable, the archival operation will be automatically redirected to the alternate destination device, as shown in Figure 8-2.
The REOPEN attribute takes precedence over the ALTERNATE attribute. The alternate destination will be used only if one of the following is true:
NOREOPEN attribute is specified.
REOPEN attribute.
REOPEN attribute and a non-zero MAX_FAILURE count have been exceeded.
The ALTERNATE attribute takes precedence over the MANDATORY attribute. This means that a destination will fail over to a valid alternate destination even if the current destination is mandatory.
The following is the archived redo log destination attribute precedence table:
| Precedence | Attribute |
|---|---|
|
Highest |
|
|
|
|
|
|
|
|
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 also be manually deferred at runtime. See Section 3.3.2.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 certainly not a requirement.
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.
Any destination can be designated as an alternate given the following restrictions:
LOG_ARCHIVE_MIN_SUCCEED_DEST parameter value.
Session-defined destinations will not activate an alternate destination defined at the system level. Conversely, system-defined destinations will not activate an alternate destination defined at the session level.
If the NOALTERNATE attribute is specified, or if no alternate destination is specified, the destination does not automatically change to another destination upon failure.
If the REOPEN attribute is specified with a non-zero value, the ALTERNATE attribute is ignored. If the MAX_FAILURE attribute is also specified with a non-zero value, and the failure count exceeds the specified failure threshold, the ALTERNATE destination is enabled. Therefore, the ALTERNATE attribute does not conflict with a non-zero REOPEN attribute value.
ARCH LGWR
The optional ARCH and LGWR attributes are used to specify the Oracle database server process that is responsible for transmitting redo log files to the corresponding destination.
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. ARCH is the implicit default setting.
The LGWR attribute indicates that redo log files 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 log files are transmitted concurrently, they are not retransmitted to the corresponding destination during the archival operation.
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 will 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 will continue to archive until the next log switch operation.
DELAY=60 NODELAY
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 may 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.
Use the DELAY attribute of the LOG_ARCHIVE_DEST_n initialization parameters 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.
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. If you specify the DELAY attribute without a time interval, the default time interval is 30 minutes.
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 has expired, use the NODELAY keyword of the RECOVER MANAGED STANDBY statement; for example:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;
DEPENDENCY=LOG_ARCHIVE_DEST_1 NODEPENDENCY
A standby destination can be defined as being dependent upon the success or failure of an archival operation to another locally accessible destination. The dependent destination is known as the child destination. The destination on which the child depends is known as the parent 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:
DEPENDENCY attribute cannot be modified at the session level.
REGISTER attribute is required.
SERVICE attribute is required.
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 were 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 may or may not be dependent upon the same parent destination.
LOCATION=/tmp/arc_dest SERVICE=stby1
Each destination identifies either a local disk directory or a remotely accessed database. A remotely accessed database can be either a physical standby database or another instance of the current database.
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 where the archived redo logs will be placed. 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 managed recovery of the primary database be necessary.
Locally archived redo logs are not used to maintain a transactionally consistent standby database.
If you specify SERVICE, specify a valid Oracle Net service name. The Oracle database server translates this net service name into a connection descriptor. The descriptor contains the information necessary for connecting to the remote database. The service name must have an associated database SID, so that the Oracle database server correctly updates the log history of the control file for the standby database.
Remote destinations indicate that the archived redo logs are to reside elsewhere and are physically outside of the primary database namespace.
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 where the archived log files will be located.
Remotely archived redo logs are available to maintain a transactionally consistent copy of the primary database.
Remotely located archived redo log files are not currently accessible for managed recovery of the primary database.
|
See Also:
Oracle9i Net Services Administrator's Guide for more information on creating Oracle Net service names |
The DESTINATION column of the V$ARCHIVE_DEST fixed view identifies the values that have been specified for a destination.
The TARGET column of the V$ARCHIVE_DEST fixed view identifies whether the destination is local or remote to the primary database.
MANDATORY OPTIONAL
You can specify a policy for reuse of online redo logs using the attributes OPTIONAL or MANDATORY. The archival of an optional destination can fail, and the online redo logs will be overwritten. If the archival of mandatory destinations fail, online redo log files will not be overwritten.
By default, one destination is mandatory even if all destinations are designated to be optional. The following example shows how to set a mandatory archiving destination:
LOG_ARCHIVE_DEST_3 = 'LOCATION=/arc_dest MANDATORY'
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:
MANDATORY for a destination is the same as specifying OPTIONAL.
OPTIONAL or MANDATORY.
At least one local destination will operationally be treated as mandatory, because the minimum value for the LOG_ARCHIVE_MIN_SUCCEED_DEST parameter is 1.
LOG_ARCHIVE_MIN_SUCCEED_DEST parameter irrelevant.
LOG_ARCHIVE_MIN_SUCCEED_DEST value cannot be greater than the number of destinations, nor greater than the number of mandatory destinations plus the number of optional local destinations.
The BINDING column of the V$ARCHIVE_DEST fixed view specifies how failure will affect the archival operation.
MAX_FAILURE=30 NOMAX_FAILURE
The MAX_FAILURE attribute specifies the maximum number of contiguous archival failures for the particular destination. Use this attribute for archiving destinations that you want to retry archival operations to after a failure, but not retry indefinitely.
You must use the MAX_FAILURE attribute in conjunction with a REOPEN attribute value greater than zero (0).
The MAX_FAILURE attribute corresponds to the MAX_FAILURE column of the V$ARCHIVE_DEST fixed view. The column FAILURE_COUNT identifies the number of contiguous failures that have occurred. The related column REOPEN_SECS identifies the REOPEN attribute value.
The MAX_FAILURE attribute identifies the maximum number of repeated archival operations that will be attempted before giving up.
Use of the NOMAX_FAILURE attribute, or use of a MAX_FAILURE attribute value of zero (0), indicates that an unlimited number of destination failures are allowed.
If the MAX_FAILURE attribute is not specified (or is specified as NOMAX_FAILURE), and the REOPEN attribute is specified with a non-zero value, the archival operation will be indefinitely attempted. If the destination has the MANDATORY attribute, the online redo log will not be reclaimable in the event of a repeated failure.
This attribute cannot be modified at the session level.
Each destination contains an internal operation failure count. The failure count is reset to zero (0) whenever the destination is modified by the user entering an ALTER SYSTEM SET statement. Runtime modifications made to the destination, such as changing the QUOTA_USED attribute (described in the QUOTA_USED and NOQUOTA_USED section), do not affect the failure count. The failure count can be displayed using the related FAILURE_COUNT column of the V$ARCHIVE_DEST fixed view.
If an archival operation fails for any reason, the failure count is incremented. If the failure count is greater than or equal to the MAX_FAILURE attribute value, the REOPEN attribute value is implicitly set to the value zero (0). The REOPEN_SECS column of the V$ARCHIVE_DEST fixed view displays the real value.
Dynamically changing the MAX_FAILURE attribute (or any other destination attribute) resets the destination failure count. This avoids the problem of setting the MAX_FAILURE attribute to a value less than the current failure count value.
QUOTA_SIZE=100K NOQUOTA_SIZE
The QUOTA_SIZE attribute indicates the maximum number of 512-byte blocks of physical storage on a disk device that may be consumed 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).
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 of the disk device by this destination; this is the default value.
This attribute cannot be modified at the session level.
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 may 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 consume a maximum of 2 GB, which would allow an additional 2 GB for other purposes. This scenario is shown in Figure 8-3.
No instance will consume more than its allotted quota, so the conceptual picture displayed in Figure 8-3 holds true.
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.
QUOTA_USED=450K NOQUOTA_USED
The QUOTA_USED attribute identifies the number of 512-byte blocks of data that have been archived on the specified local destination. Note that 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 will be automatically determined when the database is initially mounted. The QUOTA_USED attribute value will default 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 will be automatically adjusted to reflect the actual storage consumed.
This automatic calculation of the QUOTA_USED value applies only to local archiving destinations.
If, at runtime, you dynamically modify the QUOTA_SIZE attribute value, but not the QUOTA_USED attribute value, the QUOTA_USED attribute value will not be 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_USED 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 will result 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.
The QUOTA_USED attribute has a default value of zero (0) for remote archiving destinations.
REGISTER NOREGISTER
The REGISTER attribute indicates that the location of the archived redo log is to be recorded in the corresponding destination database control file. This is the implicit default setting.
For a standby destination database, this archived redo log registry serves as the manifest for the managed standby recovery operation.
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.
The optional NOREGISTER attribute indicates that the location of the archived redo log is not to be recorded in the corresponding destination database control file. 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 incompatible with the LOCATION and DEPENDENCY attributes.
REGISTER=/dsk1/dir1/arc_%t_%s.arc
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. The default filename format template is a combination of the database initialization parameters STANDBY_ARCHIVE_DEST and LOG_ARCHIVE_FORMAT.
If the attribute value is not specified, then the setting is the same as REGISTER.
The REGISTER=location_format attribute is valid with remote destinations only. It requires the DEPENDENCY attribute and is incompatible with the LOCATION attribute.
REOPEN=30 NOREOPEN
The REOPEN attribute specifies 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 option by specifying NOREOPEN.
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 without a value, the attribute has a default value of 300 seconds.
If you specify NOREOPEN, the failed destination remains disabled until:
ALTER SYSTEM SET or an ALTER SESSION SET statement with the REOPEN option
SYNC ASYNC=20480
When you use the log writer process (LGWR) to transmit redo logs to a standby database, you can specify the method by which the network I/O operations are performed.
The SYNC attribute indicates that all network I/O operations are to be performed synchronously, in conjunction with each write operation to the online redo log. Control will not be returned to the users until the redo information is received by the standby site, and the disk I/O operation on the standby site has completed. This attribute has the potential to affect primary database performance when you use slow network connections, but provides the highest degree of data availability.
The ASYNC attribute indicates that all network I/O operations are to be performed asynchronously, and control is returned to users immediately. The block count specified determines the size of the SGA network buffer to be used. In general, the slower the network connection you have, the larger the block count should be.
If you do not specify either SYNC or ASYNC, SYNC is the default. If you specify ASYNC without specifying a value, 2,048 is the default.
With local archive destinations, there is no benefit to using asynchronous I/O operations. Therefore, the ASYNC attribute is incompatible with the LOCATION attribute.
The LOG_ARCHIVE_DEST_n initialization parameters have many attributes. Some of these attributes conflict with each other. Some of the attributes require that other attributes are also defined. Table 8-1 lists the supported attributes and the requirements associated with each one.
|
 Copyright © 1996-2001, Oracle Corporation. All Rights Reserved. |
|