GoldenGate OGG　Director 安装及配置文档

安装及配置文档

GoldenGate Director

安装及配置文档

1.1  概述

本章节所有文本均基于Oracle GoldenGate V10.4版本，主要描述GoldenGate Director的安装及配置使用。所有部署在生产系统的GoldenGate进程，均需要经过开发、测试小组严格认真的测试之后才可以进行部署。

1.2  GoldenGate Director概述

GoldenGate Director是GoldenGate的图形化监控管理软件，可以方便、集中管理多个GoldenGate实例。平安集团需要部署多个GoldenGate实例，每个实例部署在一个单独的服务器上，如果使用命令行方式进行监控和维护，则每次都需要登录到每个单独的服务器，极不方便。使用GoldenGate Director，只需要事先配置好连接，就可以在统一界面中监控所有的GoldenGate实例。Director提供了两种图形化监控客户端，一种是基于Web方式，另一种是基于C/S。

下图描述了GoldenGate Director各个组件及其关系：

GoldenGate Director 体系架构

 

• GoldenGate Instances是需要被管理的实例。Director可以方便管理多个GoldenGate实例。
• Director Server是Director服务端，需要部署在WebLogic Server下。Director服务器通过Monitor Agent和GoldenGate实例进行通信。
• Director Database用来存放Director Server资料库（Repository）。
• Director Administrator是管理Director Server的客户端工具，主要负责实例的注册和配置。
• Director Client是基于C/S模式的客户端，可以用于监控实例。
• Director Web是基于Web的客户端，可以通过统一的Web界面监控多个GoldenGate实例。

1.3  GoldenGate Director的安装

1.3.1              部署方案必需条件

1.3.1.1        Director服务器安装前提

硬件

可支持的操作系统

Windows NT/XP/2000/Vista

Solaris

AIX

Redhat Linux

HP-UX

 

1GB内存

1.5GB磁盘空间

安装过程需要设置HTTP端口，默认端口为7001

 

软件

JRE 6.0

WebLogic 11g(10.3.1),需在Director Server安装之前安装。

在Director安装之前，需要安装下列数据库之一，作为Director的资料库（Repository）。

MySQL 5.x 企业版

SQL Server 2000或2005

Oracle 9i或更高版本

在Unix/Linux下安装，XWindow必须可用。

至少需要分配200MB空间的数据库数据，作为资料库使用。

1.3.1.2        Director客户端安装前提

操作系统：可以支持JRE 6.0的Windows/Linux/Unix平台

安装JRE6.0

需要Window，或XWindow

对于基于Web的客户端，支持下列的浏览器

Microsoft Internet Explorer 5.0或者更高版本

Mozilla Firefox 1.3或者更高版本

Apple Safari 1.2或者更高版本

 

以下是典型的一个安装部署例子。

GoldenGate Director部署方案

 

1.3.2              安装GoldenGate Director Server

安装步骤如下：

• 执行安装程序，在弹出的欢迎界面上点Next。
• 选择安装目录。
• 输入WebLogic Server的安装目录，以及Domain Name(如GGMonitor)。
• 输入HTTP端口。
• 选择数据库类型。选择Oracle Database。
• 配置数据库连接。
• 配置数据库用户名和密码。
• 检查各项配置之后，就可以开始安装。

输入Weblogic Server安装目录

 

输入HTTP端口

 

选择数据库类型

 

 

配置数据库连接

 

配置数据库用户名和密码

 

1.3.3              安装GoldenGate Director Client

GoldenGate Director Client的安装非常简单。启动安装文件后，一路按照提示安装即可。

需要说明的是，GoldenGate Director Client中包含了管理工具（Director Admin）。需要通过管理工具对GoldenGate Director Server进行配置。

1.3.4              启动GoldenGate Director Server/Client

启动Director Server

启动Director Server之前，必须确保Director Database已经启动并正常运行。

启动步骤：

• 进入安装目录/domain

Unix/Linux平台

运行./startWebLogic.sh

Windows平台

运行startWebLogic.cmd

 

启动Director Admin

Unix/Linux平台

• 进入Client安装目录/GoldenGateDirector/bin
• 运行./run-admin.sh

Windows平台

进入到GoldenGate Director Client安装目录/ GoldenateDirector，打开GDSC Admin Tool.exe。

输入的用户/口令为admin/admin，server为Director Server的IP和端口，要确保Director Server已经启动。

 

 

启动基于C/S的Director客户端

Unix/Linux平台

• 进入Client安装目录/GoldenGateDirector/bin
• 运行./run-director.sh

Windows平台

进入到GoldenGate Director Client安装目录/ GoldenGateDirector，打开GoldenGate-Director.exe

输入的用户/口令为admin/admin，或者Director Admin创建的用户/口令，server为Director Server的IP和端口，要确保Director Server已经启动。

 

启动基于Web的Director客户端

启动浏览器，输入http://<Director server IP地址或域名>:<端口，默认为7001>/acon， 输入的用户/口令为admin/admin，或者Director Admin创建的用户/口令，要确保Director Server已经启动。

1.4  GoldenGate Director的配置使用

1.4.1              Director Admin

• 启动Director Admin，输入口令
• 创建监控管理用户

填写Account Info和Password，“Save”以保存。

• 创建监控GoldenGate实例

Director Administrator Tool配置界面

这里需要配置需要监管维护的GoldenGate实例。创建Data Source的过程如下：

Host Identity:

• Fully Qualified Domain Name : GoldenGate实例所在的服务器名
• Manager Port : GoldenGate实例MGR进程端口号
• Data Source Name :原则上可以填写任何名称。建议制定命名规范。
• 点击Check–Connection 验证连接。

GoldenGate Info:

• Host Operating System: 选择WU（即Windows/Unix意思）
• Database: 选择数据库类型。Oracle数据库应选择ORA。
• GoldenGate Version : 10.4
• 点击 “Save”，然后点击“Yes”。

从左侧的面板上选择刚才创建的Data Source（只在通过ODBC连接时才需要填写），填写完其他信息，包括：

Default DB Credential:

• DSN: 数据库实例名或服务名
• Username : 用户名
• Password & Confirm Password : 密码

Access Control:

• Owner : 选择admin（表示配置该数据源的owner为admin，也可以选择admin外的用户）
• 勾选Host is Observable选项（表示配置该数据源对其他用户可见，也可以不勾选）
• GoldenGate Version : 10.4
• 点击“Save”

1.4.2              基于Web的Director客户端

要进入Director Web界面，在浏览器里面输入网址：http://<system name>:<port>/acon。如：http://gg_director_server:7001/acon

<system name>是Director Server所在服务器的主机名或IP地址，<port>为安装时选择的端口号。要确保开启此端口号给Director Server专用。

首次进入Director Web，需要输入用户名和密码(默认为admin/admin)。进入之后的主界面如下图示：

Director Web 主界面

 

整个主界面分为三个区域：

左侧面板包含了所有GoldenGate实例的列表以及一些功能链接。

右侧上方按照GoldenGate实例分组列出了每个实例上所有进程的概况。

右侧下方列出了所选实例的事件日志。

1.4.2.1        监控整体运行情况

首先查看主界面左侧面板，点击一个实例左边的黑三角符号可以展开该实例，查看到具体的进程。右侧面板也会有相应的变化，列出该实例下所有进程的概要信息以及事件日志。

 

表示实例正在运行（MGR进程正常运行）

表示实例没有启动（MGR进程已停止）

表示进程正常运行

表示进程正常停止

表示进程非正常停止，需要进一步调查原因。同时会用红色的Abended字样标示。

1.4.2.2        监控进程状态

右侧上方的面板显示了每一个进程的概要信息。点击More Info查看详细的进程信息。

这里可以查看到进程报告文件、详细信息、历史延时情况以及被丢弃的记录。Discard File是进程用来存放丢弃记录的文件。如果该文件中有记录，需要详细查看记录情况，分析记录被丢弃的原因，并解决相关问题。

1.4.2.3        查看事件日志

主界面右侧下方是事件日志。

Info事件只是一般的事件，如收到stats命令等，不会对GoldenGate的正常运行造成影响。

Warning事件是有可能对GoldenGate造成影响的事件，如停止MGR进程等。

Error事件需要引起关注，表示有重大错误发生，已经影响到了GoldenGate的正常运行。

 

点击右上角的Filter按钮，把Show Information和Show Un-acknowledged Only两项勾选掉。这样，仅Warning和Error信息被显示出来，便于发现问题。

筛选事件类型

筛选后的情况

1.4.2.4        Email告警

开启Email告警功能需要事先部署一个Mail服务器。点击主界面左侧面板上My Email Alerts链接，在新窗口中填写以下信息：

• Alert Name：告警的名字
• Alert Type：有两种类型可供选择。

如果选择Process Lag,则需要指定一个时限，超过这个时限会引发告警。

如果选择Event Text，则需要指定Event Type（Error，Warning等），以及Event text中包含的文本。当Event消息中包含此文本时，会引发告警。支持通配符*。

• Process Name：进程名称，支持通配符*。
• Sent an email to：目标邮件地址
• With the subject：邮件标题
• From Address：发送方地址
• Mail server：邮件服务器，需要事先部署。

 

Email 告警

1.4.2.5        运行GGSCI命令

选择主界面右上方某个实例，点击实例下方的GGSCI图标，进入命令行交互页面。

在这里，可以输入各种命令，并显示输出结果。具体命令，请参考第二章内容。

GGSCI 交互页面

 

1.4.3              基于C/S的Director客户端

1.4.3.1        查看事件日志

和基于Web的方式类似，基于C/S的Director客户端集中多个GoldenGate实例的日志，可以进行排序、过滤等操作。

 

1.4.3.2         Email告警

和基于Web的方式类似，可以指定规则，将满足规则的日志信息通过email方式告警。

 

1.4.3.3        运行GGSCI命令

和基于Web的方式类似，可以在多个GoldenGate实例间切换执行ggsci命令，以管理GoldenGate。

 

1.5  参考文献

• 《Oracle GoldenGate Licensing Information Release 10.4》
• 《Oracle GoldenGate Director Administration Guide Version 2.0》
• 《Oracle GoldenGate Director Patch Set Notes 2.0.0 for Open Systems》
• 《Oracle GoldenGate Director 2.0 Release Notes》

Oracle GoldenGate OGG与Quest Shareplex对比

 

	GoldenGate	Quest SharePlex	DSG RealSync
