OGG中主鍵與trandata的添加順序是什么

本篇文章給大家分享的是有關(guān)OGG中主鍵與trandata的添加順序是什么，小編覺(jué)得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說(shuō)，跟著小編一起來(lái)看看吧。

最近在做OGG的壓力測(cè)試，源庫(kù)與目標(biāo)庫(kù)采用表級(jí)同步。 源庫(kù)有20張表，每張表的列都在30-40個(gè)之間，數(shù)據(jù)量不小。

測(cè)試時(shí)候采用循環(huán)執(zhí)行dml語(yǔ)句的方式來(lái)測(cè)試OGG同步效果，測(cè)試腳本示意如下：

該腳本只是用于說(shuō)明過(guò)程，并不嚴(yán)謹(jǐn)

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;

/

測(cè)試結(jié)果非常差，耗時(shí)長(zhǎng)達(dá)10小時(shí)！其中抽取和投遞速度都比較理想，耗時(shí)集中在復(fù)制進(jìn)程執(zhí)行delete操作部分。

GGSCI > lag REPSYM_T

Sending GETLAG request to REPLICAT REPSYM_T ...

Last record lag: 36481 seconds.

At EOF, no more records to process.

遇到這個(gè)問(wèn)題有以下幾個(gè)思路：

1. 設(shè)置多個(gè)復(fù)制進(jìn)程，使其并行。

2. 在復(fù)制進(jìn)程參數(shù)文件中加入batchsql參數(shù)。

3. 綁定變量?jī)?yōu)化delete語(yǔ)句。

直觀感覺(jué)不是以上問(wèn)題能解決的，但是也逐一嘗試了。效果不明顯。 測(cè)試時(shí)一直監(jiān)控undo表空間和用戶(hù)表空間都沒(méi)有什么問(wèn)題，所以也不是這部分問(wèn)題。

接下來(lái)做了一個(gè)測(cè)試，不通過(guò)OGG復(fù)制的方式，在目標(biāo)端創(chuàng)建測(cè)試表，插入10萬(wàn)數(shù)據(jù)，刪除10w數(shù)據(jù)速度正常。看來(lái)問(wèn)題就是在OGG復(fù)制上。

難道是沒(méi)有主鍵？ 使用下面的SQL語(yǔ)句查看了下結(jié)果。發(fā)現(xiàn)所有的表都有主鍵。

select owner,table_name,constraint_type,constraint_name,status

from dba_constraints

where owner='TEST'

and constraint_type in('P','U');

接下來(lái)再查看trandata狀態(tài),結(jié)果很出乎我的意料。

GGSCI > dblogin userid ogg,password ogg

GGSCI> info trandata TEST.*

...

Logging of supplemental redo log data is disabled for table TEST.table1.

..

看到這里，我明白問(wèn)題出在哪了。

同步表沒(méi)有主鍵，在設(shè)置了trandata后，update、delete操作使用所有列綁定為一個(gè)列作為唯一標(biāo)識(shí)來(lái)同步變化的。后來(lái)手工添加了主鍵，但是trandata還是按照之前的方法來(lái)做，并沒(méi)有采用主鍵。解決方法很簡(jiǎn)單，刪除原有trandata，重新add trandata使主鍵生效。

GGSCI> delete trandata TEST.*

GGSCI> add trandata TEST.*

再次測(cè)試效果顯著，復(fù)制進(jìn)程的延時(shí)從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.

總結(jié)：在部署OGG之前需要先對(duì)復(fù)制對(duì)象做個(gè)健康體檢。其中最重要的一點(diǎn)就是源表需要有主鍵或唯一鍵。 如果在OGG部署完成后才發(fā)現(xiàn)源表缺少主鍵或者唯一鍵，需要手工添加后將原有trandata刪除，再重建使其生效。這樣在OGG同步update和delete操作時(shí)才能減少傳輸量，不至于將所有列打包綁定作為“鍵值”來(lái)應(yīng)用。

以上就是OGG中主鍵與trandata的添加順序是什么，小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見(jiàn)到或用到的。希望你能通過(guò)這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注億速云行業(yè)資訊頻道。