重庆分公司
重庆分公司，新征程启航
为企业提供网站建设、域名注册、服务器等服务
OGG运维手册
GOLDENGATE运维手册
公司主营业务：做网站、成都网站建设、移动网站开发等业务。帮助企业客户真正实现互联网宣传，提高企业的竞争能力。成都创新互联是一支青春激扬、勤奋敬业、活力青春激扬、勤奋敬业、活力澎湃、和谐高效的团队。公司秉承以“开放、自由、严谨、自律”为核心的企业文化，感谢他们对我们的高要求，感谢他们从不同领域给我们带来的挑战，让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。成都创新互联推出石龙免费做网站回馈大家。
OGG常用监控命令
说明
对GoldenGate实例进行监控，最简单的办法是通过GGSCI命令行的方式进行。通过在命令行输入一系列命令，并查看返回信息，来判断GoldenGate运行情况是否正常。命令行返回的信息包括整体概况、进程运行状态、检查点信息、参数文件配置、延时等。
除了直接通过主机登录GGSCI界面之外，也可以通过GoldenGate Director Web界面登录到每个GoldenGate实例，并运行GGSCI命令。假如客户部署了很多GoldenGate实例，如果单独登录到每个实例的GGSCI界面，会很不方便，此时建议通过GoldenGate Director Web界面，登录到每个实例，并运行命令行命令。
启动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进程
停止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: 239077904
Timestamp: 2008-05-20 11:39:07.000000
SCN: 2195.1048654191
Redo File: Not available
Current Checkpoint (position of last record read in the data source):
Thread #: 1
Sequence #: 9671
RBA: 239377476
Timestamp: 2008-05-20 11:39:10.000000
SCN: 2195.1048654339
Redo File: Not Available
Read Checkpoint #2
…..
Recovery Checkpoint (position of oldest unprocessed transaction in the data source):
Thread #: 2
Sequence #: 5287
RBA: 131154160
Timestamp: 2008-05-20 11:37:42.000000
SCN: 2195.1048640151
Redo File: /dev/rredo07
Current Checkpoint (position of last record read in the data source):
Thread #: 2
Sequence #: 5287
RBA: 138594492
Timestamp: 2008-05-20 11:39:14.000000
SCN: 2195.1048654739
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 *， 以免对其他复制进程造成不利影响。
查看整体运行情况
进入到GoldenGate安装目录，运行GGSCI，然后使用info all命令查看整体运行情况。如下图示：
wpsBA38.tmp
Group表示进程的名称（MGR进程不显示名字）；Lag表示进程的延时；Status表示进程的状态。有四种状态：
STARTING: 表示正在启动过程中
RUNNING：表示进程正常运行
STOPPED：表示进程被正常关闭
ABENDED：表示进程非正常关闭，需要进一步调查原因
正常情况下，所有进程的状态应该为RUNNING，且Lag应该在一个合理的范围内。
查看参数设置
使用view params <进程名> 可以查看进程的参数设置。该命令同样支持通配符*。
wpsBA39.tmp
查看进程状态
使用info <进程名称> 命令可以查看进程信息。可以查看到的信息包括进程状态、checkpoint信息、延时等。如：
wpsBA3A.tmp
还可以使用info <进程名称> detail 命令查看更详细的信息。包括所使用的trail文件，参数文件、报告文件、警告日志的位置等。如：
wpsBA4B.tmp
使用info <进程名称> showch 命令可以查看到详细的关于checkpoint的信息，用于查看GoldenGate进程处理过的事务记录。其中比较重要的是extract进程的recovery checkpoint，它表示源数据中最早的未被处理的事务；通过recovery checkpoint可以查看到该事务的redo log位于哪个日志文件以及该日志文件的序列号。所有序列号比它大的日志文件，均需要保留。
wpsBA4C.tmp
查看延时
GGSCI> lag <进程名称> 可以查看详细的延时信息。如：
wpsBA4D.tmp
此命令比用info命令查看到的延时信息更加精确。
注意，此命令只能够查看到最后一条处理过的记录的延时信息。
此命令支持通配符 *。
查看统计信息
GGSCI> stats <进程名称>,<时间频度>,table . 可以查看进程处理的记录数。该报告会详细的列出处理的类型和记录数。如：
wpsBA4E.tmp
GGSCI> stats edr, total列出自进程启动以来处理的所有记录数。
GGSCI> stats edr, daily, table gg.test列出当天以来处理的有关gg.test表的所有记录数。
查看运行报告
GGSCI> view report <进程名称> 可以查看运行报告。如：
wpsBA4F.tmp
也可以进入到
wpsBA60.tmp
如果进程运行时有错误，则报告文件中会包括错误代码和详细的错误诊断信息。通过查找错误代码，可以帮助定位错误原因，解决问题。
OGG的常见运维任务指南
配置自动删除队列
1) 进入安装目录执行./ggsci；
2) 执行edit param mgr编辑管理进程参数，加入或修改以下行
purgeoldextracts /
其中，第一个参数为队列位置，*可匹配备份中心所有队列文件；
第二个参数表示是首先要保证满足检查点需要，不能删除未处理队列；
第三个参数表示最小保留多少天，后面的数字为天数。例如，如果希望只保留队列/ggs/dirdat/xm文件3天，可以配置如下：
purgeoldextracts /ggs/dirdat/xm, usecheckpoint, minkeepdays 3
3) 停止MGR进程，修改好参数后重启该进程
GGSCI > stop mgr
输入y确认停止
GGSCI > start mgr
注：临时停止mgr进程并不影响数据复制。
配置启动MGR时自动启动Extract和Replicat进程
1) 进入安装目录执行./ggsci；
2) 执行edit param mgr编辑管理进程参数，加入以下行
AUTOSTART ER *
3) 停止MGR进程，修改好参数后重启该进程
GGSCI > stop mgr
GGSCI > start mgr
注意：一般建议不用自动启动，而是手工启动，便于观察状态验证启动是否成功，同时也便于手工修改参数。
配置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
长事务管理
在停止抽取进程前需要通过命令检查是否存在长交易，以防止下次启动无法找到归档日志：
ggsci> info extXX, showch
…..
Read Checkpoint #1
….
Recovery Checkpoint (position of oldest unprocessed transaction in the data source):
Thread #: 1
Sequence #: 9671
RBA: 239077904
Timestamp: 2008-05-20 11:39:07.000000
SCN: 2195.1048654191
Redo File: Not available
Current Checkpoint (position of last record read in the data source):
Thread #: 1
Sequence #: 9671
RBA: 239377476
Timestamp: 2008-05-20 11:39:10.000000
SCN: 2195.1048654339
Redo File: Not Available
Read Checkpoint #2
…..
Recovery Checkpoint (position of oldest unprocessed transaction in the data source):
Thread #: 2
Sequence #: 5287
RBA: 131154160
Timestamp: 2008-05-20 11:37:42.000000
SCN: 2195.1048640151
Redo File: /dev/rredo07
Current Checkpoint (position of last record read in the data source):
Thread #: 2
Sequence #: 5287
RBA: 138594492
Timestamp: 2008-05-20 11:39:14.000000
SCN: 2195.1048654739
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停掉后，便无法再自动缓存长交易，需要的归档日志就会依赖于停机时间变长。
表的重新再同步（需时间窗口）
如果是某些表由于各种原因造成两边数据不一致，需要重新进行同步，可以参照以下步骤。
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中的记录进行再次验证，如果全部一致则重新初始化也算成功完成，当然也可以另择时段对这些表重新执行初始化。
表的重新再同步（无需时间窗口）
如果是某些表由于各种原因造成两边数据不一致，需要重新进行同步，但实际业务始终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 / 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即可进入正常复制。
数据结构变更和应用升级
（仅复制DML时）源端和目标端数据库增减复制表
(一) 增加复制表
在GoldenGate的进程参数中，如果通过*来匹配所有表，因此只要符合*所匹配的条件，那么只要在源端建立了表之后GoldenGate就能自动复制，无需修改配置文件，但是需要为新增的表添加附加日志。
步骤如下：
GGSCI 〉dblogin userid goldengate, password XXXXXXX
GGSCI > info trandata .
如果不是enable则需要手动加入：
GGSCI > add trandata .
注：（仅对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和表的名称。
注：如果是没有使用通配符，则直接注释掉该表所在的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
即可进入正常复制状态。
（仅复制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) 重新启动源端和目标端的抓取和复制进程。
（仅复制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 .
如果不是enable则需要手动加入：
GGSCI > add trandata .
注：（仅对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) 重新启动源端和目标端的抓取和复制进程。
配置DDL复制自动同步数据结构变更
是否打开DDL复制
对于OGG的DDL复制具体限制请参考附录。鉴于这些限制，另外一个重要因素是DDL的trigger会对源库性能带来一定的影响，在国网原则上并不推荐DDL复制。如果有特殊理由需要打开DDL复制，可以与Oracle工程师予以协商。
打开DDL复制的步骤
以下内容为配置DDL复制的步骤，仅作参考，具体请参照GoldenGate的官方安装文档。
? （可选，但强烈建议）定期收集统计信息，提高数据字典访问速度
OGG的DDL复制需要大量访问数据字典信息，通过数据库定期收集统计信息（例如，每月一次），可以有效提高OGG DDL复制的性能。以下为一个例子:
sqlplus /nolog <
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
where is the user assigned to the GoldenGate processes.
注意这里的提示：它需要你手工将这个GGS_GGSUSER_ROLE指定给你的extract所使用的数据库用户（即参数文件里面通过userid指定的用户），可以到sqlplus下执行类似的sql:
GRANT GGS_GGSUSER_ROLE TO ggs1;
这里的ggs1是extract使用的用户。如果你有多个extract，使用不同的数据库用户，则需要重述以上过程全部赋予GGS_GGSUSER_ROLE权限。
? 启动OGG DDL捕捉的trigger
在sqlplus里面执行ddl_enable.sql脚本启用ddl捕捉的trigger。
说明：ddl捕捉的trigger与OGG的extract进程是相互独立的，它并不依赖于extract进程存在。即使OGG的extract进程不存在或者没有启动，但是trigger已经启用了，那么捕捉ddl的动作就一直延续下去。如想彻底停止捕捉DDL捕捉，需要执行下步禁用ddl的trigger。
? （可选）安装提高OGG DDL复制性能的工具
为了提供OGG的DDL复制的性能，可以将ddl_pin脚本加入到数据库启动的脚本后面，该脚本需要带一个OGG的DDL用户（即安装DDL对象的用户，本例中是goldengate）的参数:
SQL> @ddl_pin
? （如果不再需要DDL复制时）停止OGG DDL捕捉的trigger
在sqlplus里面执行ddl_disable.sql脚本启用ddl捕捉的trigger。
DDL复制的典型配置
GoldenGate的data pump进程和replicat的ddl开关默认是打开的，只有主extract是默认关闭的，所以DDL的配置一般只在主extract进行。 结合附录所述的OGG的各种限制，如果需要打开DDL复制，则建议只打开跟数据有密切关系的表和index的DDL复制，参数如下：
DDL &
INCLUDE MAPPED OBJTYPE 'table' &
INCLUDE MAPPED OBJTYPE 'index'
DDLOPTIONS ADDTRANDATA, NOCROSSRENAME
另外，在mgr里面加入自动purge ddl中间表的参数：
userid goldengate,password XXXXX
PURGEDDLHISTORY MINKEEPDAYS 3, MAXKEEPDAYS 7
PURGEMARKERHISTORY MINKEEPDAYS 3, MAXKEEPDAYS 7
对于其它对象，依然建议使用手工维护的方式在两端同时升级。要注意的是级联删除和trigger，在目标端建立后应当立即禁用。
异常处理预案
网络故障
如果MGR进程参数文件里面设置了autorestart参数，GoldenGate可以自动重启，无需人工干预。
当网络发生故障时, GoldenGate负责产生远地队列的Datapump进程会自动停止. 此时, MGR进程会定期根据mgr.prm里面autorestart设置自动启动Datapump进程以试探网络是否恢复。在网络恢复后, 负责产生远程队列的Datapump进程会被重新启动，GoldenGate的检查点机制可以保证进程继续从上次中止复制的日志位置继续复制。
需要注意的是，因为源端的抽取进程（Capture）仍然在不断的抓取日志并写入本地队列文件，但是Datapump进程不能及时把本地队列搬动到远地，所以本地队列文件无法被自动清除而堆积下来。需要保证足够容量的存储空间来存储堆积的队列文件。计算公式如下：
存储容量≥单位时间产生的队列大小×网络故障恢复时间
MGR定期启动抓取和复制进程参数配置参考：
GGSCI > edit param mgr
port 7809
autorestart er *,waitminutes 3,retries 5,RESETMINUTES 60
每3分钟重试一次，5次重试失败以后等待60分钟，然后重新试三次。
RAC环境下单节点失败
在RAC环境下，GoldenGate软件安装在共享目录下。可以通过任一个节点连接到共享目录，启动GoldenGate运行界面。如果其中一个节点失败，导致GoldenGate进程中止，可直接切换到另外一个节点继续运行。建议在Oracle技术支持协助下进行以下操作：
1) 以oracle用户登录源系统（通过另一完好节点）；
2) 确认将GoldenGate安装所在文件系统装载到另一节点相同目录；
3) 确认GoldenGate安装目录属于oracle用户及其所在组；
4) 确认oracle用户及其所在组对GoldenGate安装目录拥有读写权限；
5) 进入goldengate安装目录；
6) 执行./ggsci进入命令行界面；
7) 执行start mgr启动mgr；
8) 执行start er *启动所有进程；
检查各进程是否正常启动，即可进入正常复制。以上过程可以通过集成到CRS或HACMP等集群软件实现自动的切换，具体步骤请参照国网测试文档。
Extract进程常见异常
对于源数据库，抽取进程extxm如果变为abended，则可以通过在ggsci中使用view report命令察看报告，可以通过搜索ERROR快速定位错误。
一般情况下，抽取异常的原因是因为其无法找到对应的归档日志，可以通过到归档日志目录命令行下执行
ls –lt arch_X_XXXXX.arc
察看该日志是否存在，如不存在则可能的原因是：
§ 日志已经被压缩
GoldenGate无法自动解压缩，需要人工解压缩后才能读取。
§ 日志已经被删除
如果日志已经被删除，需要进行恢复才能继续复制，请联系本单位DBA执行恢复归档日志操作。
一般需要定期备份归档日志，并清除旧的归档日志。需要保证归档日志在归档目录中保留足够长时间之后，才能被备份和清除。即：定期备份清除若干小时之前的归档，而不是全部归档。保留时间计算如下：
某归档文件保留时间≥抽取进程处理完该文件中所有日志所需的时间
可以通过命令行或者GoldenGate Director Web界面，运行info exXX showch命令查看抓取进程exXX处理到哪条日志序列号。在此序列号之前的归档，都可以被安全的清除。如下图所示：
wpsBA61.tmp
Replicat进程常见异常
对于目标数据库，投递进程repXX如果变为abended，则可以通过在ggsci中使用view report命令察看报告，可以通过搜索ERROR快速定位错误。
复制进程的错误通常为目标数据库错误，比如：
1) 数据库临时停机；
2) 目标表空间存储空间不够；
3) 目标表出现不一致。
可以根据报告查看错误原因，排除后重新启动rep进程即可。
需要注意一点：往往容易忽略UNDO表空间。如果DML语句中包含了大量的update和delete操作，则目标端undo的生成速度会很快，有可能填满UNDO表空间。因此需要经常检查UNDO表空间的大小。
异常处理一般步骤
如果GoldenGate复制出现异常，可以通过以下步骤尝试解决问题：
1. 通过ggsci>view report命令查找ERROR字样，确定错误原因并根据其信息进行排除；
2. 通过ggsci>view ggsevt查看告警日志信息；
3. 检查两端数据库是否正常运行，网络是否连通；
4. 如不能确定错误原因，则可以寻求Oracle技术支持。在寻求技术支持时一般需要提供以下信息：
a) 错误描述
b) 进程报告，位于dirrpt下以大写进程名字开头，以.rpt结尾，如进程名叫extsz，则报告名字叫EXTSZ.rpt；
c) GGS日志ggserr.log，位于GGS主目录下；
d) 丢失数据报告，在复制进程的参数disardfile中定义，一般结尾为.dsc；
e) 当前队列，位于dirdat下。
附录
Oracle GoldenGate V11.1数据复制限制
不支持文件等非结构化数据复制
GoldenGate依赖对于数据库日志的解析获取数据变化，因此只能支持数据库中的数据变化复制，无法支持文件等非结构化数据的复制。
Oracle数据类型限制
GoldenGate支持Oralce常见数据类型的复制。
l GoldenGate不支持的数据类型
a) ANYDATA
b) ANYDATASET
c) ANYTYPE
d) BFILE
e) BINARY_INTEGER
f) MLSLABEL
g) PLS_INTEGER
h) TIMEZONE_ABBR
i) TIMEZONE_REGION
j) URITYPE
k) UROWID
l GoldenGate有限制支持XML Type复制
? 仅限于Oracle 9i及以后版本
? 表必须有主键或者唯一索引
l GoldenGate有限制支持UDT用户自定义类型复制
? 如有该类型数据请联系技术支持人员并提供脚本。
Oracle DML操作支持
GoldenGate当前支持普通表的所有DML操作和有限制支持部分特殊对象的DML操作，对于特殊表或对象请参照后面特殊对象一节的说明。
l GoldenGate不支持nologging的表等对象
当表或表空间被设置为nologging后，使用sqlloader或者append等非常规模式插入数据将不会被写入到数据库日志，因此GoldenGate无法获取这些数据变化。建议将所有需要的业务表设置为logging状态，对于nologging的表不予以复制。
l GoldenGate暂不支持对象和操作如下
a) REF
b) 使用COMPRESS 选项建立的表空间和表
c) Database Replay
l GoldenGate支持Sequence序列的复制
l GoldenGate可以通过复制源表支持对于同义词或者DBLink的复制。
由于对于这些对象本身的操作发生于其所链接的源数据库对象，数据库日志中并不记录对这些链接目标对象的操作，因此GoldenGate不复制对同义词或者DBLink本身的操作，但这些操作会应用在源表上并产生日志，因此可以通过复制源表复制变化。
l GoldenGate有限制支持IOT索引组织表复制
? 仅限于Oracle 10.2及以后版本
? 能够支持使用MAPPING TABLE创建的IOT，但是只抽取基表的数据变化，而不是MAPPING TABLE。
? 不支持以compress模式存储的IOT。例如，不支持存储在一个使用compress选项的表空间里的IOT。
l GoldenGate有限制支持Clustered Table复制
? 仅限于Oracle 9i及以后版本
? 不支持Encrypted加密和compressed压缩的clustered tables
l GoldenGate有限制支持物化视图复制
? 不支持使用WITH ROWID选项创建的物化视图
? 源表必须有主键
? 不支持物化视图的Truncate但支持DELETE FROM
? 目标物化视图必须是可更新的
? 只在Oracle 10g或以后的版本支持物化视图的Full refresh
Oracle DDL复制限制
GoldenGateDDL复制的原理是通过Trigger从源数据库获取sql，到目标端进行重现，在实际使用中有较多限制，即源端能够执行的sql到了目标端未必能够执行成功。以下为常见的一些问题：
? 当SQL语句里面设计的对象在目标不存在时，DDL无法执行成功。例如，源建立了一个DBLINk或create table as select * from mydblink，此时目标端可能并没有这个dblink指向的库或对象，所以sql语句会报错；
? 当两端的物理位置不同时，建立data file或tablespace等与物理位置相关的语句需要在目标端替换为目标的物理位置；
? 当创建约束没有指定名称时，在源和目标会生成不同名称的对象，这样以后对这些对象再进行修改时就无法正确映射到目标端；
? 当复制带有LOB的表时，ddl操作必须等待DML操作全部完成以后再复制；
? 不能复制表明和列名带有中文的表；
? 表或其它对象的定义里面不能加入中文注释;
? 不能复制带有编译错误的CREATE trigger/procedure/function/package等对象；
? 不能复制结尾带有‘/’的sql语句.
此外，GoldenGate DDL复制需要关闭Oracle的_RECYCLEBIN参数（Oracle 10.1）或者RECYCLEBIN参数（Oracle 10.2及以后版本）。
还有一个比较重要的是：由于是Trigger based，GoldenGate的DDL复制可能会降低源数据库的性能，所以不推荐使用DDL复制，具体请参照国网OGG实施原则。
说明：更多详细信息请参照OGG的官方参考手册。
Oracle 9i中如何为超过32列的无主键表添加附加日志
为数据库表添加附加日志操作的本质是执行如下的SQL语句：
Alter table
add supplemental log group (column,..) always;
Oracle GoldenGate的add trandata 也是调用这个语句执行：
1) 当表有主键时，会将所有作为主键的列放到columns子句里面添加到附加日志组里；
2) 如果没有主键，则会找唯一索引，将唯一索引列放到columns子句里面添加到附加日志组里;
3) 如果没有主键和唯一索引，则会将所有列添加到附加日志组中去。
在对于无主键和唯一索引表添加附加日志时，Oracle 9i有个限制: 即每个附加日志组不可以超过32个列（大致数字，与实际列定义长度有关）.此时调用GoldenGate的add Trandata命令会失败，其处理方法是将该表的所有列拆分为若干组，每组不超过32各列，然后分别添加附加日志组（对不同组合设置不同附加日志组名）。以下为一个超过32列表添加附加日志例子：
ALTER TABLE SIEBEL.XYZ_SQL ADD SUPPLEMENTAL LOG GROUP GGS_XYZ_SQL_649101_1(ACTION ,ACTION_HASH ,ADDRESS ,BUFFER_GETS ,CHILD_ADDRESS ,CHILD_LATCH ,CHILD_NUMBER ,COMMAND_TYPE ,CPU_TIME ,DISK_READS ,ELAPSED_TIME ,EXECUTIONS ,FETCHES ,FIRST_LOAD_TIME ,HASH_VALUE ,INSTANCE_ID ,INVALIDATIONS ,IS_OBSOLETE ,KEPT_VERSIONS ,LAST_LOAD_TIME ,LITERAL_HASH_VALUE ,LOADED_VERSIONS ,LOADS ,MODULE ,MODULE_HASH ,OBJECT_STATUS ,OPEN_VERSIONS ,OPTIMIZER_COST ,OPTIMIZER_MODE ,OUTLINE_CATEGORY ,OUTLINE_SID ,PARSE_CALLS) always;
ALTER TABLE SIEBEL.XYZ_SQL ADD SUPPLEMENTAL LOG GROUP GGS_XYZ_SQL_649101_2(PARSING_SCHEMA_ID ,PARSING_USER_ID ,PERSISTENT_MEM ,PLAN_HASH_VALUE ,REMOTE ,ROWS_PROCESSED ,RUNTIME_MEM ,SERIALIZABLE_ABORTS ,SHARABLE_MEM ,SNAP_ID ,SORTS ,SQLTYPE ,SQL_TEXT ,TYPE_CHK_HEAP ,USERS_EXECUTING ,USERS_OPENING) always;
说明：通过手工方式加入附加日志后，不能在ggsci中使用info trandata查看到附加日志，此时可以通过下列语句查询是否有表没有加入到附加日志：
SQL> select * from dba_log_groups where owner='SIEBEL' and table_name=’XXX’;
如想验证是否所需的列均在附加日志中，可以再查询dba_log_group_columns。
如需将附加日志组drop掉，可以采用如下格式：
Alter table
drop supplemental log group ;
ogg的字符集分析浅谈
我们所熟知oracle的字符集一旦创建完毕后最好不要修改，关于oracle goldengate的字符集问题还是需要注意的，因为如果目标端和源端字符集不一致，而有些字符无法在目标端表示ogg可能无法保证数据一致性。
源库字符集：
SQL> select value from v$nls_parameters where parameter='NLS_CHARACTERSET';
VALUE
----------------------------------------------------------------
AL32UTF8
如果这里小鱼在源端设置SETENV（NLS_LANG=“AMERICAN_AMERICA.ZHS16GBK”）去指定源端客户端的字符集
GGSCI (dg01) 21> view params exiaoyu
extract exiaoyu
SETENV (NLS_LANG="AMERICAN_AMERICA.ZHS16GBK")
SETENV (ORACLE_SID="xiaoyu")
userid ogg,password ogg
dynamicresolution
gettruncates
report at 2:00
reportrollover at 3:00
warnlongtrans 3h,checkinterval 10m
exttrail ./dirdat/dd
table xiaoyu.*;
table xiaoyugg.*;
来看看对应的extract进程的报告，发现此时ogg发觉源端客户端的NLS_LANG变量和源端数据库字符集不一致，从而选择源端数据库字符集，并没有根据extract进程参数中的SETENV指定。
GGSCI (dg01) 52> view report exiaoyu
** Running with the following parameters **
***********************************************************************
2013-06-04 04:50:27 INFO OGG-03035 Operating system character set identified as UTF-8. Locale: en_US, LC_ALL:.
extract exiaoyu
SETENV (NLS_LANG="AMERICAN_AMERICA.ZHS16GBK")
Set environment variable (NLS_LANG=AMERICAN_AMERICA.ZHS16GBK)
SETENV (ORACLE_SID="xiaoyu")
Set environment variable (ORACLE_SID=xiaoyu)
userid ogg,password ***
2013-06-04 04:50:28 INFO OGG-03500 WARNING: NLS_LANG environment variable does not match database character set, or not set. Using database character set value of AL32UTF8.
[oracle@ogg 11.2]$ oggerr 3500
03500, 00000, "WARNING: NLS_LANG environment variable does not match database character set, or not set. Using database character set value of {0}"
// *{0}: nls_charset (String)
// *Cause: The NLS_LANG environment variable is not set to the same as the
// database character set. Oracle GoldenGate is using the database
// character set.
// *Action: None
看来源端设置NLS_LANG跟oracle database的字符集不一致时，ogg还是会选择oracle database的字符集，而忽略掉extract的进程参数SETEVN NLS_LANG
接下来测试目标端：
这里也指定SETENV（NLS_LANG=”AMERICAN_AMERICA.ZHS16GBK”）
GGSCI (ogg.single) 15> view params rxiaoyu
replicat rxiaoyu
SETENV (NLS_LANG="AMERICAN_AMERICA.ZHS16GBK")
SETENV (ORACLE_SID="xiaoyu")
userid ogg,password ogg
assumetargetdefs
gettruncates
report at 2:00
reportrollover at 3:00
discardfile ./dirrpt/discard_rxiaoyu.dsc,append,megabytes 100
map xiaoyu.xiaoyu10,target xiaoyu.xiaoyu10,filter(@getenv("transaction","csn")>1074454806);
map xiaoyu.*,target xiaoyu.*;
map xiaoyugg.*,target ogg.*;
观察目标端的replicat进程，发现ogg选择了进程参数中SETENV（NLS_LANG=“AMERICAN_AMERICA.ZHS16GBK”）
GGSCI (ogg.single) 17> view report rxiaoyu
。。。
2013-06-05 03:14:14 WARNING OGG-03504 NLS_LANG character set ZHS16GBK on the target is different from the source database character set AL32UTF8. Replication may not be valid if the source data has an incompatible character for the target NLS_LANG character set
此时ogg给出的提示需要在replicat进程中正确设置SETENV NLS_LANG变量，这里源端传递的是AL32UTF8字符集，目标端通过replicat进程参数SETENV NLS_LANG指定的是ZHS16GBK，而ogg也采用了replicat进程的参数，并没有选择源端的字符集。
[oracle@ogg 11.2]$ oggerr 3504
03504, 00000, "NLS_LANG character set {0} on the target is different from the source database character set {1}. Replication may not be valid if the source data has an incompatible character for the target NLS_LANG character set."
// *{0}: nls_lang_charset (String)
// *{1}: src_db_charset (String)
// *Cause: The NLS_LANG environment variable on the target is set to a
// different character set than the character set of the source
// database.
// *Action: Set the NLS_LANG environment variable on the target to the
// character set of the source database that is shown in the message.
// You can use the SETENV parameter in the Replicat parameter file to
// set it for the Replicat session.
而ogg报出的3504警告是为了提醒目标端字符集和源端不一致，可能会引起replicat进程异常，这里ogg也推荐在replicat进程中设置NLS_LANG使目标端和源端一致。
那么对于字符集对ogg的影响就是源端和目标端，如果源端和目标端database字符集一直，这里在进程中直接采用一致的SETENV NLS_LANG都等于缺省的数据库字符集即可，而对于源端和目标端字符集不一致的，则需要在目标端手动指定replicat进程参数SETENV NLS_LANG等于源端字符集，当然对于最后在数据库中数据行小鱼认为还是需要再次转化成目标端oracle database的字符集。（ogg也是一个同步复制产品，其技术原理依然不能脱离oracle database）
网站标题：OGG运维手册
转载注明：http://cqcxhl.com/article/iggdos.html