ogg 学习

--并发进程的数据量决定GG内存的大小，在source system端，最少需要一个Extract 进程和一个data-pump进程，在target system 端， 至少需要一个replicat 进程
--在每个GG instance 上，GGSCI 命令结构最多支持300个Extract和 replicat 并发进程，每个GG instance 需要一个Manager 进程。
--每个Extract 和 Replicat 进程大概需要25-55M的内存，根据的要根据事务的数量和事务的并发量决定
--GG 实际使用的物理内存量是由操作系统控制的，GG的cache manager 利用操作系统的memory managementfunctions 来保证GG 以持续和有效的方式来运行
  --Cache manager 保持GG 进程在global cache 的大小内工作，在需要时仅分配virtualmemory，操作完会，会释放virtual memory。 只有在不得已的情况下，才会增加cache size。
  --系统必须要有足够的swap space 来支撑GG Extract 和Replicat 进程的运行。
  --每个GG instance 的working directories 和binaries 是40M。
  --如果是集群环境上部署GG，GG binaries 和 files 需要放在共享文件系统上。
  --至少1G的空间来存放trails 文件
--为了避免trail 被其他的应用干扰，最好分配独立的disk 或者 filesystem 来存放trail 文件。 
 Trail file 里保存的是GG capture 的data。 Trail file 默认大小是10M，该大小可以进行配置，
 trail files 是类型型的，其保留策略可以通过PURGEOLDEXTRACTS 参数控制。
 
--在一个典型的GG 配置，source 会有Extract 和data-pump进程，如果trails 存储在source 本地，当网络出现故障，data-pump 进程会失败，
 但extract 进程还会继续工作，这样trails 文件会越来越大， 必须要有足够的空间来存放trails。  
 
  --如果trails 放在target 端，那么需要根据PURGEOLDEXTRACTS参数来决定所需要的磁盘空间。  
 
  --对于RAC 集群，GG 需要安装在共享设备里，这样可以从任何一个节点启动，而且当在一个节点上运行失败时，
    可以从其他的节点启动，并不需要修改配置。
  --GG 的端口，默认从7840开始
  --在Linux 32bit等系统上运行GG，需要指定LD_LIBRARY_PATH，其要包含32bit的oraclelibraries。
  --如果是Oracle 10g以后的版本，必须要在sqlnet.ora 中设置bequeath_detach=true，以使用Bequeath connection
  --GG 支持unused 列，但是该功能默认是禁用的。可以通过DBOPTIONS参数的ALLOWUNUSEDCOLUMN 选项来强制extract 生成warning.
  --GG 支持interval partitioning。
  --GG 支持virtual columns，但是不会capture virtual columns上的数据变化，因为数据库不会将virtual columns上的的信息写入log。 
    我们可以使用FETCHCOLS 选项来fetch 到virtualcolumn上的信息，但是Replicat 进程不会应用这些信息到virtual columns上，
    即使这些信息存在trail里，但是可以将这些fetch 的信息target database上的非virtualcolumn上。
  --Because of aknown issue in Oracle 10g, the Oracle recycle bin must be turned off to supportOracle GoldenGate DDL replication. 
    If the recycle bin is enabled, the Oracle GoldenGateDDL trigger session receives implicit recycle bin DDL operations 
    that cause thetrigger to fail.   
    
  --在target table上，需要禁用triggers或者cascadeconstraints，因为source 上会将这些改变同步过去，
    如果在target  端在做一次就会报错，下面的示例使整个流程：     
    
    （1） For Oracle10.2.0.5 and later patches to 10.2.0.5, and for Oracle 11.2.0.2 and later 11gR2 versions, you can use the Replicat parameter DBOPTIONS with the SUPPRESSTRIGGERS option to cause Replicat to disable the triggers during its session.
    （2） For Oracle9.2.0.7 and later, you can use the Replicat parameter DBOPTIONS with the DEFERREFCONSToption to delay the checking and enforcement of cascade update and cascadedelete constraints until the Replicat transaction commits.
    （3） For earlier Oracle versions, you must disable triggers and integrity constraints or alter themmanually to ignore the Replicat database user.


  --GG 提供了选选项自动处理triggers 或者 cascade constraints，不同的版本，方法也不一样。    
  --如果source 端的约束是deferrable（延时）的，那么target端也必须是deferrable的。
    （1）Use SQLEXEC at the root level ofthe Replicat parameter file to defer the constraints for an entire Replicatsession.
         --使用SQLEXEC设置这个Replicat session的defer 属性
      SQLEXEC (“altersession set constraint deferred”)
    （2）For Oracle 9.2.0.7 and later, youcan use the Replicat parameter DBOPTIONS with the DEFERREFCONST option to delayconstraint checking for each Replicat transaction.
          --9.2.0.7 之后可以通过DBOPTIONS参数的DEFERREFCONST选项来设置delay constraint checking。