公司背景
公司介绍	GoldenGate成立于1995年，一直专注于数据库复制领域，现在已经被Oracle收购，能够得到数据库厂商大力支持，正在开发整合后的新版本，届时功能和性能均能进一步提高。	Quest Software成立于1987年，公司总部位于美国加州。公司致力与数据库管理软件，SharePlex只是其众多产品中一个非主流的小产品。	DSG北京公司于2002年8月在北京成立，前身是DSGuardian Inc，注册于美国。主要产品为数据库复制及备份软件。只有几十个人的国内小公司。
数据库厂商支持	Oracle公司产品，能够与数据库一起进行技术支持，并且产品持续与Oracle数据库进行整合中。（☆☆☆☆☆）	与Oracle有合作关系，但因Oracle不完全公开日志格式，在复制领域无法得到更多技术支持，出现问题后Oracle无法进行支持，版本兼容性容易出现问题。	与Oracle无关系。其产品为一位前Oracle人员开发，只有此人能够解决问题，技术力量差，无法对Oracle后继版本有效支持。同样因Oracle不完全公开日志格式，在复制领域无法得到更多技术支持，出现问题后Oracle无法进行支持。
产品成熟度	GoldeGate产品最早发布于1995年，目前版本为10.4，产品成熟度高，在全球有超过2000多个成功案例。	SharePlex产品最早发布于1999年，目前的版本为7，产品成熟性比较高，在全球有近千个成功案例	产品推出时间较短，很不成熟，会出现各种问题，经常需要开发人员在客户现场修改代码，并在客户生产环境中测试运行。仅在国内有少量案例。
成功案例	在国内有海关总署、体育彩票中心、国家税务总局、北京移动、第一重工等众多大型成功案例。在全球有超过2000多个成功案例。	在国内有一些成功案例，包括北京地 税，天津地税，贵州联通，黑龙江移 动，大连商品交易所等客户，在全球有近千个成功案例。	客户较少，应用主要集中在数据库升级及备份，实时复制案例较少。
产品方面
兼容性和可扩展性	支持Oracle、DB2、SQL Server、Sybase、MySQL、Teradata等各种数据库平台（☆☆☆☆☆）	仅支持Oracle。	仅支持Oracle。
复制机制	基于交易(Transaction)的复制，可以保证数据复制过程中交易的完整性。   只复制提交交易，保证数据一致性。   使用常规加载方式装载数据，可靠性高。 （☆☆☆☆☆）	基于SQL的复制，无法保证复制过程中交易数据的一致性。（例如，如果两边数据集不同，则相同sql可能产生不同结果）   复制所有提交和回滚交易，会造成资源浪费，也容易造成两端数据不一致。（其优势是无需保存一定时间归档日志，同时复制无需等待交易提交，对大交易速度较快）	基于交易(Transaction)的复制，可以保证数据复制过程中交易的完整性。   只复制提交交易。   使用Direct Inser模式插入数据，效率较高但有以下问题： 1 Direct模式复制过程中不检查约束，无法保证目标数据一致性。例如，A表通过外键依赖于B表，如果B表数据出现丢失，A表数据通过Direct Insert会正常插入而不检查约束，导致A、B两表数据不一致； 2 只在高水位线以上插入数据，不充分利用高水位线以下空间，会造成数据库占用空间持续增大，表空间利用率非常低，可维护性差。 3 有客户反映目标记录会出现重复（例如，一个带有主键的表在目标却出现两个相同记录，只是rowid不同）。这是因为direct insert不检查约束的原因。   另外，由于其以来rowid进行映射，如果数据库维护过程中出现行迁移操作，会使数据复制紊乱，需要重新建立复制关系。例如，以下操作会引起行迁移： alter table move tablespace alter table split partition alter table merge partition alter table move shrink tablespace
数据类型支持	支持XML Types，Nested tables，Clustered tables，IOT from/to Non-IOT	不支持XML Types，Nested tables，Clustered tables，IOT from/to Non-IOT
是否可只读取归档	GoldenGate支持只读取归档日志模式，也可以在其它主机上读取从主机共享过来的归档日志，可以在实时性要求不高的情况下最小化对生产系统的影响。 （☆☆☆☆☆）	目前尚无消息证明其能够支持只读归档日志	目前尚无消息证明其能够支持只读归档日志
数据过滤和变换	GoldenGate提供丰富的内建函数，只需简单配置即可实现灵活的数据过滤和转化，无需消耗数据库本身资源。 （☆☆☆）	Quest SharePlex需要依赖Trigger、SP等数据库内部对象实现过滤和转换，系统消耗高，实现复杂。	（需验证）机制应当与Quest类似
源系统插入性	无需在源端插入任何表、触发器、存储过程等数据库对象，对生产库影响非常小。 （只针对DML复制） （☆☆☆）	需要在源端建立部分中间表，对源库产生一定影响。	需要在原系统上插入大量的数据表，这些数据表占用大量的存储空间，维护起来相当麻烦；如果一旦这些中间表丢失数据，需要花费大量的时间重建复制，是可靠性不高的一种设计。
系统资源占用	正常复制时与数据库交互极少（只有在读取数据字典和日志中没有完整数据如大对象时才会访问源库），复制效率高，对源系统的影响非常小，所有复制进程CPU占用率在5%以内（☆☆☆）	需要与数据库交互，复制效率相对低，所有复制进程CPU占用率在10%以内。据称其最新版本资源占用与OGG基本相当。	复制进程CPU占用率在10%以内
数据复制能力	1,000G-1,8000G日志量/天 提供若干小交易合并为一个大交易和大交易拆分为小交易的选项，对于OLTP应用性能非常高。（☆☆☆☆）	Quest最新版本7性能得到了很大提高，基本和GoldenGate类似，具体数据不明。 其以前的版本只能复制300G-400G日志量/天。 由于复制回滚交易，无法提供交易合并和拆分的功能。	因为其使用了Direct Insert模式，DSG的性能比较高。 这种模式可靠性低，只是用来作为批量加载，Oracle不推荐作为实时复制。
双向复制	Goldengate可以非常好的支持同一个业务系统同一套表的实时双向复制。	Quest支持双向复制。	DSG基于rowid实现源和目标的数据库复制，从机理上肯定不能实现双向复制，同时当源端进行数据库整理时，数据的rowid会发生变化，会造成数据不一致。
反向回切	当源出现问题时，前端应用可以无缝切换到目标系统，此时目标系统会将此期间所有变化记录下来，待源系统修复后，可以自动将源出现问题期间的变化数据同步回去，最大程度的较少回切时间。	基本同GoldenGate。	基于rowid实现源和目标的数据库复制,当源出现问题，前端应用切换到目标系统，当源修复后，只能将目标系统全库同步回源系统，然后再切回去，当数据量比较大时，需要的时间会非常长。
网络带宽占用	因为有数据压缩功能，网络上传输的数据仅为数据库日志量的三十分之一，网络带宽占用最小。（☆☆☆☆）	网络带宽相对较大，数据的传输量是数据库日志量的三分之一到四分之一。	网络带宽相对较大，数据的传输量是数据库日志量的三分之一到四分之一。
不同oracle版本支持	支持oracle8i以后所有版本，以及RAC环境,在各种版本上均有大量成功案例。	支持oracle8i以后所有版本，以及RAC环境,在各种版本上均有大量成功案例。	支持Oracle8i以后所有版本，但由于其技术力量有限，通常需要很长时间才能支持Oracle最新版本，并且会有较多技术问题难以及时解决。
容错能力	软件使用检查点机制记录当前完成复制的位置。在日常运行过程中，如果由于网络中断、数据库实例失败、存储空间不够等原因造成复制停止，GoldenGate能够以自定义间隔自动检测并在异常排除后立即自动恢复复制，保障数据无丢失，使得管理和维护工作中人工介入降低到最小。（☆☆☆）	异常情况排除后，软件需要确认两端数据库中的大量信息，然后才能重新开始复制。这个确认过程最少需要几十分钟的时间，扩大了复制中断的时间。	由于产品问题，会频繁出现数据不一致错误，每次出现错误后，都需要大量的手工维护工作，才能继续复制。
产品日常维护	由于使用了多重检查点机制，一方面能保证在网络中断等一般异常情况排除后，软件能自动快速的恢复正常复制状态，另一方面在遇到因为人为错误等原因造成两端数据不一致的情况下，可以通过调整检查点（即修改抽取起始点，可以设置到之前的时间端）重新同步的方式找回丢失数据，恢复数据一致。使维护工作中人工介入降低到最小。（☆☆☆）	在异常排除后仍需要等待很长时间才能恢复正常复制状态。两端数据一旦不一致，需要手工恢复或重新初始化。	产品的维护需要大量的人工干预，停止产品时只能通过kill命令直接杀掉进程。
产品的运行监控	GoldenGate提供了集中管理的工具 Director。该工具可以对多个分布的GoldenGate实例进行集中管理，并提供命令行、web页面面和Java 界面三种管理界面，客户可以根据自身爱好选择任意一种方式管理和监控复制软件的运行。Director使得客户可以更加直观的观察复制软件运行的状态，管理和配置复制软件进程和参数，及时处理故障和报警，还可以提供与第三方监控软件的接口。	用户可通过shareplex控制台查看数据复制的各种相关信息，并设定个性化的参数以实现特定的功能，管理方便灵活。可与多种监控平台结合，实现数据复制的实施监控（使用SNMP方式）或者与Quest Foglight监控产品集成，实现监控及报警。 相对而言，其监控具有一定的优势。	产品运行情况只能通过查看日志了 解，停止产品时只能通过kill命令直 接杀掉进程；监控产品运行情况有较 大难度。
初始化	Goldengate可以和oracle数据库实现无缝结合，充分利用oracle的rman，data pump，exp/imp，在保证数据一致性的情况下，可以高速地实现数据初始化。	Quest也可以利用oracle的exp/imp初始化工具。	由于DSG基于rowid实现源和目标的同步，因此必须使用其自己的初始化工具进行初始化，速度比较快，但初始化过程中要求生产端不能有数据变化或者编译存储过程等维护操作，否则会造成数据不一致。

 

 

 

 

Appendix OGG VS SP – OS/DB/Data Type/Objects support matrix

Items		GG	SP
DB	Oracle	√	√
	DB2	√	X
	MS SQL Server	√	X
	Sybase	√	X
	Teradata	√	X
	My SQL	√	X
	HP SQL/MX	√	X
	Enscribe	√	X
OS	IBM-AIX	√	√
	Sun Solaris	√	√
	HP-UX	√	√
	Linux	√	√
	Windows	√	√
	IBM zOS	√	X
	HP Nonstop	√	X
	HP True64	√	X
Data Types	NCLOB	√	X
	INTERVAL	√	X
	XML Types	√	X
Objects Support	Nested tables	√	X
	Clustered tables	√	X
	MV to MV	√	X
	IOT from/to Non-IOT	√	X
DDL	ANALYZE TABLE	√(New 11g)	X
	ANALYZE INDEX	√(New 11g)	X

 

Oracle GoldenGate与磁盘复制和卷复制对比

如IBM、EMC、HP等存储厂商的镜像技术，Veritas等厂商的卷复制技术等。

优点：

• 灾备的可靠性

1. 在日常业务状态下的容灾，存在以下两个问题：

• 对于业务数据而言：

数据变化的最小粒度是交易，每个交易的数据应当全部被复制到目标端或者全部不被应用到目标端，这样才能保证目标数据是一致的；如果出现只有部分交易数据被复制到目标端，则目标数据就会出现不一致的情况，这是业务所绝对不能允许的。

底层复制技术从原理上根本无法获取交易的边界，例如如果一个大交易有10万点记录，那么在灾难发生时可能只传输了5万条，那么底层复制会把这5万记录复制过去，无法保证交易的完整性；而GoldenGate是逻辑复制技术，完全可以判断出来交易数据不完整，不在目标端应用该部分数据。

2）对于系统数据而言：

更为严重的是，由于这些底层复制技术对于逻辑数据的不可感知，如果在复制中断时正好数据库在更新系统数据（如控制文件、表空间等数据库内部信息），则有可能出现目标数据库出现无法装载和打开的情况，由此会造成容灾的失败，对客户业务造成严重影响。GoldenGate数据复制的备份端始终处于打开状态，可以时刻接管业务，其容灾可靠性是其它底层技术所无法实现的。

 

2. 对于人为失误和数据库Bug等意外因素

磁盘阵列和卷复制为低级复制，会把磁盘操作忠实的传播到备份端，这里面也也包括错误操作，这种错误可以是人为的，也可以是系统错误。比如操作人员失误删除了一个文件，或者磁盘写入出现错误，或者数据库有一个bug，都有可能造成数据丢失，严重的时候会造成数据库不可用。磁盘阵列复制和卷复制会忠实的传播到备份端，这样两端数据库会出现同时数据丢失或不可用的情况，导致容灾失去意义。

GoldenGate只复制交易数据，不会传播这些底层错误到备份端，可以在出现上述错误的情况下保证备份端的可用性。

 

 

一个问题：可以向各个硬件厂商提出问题，在使用磁盘镜像技术复制时，如果业务繁忙时段出现复制中断，目标数据库是否保证可以打开？

 

正如上所述，没有一个底层复制技术能够保证目标数据的可用性，而客户花费大量投资建立一个容灾系统，目的就是为了保证在出现灾难时容灾中心的数据是100%可用的，如无法保证100%可用性就意味着灾难发生肯能会丢失容灾中心全部的数据，容灾系统建设也就失去了意义。

 

• 容灾指标

1. 接管时间短 – RTO小：

容灾当中有一个很重要的指标RTO（Recovery Time Object）表示系统出现灾难后恢复到正常运行的时间。对于磁盘阵列级复制和卷复制，它们的备份端是不可用的，如果出现灾难需要重新装载磁盘或卷，数据库也需要重新恢复和启动，因此接管时间比较长。而GoldenGate的备份端是活动的，可以在灾难出现后立即把业务接管过来，快速恢复业务，大大减少RTO。

 

1. 异地备份数据丢失少 – RPO小：

容灾的另外一个指标RPO（Recovery Point Object）表示系统出现灾难后数据丢失的时间。容灾的数据丢失取决于数据复制的延迟，而延迟除去技术本身的机制外还要取决于网络及其在网络上传输的数据量，相同带宽条件下所需带宽最低的技术所丢失的数据最小。

 

• 经济性和投资回报率

1. 带宽要求低

这是因为GoldenGate需要在网络上传输的数据量要小。磁盘阵列的数据复制是以块为复制单位，当块中任何数据发生变化，整个块都要复制到备份端。对于卷复制，通过把逻辑卷划分为若干个单元，当每个单元中发生变化，则将此单元发送到备份端。由此可见，无论是磁盘阵列复制还是卷复制，都要传输大量的冗余数据。而GoldenGate是通过解析数据库日志，只复制其中数据的变化，因此相对于磁盘阵列和卷复制方式，数据量要小很多。另外GoldenGate还可以提供数据压缩功能，可以进一步降低网络传输的数据量。如果采用磁盘阵列复制和卷复制，在交易量比较大的情况下一般都要求采用光纤等高带宽的传输方式，投资和运营的费用非常大。而采用GoldenGate则有可能采用比较低廉的通讯链路比如租用电信的DDN线路，从而节约很大一笔费用。如果相同的网络情况下，GoldenGate因为要传输的数据量小，它的延时会比磁盘阵列和卷复制要小。

例如，根据某国家机关的统计，GoldenGate数据复制带宽占用约为磁盘阵列复制的1/300或更小。例如，其两家数据量相当的分支机构，使用磁盘阵列复制的点日常复制占用60兆带宽，则使用GoldenGate复制的点日常带宽占用只有约200K左右。

 

