GoldenGate运维手册.doc

GOLDENGATE运维手册

2023年4月

文档修改记录
版本号
日期
说明
编写者
审核者
V1.0
2023/4
文档编写

目录

1 OGG常用监控命令 3
1.1 说明 3
1.2 启动GoldenGate进程 3
1.3 停止GoldenGate进程 4
1.4 查看整体运营情况 6
1.5 查看参数设立 7
1.6 查看进程状态 7
1.7 查看延时 8
1.8 查看记录信息 9
1.9 查看运营报告 9
2 OGG的常见运维任务指南 11
2.1 配置自动删除队列 11
2.2 配置启动MGR时自动启动Extract和Replicat进程 11
2.3 配置MGR自动重新启动Extract和Replicat进程 12
2.4 长事务管理 12
2.5 表的重新再同步（需时间窗口） 15
2.6 表的重新再同步（无需时间窗口） 15
3 数据结构变更和应用升级 17
3.1 （仅复制DML时）源端和目的端数据库增减复制表 17
3.2 （仅复制DML时）修改表结构 19
3.3 （仅复制DML时）客户应用的升级 19
3.4 配置DDL复制自动同步数据结构变更 21
(一) 是否打开DDL复制 21
(二) 打开DDL复制的环节 21
(三) DDL复制的典型配置 23
4 异常解决预案 24
4.1 网络故障 24
4.2 RAC环境下单节点失败 25
4.3 Extract进程常见异常 25
4.4 Replicat进程常见异常 26
4.5 异常解决一般环节 26
5 附录 28
5.1 Oracle GoldenGate V11.1数据复制限制 28
(四) 不支持文献等非结构化数据复制 28
(五) Oracle数据类型限制 28
(六) Oracle DML操作支持 29
(七) Oracle DDL复制限制 30
5.2 Oracle 9i中如何为超过32列的无主键表添加附加日记 31

1 OGG常用监控命令
1.1 说明
对GoldenGate实例进行监控，最简朴的办法是通过GGSCI命令行的方式进行。通过在命令行输入一系列命令，并查看返回信息，来判断GoldenGate运营情况是否正常。命令行返回的信息涉及整体概况、进程运营状态、检查点信息、参数文献配置、延时等。
除了直接通过主机登录GGSCI界面之外，也可以通过GoldenGate Director Web界面登录到每个GoldenGate实例，并运营GGSCI命令。假如客户部署了很多GoldenGate实例，假如单独登录到每个实例的GGSCI界面，会很不方便，此时建议通过GoldenGate Director Web界面，登录到每个实例，并运营命令行命令。
1.2 启动GoldenGate进程
1) 一方面以启动GoldenGate进程的系统用户（一般为oracle）登录源系统。
2) 进入GoldenGate安装目录，执行./ggsci进入命令行模式。
3) 启动源端管理进程GGSCI > start mgr
4) 同样登陆到目的端GoldenGate安装目录，执行./ggsci，然后执行GGSCI > start mgr启动管理进程。
5) 在源端执行GGSCI > start er *启动所有进程
6) 同样登录到备份端执行GGSCI > start er *启动所有进程
7) 使用GGSCI > info er * 或者 GGSCI > info <进程名>察看进程状态是否为Running（表达已经启动）。注意有的进程需要几分钟起来，请反复命令观测其启动状态。
说明：无论源还是目的，启动各extract/replicat进程前需要启动mgr进程。
start 命令的一般用法是：start <进程名称>
如：
GGSCI> start extdm 启动一个名叫extdm的进程
也可以使用通配符，如：
GGSCI> start er * 启动所有的extract和replicat进程
GGSCI> start extract *d* 启动所有的包含字符‘d’extract进程
GGSCI> start replicat rep* 启动所有以“rep“开头的replicat进程
1.3 停止GoldenGate进程
依照以下环节停止GoldenGate进程：
1) 以启动GoldenGate进程的系统用户（一般为oracle）登录源主机，进入GoldenGate安装目录执行./ggsci进入命令行管理界面
2) （本环节仅针对抽取日记的主extract进程， data pump进程和replicat进程不需要本环节）验证GoldenGate的抽取进程重起所需的日记存在，对各个主extXX进程，执行如下命令：
ggsci> info extXX, showch
…..
Read Checkpoint #1
….

