本篇文章给大家分享的是有关OGG中主键与trandata的添加顺序是什么,小编觉得挺实用的,因此分享给大家学习,希望大家阅读完这篇文章后可以有所收获,话不多说,跟着小编一起来看看吧。
最近在做OGG的压力测试,源库与目标库采用表级同步。源库有20张表,每张表的列都在30 - 40个之间,数据量不小。
测试时候采用循环执行dml语句的方式来测试OGG同步效果,测试脚本示意如下:
该脚本只是用于说明过程,并不严谨
开始的我1 . .100000年循环
,,,,,插入表1 (test_id、col1 col2)值(x, x);
,,,,,插入表二(test_id、col1 col2)值(x, x);
,,,,,…
,,,,,插入table20 (test_id、col1 col2)值(x, x);
,,,,,如果国防部(1000)=0
,,,,,,,提交;
,,,,,如果,
结束循环;
提交;
,
/
开始的我1 . .100000年循环
,,,,,更新表1组col1=48452 test_id=我;
,,,,,更新表二组col1=48452 test_id=我;
,,,,,…
,,,,,更新table20 col1=48452, test_id=我;
,,,,,如果国防部(1000)=0
,,,,,,,提交;
,,,,,如果,
结束循环;
提交;
,
/
开始的我1 . .100000年循环
,,,,,删除table1 test_id=我;
,,,,,删除表test_id=我;
,,,,,…
,,,,,删除table20 test_id=我;
,,,,,如果国防部(1000)=0
,,,,,,,提交;
,,,,,如果,
结束循环;
提交;
,
/
测试结果非常差,耗时长达10小时。其中抽取和投递速度都比较理想,耗时集中在复制进程执行删除操作部分。
GGSCI祝辞lag REPSYM_T
GETLAG将请求发送给REPLICAT REPSYM_T……
最后记录延迟:<强> 36481 秒。
EOF,没有更多的记录过程。
遇到这个问题有以下几个思路:
1。设置多个复制进程,使其并行。
2。在复制进程参数文件中加入batchsql参数。
3。绑定变量优化删除语句。
直观感觉不是以上问题能解决的,但是也逐一尝试了。效果不明显。测试时一直监控撤消表空间和用户表空间都没有什么问题,所以也不是这部分问题。
接下来做了一个测试,不通过OGG复制的方式,在目标端创建测试表,插入10万数据,删除10 w数据速度正常。看来问题就是在OGG复制上。
难道是没有主键吗?使用下面的SQL语句查看了下结果。发现所有的表都有主键。
选择主人,table_name, constraint_type, constraint_name,地位从dba_constraints
所有者=& # 39;测试# 39;
和constraint_type (& # 39; p # 39; & # 39; u # 39;);
接下来再查看trandata状态,结果很出乎我的意料。
GGSCI 比;dblogin userid ogg,密码ogg
GGSCI>信息trandata测试。*
…
补充重做日志数据的日志<强> 表TEST.table1禁用。
. .
看到这里,我明白问题出在哪了。
同步表没有主键,在设置了trandata后,更新,删除操作使用所有列绑定为一个列作为唯一标识来同步变化的。后来手工添加了主键,但是trandata还是按照之前的方法来做,并没有采用主键。解决方法很简单,删除原有trandata,重新添加trandata使主键生效。
GGSCI>删除trandata测试。*
GGSCI>添加trandata测试。*
再次测试效果显著,复制进程的延时从36481降到了542秒!
GGSCI>lag REPSYM_T
GETLAG将请求发送给REPLICAT REPSYM_T……
最后记录延迟:<强> 542 秒。
EOF,没有更多的记录过程。
总结:在部署OGG之前需要先对复制对象做个健康体检。其中最重要的一点就是源表需要有主键或唯一键。如果在OGG部署完成后才发现源表缺少主键或者唯一键,需要手工添加后将原有trandata删除,再重建使其生效。这样在OGG同步更新和删除操作时才能减少传输量,不至于将所有列打包绑定作为“键值”来应用。
以上就是OGG中主键与trandata的添加顺序是什么,小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注行业资讯频道。
