昨天遇到一个问题一个OGG的复制进程在复制序列(Sequence)时Hang住不动，进程状态一直是Running状态但是不往前进行复制，导致进程延迟6个多小时
|
1
2
3
4
5
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的语句上
|
1
2
3
|
Wildcard MAP resolved (entry USIM.*):
map
"USIM"
.
"SEQ_PROCESSSTEP"
, target USIM.
"SEQ_PROCESSSTEP"
;
Resolving target sequence USIM.SEQ_PROCESSSTEP.
|
查看ggserr.log也没有报错信息。
于是查看数据库里的会话
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
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用户的角色
|
1
2
3
4
5
6
7
|
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，终于问题解决了。复制进程开始往下复制了，而且序列复制的很快
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
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角色导致的么？现在还不清楚。如果哪位大神知道问题的原因可以在博客中回复，感激不尽。
本文转自hbxztc 51CTO博客，原文链接：http://blog.51cto.com/hbxztc/1893514，如需转载请自行联系原作者