Recovery Checkpoint (position of oldest unprocessed transaction in the data source):
Thread #: 1
Sequence #: 9671
RBA:
Timestamp: 2023-05-20 11:39:07.000000
SCN: 2195.
Redo File: Not available

Current Checkpoint (position of last record read in the data source):
Thread #: 1
Sequence #: 9671
RBA:
Timestamp: 2023-05-20 11:39:10.000000
SCN: 2195.
Redo File: Not Available

Read Checkpoint #2
…..

Recovery Checkpoint (position of oldest unprocessed transaction in the data source):
Thread #: 2
Sequence #: 5287
RBA:
Timestamp: 2023-05-20 11:37:42.000000
SCN: 2195.
Redo File: /dev/rredo07

Current Checkpoint (position of last record read in the data source):
Thread #: 2
Sequence #: 5287
RBA:
Timestamp: 2023-05-20 11:39:14.000000
SCN: 2195.
Redo File: /dev/rredo07

…..
一方面察看Recovery Checkpoint所需要读取的最古老日记序列号，如举例中的实例1需要日记9671及其以后所有归档日记，实例2需要序列号为5287及以后所有归档日记，确认这些归档日记存在于归档日记目录后才可以执行下一步重起。假如这些日记已经被删除，则下次重新启动需要先恢复归档日记。
注意：对于OGG 11及以后版本新增了自动缓存长交易的功能，缺省每隔4小时自动对未提交交易缓存到本地硬盘，这样只需要最多8个小时归档日记即可。但是缓存长交易操作只在extract运营时有效，停止后不会再缓存，此时所需归档日记最少为8个小时加上停机时间，一般为了保险起见建议保证重启时要保存有12个小时加上停机时间的归档日记。
3) 执行GGSCI >stop er *停止所有源进程，或者分别对各个进程执行stop <进程名>单独停止。
4) 以oracle用户登录目的系统，进入安装目录/oraclelog1/goldengate，执行./ggsci进入命令行。
5) 在目的系统执行stop er *停止复制
6) 在两端进程都已停止的情况下,如需要可通过stop mgr停止各系统内的管理进程。
类似的，stop命令具有跟start命令同样的用法。这里不再赘述。
注意，假如是只修改抽取或者复制进程参数，则不需要停止MGR。不要容易停止MGR进程，并且慎重使用通配符er *， 以免对其他复制进程导致不利影响。
1.4 查看整体运营情况
进入到GoldenGate安装目录，运营GGSCI，然后使用info all命令查看整体运营情况。如下图示：

Group表达进程的名称（MGR进程不显示名字）；Lag表达进程的延时；Status表达进程的状态。有四种状态：
STARTING: 表达正在启动过程中
RUNNING：表达进程正常运营
STOPPED：表达进程被正常关闭
ABENDED：表达进程非正常关闭，需要进一步调查因素

正常情况下，所有进程的状态应当为RUNNING，且Lag应当在一个合理的范围内。
1.5 查看参数设立
使用view params <进程名> 可以查看进程的参数设立。该命令同样支持通配符*。

1.6 查看进程状态
使用info <进程名称> 命令可以查看进程信息。可以查看到的信息涉及进程状态、checkpoint信息、延时等。如：

还可以使用info <进程名称> detail 命令查看更具体的信息。涉及所使用的trail文献，参数文献、报告文献、警告日记的位置等。如：

