我们一般认为oracle的归档行为是：按照LOG_ARCHIVE_DEST_n的设置，先归档第一个路径（local destination），然后再归档另一个路径（remote destination)。
实际上并不是这样，Oracle 9iR2及其以前的版本中，Oracle总是一次得到所有的归档路径列表，然后依次从online redo中读取1M数据，依次发送到各归档目标路径。这样，整个归档的时间就取决于最慢的路径，比如远程的standby。如果当网络发生问题时，很可能出现归档进程hang住，导致日志无法切换。
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.
The following underscore parameter was introduced as of 22.214.171.124 to allow the DBA to change this default behavior.:
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 126.96.36.199 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.
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10640532/viewspace-563066/，如需转载，请注明出处，否则将追究法律责任。