1. 高兼容性、降低投资

对于磁盘阵列复制，各厂家一般要求用同一厂商的同种或者几种磁盘阵列，操作系统和数据库也必须保持一致。对于卷复制，对磁盘阵列兼容性好，但是也需要相同的操作系统和数据库。而GoldenGate则可以兼容各种磁盘阵列，也可以跨不同操作系统和不同数据库以及数据库不同版本，因此客户在采购方面可以更为灵活，处于更有利的商务地位。另外，采用磁盘阵列复制或卷复制方案原有设备可能需要彻底更新，而利用GoldenGate可以跨平台复制的特性可以将旧设备用作备份端，保护以前的投资。

 

1. 实现目标库的再利用

使用GoldenGate建立灾备系统以后，由于灾备系统数据库是活动的，可以在日常担负部分报表、查询等业务。可以将主机的部分业务转移到备份端执行，实现负载均衡，有效地降低主机的负荷。比如，一些查询相关的业务就可以放到备份端，提供实时的数据查询。而磁盘阵列级复制和卷级复制备份端是不可用的，无法做到负载均衡，某些厂家可以作只读的快照，但是在数据量大的情况下需要时间会比较长，而且数据不是实时的。

 

• 可扩展性

GoldenGate可以实现一对一、一对多、多对一、双向复制等多种灵活的拓扑结构，它可以实现数据的分发和集中以及对等复制，非常灵活。比如容灾中广泛采用的n+1备份模式，只需建立一个备份中心，通过GoldenGate实时复制将各数据库的数据整合到一个数据库，提供统一的数据视图，而磁盘阵列复制和卷复制只能做到物理上的集中，无法实现逻辑上的集中。

 

 

 

缺点

• GoldenGate不能复制数据库以外的数据

例如应用程序。磁盘阵列复制和卷复制则没有这个限制。可以如下解释：

• 应用程序的容灾是不必要的

应用程序与数据不同，数据是一直在持续变化的，而一般客户均有正式的应用开发、测试和发布流程，是间断更新的，而且无需担心没有备份。

如果仅仅是数据库出现灾难，可以直接将现有应用切换到容灾库上。

如果考虑应用系统容灾，可以在备份端维护一个备用应用系统，发布新版本时同时发布一份；或者RTO要求不高时也可以灾难发生后临时在目标端部署。

• 应用程序使用磁盘阵列复制是不可靠的

应用程序如果通过磁盘阵列复制到目标端，会出现与数据库一样的应用程序数据不一致，导致会出现应用系统无法启动的问题。

• 应用程序使用磁盘阵列复制会延长接管时间和带来人工风险

使用磁盘阵列复制备份的应用系统即使可以启动，也需要对应用程序中相当多的配置进行人工现场重新修订才可以重新启动服务，如与数据库之间的链接、与其它各系统之间的连接等等。这些配置由于磁盘阵列复制目标是不可用的，只能等待接管时进行重新调整，造成接管时间延长，同时紧急时刻的人工操作可能会带来认为失误。而使用数据库级复制技术，由于目标端是活动的，可以日常对于应用和数据库调整好，灾难接管时直接接管即可。

 

• GoldenGate需要消耗一定的CPU和内存等主机资源

对系统影响不大，一般占用CPU在3%左右。

卷复制也是软件复制大概需要占用10%或更多的资源。

而磁盘阵列复制不占用主机资源，但是要求更为高性能的磁盘阵列。

因此综合起来GoldenGate占用资源依然是相对较低的。

 

• 只能做异步复制

磁盘阵列复制和卷复制可以做近距离的同步复制，如果是距离超过一百公里同样无法做到同步复制。

四、维护工作较多

本文永久链接地址：https://www.askmac.cn/archives/goldengate-ogg-安装实施最佳实践.html

GoldenGate OGG 安装实施最佳实践 

GoldenGate OGG 安装实施准备

安装信息收集

• 收集客户信息（建议至少提前两周）

–测试环境，操作系统、数据库、网络等

–数据结构，包括表数量、是否存在无主键表、是否有不支持数据类型、是否有不支持操作（如direct insert等）等

–客户需求、测试场景、（竞争对手）

• 一定要验证OGG版本可用性！！！

–Metalink上面有很多edelivery上所没有的patch可用于POC测试

带宽估算

• 根据峰值产生日志量估算带宽占用
• 假设条件

–假设OGG队列与日志比例为1：4。如只复制部分表则此比例可以假设为更低。

–假设网络传输效率为0.7

–假设网络传输压缩比例为1：8。根据数据内容有所变化，一般字符数据较多时压缩比例较大，二进制对象压缩效率较低

• 带宽估算算法

–以客户业务高峰期每小时产生40G为例，可以估算如下

–

带宽=40G/3600（秒/小时）/ 4(日志过滤比例)/8（压缩比率） * 8（每字节8位） /0.7(网络传输效率)=4M

 

实施准备

–实施文档准备

• 拟定安装操作文档
• 拟定初始化方案并与客户达成一致

–根据测试场景准备

• 数据库脚本，如建立用户、赋予权限等
• 准备OGG安装所需脚本，如add trandata命令脚本、目标端禁止trigger和cascade delete脚本等
• OGG参数文件，列出所有可能用到参数
• OGG命令，常用命令预先放在文本里
• 验证参数、命令、脚本的可行性
• 发现潜在的问题，及时寻求解决方案

–预订技术支持

–

注意：OGG参数文件中所有关键字或“，（）”等分割符前后应当加入空格(半角！)，否则可能会被误认为连续的字符串，导致进程终止

 

本文永久链接地址：https://www.askmac.cn/archives/goldengate-ogg-安装实施最佳实践.html

实施准备 –系统设置（源和目标）

• 建立GoldenGate运行用户

–需访问数据库的动态库、在线日志及归档日志

–使用oracle用户，也可为其创建新的系统用户将其加入到oracle安装用户所在组（一般为oinstall）。

–为GoldenGate运行用户配置内存限制

• 分析和抽取交易数据需一定内存，需放宽GoldenGate运行系统用户对内存大小（memory）、文件大小(fsize)、DATA、STACK等参数的值，在系统允许的情况下尽量将参数设置为-1（ulimited），一般在/etc/security/limits文件中。
• RAC各节点配置时钟同步

–GoldenGate在单节点上对所有节点日志进行解析，为了保证其在各节点抽取数据顺序的一致性，需要在各个节点主机上配置时钟同步（例如在AIX下配置NTP服务）。

 

 

实施准备 –网络设置

 

• OGG所有源端必须能够访问其目标主机以下端口

–目标端OGG的Mgr端口（缺省为7809）

–目标端Mgr参数DYNAMICPORTLIST中定义的端口范围。如Mgr参数文件没有配置，则自动从7840开始递增，建议保留到7850

–目前尚未有目标主机需访问源端主机的端口需求

• Director Server必须能够访问其管理的OGG主机以下端口

–目标端OGG的Mgr端口（缺省为7809）

–目标端Mgr参数DYNAMICPORTLIST中定义的端口范围。如Mgr参数文件没有配置，则自动从7840开始递增，建议保留到7850

• 受管理的OGG主机应当能够访问Director Server主机所有端口

–尚需证实，Director Server发起的与OGG通讯端口目前是随机的

• Veridata Server需访问需对比的数据库主机中

–Veridata Agent的Mgr端口

–Veridata Agent的DYNAMICPORTLIST中定义的端口（缺省为7840起）

–是否需其它端口尚需进一步证实

–

 

实施准备 – 存储空间（源和目标）

• 为GoldenGate分配空间

–建议在共享阵列，可以在单节点失败后由其它节点接管，通过脚本可以与集群软件集成

–GoldenGate软件所需空间主要取决于队列的产生速度，一般建议为其保留相当于数据库1-3天归档日志量的存储空间。

–存储划分完后建立OGG安装目录并将该目录Owner设为OGG运行用户

• 为数据库保留3-5天归档日志

–在重启时需要从上次读取日志重新开始

–长交易需要其开始时段的日志

–当前理论上可以通过脚本获取当前GoldenGate所需日志序列号，然后与RMAN等工具集成控制归档日志自动删除。在OGG后继版本会有所增强。

 

实施准备 – 数据库（源）

• 打开归档模式

–避免OGG重启无法找到对应日志

• 配置parallelism（仅针对Oracle 9i）

–将LOG_PARALLELISM参数设为1，OGG不支持大于1

• 关闭recycle bin（仅针对DDL复制）

–Oracle 10g R2 and later: 将RECYCLEBIN初始化参数设置为OFF.

–Oracle 10g R1: 将 _RECYCLEBIN初始化参数设置为FALSE.

 

 

OGG GoldenGate 安装实施操作步骤

OGG软件安装  （源和目标）

• 上传和解压OGG软件

–检查安装目录Owner是否是OGG运行用户

• 配置环境变量

–如使用Oracle运行用户一般无需调整

–如非Oracle用户则建议拷贝Oracle的profile文件，至少需配置如下环境变量

• PATH
• ORACLE_SID
• ORACLE_HOME
• LD_LIBRARY_PATH (Solaris, Linux), LIBPATH (AIX), SHLIB_PATH (HPUX)
• 配置完毕可以通过能否执行sqlplus进行初步验证

–使用ulimit –a检查内存等限制

 

 

• 执行ggsci,检查是否能够进入OGG命令行界面
• 执行create subdirs创建子目录
• 执行edit param mgr为manager配置参数,然后尝试启动mgr进程

如以上步骤均能顺利执行,则表明初步安装成功.由于以上步骤并不影响生产库运行,可以在实施前几天提前完成.

 

打开附加日志（源）

• 以渐进模式打开附加日志

–第一步,在晚上或其他业务较空闲时段打开数据库级最小附加日志

–第二步,经过一段时间运行观察数据库最小附加日志对数据库是否有影响,观察日志量的增加

–第三步,同样选择空闲时段打开所需复制表的附加日志

–第四步,经过一段时间运行观察数据库是否有性能下降,归档日志量是否有明显增加

• 如何降低附加日志影响 （☆）

–排除一些应用的中间表

–尽量排除无主键和唯一索引表(记录全部列会导致日志量显著增加)或给他们加上主键

 

创建OGG所需数据库用户（源和目标）

• OGG用户在源端所需权限(DML)

–GRANT CONNECT TO goldengate;

–GRANT ALTER ANY  TABLE TO goldengate; //用于添加表附加日志

–GRANT ALTER SESSION TO goldengate;

–GRANT CREATE SESSION TO goldengate;

–GRANT FLASHBACK ANY TABLE TO goldengate;

–GRANT SELECT ANY DICTIONARY TO goldengate;

–GRANT SELECT ANY TABLE TO goldengate;

–GRANT RESOURCE TO goldengate;

• 目标端DML复制需所有源端权限加上

–GRANT INSERT ANY TABLE TO goldengate;

–GRANT UPDATE ANY TABLE TO goldengate;

–GRANT DELETE ANY TABLE TO goldengate;

• 如需复制DDL,则两端均需要sysdba权限

–grant sysdba to goldengate;

 

OGG最佳实践 – 宕机初始化

• 完成前面所述的所有准备工作
• 根据约定时间停止业务应用
• 源端

–锁定除去OGG数据库用户以外其余所有用户

–停止Oracle内部的所有Job

–关闭数据库

–重新启动数据库

–配置OGG抽取进程和本地队列

–启动OGG抽取进程,验证

• 抽取进程是否可以正常启动,主要是验证是否能正常读取日志
• 观察是否有数据被抽取出来,如有则说明尚有其它连接在修改数据,需找出原因并停止

–停止OGG抽取进程

–可使用脚本记录部分主要表或所有表记录总数

–关闭数据库

本文永久链接地址：https://www.askmac.cn/archives/goldengate-ogg-安装实施最佳实践.html

 

• 源端

–使用RMAN/可传输表空间/BCV等方式将数据导出

–在源端打开数据库

–启动源端抽取进程(也可重新配置一遍,注意清除旧的队列)

–解开锁定的其它用户,恢复job

–启动应用

–观察数据抽取是否正常

• 目标端

–将数据导入到目标库

–打开数据库

–解锁其它用户(如允许也可保持锁定状态防止修改数据)

–对比记录的源端数据库记录数与目标记录数是否相同,验证恢复完成

–禁止目标库Trigger

–禁止目标库中cascade delete

–处理其它对象如删除或者重建物化视图等

 

 

• 源端

–配置Data Pump和远程队列

–启动Data Pump观察数据传输是否正常

• 目标端

–配置Replicat

• 注意目标端用户权限比源端多几个

–启动Replicat观察数据是否正常

• 注:此时一般将reperr设置为abended模式(即默认模式)并配置discardfile参数,遇有错误进程可以立即中止,便于及时查找错误

–如Replicat速度跟不上队列增长速度,需进行Replicat拆分,具体方法见调优部分

 

OGG最佳实践 – 基于SCN号的无宕机初始化

