Oracle GoldenGate 支持 从SAP  HANA database抽取或者复制数据到SAP HANA database 吗？ 来源于： Does Oracle GoldenGate Support Replication to / from SAP - HANA database (文档 ID 1413202.1) 适用于： Oracle GoldenGate - Version 10.4.0.19 and later Information in this document applies to any platform. 目的： 验证Oracle GoldenGate对 SAP  HANA database 的支持情况 问题与答案 ~~~ Question: Does Oracle GoldenGate support replication, i.e. capture or delivery for SAP-HANA database Answer: Oracle GoldenGate does not support replication to SAP-HANA database Although at this point, SAP HANA is not supported as a native target, GoldenGate offers Robust Java Adapter framework to build any custom adapters that are not available out of the box with GoldenGate. In fact the Adapter API is leveraged internally as well for supporting targets such as JMS and Big Data Targets. The API itself is very simplistic and only basic Java skills are needed to build a custom adapter. In addition to the API, packaged examples are available to kick start the initiative. ~~~

Oracle GoldenGate 怎么在源头的传输进程和目的端的server/collector进程之间分配 端口？ 来源于： How Does GoldenGate Allocates Ports between Source Extract Pump and Target Server/Collector? (文档 ID 965270.1) 适用于： Oracle GoldenGate - Version 9.5.0.0 and later Information in this document applies to any platform. Checked for relevance on 24-May-2012 解决方案： 背景： 通常，OGG 通过TCP/IP来将OGG trail 从源头move到目的端。 抽取进程（通常叫做Extract Pump） 读取本地的trail file ，并通过网络发送数据给目标主机上的server进程（即:collector） 配置如下： Extract Pump进程的参数文件中有rmthost参数，类似如下： RMTHOST , MGRPORT Example: RMTHOST REMOTESERVER, MGRPORT 7809  为了控制目的端主机上的端口使用，通常使用manager 进程的DYNAMICPORTLIST 参数，该参数限制OGG使用的端口的范围 例如： PORT 7809 DYNAMICPORTLIST 8000-8010 那么，OGG怎么在源头的传输进程和目的端的server/collector进程之间分配 端口呢？ 当Extract Pump进程使用 rmthost参数中指定的端口号（RMTHOST REMOTESERVER, MGRPORT 7809）来启动到目的端的链路时， manager进程会运行在目的端主机上，并监听在7809端口上。 The target manager will start a collector and pass to the collector if configured the DYAMICPORTLIST range of ports.  If this is not configured random ports will be used. 如上两句不翻译了，主要是pass to不知道该翻译成啥比较合适。。。 目的端的manager进程回到7809端口上监听。 Collector进程将会按顺序尝试使用（称之为:TCP/IP BIND）每个port，直到collector发现有一个port端口能工作。 Collector进程将会与Extract pump进行联系，并指示Extract pump 进程使用这个端口进行通信。 注意： 你可以使用如下命令来检查目的端上的端口使用情况： GGSCI > SEND MGR GETPORTINFO.  在OGG version 11之前，manager进程搜索server上的一个端口，而不是从server上定位一个可用的端口.

OGG replicat 进程使用的 TCP 端口 来源于： 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 症状： 若是一个客户基于少量的（a small number of）collector进程的考虑配置了少量的端口号，ogg的manager进程可能会用尽可用的端口，因为replicat进程也会使用端口。 新的extract 连接将会fail，会报各种的TCP 错误，比如“no ports available”，比如“connection refused” 原因： 典型的，客户通过manager 参数DYNAMICPORTLIST指派了一个端口的访问， 客户希望这些端口给manager进程使用，以便当extract请求时，建立server.exe collector进程 OGG的replicat进程也会从这个端口范围中消耗端口--这是没有在文档上记载的。 因此，如果客户基于少量的collector进程的考虑配置了少量的端口号，ogg的manager进程可能会用尽可用的端口，因为replicat进程也会使用端口。 客户应该总是配置比理解上需要的更多的端口。 由于 孤儿端口 的可能性，manager进程应该被分配更多的端口--这个端口数量要比collector进程+ replicat进程的总数还要多。 解决方案： 配置DYNAMICPORTLIST 加上更多可用的端口。

