My Technology Workstation

OGG-01705 Input checkpoint position 68047491 for input trail file './dirdat/et001646' is greater than the size of the file (68047295).

一.说明虽然goldengate在MGR进程中提供了系统自动清理DDL源数据(ggs_marker/ggs_ddl_hist)的功能，但是有的OGG版本的这两个功能会引起一些BUG。并且按照ORACLE官方的说法也是建议手工对这些表备份后再进行清理，所以此处对手工清理方式进行说明。二.清理步骤:2.1.清理一个月以前的历时数据delete from ggs_

一.说明在Goldengate的环境中我们可以从以下几个方面对OGG的性能进行优化:1.操作系统层面I/O、参数等;2.网络层面;3.数据库或应用层面;4.OGG的进程配置层面;二.优化方式2.1.进程拆分实现负载均衡因为12c以前的goldengate各个进程处trail文件是串行(12c开始就是并行的了)处理的，所以当源端一个大事务提

作用范围:Replicat前提条件:使用GG自动初始化的时候用(如果使用RMAN/EXPDP等方式初始化建议不要使用此参数，容易确保数据完整性)说明:handlecollisions参数实际工作原理如下:1).当向目标端更新一条记录的时候(trail记录包含所有列,否则会出现丢失列而abend)，如果目标端不存在此where条件中的值则rep将trail中的记录转换为ins

一.基础环境==================================================1.环境说明--------------------------------------------------     10gRAC+ASM on Linux5.5(初始安装在node102上，后续调整成集群管理的HA模式)     10gSingle+FS on

--------------------------------------------------1.基础环境--------------------------------------------------1).已有能进行单向复制DDL的OGG2).目标端安装11g单机软件3).停掉目标端的rep进程-->源端Pmp-->目标端mgr(确保源端的keep时间长一点)4

一.主要作用从Oracle官方文档中看来，CACHEMGR参数主要用于控制存放未提交事务的虚拟内存(virtual memory应该是指的swap/paging space空间)和临时磁盘空间。所有的数据存放在叫做global cache(在报告中显示的是super pool)的虚拟内存池中，当数据库接收到commit/rollback之后这些cache里面的内容才会写到trail文件中。gl

一.基础环境检查1.1.平台检查确认操作系统版本已经通过官方认证；GG软件位数需要和DB位数一致1.2.操作系统检查1.2.1.检查内存OGG每个实例最多支持5000个并发链路，每个进程至少需要25-55MB的内存。OGG会自动根据实际需求进行内存分配(大事务多可能会占用更多内存)；详细内存管理参照Cache Manager(CACHEMGR)

一.适用场景因某种特殊原因导致目标端确定的某个/某几个表的数据和源端不一致，我们需要重新对这些表进行初始化，如果整个schema重新初始化工作量过大的情况。本文章使用的重新初始化的原理参照(OGG Troubleshooting官方文档中out of sycn部分)，实现原理为：1).目标端数据不一致后将不一致的表从原有进程中拆分出来;2).基于SCN对该表单独建立re

一.背景:客户工程师提出要求，希望将位于测试环境数据库的director repository迁移到比较稳定的生产环境。希望我们提供相关方案并进行迁移。二.迁移方案2.1.迁移数据库后修改WLS配置1).停掉director server2).expdp迁移director repository数据;3).重启director server并

一.概述Oracle提供了很多工具供我们用于监控OGG的进程状态，优化OGG的性能及问题处理。主要包含以下工具:1).GGSCI命令行;2).OGG trace参数;3).OGG报告和日志;4).OGG Director;5).操作系统日志;6).OGG logdump工具7).MOS文档二.工具详解:2.1.GGSCI命令行:我

一.概要前段时间,一个朋友问我关于goldengate中的Lag的问题。因涉及到Lag的详细行程过程，而我一直觉得Lag就是：本进程处理一条记录的时间点和前一个进程处理该记录时的时间点的差距，因为一般情况下都是目标端的REP进程出现LAG的机会比较大，平时也更加侧重于如何去诊断LAG和优化，所以当纠结一些详细原因的时候就卡住了(到底是不是当前处理时间和源库产生的时间)。那既然要更加明确

一.原理概述1.1.框架说明:Goldengate实例可以通过Monitor对mgr,ext,rep,dp进程进行监控，监控原理为:被监控进程周期性更新监控点(比如:status,lag,checkpoint等)。MGR进程则将这些监控信息通过Monitor的agent将信息发送出去到Monitor Server。一个Monitor Server可以最多监控20个OGG实例，每个OGG

一.背景说明2014/10/26, 在家和QQ群里面的兄弟们探讨同一个数据库中有两个相同文件名的数据文件(最终确认是因为文件命里面有空格引起的)的时候对goldengate表空间进行了下线然后添加数据文件的动作(当然是加不上的啦!)。 在对标空间进行上线的时候发现数据库一直报错：SQL> alter tablespace goldengate online;alter

Goldengate handlecollisions引起的数据重复

1.OGG-01296WARNING OGG-01154 Oracle GoldenGate Delivery for Oracle, rep_hr.prm: SQL error 1403 mapping HR.EMPLOYEES to HR.EMPLOYEES.WARNING OGG-01003 Oracle GoldenGate Delivery for Oracle, rep_h