• 前提条件

–客户具有能够将目标恢复到某一特定SCN号的备份/恢复工具

• RMAN (强烈推荐)
• Exp/imp (未验证过)
• 操作步骤

–源端

• 完成前面所述的所有准备工作
• 配置OGG抽取进程和本地队列
• 启动OGG抽取进程并记录开始时间
• 查询数据库中当前交易最早的开始时间,直到该时间超过OGG抽取启动时间点 (Why?)
• 查询和记录此时SCN号为最小所需SCN
• 可每隔半小时或一小时重新查询SCN号和记录此时全库所有表或部分关键业务表中记录数

–

 

• 目标端

–使用备份/恢复工具恢复目标库到指定SCN号

• 如果是RMAN可以边恢复边观察,直到恢复出来的SCN号和时间点大于记录的最小所需SCN号

–查询目标库中全部表或关键表记录,看其是否大致符合源端记录数

• 源端

–使用logdump查找目标SCN的相邻SCN号

• 可以在logdump中通过ggstoken detail显示SCN号
• 注意:SCN号只存在于每个交易的第一条记录中
• 注意:logdump没有命令定位相邻SCN,只能首先通过时间戳判定应该在某几个队列文件中,然后检查各个队列中第一个记录的SCN号,再根据二分发查找符合条件的SCN边界

–查找该位置之前小于该SCN号的若干条记录, 其在目标端状态应为

• Insert:应当在目标端存在
• Delete:应当在目标端不存在
• Update:应当在目标端存在,但具体值可能与目标不符(Why?)

• 源端

–查找该位置之后大于该SCN号的若干条记录,对其在目标端状态进行核实

• Insert:应当在目标端不存在
• Delete:应当在目标端存在
• Update:应当在目标端存在

–如通过上面几条验证,则证明目标确实精确恢复到指定SCN

–对目标端Trigger/Cascade Delete/物化视图等进行处理

–配置Data Pump并启动数据传输

• 目标端

–配置Replicat

• 注:此时一般将reperr设置为abended模式(即默认模式)并配置discardfile参数,遇有错误进程可以立即中止,便于及时查找错误

–使用以下命令启动Replicat

• Start myrep, AFTERCSN <目标恢复到的CSN>

–观察数据复制是否正常

 

Replicat使用数据库检查点

 

• Replicat的数据库检查点是可选的，但强烈建议采用

–文件检查点的读写与交易的提交是分离的

–数据库检查点可以与交易一起进行提交，可以更好的保证数据一致性

• 使用数据库检查点的方法

–在OGG安装根目录下编辑GLOBALS文件加入一行指定检查点表：

CHECKPOINTTABLE goldengate.checkpoint_tab

–重起Mgr进程，进入ggsci生成检查点表（该用户需要有建表权限）：

dblogin userid goldengate, password goldengate

add checkpointtable

–添加Replicat时不要使用nodbcheckpoint，会自动使用预定义检查点表

add rep repda, exttrail /ggs/dirdat/da

• 问题：GGS ERROR 516 Extract read…

–可能原因是检查点表不存在或者表中该进程对应检查点行已损坏

–通过info replicat命令查看文件检查点，若无问题可以在OGG安装目录下使用convchk工具使replicat重启时重建检查点表中的检查点

convchk <group name> <schema>.<table>

 

目标库常见特殊处理

• 禁止目标端所有Trigger,防止次生数据产生
• 禁止目标端所有cascade delete引用,OGG复制过来的delete操作会跟自动删除产生冲突
• 物化视图

–删除目标端无用的物化视图

–如目标端需要物化视图,则可以在目标端重建,避免使用OGG复制物化视图本身数据

–如需复制源端物化视图到目标物化视图,需参考相关手册

–注意:物化视图均包含有一个基表,在参数文件中使用*时需要通过tableexclude或者mapexclude排除

 

 

GoldenGate OGG 配置日常复制错误处理 

 

OGG最佳实践 – 配置数据复制错误处理

 

• 一般只针对于目标端的Replicat进程
• 常用参数

–reperror default, ABEND | DISCARD | IGNORE

• Abend （缺省模式），遇错即停，等待处理错误后再重启。建议配置为日常复制正常运行模式。
• Discard，将出错数据放到discardfile供以后分析，继续处理以后数据。仅用于确认已知有部分错误数据，又不想影响后继处理的情况。注意：如果出错数据较多会堆满discardfile，而且有可能忽略掉未知的数据错误，所以最佳选择依然是重新初始化该部分数据或者改变复制范围并使用abend模式。

–ddlerror default, ABEND | DISCARD | IGNORE

• 缩小复制范围，只复制必须的DDL操作，错误处理设置为abend模式（缺省）

–DISCARDFILE discard.txt, APPEND | PURGE, MEGABYTES <n>

• 该参数不是必须参数，但是一定要配置
• 一旦数据出错，可以找到出错数据的详细信息

 

• 常用参数

–HANDLECOLLISIONS

• 依据主键处理冲突数据，一般只用于初始化
• 对于无主键表无法处理冲突，可能会导致重复记录
• 打开此参数则所有数据错误不管reperror如何配置均不再写discard文件，即所有数据冲突信息被默认规则处理，没有任何日志，因此日常复制不建议使用该参数
• 可予以考虑的特殊场景

–只需新增数据，无需复制历史数据

–

–

注意：该参数仅处理数据本身的Insert/Delete冲突，如果出现两端映射或其它结构性问题Replicat进程依然会abend，不能被忽略

 

 

 

 

 

 

本文永久地址：https://www.askmac.cn/archives/goldengate-ogg-回切方案.html

GoldenGate OGG 回切方案

 

回切步骤

1.恢复生产系统数据库服务，如果数据库可以直接恢复，只需要处理数据增量同步，如果数据库本身不可恢复，需要从应急系统向生产系统进行全量数据初始化

2.在生产数据库上禁用触发器和数据约束

3.启动生产数据库的数据投递进程，从应急数据库向上产数据库同步数据

4.应急系统积压的数据处理完毕，生产系统数据实现与应急数据库的同步

5.停止应用运行，确认数据已经完全同步回生产系统（数据对比见下文)

6.启动生产系统的数据捕获进程

7.启用生产系统数据库的触发器和数据约束

8.重置生产系统数据库的Sequence

9.修改应用的数据源配置到生产系统数据库

10.启动应用

11.禁用应急数据库的触发器和数据约束

12.确认应急数据库的数据同步配置包含Sequence，启动应急数据库的数据投递进程

13.监控数据同步情况和系统运行情况。

 

 

应急系统向生产系统回切（https://www.askmac.cn/）

6.1 回切条件

原有生产系统恢复运行，如果原生产系统数据可以恢复，首先完成从生产向应急的剩余数据

同步过程，然后启用生产系统的投递进程，把应急系统运行期间处理的数据同步回生产系统，

应急系统的积压数据处理完成后即具备向生产系统回切的条件。

6.2 回切操作

如果生产系统中存在强制性自增列则：

1. 应急系统向生产系统进行全量数据初始化，并开始捕获应急系统的增量数据
2. 在生产数据库上禁用触发器和数据约束
3. 启动生产数据库的数据投递进程，从应急数据库向上产数据库同步数据
4. 应急系统积压的数据处理完毕，生产系统数据实现与应急数据库的同步
5. 停止应用运行，确认数据已经完全同步回生产系统
6. 启动生产系统的数据捕获进程
7. 启用生产系统数据库的触发器和数据约束
8. 修改应用的数据源配置到生产系统数据库
9. 启动应用
10. 禁用应急数据库的触发器和数据约束
11. 确认应急数据库的数据同步配置，启动应急数据库的数据投递进程
12. 监控数据同步情况和系统运行情况。

如果生产系统中不存在强制性自增列则：

1. 恢复生产系统数据库服务，如果数据库可以直接恢复，只需要处理数据增量同步，如果数据

库本身不可恢复，需要从应急系统向生产系统进行全量数据初始化

2. 在生产数据库上禁用触发器和数据约束
3. 启动生产数据库的数据投递进程，从应急数据库向上产数据库同步数据
4. 应急系统积压的数据处理完毕，生产系统数据实现与应急数据库的同步
5. 停止应用运行，确认数据已经完全同步回生产系统
6. 启动生产系统的数据捕获进程
7. 启用生产系统数据库的触发器和数据约束
8. 修改应用的数据源配置到生产系统数据库
9. 启动应用
10. 禁用应急数据库的触发器和数据约束
11. 确认应急数据库的数据同步配置，启动应急数据库的数据投递进程
12. 监控数据同步情况和系统运行情况。

 

回切步骤

1.在生产端， 停止旧的extract进程

2.在生产端，禁止和复制表相关的cascade constraints，disable表的外键,修改表的强制自增列为默认自增列

3.在生产端， 添加、配置并启动replicat进程，准备应用来自于应急端的数据

4.在应急端， 添加并启动data pumb进程， 将增量数据传送到生产端

5.在应急端，启动监测日志extract进程,扑捉数据库新生成的数据，并传递给data pump.

6.在生产端和应急端，观察数据同步情况，如果数据大致持平那么

7.在应急端， 停止业务应用

8.在生产端，观察数据是否已经完全同步（数据对比见下文)

9.在生产端， 如果数据已经完全同步， 则停止并删除replicat

10.在生产端，启用和复制表相关的cascade constraints,和相关外键约束

11.在生产端，添加并启动extract进程，用于捕获生产端的增量数据

12.在生产端， 启用业务应用

13.在应急端， 停止extract进程和data pumb 进程

14.在应急端，禁止和复制表相关的cascade constraints

15.在应急端，添加并启动replicat

16.在生产端，添加并启动data pumb，将增量数据同步到应急端

回切前的数据比对

数据比对的总体方案

• 数据比对的目的是：确认应急库上所有的更新是否都已经被应用到生产端，即验证应急与生产库的数据一致性。
• 经过与国内售前、售后部门多个资深GoldenGate工程师的深入交流，对于VLDB，只能采用一种基于客户业务数据的比对方案，即：
• 根据表中数据的性质，将全部进行复制的表进行分类。
• 每种类别，采用不同的方式进行比对。

 

回切前的数据比对

数据复制中的比对

• 应急库的数据是动态的。
• 在不停止GoldenGate的情况下，生产库的数据也是动态的。
• 一种比对方案是：计算并比较日志表中历史记录的数量，也可以比较某些字段的sum值。
• 比如，可以将按日期字段进行分区的表作为日志表。
• 将分区字段作为查询条件，计算记录数。（https://www.askmac.cn/）

select count(*)

where part_key between to_date( ‘20121028’ ) and to_date( ‘20121029’ )

 

数据类型	数据重要性	数据量	数据比对方式
日志表	一般	大	对比最近某天的记录数，并且计算sum值

 

• 在停止了应用、源库的数据不再被更改后，对比应急库与生产库。
• 数据已经为静态的。
• 一种分类比对方案是：

 

数据类型	数据重要性	数据量	数据比对方式
客户资料表	最为关键	很大	•对比全表的记录数；•对于关键字段（比如具有账户金额性质的字段）获取全部记录的 sum 值，再进行比对。
码表、其它小表	最为关键	小	利用 select minus 语句，对于源、目标库执行两遍全表的数据对比（分别为从源到目标、从目标到源）。
日志表、其它大表	一般	超大	对比全表的记录数

 

 

两端数据不一致的排查与解决

1.数据复制本身的延时

2.目标库数据库内部存在内部导致修改数据的对象和机制

3.操作系统上的job Scheduler

4.OGG的错误处理模式设置

5.修改OGG的检查点

6.OGG配置的逻辑错误

7.OGG配置参数的正确性

8.其它可能导致数据不一致的因素 如人工误操作

 

 

两端数据不一致的排查与解决

现象

在执行数据对比过程中，部分网省的业务系统中发现有部分表在两端的记录是不一致的。

原因分析与排查

两端出现数据不一致的原因非常多，下面是对比结果有差异的一些可能性因素：

数据复制本身的延时

由于源端数据可能一直在变化，而对比只能取当时时间的数据，两端取出来的数据有一定差异，所以有可能带来对比结果不一致。

此时并不一定是复制出现问题，可以针对这些不一致的记录做进一步的观察，过一段时间进行再确认。

目标库数据库内部存在内部导致修改数据的对象和机制

可能包括数据库中的对象：如没有被禁止的trigger、自动运行的job等。

操作系统上的job Scheduler

可能是存在操作系统上的job，可以检查其所有用户的crontab等自动任务管理器。

OGG的错误处理模式设置

OGG的replicat里面的错误处理模式默认为是abend模式，即只要有数据问题进程就会出错结合监控告警：

REPERROR DEFAULT, ABEND

该参数的其它配置包括DISCARD和IGNORE模式。如果是discard模式，则出错会被写到discard文件里面，可以查找discardfile指定的该文件是否有出错记录；而如果是ignore模式则会忽略所有错误，而且不记日志。