OGG的集成捕捉模式支持Oracle database标准版么？ 来源于： Does OGG 11.2.1 Integrated Capture Work with Oracle Database Standard Edition? (文档 ID 1431938.1) 适用于： Oracle GoldenGate - Version 11.2.1.0.0 and later Information in this document applies to any platform. 目标： Oracle GoldenGate 11.2.1.0引入了一个新特性：集成捕捉模式（Integrated Capture Mode）。 该模式可以与Oracle database的 log mining server集成在一起，从本地或者 downstream mining database 中，以逻辑改变记录（logical change records，即：LCR)的方式接收变化数据 OGG的集成捕捉模式支持Oracle database标准版么？ 解决方案： OGG集成捕捉模式可以与Oracle database标准版一起工作，前提是：INTEGRATEDPARAMS parameter PARALLELISM 必须设置为0或者1（默认值是2） 但是，集成捕捉模式支持诸如压缩，高级安全选项，XA分布式事务等等特性，这些特性在Oracle database标准版里边是不适用的。 但是，对于任何支持的Oracle database 版本，OGG 11.2.1.0抽取进程可以被配置直接从redo log 中捕捉。 传统的方式被称之为经典捕捉模式 对于Oracle 数据库标准版，经典捕捉模式是被推荐的。

Oracle Restart可以用来给Oracle GoldenGate  做 High Availability 使用么？ 来源于： Can Oracle Restart be used with Oracle GoldenGate for High Availability ? (文档 ID 2025185.1) 适用于： Oracle GoldenGate - Version 11.2.1.0.20 and later Information in this document applies to any platform. 目标： Oracle Restart可以用来给Oracle GoldenGate  做 High Availability 使用么？ 解决方案： Oracle Restart不支持Oracle GoldenGate，因为在Oracle Restart 架构内，Oracle Restart不允许  GoldenGate作为一个受管理的组件。

GoldenGate 对IBM大型机 z/OS 2.1 和DB2 v11的支持 来源于： GoldenGate Support for z/OS 2.1 and DB2 v11 (文档 ID 1941364.1) 适用于： Oracle GoldenGate - Version 12.1.2.1.2 and later Information in this document applies to any platform. 目标： 需要知道是否有一个GoldenGate版本能支持 IBM大型机 z/OS 2.1 上的DB2 v11？ 解决方案： 当前有GoldenGate版本能支持z/OS 2.1 ~~~ - 11.2..1.0.23: 18794269 ORACLE GOLDENGATE V11.2.1.0.23 FOR IBM DB2 9.1 ON Z/OS (Patch) - 12.1.2.0.1: 18468962 ORACLE GOLDENGATE PATCH FOR MLR 19137739: IBM Z/OS : DB2 9.1: OGG 12.1.2.0.1 OGG 12.1.2.1.4 to support DB2 Versions 9.1 and 11.1 is now available from My Oracle Support - Patch 20474612: Oracle GoldenGate v12.1.2.1.4 for FOR IBM DB2 9.1 ON Z/OS Patch 20737854: Patch for BLR 20660883: IBM Z/OS : DB2 11.1: OGG 12.1.2.1.4 ~~~ GoldenGate认证信息可以在如下网址中查到： [http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html](http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html)

来源于： Does OGG support Invisible Indexes in Oracle 11g db (文档 ID 1515952.1) ### APPLIES TO: Oracle GoldenGate - Version 11.2.1.0.1 and later Information in this document applies to any platform. ### GOAL A new feature in Oracle 11g allows the creation of "invisible" indexes which means they are indexes that we can choose when to expose to the optimizer when generating SQL plans.  Current versions of OGG do not support invisible indexes.  So if only an invisible unique index is defined on a table, OGG chooses not to see the unique index and treats this table as not having any unique index defined. ### FIX It is supported in OGG version 11.2.1.0.5 and higher. Support was added in following bug fix. Bug 14099231 - SUPPORT ORACLE INVISIBLE INDEXES The fix can be backported if needed. There is also a work-around of using KEYCOLS to force the selection of invisible index columns. ### REFERENCES [BUG:15856355](https://support.oracle.com/epmos/faces/BugDisplay?parent=DOCUMENT&sourceId=1515952.1&id=15856355) - ORACLE GOLDENGATE V11.2.1.0.4_02 FOR ORACLE 11G ON LINUX X64

