目标库DML 堵塞(dblink)导致OGG延迟

目录

• 问题概述
• 问题原因
• 解决方案
• 模拟故障
• 参考文档

问题概述

xx库OGG延迟超过8个小时，但进程处于RUNNING。

问题原因

定位到有人通过A库的DBLINK修改目标库的数据。 OGG同步的表， 目标的端也在做修改相同数据，无法保证一致。 改完数据未进行提交，产生enq:tx lock，超过8个小时。

解决方案

跟业务核实并确认可以把dblink的session kill掉

模拟故障

1、准备3台测试环境
第一台：ogg源端
第二台：ogg目标端
第三台：模拟故障中的A库
2、测试创建测试表 在源端insert 2条记录

SQL> create table itpux01.t_ljc (a int);

表已创建。

SQL> insert into itpux01.t_ljc values(1)
2 ;

已创建 1 行。

SQL> insert into itpux01.t_ljc values(2);

已创建 1 行。

SQL> commit;

3、目标库创建表，并查询数据是否同步正常。

SQL> create table itpux01.t_ljc (a int);

表已创建。

SQL> select * from itpux01.t_ljc;

A
----------
1
2

4、在第三个库上

CREATE PUBLIC DATABASE LINK db_link_test2 CONNECT TO dbmt IDENTIFIED BY xxx USING '(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST =192.168.3.62)(PORT =1521 ))
)
(CONNECT_DATA =
(SERVICE_NAME = tsoadb)
)
)';

5、用dblink 做update语句，不要commit；

QL>
SQL> update itpux01.t_ljc@db_link_test2 set a=3 where a=2;

1 row updated.

SQL>

6、主库在插入几条记录
7、在目标库上看ogg进程

GGSCI (jcogg02) 33> info all

Program Status Group Lag at Chkpt Time Since Chkpt

MANAGER RUNNING
REPLICAT RUNNING RITPUX01 00:00:00 02:46:35

8、查看一下active session

SQL> @ase
USERNAME SID EVENT MACHINE MODULE STATUS LAST_CALL_ET SQL_ID WAI_SECINW ROW_WAIT_OBJ# SQLTEXT BS CH# OSUSER HEX
----------- ---------- -------------------- ---------- -------------------- -------- ------------ --------------- ---------- ------------- ------------------------------ ---------- ---- ---------- ---------
GOLDENGATE 16 enq: TX - row lock c jcogg02 OGG-OPEN_DATA_SOURCE ACTIVE 4416 2c27jbgnzd0rg 0:4250 73785 UPDATE "ITPUX01"."T_LJC" x SET 1:1 0 oracle 1000000

SQL>

9、业务确认kill session
10、查看ogg 进程延迟

GGSCI (jcogg02) 49> info all

Program Status Group Lag at Chkpt Time Since Chkpt

MANAGER RUNNING
REPLICAT RUNNING RITPUX01 00:00:00 00:00:02

参考文档

无