goldengate回切switchback 与数据校验/验证/比对
goldengate回切switchback 与数据校验/验证/比对回切步骤(1)
恢复生产系统数据库服务，如果数据库可以直接恢复，只需要处理数据增量同步，如果数据库本身不可恢复，需要从应急系统向生产系统进行全量数据初始化
在生产数据库上禁用触发器和数据约束
启动生产数据库的数据投递进程，从应急数据库向上产数据库同步数据
应急系统积压的数据处理完毕，生产系统数据实现与应急数据库的同步
停止应用运行，确认数据已经完全同步回生产系统（数据对比见下文)
启动生产系统的数据捕获进程
启用生产系统数据库的触发器和数据约束
重置生产系统数据库的Sequence
修改应用的数据源配置到生产系统数据库
启动应用
禁用应急数据库的触发器和数据约束
确认应急数据库的数据同步配置包含Sequence，启动应急数据库的数据投递进程
监控数据同步情况和系统运行情况。
回切步骤(2)
在生产端， 停止旧的extract进程
在生产端，禁止和复制表相关的cascade constraints，disable表的外键,修改表的强制自增列为默认自增列
在生产端， 添加、配置并启动replicat进程，准备应用来自于应急端的数据
在应急端， 添加并启动data pumb进程， 将增量数据传送到生产端
在应急端，启动监测日志extract进程,扑捉数据库新生成的数据，并传递给data pump.
在生产端和应急端，观察数据同步情况，如果数据大致持平那么
在应急端， 停止业务应用
在生产端，观察数据是否已经完全同步（数据对比见下文)
在生产端， 如果数据已经完全同步， 则停止并删除replicat
在生产端，启用和复制表相关的cascade constraints,和相关外键约束
在生产端，添加并启动extract进程，用于捕获生产端的增量数据
在生产端， 启用业务应用
在应急端， 停止extract进程和data pumb 进程
在应急端，禁止和复制表相关的cascade constraints
在应急端，添加并启动replicat
在生产端，添加并启动data pumb，将增量数据同步到应急端
回切前的数据比对
数据比对的总体方案
数据比对的目的是：确认应急库上所有的更新是否都已经被应用到生产端，即验证应急与生产库的数据一致性。
经过与国内售前、售后部门多个资深GoldenGate工程师的深入交流，对于VLDB，只能采用一种基于客户业务数据的比对方案，即：
根据表中数据的性质，将全部进行复制的表进行分类。
每种类别，采用不同的方式进行比对。
回切前的数据比对
数据复制中的比对
应急库的数据是动态的。
在不停止GoldenGate的情况下，生产库的数据也是动态的。
一种比对方案是：计算并比较日志表中历史记录的数量，也可以比较某些字段的sum值。
比如，可以将按日期字段进行分区的表作为日志表。
将分区字段作为查询条件，计算记录数。
select count(*)
where part_key between to_date( ‘20121028’ ) and to_date( ‘20121029’ )
数据类型 数据重要性 数据量 数据比对方式
日志表 一般 大 对比最近某天的记录数，并且计算sum值
回切前的数据比对
回切前的比对
在停止了应用、源库的数据不再被更改后，对比应急库与生产库。
数据已经为静态的。
一种分类比对方案是：
数据类型 数据重要性 数据量 数据比对方式
客户资料表 最为关键 很大 • 对比全表的记录数； • 对于关键字段（比如具有账户金额性质的字段）获取全部记录的 sum 值，再进行比对。
码表、其它小表 最为关键 小 利用 select minus 语句，对于源、目标库执行两遍全表的数据对比（分别为从源到目标、从目标到源）。
日志表、其它大表 一般 超大 对比全表的记录数
两端数据不一致的排查与解决
1.数据复制本身的延时
2.目标库数据库内部存在内部导致修改数据的对象和机制
3.操作系统上的jobScheduler
4.OGG的错误处理模式设置
5.修改OGG的检查点
6.OGG配置的逻辑错误
7.OGG配置参数的正确性
8.其它可能导致数据不一致的因素 如人工误操作
解决方案1.人工补足少量的数据
2.执行部分表的初始化
3.全部重新初始化
应急系统向生产系统回切
6.1 回切条件
原有生产系统恢复运行，如果原生产系统数据可以恢复，首先完成从生产向应急的剩余数据
同步过程，然后启用生产系统的投递进程，把应急系统运行期间处理的数据同步回生产系统，
应急系统的积压数据处理完成后即具备向生产系统回切的条件。
6.2 回切操作
如果生产系统中存在强制性自增列则：
1. 应急系统向生产系统进行全量数据初始化，并开始捕获应急系统的增量数据
2. 在生产数据库上禁用触发器和数据约束
3. 启动生产数据库的数据投递进程，从应急数据库向上产数据库同步数据
4. 应急系统积压的数据处理完毕，生产系统数据实现与应急数据库的同步
5. 停止应用运行，确认数据已经完全同步回生产系统
6. 启动生产系统的数据捕获进程
7. 启用生产系统数据库的触发器和数据约束
8. 修改应用的数据源配置到生产系统数据库
9. 启动应用
10. 禁用应急数据库的触发器和数据约束
11. 确认应急数据库的数据同步配置，启动应急数据库的数据投递进程
12. 监控数据同步情况和系统运行情况。
如果生产系统中不存在强制性自增列则：
1. 恢复生产系统数据库服务，如果数据库可以直接恢复，只需要处理数据增量同步，如果数据
库本身不可恢复，需要从应急系统向生产系统进行全量数据初始化
Copyright @ 2009 Oracle Corporation
All rights reserved.
广东移动网上营业厅应急系统建设方案
2. 在生产数据库上禁用触发器和数据约束
3. 启动生产数据库的数据投递进程，从应急数据库向上产数据库同步数据
4. 应急系统积压的数据处理完毕，生产系统数据实现与应急数据库的同步
5. 停止应用运行，确认数据已经完全同步回生产系统
6. 启动生产系统的数据捕获进程
7. 启用生产系统数据库的触发器和数据约束
8. 修改应用的数据源配置到生产系统数据库
9. 启动应用
10. 禁用应急数据库的触发器和数据约束
11. 确认应急数据库的数据同步配置，启动应急数据库的数据投递进程
12. 监控数据同步情况和系统运行情况。
两端数据不一致的排查与解决
现象
在执行数据对比过程中，部分网省的业务系统中发现有部分表在两端的记录是不一致的。
原因分析与排查
两端出现数据不一致的原因非常多，下面是对比结果有差异的一些可能性因素：
数据复制本身的延时
由于源端数据可能一直在变化，而对比只能取当时时间的数据，两端取出来的数据有一定差异，所以有可能带来对比结果不一致。
此时并不一定是复制出现问题，可以针对这些不一致的记录做进一步的观察，过一段时间进行再确认。
目标库数据库内部存在内部导致修改数据的对象和机制
可能包括数据库中的对象：如没有被禁止的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
所有的报告文件
丢失数据的大致操作时间
丢失数据相关时段的归档日志
根据不一致数据表的多少以及不一致数据的条数，可以采取以下方案：
人工补足少量的数据
在确认只有部分表的若干条数据不一致后，可以使用手工方法对不一致的数据进行重新再同步，即从源端找出当前的值，覆盖目标表的相关记录。本方法只适用于不一致数据较少的情况，如从discard文件中可以找到有限的出错记录。
执行部分表的初始化
当其中某些表不同步，而数据条数较多时，可以对该部分表执行重新初始化，具体步骤参见运维文档的第5.5节。
全部重新初始化
当大部分表出现不一致的情况时，需要对全库执行重新初始化，可以按照安装实施文档的步骤执行，之前请务必保证安装实施文档中的步骤正确性，如有问题可以联系技术支持。
谢谢分享，正需要 thanks a lot
页:
[1]