### APPLIES TO: Management Pack for Oracle GoldenGate - Version: 1.0.0.0 - Release: 1.0 Information in this document applies to any platform. Activity Console ### SOLUTION **Question** The Director Server is installed, but how do I know which database and user is being used? **Answer** The Director Server installer (install anywhere) outputs a file named /<director install>/bin/db-config-ia.cds which contains information including the database driver, database name, and user. This does not necessarily mean that the installer was successful. If there were issues, such as a bad user or database name, or insufficient creditials to create tables, then the Director will default to the Hypersonic database.

Does Oracle GoldenGate requires Xlc.Adt.Include 8.0 (文档 ID 1147116.1) ### APPLIES TO: Oracle GoldenGate - Version: 10.4.0.0 and later   [Release: 10.4.0 and later ] Information in this document applies to any platform. ### GOAL Does Oracle GoldenGate requires Xlc.Adt.Include 8.0? ### SOLUTION In README.txt, it is written that the following as the minimum runtime libraries required  Some versions of AIX 5.3 do not have the latest runtime libraries required by Oracle GoldenGate. Please make sure the following minimums are met:  xlC.adt.include 8.0 COMMITTED C Set ++ Application* xlC.aix50.rte  8.0 COMMITTED XL C/C++ Runtime for AIX 5.3 xlC.msg.en_US.rte 8.0 COMMITTED XL C/C++ Runtime xlC.rte 8.0 COMMITTED XL C/C++ Runtime* The list above is not correct. Library xlC.adt.include 8.0 is not required. The rest of the other three runtime libraries are still required for Oracle GoldenGate to function normally.  The following link has the required runtime libraries http://www-01.ibm.com/support/docview.wss?rs=2239&uid=swg24019829 Necessary changes will be made to README.txt.

