表结构完全一样也报错啊？ OGG-01161 Bad column index (xx) specified for table ., max columns = xx

你有没有遇到过表结构完全一样也报错啊？

ERROR OGG-01161 Bad column index (94) specified for table ., max columns = 94

处理思路：检查对比源端和目标端的表结构是否一致：包括字段个数、字段类型、字段长度，主键索引个数。理论上确保一致即可。但发现的确是一致的，太奇怪了？？？

故障现象

目标端ogg复制进程报错：
view report rep_xx

故障处理：

1.对比表结构：字段结构发现完全一致
2.对比索引：目标端缺少一个索引，创建完索引，但是还是报一样错误–其实ogg源和目标端的普通索引可以不同
3.询问故障前，源端表做过什么变更？

4.原来是源端增加过字段后删除。

处理办法：

1.源端提供增加字段后的def发送到目标端替换
2.目标端增加之前源端删除的字段
3.目标端启动复制进程观察，报错后
4.源端提供删除字段后的def发送到目标端替换
5.目标端删除增加的字段后启动复制进程
6.同步正常

相关参考：OGG-01161 Bad Column Index Even When Tables Have Same Structure (Doc ID 2165535.1)

Oracle GoldenGate - Version 12.2.0.1.0 and later
Information in this document applies to any platform.
SYMPTOMS
Here is the error detail from report file:-

2016-07-25 02:17:24 ERROR OGG-01161 Bad column index (18) specified for table <Schema_name>.<Tablename>, max columns = 18.

Last log location read:
  FILE: <FILE_NAME>
  SEQNO: 5633
  RBA: 105503639
  TIMESTAMP: 2016-07-21 07:16:21.000000
  EOF: NO
  READERR: 0


2016-07-25 02:17:24 ERROR OGG-01668 PROCESS ABENDING.
 

CHANGES
 There could be the situation where assumetargetdef is define and your source and target table have same structure ( suppose 18 columns )  and due to some change request , you have to add a new column in source table and then same column was added on target side.

DML application run on table and then all of sudden , you have to revert back the change request ( DDL changes ) and you drop that newly added column from source and target also. But data run after DDL changes captured by extract and present in trail but did not get replicated in target table , So kind of situation can come.

CAUSE
2016-07-25 02:17:24 ERROR OGG-01161 Bad column index (18) specified for table <Schema_name>.<Tablename>, max columns = 18.
 
Issue with DDL structure different from source and trail file.
 

SOLUTION
Follow the below steps which will help you

  A. add the dropped column in target replicate
  B. start the replicate
  C. let it abend with same error where it say it has 18 columns and target has 19 columns , then drop the last column which you have added in step A
  D. Then start the replicate and it will work fine.
 

REFERENCES
NOTE:1585474.1 - Using OGG Logdump Getting Message Bad Compressed Block, Found Length Of < ( )>, RBA <>

其它可能原因：OGG Replicat Abends with OGG-01161 Bad Column Index (Doc ID 1263504.1)

SYMPTOMS
OGG (Oracle GoldenGate) replicat is abending with error
OGG-01161 Bad column index (###) specified for table ###.###, max columns = ###.
The replicat parameter file shows, assumetargetdefs is in use
CAUSE
Causes
1) The target table doesn't match source table, there is a mismatch on columns for source and target.

The source and the target are not the same structure.
In such a case assumetargetdefs cannot be used.

So if this had worked before ok, there was a change in the source table and this change needs to be propagated to the target as well.

2) The same can occur if sourcedefs is used and the sourcedefs are not current with the data in the trail record. This happens when a DDL is changed and a new sourcedefs file is not generated or the implementation of the new defs file is not synchronized with the updates to data using the new table structure.

3) The trail is encrypted and replicat does not have DECRYPTTRAIL in the parameter or when the ENCKEYS does not match between source and target. An Encrypted trail can be checked by running logdump and displaying any DML records without specifying the DECRYPT logdump command. It will display for example "Bad compressed block, found length of 34475 (x86ab), RBA 5059589"

SOLUTION
1) Compare the description of the failed table on source and target, e.g. if it is an Oracle RDBMS, run
desc <schema>.<table>
and compare the results,
Then alter the target table accordingly to match the source.
Restart the replicat

2) Rerun DEFGEN

3) Provide the necessary decryption.