分析ARCHwaitonSENDREQ等待事件

本篇內(nèi)容介紹了“分析ARCH wait on SENDREQ等待事件”的有關(guān)知識，在實(shí)際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

公司主營業(yè)務(wù)：網(wǎng)站設(shè)計(jì)、成都做網(wǎng)站、移動網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。創(chuàng)新互聯(lián)是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會用頭腦與智慧不斷的給客戶帶來驚喜。創(chuàng)新互聯(lián)推出榆陽免費(fèi)做網(wǎng)站回饋大家。

客戶庫，AWR報告采樣間隔8小時，ARCH wait on SENDREQ等待事件平均等待時間較長，約3秒。

恰巧告警日志中提示無法分配日志，雖然archive_lag_target參數(shù)設(shè)置較小（為900），但是數(shù)據(jù)庫有5個重做日志組，按理說應(yīng)該不會出現(xiàn)無法分配日志組的情況出現(xiàn)。由于這個等待事件的出現(xiàn)，故猜想主備庫之間的網(wǎng)絡(luò)可能較差，導(dǎo)致主庫的歸檔無法及時歸檔到備庫上，從而引發(fā)cannot allocate new log。

Tue Jul 19 22:19:33 2011
Thread 1 cannot allocate new log, sequence 26887
Private strand flush not complete

從Metalink（MOS）上可查到如下關(guān)于ARCH wait on SENDREQ等待事件的信息

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

在log switch階段會出現(xiàn)ARCH wait on SENDREQ等待事件，如果此事件出現(xiàn)在Top5等待事件中，說明網(wǎng)絡(luò)滿負(fù)載或網(wǎng)絡(luò)配置問題（總之，網(wǎng)絡(luò)較差）

還有一篇，說是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’

第三種解決方案提示修改隱含參數(shù)：_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.表示質(zhì)疑，因?yàn)閺奈冶镜?1.2.0.1的庫來看，此隱含參數(shù)默認(rèn)還是空。

嘗試在非生產(chǎn)庫上修改此隱含參數(shù)做測試：

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';

系統(tǒng)已更改。

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

綜上：我認(rèn)為應(yīng)該仔細(xì)檢查一下用戶主備庫網(wǎng)絡(luò)情況，檢查客戶備庫磁盤IO。

“分析ARCH wait on SENDREQ等待事件”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！

文章名稱：分析ARCHwaitonSENDREQ等待事件
文章URL：http://muchs.cn/article48/pichep.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供Google、商城網(wǎng)站、全網(wǎng)營銷推廣、營銷型網(wǎng)站建設(shè)、用戶體驗(yàn)、虛擬主機(jī)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)