GoldenGate資料遷移的問題總結(二)(r10筆記第85天)
昨天使用GoldenGate同步資料,資料量玩得有些大了。最後發現很多小問題變得更加嚴峻,比如空間問題。
而且由於沒有更多的經驗,導致這個問題被我引入了另外一個極端。
檢視目標端的空間,一個臨時建立的目錄一下子滿了,得清理一下空間了。
[oracle@newtest ogg_10g]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda5 9.9G 9.4G 17M 100% /
停止了目標端的replicat程序。
> stop rep_test Sending STOP request to REPLICAT REP_TEST ..
這個時候注意到源端的日誌輸出了下面的資訊,已經做了Rolling over的操作
2016-11-16 17:27:58 INFO OGG-01026 Oracle GoldenGate Capture for Oracle, ext_tlbb.prm: Rolling over remote file /export/home/oracle/ogg/ogg_10g/dirdat/tl000068. 2016-11-16 17:28:31 INFO OGG-01026 Oracle GoldenGate Capture for Oracle, ext_tlbb.prm: Rolling over remote file /export/home/oracle/ogg/ogg_10g/dirdat/tl000069. 2016-11-16 17:29:05 INFO OGG-01026 Oracle GoldenGate Capture for Oracle, ext_tlbb.prm: Rolling over remote file /export/home/oracle/ogg/ogg_10g/dirdat/tl000070.
為了儘快清理目標端的trail檔案,我查看了下help的輸出,發現一個cleanup的命令,這個應該不錯,試一試吧。
> cleanup replicat rep_test
Cleanup completed.
然後檢視實際上目標伺服器上壓根沒有清理掉這些trail檔案,而稍後又運行了下面的幾個命令。
delete exttrail /export/home/oracle/ogg/ogg_10g/dirdat/tl000051
delete exttrail /export/home/oracle/ogg/ogg_10g/dirdat/tl
沒有任何的提示,而且伺服器端空間還是沒有釋放。
-rw-rw-rw- 1 oracle oinstall 99999876 Nov 16 17:19 /export/home/oracle/ogg/ogg_10g/dirdat/tl000051
這可讓我很疑惑了。乾脆先停了試試,發現停程序失敗。
> stop rep_test
Sending STOP request to REPLICAT REP_TLBB ...
STOP request pending end-of-transaction (765395 records so far)..
以上的操作都是測試環境的測試所用,所以沒有太大的心理負擔,但是發現問題似乎很難解決了。
從下面的額資訊可以看出,似乎是在寫48號trail檔案的時候hang住了,也不處理任何資料。
> send rep_test, status
Sending STATUS request to REPLICAT REP_TEST ...
Current status: At EOF
Sequence #: 48
RBA: 99999876
6158834 records in current transaction
PENDING
STOP request pending end-of-transaction (6158834 records so far)
最後我使用kill的方式才終於停止了程序。
> kill replicat rep_test
Sending KILL request to MANAGER ...
Killed process (84166) for REPLICAT REP_TEST
然後再次啟動的時候,發現目標端的trail檔案出現了一些變化,程序啟動失敗了,會自動終止。
2016-11-16 18:41:24 INFO OGG-00996 Oracle GoldenGate Delivery for Oracle, rep_tlbb.prm: REPLICAT REP_TLBB started.
2016-11-16 18:41:24 ERROR OGG-01091 Oracle GoldenGate Delivery for Oracle, rep_tlbb.prm: Unable to open file "/export/home/oracle/ogg/ogg_10g/dirdat/tl000022" (error 2, No such file or directory).
2016-11-16 18:41:24 ERROR OGG-01668 Oracle GoldenGate Delivery for Oracle, rep_tlbb.prm: PROCESS ABENDING.
納悶的是trail檔案指向了22號檔案。而前面的trail檔案已經被我刪除了。
這個問題這個時候該怎麼辦?而更讓人奇怪的trail檔案開始瘋狂複製,而源端的trail檔案id最大還是83,目標端已經到了100多。
2016-11-16 18:54:27 INFO OGG-01735 Oracle GoldenGate Collector for Oracle: Synchronizing /export/home/oracle/ogg/ogg_10g/dirdat/tl000168 to disk.
反覆嘗試,折騰了不少時間,想這下只能是重新複製一遍了,如果在資料量很大的情況下,這真是一次失敗的資料複製。
不過今天看了下,想還有沒有救,我試了下面的方法,可能算是一個土辦法,僅供借鑑。
我在目標端的目錄下刪除了應用程序的trail檔案,從源端重新拷貝到了目標端。
在目標端開啟應用程序,不過SEQNO,RBA得改改。
alter replicat rep_TEST, EXTSEQNO 22 EXTRBA 0
這樣一來,rep看似就有了一些反應。
2016-11-17 12:00:55 INFO OGG-00996 Oracle GoldenGate Delivery for Oracle, rep_tlbb.prm: REPLICAT REP_TLBB started.
2016-11-17 12:01:09 INFO OGG-01020 Oracle GoldenGate Delivery for Oracle, rep_tlbb.prm: Processed extract process RESTART_ABEN
D record at seq 23, rba 1037 (aborted 0 records).
檢視應用程序的情況,已經可以看到大事務的資料處理了。
> send rep_test,status
Sending STATUS request to REPLICAT REP_TLBB ...
Current status: Processing data
Sequence #: 37
RBA: 45790084
3352129 records in current transaction
這個過程持續了些時間,同步完成後,資料是同步了過來,已經應用到了83號trail檔案,我想這個問題應該是告一段落了,但是當我在源端繼續修改一些資料,發現目標端沒有同步過來。看來我的那個小伎倆還是有一些限制,而我在源端停止了投遞程序後,重啟就失敗了。
2016-11-17 15:28:34 ERROR OGG-01496 Oracle GoldenGate Capture for Oracle, dp_tlbb.prm: Failed to open target trail file /export
/home/oracle/ogg/ogg_10g/dirdat/tl000169, at RBA 84770994.
2016-11-17 15:28:34 ERROR OGG-01668 Oracle GoldenGate Capture for Oracle, dp_tlbb.prm: PROCESS ABENDING.
不過這個問題通過我對OGG的一些瞭解似乎還是有一些門道。
3> alter extract DP_TEST ETROLLOVER
4> alter DP_TEST extseqno 83,extrba 0
這樣源端的投遞程序就可以啟動了,而問題是目標端的應用程序又開始報錯了,,這個過程就是檢視ggserr.log的資訊,看到是170的trail,那麼我們就修改為170號trail檔案。
alter REPLICAT rep_TLBB,extseqno 170,extrba 0
問題的原因是什麼呢,我們來檢視源端的投遞程序就明白了。源端和目標端是有read position和write position。
> send dp_test,status
Sending STATUS request to EXTRACT DP_TEST ...
EXTRACT DP_TEST (PID 8302)
Current status: Recovery complete: At EOF
Current read position:
Sequence #: 83
RBA: 84769935
Timestamp: 2016-11-17 15:25:38.000000
Extract Trail: /export/home/oracle/ogg/ogg_10g/dirdat/tl
Current write position:
Sequence #: 170
RBA: 84769847
Timestamp: 2016-11-17 15:43:38.610104
Extract Trail: /export/home/oracle/ogg/ogg_10g/dirdat/tl
而對於OGG的資料同步有些過程怎麼理解呢。其實和Oracle中的物化檢視日誌有一些相似,物化檢視的增量重新整理是不完全依賴於物化檢視日誌,而在同步的過程中是會參考已有的資料,其中一個基準就是rowid.
比如下面的語句。
delete from SWD_QDRAWCHECK where rownum<2;
其實對映到目標端就是這樣的形式:
fqgms90ybsvnk DELETE FROM "TEST"."SWD_QDRAWCHECK" WHERE "ID" = :b0
這個過程怎麼去源端印證呢。
我們做了一個delete操作,這些變更就寫入了最新的trail檔案,那麼我們使用strings來檢視裡面的資訊。
AAACe8AAEAAEf5jAEB
TEST.SWD_QDRAWCHECK
8876366
8876242
...
TEST.SWD_DRAWCN
AAACd3AAEAACk4iAAG
16385776
我們根據rowid來檢視,可以看到資料是依舊於ROWID定位到的,而目標端肯定是沒有這個ROWID對應,這就需要傳入一個需要的ID值,比如唯一性主鍵的值等。
> select * from TEST.SWD_QDRAWCHECK where rowid='AAACe8AAEAAEf5jAEB';
ID QDETAILID DRAWCNID
---------- ---------- ----------
8876362 8876233 11171791
整個過程雖然走了不少的彎路,但是反覆嘗試,仔細比對,還是找到了一些門道,希望繼續整理,保證資訊的準確性,,能夠幫助到更多需要的朋友。
今天的筆記到此告一段落,先準備去趕航班了,下一站會到達魔都上海去感受一場技術盛宴,寫筆記的老傳統依舊不變。