golden gate的DDL配置

DDL复制的配置

1. 目前只支持oracle和teradata的ddl复制
2. oracle能复制除了系统对象之外的所有对象
3. 两种配置方法：
   1. 基于trigger的DDL：对于生产库有一定影响。
      1. 原理：
         1. 源库建立一个oracle全库级别的trigger捕捉DDL操作到中间表。
         2. extract读取中间表的DDL语句并且与DML语句根据csn排序。
         3. 目标端重现该DDL操作sql语句。
      2. 特点：
         1. DDL和DML复制原理不同：
         2. DDL复制基于Trigger，DML复制基于日志，两者复制机理不同，它们之间的数据捕捉是没有联系的，只是在主extract进程中通过scn号按照发生的顺序进行组装，保证DDL操作和DML操作按照其原来的顺序执行。
         3. DDL和DML复制互相独立：DDL的复制Trigger建立之后，无论DML复制是否运行，该Trigger一直在发生作用，捕捉DDL的sql语句到中间表。因此，DML复制的启停并不影响DDL的捕获；DDL Trigger的启用和停止并不影响DML的复制，只是该Trigger被禁止后不再抓取DDL操作；DDL和DML之间除了在extract组装时靠scn排序产生次序关系，没有其它任何联系。
         4. DDL复制只是简单的sql复制。抓取sql扔到目标端重新执行一遍而已。
         5. 打开DDL复制能够自动创建每次补丁新建和修改的对象，并自动维护对于的附加日志，无需人工介入，减少人工工作量。
      3. 使用原则：
         1. 两端必须是oracle数据库：不支持standby db的ddl抽取。
         2. 支持双向复制DDL （只是支持2个节点）
         3. 两端表结构保持一致;(replicat:ASSUMETARGETDEFS)
         4. 不支持DDL transform（map和filter支持）
         5. DDL语句小于2M大小；
         6. pump进程不负责任任何map和filter，使用passthru
         7. 数据库每天的日子量不宜过大：100g以下；过大会影响性能。
         8. 应用系统在数据库中不能有频繁的DDL操作，在erp系统里面，如频繁建立中间表等操作，这个时候性能也被极大影响。
      4. 默认：
         1. 默认情况下：extract是关闭DDL的，而data pump进程和replicat默认是打开的。所以只需要在extract进程中配置DDL复制就可以了。但是建议在replicat中配置DDL相关属性；
         2. replicat进程默认是所有DDL都做复制，如果有多个replicat进程在跑，那必须在每个replicat进行配置，否则会引起重复复制。
         3. goldengate用户和oracle数据库自带的用户的DDL操作不会被复制。
         4. 当开启full ddl（all scope）支持时，不需要在参数文件中使用gettruncates参数。
      5. DDL复制范围界定：
         1. ALL:表示复制所有的DDL操作，所有源库产生的ddl都会被放到队列当中。
         2. MAPPED:表示只复制在后面所有table参数指定的表，所相关联的对象，如索引，列的变化等，如果要复制新建的表，那么这些表必须显示列在table语句里，或者符合table中使用匹配的条件。
         3. unmapped：表示只复制不在table范围内的表的相关的DDL。
         4. Other：该范围表示无关的DDL操作：例如对数据库本身，用户，表空间，数据文件的操作。一般实际中不使用。
         5. OPTYPE：操作类型：比如：create，alter
         6. OBJTYPE:对象范围：如table或index
         7. OBJNAME：对象名：
         8. INSTR：关键字的范围
      6. 实际例子

         DDL &
         
         INCLUDE MAPPED OBJTYPE 'table' & --$符号是转行符号，可以降低出错率。
         
         INCLUDE MAPPED OBJTYPE 'index'
         
         ddloptions addtrandata, nocrossrename
         
         table abc.*
         
         
         
         --为了降低出错率，建议只复制map范围内的表和索引等主要对象；
         
         --如果要复制新建表，该表必须在后面table指定范围内（一般用×）
         
         --trandata：自动更新附加日志，也可以用add schematrandata
         
         DDL [{INCLUDE | EXCLUDE}]
         
         [, MAPPED | UNMAPPED | OTHER | ALL]
         
         [, OPTYPE <type>]
         
         [, OBJNAME "<name>" ]
         
         [, INSTR '<string>' ]

      7. 基于trigger的几个小问题：
         1. 数据库(源库)如果是10g，一定需要关闭recycle bin。避免隐形的ddl的抽取，可能会出现两次的操作，11g以后不需要，原理改变。
         2. goldengate需要独立的表空间：不能共享。
         3. 执行ddl_setup.sql之前，需要明确授权：create table, create sequence,即使有DBA权限也不行。
         4. 大致步骤：marker_setup -- DDL setup -- role setup -- enable DDL trigger
      8. 几个特例说明：
         1. 和目标数据库一致性有关的测试：
            1. create job不支持
            2. create trigger是可以复制的，且enable状态，所以必须手工设置为disable或者replicat参数；
            3. create tablespace是可以复制的，可以支持复制到不同文件目录；
            4. CTAS语句的复制：最终结果按照本地的数据来（如：create table xx as select * from dba_objects;)
            5. rename t1 to t2 会被转换成alter table t1 rename to t2 (view report rep1)
            6. flashback table to scn ---可以支持复制
            7. flashback table to before drop --不支持复制
   2. Native DLL（通过logminer server进行日志解析 – ogg12c + integrated extract +db11204及以上）：从日志里面进行解析。
      1. 版本要求：OGG12c, db11204,以上；compatible设置11.2.0.4或以上；downstream模式下，sourcedb也要满足以上要求。
      2. 集成抽取模式
      3. 参数不变

12c复制的新特性

truncate复制

sequence复制的配置

压缩配置

加密配置

TDE透明技术加密的列的抽取