请务必将Replicat错误处理机制设置为abend模式！仅仅在错误处理等特殊情况下配合技术支持使用DISCARD模式。

修改OGG的检查点

人为修改OGG的检查点有可能带来数据不一致，包括使用alter命令修改主extract/data pump/replicat等。所有ggsci中对进程的操作记录都记录在ggserr.log里面，只要用户没有手工清除，可以通过对该文件进行分析观察是否修改过检查点。

OGG配置的逻辑错误

主要包括以下配置复制关系时的错误：

所有Extract表的复制范围必须是互补的，且互不交叉的，不能存在需要复制但不包含在任何一个主extract中的情况；

Data Pump的复制范围必须和主Extract保持一致；

Replicat的复制范围同样必须对应于主Extract和Data Pump的所有表，且负责相同队列的各Replicat之间互补和无交集；

 

OGG配置参数的正确性

有时如果OGG的参数文件中语法问题也会造成数据不一致。例如：

在Extract的table语法错误。正确语法：

table ggs1.tcustmer;

即table关键字+空格+schema.tablename+分号。

Replicat的map语句出现错误。正确语法：

MAP ggs1.TCUSTMER, TARGET ggs2.TCUSTMER;

即map关键字 + 空格 + source_schema.source_tablename + 逗号 + 空格 + target关键字 + source_schema.source_tablename + 分号。如果写错格式会导致OGG无法将正确数据投递到目标表。

OGG的关键字前后、逗号前后建议加入空格（英文，一定不要用全拼），一行的开头不用。OGG有时会将中间没有空格的多个关键字连在一起视作一个字符串。

不可使用word等格式化工具编辑OGG参数然后上传，可能会带来比如空格、换行等问题。

 

其它可能导致数据不一致的因素

如人工误操作。为了减少类似可能出现的问题，建议在日常灾备运行状态下目标数据库disable除去OGG的用户之外的其它所有用户，等接管时再重新enable。

 

如果以上均没有问题，可以提供源库和目标库的以下资料，由技术支持进行分析：

OGG的ggserr.log

所有的报告文件

丢失数据的大致操作时间

丢失数据相关时段的归档日志

 

 

解决方案

1.人工补足少量的数据

2.执行部分表的初始化

3.全部重新初始化

根据不一致数据表的多少以及不一致数据的条数，可以采取以下方案：

人工补足少量的数据

在确认只有部分表的若干条数据不一致后，可以使用手工方法对不一致的数据进行重新再同步，即从源端找出当前的值，覆盖目标表的相关记录。本方法只适用于不一致数据较少的情况，如从discard文件中可以找到有限的出错记录。

执行部分表的初始化

当其中某些表不同步，而数据条数较多时，可以对该部分表执行重新初始化，具体步骤参见运维文档的第5.5节。

全部重新初始化

当大部分表出现不一致的情况时，需要对全库执行重新初始化，可以按照安装实施文档的步骤执行，之前请务必保证安装实施文档中的步骤正确性，如有问题可以联系技术支持。

 

 

 

本文永久链接： https://www.askmac.cn/archives/goldengate-ogg-issues.html ‎

GoldenGate OGG Extract常见问题

Extract: Application failded to initialize（Win）

错误描述：

run ggsci command but the Alert window report “Application failded to initialize(0xc000026e)”

错误分析：

–GoldenGate在Windows平台上需要安装Microsoft Visual C ++ 2005 SP1 Redistributable Package

–如果是Microsoft Itanium平台,需要安装vcredist_IA64.exe

–Windows 2008需以下额外操作

• 右击‘cmd‘ (DOS), 选择’run as administrator’，然后在该命令行窗口中启动mgr和extract才能够读取数据库日志；
• 将OGG安装为服务 时(即运行“install ADDSERVICE”)，需要使用管理员权限.这样启动服务后即能访问日志。
• 通过以下方法为运行mgr和extract的用户添加读取日志文件的权限.
  右键点击文件 ->property->security->Edit->add

 

Extract: Cannot load program ./ggsci . . .

错误描述：

./ggsci  exec(): 0509-036 Cannot load program ./ggsci because of the following errors:

        0509-150   Dependent module libclntsh.a(shr.o) could not be loaded.

        0509-022 Cannot load module libclntsh.a(shr.o).

        0509-026 System error: A file or directory in the path name does not exist.

错误分析：

–请首先检查该OGG Build是否与操作系统和数据库相符

–其次如果是Aix请检查xLC版本是否符合10.0以上

–检查环境变量中动态库路径是否包含了数据库动态库目录，

例如：export LD_LIBRARY_PATH=$ORACLE_HOME/lib

–不同平台下的环境变量不同：

• Aix： LIBPATH
• Solaris、Linux等： LD_LIBRARY_PATH
• HP-Unix：SHLIB_PATH

–重设环境变量需重启Mgr和Ext/Rep进程

 

 

Extract: Block size mismatch (8192/512) …

错误描述：

 2010-04-22 17:58:23.872  Redo thread 2: No positions processed, Block size mismatch (8192/512) reading redo log /dev/rora_redo22_256m for sequence 11812, …

错误分析：

–裸设备的偏移量各操作系统默认为0，但AIX默认为4096.

–当创建裸设备时使用了-TO选项时，Oracle不会跳过4096字节而是直接从0开始读写。

–因此在AIX下使用裸设备时，出现此错误需要指定OGG从偏移量0开始读取

tranlogoptions rawdeviceoffset 0

–该参数其在实际环境中使用几率非常高

• 在9.0以前是公开参数，目前版本只存在于内部文档中
• 在以前版本中如果缺少此参数Extract立即终止，但新版本Extract会持续进行尝试，并不自动终止，需检查报告文件

 

Extract: ORA-15000 ASM connection error

错误描述：

 GGS ERROR       182  Oracle GoldenGate Capture for Oracle, extbill.prm:  OCI Error beginning session (status = 15000-ORA-15000: command disallowed by current instance type).

错误分析：

–该错误为OCI错误，表示Extract是在连接数据库时出现问题，根据错误信息判断为权限问题

–首先在Extract参数中检查ASM相关参数

tranlogoptions asmuser sys@+ASM1, asmpassword oracle

–检查tnsnames.ora和listener.ora验证ASM实例配置正确

–确认ASM用户具有SYSDBA 权限；如果使用SYS,需要将ASM实例的init.ora中REMOTE_LOGIN_PASSWORDFILE参数设置为SHARED. （多个数据库可以使用一个password文件，只有SYS用户可以远程登录.）

–使用sqlplus验证

sqlplus sys/oracle@asm1 as sysdba；可以登录

sqlplus sys/oracle@asm1 ；报告15000错误

 

 

Extract: Could not find archived log…

错误描述：

 Redo thread 2: Could not find archived log for sequence 5242 thread 2 under default destinations SQL <SELECT  name    FROM gv$archived_log   WHERE sequence# = :ora_seq_no AND         thread# = :ora_thread AND         resetlogs_id = :ora_resetlog_id AND         archived = ‘YES’ AND         deleted = ‘N>, error retrieving redo file name for sequence 5242, archived = 1, use_alternate = 0…

错误分析：

–OGG会缺根据gv$archived_log查找归档日志位置.

–可以通过参数指定归档日志目录

 tranlogoptions PRIMARY altarchivelogdest instance ora1 /arch1, altarchivelogdest instance ora2 /arch2

–配置该参数并加入primary选项可以避免Extract持续查询归档日志位置，降低对主库的压力，建议无论归档日志是否放在数据库中指定位置均应配置此参数

 

 

Extract: Encountered SCN That Is Not Greater Than The Highest SCN Already Processed …

错误描述：

 GGS ERROR    180  encountered commit SCN 2187.3361189672 that is not greater than the highest SCN already processed

原因分析：

–在Oracle RAC环境中，Extract会启动一个coordinator线程对各个节点上的操作进行根据SCN进行排序，它在交易提交后会等待THREADOPTIONS MAXCOMMITPROPAGATIONDELAY 参数所定义时间来确认空闲节点没有交易，然后再收集交易数据；写入该交易后如果空闲节点后来又读到了一个SCN号要小的交易，则会报告该错误

–可能原因：

• 各节点之间没有配置时钟同步
• 一个节点比另外一个节点慢（IO问题可能性较大）

解决方法：

–在各节点之间配置时钟同步（如NTP服务）

（Q：为什么RAC环境下一个Extract最多可占用N+1个CPU？）

 

 

解决方法（续）：

–调整Extract参数

THREADOPTIONS MAXCOMMITPROPAGATIONDELAY <msec> IOLATENCY <msec>

• MAXCOMMITPROPAGATIONDELAY有效范围是0-90000ms，缺省为3s（即3000ms）.
• GGS V9.x多了一个IOLATENCY参数，可以与上面参数一起加大等待时间。IOLATENCY缺省为1.5s，最大值为180000
• 建议出现180错误后可以将此二参数设置为较大值，然后逐步降低获取最佳设置

–说明：

• 出现此错误后，因后面的交易可能已被写入日志，重启Extract可成功启动，但是可能出现如下问题：

–Extract会重写当前队列覆盖前面的交易数据，后面的Data Pump进程可能会出现abend with incompatible record errors错误终止（旧版本可能出现）

 

Extract: Encountered SCN That Is Not Greater …
& GGS ERROR    ZZ-0RG  The previous run abended due to an out of order transaction…

• 在新版本的OGG（10.0+）中，如果出现Encountered SCN That Is Not Greater 后，Extract重启可能出现错误：

–GGS ERROR    ZZ-0RG  The previous run abended due to an out of order transaction. Issue ALTER ETROLLOVER…

–此错误是出现Encountered SCN That Is Not Greater错误后Extract无法自动修复（当前正在开发自动修复功能），需通过人工操作予以恢复，修复方法可以参照Doc ID 987379.1，也可参考下述方法

• 恢复步骤（非正式）

–停止所有Data Pump和Replicat

–针对所有的Extract记录其Write Checkpoint的队列Seqno；

–对于每个Extract向下滚动一个队列

ALTER EXTRACT [name], ETROLLOVER

–启动Extract查看是否滚动到了下一个队列，记录其新队列seqno，应当是旧队列号+1

–

 

• 恢复步骤（续）

–修改Data Pump从新的队列开始传输

ALTER EXTRACT [pump_name], EXTSEQNO ##### EXTRBA 0

–重启Data Pump查看是否能够重启成功并从新的队列传输

–修改replicat参数文件，加入或者打开HANDLECOLLISIONS，如果有GROUPTRANSOPS和MAXTRANSOPS请注释掉

–启动Replicat，观察其是否能够读取新传输过来的队列

–如Replicat无法自动滚动到下一个队列，需要通过alter replicat [replicat_name], EXTSEQNO ##### EXTRBA 0手工滚动。

–等待Replicat处理到结尾没有延迟时，可以关闭HANDLECOLLISIONS和恢复原来的GROUPTRANSOPS和MAXTRANSOPS参数

–重新启动Replicat即可恢复正常复制。

 

 

Extract: GGS ERROR 146  NUMCNV_getNumeric

错误描述(askmac.cn)：

2010-05-26 10:05:05  GGS ERROR       146  NUMCNV_getNumeric(char *, size_t, int64_t *, short *, BOOL): Buffer overflow, needed: 20, allocated: 19

错误分析：

–该问题一般出现在sequence复制中（也曾出现在表复制中）

–参考Bug 9734755: OGG EXTRACT CAUSES GGS ERROR 146 – NUMCNV_GETNUMERIC: BUFFER OVERFLOW

–在OGG的10.4.0.68.002以后版本已经修复

 

filter无法正常工作

错误描述：

TABLE demo_src.people,  FILTER (age > 50);

添加后无法正常工作，update时filter不起作用

注意：在过滤出现问题时OGG并不报告错误

 

错误分析：

–该配置从语法看没有错误，但是对比的列age如果不是主键，则update在日志中不存在该列值，也就没有办法通过该列进行比较

–解决方法为Add trandata demo_src.people, cols (age)强制为该列加入附加日志

–

–注：也可通过fetch从数据库中读取该记录进行比较（只能在源端抽取进程），如下所示（此方法每条记录均需要访问数据库，导致复制效率降低）：

TABLE demo_src.people, FETCHBEFOREFILTER, FETCHCOLS (age), FILTER (age > 50);

 

 

Data Pump: ERROR 112 network communication

错误描述：

