配置定时删除过期队列 用于自动删除过期队列，节省硬盘空间 建议配置在Mgr进程中，可集中管理所有队列 在mgr参数中加入以下行 purgeoldextracts //dirdat/*, usecheckpoint, minkeepdays 7 其中，第一个参数为队列位置，*可匹配备份中心所有队列文件； 第二个参数表示是首先要保证满足检查点需要，不能删除未处理队列； 第三个参数表示最小保留多少天，后面的数字为天数。例如，如果希望只保留队列/ggs/dirdat/xm文件3天，可以配置如下： purgeoldextracts /ggs/dirdat/xm, usecheckpoint, minkeepdays 3 说明 Mgr进程参数需重启Mgr进程后生效 临时停止mgr进程并不影响数据复制。 配置自动定时重启进程 用于自动恢复由于网络临时中断、数据库或系统维护等原因造成的进程终止，降低人工工作量 建议在Mgr进程配置 在mgr参数文件加入以下行 AUTORESTART ER *, RETRIES 3, WAITMINUTES 5, RESETMINUTES 60 以上参数表示每5分钟尝试重新启动所有进程，共尝试三次。以后每60分钟清零，再按照每5分钟尝试一次共试3次。 说明 需重启Mgr进程使参数生效 可查询ggserr.log文件查看重启尝试信息 长交易的管理 停止Extract之前需验证检查点和长交易，以防止下次启动无法找到归档日志： ggsci> info extXX, showch 查看长交易 例如,查看extsz进程中节点1上最长的10个交易，可以通过下列命令： Ggsci> send extract extsz , showtrans thread 1 count 10 强制跳过或接受长交易 Ggsci> SEND EXTRACT <进程名>, SKIPTRANS <5.17.27634> THREAD <2> //跳过交易 Ggsci>SEND EXTRACT <进程名>, FORCETRANS <5.17.27634> THREAD <1> //强制认为该交易已经提交 说明：使用这些命令只会让GoldenGate进程跳过或者认为该交易已经提交，但并不改变数据库中的交易，他们依旧存在于数据库中。因此，强烈建议使用数据库中提交或者回滚交易而不是使用GoldenGate处理。 配置长交易告警 可以在extract进程中配置长交易告警，参数如下所示： warnlongtrans 12h, checkintervals 10m 以上表示GoldenGate会每隔10分钟检查一下长交易，如果有超过12个小时的长交易，GoldenGate会在根目录下的ggserr.log里面加入一条告警信息。通过察看ggserr.log或者在ggsci中执行view ggsevt命令查看这些告警信息，可以配置Director或自定义脚本发送告警邮件。 修改检查点 - Extract 修改主Extract的读检查点 修改全部检查点 Alter extract begin [now]|[yyyy-mm-dd hh:mm:ss] 修改单个检查点 Startup检查点无需修改 Current Checkpoint的修改 ALTER EXTRACT myext [, THREAD 2], EXTSEQNO 1126, EXTRBA 0 RAC环境下读取日志的Extract必须针对每一个节点单独指定thread号和日志序列号/字节进行修改 Recovery Checkpoint的修改 （内部命令） ALTER EXTRACT myext [, THREAD 2], IOEXTSEQNO IOEXTRBA 同Current Checkpoint，对RAC各节点均需单独修改 举例：如果重启时确认长事务无需复制，可以将Recovery设置为Current Checkpoint相同或之前的特定位置，跳过某些归档日志 修改主Extract的写检查点 不能强制指定Extract写检查点的extseno和extrba 只能通过重启或者ALTER EXTRACT myext, ETROLLOVER让Extract滚动到下一个队列，由于该命令不会写队列文件头尾信息需手工修改后继进程检查点以保证其顺利读到下一个队列。 注：如果是旧版本，只能通过ETROLLOVER滚动 修改Data Pump的读检查点 不能通过begin now或指定时间点修改Data Pump读检查点！ 只能修改Data Pump读取的队列序列号和字节 ALTER EXTRACT mydp, EXTSEQNO 26, EXTRBA 0 注：如果想要设定为从某个时间点开始，只能手工通过logdump查找队列中时间点附近的记录并指定从该记录位置开始 修改Data Pump的写检查点 同修改主Extract的写检查点，只能通过etrollover向下滚动一个队列 修改Replicat读检查点 同修改Data Pump的读检查点，只能通过指定队列序列号和RBA 修改Replicat写检查点 N/A，Replicat只使用一个检查点 增加复制表的步骤 停止Extract/Data Pump/Replicat进程 注意停止Extract时检查长交易和归档日志 在源和目标建立复制表 在源端为该表添加附加日志 修改Extract/Data Pump/Replicat参数中复制范围包含该表 重启Extract/Data Pump/Replicat进程 可以开始对新增表进行操作 注意：以上操作仅限于DML复制。如配置了DDL复制则可以自动生成附加日志和在目标端创建表结构。 场景分析 – 添加复制表忘记附加日志 场景描述 在添加复制表时，忘记了添加新增表附加日志 场景分析 Insert操作可以正常复制，不受附加日志影响 Update/Delete因为没有主键列信息记入日志，目标端无法生成对应SQL 处理方法 源库对该表添加附加日志 重新对该表进行初始化（见后面） Q：可否修改时间点或使用当前队列进行恢复？ 停止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进行排除，可以避免各进程做不必要的工作；同时，在各个进程参数均明确去掉该表可以保持前后的逻辑统一性和易读性 修改复制表结构的步骤 OGG在读取表结构定义后将其缓存在内存中，不自动进行刷新，因此凡涉及表结构变更，例如表中列的增删改和主键（或唯一索引）的变化均需按照下列步骤执行 （Q:普通索引如何？） 操作步骤 检查无延迟后停止源和目标端各进程（注意检验重启时归档日志可用性） 修改目标表结构; 修改源表结构; 如果表有主键(或唯一索引)，并且本次修改未修改主键，则可以直接启动源和目标所有进程继续复制，完成本次修改；否则，如果表无主键和唯一索引或者本次修改了主键则需重新为该表增加附加日志 ggsci> dblogin userid goldengate, password XXXXXX ggsci> delete trandata schema.mytable ggsci> add trandata schema.mytable 重新启动源端和目标端的抓取和复制进程。 如何打数据库补丁 影响打补丁流程的重点是附加日志的分析 开发时要求补丁按照DDL和DML进行划分 对数据库补丁脚本进行分析 核心是补丁中是否存在依赖于本次需新增或修改的表附加日志的操作 新增表数据的Update和Delete 原有表的PK修改（或无PK时UI修改、无PK/UI表任意列修改）以及对这些表的Update和Delete操作 以下不影响附加日志，无需予以特殊考虑 本次补丁涉及范围外的所有表的增删改操作 新增表的Insert操作 临时表及其任何操作 其它数据库对象的增删改操作 对数据库补丁脚本进行分析（续） 准备在目标端的脚本 所有源端的DDL操作 排除掉所有OGG可以复制过来的DML操作 按照逻辑顺序对这些脚本进行排序 打补丁操作步骤 停止Extract/Data Pump/Replicat进程，注意检查长交易和归档日志 根据补丁修改Extract/Data Pump/Replicat参数中复制范围 在两端执行DDL脚本 在ggsci中修改本次补丁需新增或修改的附加日志 在源端执行DML脚本 在目标端执行排除掉可复制操作后的DML脚本 重启Extract/Data Pump/Replicat进程，观察复制直到没有延迟 如果补丁需要依据逻辑顺序分为多个DDL和DML脚本，则继续重复以上步骤直到完成所有脚本 复制表的重新初始化 监控各进程到全部没有延迟 停止各进程，从源端导出此部分表并导入目标端 在Replicat参数中单独对该部分表加入冲突处理： MAP dbo.tcust, TARGET dbo.tcust, HANDLECOLLISIONS; 启动各进程直到没有延迟，去除该表的handlecollisions参数并重启Replicat 注意：如该表没有主键或唯一索引，不能使用本方法。只能在一个空闲时段或者锁定该表进行重新初始化。 Q：为什么不像安装实施时那样，等待所有交易最早开始时间小于进程停止时间后再做重新初始化？ 日常维护中如果遇到计划内停机时，例如硬件、操作系统、数据库等维护需要进行，应当 首先手工停止OGG所有复制进程和MGR进程 执行对应的维护操作 等待数据库恢复后，重新启动OGG的MGR进程和其它复制进程 避免进程出现异常退出 进程异常退出可能会带来未知的风险，如数据丢失、数据重复或OGG文件异常等 某些特定条件的异常退出进程来不及写入错误信息，给问题排除带来一定困难 GGSERR文件会写入错误信息引起报警 如果MGR进程出现问题，则无法自动重启其它进程
转载自：http://blog.itpub.net/196700/viewspace-1225782/
