【OGG-01414】extract abend CACHEMGR: tran id: 0 length memtran
rac一节点配置了OGG，在启动extract进程不久后报错：OGG-01414CACHEMGR: tran id: 0 length memtran: 0x0000000103cba020，查了MOS解释如下：
APPLIES TO:
Oracle GoldenGate -Version 11.1.1.0.7 and later
Information in this document applies to anyplatform.
SYMPTOMS
Because CDR is used at replicat, the beforeimage is taken from extract. When extract contains GETBEFORE* parameter, like GETBEFORECOLS orGETBEFOREUPDATES, sometimes, extract abends with error:
Source Context :
SourceModule : [ggapp.cachemgr]
SourceID :[/scratch.local/mmar/view_storage/mmar_16702510/oggcore/OpenSys/src/gglib/ggapp/cachemgr.c]
SourceFunction : [cm_obj_free_resources]
SourceLine : [1230]
2013-05-20 21:19:27 ERROR OGG-01414CACHEMGR: tran id: 0 length memtran: 0x0000000103cba020.
--由于replicat进程使用了CDR，若extract进程使用GETBEFORE*参数，那么extract进程有时就会abend掉。
CAUSE
Cause:
This is bug 16837538.
It happens when following conditions are met:
1) getbeforeupdates or any variation of such that causes extract to generate 2separate records in trail on update operation.
2) inline lob/xml (out-of-row data is fine since extract filter out allout-of-row lob/xml from before image)
3) Conversion required on inline lob/xml (either via parameter_CONVERTUCS2CLOBS or db multi-byte character set)
4) result of conversion on lob/xml with length > 4k (this causes data to gointo lobrow instead of regular buffer)
--看来跟lob字段有关，我要同步的一张表有lob字段，源数据同步到目标端需要进行转换（源端与目标端完全异构），extract参数文件中也使用了getupdatebefores及CONVERTUCS2CLOBS参数，符合造成1414错误的多种情况，从而导致extract挂掉。
SOLUTION
A fix will be provided in11.2.1.0.7. A backport may be requested before the availbility of11.2.1.0.7.
The workarounds are:
1. do not get before image
2. exclude the table from extract and resync later.
--我把getupdatebefores参数从extract中去除就没问题了。
REFERENCES
BUG:16837538 -EXTRACT ABEND WITH TRAN ID OF 0
OGG-1414这个错误和CDR有很大的关系，那么来看下什么是CDR？
CDC——ConflictDetection and Resolution 冲突侦测与解决
Handlingconflicts with the Oracle GoldenGate CDR feature
OracleGoldenGate Conflict Detection and Resolution (CDR) provides basic conflict resolutionroutines that:
● Resolve a uniqueness conflict for an INSERT.
● Resolvea “no data found” conflict for an UPDATE when the row exists, but the before image of one or more columns is differentfrom the current value in the database.
● Resolvea “no data found” conflict for an UPDATE when the row does not exist.
● Resolvea “no data found” conflict for a DELETE when the row exists, but the before image ofone or more columns is different from the current value in the database.
● Resolvea “no data found” conflict for a DELETE when the row does not exist. To use conflictdetection and resolution (CDR), the database must reside on a Windows, Linux,or UNIX system. It is not supported for databases on the NonStop platform. CDRsupports data types that can be compared with simple SQL and without explicit conversion:
❍NUMERIC
❍DATE
❍TIMESTAMP
❍CHAR/NCHAR
❍VARCHAR/ NVARCHAR
This means that these column types can beused with the COMPARECOLS parameter, the GETBEFORECOLSparameter, and as the resolution column inthe USEMIN or USEMAX option of the RESOLVECONFLICTparameter. Only NUMERIC columns can be used for the USEDELTAoption of RESOLVECONFLICT. Do notuse CDR for columns that contain LOBs, abstract data types (ADT), oruser-defined types (UDT). --看到了吧，含有LOB字段就不要使用CDR了！
Conflict resolution is not performed whenReplicat operates in BATCHSQL mode. If a conflict occurs in BATCHSQLmode, Replicat reverts to GROUPTRANSOPSmode, and then to single-transaction mode.Conflict detection occurs in all three modes. For more information, see the BATCHSQLparameter in the Oracle GoldenGate Windows and UNIX Reference Guide.
Sharon
20140512
-----------------------------------------------------------------------------------------------------
转载须注明出处与链接！！！！
转载须注明出处与链接！！！！
转载须注明出处与链接！！！！
转载须注明出处与链接！！！！