在OGG中跳过Oracle DB 长事务的命令 ~~~ GGSCI (hostdb2) 2> SEND EXTRACT extxxx , SKIPTRANS 10.40.1122351 THREAD 1 Sending SKIPTRANS request to EXTRACT EXTXXX ... Are you sure you sure you want to skip transaction [XID 10.40.1122351, Redo Thread 1, Start Time 2015-06-05:13:03:48, SCN 3035.1404832899 (13036630576259)]? (y/n)y Sending SKIPTRANS request to EXTRACT EXTXXX ... Transaction [XID 10.40.1122351, Redo Thread 1, Start Time 2015-06-05:13:03:48, SCN 3035.1404832899 (13036630576259)] skipped. GGSCI (hostdb2) 4> ~~~ 10.40.1122351这个长事务的来源： ~~~ GGSCI (hostdb2) 1> send extxxx, showtrans Sending SHOWTRANS request to EXTRACT EXTXXX ... Oldest redo log files necessary to restart Extract are: Redo Thread 1, Redo Log Sequence Number 14727, SCN 3388.1470752302 (14552819951150), RBA 429154320 Redo Thread 2, Redo Log Sequence Number 10195, SCN 3388.1471271618 (14552820470466), RBA 327736336 ------------------------------------------------------------ XID: 7.8.447821 ------>这就是事务的id。 Items: 268257 ------->注意这个数字，当send extxxx, showtrans再次执行一遍时，该值在不断减小，这说明extxxx进程在干活。 Extract: EXTXXX Redo Thread: 1 Start Time: 2015-11-24:02:00:13 SCN: 3388.1470752302 (14552819951150) Redo Seq: 14727 Redo RBA: 429154320 Status: Running --->>>>>>额外注意：Select * from gv$transaction where xidusn=7 and XIDSLOT =8 and XIDSQN =447821;居然查不到记录。 --->>>>>>额外注意：死事务查询（如下）也查询不到死事务： --->>>>>> select ktuxeusn USN, ktuxeslt Slot, ktuxesqn Seq, ktuxesta State, ktuxesiz Undo --->>>>>> from x$ktuxe --->>>>>> where ktuxesta <> 'INACTIVE' and ktuxecfl like '%DEAD%' order by ktuxesiz asc; ------------------------------------------------------------ XID: 23.11.535573 Items: 0 Extract: EXTXXX Redo Thread: 2 Start Time: 2015-11-24:08:37:32 SCN: 3388.1475780146 (14552824978994) Redo Seq: 10215 Redo RBA: 189050896 Status: Running ~~~ 最后，有人会问,你这样跳过事务，那复制就不完整了啊。其实，针对这一点，我认为复制还是完整的（即：数据复制是完整的） ~~~ 1. Select * from gv$transaction where xidusn=7 and XIDSLOT =8 and XIDSQN =447821;居然查不到记录。 ~~~ 从这一点来说，2个db实例中均没有此事务的记录。 ---引出了另外一点，db实例中都没有该事务，你用ogg命令的查询为啥能查到？---我猜测是ogg的命令可能借助了OGG的BR。 ~~~ 2.如下命令的结果 GGSCI (hostdb2) 1> send extxxx, status Sending STATUS request to EXTRACT EXTXXX ... EXTRACT EXTXXX (PID 23683) Current status: Recovery complete: Processing data with empty data queue--->注意此处的空队列。 Current read positions: Redo thread #: 1 Sequence #: 14736 RBA: 119375680 Timestamp: 2015-11-24 04:34:52.000000 SCN: 3388.1471781460 Redo thread #: 2 Sequence #: 10214 RBA: 381925240 Timestamp: 2015-11-24 05:00:17.000000 SCN: 3388.1471790456 Current write position: Sequence #: 268963 RBA: 5568905 Timestamp: 2015-11-26 09:20:12.756297 Extract Trail: /u02/ggs/dirdat/aa ~~~

