解决了一个看似蹊跷的问题

    今天下午又一次检查了INFORMATICA跑SESSION时产生的日志，对几个含有“ORA-”错误的log日志认真地过了一遍。谁知发现了几个很异常的error log。我们的SESSION分为INSERT和UPDATE方式的两种，所以，error log里含有“ORA-00001”的错误应当为INSERT方式产生的才对，并且对于这种error的产生原因大都是源系统的脏数据导致。UPDATE方式的SESSION实际上是实现UPDATE ELSE INSERT的逻辑，因此，以这种方式产生的log文件里决不应当有“ORA-00001”的错误。不幸又有幸的是，今天下午就恰恰碰到了这样的问题：在跑UPDATE ELSE INSERT的SESSION时也报错——ORA-00001 违反唯一性约束！
    咋一看好像是不可理解的，因为是UPDATE ELSE INSERT操作。既然根据主键作比较，不同主键值的记录才能够进行INSERT操作，怎么还能报这种错误？仔细地查找原因，最终还是找到了错误产生的原因——竟是由目标系统中主键为char(n)类型引起的！
    这种情况发生的原理是：在第一次跑SESSION时（目标系统是干净的无数据的），如果有长度不满n位的数据进入后，ORACLE会自动在末尾添满n位的空格。就是这样的一个小动作，显然已经改变了主键字段的值。那么当第二次跑UPDATE ELSE INSERT的SESSION时，在对主键值进行比较的时候，补过空格的主键字段值显然与真实的不够n位的主键字段值是不相同的，因此INFORMATICA就产生了本不该进行INSERT的数据，紧接着INFORMATICA就进行了INSERT操作，这个时候ORACLE还是要对不够n位的主键字段值进行补空格的处理，这样就导致了主键值重复情况的产生，即报错：违反唯一性约束。

解决办法：
1、SAP系统中作为主键的字段，如果其类型为char(n)，但数据却不满位数n时，进入ODS层的时候应对其进行rpad的处理
2、在DW中的ODS层，将所有主键类型为char(n)的设置为varchar2(n)  /*推荐的办法*/
3、也可以什么都不要改，接受这种报错的情况，因为数据是没有丢失的。
(对于我这个实例，报错的session有：s_map_ods_marm.log, s_map_ods_t006.log, s_map_ods_t006a.log, s_map_ods_tcurc.log,s_map_ods_tcurt.log)

尾记：
这个错误起初看起来真的很蹊跷，着实让人摸不着头脑，不过，细心耐心查下去后就发现了其中的玄机。应当说，问题还是相当隐蔽的。问题是解决了，可是，我还想问一句：到底谁的错？  我晕，这个问题我可解不开了~~^_^

原文转自：http://www.ltesting.net