一次数据库连接BUG数据排查

本次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,更换了驱动,本机测试,,一切正常。。。

 

最后总结这两天,排查过程艰辛而有趣,但是解决方法很简单。。反而无趣了。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值