一 問題描述前段時間，給客戶部署了三套DataGuard，一直都非常穩定，但最近客戶反應primary database時常出現無響應，重啟後一切正常，但不久後仍然處於無響應狀態。
環境：windows2003+oracle 9.2.0.8
DataGuard保護模式：最大性能模式，ARCH傳輸。
primary database告警日志：
Mon Aug 26 00:04:11 2013
ARC2: Begin FAL archive (thread 1 sequence 38840 destination standby)
Creating archive destination LOG_ARCHIVE_DEST_2: 'standby'
ARC2: FAL archive, error 270 creating remote archivelog file 'standby'
Mon Aug 26 00:04:12 2013
Errors in file c:\oracle\admin\prd1\bdump\prd1_arc2_7128.trc:
ORA-00270: error creating archive log
ARC2: FAL archive failed, see trace file.
ARCH: FAL archive failed. Archiver continuing
Mon Aug 26 00:04:12 2013
Errors in file c:\oracle\admin\prd1\bdump\prd1_arc2_7128.trc:
ORA-16055: FAL request rejected
Mon Aug 26 00:04:31 2013
Thread 1 advanced to log sequence 38842
Current log# 2 seq# 38842 mem# 0: D:\DATA\PRD1\REDO02_A.LOG
Mon Aug 26 00:04:31 2013
Current log# 2 seq# 38842 mem# 1: F:\DATA\PRD1\REDO02_B.LOG
Mon Aug 26 00:04:32 2013
ARCH: Evaluating archive log 1 thread 1 sequence 38841
Mon Aug 26 00:04:32 2013
ARCH: Beginning to archive log 1 thread 1 sequence 38841
Mon Aug 26 00:04:32 2013
ARC0: Evaluating archive log 1 thread 1 sequence 38841
ARC0: Unable to archive log 1 thread 1 sequence 38841
Log actively being archived by another process
Mon Aug 26 00:04:32 2013
Creating archive destination LOG_ARCHIVE_DEST_2: 'standby'
Creating archive destination LOG_ARCHIVE_DEST_1: 'F:\PRD1\ARCHIVELOG\ARCH_1_38841.ARC'
ARCH: Completed archiving log 1 thread 1 sequence 38841
Mon Aug 26 00:04:33 2013
Thread 1 advanced to log sequence 38843
Current log# 3 seq# 38843 mem# 0: D:\DATA\PRD1\REDO03_A.LOG
Mon Aug 26 00:04:33 2013
Current log# 3 seq# 38843 mem# 1: F:\DATA\PRD1\REDO03_B.LOG
Mon Aug 26 00:04:34 2013
ARCH: Evaluating archive log 2 thread 1 sequence 38842
Mon Aug 26 00:04:34 2013
ARCH: Beginning to archive log 2 thread 1 sequence 38842
Mon Aug 26 00:04:34 2013
ARC1: Evaluating archive log 2 thread 1 sequence 38842
Mon Aug 26 00:04:34 2013
ARC1: Unable to archive log 2 thread 1 sequence 38842
Log actively being archived by another process
從告警日志可看出遠程歸檔失敗，才導致primary database歸檔無法正常進行，使primary database掛起。理論上說，在Max Performance最大性能模式下，即便遠程無法歸檔，也不應該導致主庫無法正常歸檔的。
在Metalink查詢下，已經有文檔對該問題進行解釋和解決了。
當歸檔本地和遠程使用ARCH進程，並且遠程目標是速度較慢的網絡時，就很有可能出現該錯誤，即便在Max Performance最大性能模式下也會導致主庫無法正常歸檔，最終掛起。
文檔中提到設置隱含參數”_LOG_ARCHIVE_CALLOUT”為LOCAL_FIRST=TRUE來控制ARCH歸檔進程優先完成本地歸檔任務，再傳到備庫，這樣就不影響主庫的歸檔工作。
主庫中修改參數：
alter system set "_LOG_ARCHIVE_CALLOUT"='LOCAL_FIRST=TRUE' scope=both;
alter system set log_archive_max_processes=6 scope=both;
通過調整，數據庫運行正常。
