Shulou(Shulou.com)05/31 Report--

This article introduces the relevant knowledge of "analyzing ARCH wait on SENDREQ waiting events". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

In the customer library, AWR reports that the sampling interval is 8 hours, and the average waiting time for ARCH wait on SENDREQ waiting events is longer, about 3 seconds.

It just so happens that the alarm log indicates that the log cannot be allocated. Although the archive_lag_target parameter setting is small (900), the database has 5 redo log groups, so it should not happen that log groups cannot be allocated. Due to the occurrence of this waiting event, it is speculated that the network between the master and slave databases may be poor, resulting in the archiving of the master database cannot be archived to the standby database in time, thus causing cannot allocate new log.

Tue Jul 19 22:19:33 2011

Thread 1 cannot allocate new log, sequence 26887

Private strand flush not complete

The following information about ARCH wait on SENDREQ wait events can be found on Metalink (MOS)

"Data Guard Wait Events"

"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.

The ARCH wait on SENDREQ wait event occurs during the log switch phase. If this event occurs in the Top5 wait event, it indicates a network full load or network configuration problem (in short, the network is poor)

Another article, said to be from metalink, but could not find the original text:

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'

The third solution prompts you to modify the implied parameter: _ 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.

Beginning with Oracle Database 10g Release 1. Doubt, because from my local library of 11.2.0.1, this implied parameter is still empty by default.

Try to modify this implicit parameter on a non-production library for testing:

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 ismod, 4 ismod

6 decode (bitand (y.ksppstvfMagne2), 2 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

17 /

Enter the value of par: callout

Original value 14: x.ksppinm like'% _ & par%'

New value 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'

The system has changed.

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 ismod, 4 ismod

6 decode (bitand (y.ksppstvfMagne2), 2 isadj

7 from

8 sys.x$ksppi x

9 sys.x$ksppcv y

10 where

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 /

Enter the value of par: callout

Original value 14: x.ksppinm like'% _ & par%'

New value 14: x.ksppinm like'% _ callout%'

NAME VALUE ISDEFAULT ISMOD ISADJ

_ log_archive_callout LOCAL_FIRST=TRUE TRUE SYSTEM_MOD FALSE

To sum up: I think we should carefully check the network of the user's main and standby libraries and check the disk IO of the customer's standby library.

This is the end of "analyzing ARCH wait on SENDREQ waiting events". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.