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

本篇文章給大家分享的是有關OGG中主鍵與trandata的添加順序是什么，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

最近在做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操作時才能減少傳輸量，不至于將所有列打包綁定作為“鍵值”來應用。

以上就是OGG中主鍵與trandata的添加順序是什么，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。