今天对GoldenGate的数据同步进一步做了测试，发现在一些模拟真实的场景中，需要考虑的因素要更多更为复杂。简单同步几条，几百条数据的测试同步做验证测试可以，但是很难测试出来一些潜在的问题，今天碰到了一些问题，基本都得到了解决。

首先要测试的这个环境数据要多一些。导出了一个测试环境的数据进行OGG的复制演练。

test@TESTDB> select table_type from cat group by table_type

TABLE_TYPE ----------- TABLE VIEW SYNONYM SEQUENCE test@TESTDB> select count(*)from cat;   COUNT(*) ----------        259

我觉得数据迁移里面增量数据的迁移实在是太复杂了，一旦某个地方出错，回滚的余地都会很小。这个用户下有不少的表，所以测试起来就会更加谨慎小心。为了不影响其它用户，我先做了源端和目标端的配置。源端基于Solaris,10gR2,目标端基于Linux 64,11gR2

配置抽取进程

dblogin userid ogg_source,password oracle

add trandata test.* edit params ext_test  EXTRACT ext_test  USERID ogg_source, PASSWORD oracle  EXTTRAIL /export/home/oracle/ogg/ogg_10g/dirdat/tl  TABLE test.*; ADD EXTRACT ext_test, TRANLOG, BEGIN NOW ADD EXTTRAIL /export/home/oracle/ogg/ogg_10g/dirdat/tl, EXTRACT ext_test start ext_test info ext_test

配置投递进程

edit params dp_test

 EXTRACT dp_test  PASSTHRU  RMTHOST 10.127.133.125, MGRPORT 1530  RMTTRAIL  /export/home/oracle/ogg/ogg_10g/dirdat/tl  TABLE test.*; ADD EXTRACT dp_test,EXTTRAILSOURCE /export/home/oracle/ogg/ogg_10g/dirdat/tl ADD RMTTRAIL /export/home/oracle/ogg/ogg_10g/dirdat/tl, EXTRACT dp_test start dp_test info dp_tes配置应用进程

dblogin userid ogg_target,password oracle

edit params rep_test  REPLICAT REP_test  USERID ogg_target, PASSWORD oracle  ASSUMETARGETDEFS  HANDLECOLLISIONS  MAP test.*,TARGET test.*; ADD REPLICAT rep_test, EXTTRAIL /export/home/oracle/ogg/ogg_10g/dirdat/tl,CHECKPOINTTABLE ogg_target.CHKPTAB start rep_test为了简单测试一下数据量大的情况下的同步情况，我选取了下面的几个表数据,摘自impdp的日志

. . imported "test"."SWD_DRAWCN"                         839.7 MB 11174310 rows

. . imported "test"."SWD_QDRAWCHECK"                     187.7 MB 9052277 rows . . imported "test"."TL_SERVER_LOG"                      13.92 MB   61341 rows . . imported "test"."SWD_DRAWCARD"                       8.129 MB  185044 rows

首先测试了delete的情况，看看源端，目标端的同步速率，整个过程持续了近40分钟，其中大部分的时间都在源端，可见硬件老化还是很严重的，在目标端同样的操作就快了不是一点半点。

问题1：抽取进程失败

然后再次使用impdp在源端导入数据，这个过程源端的抽取进程很可能会失败，原因之一就是因为impdp需要创建一个临时表，而我们在配置里指定测试用户下的表都要映射 。

2016-11-16 16:21:04  ERROR   OGG-00901  Failed to lookup object ID for table test.SYS_IMPORT_TABLE_01

.这个过程很容易，在Impdp完成后重启抽取进程即可。

问题2：支持TRUNCATE

我对测试环境中的对象进行了检查，发现有一个地方很可能出现问题，因为在线上库中存在一个JOB,会先清空一个中继表数据，然后补入一部分数据，清空的操作是truncate,所以数据同步还是需要支持truncate操作，对于其它的DDL暂时先不动。

要实现识别truncate的操作，OGG已经做好了，需要在抽取进程和应用进程的参数配置，加入一个参数GETTRUNCATES即可。这样就可以轻松同步数据了，使用truncate都可以自动同步，摆平了一个潜在的隐患。

问题3：投递进程失败

下午在大批量数据的测试场景中，发现投递进程竟然自动停了。

2016-11-16 17:22:36  ERROR   OGG-01668  Oracle GoldenGate Capture for Oracle, dp_test.prm:  PROCESS ABENDING.

2016-11-16 17:22:53  INFO    OGG-01026  Oracle GoldenGate Capture for Oracle, ext_test.prm:  Rolling over remote file /export/home/o racle/ogg/ogg_10g/dirdat/tl000059.登录到目标端，发现数据库直接hang住了。

[oracle@newtest ~]$ sqlplus n1/n1

^C ERROR: ORA-02002: error while writing to audit trail ORA-00604: error occurred at recursive SQL level 1 ORA-01013: user requested cancel of current operation

而问题的原因就是归档空间满了。简单清理后继续测试。

问题4：trail文件的清理

而后续继续测试，发现另外一个问题摆上了日程，那就是对trail文件的清理，其中一个方式就是在mgr中配置参数，设定一个范围来删除。

edit param mgr

PURGEOLDEXTRACTS /export/home/oracle/ogg/ogg_10g/dirdat/tl*, USECHECKPOINTS, MINKEEPDAYS 2

问题5：无法停止replicat进程

如果在数据同步的过程中，停止replicat进程失败，会直接影响数据同步的情况

GGSCI (newtest.oracle.com) 10> stop rep_test

Sending STOP request to REPLICAT REP_test ... STOP request pending end-of-transaction (6158834 records so far)..

可以使用kill的方式终止

GGSCI (newtest.oracle.com) 9> info all

Program     Status      Group       Lag at Chkpt  Time Since Chkpt MANAGER     STOPPED                                            REPLICAT    STOPPED     REP_1       00:00:00      00:00:34     REPLICAT    RUNNING     REP_test    00:31:32      01:01:07  

GGSCI (newtest.oracle.com) 14> start mgr

Manager started.

GGSCI (newtest.oracle.com) 17> kill replicat rep_test

Sending KILL request to MANAGER ... Killed process (84166) for REPLICAT REP_test

小技巧：

在数据复制的过程中，如果想查看源端目标端的同步情况，使用info得到的信息是很笼统的，我们可以使用send的方式得到一个状态信息，这个数据是相对准确的。

GGSCI (newtest.oracle.com) 2> 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)

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-2128589/，如需转载，请注明出处，否则将追究法律责任。