背景描述:有时候OGG进程同步出现问题,症状某些进程起不来,而且问题一时半会儿解决不了.最简单的办法是:用数据泵初始化数据,OGG进程重建. 1.查看源端.目的端的进程状态. (作者OGG进程是正常的,假设进程是 abend ) 源端:GGSCI (11g) 1> info all Program Status Group Lag at Chkpt Time Since ChkptMANAGER RUNNING EXTRACT RUNNING DPEA 00:00:00 00:00:08 EXT

请注意:请谨慎改动Oracle GoldenGate(ogg)各个进程的读检查点和写检查点. 请确保已经 掌握 ogg 各个进程的读检查点和写检查点的详细含义. BEGIN {NOW | yyyy-mm-dd[:hh:mi:[ss[.cccccc]]] | EOF | SEQNO <sequence number>} --改动抽取进程的開始抽取点:(即:myext的读检查点) alter extract myext BEGIN yyyy-mm-dd:hh:mi:ss alter extract

-- :: INFO OGG- Positioning to (Thread ) Sequence , RBA , SCN 0.470706262. Source Context : SourceModule : [er.common] SourceID : [/scratch/aime1/adestore/views/aime1_adc4150256/oggcore/OpenSys/src/app/er/common.cpp] SourceFunction : [extract_start_p

OGG replicat 进程使用的 TCP port 来源于: TCP PORT USED BY REPLICAT PROCESSES (文档 ID 1060954.1) 适用于: Oracle GoldenGate - Version 10.4.0.12 and later Information in this document applies to any platform. ***Checked for relevance on 25-May-2012*** 症状: 若是一个客户基于少

日常运维过程中,可能发现OGG同步进程延迟很高: 本篇介绍其中的一种方式. OGG复制进程,或者说同步进程及通过解析ogg trail文件,输出dml语句,在目标库执行dml操作,那么延迟高可能性其一.执行dml操作效率太低. 本篇不考虑并发过高或其它原因. 本次只考虑是执行update or delete的时候SQL效率执行太差! 导致OGG复制进程延迟很高. GGSCI > info all Program Status Group Lag at Chkpt Time Since Chkpt

https://www.cnblogs.com/lvcha001/p/13469500.html 接前序,本次场景中有索引,但是OGG复制进程使用了低效率的索引?  类似SQL使用低效索引,如何让Oracle使用好的索引,从而加快复制进程的效率呢? 疑问? Oracle为什么有好的索引,但是还是选择不好的索引,从而造成SQL效率低下,OGG复制进程缓慢呢? 本次DB版本11g,都是CBO,基于成本进行计算. 1.重新收集统计信息,让Oracle自动选择好的索引,走好的执行计划,从而让OGG复制进

1.1现象 之前有个客户遇到一个问题,OGG同步数据链路,突然有一天网络出现问题,导致OGG投递进程无法正常投递,无法写入目标端的该文件. 猜测是由于网络丢包等原因导致文件损坏,无法正常open,read,write. 解决方法,投递进程etrollover. 本篇文档是基于这种方式测试下etrollover [测试没有完美还原网络的问题,只是对其进行了测试] 1.2测试OGG进程restart与seqno有什么关系? 1)OGG 同步表及进程参数查看SQL> select * from dd;

1.首先看看什么是OGG,以及OGG的用途       简单的来讲 Oracle Golden Gate (简称OGG)是一种基于日志的结构化数据复制备份软件,它通过解析源数据库在线日志或归档日志获得数据的增量变化,再将这些变化应用到目标数据库,从而实现源数据库与目标数据库同步.OGG可以跨越不通平台(包括不通操作系统,数据库)实现大量数据亚秒一级的实时复制,从而在可以在应急系统.在线报表.实时数据仓库供应.交易跟踪.数据同步.集中/分发.容灾.数据库升级和移植.双业务中心等多个场景下应用.同时

1.问题现象抽取进程常常running,但是没有新产生trail文件,lag比较大 GGSCI (xxxdb) > info all Program Status Group Lag at Chkpt Time Since Chkpt MANAGER RUNNING EXTRACT RUNNING EXT1 :: :: EXTRACT RUNNING PUMP1 :: :: GGSCI (xxxdb) > GGSCI (xxxdb) > info EXT1,showch EXTRACT

1.注意通过进程查找sql_id时,进程号要查询两次 2.杀进程的连接 https://www.cnblogs.com/kerrycode/p/4034231.html 参考资料 1.https://blog.csdn.net/weixin_34326179/article/details/89906712 这篇有些看不太懂 2.https://blog.csdn.net/liqfyiyi/article/details/47816147 表没有任何主键和约束,oracle默认是all colu

GGSCI (hosta) 48> view report dpfull ***********************************************************************                  Oracle GoldenGate Capture for Oracle  Version 11.2.1.0.27 19591627 OGGCORE_11.2.1.0.0OGGBP_PLATFORMS_141006.1156_FBO    Linu

