a515047717 发表于 2012-7-9 14:03:40

goldengate目标端lag延迟过大

通过info all命令在目标端执行后，发现其中一个复制进程lag延迟过大，达到100多个小时，并且还在不断增大中，请问我如何查询目标端在做什么操作导致该lag延迟过大并且查看该复制进程是否还在运行当中？

Maclean Liu(刘相兵 发表于 2012-7-9 14:17:59

action plan:

执行以下语句并 贴出输出

        info REPLICAT YOUR_REP_NAME, detail
        lag REPLICAT YOUR_REP_NAME

a515047717 发表于 2012-7-9 14:36:04

附件是刘大要求的查询输出，目前该复制进程一直在Log Read Checkpoint  File ./dirdat/ya016291
                                                                                2012-07-01 05:48:12.261576  RBA 27481858
停滞不前，请问如何处理？

Wizard 发表于 2012-7-9 15:03:46

source DB 和 target DB分别是什么版本？

a515047717 发表于 2012-7-9 15:09:25

回复 4# 的帖子

源端和目标端数据库版本都是10.2.0.4.0的

Maclean Liu(刘相兵 发表于 2012-7-9 15:11:19

Action Plan:

代码:
ggsci

info all
info YOUR_REP,detail
send YOUR_REP,status
status YOUR_REP
info replicat YOUR_REP,showch
view report YOUR_REP



Logon database:

Select * From v$transaction;

a515047717 发表于 2012-7-9 15:35:13

Maclean Liu(刘相兵 发表于 2012-7-9 20:39:46

v$transaction 中
一个活动事务 USED_UBLK达到 316280个block

这说明存在一个大事务 导致 replicat 缓慢，建议你查询target端的alert.log检查是否存在性能瓶颈

该事务从07/09/12 09:00:04就开始了

USED_UBLK – Number of undo blocks used
USED_UREC – Number of undo records used

a515047717 发表于 2012-7-10 08:11:38

回复 8# 的帖子

谢谢刘大 今天早上查看该事务还是停留在原来的时间点，查看alert.log信息都是正常的日志切换信息，能否有正确的方法使该事务结束？

pengzhi 发表于 2012-7-10 21:15:58

到恢复的数据库里面检查一下是同步那张表导致的,然后stop ,edit param 参数文件, 把那张表TABLEEXCLUDE掉,跳过那张表的同步,等同步完后,再STOP replicat,手工同步跳过的表.再修改参数文件---->启动恢复进程.

pengzhi 发表于 2012-7-10 23:39:12

检查一下TARGET库的约束和TRIGER是否都已经禁用了.

zhanwenjun 发表于 2015-1-6 14:37:50

你好，你最后是怎么解决的？replicat  lag很大
页: [1]
查看完整版本: goldengate目标端lag延迟过大