您好,登錄后才能下訂單哦!
昨天遇到一個(gè)問題一個(gè)OGG的復(fù)制進(jìn)程在復(fù)制序列(Sequence)時(shí)Hang住不動(dòng),進(jìn)程狀態(tài)一直是Running狀態(tài)但是不往前進(jìn)行復(fù)制,導(dǎo)致進(jìn)程延遲6個(gè)多小時(shí)
GGSCI (ctm-3) 2> info all Program Status Group Lag at Chkpt Time Since Chkpt MANAGER RUNNING REPLICAT RUNNING USIM 00:13:39 06:50:22
操作復(fù)制進(jìn)程時(shí),stats和stop顯示操作超時(shí),只能kill進(jìn)程,重啟復(fù)制進(jìn)程問題依就。問題從下午一直持續(xù)到晚上7點(diǎn)多,實(shí)在沒有辦法把所有數(shù)據(jù)都全部初始化了,還是不行,好在數(shù)據(jù)量不大。最后把goldengate用戶賦予dba權(quán)限問題就解決了,但是GOLDENGATE用戶的權(quán)限分配問題依然還是一個(gè)問題。下面記錄了問題的處理過程,有興趣的朋友可以看看。
使用view report usim查看日志,日志停在一個(gè)復(fù)制Sequence的語句上
Wildcard MAP resolved (entry USIM.*): map "USIM"."SEQ_PROCESSSTEP", target USIM."SEQ_PROCESSSTEP"; Resolving target sequence USIM.SEQ_PROCESSSTEP.
查看ggserr.log也沒有報(bào)錯(cuò)信息。
于是查看數(shù)據(jù)庫里的會(huì)話
SYS@ctm> select sid,serial#,LOGON_TIME,MODULE,sql_id,prev_sql_id,event,blocking_session from v$session where MODULE like '%USIM%'; SID SERIAL# LOGON_TIME MODULE SQL_ID PREV_SQL_ID EVENT BLOCKING_SESSION ---------- ---------- ------------ ------------------------------ ------------- ------------- ------------------------------ ---------------- 764 8229 20-JAN-17 OGG-USIM-OPEN_DATA_SOURCE awjuqsu6bk5d4 b6zg67dtg1q14 row cache lock SYS@ctm> select sql_text from v$sql where sql_id='awjuqsu6bk5d4'; SQL_TEXT -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- SELECT "SEQ_PROCESSSTEP".NEXTVAL FROM DUAL SYS@ctm> select sql_text from v$sql where sql_id='b6zg67dtg1q14'; SQL_TEXT -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- SELECT HIGHWATER FROM SYS.SEQ$ WHERE OBJ#=:B1
看到當(dāng)前ogg的復(fù)制進(jìn)程在執(zhí)行SELECT "SEQ_PROCESSSTEP".NEXTVAL FROM DUAL的語句,進(jìn)程是在等待row cache lock。上面貼出來的是晚上查詢時(shí)的情況,其實(shí)下午在查這條sql時(shí)是不同的一個(gè)序列名字,但是動(dòng)作一樣都是select nextval from dual,但是等待事件有l(wèi)ibrary cache: mutex X、cursor: pin S wait on X、latch free、latch: shared pool。
看到這些等待事件頭都大了,先到百度上去搜索,看到有帖子說有可能是BUG,然后又到MOS上去搜等待事件的組合,看到很多BUG的文章,但是描述跟現(xiàn)在遇到的情況不一致。于是又轉(zhuǎn)到搜goldengate和序列hang的關(guān)鍵字,搜到一篇http://m.blog.csdn.net/article/details?id=48544207,在MOS上搜到1331998.1和1535322.1,但都是跟現(xiàn)在的情況不符。
于是又無奈的去查官方文檔,在Oracle GoldenGate Oracle Installation and Setup Guide中查到下面的幾句話:
看到紅框中的那句后恍然想到,由于系統(tǒng)交維,要求不允許用戶有DBA角色,GOLDENGATE也不可以,于是查看GOLDENGATE用戶的角色
SYS@ctm> select granted_role from dba_role_privs where grantee='GOLDENGATE'; GRANTED_ROLE ------------------------------ RESOURCE CONNECT SELECT_CATALOG_ROLE
果然沒有DBA角色,那問題是不是出在這里呢,于是嘗試給GOLDENGATE用戶DBA角色
grant dba to goldengate;
kill掉hang住的會(huì)話,重啟復(fù)制進(jìn)程usim,終于問題解決了。復(fù)制進(jìn)程開始往下復(fù)制了,而且序列復(fù)制的很快
GGSCI (ctrm-r3) 20> stats usim hourly Sending STATS request to REPLICAT USIM ... Start of Statistics at 2017-01-20 21:47:22. DDL replication statistics: *** Total statistics since replicat started *** Operations 0.00 Mapped operations 0.00 Unmapped operations 0.00 Other operations 0.00 Excluded operations 0.00 Errors 0.00 Retried errors 0.00 Discarded errors 0.00 Ignored errors 0.00 Replicating from USIM.SEQ_PROCESSSTEP to USIM.SEQ_PROCESSSTEP: *** Hourly statistics since 2017-01-20 21:46:06 *** Total updates 16.00 Total discards 0.00 Total operations 16.00 End of Statistics.
最后再回想,難道就真的是因?yàn)镈BA角色的關(guān)系么?于是把GOLDENGATE用戶的DBA角色收回:revoke dba from goldengate;
再次觀察復(fù)制進(jìn)程情況,竟然正常在復(fù)制,沒有受到影響。而且從昨晚10點(diǎn)多回收dba角色,到今天發(fā)博客,復(fù)制進(jìn)程也沒有hang住,還在正常復(fù)制。這就回到了上面疑問,真的是因?yàn)镈BA角色導(dǎo)致的么?現(xiàn)在還不清楚。如果哪位大神知道問題的原因可以在博客中回復(fù),感激不盡。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。