| Oracle Data Guard Concepts and Administration Release 2 (9.2) Part Number A96653-02 |
|
|
View PDF |
| Oracle Data Guard Concepts and Administration Release 2 (9.2) Part Number A96653-02 |
|
|
View PDF |
This chapter provides syntax, values, and information on validity for the archival attributes of the LOG_ARCHIVE_DEST_n initialization parameter. These attributes include:
In addition, this chapter includes the following topics:
|
Note: Each destination must identify either a local disk directory or a remotely accessed database. See Chapter 5 for additional information about log transport services and using these initialization parameters. See Appendix D for information about using these initialization parameters to set up cascaded redo logs. |
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.
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.
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 |
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.
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.
Example 12-2 shows how to set multiple attributes incrementally on separate lines. Specify the SERVICE or LOCATION attribute on the first line.
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.
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:
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.
LOG_ARCHIVE_DEST_1='LOCATION=/disk1/oracle/oradata/payroll' LOG_ARCHIVE_DEST_2='SERVICE=stdby REOPEN=60' LOG_ARCHIVE_DEST_1=''
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;
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.
If the AFFIRM or the NOAFFIRM attribute is not specified with the
LOG_ARCHIVE_DEST_n parameter, the default is NOAFFIRM.
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.
The highest degree of data availability also has the potential for the lowest primary database performance.
|
Note: When the primary database is in the |
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.
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
| 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 ... |
|
|
|
Attribute class |
|
|
|
Corresponding |
|
|
|
Related |
|
|
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. |
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.
If the ALTERNATE or the NOALTERNATE attribute is not specified with the LOG_ARCHIVE_DEST_n parameter, the default is NOALTERNATE.
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.
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:
NOREOPEN attribute is specified.REOPEN attribute.REOPEN attribute and a nonzero MAX_FAILURE count were exceeded.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 |
|
|
2 |
|
|
3 |
|
|
4 |
|
| 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.
Any destination can be designated as an alternate given the following restrictions:
LOG_ARCHIVE_MIN_SUCCEED_DEST parameter value.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.
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.
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.
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.
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
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.
If the ARCH or the LGWR attribute is not specified with the LOG_ARCHIVE_DEST_n parameter, the default is 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.
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.
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
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.
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.
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 |
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;
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.
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
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.
If the DEPENDENCY or the NODEPENDENCY attribute is not specified with the
LOG_ARCHIVE_DEST_n parameter, the default is NODEPENDENCY.
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 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.
Specifies that there is no dependency on the success or failure of an archival operation to another destination.
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
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 |
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:
TARGET column of the V$ARCHIVE_DEST fixed view identifies if the destination is local or remote to the primary database.DESTINATION column of the V$ARCHIVE_DEST fixed view identifies the values that were specified for a destination. For example, the destination parameter value specifies the Oracle Net service name identifying the remote Oracle instance where the archived logs are located.One of these attributes must be specified. There is no default.
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.
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 |
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
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:
OPTIONAL or MANDATORY.
At least one local destination is operationally 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 affects the archival operation.
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.
Specifies that archiving to the destination must succeed before the redo log can be made available for reuse.
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.
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
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.
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.
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.
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:
MAX_FAILURE attribute
ALTER SYSTEM SET statement to dynamically change the MAX_FAILURE attribute (or any other destination attribute). The failure count is reset to zero (0) whenever the destination is modified by an ALTER SYSTEM SET statement. This avoids the problem of setting the MAX_FAILURE attribute to a value less than the current failure count value.
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.
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.
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.
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
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.
If the NET_TIMEOUT or the NONET_TIMEOUT attribute is not specified with the LOG_ARCHIVE_DEST_n parameter, the default is NONET_TIMEOUT.
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:
NET_TIMEOUT attribute on the primary database in the Data Guard configuration.EXPIRE_TIME and the TCP/IP keepalive parameters on each standby database in the Data Guard configuration.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.
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:
NET_TIMEOUT attribute, which determines how long it takes to time out the connection.EXPIRE_TIME parameter or keep alive intervals on the standby database, which determine the minimum amount of time that the reconnection will take on the primary databaseFor 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.
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.
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
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.
If the QUOTA_SIZE or the NOQUOTA_SIZE attribute is not specified with the LOG_ARCHIVE_DEST_n parameter, the default is NOQUOTA_SIZE.
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.
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.
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.
The following example shows the QUOTA_SIZE attribute with the LOG_ARCHIVE_DEST_n parameter.
LOG_ARCHIVE_DEST_4='QUOTA_SIZE=100K'
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.
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.
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.
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.
Specifies that an unlimited number of blocks of data can be archived on a specified destination.
Data Guard automatically sets this value. You do not need to change the value of the QUOTA_USED and the NOQUOTA_USED attributes.
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.
If the REGISTER or the NOREGISTER attribute is not specified with the LOG_ARCHIVE_DEST_n parameter, the default is 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 |
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.
The following example shows the REGISTER attribute with the LOG_ARCHIVE_DEST_n parameter.
LOG_ARCHIVE_DEST_5='REGISTER'
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.
There is no default for this attribute.
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.
The REGISTER=location_format attribute is valid with remote destinations only.
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'
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.
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.
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:
REOPEN attribute, the archiving process checks if the time of the recorded error plus the REOPEN interval is less than the current time. If it is, the archival operation to that destination is retried.MAX_FAILURE=count attribute of the LOG_ARCHIVE_DEST_n initialization parameter.If you specify NOREOPEN, the failed destination remains disabled until:
ALTER SYSTEM SET or an ALTER SESSION SET statement with the REOPEN attribute.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
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 |
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.
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.
SYNC=NOPARALLEL is used, the log writer process performs the network I/O to each destination in series. In other words, the log writer process initiates an I/O to the first destination and waits until it completes before initiating the I/O to the next destination. Specifying the SYNC=NOPARALLEL attribute is the same as specifying the ASYNC=0 attribute.SYNC=PARALLEL is used, the network I/O is initiated asynchronously, so that I/O to multiple destinations can be initiated in parallel. However, once the I/O is initiated, the log writer process waits for each I/O operation to complete before continuing. This is, in effect, the same as performing multiple, synchronous I/O operations simultaneously. The use of SYNC=PARALLEL is likely to perform better than SYNC=NOPARALLEL.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.
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:
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
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 |
There is no default for this attribute.
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.
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.
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.
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.
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.
|
 Copyright © 1998, 2002 Oracle Corporation. All Rights Reserved. |
|