Oracle&GoldenGate学习之Goldengate介绍
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
Goldengate介绍
GoldenGate
TDM（交易数据管理）软件是一种基于日志的结构化数据复制软件，它通过解析源数据库在线日志或归档日志获得数据的增删改变化，再将这些变化应用到目标数据库，实现源数据库与目标数据库同步、双活。GoldenGate
软件可以在异构的IT基础结构（包括几乎所有常用操作系统平台和数据库平台）之间实现大量数据亚秒一级的实时复制，其复制过程简图如下：
利用捕捉进程(Capture Process)在源系统端读取Online Redo Log或Archive
Log，然后进行解析，只提取其中数据的变化如增、删、改操作，并将相关信息转换为GoldenGate
TDM自定义的中间格式存放在队列文件中。再利用传送进程将队列文件通过TCP/IP传送到目标系统。捕捉进程在每次读完log中的数据变化并在数据传送到目标系统后，会写检查点，记录当前完成捕捉的log位置，检查点的存在可以使捕捉进程在中止并恢复后可从检查点位置继续复制；
&& 目标系统接受数据变化并缓存到GoldenGate
TDM队列当中，队列为一系列临时存储数据变化的文件，等待投递进程读取数据；
&&& GoldenGate
TDM投递进程从队列中读取数据变化并创建对应的SQL语句，通过数据库的本地接口执行，提交到数据库成功后更新自己的检查点，记录已经完成复制的位置，数据的复制过程最终完成。
由此可见，GoldenGate
TDM是一种基于软件的数据复制方式，它从数据库的日志解析数据的变化（数据量只有日志的四分之一左右）。GoldenGate
TDM将数据变化转化为自己的格式，直接通过TCP/IP网络传输，无需依赖于数据库自身的传递方式，而且可以通过高达9:1的压缩率对数据进行压缩，可以大大降低带宽需求。在目标端，GoldenGate
TDM可以通过交易重组，分批加载等技术手段大大加快数据投递的速度和效率，降低目标系统的资源占用，可以在亚秒级实现大量数据的复制，并且目标端数据库是活动的
GoldenGate TDM提供了灵活的应用方案，基于其先进、灵活的技术架构可以根据用户需求组成各种拓扑结构，如图所示：
GoldenGate TDM 可以提供可靠的数据复制，主要体现在下面三点： &
保证事务一致性
GoldenGate TDM
在灾备数据库应用复制数据库交易的顺序与在生产中心数据库上的顺序相同，并且按照相同的事务环境提交，确保在目标系统上数据的完整性和读一致性，为实时查询和事务处理创造了条件。
检查点机制保障数据无丢失
GoldenGate
TDM的抽取和复制进程使用检查点机制记录完成复制的位置。对于抽取进程，其检查点记录当前已经抽取日志的位置和写队列文件的位置；对于投递进程，其检查点记录当前读取队列文件的位置。检查点机制可以保证在系统、网络或GoldenGate
TDM进程故障重启后数据无丢失。
可靠的数据传输机制
GoldenGate TDM
用应答机制传输交易数据，只有在得到确认消息后才认为数据传输完成，否则将自动重新传输数据，从而保证了抽取出的所有数据都能发送到备份端。数据传输过程中支持128位加密和数据压缩功能。
GoldenGate TDM 可以提供可靠的数据复制，主要体现在下面三点： &
保证事务一致性
GoldenGate TDM
在灾备数据库应用复制数据库交易的顺序与在生产中心数据库上的顺序相同，并且按照相同的事务环境提交，确保在目标系统上数据的完整性和读一致性，为实时查询和事务处理创造了条件。
检查点机制保障数据无丢失
GoldenGate
TDM的抽取和复制进程使用检查点机制记录完成复制的位置。对于抽取进程，其检查点记录当前已经抽取日志的位置和写队列文件的位置；对于投递进程，其检查点记录当前读取队列文件的位置。检查点机制可以保证在系统、网络或GoldenGate
TDM进程故障重启后数据无丢失。
可靠的数据传输机制
GoldenGate TDM
用应答机制传输交易数据，只有在得到确认消息后才认为数据传输完成，否则将自动重新传输数据，从而保证了抽取出的所有数据都能发送到备份端。数据传输过程中支持128位加密和数据压缩功能。
公司的GoldenGate产品，可以在异构的IT基础结构之间实现大量数据的秒一级的数据捕捉、转换和投递。GoldenGate可以支持几乎所有常用操作系统如和数据库平台，如下表所示：
MS NT, 2000, XP, Linux, Sun Solaris, HP-UX, IBM
AIX, HP NonStop, TRU64, IBM z/OS，OS/390
Oracle, DB2, MS SQL Server, MySQL, Enscribe,
SQL/MP, SQL/MX, Sybase, Teradata, 其他ODBC 兼容数据库
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。oracle reproduced（12）
转自：.cn/s/blog_a32eff.html
日志或归档日志获得数据的增删改变化，再将这些变化应用到目标数据库，实现源数据库与目标数据库同步、双活。GoldenGate TDM 软件可以在异构的IT基础结构（包括几乎所有常用操作系统平台和数据库平台）之间实现大量数据亚秒一级的实时复制，其复制过程简图如下：
如上图所示，的数据复制过程如下：
&&&&利用捕捉进程(Capture Process)在源系统端读取Online Redo Log或Archive Log，然后进行解析，只提取其中数据的变化如增、删、改操作，并将相关信息转换为GoldenGate TDM自定义的中间格式存放在队列文件中。再利用传送进程将队列文件通过TCP/IP传送到目标系统。捕捉进程在每次读完log中的数据变化并在数据传送到目标系统后，会写检查点，记录当前完成捕捉的log位置，检查点的存在可以使捕捉进程在中止并恢复后可从检查点位置继续复制；
&&&目标系统接受数据变化并缓存到GoldenGate TDM队列当中，队列为一系列临时存储数据变化的文件，等待投递进程读取数据；
&&&&GoldenGate TDM投递进程从队列中读取数据变化并创建对应的SQL语句，通过数据库的本地接口执行，提交到数据库成功后更新自己的检查点，记录已经完成复制的位置，数据的复制过程最终完成。
&&&&由此可见，GoldenGate TDM是一种基于软件的数据复制方式，它从数据库的日志解析数据的变化（数据量只有日志的四分之一左右）。GoldenGate TDM将数据变化转化为自己的格式，直接通过TCP/IP网络传输，无需依赖于数据库自身的传递方式，而且可以通过高达9:1的压缩率对数据进行压缩，可以大大降低带宽需求。在目标端，GoldenGate TDM可以通过交易重组，分批加载等技术手段大大加快数据投递的速度和效率，降低目标系统的资源占用，可以在亚秒级实现大量数据的复制，并且目标端数据库是活动的
GoldenGate TDM提供了灵活的应用方案，基于其先进、灵活的技术架构可以根据用户需求组成各种拓扑结构，如图所示：
GoldenGate TDM 可以提供可靠的数据复制，主要体现在下面三点： &
保证事务一致性
GoldenGate TDM 在灾备数据库应用复制数据库交易的顺序与在生产中心数据库上的顺序相同，并且按照相同的事务环境提交，确保在目标系统上数据的完整性和读一致性，为实时查询和事务处理创造了条件。 &
检查点机制保障数据无丢失
GoldenGate TDM的抽取和复制进程使用检查点机制记录完成复制的位置。对于抽取进程，其检查点记录当前已经抽取日志的位置和写队列文件的位置；对于投递进程，其检查点记录当前读取队列文件的位置。检查点机制可以保证在系统、网络或GoldenGate TDM进程故障重启后数据无丢失。
可靠的数据传输机制
GoldenGate TDM 用应答机制传输交易数据，只有在得到确认消息后才认为数据传输完成，否则将自动重新传输数据，从而保证了抽取出的所有数据都能发送到备份端。数据传输过程中支持128位加密和数据压缩功能。
GoldenGate TDM 可以提供可靠的数据复制，主要体现在下面三点： &
保证事务一致性
GoldenGate TDM 在灾备数据库应用复制数据库交易的顺序与在生产中心数据库上的顺序相同，并且按照相同的事务环境提交，确保在目标系统上数据的完整性和读一致性，为实时查询和事务处理创造了条件。 &
检查点机制保障数据无丢失
GoldenGate TDM的抽取和复制进程使用检查点机制记录完成复制的位置。对于抽取进程，其检查点记录当前已经抽取日志的位置和写队列文件的位置；对于投递进程，其检查点记录当前读取队列文件的位置。检查点机制可以保证在系统、网络或GoldenGate TDM进程故障重启后数据无丢失。
可靠的数据传输机制
GoldenGate TDM 用应答机制传输交易数据，只有在得到确认消息后才认为数据传输完成，否则将自动重新传输数据，从而保证了抽取出的所有数据都能发送到备份端。数据传输过程中支持128位加密和数据压缩功能。
Oracle 公司的GoldenGate产品，可以在异构的IT基础结构之间实现大量数据的秒一级的数据捕捉、转换和投递。GoldenGate可以支持几乎所有常用操作系统如和数据库平台，如下表所示：
MS NT, 2000, XP, Linux, Sun Solaris, HP-UX, IBM AIX, HP NonStop, TRU64, IBM z/OS，OS/390
Oracle, DB2, MS SQL Server, MySQL, Enscribe, SQL/MP, SQL/MX, Sybase, Teradata, 其他ODBC 兼容数据库
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：46225次
积分：1138
积分：1138
排名：千里之外
原创：66篇
转载：13篇
(1)(2)(1)(7)(10)(5)(6)(9)(24)(7)(3)(4)Oracle GoldenGate简介_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
Oracle GoldenGate简介
上传于||文档简介
&&O​r​a​c​l​e​ ​G​o​l​d​e​n​G​a​t​e​ ​(​O​G​G​)​简​介​和​环​境​搭​建
阅读已结束，如果下载本文需要使用1下载券
想免费下载本文？
下载文档到电脑，查找使用更方便
还剩16页未读，继续阅读
你可能喜欢Goldengate升级之目标端（replicat端）升级
要升级replicat端的原因为：目标端OGG软件版本与源端OGG软件版本不同，在实际生产应用中，经常发现replicat端事务丢失的情况，所以，需要将目标端的OGG软件升级为与源端OGG相同软件版本。
1、升级前环境情况
源端OGG版本11.2.1.0.1
目标端OGG版本11.1.1.1.2
升级前，为了解决源端、目标端OGG版本不一致不能正常同步的问题，在源端抽取Tail file格式时，加了format release 11.1的格式转换命令，在extract与data pump进程中均配置，其配置方式如下：
EXTTRAIL ./dirdat/tr, format release 11.1
2、升级目标
将目标端OGG版本从11.1.0.2升级到与源端一致的11.2.0.1版本
3、升级前准备
3.1 停止源端的extract和datapump进程
GGSCI&stop exttr
GGSCI&stop dpetr
3.2 停止目标端的replicat和mgr进程
GGSCI&stop reptr
GGSCI&stop mgr
3.3 去除extract和datapump进程中的format release参数
因为在extract与datadump进程中都配置有formatrelease 11.1关键字，在目标端升级后，该配置需要取消，但是，取消该配置，并不只是从配置文件中删除这么简单的事，还需要对进程做ETROLLOVER操作，否则进程启动时，会报如下错误：
ERROR OGG-01416 File ./dirdat/tr000008, with format RELEASE 10.4/11.1, does not match
current format specification of RELEASE 11.2.Modify the parameter file to specify format RELEASE 10.4/11.1
or issueETROLLOVER prior to restart.
操作方法：在OGG中以edit paramsextract_name和edit params datadump_name的方式进入进行修改（具体操作：略）。
3.4 对extract与datadump进程做ETROLLOVER操作
因为extract与datadump都修改了format release信息，所以，都需要做ETROLLOVER操作
GGSCI&alter extract exttrETROLLOVER
GGSCI&alter extract dpetrETROLLOVER
3.5 修改源端datapump进程的EXTSEQNO号和EXTRBA号
因为源端的extract-exttr进程执行ETROLLOVER操作后，进程的extseqno和extrba号被重置至下一个extseqno号的第0号extrba，而datapump并不知道extract进程发生了这个变化，仍然守望在extract ETROLLOVER前的extseqno和extrba号上，永远也等不到这个extseqno上有新的RBA变化，造成就无法将extract新抽取到的数据，传递到目标端去。
所以，在extract进程ETROLLOVER后，需要使用&Alterextract group_name EXTSEQNO X, EXTRBA 0&的命令，重置checkpoint位置，datadump进程才能正常的将数据继续传递到远端。
3.5.1 记录下exttr进程ETROLLOVER后的extseqno和extrba号
GGSCI& info exttr, detail
GGSCI (server1) 140& info exttr, detail
EXTRACT EXTTR Initialized
13:02 Status STOPPED
Checkpoint Lag 00:00:00 (updated 00:00:27 ago)
Log Read Checkpoint
13:18:27 Seqno 365, RBA
SCN 0.726669)
Target Extract Trails:
Remote Trail Name Seqno RBA Max MB
./dirdat/tr 4 0 100
Extract Source Begin End
3.5.2 修改datadump进程的extseqno和extrba号
GGSCI&Alter extract dpetr EXTSEQNO 4,EXTRBA 0
3.6 查出datadump进程ETROLLOVER后的Target ExtractTrails的extseqno和extrba号
GGSCI (server1) 160& info dpetr, detail
EXTRACT DPETR Initialized
13:03 Status STOPPED
Checkpoint Lag 00:00:00 (updated 00:02:10 ago)
Log Read Checkpoint File ./dirdat/tr000003
13:18:18.000000 RBA
Target Extract Trails:
Remote Trail Name Seqno RBA Max MB
./dirdat/tr 4 0 100
3.7 备份目标端的OGG目录
#cp &ra /u01/ogg /u01/ogg_backup
3.8 记录下目标端replicat的checkpoint信息
GGSCI (server2) 1& info reptr, showch
REPLICAT REPTR Last Started
13:03 Status STOPPED
Checkpoint Lag 00:00:00 (updated 00:10:36 ago)
Log Read Checkpoint File ./dirdat/tr000003
13:18:16.296427 RBA
Current Checkpoint Detail:
Read Checkpoint #1
GGS Log Trail
Startup Checkpoint (starting position in the data source):
Sequence #: 0
Timestamp: Not Available
Extract Trail: ./dirdat/tr
Current Checkpoint (position of last record read in the data source):
Sequence #: 3
Timestamp:
13:18:16.296427
Extract Trail: ./dirdat/tr
Current Checkpoint为 Sequence #: 3 RBA:
4、OGG软件升级
4.1 将新版OGG 11.2.1.0.1软件复制到原旧版OGG目录下
$ cp ogg112101_fbo_ggs__x64_ora11g_64bit.zip/u01/ogg
4.2 删除OGG目录下的fbo_ggs_Linux_x64_ora11g_64bit.tar文件
fbo_ggs_Linux_x64_ora11g_64bit.tar文件是旧版OGG安装时解压出来的tar文件，新版OGG软件unzip解压时，也会生成此文件，当然也可以使用unzip解压时的覆盖替代手工删除
$rm fbo_ggs_Linux_x64_ora11g_64bit.tar
4.3 在原版OGG目录中安装（解压）新版OGG软件
$unzip ogg112101_fbo_ggs_Linux_x64_ora11g_64bit.zip
$tar xvf fbo_ggs_Linux_x64_ora11g_64bit.tar
4.4 验证升级成功情况
[oracle@server2 u01]$ cd $OGG
[oracle@server2 ogg]$ ./ggsci
Oracle GoldenGate Command Interpreter for Oracle
Version 11.2.1.0.1 OGGCORE_11.2.1.0.1_PLATFORMS_0_FBO
Linux, x64, 64bit (optimized), Oracle 11g on Apr 23 :14
Copyright (C) , Oracle and/or its affiliates. All rights reserved.
GGSCI (server2) 1&
从这里看到，OGG软件版本已经升级至11.2.1.0.1
5、验证升级后replicat的checkpoint是否为一致
5.1 查看升级后replicat的checkpoint是否与升级前一致
GGSCI (server2) 46& info reptr, detail
REPLICAT REPTR Last Started
13:03 Status STOPPED
Checkpoint Lag 00:00:00 (updated 00:12:58 ago)
Log Read Checkpoint File ./dirdat/tr000003
13:18:16.296427 RBA
Extract Source Begin End
./dirdat/tr000003 * Initialized *
./dirdat/tr000000 * Initialized * First Record
Current directory /u01/ogg
Report file /u01/ogg/dirrpt/REPTR.rpt
Parameter file /u01/ogg/dirprm/reptr.prm
Checkpoint file /u01/ogg/dirchk/REPTR.cpr
Checkpoint table GOLDENGATE.CHECKPOINT_REPTR_01
Process file /u01/ogg/dirpcs/REPTR.pcr
Stdout file /u01/ogg/dirout/REPTR.out
Error log /u01/ogg/ggserr.log
Current Checkpoint 跟升级前一样，仍为Sequence #: 3 RBA: ，进一步证明升级成功。
6、验证升级后可正常同步数据场景准备
6.1 先记录下源端、目标端数据量为一致
（生产库环境此步可以跳过，因为生产库的表受业务的操作数据不断发生变化，本案例为创建一张专用用于测试升级的表进行测试）
SQL& select count(*) from goldengate.ogg_
----------
SQL& select count(*) from goldengate.ogg_
----------
源端和目标端数据量一致。
6.2 在目标端replicat进程启动前在源端删除部分数据
SQL& delete goldengate.ogg_upg where rownum &1000001;
1000000 rows deleted.
SQL& select count(*) from goldengate.ogg_
----------
7、重建目标端replicat进程
重建replicat进程的原因：ogg_11.1.1.1.2每条replicat进程只有CHECKPOINT一张表，而ogg_11.2.x.x.1每条replicat进程有CHECKPOINT,CHECKPOINT_LOX两张表，所以，如果在升级后，直接启动replicat进程，是无法启动的，会报如下错误：
ERROR OGG-00665 OCI Error describe for query (status = 942-ORA-00942: table or view does not exist), SQL&SELECT a.current_dir, a.seqno, a.rba, a.audit_ts, a.log_csn, a.log_xid, a.log_cmplt_csn, a.log_cmplt_xids, b.log_cmplt_xids FROM GOLDENGATE.CHECKPOINT_REPTR_01 a LEFT JOIN GOLDENGATE.CHECKPOINT_REPTR_01_lox b ON a.group_name = b.group_name AND a.group_key = b.group_key AND a.log_cmplt_csn = b.log_cmplt_csn WHERE a.group_name = 'REPTR' AND a.group_key = &.
05:12:59 ERROR OGG-01668 PROCESS ABENDING.
提示表不存在，这张表是指：GOLDENGATE.CHECKPOINT_REPTR_01_lox表（CHECKPOINT_LOX表），重建replicat的最终目的是让在重建进程时，自动将两张checkpoint表都自动创建起来。
7.1 删除replicat进程与checkpoint表
GGSCI&dblogin userid goldengate,password goldengate
GGSCI&delete replicat reptr
GGSCI&delete checkpointtable GOLDENGATE.CHECKPOINT_REPTR_01
7.2 重新建立replicat进程
GGSCI&dbloginuserid goldengate, password goldengate
GGSCI&add checkpointtable goldengate.checkpoint_reptr_01
GGSCI&add replicat reptr, exttrail ./dirdat/tr,checkpointtable goldengate.checkpoint_reptr_01
到这一步，replicat启动后，还是无法继续应用源端投递过来的trail的，因为源端的datapump进程做过ETROLLOVER了，所以需要手工修改replicat的sequence#和RBA号到与datadump进程的target extract trails中的seqno和RBA一致。
7.3 修改目标端replicat的extseqno和extrba号
根据上面一步，查出的源端的datadump进程的remotetrail file的seqno号和RBA，决定replicat要更改的extseqno和extrba号
GGSCI (server2) 37& Alter replicat reptrEXTSEQNO 4, EXTRBA 0
7.4 查看新建立的replicat进程的SEQ#和RBA号
GGSCI(server2) 27& info reptr, showch
GGSCI (server2) 3& info reptr, showch
REPLICAT REPTR Initialized
13:39 Status STOPPED
Checkpoint Lag 00:00:00 (updated 00:00:07 ago)
Log Read Checkpoint File ./dirdat/tr000004
First Record RBA 0
Current Checkpoint Detail:
Read Checkpoint #1
GGS Log Trail
Startup Checkpoint (starting position in the data source):
Sequence #: 4
Timestamp: Not Available
Extract Trail: ./dirdat/tr
Current Checkpoint (position of last record read in the data source):
Sequence #: 4
Timestamp: Not Available
Extract Trail: ./dirdat/tr
Start checkpoint 的sequence#和RBA号已经通过手工，都定位到了源端ETROLLOVER后的状态
Current checkpoint的sequence#和RBA号已经通过手工，也都定位到了源端ETROLLOVER后的状态
7.5 查看checkpoint表的数据内容
SQL&select * from goldengate.checkpoint_reptr_01;
No rows selected
SQL&select * from goldengate.checkpoint_reptr_01_
No rows selected
这时，两个checkpoint表中的数据还是空的，待replicat启动运行后，进行状态信息就会写入到checkpoint表中
8、启动源端和目标端进程
8.1 启动目标端的replicat和mgr进程
GGSCI&start mgr
GGSCI&start reptr
8.2 启动源端的datapump进程
GGSCI&start dpetr
9、验证是否能继续同步数据
此步最重要的，是要验证在升级时间时，源端所做的操作能否同步到目标库中来。本案例在升级过程中，对goldengate.ogg_upg表删除了1000000行数据。
9.1 查看目标端goldengate.ogg_upg表的数据变化
SQL& select count(*) from goldengate.ogg_
----------
SQL& select count(*) from goldengate.ogg_
----------
9.2 目标端查看checkpoint表内check状态
select * from goldengate.checkpoint_reptr_01
-------------------------------------------------
4 5-01-30 13:55:59.5/1/30 13:36:43
14:01:01 /u01/ogg .16.33 7.16.20512 1
从上面两步看来，升级后replicat正常的，接着升级前的状态在同步数据。
(window.slotbydup=window.slotbydup || []).push({
id: '2467140',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467141',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467143',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467148',
container: s,
size: '1000,90',
display: 'inlay-fix'}