使用info <进程名称> showch 命令可以查看到具体的关于checkpoint的信息，用于查看GoldenGate进程解决过的事务记录。其中比较重要的是extract进程的recovery checkpoint，它表达源数据中最早的未被解决的事务；通过recovery checkpoint可以查看到该事务的redo log位于哪个日记文献以及该日记文献的序列号。所有序列号比它大的日记文献，均需要保存。

1.7 查看延时
GGSCI> lag <进程名称> 可以查看具体的延时信息。如：

此命令比用info命令查看到的延时信息更加精确。
注意，此命令只可以查看到最后一条解决过的记录的延时信息。
此命令支持通配符 *。
1.8 查看记录信息
GGSCI> stats <进程名称>,<时间频度>,table <owner name>.<table name> 可以查看进程解决的记录数。该报告会具体的列出解决的类型和记录数。如：

GGSCI> stats edr, total列出自进程启动以来解决的所有记录数。
GGSCI> stats edr, daily, table gg.test列出当天以来解决的有关gg.test表的所有记录数。
1.9 查看运营报告
GGSCI> view report <进程名称> 可以查看运营报告。如：

也可以进入到 <GoldenGate安装目录>/dirrpt/目录下，查看相应的报告文献。最新的报告总是以<进程名称>.rpt命名的。加后缀数字的报告是历史报告，数字越大相应的时间越久。如下图示：

假如进程运营时有错误，则报告文献中会涉及错误代码和具体的错误诊断信息。通过查找错误代码，可以帮助定位错误因素，解决问题。

