本文永久链接地址：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，不能被忽略
Comment