前段时间生产的一个数据库的ogg进程挂了快半个月才被发现,已经起不来了,只有重新初始化再同步.因此很有必要监控下ogg的进程,这里给大家介绍如何使用zabbix监控oracle的ogg的进程.思路就是利用oracle用户去查ogg的相关状态,并把状态写入一个临时文件,供zabbix用户访问.如果ogg状态都是RUNNING,那么该文件应该是个空文件,如果有任何一个进程stopped或abended,那么这个文件就非空了,通过设置触发器判断这个文件内容的长度是否大于0来判断ogg的状态. 监控wi

清理归档日志 ogg使用需要开启归档日志,归档日志会随着时间的推移逐渐增多,占满空间,导致应用无法正常运行. 如果归档日志满了会报错 ORA-00257:archiver error解决办法 检查flash recovery area的使用情况 select * from V$FLASH_RECOVERY_AREA_USAGE; 解决办法:使用rman ,采用定时任务,定时清理. 定时任务脚本: OracleArchLogClear.bat D:\app\Administrator\produc

昨天突然接到消息说有一个线上的ogg出现了问题,看是否能修复,由于ogg以前玩的少,所以就加急搞了个测试环境,练习了一把 环境 db1,db2(单实例)ip: 1*,1*sid: orcl,ogg1os: centos 6.5,centos 6.5oracle version: 11.2.0.4,11.2.0.4 1 --可以创建ogg用户,也可以使用oracle用户 useradd -u 2100 -g oinstall -G dba oggpasswd ogg [ogg@DSI ~]$ vi

Golden Gate(简称OGG)提供异构环境下交易数据的实时捕捉.变换.投递. OGG支持的异构环境有: OGG的特性: 对生产系统影响小:实时读取交易日志,以低资源占用实现大交易量数据实时复制 以交易为单位复制,保证交易一致性:只同步已提交的数据 高性能 智能的交易重组和操作合并 使用数据库本地接口访问 并行处理体系 灵活的拓扑结构:支持一对一.一对多.多对一.多对多和双向复制等 支持数据过滤和转换 可以自定义基于表和行的过滤规则. 可以对实时数据执行灵活影射和变换. 提供数据压缩和加密:

OGG学习笔记03-单向复制简单故障处理 环境:参考:OGG学习笔记02-单向复制配置实例 实验目的:了解OGG简单故障的基本处理思路. 1. 故障现象 故障现象:启动OGG源端的extract进程,data pump进程,一段时间后发现进程均被终止. GGSCI (oradb30) 1> info all Program Status Group Lag at Chkpt Time Since Chkpt MANAGER RUNNING EXTRACT ABENDED LPJY1 00:00:

OGG学习笔记04-OGG复制部署快速参考 源端:Oracle 10.2.0.5 RAC + ASM 节点1 Public IP地址:192.168.1.27 目标端:Oracle 10.2.0.5 IP地址:192.168.1.30 操作目标:将源端数据库业务用户jy下两张表ogg同步到目标端数据库业务用户ludan下. 在源端配置OGG extract.data pump进程:数据初始化:目标端配置OGG replicat进程. 本文假设两端的OGG软件和环境变量已配置完成,即操作系统ogg

首先,我们来看两个OGG同步中可能的问题: l oracle在线日志包含已提交的和未提交的事务,但OGG只会将已提交的事务写入到队列文件.因此,针对未提交的事务,特别是未提交的长事务,OGG会怎样处理呢? l 有些长事务是在批处理作业中,需要几个小时才能执行完成,比如晚上跑批的作业.OGG在解析过程中,会从这些事务一执行就开始读取在线日志,但这些事务可能会持续很久,这期间,在线日志可能会切换到归档日志,同时这期间也会有其它事务在执行和提交,如果长事务一直未提交,归档日志又因为定期的rman备份而

出处:https://www.cnblogs.com/qiumingcheng/p/5435907.html Golden Gate(简称OGG)提供异构环境下交易数据的实时捕捉.变换.投递. OGG支持的异构环境有: OGG的特性: 对生产系统影响小:实时读取交易日志,以低资源占用实现大交易量数据实时复制 以交易为单位复制,保证交易一致性:只同步已提交的数据 高性能 智能的交易重组和操作合并 使用数据库本地接口访问 并行处理体系 灵活的拓扑结构:支持一对一.一对多.多对一.多对多和双向复制等

数据同步报错: 2017-07-03 12:44:36 ERROR OGG-01163 Oracle GoldenGate Delivery for Oracle, rora_t1.prm: Bad column length (343) specified for column BQJL in table CLINICS.ZY_NURSING, maximum allowable length is 300. 2017-07-03 12:44:36 ERROR OGG-01668 Oracle