昨天遇到一个问题一个 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 也没有报错信息。
于是查看数据库里的会话
- > 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
- > select sql_text from v$sql where sql_id='awjuqsu6bk5d4';
- SQL_TEXT
- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
- SELECT "SEQ_PROCESSSTEP".NEXTVAL FROM DUAL
- > 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 的关键字,搜到一篇,在 MOS 上搜到 1331998.1 和 1535322.1,但都是跟现在的情况不符。
于是又无奈的去查官方文档,在 Oracle GoldenGate Oracle Installation and Setup Guide 中查到下面的几句话:
看到红框中的那句后恍然想到,由于系统交维,要求不允许用户有 DBA 角色,GOLDENGATE 也不可以,于是查看 GOLDENGATE 用户的角色
- > 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 角色导致的么?现在还不清楚。如果哪位大神知道问题的原因可以在博客中回复,感激不尽。
来源: