ARCH wait on SENDREQ等待事件

“ARCH wait on SENDREQ” This wait event monitors  the amount of time spent by all archiver processes to write the received redo to disk as well as open and close the remote archived redo logs.

《Troubleshooting 9i Data Guard Network Issues》

The ‘ARCH wait on SENDREQ’ wait  event increases during a log switch period. This event’s average wait time also increases as the network round trip time (RTT) increases.  If this wait event is in the top 5, then it may be indicative of a saturated network or a poorly configured network. Also, make sure that enough redo log groups are configured so that any delay in remote archiving does not result in a hung database due to no available online redo logs.

在log switch阶段会出现ARCH wait on SENDREQ等待事件，如果此事件出现在Top5等待事件中，说明网络满负载或网络配置问题（总之，网络较差）

还有一篇，说是metalink上的，不过没找到原文：

1)It means that there is a  slow network between primary and standby database.

2)It also means that there is a chance of  slow performance on disk where remote archiving is happening.

Solution：

1.Please get in touch with your network admin and  check the network response.

2.If the remote destination is slow and archiver is taking longer to archive to that destination, then the user needs to  allocate more redo log groups so that there is a logfile available for a logswitch to switch into, and not wait for the archiver to finish archiving to the destination.

3.One more workaround you can use is to set below parameter in primary site:

_LOG_ARCHIVE_CALLOUT=’LOCAL_FIRST=TRUE’

第三种解决方案提示修改隐含参数：_LOG_ARCHIVE_CALLOUT

_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 localdestination, 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.

我对上文This is the default behavior. beginning with  Oracle Database  10g Release 1.表示质疑，因为从我本地11.2.0.1的库来看，此隐含参数默认还是空。

尝试在非生产库上修改此隐含参数做测试：

SQL> set linesize 132 SQL> column name format a30 SQL> column value format a25 SQL> select 2    x.ksppinm  name, 3    y.ksppstvl  value, 4    y.ksppstdf  isdefault, 5    decode(bitand(y.ksppstvf,7),1,’MODIFIED’,4,’SYSTEM_MOD’,’FALSE’)  ismod, 6    decode(bitand(y.ksppstvf,2),2,’TRUE’,’FALSE’)  isadj 7  from 8    sys.x$ksppi x, 9    sys.x$ksppcv y 10  where 11    x.inst_id = userenv(‘Instance’) and 12    y.inst_id = userenv(‘Instance’) and 13    x.indx = y.indx and 14    x.ksppinm like ‘%_&par%’ 15  order by 16    translate(x.ksppinm, ‘ _’, ‘ ‘) 17  / 输入 par 的值:  callout 原值   14:   x.ksppinm like ‘%_&par%’ 新值   14:   x.ksppinm like ‘%_callout%’

NAME                           VALUE                     ISDEFAULT ISMOD      ISADJ —————————— ————————- ——— ———- —– _log_archive_callout                                     TRUE      FALSE      FALSE

SQL> alter system set “_log_archive_callout”=’LOCAL_FIRST=TRUE';

系统已更改。

SQL> set linesize 132 SQL> column name format a30 SQL> column value format a25 SQL> select 2    x.ksppinm  name, 3    y.ksppstvl  value, 4    y.ksppstdf  isdefault, 5    decode(bitand(y.ksppstvf,7),1,’MODIFIED’,4,’SYSTEM_MOD’,’FALSE’)  ismod, 6    decode(bitand(y.ksppstvf,2),2,’TRUE’,’FALSE’)  isadj 7  from 8    sys.x$ksppi x, 9    sys.x$ksppcv y 10  where 11    x.inst_id = userenv(‘Instance’) and 12    y.inst_id = userenv(‘Instance’) and 13    x.indx = y.indx and 14    x.ksppinm like ‘%_&par%’ 15  order by 16    translate(x.ksppinm, ‘ _’, ‘ ‘) 17  / 输入 par 的值:  callout 原值   14:   x.ksppinm like ‘%_&par%’ 新值   14:   x.ksppinm like ‘%_callout%’

NAME                           VALUE                     ISDEFAULT ISMOD      ISADJ —————————— ————————- ——— ———- —– _log_archive_callout           LOCAL_FIRST=TRUE          TRUE      SYSTEM_MOD FALSE

综上：我认为应该仔细检查一下用户主备库网络情况，检查客户备库磁盘IO。