2010-05-18 10:10:20  GGS ERROR       112  There is a problem in network communication, a remote file problem, encryption keys for target and source do not match (if using ENCRYPT) or an unknown error. (Remote file used is ./dirdat/contact/EC001606, reply received is Unable to lock file “./dirdat/contact/EC001606″ (error 13, Permission denied).

 

错误分析：

–如果使用主机名确认hosts里面包含有该主机IP的解析

–确认可以通过telnet访问参数rmthost配置的远程主机mgr端口

–停止其它所有Data Pump查看目标端是否存在server进程（即collector进程），如果存在则通过kill杀死该进程重启Data Pump

–确认目标端Manager进程中是否配置了dynmaicportlist，有可能因为指定端口范围太小或者被其它应用占用了端口导致无法连接，可以调大端口范围后再试（一般1个Data pump需一个端口，如有Director则需多保留几个端口）

–检查传输是否使用了加密

 

 

Extract:源数据库性能降低，出现大量等待会话…

错误描述：

源端数据库主机的ora_lms和ora_lmp进程占用大量资源，出现大量control file sequential read等待会话…

错误分析：

–Extract参数

EXTRACT mer_ext

USERID ggs, PASSWORD ggs

EXTTRAIL /home/ggs/dirdat/et

FLUSHCSECS 3

EOFDELAYCSECS 3

TABLE orange.ITEMS;

–Data Pump参数

EXTRACT mer_pump

USERID ggs, PASSWORD ggs

RMTHOST cblhprac1, MGRPORT 7810

RMTTRAIL /home/ggs/10.4/dirdat/et

FLUSHCSECS 3

EOFDELAYCSECS 3

TABLE orange.ITEMS;

 

–建议

–Data Pump去掉USERID参数并加入Passthru

–FLUSHCSECS 3 全部去掉或者改为FLUSHSECS 3

–EOFDELAYCSECS 3全部去掉或者改为EOFDELAYSECS 3

 

GoldenGate OGG replicat常见问题

 

数据复制典型错误 – GGS ERROR 101 Invalid option for MAP…

错误描述(askmac.cn)：

GGS ERROR 101 Invalid option for MAP: TOKENS(TKN-

USERID=@GETENV(“TRANSACTION”..

错误分析：

–101错误为参数错误，表明当前MAP语句中语法出现问题

–查看该行参数语法没有发现错误，如下所示：

MAP AU.JOBS, TARGET NZ.JOBS,

COLMAP (USEDEFAULTS,

TRAN_TIME = @TOKEN(“TKN-COMMITTIMESTAMP”),

DB_USER = @TOKEN(“TKN-USERID”),

OP_TYPE = @TOKEN(“TKN-OPTYPE”);

–出现错误原因是OGG解析参数文件时可能会把函数等关键字（如TOKEN）和括号等连续在一起的字符认为是一个关键字

–在TOKEN后面和括号之间加入一个空格重启即可

说明：日常要养成在OGG参数文件中关键字和各中符号前后加入空格的良好习惯。

 

 

数据复制典型错误 – SQL error 1403 mapping

错误描述(askmac.cn)：

2010-02-25 13:20:08  GGS WARNING     218  Oracle GoldenGate Delivery for

Oracle, rep_stnd.prm:  SQL error 1403 mapping HR.MY_EMPLOYEE to HR.MY_EMPLOYEE.

错误分析：

–可能原因包括：

• 两端结构不一致（异构环境，列和主键不同）
• 两端有不一致记录
• 附加日志不全

–可以到discard文件中查看具体错误信息，如果为update 或者delete找不到对应记录，并且某几个字段为空，则可认定为缺少了附加日志

Problem replicating GGS1.HISCUSTMER to GGS2.HISCUSTMER

Error  occurred with delete record (target format)…

*

CUST_CODE = 

 *

注意：添加表的附加日志是即时生效，如extract已经将数据抽入队列,则重新添加附加日志后进行重新初始化，旧的队列数据不能被继续使用

 

数据复制典型错误 – GGS ERROR 160 Use ALLOWNOOPUPDATES to process the update

错误描述：

2010-05-07 10:16:01  GGS ERROR       160  Encountered an update for target table

 CASEM.BILLING_ERROR_TEMP, which has no unique key defined.  KEYCOLS can be used

 to define a key.  Use ALLOWNOOPUPDATES to process the update without applying i

t to the target database.  Use APPLYNOOPUPDATES to force the update to be applie

d using all columns in both the SET and WHERE clause.

错误分析：

–首先确认该表正确添加了附加日志，若附加日志正确则原因为下说述

–当Update一条记录但是未修改其中某些字段记录时，Oracle会在日志中记录该Update操作，但是由于数据本身没有改变，可能并没有记录其后影像。此时OGG抽取数据后队列中也没有后影像，导致目标端Replicat无法组成正确SQL

• 例如，表T中有一条记录其字段C原来值为‘a’，如果update t set c=‘a’ where rowid=‘XXXXXXX’即会产生该情形

–解决方法正如错误描述中说述在参数中加入即可继续

ALLOWNOOPUPDATES

注意：该参数是一个内部参数

 

DB2典型错误 – SQL0798N  不能对定义为 GENERATED ALWAYS 的列 “ID” 指定值

 

错误描述：

2010-01-13 13:43:31  GGS WARNING     218  Aborting BATCHSQL transaction. Databas

e error -798 ([IBM][CLI Driver][DB2/NT] SQL0798N  不能对定义为 GENERATED ALWAYS

的列 “ID” 指定值。  SQLSTATE=428C9

错误分析：

–检查出错的表结构是否包含IDENTITY类型字段

–在DB2中提供了两种标识列值

• GENERATED ALWAYS AS IDENTITY –始终生成
• GENERATED BY DEFAULT AS IDENTITY –缺省情况下生成

–通常IDENTITY字段是定义为第一种，即始终由数据库自行产生的，不允许插入时指定值，例如如下字段：

ID INT NOT NULL PRIMARY KEY GENERATED ALWAYS AS IDENTITY(START WITH 0,INCREMENT BY 1,CACHE 50)

–将该字段改成GENERATED BY DEFAULT AS IDENTITY允许插入值即可。

 

 

使用RANGE时告警 – Database error 60 (ORA-00060: deadlock detected…

 

告警描述：

2010-05-28 10:45:05 GGS WARNING 218 Oracle GoldenGate Delivery for Oracle, r_ro_12b.prm: Aborted grouped transaction on ‘SIEBEL.S_ORDER_ITEM’, Database error 60 (ORA-00060: deadlock detected while waiting for resource).

错误分析：

–一般出现在通过RANGE进行拆分的行数特大的表

–各Replicat会根据主键hash值各自负责不同的数据集，不会有多个进程对同一条数据进行操作

–但是，可能出现多个进程修改的记录在同一个块上的情况，此时会引起死锁

–可以通过修改该表的INITRANS参数增大每个块中处理行级锁事务的数量，该参数缺省为1，建议至少设置为拆分出来的Replicat数量

ALTER TABLE TEST MOVE INITRANS 100

alter index index_name rebuild online;

注：修改此项参数建议先停止对应的Replicat。Move操作可以保证对原有数据有效，否则只做用于新增数据；Move之后需要重建索引。

–

 

Tips – 如何获取当前无法执行的SQL

• 可以通过获取Replicat执行的SQL帮助解决数据错误
• 在Replicat中加入以下参数

NOBINARYCHARS

NODYNSQL

SHOWSYNTAX

• 从shell命令行（不是ggsci）启动Replicat

Shell> REPLICAT PARAMFILE dirprm/<Replicat name>.prm

• 启动后会显示第一个SQL语句

–选择Keep Displaying (default)可以执行当前SQL并显示下一条

–选择Stop Display停止显示

• 完成诊断后从参数文件中移除这3个参数

Q:如何持续获取OGG队列中的SQL语句？配置一个使用formatsql参数的Data Pump。

ogg-00324错误，官网解释为：
Description： Must specify EXTRACT, REPLICAT or ER for group type

Cause：
A process was not specified for the specified parameter to act upon.

Action：
This parameter accepts values of ER, EXTRACT, or REPLICAT. For more information, see the Oracle GoldenGate reference documentation.

CAUSE

The issue is caused by the following setup: autostart and/or autorestart parameter specified with invalid options.

According to Oracle GoldenGate Reference Guide. The valid syntax for autostart and autorestart is
AUTOSTART [, RETRIES ] [, WAITMINUTES ][, RESETMINUTES ]

AUTOSTART

But user has specified

AUTOSTART rep* which is not valid.

SOLUTION

1. edit params mgr

2. Change

autostart rep*
to
autostart replicat *

and save the file

3. Restart the replicat

用户的SIEBEL RAC系统中配置了OGG 11.1.1.1.2 ，在最近发现备份脚本未正常将归档日志备份后删除掉，示例日志如下：

 

iece handle=al_18090002_1_848331814 tag=TAG20140523T154330 comment=API Version 2.0,MMS Version 5.0.0.0
channel ch00: backup set complete, elapsed time: 00:01:35
channel ch00: deleting archived log(s)
RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process
archived log file name=/ora/archivelog/2014_05_21/o1_mf_2_171530_1cccD0E1h_.arc thread=2 sequence=171530
RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process
archived log file name=/ora/archivelog/2014_05_21/o1_mf_2_171531_1cccD0VDr_.arc thread=2 sequence=171531
RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process
archived log file name=/ora/archivelog/2014_05_21/o1_mf_1_84695_1cccD0K8I_.arc thread=1 sequence=84695
RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process
archived log file name=/ora/archivelog/2014_05_21/o1_mf_2_171532_1cccD0C2h_.arc thread=2 sequence=171532
RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process
archived log file name=/ora/archivelog/2014_05_21/o1_mf_2_171533_1cccD0Y2l_.arc thread=2 sequence=171533
channel ch00: starting archived log backup set
channel ch00: specifying archived log(s) in backup set
input archived log thread=1 sequence=84696 RECID=261042 STAMP=848117115
input archived log thread=2 sequence=171534 RECID=261053 STAMP=848117139
input archived log thread=2 sequence=171535 RECID=261051 STAMP=848117138
input archived log thread=2 sequence=171536 RECID=261054 STAMP=848117139
input archived log thread=1 sequence=84697 RECID=261048 STAMP=848117125
channel ch00: starting piece 1 at 23-MAY-14
channel ch00: finished piece 1 at 23-MAY-14
piece handle=al_18090003_1_848331909 tag=TAG20140523T154330 comment=API Version 2.0,MMS Version 5.0.0.0
channel ch00: backup set complete, elapsed time: 00:01:35
channel ch00: deleting archived log(s)
RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process

 

 

针对该问题用户提交了SR，并禁用了TRANLOGOPTIONS LOGRETENTION DISABLED特性：

 

 

USERID ggs, password ************************************************ , ENCRYPTKEY default
exttrail ./dirdat/or
--HANDLECOLLISIONS
--FETCHOPTIONS FETCHPKUPDATECOLS
--FETCHOPTIONS, MISSINGROW IGNORE, NOFETCH
THREADOPTIONS OUTQUEUESIZE 512 INQUEUESIZE 1024
--TRANLOGOPTIONS _NOREADAHEAD ANY
TRANLOGOPTIONS LOGRETENTION DISABLED
--EOFDELAY 30
--BR BROFF
GETUPDATEBEFORES

但仍无法有效删除对应归档日志，相关的Note:

1. Disable logretention.

2. Make sure the capture process is removed from dba_capture.

3. Please follow the solution as per below document to cleanup the Orphan entries from metadata tables.

Ora-1 ''Unique Constraint (System.Logmnr_session_uk1) Violated'' During Streams Config (Doc ID 413774.1)

4. Please enable logretention which recreates the capture process again.
Make sure it has only one session for logminer.
Registered Extract - Archivelog Delete Problem (Doc ID 1487374.1)

 

 

 

这个case通过delete force 强制删除命令绕过了,例如：

 delete force archivelog sequence 171532 thread 2 ;

 

 

对于备份后delete input 的 删除也可以使用：

backup archivelog until time 'sysdate-1' delete input force;

1 ORACLE数据复制方案环境要求

1.1 操作系统环境要求

1.1.1 磁盘要求

 

• 数据库为集群方式。要安装Oracle GoldenGate 二进制文件和其他文件到共享阵列。
• 数据库为主备HA方式。要安装Oracle GoldenGate 二进制文件和其他文件到共享阵列。
• 复制软件本身的大小为200 MB左右。
• 为Oracle GoldenGate trails分配足够的磁盘空间，一般与GoldenGate分配到同一文件系统。
• 这些trails文件占用的磁盘空间依赖于处理的数据量大小，根据Trail文件的保存期限进行设置。说明如下：

Trail文件可以位于Oracle GoldenGate安装的本地驱动器上，它们也可以位于NAS或者SAN设备上。对于存储在源端的那些trails文件，应该有足够的空间处理网络连接失败时的数据累积。在典型配置下，第二个extract进程(data pump)通过网络从本地trail发送数据，当网络连接中断，发送将失败。然而，读事务日志并且写到本地trail的主extract进程将继续。这个extract进程不应该因失败而停止，因此应该有足够的磁盘空间来容纳数据累积。

• 在目标端的安装位置与空间建议与源端相同。

 

估算trail需要的空间的方法

1. 估算网络不可用的最长时间。
2. 估算商业应用程序每小时生成多少事务日志。
3. 使用下面的公式计算需要的磁盘空间

[每小时的日志量] x [宕机小时数] x .4 = trail需要的磁盘空间

这个等式使用百分之四十是因为Oracle GoldenGate大约只需要一个事务日志中百分之四十的数据。

注意:这个公式只是一个保守的估算，应该在配置好Oracle GoldenGate后，做测试来决定trail文件需要的准确空间。

1.1.2 TCPIP的配置要求

 

• 配置系统使用TCP/IP 服务，包括
• 配置运行Oracle GoldenGate进程的所有系统的主机名或者IP地址，以及Oracle GoldenGate将要连接的系统的主机名或者IP地址。建议使用主机名。
• Oracle GoldenGate使用下列TCP/IP 端口:

Manager process 和other Oracle GoldenGate processes通讯端口.

端口范围:默认端口范围是从7840开始或者可以自定义256个其它端口.

具体TCP/IP端口的分配参见国网下发的具体文档。

1.1.3 操作系统用户及权限要求

 

• 在unix上安装Oracle GoldenGate ，用户必须有读写Oracle GoldenGate安装目标的权限。
• 在windows上安装Oracle GoldenGate ，用户必须以Administrator 登录系统。
• Oracle GoldenGate 进程需要一个有权限读、写和删除Oracle GoldenGate目录下的文件和子目录的操作系统用户。此外，Manager进程用户需要有权限控制Oracle GoldenGate进程。
• 推荐这些操作系统用户给Oracle GoldenGate专用。

 

1.2 对ORACLE数据库环境的要求

1.2.1 对数据/对象和操作的支持

支持的数据类型

Numeric data types

• NUMBER
• BINARY FLOAT
• BINARY DOUBLE

 

Character data types

• CHAR
• VARCHAR2
• LONG
• NCHAR
• NVARCHAR2

 

Multi-byte character types

• NCHAR and NVARCHAR2 multi-byte character data types
• Multi-byte data stored in CHAR and VARCHAR2 columns

 

Binary data types

• RAW
• LONG RAW

 

Date and timestamp data types

• DATE
• TIMESTAMP

 

Large object data types

• CLOB
• NCLOB
• BLOB

 

XML data types

• XMLType（Oracle 9i及以上）

 

User defined types (objects)

GoldenGate 支持UDT（user defined types）类型，要求源和目标必须有相同的结构，Schema可以不同。

 

Other supported data types

• ROWID
• VARRAY
• INTERVAL DAY 和 INTERVAL YEAR，要求目标必须大于等于源

不支持的数据类型

• ORDDICOM
• ANYDATA
• ANYDATASET
• ANYTYPE
• BFILE
• MLSLABEL
• TIMEZONE_ABBR
• TIMEZONE_REGION
• URITYPE
• UROWID

支持的对象和操作

对象	是否支持	说明
Clusters	支持
Functions	支持
Indexes	支持
Packages	支持
Procedure	支持
Tables	支持	包括字段，约束
Tablespaces	支持
Roles	支持
Sequences	支持
Synonyms	支持
Triggers	支持
Types	支持
Views	支持
materialized views	支持
Users	支持

数据类型排查脚本

该脚本用于排查现有源数据库中是否用到GoldenGate不支持的数据类型。

1.2.2 数据库配置

• 源数据库必须开启归档模式。
• Oracle GoldenGate需要读取数据库的在线和归档日志，需要保留一定时间以内的数据库系统产生的日志，这个时间间隔不要少于数据复制可能落后生产库操作的最长时间。
• 对于Oracle RAC环境，必须保证GoldenGate能够访问到每个节点存放的归档日志文件。

1.2.3 数据库用户

• 需要创建一个数据库用户来管理Oracle GoldenGate（例如：ggs） 。需要连接到一个数据库上的所有Oracle GoldenGate进程可以使用同一用户 ：
  • Extract （源数据库）
  • Replicat (目标数据库)
  • DEFGEN (源数据库或目标数据库)
• 为了保护数据的安全与精确地监控Oracle GoldenGate 进程，不允许其他用户、应用系统，或者进程以Oracle GoldenGate数据库用户登录或操作。
• 分配系统管理员权限（DBA）给运行Extract的数据库用户。

GRANT DBA TO GGS;

 

• 要运行Replicat至少授予数据库用户如下权限：
  • CONNECT到目标数据库
  • SELECT系统视图目录
  • 在目标数据库表可以SELECT, INSERT, UPDATE, 和 DELETE

建议赋予DBA的权限。

 

2 系统环境现状检查与调整

2.1 操作系统现状检查与调整

 

分类	项目	目标	现状检查	系统调整步骤	备注
操作系统	磁盘要求	见3.1.1磁盘需求	1．  主备方式 2．  已经分配了磁盘空间	不需要
	TCPIP网络配置	见3.1.2 TCPIP的配置要求	1．  满足配置要求	不需要
	用户和权限	见3.1.3操作系统用户及权限要求	1．  ORACLE实例用户已经存在 2．  还未建立OGG安装目录	1．  使用数据库实例用户，不需要另外定义新用户 2．  由数据库管理员创建GGS软件安装目录：/ggsfs mkdir /ggsfs; 修改目录的属主和属组为数据库实例用户及所在的组oracle:dba 3．  说明：请确认已按照安装准备要求将OGG所在的文件系统放置在阵列上，可以提高性能和高可用性。

 

 

 

 

2.2 ORACLE数据库检查与调整

 

分类	项目	目标	现状检查	系统调整步骤	备注
数据库准备	检查源库是否存在不支持的对象	发现不支持的对象	1．  检查源数据库 参见3.2.1排查脚本	没有发现不支持的对象。如果发现有不支持的对象，应从OGG参数文件中将该对象删除。
	检查数据库日志参数	确保日志处于归档状态	1．   连接到ORACLE数据库： 2．   SQL> SELECT LOG_MODE FROM V$DATABASE;	如果没有开启归档模式，按照如下步骤开启归档模式。 1．  SQL> SHUTDOWN IMMEDIATE 2．   SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST=’/U01/archive’; 3．   SQL> STARTUP MOUNT; 4．   SQL> ALTER DATABASE ARCHIVELOG; 5．   SQL> ALTER DATABASE OPEN; 6．  SQL> ARCHIVE LOG LIST;
	归档日志路径	确认归档日志的路径	检查归档路径，对于RAC环境必须保证可以访问到每个节点的归档文件。
	检查日志保留策略	确保在系统上保留一定时间段内的归档日志	当前日志的备份策略需要保留一定时间以内的数据库系统产生的日志，这个时间间隔不要少于数据复制可能落后生产库操作的最长时间。	满足。 如果不满足。需要进行调整。
	确认源表的DATA_CAPTURE状态	确保源表必要的数据可以被同步工具捕获	确认源数据库是否开启附加日志 SQL> SELECT SUPPLEMENTAL_LOG_DATA_MIN FROM V$DATABASE;	如果没有开启，按照如下步骤开启附加日志。 SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; SQL> SELECT SUPPLEMENTAL_LOG_DATA_MIN FROM V$DATABASE;
数据表准备	去掉目标表的约束	去掉trigger，cascade delete/update约束	在目标数据库初始化之后，未开启OGG复制进程之前，执行此步骤。

 

 

 

 

3 数据复制方案的部署

3.1 网省端软件安装

1、使用Oracle用户（如非此用户，请自行取代，下同）通过ftp上传GGS软件并解压缩：

tar zxvf *.gz

或者分两步解压：

gunzip *.gz 或 gzip –d *.gz

tar xvf *.gz

2、创建子目录，上传参数文件

在数据库服务器上创建文件系统：/ggsfs（小写），大小10G（营销系统除外）， GoldenGate安装目录统一为：/ggsfs（小写）

队列文件存放在本地，存放目录为/ggsfs/dirdat

1. a) 在/ggsfs目录下运行GGS命令行控制界面：

./ggsci

1. b) 在GGS命令行界面下创建子目录：

GGSCI> create subdirs

1. c) 通过ftp上传参数文件mgr, ext*, dpe*到dirprm文件夹中。

3.2 容灾中心端软件安装

1、使用Oracle用户（如非此用户，请自行取代，下同）通过ftp上传GGS软件并解压缩：

tar zxvf *.gz

或者分两步解压：

gunzip *.gz 或 gzip –d *.gz

tar xvf *.gz

2、创建子目录，上传参数文件

在数据库服务器上创建文件系统：/ggsfs（小写），大小10G（营销系统除外）， GoldenGate安装目录统一为：/ggsfs（小写）

1. a) 在/ggsfs目录下运行GGS命令行控制界面：

./ggsci

1. b) 在GGS命令行界面下创建子目录：

GGSCI> create subdirs

1. c) 通过ftp上传参数文件mgr, rep*到dirprm文件夹中。

