http://www.linuxidc.com/Linux/2015-04/115777.htm SQL> select t.addr,t.START_DATE from v$transaction t; ADDR START_DAT ---------------- --------- 0000000136AED710 14-JUL-17 SQL> select t.PREV_SQL_ID from v$session t where taddr='0000000136AED710'; PR

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

一.测试目标 疑问,OGG初始化同步表,源端抽取进程开始抽取的scn<源端事务的start_scn时,这个变化是否会同步到目标库中? 二.实验测试 如下进行测试! session 1 SQL> conn yz/yz SQL> create table t1(id int,cc_name varchar2(20)); SQL> insert into t1 values(1,'test'); 1 row created. OGG源端开始抽取t1表; GGSCI (t1 as ogg@

OGG-01027(长事务) 示例9-25: WARNING OGG-01027  Long Running Transaction: XID 82.4.242063, Items 0,  Extract YX_EXT1, Redo Thread 1, SCN 2379.2132775890 (10219859973074), Redo  Seq #5688, Redo RBA 195997712. 可以通过下面的命令寻找更详细的信息: 示例9-26: GGSCI> send extract x

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

请注意:请谨慎改动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

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

一.学习目标 有同事问OGG技术问题,OGG软件,在oracle数据库中,集成模式抽取进程REGISTER DATABASE,都做了什么操作? 有什么风险? 并且提到了一个抽取进程注册,在瞬时间并发占用了大量的进程process,并且当时某DB process剩余不足,最终导致DB的process占满,影响了DB系统! 那么带来一些疑问: 1) 集成模式抽取进程REGISTER DATABASE,做了哪些操作? 2) REGISTER DATABASE 会在数据库中产生大量的并发会话吗? 具体会

:first-child { margin-top: 0; } blockquote > :last-child { margin-bottom: 0; } img { border: 0; max-width: 100%; height: auto !important; margin: 2px 0; } table { border-collapse: collapse; border: 1px solid #bbbbbb; } td, th { padding: 4px 8px; bord

环境描述: 1.节点描述 节点 IP 节点描述 11.6.76.221 GG 抽取端 / DG 节点,数据库版本号为 Oracle-11.2.0.3,与 11.6.76.222 组成 DataGuard. 11.6.76.222 DG 节点,数据库版本号为 Oracle-11.2.0.3,与 11.6.76.221 组成 DataGuard. 192.168.87.221 GG 复制端,数据库版本号为 Oracle-11.2.0.4 2.拓扑结构   方案描述: 假设 11.6.76.221 最

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*** 症状: 若是一个客户基于少

长事务 长事务用于支持 AutoCAD 参照编辑功能,对于 ObjectARX 应用程序非常有用.这些类和函数为应用程序提供了一种方案,用于签出实体以进行编辑并将其签回其原始位置.此操作会将原始对象替换为已编辑的对象.有三种类型的长期交易结帐: 从同一图形中的普通块 从图形的外部参照 (外部参照) 从不相关的临时数据库 长事务类和函数概述 主要的长事务类和函数是 AcDbLongTransaction.class AcDbLongTransWorkSetIterator.class AcApLo

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

),value )); INSERT INTO @tab EXEC('DBCC OPENTRAN WITH TABLERESULTS'); SELECT name,CAST(value AS DATETIME) startDate,getdate() currentDate ,DATEDIFF(s,CAST(value AS DATETIME),getdate()) diffsecond FROM @tab WHERE name in ('OLDACT_STARTTIME') SELECT sp

还是有漏洞 ,万一 working.py未超时, kill_job.sh 会不会杀死别人的进程啊start.sh#!/bin/bash python working.py &python working.py &python working.py & pids=$(jobs -p)echo $pidssh kill_job.sh $pids & pids_1=$(jobs -p)echo $pids_1 for job in $pidsdo    wait $jobdone

mysql> desc information_schema.innodb_trx -> ; +----------------------------+---------------------+------+-----+---------------------+-------+ | Field | Type | Null | Key | Default | Extra | +----------------------------+---------------------+------

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

oracle最坑爹的地方:你insert   update  delete之后  或者kill死锁的时候记得一定要提交事务不然就是死锁卡在那里了 记住  kill死锁也是要提交事务的 select * from v$session where sid in (select session_id from v$locked_object) SELECT s.username,l.OBJECT_ID,l.SESSION_ID,s.SERIAL#,l.ORACLE_USERNAME,l.OS_USER