GoldenGate实施参考

 GoldenGate实施参考转载一篇原厂的Oracle GoldenGate的实施参考安装信息收集• 收集客户信息（建议至少提前两周）– 测试/生产环境– 操作系统列表– 数据库列表– 数据库日志增量评估• 每天日志增量、峰值日志增量–网络配置：带宽、端口等• 带宽评估（如带宽不足，是否需要启动压缩，压缩对CPU占用测试）– 数据结构• 包括表数量、是否存在无主键表、是否有不支持数据类型等– 验证OGG版本可用性！• 针对不同的操作系统和数据库版本下载需要的OGG版本并安装测试带宽估算• 根据峰值产生日志量估算带宽占用• 假设条件– 假设OGG队列与日志比例为1：4。如只复制部分表则此比例可以假设为更低。– 假设网络传输效率为0.7– 假设网络传输压缩比例为1：8。根据数据内容有所变化，一般字符数据较多时压缩比例较大，二进制对象压缩效率较低• 带宽估算算法– 以客户业务高峰期每小时产生40G为例，可以估算如下带宽=40G/3600（秒/小时）/ 4(日志过滤比例)/8（压缩比率） * 8（每字节8位） /0.7(网络传输效率)=4Mbps无主键表的复制• GoldenGate可以正常复制无主键表，以所有列作为基准代替主键• 强烈建议排除掉无主键表或者增加主键（或唯一索引）– 一般为临时表或者历史表– 导致附加日志增量较大，可能影响生产系统性能– 目标端replicat投递效率非常低且无法进行优化– 容易出现数据不一致且不易修复– 无法使用HANDLECOLLISIONS• 该参数依赖于表的主键进行逻辑判断，无主键表使用该参数会导致重复记录出现测试安装准备– 测试安装文档准备• 拟定安装操作文档• 拟定初始化方案并与客户达成一致– 根据测试安装场景准备• 数据库脚本，如建立用户、赋予权限等• 准备OGG安装所需脚本，如add trandata命令脚本、目标端禁止trigger和cascade delete脚本等• OGG参数文件，列出所有可能用到参数• OGG命令，常用命令预先放在文本里• 验证参数、命令、脚本的可行性• 发现潜在的问题，及时寻求解决方案– 预订技术支持测试安装准备 –网络端口• 对于GoldenGate所在的数据库主机– 源和目标均向对方开放端口7800-7810，用于mgr管理进程通讯和数据传输进程传输数据。– Director管理各个GoldenGate实例需要执行大量监控命令，每次命令需要一个端口，建议开放7811-7850端口；– Veridata为了实现并发比较，同样需要大量端口，建议开放7851-7950端口；– 综上所述，建议复制源和目标相互以及为Director Server和VeridataServer开放7800-7950端口。• 对于Veridata Server和Director Server– 由于国网需要每个Director Server监控上百台主机，需要大量动态分配端口，建议Director Server向所有受控服务器开放所有端口。测试安装准备 –系统设置（源和目标）• 建立GoldenGate运行用户– 需访问数据库的动态库、在线日志及归档日志– 使用oracle用户，也可为其创建新的系统用户将其加入到oracle安装用户所在组（一般为oinstall）。– 为GoldenGate运行用户配置内存限制• 分析和抽取交易数据需一定内存，需放宽GoldenGate运行系统用户对内存大小（memory）、文件大小(fsize)、DATA、STACK等参数的值，在系统允许的情况下尽量将参数设置为-1（ulimited），一般在/etc/security/limits文件中。• RAC各节点配置时钟同步– GoldenGate在单节点上对所有节点日志进行解析，为了保证其在各节点抽取数据顺序的一致性，需要在各个节点主机上配置时钟同步（例如在AIX下配置NTP服务）。创建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;测试安装准备 – 存储空间（源和目标）• 为GoldenGate分配空间– 建议在共享阵列，可以在单节点失败后由其它节点接管，通过脚本可以与集群软件集成– GoldenGate软件所需空间主要取决于队列的产生速度，一般建议为其保留相当于数据库1-3天归档日志量的存储空间。– 存储划分完后建立OGG安装目录并将该目录Owner设为OGG运行用户• 为数据库保留1-3天归档日志– 长交易需要其开始时段的日志测试安装准备 – 数据库（源）• 打开归档模式– 避免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软件安装 （源和目标）• 上传和解压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检查内存等限制OGG软件安装 -续（源和目标）• 执行ggsci,检查是否能够进入OGG命令行界面• 执行create subdirs创建子目录• 执行edit param mgr为manager配置参数,然后尝试启动mgr进程如以上步骤均能顺利执行,则表明初步安装成功.由于以上步骤并不影响生产库运行,可以在测试安装前几天提前完成.打开附加日志（源）• 以渐进模式打开附加日志– 第一步,在晚上或其他业务较空闲时段打开数据库级最小附加日志– 第二步,经过一段时间运行观察数据库最小附加日志对数据库是否有影响,观察日志量的增加– 第三步,同样选择空闲时段打开所需复制表的附加日志– 第四步,经过一段时间运行观察数据库是否有性能下降,归档日志量是否有明显增加• 如何降低附加日志影响（☆）– 排除一些应用的中间表– 尽量排除无主键和唯一索引表(记录全部列会导致日志量显著增加)或给他们加上主键、如何打开附加日志• 数据库级附加日志– 视图v$database• SUPPLEMENTAL_LOG_DATA_MIN：最小附加日志，开关– 打开所需复制表的表级附加日志• ALTER DATABASE add SUPPLEMENTAL LOG DATA;• 目的是产生最小日志增量，避免对生产主机产生较大影响• 表级附加日志– 通过OGG命令行中的add trandata schema.table 命令添加– 如果有主键则只加入主键；无主键添加唯一索引；两者皆无，则自定义添加，否则添加所有列Extract进程• 设置操作系统变量– 继承mgr进程变量• 设置进程本身参数和变量– 读取参数文件– 设定内存限制（可以通过CACHEMGR修改，缺省单个进程32位系统最大2G，64位系统最大8G内存）• 连接数据库– 根据下列信息登录数据库• userid参数• 环境变量ORACLE_SID（也可通过setenv参数设置）• 环境变量ORACLE_HOME （也可通过setenv参数设置）– 获取数据库版本信息和字符编码• 注意：环境变量中NLS_LANG设置必须与数据库保持一致– 根据检查点确定读取日志,寻找并开始解析日志Oracle日志的读取 – 在线日志• 根据检查点中的日志序列号判断是在线还是归档• 在线日志– 由于在线日志频繁读写，在系统IO缓存中，读取速度较快– 在线日志位置及特殊参数• 文件系统• ASM。需配置如下（只能使用SYS登录ASM实例）：TRANLOGOPTIONS ASMUSER SYS@<ASM_instance>,ASMPASSWORD <password>• RAW DEVICE。在Aix下一般需要配置如下参数：tranlogoptions rawdeviceoffset 0注意：该参数只在内部参考手册中存在• 如果需抽取CLOB必须加上– TRANLOGOPTIONS CONVERTUCS2CLOBS• 说明：如果使用begin now时OGG读取日志序列号错误，可以尝试使用extrba和extseqno直接指定日志位置Oracle日志的读取 – 归档日志• 缺省查询数据库中归档日志位置和格式并到指定位置查找对应归档日志文件• 可通过参数指定归档日志– TRANLOGOPTIONS {[ALTARCHIVEDLOGFORMAT <string>] [INSTANCE<instance_name>] [THREADID <id>]• 指定日志文件名的格式[ALTARCHIVELOGDEST [PRIMARY] [INSTANCE<instance_name>] <path name>]• 指定归档日志目录。如果是RAC，需要访问到所有节点归档日志，可使用共享文件系统或者使用nfs等将其它节点归档共享到运行节点• 如果为所有节点指定了归档日志目录，则可以使用PRIMARY参数告诉GoldenGate无需再去查询log_archive_dest_N– 可以通过降低进程对控制文件访问次数Replicat进程• 设置操作系统变量– 继承mgr进程变量• 设置进程本身参数和变量– 读取参数文件• 初始化加载之后指定开始的CSN• 连接数据库– 根据下列信息登录数据库• userid参数• 环境变量ORACLE_SID（也可通过setenv参数设置）• 环境变量ORACLE_HOME （也可通过setenv参数设置）– 获取数据库版本信息和字符编码• 注意：环境变量中NLS_LANG设置必须与数据库保持一致宕机初始化步骤• 完成前面所述的所有准备工作• 根据约定时间停止业务应用• 源端– 锁定除去OGG数据库用户以外其余所有用户– 停止Oracle内部的所有Job– 关闭数据库– 重新启动数据库– 配置OGG抽取进程和本地队列– 启动OGG抽取进程,验证• 抽取进程是否可以正常启动,主要是验证是否能正常读取日志• 观察是否有数据被抽取出来,如有则说明尚有其它连接在修改数据,需找出原因并停止– 停止OGG抽取进程– 可使用脚本记录部分主要表或所有表记录总数– 关闭数据库OGG最佳实践 – 宕机初始化 (续一)• 源端– 使用RMAN/可传输表空间/BCV等方式将数据导出– 在源端打开数据库– 启动源端抽取进程(也可重新配置一遍,注意清除旧的队列)– 解开锁定的其它用户,恢复job– 启动应用– 观察数据抽取是否正常• 目标端– 将数据导入到目标库– 打开数据库– 解锁其它用户(如允许也可保持锁定状态防止修改数据)– 对比记录的源端数据库记录数与目标记录数是否相同,验证恢复完成OGG最佳实践 – 宕机初始化 (续二)• 源端– 配置Data Pump和远程队列– 启动Data Pump观察数据传输是否正常• 目标端– 配置Replicat• 注意目标端用户权限比源端多几个– 启动Replicat观察数据是否正常• 注:此时一般将reperr设置为abended模式(即默认模式)并配置discardfile参数,遇有错误进程可以立即中止,便于及时查找错误– 如Replicat速度跟不上队列增长速度,需进行Replicat拆分OGG最佳实践 – 基于SCN号的无宕机初始化• 前提条件– 客户具有能够将目标恢复到某一特定SCN号的备份/恢复工具• RMAN (强烈推荐)• Exp/imp• 操作步骤– 源端• 完成前面所述的所有准备工作• 配置OGG抽取进程和本地队列• 启动OGG抽取进程并记录开始时间• 查询数据库中当前交易最早的开始时间,直到该时间超过OGG抽取启动时间点• 查询和记录此时SCN号为最小所需SCN• 可每隔半小时或一小时重新查询SCN号和记录此时全库所有表或部分关键业务表中记录数OGG最佳实践 – 基于SCN号的无宕机初始化 (续一)• 目标端– 使用备份/恢复工具恢复目标库到指定SCN号• 如果是RMAN可以边恢复边观察,直到恢复出来的SCN号和时间点大于记录的最小所需SCN号– 查询目标库中全部表或关键表记录,看其是否大致符合源端记录数– 删除掉目标端物化视图等无用对象– 通过SQL禁止目标端trigger和外键或者配置GoldenGate目标端参数在会话级禁止– 配置Replicat• 注:此时一般将reperr设置为abended模式(即默认模式)并配置discardfile参数,遇有错误进程可以立即中止,便于及时查找错误– 使用以下命令启动Replicat• Start myrep, AFTERCSN <目标恢复到的CSN>– 观察数据复制是否正常目标初始化方案• 初始化的关键– 如何避免数据丢失– 如果处理冲突数据• 使用HANDLECOLLISIONS处理冲突数据– 条件：表均有主键或唯一索引– 方法：在启动replicat前加入HANDLECOLLISIONS参数，依赖表主键处理掉重复数据– 问题：如果表没有主键则可能产生重复记录• 使用SCN– 启动extract后按照前面说述选择合适时间点获取其SCN；– 使用exp或rman等获取对应于该SCN的影像并装载到目标端；– 启动replicat时使用start replicat <name>, aftercsn <number>或者在replicat的map参数加入filter ( @getenv (“TRANSACTION”,“CSN”) > <number>) ;使replicat从该scn后的记录开始。数据复制典型场景 – 重新获取最近数据变化• 可以通过修改ext/replicat起始检查点到指定时间– 方案一：使用alter extga,begin 2010-03-21 08:00:00• 条件：对应归档日志依然存在– 方案二：修改replicat从指定位置队列重新开始应用• ALTER REPLICAT finance, EXTSEQNO 53，EXTRBA 0• 可以通过查看队列生成时间或者logdump查看记录时间戳定位时间• 重复数据处理– 在replicat使用handlecollisions（必须有主键或者唯一索引）DDL复制的范围• 只支持Oracle数据库– 暂不支持其它数据库DDL复制！• 对于Oracle数据库，GoldenGate能够支持除去数据库系统对象之外所有对象DDL变化的复制• GoldenGate DDL复制需要关闭Oracle的– _RECYCLEBIN参数（Oracle 10.1）–RECYCLEBIN参数（Oracle 10.2及以后版本）。DDL复制的原理及特点• Oracle GoldenGate的DDL复制是基于Trigger的复制，– 在源库建立一个Oracle全库级的Trigger捕捉DDL操作到中间表– Extract读取中间表DDL语句并与DML语句根据csn排序– 目标端重现该DDL操作sql语句• 特点– DDL复制与DML复制的复制机理是完全不同的• DDL复制基于Trigger，而DML复制基于日志，两者的复制机理不同，其数据捕捉是没有联系的，只是在主Extract进程中通过scn号按照发生的顺序进行组装，保证DDL操作和DML操作按照其原来的顺序执行。DDL复制的原理及特点（续）• 特点（续）– DDL复制与DML复制是相互独立的• DDL复制的Trigger建立和启用后，无论DML复制是否运行，该Trigger一直在发生作用，捕捉DDL sql语句到中间表。因此，DML复制的起停并不影响DDL的捕获。• 同样，DDL Trigger的启用和停止并不影响DML复制，只是该Trigger被禁止后不再抓取DDL操作。• 它们之间只是在Extract进行组装时根据scn号进行排序，没有其它任何联系。– DDL复制只是简单的sql复制• 通过Trigger捕捉DDL其实就是抓取原始的sql语句并发送到目标重新执行一遍。DDL复制的限制• DDL复制会影响数据库性能– 捕获DDL语句的Trigger是全库级别的Trigger，即该数据库上的任何一个DDL操作无论其是否在复制范围内均会触发该Trigger并被记录到中间表供Extract进程删选。因此启用DDL复制会导致源库的DDL操作全部触发Trigger，如果数据库日常业务量较多并且DDL操作较多，会导致数据库性能下降很多。• DDL语句并不一定能在目标执行成功– 由于两端数据库总存在物理和逻辑上的不同，例如两边的安装目录和数据文件、表空间等会有所区别，造成同样的DDL语句在源端能够执行但无法在目标端执行。虽然可以通过字符串替换预先定义和解决类似问题，但DDL语句有可能在目标重现后产生与源端不同结果，需要较多的维护操作。何时打开DDL复制• DDL复制优点– 打开DDL复制能够可以自动创建每次补丁新建和修改的对象，并自动维护对应的附加日志，无需人工介入，减少人工工作量。• 使用原则：– 两端必须是Oralce数据库;– 两端的表结构完全相同；– 数据复制过程中没有数据的转换;– 数据库每日产生日志量不超过50G；– 应用系统在数据库中不能有频繁的DDL操作，如频繁建立中间表等操作。如果符合以上条件，可以联系Oracle GoldenGate技术支持探讨打开DDL复制。