Purpose
When archiving locally and remotely using the ARCH process where the remote destination is across a saturated or slow network you can receive the following errors in the alert log:
ARC0: Evaluating archive log 2 thread 1 sequence 100
ARC0: Unable to archive log 2 thread 1 sequence 100
Log actively being archived by another process
If the ARCH process is unable to archive at the rate at which online logs are switched then it is possible for the primary database to suspend while waiting for archiving to complete.The following discussion describes how this can occur.
Default Behavior for 9iR2 and Below
The ARCH process sits in a very tight loop waiting for an update to the controlfile that states an online log needs to be archived.Once the update occurs the ARCH process builds a list of archive destinations that need to be serviced.Once this list is complete, the ARCH process will read a one megabyte chunk of data from the online log that is to be archived.This one megabyte chunk is then sent to the first destination in the list.When the write has completed, the same one megabyte chunk is written to the second destination.This continues until all of the data from the online log being archived has been written to all destinations.So it can be said that archiving is only as fast as the slowest destination.
A common misconception is that if the LOG_ARCHIVE_DEST_n parameter for a particular destination has the OPTIONAL attribute set, then that destination will not impede local archiving. This is true during error situations while archiving to that destination - e.g. a network disconnect error, but not during an archival over a slow network, which is not an error situation. In error situations, whether the destination is marked OPTIONAL or MANDATORY, Data Guard will close that destination and continue transmitting to all other valid destinations. Transmitting to the closed destination will be attempted again only after the time specified in the REOPEN attribute has expired and a log switch has occurred.This process will continue for the number of times specified by the MAX_FAILURE attribute. During this time, it is possible that the log writer process recycles through the available online redo log groups and tries to use the online redo log file which has not yet been transmitted successfully to the remote destination. If the destination is marked OPTIONAL, log writer will reuse the online redo log file for the next set of redo. If the destination is marked MANDATORY,log writer will not be able to reuse that online redo log file, and the primary database will delay processing until that online redo log file has been successfully transmitted to the remote destination.
However, the situation is very different if the transmission is being done over a slow network. In this case, no error is encountered and the destination is not closed. Transmission continues, but is very slow. Ultimately, with the unavailability of any more online redo log groups, Log writer may suspend because the archive process is taking a long time to complete its archival, including local archival.
Refining the Default Behavior
The following underscore parameter was introduced as of 9.2.0.5 to allow the DBA to change this default behavior:
_LOG_ARCHIVE_CALLOUT='LOCAL_FIRST=TRUE'
If the above parameter is set then the ARCH process will begin archiving to the local destination first.Once the redo log has been completely and successfully archived to at least one local destination, it will then be transmitted to the remote destination. This is the default behavior beginning with Oracle Database 10g Release 1.
Starting in 9.2.0.7 patchsets, one ARCH process will begin acting as a 'dedicated' archiver, handling only local archival duties. It will not perform remote log shipping or service FAL requests. This is a backport of behavior from 10gR1 to 9iR2.
From Metalink: 260040.1
|
