GoldenGate資料遷移的問題總結(二)

昨天使用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

整個過程雖然走了不少的彎路，但是反覆嘗試，仔細比對，還是找到了一些門道，希望繼續整理，保證資訊的準確性，，能夠幫助到更多需要的朋友。

今天的筆記到此告一段落，先準備去趕航班了，下一站會到達魔都上海去感受異常技術盛宴，寫筆記的老傳統依舊不變。