昨天遇到一個問題一個OGG的複製進程在複製序列(Sequence)時Hang住不動，進程狀態一直是Running狀態但是不往前進行復制，導致進程延遲6個多小時
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
操作複製進程時，stats和stop顯示操作超時，只能kill進程，重啓複製進程問題依就。問題從下午一直持續到晚上7點多，實在沒有辦法把所有數據都全部初始化了，還是不行，好在數據量不大。最後把goldengate用戶賦予dba權限問題就解決了，但是GOLDENGATE用戶的權限分配問題依然還是一個問題。下面記錄了問題的處理過程，有興趣的朋友可以看看。
使用view report usim查看日誌，日誌停在一個複製Sequence的語句上
Wildcard MAP resolved (entry USIM.*): map "USIM"."SEQ_PROCESSSTEP", target USIM."SEQ_PROCESSSTEP"; Resolving target sequence USIM.SEQ_PROCESSSTEP.
查看ggserr.log也沒有報錯信息。
於是查看數據庫裏的會話
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
看到當前ogg的複製進程在執行SELECT "SEQ_PROCESSSTEP".NEXTVAL FROM DUAL的語句，進程是在等待row cache lock。上面貼出來的是晚上查詢時的情況，其實下午在查這條sql時是不同的一個序列名字，但是動作一樣都是select nextval from dual，但是等待事件有library cache: mutex X、cursor: pin S wait on X、latch free、latch: shared pool。
看到這些等待事件頭都大了，先到百度上去搜索，看到有帖子說有可能是BUG，然後又到MOS上去搜等待事件的組合，看到很多BUG的文章，但是描述跟現在遇到的情況不一致。於是又轉到搜goldengate和序列hang的關鍵字，搜到一篇http://m.blog.csdn.net/article/details?id=48544207，在MOS上搜到1331998.1和1535322.1，但都是跟現在的情況不符。
於是又無奈的去查官方文檔，在Oracle GoldenGate Oracle Installation and Setup Guide中查到下面的幾句話：
看到紅框中的那句後恍然想到，由於系統交維，要求不允許用戶有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住的會話，重啓複製進程usim，終於問題解決了。複製進程開始往下複製了，而且序列複製的很快
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.
最後再回想，難道就真的是因爲DBA角色的關係麼？於是把GOLDENGATE用戶的DBA角色收回:revoke dba from goldengate;
再次觀察複製進程情況，竟然正常在複製，沒有受到影響。而且從昨晚10點多回收dba角色，到今天發博客，複製進程也沒有hang住，還在正常複製。這就回到了上面疑問，真的是因爲DBA角色導致的麼？現在還不清楚。如果哪位大神知道問題的原因可以在博客中回覆，感激不盡。