3.3 网省端数据链路的配置和启动

1、在源数据库创建GoldenGate用户

sqlplus / as sysdba

sql>create user ggs identified by xxx default tablespace xx（表空间名）temporary tablespace xx（表空间名）;

sql>grant dba to ggs;

2、GOLDENGATE进程的配置

1. a) 配置mgr进程

GGSCI>edit param mgr

GGSCI>start mgr

Manager started.

1. b) 为需要抽取数据的schema增加trandata

GGSCI>dblogin userid ggs, password xxx

GGSCI>add trandata schema.*

1. c) 配置源端extract进程

GGSCI>edit param dpeXX

—下面的命令在进行数据库备份之前执行

GGSCI>add ext extXX, tranlog, begin now

EXTRACT added.

GGSCI>add exttrail /ggsfs/dirdat/XX, ext extXX, megabytes 50

EXTTRAIL added.

1. d) 配置源端datapump进程

GGSCI>edit param dpeXX

GGSCI>add ext dpeXX, exttrailsource /ggsfs/dirdat/XX

EXTRACT added.

GGSCI>add rmttrail /ggsfs/dirdat/XX, ext dpeXX, megabytes 50

RMTTRAIL added.

3、启动源端进程

1. a) 启动源端抓取进程：

GGSCI>start er *

1. b) 查看源端进程状态：

GGSCI>info er *

RUNNING

RUNNING

注：若目标端mgr进程未启动，则该步骤无法启动dpe*进程，需等目标端mgr进程启动后再启动。

3.4 容灾中心数据链路的配置和启动

1、在目标数据库创建GoldenGate用户

以管理员用户登录oracle数据库

sqlplus / as sysdba

sql>create user ggs identified by xxx default tablespace xx（表空间名）temporary tablespace xx（表空间名）;

sql>grant dba to ggs;

2、 配置MGR进程

GGSCI>edit param mgr

GGSCI>start mgr

Manager started.

3、配置检查点

GGSCI>EDIT PARAMS ./GLOBALS

文件名：GLOBALS，内容如下：

CHECKPOINTTABLE ggs.ggschkpt

GGSCI> EXIT

Shell> ggsci

GGSCI> DBLOGIN USERID ggs, PASSWORD xxx

GGSCI> ADD CHECKPOINTTABLE

4、配置目标端复制进程

GGSCI>edit param repXX

GGSCI>add rep repXX, exttrail /ggsfs/dirdat/XX

REPLICAT added.

—下面的命令在进行数据库完全恢复之后执行

GGSCI>start  repXX

REPLICAT REP* starting

5、查看目标端进程状态

GGSCI>info er *

RUNNING

 

3.5 Oracle RMAN初始化步骤

在数据初始化的过程中，不需要源数据库停机。

 

注意：

一定要保证所有交易是在extract启动之后开始的再启动备份！

否则，可能某些交易开始早于Extract启动，其数据变化无法捕捉。可以通过查看(g)V$TRANSACTION中的最小的START_TIME，与extract启动时间做对比。如果比extract启动时间时间早就需要再等一段时间，否则就可以开始备份了。

 

0、清除过期的归档日志

$rman target /

RMAN>

run {

crosscheck backupset;

delete expired backup;

}

 

1、源端和目标端安装OGG软件，并启动manager

2、源端配置OGG的Extract及DataPump

3、源端启动Extract进程以及DataPump进程

4、使用oracle用户登录，执行rman备份

$rman target /

RMAN>

run {

crosscheck backupset;

delete expired backup;

crosscheck archivelog all;

backup incremental level 0 filesperset 1 format ‘/u01/oracle/rmanbk/hpdb_full_%s%t%p.dbf’ database;

sql ‘alter system archive log current’;

}

 

RMAN>

run {

backup format ‘/u01/oracle/rmanbk/hp_archiveloghp_%s%t%p.dbf’ archivelog all delete input;

}

=================================

 

RMAN>

backup format ‘/u01/oracle/rmanbk/hpdb_ctlfile_%s%t%p.dbf’ current controlfile;

LIST BACKUP OF CONTROLFILE;

List of Backup Sets

=================================

 

BS Key  Type LV Size       Device Type Elapsed Time Completion Time

——- —- — ———- ———– ———— —————

72      Incr 0  11M        DISK        00:00:34     01-DEC-10

BP Key: 72   Status: AVAILABLE   Tag: TAG20101201T185001

Piece Name: /u01/oracle/rmanbk/hpdb_full_727366278761.dbf

Controlfile Included: Ckp SCN: 218216       Ckp time: 01-DEC-10

 

BS Key  Type LV Size       Device Type Elapsed Time Completion Time

