本次BUG事件排查为两天,事发是实施在客户处收到一个线上BUG,我们提供的webservice服务在操作的时部分数据入库有问题。
第一反应是:数据本身有问题,因为有部分数据入库,而部分数据入库。但我们的业务逻辑是对数据进行加密,同时将原始数据和加密后的数据进行入库,那么首要操作需要排查出出问题的原始数据。这时,问题出现了,客户没按原来的定好的逻辑操作,而是将原始数据加密后,作为原始数据传给程序,我们的程序再次加密,同时,提供给我们的为
dmp文件,故需要导入数据库才能查看(后发现,这个细节没有引起我足够的注意,导致浪费了很多时间)。导入oracle 10g后发现数据已经是以乱码形式存在,根本无法比较正确入库和未入库的数据有什么区别。
然后想到的是,查看日志,但是,因为是产品,真正运行环境是实施所在的外地,在人家的环境,所以在第一时间没有获得日志。
然后想到的是,最痛苦的过程 重现环境。。。。产品分为两部分,一部分是提供webservice接口的服务,一部分是提供一个管理平台,问题又来了,管理平台源码居然没有了!
后来千辛万苦,找到了一份可以执行的.class。。重现搭建好环境后,第一天已经过去了。。
第二天的情况是,得到了客户环境的日志,发现
出错的数据分为两类,1是对应的字段为varchar2(200)但是,持久化的字段只要为中文,就会报错。2对应字段为clob,但是当存入的数据超出某个长度的时候,也会报错,而报出的错误为一个:ORA-01461: can bind a LONG value only for insert into a LONG column。
经过google后,发现大家对这个错误的解决为:1,更新jdbc驱动 2将clob数据分开储存。而引起中文这个问题的可能性最大是因为数据库的字符集。
突然想到是不是数据库版本有问题 然后确定客户数据库版本,,他们果然是11g...当时有种莫名的东西堵在胸口。。。要知道,这可是线上运行很久的系统了,我是从接到bug的时候才开始知道这个项目的。NND,更换了驱动,本机测试,,一切正常。。。
最后总结这两天,排查过程艰辛而有趣,但是解决方法很简单。。反而无趣了。