查找OGG trail file中是否存在相关记录的命令 如下是查找一个insert into USERA.TABLE1是否存在于OGG源头的trail file中， 同时，本文也可以视为OGG 目的端rep进程报 SQL error 1403 mapping USERA.TABLE1 to USERA.TABLE1的问题诊断思路。 如下诊断用到了ogg自带的logdump工具 拿USERA.TABLE1表来说，我们通过查询 rep进程的丢弃文件(dsc文件，也就是discard文件，位于$OGG_HOME/dirrpt下)中该表的报错信息，如下： 确认有如下记录（仅仅拿一个记录为例）肯定是没有insert到数据库中的， USERA.TABLE1 表中id=53874605的记录, 然后在源头数据库上查出ID,之所以查询出ID是因为在logdump的输出中，这个值比较直观： ~~~ select ID from USERA.TABLE1 where id=53874605 ~~~ 获得id的值： ~~~ WW151124160530101510740104947088A ~~~ 以此值到源头trailfile 中进行搜索，注意如下的搜索方法： ~~~ oracle@host2:/gg/ggs$ logudump Oracle GoldenGate Log File Dump Utility for Oracle Version 11.2.1.0.27 19591627 20148126 Copyright (C) 1995, 2014, Oracle and/or its affiliates. All rights reserved. Logdump 644 >open /gg/ggs/dirdat/sd021739 ghdr on detail on detail data ggstoken on usertoken on ggstokens detail filter include FILENAME USERA.TABLE1 filter include STRING 'WW1511241605301015107401049470856A' filter match all show filter---->此处是命令的结尾,然后敲回车即可 Current LogTrail is /gg/ggs/dirdat/sd021739 Logdump 645 >Logdump 646 >Logdump 647 >Logdump 648 >Logdump 649 >Logdump 650 >Logdump 651 >Logdump 652 >Logdump 653 >Logdump 654 > Data filters are ENABLED Include Match ALL Filename-0 : USERA.TABLE1 String-0 : (34), CaseSensitive 4648 3135 3131 3234 3136 3035 3330 3130 3135 3130 | WW151124160530101510 3734 3031 3034 3934 3730 3835 3641 | 7401049470888A Exclude Match ANY Logdump 655 >n Scanned 10000 records, RBA 5742984, 2015/11/14 03:43:16.000.000 Scanned 20000 records, RBA 11498403, 2015/11/14 03:48:10.000.000 Scanned 30000 records, RBA 17287262, 2015/11/14 03:53:32.000.000 Scanned 40000 records, RBA 22759004, 2015/11/14 03:58:06.000.000 Scanned 50000 records, RBA 28498882, 2015/11/14 04:03:16.000.000 Scanned 60000 records, RBA 34247854, 2015/11/14 04:07:40.000.000 Scanned 70000 records, RBA 40072024, 2015/11/14 04:12:40.000.000 Scanned 80000 records, RBA 45960655, 2015/11/14 04:16:56.000.000 Filtering suppressed 87002 records Logdump 656 >nt LogTrail /gg/ggs/dirdat/sd021739 closed Current LogTrail is /gg/ggs/dirdat/sd021740 Logdump 657 >n Scanned 10000 records, RBA 5833212, 2015/11/14 04:24:45.000.000 Scanned 20000 records, RBA 11584249, 2015/11/14 04:29:13.000.000 Scanned 30000 records, RBA 17067992, 2015/11/14 04:32:52.000.000 Scanned 40000 records, RBA 22918136, 2015/11/14 04:36:57.000.000 Scanned 50000 records, RBA 28712547, 2015/11/14 04:41:22.000.000 Scanned 60000 records, RBA 34567058, 2015/11/14 04:46:24.000.000 Scanned 70000 records, RBA 40357769, 2015/11/14 04:51:08.000.000 Scanned 80000 records, RBA 46148680, 2015/11/14 04:55:49.000.000 Filtering suppressed 86515 records Logdump 658 >exit ~~~ 如上的结果显示：USERA.TABLE1 中  id=53874605的记录不在源头的trail file中，也就是说： 问题得到定性：ogg源头的抽取进程漏抽数据。 插曲： 凭什么就定位到/gg/ggs/dirdat/sd021739这个源头的trail file？要知道rep进程的丢弃文件中只会显示目的端的trailfile号。熟悉ogg的人都知道，源头trail file 号与目的端trail file号没有任何的等价关系，也没有加1 或者减1的关系。 这里就需要去看源头dp（datapump进程）的rpt文件，根据大体的时间，获得如下信息： ~~~ 2015-11-14 03:09:57 INFO OGG-01026 Rolling over remote file /ogg/ggs/dirdat/pa059719. Switching to next trail file /gg/ggs/dirdat/sd021739 at 2015-11-14 03:37:59 due to EOF, with current RBA 49999824 Opened trail file /gg/ggs/dirdat/sd021739 at 2015-11-14 03:37:59 2015-11-14 03:56:52 INFO OGG-01026 Rolling over remote file /ogg/ggs/dirdat/pa059720. Switching to next trail file /gg/ggs/dirdat/sd021740 at 2015-11-14 04:20:08 due to EOF, with current RBA 49999149 Opened trail file /gg/ggs/dirdat/sd021740 at 2015-11-14 04:20:08 ~~~ 上面的/gg/ggs/dirdat/sd021739就是源头的trail文件号。  

