OGG 投递进程报错OGG-01163处理一例

问题现象

监控告警有一个OGG源端的投递(EXTRACT)进程挂起，尝试直接start无法启动。view report查看报错信息为OGG-01163 Bad column length(65536) specified for column XXXX in table XX.xxxx ,maximum allowable length is 2.

问题分析

这个报错之前也遇到过，不过都是在目标端复制(REPLICA)进程出现的报错，原因是源目标端表字段长度不一致。现在的情况不一样。

1. 查看源目标端表字段定义境均为varchar2(2)
   
2. 检查表的trandata也是enabled
   

到此没的了分析思路，开始分两路想办法：

1. 今晚是公司版本日，大概率对这张表做了变更操作，开应用运维确认具体的变更操作。
2. 去网上找相关的文章看有没有提供解决思路。
   百度查了一下报错关键字。翻了几页相关文章讲的都是复制进程出现这个报错如何处理，而且好多都是内容一模一样网站不同，没有什么参考价值。这里要吐槽一下百度了，关键时刻找不到什么有用的信息。也可能是我用的关键字不对，但是用同样的关键字在BING搜索第一条就出现想要的MOS解决建议。

问题解决

从应用运维处得到反馈，对这个字段做了调整字段长度及类型的操作，是从char(1)改为了varchar2(2)


使用BING搜索找到MOS上的一篇文档对于这个问题的处理方法。
Extract Abends with ERROR OGG-01163 Bad column length (4) specified for column ADDRESS in table SCHEMA1.TABLE1, maximum allowable length is 3. (Doc ID 1540652.1)
详细内容贴图在下面，方便没有MOS账号的同学参考。英文文档自行阅读，就不做翻译了。

详细阅读文档，最后一句是解决我们问题的关键：
Or if this is an Extract PUMP , removing the USERID parameter and adding PASSTHRU would stop this check occuring
添加PASSTHRU参数到投递进程，问题解决。
PASSTHRU参数解释

官方解释：
Use the PASSTHRU and NOPASSTHRU parameters to control whether a data-pump Extract processes tables in pass-through mode or normal mode. In pass-through mode, the Extract process does not look up table definitions, either from the database or from a datadefinitions file. Normally, the Extract process logs into the database to retrieve data definitions and, if the target is NonStop, reads a data-definitions file. The definitions are used to perform mapping and conversion functions.
中文博客解释：https://blog.csdn.net/clep17285/article/details/100253564

总结

1. 由于非正常的字段类型调整，导致OGG进程异常，后面需要添加到上线规范中，防止此类事情的发生。
2. 使用好的搜索工具可以提高问题处理效率。

OGG 投递进程报错OGG-01163处理一例

原文：https://blog.51cto.com/hbxztc/2825057