——- —- — ———- ———– ———— —————

75      Full    11M        DISK        00:00:03     01-DEC-10

BP Key: 75   Status: AVAILABLE   Tag: TAG20101201T185358

Piece Name: /u01/oracle/rmanbk/hpdb_ctlfile_757366280381.dbf

Controlfile Included: Ckp SCN: 218562       Ckp time: 01-DEC-10

 

在源机执行

SQL>select * from v$log;

SQL>set line 200

 

GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM

———- ———- ———- ———- ———- — —————- ————- ———

1          1         23  104857600          1 NO  CURRENT                 218512 01-DEC-10

2          1         22  104857600          1 YES ACTIVE                  218422 01-DEC-10

3          2         17  104857600          1 NO  CURRENT                 218503 01-DEC-10

4          2         16  104857600          1 YES INACTIVE                218412 01-DEC-10 (*)

获取不活动的归档日志的最后一个SCN号，如果有多个INACTIVE的组，取最大的FIRST_CHANGE#，这里取218412

记录该SCN号

 

将备份文件，FTP到目标机

========================================

hpux2:/u01/oracle$ ftp 192.168.1.27

Connected to 192.168.1.27.

220 hpux_dr FTP server (Revision 4.0 Version wuftpd-2.6.1 Wed Jun 18 07:11:14 GMT 2008) ready.

Name (192.168.1.27:oracle): oracle

331 Password required for oracle.

Password:

230 User oracle logged in.

Remote system type is UNIX.

Using binary mode to transfer files.

ftp> cd /u01/oracle/rmanbk

250 CWD command successful.

ftp> lcd /u01/oracle/rmanbk

Local directory now /u01/oracle/rmanbk

ftp> bin

200 Type set to I.

ftp> prompt

Interactive mode off.

ftp> mput hp*

 

===============================================

5、使用oracle用户登录目标机执行恢复

在目标机建立相同的目录结构，并正确设置：ORACLE_BASE，ORACLE_HOME，ORACLE_SID环境变量。

拷贝源机init{ORACLE_SID}.ora文件到目标机

cp $ORACLE_HOME/dbs/initorcl.ora  目标机对应目录

生成口令文件或者copy $ORACLE_HOME/dbs/PWD{ORACLE_SID}

 

6、启动数据库到nomount状态

sqlplus ‘/ as sysdba’

SQL>startup nomount

 

7、启动RMAN恢复控制文件

rman target /

RMAN>restore controlfile from ‘/u01/oracle/rmanbk/hpdb_ctlfile_757366280381.dbf’;

 

8、将数据库更改为mount状态

sqlplus ‘/ as sysdba’

SQL>alter database mount;

 

9、启动RMAN恢复数据库

 

rman target /

RMAN>restore database;

 

RMAN> list backup;

查找最小的SCN号，推荐使用上面记录的SCN号，例如：218412

RMAN>

run

{

set archivelog destination to ‘/u01/arch’;

SET UNTIL SCN 218412;

RECOVER DATABASE;

–SHUTDOWN IMMEDIATE;

}

9-1、（备选）如果源端为RAC，目标端为单机，需将目标机改为单机模式

删除多余的redolog group

SQL> select THREAD#, STATUS, ENABLED from v$thread;
THREAD# STATUS ENABLED
———- —— ——–
1 OPEN   PUBLIC
2 CLOSED PRIVATE
SQL> select group# from v$log where THREAD#=2;

GROUP#
———-
4
5
6

SQL> alter database disable thread 2;

Database altered.

SQL> alter database drop logfile group 4;
alter database drop logfile group 4
*
ERROR at line 1:
ORA-00350: log 4 of instance racdb2 (thread 2) needs to be archived
ORA-00312: online log 4 thread 2: ‘/u01/oracle/oradata/ractest/log/redo04.log’

SQL> alter database clear unarchived logfile group 4;

Database altered.

SQL> alter database drop logfile group 4;

Database altered.

SQL> alter database drop logfile group 5;

Database altered.

SQL> alter database drop logfile group 6;

Database altered.

SQL> select THREAD#, STATUS, ENABLED from v$thread;

THREAD# STATUS ENABLED
———- —— ——–
1 OPEN   PUBLIC

删除多余UNDO表空间

SQL> show parameter undo;
NAME                                 TYPE        VALUE
———————————— ———– ——————————
undo_management                   string      AUTO
undo_retention                       integer     900
undo_tablespace                      string      UNDOTBS1
SQL> select tablespace_name from dba_tablespaces where contents=’UNDO’;
TABLESPACE_NAME
——————————
UNDOTBS1
UNDOTBS2
SQL> drop tablespace UNDOTBS2 including contents and datafiles;
Tablespace dropped.
如果源数据库为Oracle9i，因为RMAN时不备份TEMP表空间，需重新创建TEMP表空间

SQL> create temporary tablespace TEMP  tempfile ‘/u01/temp.dbf’ size 500M;
Tablespace created.
SQL> alter database default temporary tablespace TEMP;
Database altered.
10、目标端打开数据库

alter database open resetlogs;

 

11、将目标数据库的触发器及约束禁止掉

脚本参见4.2节中“去掉目标表的约束”

 

12、目标端启动Replicat进程

start replicat，aftercsn 218412

3.6 Oracle EXPDP/IMPDP初始化步骤

在数据初始化的过程中，不需要源数据库停机。

1、源端和目标端安装OGG软件，并启动manager

2、源端配置OGG的Extract及DataPump

3、源端启动Extract进程以及DataPump进程

4、创建directory用于执行数据泵操作

–directory path for store dump file

CREATE OR REPLACE DIRECTORY DATA_PUMP AS ‘E:\OGG\data’;

grant read ,write on DIRECTORY DATA_PUMP to ggs ;

–users to execute expdp

grant read ,write on DIRECTORY DATA_PUMP to sglaw ;

5、源端获取数据库当前的SCN

SQL> select dbms_flashback.get_system_change_number from dual;

 

GET_SYSTEM_CHANGE_NUMBER

————————

3079975

注意：

一定要保证所有交易是在extract启动之后开始的，再选这个SCN！

否则，可能某些交易开始早于Extract启动，其数据变化无法捕捉。可以通过查看(g)V$TRANSACTION中的最小的START_TIME，与extract启动时间做对比。如果比extract启动时间时间早就需要再等一段时间，否则就可以开始备份了。

 

6、源端数据导出

在源端OS系统中执行数据导出，导出用户名、dmp文件名自行修改，导出完成后ftp至目标端datapump目录

expdp sglaw/sglaw directory=DATA_PUMP dumpfile=<dp_sglaw.dmp> flashback_scn=<scn>

—以下在目标端执行

7、创建directory用于执行数据泵操作，同时给ggs以及导入用户赋权

–directory path for store dump file

CREATE OR REPLACE DIRECTORY DATA_PUMP AS ‘/ggsfs/data’;

grant read ,write on DIRECTORY DATA_PUMP to ggs ;

grant read ,write on DIRECTORY DATA_PUMP to <sglaw>;

8、目标端导入数据

— 以下操作在OS中执行，具体用户名与导入dmp文件名视具体情况而定

impdp sglaw/sglaw DUMPFILE=DATA_PUMP:DP_SGLAW.DMP

9、将目标数据库的触发器及约束禁止掉

脚本参见4.2节中“去掉目标表的约束”

10、目标端启动复制进程

GGSCI > start repa3, aftercsn 3079975

 

3.7 检查各个进程的状态和报告

 

GGSCI > view ggsevt

GGSCI > info er *

GGSCI > status er *

 

GGSCI > view report extXX

GGSCI > view report dpeXX

GGSCI > view report repXX

 

 

3.8 设置进程自动重启及HA切换

针对网络中断、数据库停机等异常情况,可在GOLDENGATE TDM软件的mgr进程       参数文件中设置自动重启参数，在无需人工干预的情况下重启抽取及复制进程。

mgr参数文件如下：

port 7809

–autostart er *

autorestart er *, waitminutes 3, retries 15

 

在HA环境下，需要在HA脚本中添加启动GoldenGate的命令：

sh start_mgr.sh

脚本start_mgr.sh的内容：

cd /ggsfs/dirpcs

rm -f *

cd /ggsfs

./ggsci << EOF

start mgr

EXIT

EOF

详细内容参见附件

4 GoldenGate参数文件样例

4.1 源端参数文件

4.1.1 manager参数文件

文件名：mgr.prm，内容如下：

PORT 7839

DYNAMICPORTLIST 7840-7914

AUTOSTART ER *

AUTORESTART ER *, WAITMINUTES 2, RETRIES 5

PURGEOLDEXTRACTS /ggsfs/dirdat/*, USECHECKPOINTS, minkeepdays 7

4.1.2 extract参数文件

文件名：exee.prm，内容如下：

EXTRACT exee

SETENV (ORACLE_SID = “<SID>”)

SETENV (ORACLE_HOME=/app/oracle/product/10.2.0/db_1)

SETENV (NLS_LANG = “AMERICAN_AMERICA.ZHS16GBK”)

–如果使用tnsname，可以不设置上面的ORACLE_SID环境变量

USERID ggs@gg, PASSWORD xxx

WARNLONGTRANS 2h, CHECKINTERVAL 3m

–如果是RAC环境，需要增加下面一行

–TRANLOGOPTIONS altarchivelogdest primary instance src1 /arch1, altarchivelogdest instance src2 /arch2

FETCHOPTIONS NOUSESNAPSHOT

grouptransops 20000

exttrail ./dirdat/ee, megabytes 500

discardfile ./dirrpt/ee.dsc,append, megabytes 50

dynamicresolution

–抽取哪些表，依次增加到下面

table TEST.CZ2;

4.1.3 datapump参数文件

文件名：dpee.prm，内容如下：

EXTRACT dpee

SETENV (ORACLE_SID = “<SID>”)

SETENV (ORACLE_HOME=/app/oracle/product/10.2.0/db_1)

SETENV (NLS_LANG = “AMERICAN_AMERICA.ZHS16GBK”)

RMTHOST 192.168.1.7, MGRPORT 7839, compress

RMTTRAIL ./dirdat/ee

PASSTHRU

dynamicresolution

table TEST.CZ2;

4.1.4 生成TABLE LIST脚本

–将该脚本输出结果添加到extract和datapump参数文件中即可

set pagesize 0

set feedback off

spool ext_table_list.txt

select ‘TABLE ‘||owner||’.’||table_name||’ ;’ from dba_tables where owner=’SGLAW’

spool off

 

4.2 容灾端参数文件

4.2.1 GLOBALS参数文件

GGSCI>EDIT PARAMS ./GLOBALS

文件名：GLOBALS，内容如下：

CHECKPOINTTABLE ggs.ggschkpt

GGSCI> EXIT

Shell> ggsci

GGSCI> DBLOGIN USERID ggs, PASSWORD xxx

GGSCI> ADD CHECKPOINTTABLE

4.2.2 manager参数文件

文件名：mgr.prm，内容如下：

PORT 7839

DYNAMICPORTLIST 7840-7914

AUTOSTART ER *

AUTORESTART ER *, WAITMINUTES 2, RETRIES 5

PURGEOLDEXTRACTS /ggsfs/dirdat/*, USECHECKPOINTS, minkeepdays 7

4.2.3 replicat参数文件

文件名：rpee.prm，内容如下：

REPLICAT rpee

SETENV (ORACLE_SID = “<SID>”)

SETENV (ORACLE_HOME=/app/oracle/product/10.2.0/db_1)

SETENV (NLS_LANG = “AMERICAN_AMERICA.ZHS16GBK”)

USERID ggs@gg, PASSWORD xxx

–handlecollisions

assumetargetdefs

allownoopupdates

discardfile ./dirrpt/ee.dsc,append, megabytes 500, purge

dynamicresolution

 

map TEST.CZ2, target TEST.CZ2;

4.2.4 生成MAP脚本

— 生成replicat table list，用于map源与目标表，将该脚本的输出添加到replicat参数文件即可

set pagesize 0

set feedback off

spool rep_table_list.txt

select trim(‘MAP ‘||owner||’.’||table_name||’ , TARGET ‘||owner||’.’||table_name||’;’) from dba_tables where owner=<‘SGLAW’>

删除复制表的步骤

停止Extract/Data Pump/Replicat进程
注意停止Extract时检查长交易和归档日志
修改Extract/Data Pump/Replicat参数中复制范围排除该表

如使用通配符时，Extract/Data Pump可通过tableexclude排除表

tableexclude ctais2.KJ_*;
tableexclude ctais2.DJ_YZCWSBQC;
table ctais2.*;
如使用通配符时，Replicat可通过mapexclude排除表
MAPEXCLUDE fin.TEST
MAP fin.*, TARGET fin.*;
重启Extract/Data Pump/Replicat进程
说明：在一个复制链路的任何一个环节去掉该表即可排除该表复制，但建议
在主Extract进行排除，可以避免各进程做不必要的工作；同时，在各个进程
参数均明确去掉该表可以保持前后的逻辑统一性和易读性