OGG

特点：

1. 优点：独立于oracle，有自己的进程，使用较少的CPU和内存。和DG，Stream相比比较轻。
2. 架构：前端OLTP系统，后端数据仓库，以OGG相连。采用单向，DML复制。
3. 问题：双向复制实际上非常难以维护，总会有数据冲突，DDL是非常好的概念，但是现在还有许多bug。很多truncate无法忠实复制到目标端。而且国际字符也会成为问题。
4. RAC环境：一般需要把OGG的文件放在共享磁盘，可以从任何节点启动，可以把OGG添加到集群服务中，当OGG死了可以自动启动。理论上可行，实际碰到的问题是：当节点弹的时候，ogg在另外一端启动，可是内存中的信息还没有清理干净，这样OGG直接就abend了。

监控

1. 监控什么？：Extract、Pump、Replicate、Lagging、Long running sessions
2. 工具：OGG director、OEM、脚本
3. 进程状态读取：1）ggsci: >info all； 2）tail -n50 ggserr.log
4. Lagging:1)能够容忍多久的延迟（very close sync） 2） 在源端有没有大量的导入数据，如果有，延迟是不可避免的。3)用heartbeat table 来做lagging monitor。
5. Long transactions:1）有时候一个事务好几天没有提交或回滚，这样会导致这个事务的日志已经归档而且连归档都已经清空，这个时候来一个提交，结果需要从磁带上恢复归档日志。然后OGG才可以读取日志，传递到目标端。2）主要通过v$transaction 视图（实际上，就算一些和复制无关的长事务，也会导致问题。因为在事务没提交时，OGG锁定内存，一方面导致内存被极大占用（例子：12c中，一个extract 60g，设置参数不起作用，问oracle也解决不了。），另一方面长事务经常会导致问题，11g以后因为引入了boundary recovery，长事务abend的情况变少了。）3）OGG在分布式数据库中使用时，不容易控制。
6. OGG的文件存储问题：1）必须预先保留空间给突发的长事务。2）对于归档日志，可以采用双目录的策略，OGG的目录必须保留3倍的内容：如正常1天，OGG3天。

维护abend：任何时候abend，先确定是逻辑问题，还是物理问题。

1. 物理问题有可能是：
   1. 装trail文件的file system满了
   2. 需要的archive log不在了，需要从磁盘导入。
   3. 网络问题：查看ggserr.log会看到TCP错误
   4. 在Rac环境下有些节点无法访问OGG
   5. 如果服务器荷载很大，每个OGG的进程会消耗大量cpu和内存，有可能击垮服务器。
2. 逻辑问题：
   1. Unique Key violation:源如果source里面有重复行，目标端如果有primary key会报错。
   2. No data found/Delete row not existing. 如果在父子表里面删除一行，有时候目标端会删除两遍。这样replicat进程会abend。
3. 查看详细的错误信息：
   1. ggserr.log 或者view report
   2. Discard file
   3. REPERROR:在target端非常有用，可以压制错误。错误可以ignore,默认是abend,也可以goto “exception tables”.
   4. exception table:可以捕获所有失败记录
4. 其他的工具：
   1. logdump:用来read/mine trail file：具体事例
5. 风险评估和数据同步。
1. 如果出现逻辑原因的abend，首先要查看源端和目标端是否真的异步out of sync。
2. 如果异步，我们只需要给数据打补丁，还是需要重新导入？
3. 如果需要重新导入，我们有没有downtime 时间。
4. 我们可以用export/import来做initial laod。
5. 用OGG的initial laod，关键参数是source:sourceistable,target: special run, handlecollisions

案例分析：

1. replicate 进程abend，需要table的重新同步：我们发现有一个表没有同步好，需要重新同步。
1. 现在replicate 参数文件上注释掉对应的表格。
2. 重启replicate（stop/start），这样没有受影响的表继续同步。
3. 记录源端的时间戳:2012-06-17 13:33:00
4. 将现在在运行的长时间事务尽可能提交完成。
5. 复制源端的数据。
6. 将数据导入目标数据库
7. 针对这个数据，创建一个新的replicate组，add replicat rvtd,ExtTrail ./dirdat/rb, Begin 2012-06-17 13:33:00
8. 创建一个新的参数文件，然后启动新的replicat：

   replicat rvtd
   SETENV(ORACLE_HOME="/apps/opt/oracle/product/11.2.0/db_1")
   SETENV(ORACLE_SID = "tdnprdfd1")
   SETENV(NLS_LANG=AMERICAN_AMERICA.AL32UTF8)
   DBOPTIONS
   SUPPRESSTRIGGERS
   userid gg_owner@tdnprdfd1, password
   AADAAAAAAAAAAAHAJIKGFGKGRJTBJBCIZGUERJNHBFPBLCAEOBUADFWASJMJCDWEICWGBEG
   HOIRESCPA, encryptkey securekey1
   discardfile ./dirrpt/RTDNFRD.dsc, Append, megabytes 1
   handlecollisions
   assumetargetdefs
   MAP WAX_TDN.V_TAX_DETAILS, TARGET WAX_TDN.V_TAX_DETAILS;

9. 查看新repilcat文件的lag，直到出现“At EOF, no more records to process”

   GGSCI> Send replicat rvtd, GetLag

10. 关闭HandleCollisions：

    GGSCI> send replicat rvtd NoHandleCollisions

11. 如果还出现bounce process，那么把参数文件里的HandleCollisions注释掉，或删除。（以下几步把分出来的进程进行合并）
12. 停止extract（源）
13. 将注释的replicat复位。
14. 启动extract，启动原replicat，删除新的replicat
2. replicat进程停止，由于discard file满了。 Discard文件用来记录不能处理的条目，大小由MAXBYTES or MEGABYTES 选项控制。
3. 如何通过logdump和logminer来发现GGS bug。
1. 确定插入的行有没有进入trail，用logdump打开trail文件，查找“IO type insert”,
2. 同时使用logminer去挖同期的DMLs，将结果和logdump的一起比较，明显有些行没有被插入到trail。
3. 然后我们就可以向oracle support证明GGS有bug。
4. 其它配置细节：
1. 3个重要的表：
1. heartbeat table：
2. discard file：
3. exception file：
2. trail文件的大小，端口号在mgr.prm里面控制。
3. discard文件大小在replicat 参数文件里控制
4. 对所有表，一定要打开supplemental logging。
5. OGG性能：最大的问题是Lagging。
1. 硬件上：cpu，内存，Disk IO，网络总是越多越快越好。
2. Lagging：我们关心的是heartbeat lagging时间。
3. split replicat：在replicat将表按range分裂。因为replicat是一条条插入条目，相当慢，和extract只读取log文件不同。
4. 分拆extract：有时候可以分拆extract，等lagging现象消失了，再合并extract。有时候会出现读取日志争用的问题。