Non-standard redo detected in 10g compatible format. 导致extract abend

Maclean Liu(刘相兵

Non-standard redo detected in 10g compatible format. 导致extract abend



***********************************************************************
                 Oracle GoldenGate Capture for Oracle
                      Version 10.4.0.19 Build 002
   Linux, x64, 64bit (optimized), Oracle 11 on Sep 18 2009 00:14:22

Copyright (C) 1995, 2009, Oracle and/or its affiliates.  All rights reserved.


extract


CACHEMGR virtual memory values (may have been adjusted)
CACHEBUFFERSIZE:                         64K
CACHESIZE:                                8G
CACHEBUFFERSIZE (soft max):               4M
CACHEPAGEOUTSIZE (normal):                4M
PROCESS VM AVAIL FROM OS (min):          16G
CACHESIZEMAX (strict force to disk):  13.99G

Database Version:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
PL/SQL Release 11.2.0.2.0 - Production
CORE        11.2.0.2.0        Production
TNS for Linux: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production

Database Language and Character Set:
NLS_LANG = "AMERICAN_AMERICA.UTF8"
NLS_LANGUAGE     = "AMERICAN"
NLS_TERRITORY    = "AMERICA"
NLS_CHARACTERSET = "UTF8"

2013-10-17 17:24:41  GGS WARNING  Z1-078  No valid default archive log destination directory found for thread 1.

2013-10-17 17:24:42  GGS WARNING  Z1-078  No valid default archive log destination directory found for thread 2.

2013-10-17 17:24:42  GGS INFO     Z0-016  Default thread stack size: 10485760.

2013-10-17 17:24:42  GGS INFO        112  Recovery initialization completed for target file /home/gggate/goldengate/dirdat/e6044241, at RBA 1062.

2013-10-17 17:24:42  GGS INFO     Z0-05M  Output file /home/gggate/goldengate/dirdat/e6 is using format RELEASE 10.4.
     212248761882775453  Redo Thread 1:  thread abend: REDO_read_transaction( 1, (nil), Non-standard redo detected in 10g compatible format. )-> 500

Source Context :
  SourceModule            : [er.redo.ora.rtc]
  SourceID                : [$Id: //depot/releases/OpenSys/v10.4.0/src/app/er/redo/oracle/rtc.c#2 $]
  SourceFunction          : [RTC_producer]
  SourceLine              : [1748]
  ThreadBacktrace         : [5] elements
                          : [/home/gggate/goldengate/extract(_ZN15CMessageContext16AddThreadContextEv+0x26) [0x605e66]]
                          : [/home/gggate/goldengate/extract(_ZN15CMessageFactory13CreateMessageEP14CSourceContextjz+0x386) [0x5fe836]]
                          : [/home/gggate/goldengate/extract(_Z12RTC_producerPv+0x38e) [0x5ed76e]]
                          : [/lib64/libpthread.so.0 [0x2ba04e42c73d]]
                          : [/lib64/libc.so.6(clone+0x6d) [0x2ba051bb5d1d]]

2013-10-17 17:24:42  GGS ERROR       190  Non-standard redo detected in 10g compatible format.

2013-10-17 17:24:42  GGS INFO        224  Rolling over remote file /home/gggate/goldengate/dirdat/e6044241.

2013-10-17 17:24:42  GGS INFO        112  Recovery completed for target file /home/gggate/goldengate/dirdat/e6044242, at RBA 1062.

2013-10-17 17:24:42  GGS INFO        112  Recovery completed for all targets.



212248761882775453  Redo Thread 1:  thread abend: REDO_read_transaction( 1, (nil), Non-standard redo detected in 10g compatible format. )-> 500  


导致了goldengate ogg的extract 进程 abend ， 之前的操作时设置了 seqno 和RBA


原因是10.4的bug :

Oracle GoldenGate - Version 10.4.0.19 and later
Information in this document applies to any platform.
Checked for relevance 15-Oct-2012
Symptoms

OGG Extract abends : Non-Standard Redo Detected in 10g compatible Format
Cause

Cause 1

This error occurs when  the extract's starting seqno# and rba are not on log write boundary. When positioning by time, extract will find the right log write boundary by itself.

Cause 2

Extract may fail with same error due to bug in AsyncReader logic. This issue occurs when the AsyncReader reaches an EOF condition and stops read operations before the REDO thread detects the EOF condition and instructs the AsyncReader thread to stop reading.


Solution

Solution 1

Alter extract to position by timestamp and restart

ggsci> ALTER EXTRACT {extract group}, BEGIN {timestamp}
ggsci> START {extract group}

Solution 2

1. This issue is recoverable by restarting extract

2. This issue can be avoided via 'tranlogoptions _NOREADAHEAD CURRENT'

3. Upgrade to 11.2.1.0.0 or later

lunar

ogg 10.4.0.19，这个版本的ogg比较经典，是oracle'收购ogg后国内开始大面积推广的早期版本，我的第一个客户用的就是这个版本，结果遇到一个致命bug：对于BLOB数据，无论你以前的lob有多大，同步到目标段后都是XXX bytes（记不清具体数字了，好像是83bytes？？），且OGG 10.4.0.19的这个bug在所有平台都很容易重现。。。我的客户是直接上生产了，因此，结果你懂得，O(∩_∩)O哈哈~。。。。。。。