故障： 昨天客户处的ogg rep进程报ora-01403,然后update语句执行失败。 环境是：11.2.0.3.8 rac，asm方式，ogg是11.2.1.0.27 分析： 1.logdump分析目的端的trail file， 发现pkgid='4605'的insert记录不在目的端的trail file中 2.logdump分析源头上的trail file， 发现pkgid='4605'的insert记录不在源头的trail file中 3.至此，问题得到定性：ogg源头的抽取进程漏抽数据。 4.检查ogg源头的抽取进程的rpt文件， ~~~ 2015-11-23 3:40:16 WARNING OGG-01027 Long Running Transaction: XID 8.2.3069, Items 0, Extract EXTXXX, Redo Thread 2, SCN 17.3644768588 (76659212620), Redo Seq #3153, Redo RBA 434248208. 2015-11-23 3:45:16 WARNING OGG-01027 Long Running Transaction: XID 8.2.3069, Items 0, Extract EXTXXX, Redo Thread 2, SCN 17.3644768588 (76659212620), Redo Seq #3153, Redo RBA 434248208. 2015-11-23 3:50:16 WARNING OGG-01027 Long Running Transaction: XID 8.2.3069, Items 0, Extract EXTXXX, Redo Thread 2, SCN 17.3644768588 (76659212620), Redo Seq #3153, Redo RBA 434248208. 2015-11-23 3:55:16 WARNING OGG-01027 Long Running Transaction: XID 8.2.3069, Items 0, Extract EXTXXX, Redo Thread 2, SCN 17.3644768588 (76659212620), Redo Seq #3153, Redo RBA 434248208. 2015-11-23 4:00:16 WARNING OGG-01027 Long Running Transaction: XID 8.2.3069, Items 0, Extract EXTXXX, Redo Thread 2, SCN 17.3644768588 (76659212620), Redo Seq #3153, Redo RBA 434248208. 2015-11-23 4:02:53 WARNING OGG-00723 Record with class# 78, slt# 8, at seqno 3546, rba 334954000 SCN 18.56689670 (77366100998) has secondary transaction ID that is duplicate of existing open uncommitted transaction. 2015-11-23 4:02:53 WARNING OGG-00715 [Thread #2] Purging transaction (transaction id: 31.8.122377, start time: 2015-11-24 13:57:04, start seqno: 3546, start RBA: 318146576). 2015-11-23 4:02:53 WARNING OGG-00712 Updating I/O checkpoint after purging orphaned transactions on thread 2 with current position (Seq#: 3546, RBA: 334957552). ~~~ 重点是最后3行的信息（前5行的信息都是长事务的报警），以最后3行的信息去mos搜索，发现如下的mos文章: ~~~ GG Extract Report Shows "Purging Transaction", WARNING OGG-00723, OGG-00715, Updating I/O Checkpoint after Purging Orphaned Transactions, Has Secondary Transaction ID That Is Duplicate of Existing Open Uncommitted Transaction (文档 ID 1458472.1) Classic Extract reports false redo corruption errors when using the DBLOGREADER interface (文档 ID 2014521.1) Replicat abends due to a record missed by an extract (文档 ID 1990385.1) GoldenGate Replication On RAC (文档 ID 2079091.1) ~~~ 如上文章说的是有个ogg的隐含参数TRANLOGOPTIONS _DISABLESTREAMLINEDDBLOGREADER 该隐含参数的作用如下： ~~~ This parameter will force DBLOGREADER api check the NAB flag of the redo log before switching, thus eliminate the chance of switching to the new log file prematurely. This parameter has become default from V12.1.2.1.0 and up. Note: The parameter _DISABLESTREAMLINEDDBLOGREADER is available only from v11.2.1.0.26 onwards ~~~ 于是，就在ogg源头的抽取进程中添加了这个隐含参数（加在了TRANLOGOPTIONS DBLOGREADER下面一行），重启了ogg源头的抽取进程。 继续观察运行情况。

> 原文出处：[Oracle GoldenGate](http://blog.csdn.net/column/details/oracle-goldengate.html) >作者：[msdnchina](http://blog.csdn.net/msdnchina) **本系列文章经作者授权在看云整理发布，未经作者允许，请勿转载！** # Oracle GoldenGate > Oracle GoldenGate是Oracle公司的一款逻辑复制软件,用于不同操作系统的不同数据库之间的数据同步