共計(jì) 2097 個(gè)字符，預(yù)計(jì)需要花費(fèi) 6 分鐘才能閱讀完成。
本篇文章給大家分享的是有關(guān) OGG 中主鍵與 trandata 的添加順序是什么，丸趣 TV 小編覺(jué)得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說(shuō)，跟著丸趣 TV 小編一起來(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 表空間和用戶表空間都沒(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 的添加順序是什么，丸趣 TV 小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見到或用到的。希望你能通過(guò)這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注丸趣 TV 行業(yè)資訊頻道。