2 OGG的常见运维任务指南
2.1 配置自动删除队列
1) 进入安装目录执行./ggsci；
2) 执行edit param mgr编辑管理进程参数，加入或修改以下行
purgeoldextracts /<goldengate安装目录>/dirdat/*, usecheckpoint, minkeepdays 7
其中，第一个参数为队列位置，*可匹配备份中心所有队列文献；
第二个参数表达是一方面要保证满足检查点需要，不能删除未解决队列；
第三个参数表达最小保存多少天，后面的数字为天数。例如，假如希望只保存队列/ggs/dirdat/xm文献3天，可以配置如下：
purgeoldextracts /ggs/dirdat/xm, usecheckpoint, minkeepdays 3
3) 停止MGR进程，修改好参数后重启该进程
GGSCI > stop mgr
输入y确认停止
GGSCI > start mgr
注：临时停止mgr进程并不影响数据复制。

2.2 配置启动MGR时自动启动Extract和Replicat进程
1) 进入安装目录执行./ggsci；
2) 执行edit param mgr编辑管理进程参数，加入以下行
AUTOSTART ER *
3) 停止MGR进程，修改好参数后重启该进程
GGSCI > stop mgr
GGSCI > start mgr
注意：一般建议不用自动启动，而是手工启动，便于观测状态验证启动是否成功，同时也便于手工修改参数。

2.3 配置MGR自动重新启动Extract和Replicat进程
GoldenGate具有自动重起extract或者replicat进程的功能，可以自动恢复如网络中断、数据库临时挂起等引起的错误，在系统恢复后自动重起相关进程，无需人工介入。
1) 进入安装目录执行ggsci进入命令行界面；
2) 执行edit param mgr编辑管理进程参数，加入以下行
AUTORESTART ER *, RETRIES 3, WAITMINUTES 5, RESETMINUTES 60
以上参数表达每5分钟尝试重新启动所有进程，共尝试三次。以后每60分钟清零，再按照每5分钟尝试一次共试3次。
3) 停止MGR进程，修改好参数后重启该进程，使修改后的参数文献生效
GGSCI > stop mgr
GGSCI > start mgr

2.4 长事务管理
在停止抽取进程前需要通过命令检查是否存在长交易，以防止下次启动无法找到归档日记：
ggsci> info extXX, showch
…..
Read Checkpoint #1
….

Recovery Checkpoint (position of oldest unprocessed transaction in the data source):
Thread #: 1
Sequence #: 9671
RBA:
Timestamp: 2023-05-20 11:39:07.000000
SCN: 2195.
Redo File: Not available

Current Checkpoint (position of last record read in the data source):
Thread #: 1
Sequence #: 9671
RBA:
Timestamp: 2023-05-20 11:39:10.000000
SCN: 2195.
Redo File: Not Available

Read Checkpoint #2
…..

Recovery Checkpoint (position of oldest unprocessed transaction in the data source):
Thread #: 2
Sequence #: 5287
RBA:
Timestamp: 2023-05-20 11:37:42.000000
SCN: 2195.
Redo File: /dev/rredo07

Current Checkpoint (position of last record read in the data source):
Thread #: 2
Sequence #: 5287
RBA:
Timestamp: 2023-05-20 11:39:14.000000
SCN: 2195.
Redo File: /dev/rredo07

…..
为了方便长交易的管理，GoldenGate提供了一些命令来查看这些长交易，可以帮助客户和应用开发商查找到相应长交易，并在GoldenGate中予以提交或者回滚。
(一) 查看长交易的方法
Ggsci> send extract <进程名> , showtrans [thread n] [count n]
其中，<进程名>为所要察看的进程名，如extsz/extxm/extjx等；
Thread n是可选的，表达只查看其中一个节点上的未提交交易；
Count n也是可选的，表达只显示n条记录。例如,查看extsz进程中节点1上最长的10个交易，可以通过下列命令：
Ggsci> send extract extsz , showtrans thread 1 count 10

输出结果是以时间降序排列的所有未提交交易列表，通过xid可以查找到相应的事务，请应用开发商和DBA帮助可以查找出未提交因素，通过数据库予以提交或者回滚后GoldenGate的checkpoint会自动向前滚动。
(二) 使用GoldenGate命令跳过或接受长交易的方法
在GoldenGate中强制提交或者回滚指定事务，可以通过以下命令（<>中的为参数）：
Ggsci> SEND EXTRACT <进程名>, SKIPTRANS <5.17.27634> THREAD <2> //跳过交易
Ggsci>SEND EXTRACT <进程名>, FORCETRANS <5.17.27634> THREAD <1> //强制认为该交易已经提交
说明：使用这些命令只会让GoldenGate进程跳过或者认为该交易已经提交，但并不改变数据库中的交易，他们依旧存在于数据库中。因此，强烈建议使用数据库中提交或者回滚交易而不是使用GoldenGate解决。
(三) 配置长交易告警
可以在extract进程中配置长交易告警，参数如下所示：
extract extsz
……
warnlongtrans 12h, checkintervals 10m
exttrail /backup/goldengate/dirdat/sz
….
以上表达GoldenGate会每隔10分钟检查一下长交易，假如有超过12个小时的长交易，GoldenGate会在根目录下的ggserr.log里面加入一条告警信息。可以通过察看ggserr.log或者在ggsci中执行view ggsevt命令查看这些告警信息。以上配置可以有助于及时发现长交易并予以解决。
说明：在OGG 11g中，extract提供了BR参数可以设立每隔一段时间（默认4小时）将长交易缓存到本地硬盘（默认dirtmp目录下），因此extract只要不断止一般需要的归档日记不超过8个小时（极限情况）。但是假如extract停掉后，便无法再自动缓存长交易，需要的归档日记就会依赖于停机时间变长。

2.5 表的重新再同步（需时间窗口）
假如是某些表由于各种因素导致两边数据不一致，需要重新进行同步，可以参照以下环节。
1) 确认需要修改的表无数据变化（假如有条件建议停止应用系统并锁定除去sys和goldengate以外的其它所有用户防止升级期间数据变化，或者锁定所要再同步的表）；
2) 重启dpe进程（为了可以对记录信息清零）；
3) 停止目的端的rep进程；
注意：环节4-6为将源端数据通过exp/imp导入到目的端，客户也可以选择其它初始化方式，比如在目的端为源端表建立dblink，然后通过create table as select from的方式初始化目的端表。
4) 在源端使用exp导出该表或者几张表数据。例如：
exp goldengate/XXXX file=nanhai.dmp tables=ctais2.SB_ZSXX grants=y
5) 通过ftp传输到目的端；
6) 在目的端，使用imp导入数据；
nohup imp goldengate/XXXXX file=nanhai.dmp fromuser=ctais2 touser=ctais2 ignore=y &
7) 假如这些表有外键，在目的端检查这些外键并严禁它们（记得维护dirsql下的严禁和启用外键的脚本SQL）；
8) 启动目的端的rep进程；
9) 使用stats mydpe命令观测data pump的记录信息，观测里面是否包含了本次重新同步表的数据变化，如确认该时段内这些表无数据变化，则重新初始化成功；否则中间也许产生反复数据，目的replicat会报错，将错误解决机制设立为reperror default,discard，等待replicat跟上后对discard中的记录进行再次验证，假如所有一致则重新初始化也算成功完毕，当然也可以另择时段对这些表重新执行初始化。
2.6 表的重新再同步（无需时间窗口）
假如是某些表由于各种因素导致两边数据不一致，需要重新进行同步，但实际业务始终24小时可用，不能提供时间窗口，则可以参照以下环节。（因较为复杂，使用需谨慎！）
1) 确认ext/dpe/rep进程均无较大延迟，否则等待追平再执行操作；
2) 停止目的端的rep进程；
注意：环节3-5为将源端数据通过exp/imp导入到目的端，客户也可以选择其它初始化方式，比如expdp/impdp。
3) 在源端获得当前的scn号。例如：
select dbms_flashback.get_system_change_number from dual;
以下以获得的scn号为1176681为例
4) 在源端使用exp导出所需重新初始化的表或者几张表数据，并且指定到刚才记下的scn号。例如：
exp <username>/<password> tables=ctais2.SB_ZSXX grants=n statistics=none triggers=n compress=n FLASHBACK_SCN=1176681
5) 通过ftp传输到目的端；
6) 在目的端，使用imp导入数据；
nohup imp goldengate/XXXXX file=nanhai.dmp fromuser=ctais2 touser=ctais2 ignore=y &
7) 假如这些表有外键，在目的端检查这些外键并严禁它们（记得维护dirsql下的严禁和启用外键的脚本SQL）；
8) 编辑目的端相应的rep参数文献，在其map里面加入一个过滤条件，只对这些重新初始化的表应用指定scn号之后的记录（一定要注意不要修改本次初始化之外的其它表，会导致数据丢失！）：
map source.mytab, target target.mytab, filter ( @GETENV ("TRANSACTION", "CSN") > 1176681 ) ;
9) 确认参数无误后，启动目的端的rep进程；
10) 使用info repxx或者lag repxx直到该进程追上，停止该进程去掉filter即可进入正常复制。

3 数据结构变更和应用升级
3.1 （仅复制DML时）源端和目的端数据库增减复制表
(一) 增长复制表
在GoldenGate的进程参数中，假如通过*来匹配所有表，因此只要符合*所匹配的条件，那么只要在源端建立了表之后GoldenGate就能自动复制，无需修改配置文献，但是需要为新增的表添加附加日记。
环节如下：
GGSCI 〉dblogin userid goldengate, password XXXXXXX
GGSCI > info trandata <schema>.<table name>
假如不是enable则需要手动加入：
GGSCI > add trandata <schema>.<table name>
注：（仅对Oracle 9i）假如该表有主键或者该表不超过32列，则显示enabled表达添加成功；假如无主键并且列超过32列，则也许出现错误显示无法添加则需要手工解决，此时请根据附录二中方法手工解决。

假如没有使用统配符，则需要在主Extract、Data Pump里面最后的table列表里加入新的复制表；在目的端replicat的map列表同样也加入该表的映射。

然后，新增表请一方面在目的端建立表结构。

假如有外键和trigger，需要在目的表临时严禁该外键和trigger，并维护在dirsql下的严禁和启用这些对象的相应脚本文献。

对于修改了文献的所有源和目的进程，均需重启进程使新的参数生效。

(二) 减少复制表
GoldenGate缺省复制所有符合通配符条件的表，假如有的表不再需要，可以在源端drop掉，然后到目的drop掉，无需对复制做任何修改。
假如其中几个表仍然存在，只是无需GoldenGate复制，则可以通过以下环节排除：
1) 在源端系统上一方面验证所需归档日记存在后通过stop extXX停止相应的extXX进程；
2) 在目的端系统上ggsci中执行stop repXX停止目的端的复制进程；
3) 在源端修改ext进程的参数文献排除所不复制的表:
Ggsci> edit param extXX
……
tableexclude ctais2.TMP_*;
tableexclude ctais2.BAK_*;
tableexclude ctais2.MLOG$_*;
tableexclude ctais2.RUPD$_*;
tableexclude ctais2.KJ_*;

tableexclude myschema.mytable;

table ctais2.*;
…….
在文献定义table的行前面加入一行“tableexclude <schema>.<tablename>;” 注意写全schema和表的名称。
注：假如是没有使用通配符，则直接注释掉该表所在的table行即可。
4) 在目的端修改rep进程参数，同样排除该表:
GGSCI>edit param repXX
在map前面加入一行：
--mapexclude CTAIS2.SHOULIXINXI
mapexclude myschema.mytable
MAP ctais2.* ,TARGET ctais2.*;
注：假如是没有使用通配符，则直接注释掉该表所在的map行即可。

5) 在目的端系统上启动复制进程 repXX
GGSCI > start repXX
6) 在源端系统上启动源端的抓取进程extXX
GGSCI > start extXX
即可进入正常复制状态。

3.2 （仅复制DML时）修改表结构
当数据库需要复制的表结构有所改变，如增长列，改变某些列的属性如长度等表结构改变后，可以按照下列环节执行：
1) 按照本文前面所述操作顺序停止源和目的端各抽取及投递进程（注意停源端抽取要验证一下归档日记是否存在防止无法重起），无需停止manager进程；
2) 修改目的表结构;
3) 修改源表结构;
4) 假如表有主键，并且本次修改未修改主键，则可以直接启动源和目的所有进程继续复制，完毕本次修改；否则，假如表无主键或者本次修改了主键则需继续执行下列环节；
ggsci> dblogin userid goldengate, password XXXXXX
ggsci> delete trandata schema.mytable
ggsci> add trandata schema.mytable
（仅对Oracle 9i）假如表超过了32列则上述操作也许会报错，此时需要手工进行解决，请参考附录二如何手动为表删除和增长附加日记。
5) 重新启动源端和目的端的抓取和复制进程。

3.3 （仅复制DML时）客户应用的升级
假如是客户的应用进行了升级，导致了源系统表的变化，在不配置DDL复制到情况下，需要对GoldenGate同步进程进行修改，可以参照以下环节。
1) 停止源和目的端各抽取及投递进程（注意停源端抽取要验证一下归档日记是否存在防止无法重起），无需停止manager进程；
2) 对源系统进行升级;
3) 在目的端将客户升级应用所创建的存储过程、表、function等操作再重新构建一遍。对业务表的增删改等DML操作不必在目的端再执行，它们会被OGG复制过去;
4) 在目的端手工严禁建立的trigger和外键，并将这些sql以及反向维护的（即重新启用trigger和外键）SQL添加到目的端OGG dirsql目录下相应的脚本文献里;
注意：在安装实行时，应当将执行的严禁trigger和外键的表放到目的dirsql下，文献名建议为disableTrigger.sql和disableFK.sql。同时，需要准备一个反向维护（即重新启用trigger和外键，建议为enableTrigger.sql和enableFK.sql）SQL，同样放置到目的端OGG的dirsql目录下，以备将来接管应用时重新启用。
5) 对于升级过程中在源端增长的表，需要为新增的表添加附加日记。环节如下：
GGSCI 〉dblogin userid goldengate, password XXXXXXX
GGSCI > info trandata <schema>.<table name>
假如不是enable则需要手动加入：
GGSCI > add trandata <schema>.<table name>
注：（仅对Oracle 9i）假如该表有主键或者该表不超过32列，则显示enabled表达添加成功；假如无主键并且列超过32列，则也许出现错误显示无法添加则需要手工解决，此时请根据附录二中方法手工解决。
6) 对于升级过程中在源端drop掉的表，GoldenGate缺省复制所有符合通配符条件的表，可以直接在目的端drop掉，无需对复制做任何修改；
7) 假如升级过程中修改了主键的表则需继续执行下列环节；
ggsci> dblogin userid goldengate, password XXXXXX
ggsci> delete trandata schema.mytable
ggsci> add trandata schema.mytable
（仅对Oracle 9i）假如表超过了32列则上述操作也许会报错，此时需要手工进行解决，请参考附录二如何手动为表删除和增长附加日记。
8) 重新启动源端和目的端的抓取和复制进程。

3.4 配置DDL复制自动同步数据结构变更
(一) 是否打开DDL复制
对于OGG的DDL复制具体限制请参考附录Error! Reference source not found.。鉴于这些限制，此外一个重要因素是DDL的trigger会对源库性能带来一定的影响，在国网原则上并不推荐DDL复制。假如有特殊理由需要打开DDL复制，可以与Oracle工程师予以协商。
(二) 打开DDL复制的环节
以下内容为配置DDL复制的环节，仅作参考，具体请参照GoldenGate的官方安装文档。
Ø （可选，但强烈建议）定期收集记录信息，提高数据字典访问速度
OGG的DDL复制需要大量访问数据字典信息，通过数据库定期收集记录信息（例如，每月一次），可以有效提高OGG DDL复制的性能。以下为一个例子:
sqlplus /nolog <<EOF
connect / as sysdba
alter session enable parallel dml;
execute dbms_stats.gather_schema_stats('CTAIS2',cascade=> TRUE);
execute dbms_stats.gather_schema_stats('SYS',cascade=> TRUE);
execute dbms_stats.gather_schema_stats('SYSTEM',cascade=> TRUE);
exit
EOF

Ø 建立OGG复制用户，或给现有用户赋权限：
CREATE USER goldengate IDENTIFIED BY goldengate DEFAULT TABLESPACE ts_ogg;
GRANT CONNECT TO goldengate;
GRANT RESOURCE TO goldengate;
grant dba to goldengate;
Ø 指定DDL对象所在的schema，这里直接建立在goldengate用户下：
Ggsci>EDIT PARAMS ./GLOBALS
GGSCHEMA goldengate
Ø 检查数据库的recyclebin参数是否已关闭：
SQL> show parameter recyclebin

NAME TYPE
------------------------------------ ---------------------------------
VALUE
------------------------------
recyclebin string
on

如不是off，需要关闭recyclebin：
alter system set recyclebin=off
Ø 建立OGG的DDL对象：

sqlplus "/ as sysdba"
SQL> @marker_setup.sql
Enter GoldenGate schema name:goldengate
SQL> @ddl_setup.sql
Enter GoldenGate schema name:goldengate
SQL> @role_setup.sql
Grant this role to each user assigned to the Extract, Replicat, GGSCI, and Manager processes, by using the following SQL command:

GRANT GGS_GGSUSER_ROLE TO <loggedUser>

where <loggedUser> is the user assigned to the GoldenGate processes.
注意这里的提醒：它需要你手工将这个GGS_GGSUSER_ROLE指定给你的extract所使用的数据库用户（即参数文献里面通过u