背景
用户11.2.0.1 on Solaris (Sun sparc 64bit)的库需要迁移到11.2.0.4 on SUSE Linux 11 64bit ,由于数据变化量骚大,停机窗口和测试窗口时间不允许,顾想用OGG方式的先将大基础数据先行同步过去,然后花一个礼拜的时间对其进行测试,测试完毕后,确定切换时间点。
由于用户数据库版本限制,我们只能采用了 ogg 11.2.1.0.1 on sparc solaris 64位的软件版本,采用了Classic Mode,而不能使用integrated mode,在POC阶段,打开database forcelogging模式的情况下,依然遇到如下问题:
ERROR OGG-01960 Failed to validate table NCAOWII.I_LLDCA. The table is created with the NOLOGGING option,which is not supported. Extract may not be able to capture data from it. |
顾参考了oracle提供的workaround方法,如下:
Reference: MOS(OGG Extract 11.2 abends with ERROR OGG-01960 Failed to validate table The table is creat ed with the NOLOGGING option, which is not supported. [ID 1465720.1]) Applies to: Oracle GoldenGate - Version 11.2.1.0.1 and later Information in this document applies to any platform Symptoms On : 11.2.1.0.1 version, EXTRACT executable When starting the extract, the following error occurs: ERROR ----------------------- ERROR OGG-01960 Failed to validate table MSC.MSC_SUPPLIES. The table is created with the NOLOGGING option, which is not supported. Extract may not be able to capture data from it. Cause Prior to v11.2 extract logs a warning message and keeps the extract running which can cause data loss. When user upgrades from v11.1.1.1.x to 11.2, an extract abended with "ERROR OGG-01960 Failed to validate table." From OGG v ersion 11.2 onward, the default behavior is to make the extract abend when it encounters a table/partition create d with nologging option. Solution Workaround: As a temporary workaround, DBOPTIONS ALLOWNOLOGGING can be added after USERID parameter in the extract parameter file. This parameter will cause the extract to log a warning message and continue to run. However, there is a cha nce for data loss. Resync in required. To get the extract running: 1. edit params 2. Add the following parameter after USERID parameter DBOPTIONS ALLOWNOLOGGING 3. Restart the extract Note: However post the code change in bug 14158453 the parameter DBOPTIONS ALLOWNOLOGGING is no longer valid. Ext ract no longer relies on the table metadata (logging/ nologging) and instead uses special records in the redo log to detect missing data and when detected it would error as below indicating the object id of the table in questi on. 2012-08-02 09:10:09 ERROR OGG-01965 The redo record indicates data loss on object 167,946 Workaround: The table can be excluded from the extract, enable logging at the table/ partition/ tablespace level and include it back in the extract if it needs to be replicated across. Solution: Change the table/partition created with NOLOGGING option to LOGGING option and resync the source and target table s. |
ORACLE 给出的解决方法是在 EXTRACT 进程的配置文件里加上 DBOPTIONS ALLOWNOLOGGING 参数,允许表是NOLOGGING 属性,增加 DBOPTIONS ALLOWNOLOGGING 参数后,暂时还没遇到不利影响,但如果符合能用integrated mode条件的话尽量采取这种方式进行数据同步 。