環境：AIX 5.3 9i 9.2.0.8
DG模式：最大性能，ARCH傳輸方式
物理連接方式：電信4M專線（8臺數據庫共享）
客戶8套災備standby數據庫從上海本地機房搬遷至北京IDC數據中心後周一生產環境下，一套FMDB數據庫primary端不能正常歸檔導致數據庫被掛起。
Mon Dec 24 10:00:47 2012
ARC0: Complete FAL archive (thread 1 sequence 55730 destination fmpdb_new)
ARC0: Evaluating archive log 2 thread 1 sequence 57890
ARC0: Unable to archive log 2 thread 1 sequence 57890
Log actively being archived by another process
ARC0: Evaluating archive log 4 thread 1 sequence 57891
ARC0: Beginning to archive log 4 thread 1 sequence 57891
Creating archive destination LOG_ARCHIVE_DEST_2: 'fmpdb_new'
Creating archive destination LOG_ARCHIVE_DEST_1: '/oradata/fmpdb/arch/1_57891.dbf'
Mon Dec 24 10:03:19 2012
ORACLE Instance fmpdb - Can not allocate log, archival required意思是數據庫有歸檔的請求但是不能正常進行歸檔，這個時候就有可能產生數據庫非常緩慢以及掛起的情況。
通過檢查發現是由於專線帶寬不足引起的問題，那爲什麼該套DG數據庫會由於不能正常歸檔被hang住呢？
首先，講一下我們生產的環境，我們生產端和災備端是通過一根4M的專線去連接的，4M專線的速度理論即 4096/8=512KB，如果加上線路損耗的話實際應該是小於這個值的，這樣一根專線需要供8臺數據庫做同步通信使用。
在最大性能模式，9i數據庫下從online redo log中輪流讀1M歸檔日誌數據到primary db本地歸檔目錄，然後讀1M歸檔日誌數據到standby歸檔目錄，這樣直到讀取完一個redo log爲止，在出現網絡及慢的情況下tnsping不會返回有任何結果（又不正常但又沒有error返回），這樣就導致不能讀寫到standby,從而primary db不能正常歸檔，以至於數據庫被掛起。 由於9i下這種輪流替換傳輸歸檔的特殊性導致在極端帶寬條件下導致錯誤的發生。通過查詢ORACLE 對於9.2.0.5以後的版本爲了解決該問題開放了一個隱含參數供設置。
ORACLE 官方已有對該問題的解釋，詳見文檔ID 260040.1：
Refining Remote Archival Over a Slow Network with the ARCH Process [ID 260040.1]
裏面有提到通過設置隱含參數”_LOG_ARCHIVE_CALLOUT”爲LOCAL_FIRST=TRUE來強制數據庫先進行本地歸檔再傳輸到standby數據庫
alter system set “_LOG_ARCHIVE_CALLOUT”=’LOCAL_FIRST=TRUE’ scope=both;
因爲數據庫默認log_archive_max_processes=2,爲了增加archive的可處理進程建議增加至跟數據庫online redo log的組數保持一致，即log_archive_max_processes=6 (生產環境online redo log爲6組，最大不能超9)
通過設置_LOG_ARCHIVE_CALLOUT=’LOCAL_FIRST=TRUE’ 以及’log_archive_max_processes=6′一般即可解決該問題。
【附】Refining Remote Archival Over a Slow Network with the ARCH Process [ID 260040.1]
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 continuefor the number of times specifiedby 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’
This is a dynamic Parameter, so you can set it this Way:
SQL> alter system set “_LOG_ARCHIVE_CALLOUT”=’LOCAL_FIRST=TRUE’ scope=both;
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.