昨天使用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
整个过程虽然走了不少的弯路，但是反复尝试，仔细比对，还是找到了一些门道，希望继续整理，保证信息的准确性，，能够帮助到更多需要的朋友。
今天的笔记到此告一段落，先准备去赶航班了，下一站会到达魔都上海去感受异常技术盛宴，写笔记的老传统依旧不变。
