最近在做OGG的压力测试，源库与目标库采用表级同步。 源库有20张表，每张表的列都在30-40个之间，数据量不小。
测试时候采用循环执行dml语句的方式来测试OGG同步效果，测试脚本示意如下：
该脚本只是用于说明过程，并不严谨
begin
for i in 1..100000 loop
Insert into table1 (test_id, col1,col2) values(i,x,x);
Insert into table2 (test_id, col1,col2) values(i,x,x);
...
Insert into table20 (test_id, col1,col2) values(i,x,x);
if mod(1,1000)=0 then
commit;
end if;
end loop;
commit;
end;
/
begin
for i in 1..100000 loop
update table1 set col1=48452 where test_id=i;
update table2 set col1=48452 where test_id=i;
…
update table20 set col1=48452 where test_id=i;
if mod(1,1000)=0 then
commit;
end if;
end loop;
commit;
end;
/
begin
for i in 1..100000 loop
delete table1 where test_id=i;
delete table2 where test_id=i;
…
delete table20 where test_id=i;
if mod(1,1000)=0 then
commit;
end if;
end loop;
commit;
end;
/
测试结果非常差，耗时长达10小时！其中抽取和投递速度都比较理想，耗时集中在复制进程执行delete操作部分。
GGSCI > lag REPSYM_T
Sending GETLAG request to REPLICAT REPSYM_T ...
Last record lag: 36481 seconds.
At EOF, no more records to process.
遇到这个问题有以下几个思路：
1. 设置多个复制进程，使其并行。
2. 在复制进程参数文件中加入batchsql参数。
3. 绑定变量优化delete语句。
直观感觉不是以上问题能解决的，但是也逐一尝试了。效果不明显。 测试时一直监控undo表空间和用户表空间都没有什么问题，所以也不是这部分问题。
接下来做了一个测试，不通过OGG复制的方式，在目标端创建测试表，插入10万数据，删除10w数据速度正常。看来问题就是在OGG复制上。
难道是没有主键？ 使用下面的SQL语句查看了下结果。发现所有的表都有主键。
select owner,table_name,constraint_type,constraint_name,status
from dba_constraints
where owner='TEST'
and constraint_type in('P','U');
接下来再查看trandata状态,结果很出乎我的意料。
GGSCI > dblogin userid ogg,password ogg
GGSCI> info trandata TEST.*
...
Logging of supplemental redo log data is disabled for table TEST.table1.
..
看到这里，我明白问题出在哪了。
同步表没有主键，在设置了trandata后，update、delete操作使用所有列绑定为一个列作为唯一标识来同步变化的。后来手工添加了主键，但是trandata还是按照之前的方法来做，并没有采用主键。解决方法很简单，删除原有trandata，重新add trandata使主键生效。
GGSCI> delete trandata TEST.*
GGSCI> add trandata TEST.*
再次测试效果显著，复制进程的延时从36481降到了542秒！
GGSCI> lag REPSYM_T
Sending GETLAG request to REPLICAT REPSYM_T ...
Last record lag: 542 seconds.
At EOF, no more records to process.
总结：在部署OGG之前需要先对复制对象做个健康体检。其中最重要的一点就是源表需要有主键或唯一键。 如果在OGG部署完成后才发现源表缺少主键或者唯一键，需要手工添加后将原有trandata删除，再重建使其生效。这样在OGG同步update和delete操作时才能减少传输量，不至于将所有列打包绑定作为“键值”来应用。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/31522432/viewspace-2151656/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
没有了~
下一篇：
RMAN 备份与恢复深入解析（一）
请登录后发表评论
登录
全部评论
