2009年七月月 发布的文章

分享一个Oracle OCI库的BUG

上周测试组反馈在一台HP X86-64主机Solaris 10 for X86环境下部署的应用无法连接Oracle数据库,错误码ORA-12154。而另外一个产品的部署在这台主机上的应用却能正常连接到数据库。本周安排专人对该问题进行查找,在先后排除了用户环境设置、Oracle数据库服务端等问题后,我们最终把目光集中在了Oracle客户端的OCI库上。

定位过程如下:
1、SQLPLUS可以访问数据库;
2、同环境下另一个应用可以访问数据库;
以上证明用户环境和tnsnames.ora配置没有问题;
3、通过抓包未发现客户端有到Oracle服务端的链接和数据传输,所以该问题应该与Oracle Server端一毛钱关系都没有;
4、发现我们产品的应用使用的是32bit库编译的,而另外一个产品的应用使用的是64bit库,但两个产品底层调用都是一样的;
5、基本锁定是该主机上装的Oracle OCI 32bit库有bug;
6、我们的资深系统工程师在Oracle官方找到了该问题的根源;
7、安装新patch后,应用顺利连接到Oracle Server,问题解决。

Oracle官方对该问题的说明摘录如下:
Solaris x86-64: Running 32-bit Applications Connecting to Database Using TNS Naming Adapter Fails With Segmentation Fault (SIGSEGV) or ORA-12154
  Doc ID:  388631.1 Type:  PROBLEM
  Modified Date :  23-OCT-2007 Status:  PUBLISHED

——————————————————————————–
Applies to:
Oracle Server – Enterprise Edition – Version: 10.2.0.2

Symptoms
Running 32-bit applications connecting to Database using TNS Naming Adapter Fails With Segmentation Violation (SIGSEGV)

Segmentation Fault(coredump)

Running 64-bit work as expected.

Other symptoms would be

ORA-12154: TNS:could not resolve the connect identifier specified

Cause
This has been identified to be caused by
Bug 5389730 10.2.0.1 32BIT OCI EXECUTABLES FAILS WITH ORA-12154 ON SOLARIS 10 X86-64(AMD64)

TNS Naming Adapter was not included within the 32-bit Naming Libraries.

Solution
This is fixed Oracle11g Client 11.0.

There exists patches for 10.2.0.2 and 10.2.0.3:

download and installPatch 5389730 with opatch or

To implement the solution manually, please execute the following steps:

Download Patch 5389730
cp $ORACLE_HOME/network/lib/ins_net_client.mk
$ORACLE_HOME/network/lib/ins_net_client.mk.prePatch_5389730
extract ins_net_client.mk into $ORACLE_HOME/network/lib/ins_net_client.mk
cd $ORACLE_HOME/network/lib
make -f ins_net_client.mk nnfgt.o
Which update (check this)
$ORACLE_HOME/lib/libn10.a and $ORACLE_HOME/lib32/libn10.a
make -f ins_net_client.mk client_sharedlib

which update (check this)
#$ORACLE_HOME/lib32/libclntsh.so
#$ORACLE_HOME/lib32/libclntsh.so.10.1
#$ORACLE_HOME/lib/libclntsh.so
#$ORACLE_HOME/lib/libclntsh.so.10.1

Check that executable is loading $ORACLE_HOME/lib32/libclntsh.so.10.1 by ldd ‘executable’

All dynamically linked applications that use libclntsh should work now.
Static linked applications, need to be relinked with the new libraries.

Picasa Web Albums疑似被和谐了

网络相册,我一直用Google的Picasa Web Albums。若干年前的我最初使用的是Flickr,可好景不长,Flickr的图片地址在国内无法访问到了。无奈换到Picasa Web Albums,当初还花了好大力气将各个blog文章中的图片重新上传到Picasa,并更换文章中的链接。近期我最喜欢的巴萨开始正式赛季前的热身了,本打算写几篇文章发表下看法,但是却发现Picasa Web Albums无法显示相册图片了,而且以前上传的图片在blog中也无法显示出来。到Google的帮助中心看了一下,才发现原来国内很多地方的网友都在帮助中心的论坛上发帖,咨询为什么无法看到Picasa的图片了。这时我才醒悟:疑似Picasa Web Albums遭遇了与饭否等的同等待遇-被和谐了。

政府的这种手段不用多加评论了,大家心里都有数了。在没有Pisaca的这段日子里,只能暂以纯文字形式记录生活吧。期待Pisaca早日恢复正常。

周末“捉虫”记

周六,对于上班族来说是多么好的日子,能在家里享受自由的无拘无束的生活而且不用担心第二天的工作,应该说是一周中最没有压力的一天。六点半起床,慢慢喝下一杯225ml左右的凉白开(保健医生说20-25摄氏度的凉白开比较适宜作为起床后的第一杯水),套上运动短裤和上衣,打开MP3播放器,塞上耳机,出门在园区内慢跑。昨晚下了一场雨,所以园区早上的空气很好。耳畔酷玩乐队的“Viva La Vida”让我跑起来很轻松,30分钟的有氧慢跑能让我的大脑和心脏获得足够的氧气,心情也变得更好。最后绕着园区走上一圈结束锻炼。

回房间后,舒舒服服的冲了个热水澡。简单的吃过早饭后就回到了本本前,本来计划解决一下本周五发现的一个GB2312转Unicode码的问题。但此时远在南方某省的技术支持人员打来电话,说我们的产品又出现问题了。这个问题早有端倪,曾先后引起客户总部的投诉、当地一些客户的投诉以及计费部门的投诉。前些时间在查这个问题时一直很迷惑,同样的机器和配置在其他省就没有问题,为什么唯独在该省问题严重。而且从业务量上来说,该省虽然业务量上比其他省高出一些,但按照目前我们产品的处理能力来看,还是完全可以满足要求的。在没有找到根本问题前,本周一直在做一些程序部署上的优化以及参数调整,希望能通过这些手段来缓解问题的严重程度。

本周五刚刚完成了一些I/O上优化,周六却又出现了问题,而且这次是客户集团总部的投诉。前方的技术人员已经是火急火燎,但是查问题也不是一蹴而就的事情,还是需要细心、耐心和稳定的心理的,不能头脑发热。

所有问题的查找都只能从已出现的问题现象着手。今天问题的现象是:我们的产品作为Server端时无法及时收消息并回应答,导致客户端异步发送窗口中的消息超时并重发该消息,而这条重发的消息因与前一条消息有着同样的消息ID而被我们的产品拒绝。还有一个现象就是:我们的产品作为Client端向一内部的鉴权子系统发鉴权请求,因未能及时收到应答而导致我们自己的异步发送窗口中的消息过期而直接进行了下一个环节的处理,这样一来这些消息在用户体验和计费上都会出现问题而导致投诉。

试着调整一下两端通信的参数以及一些队列的缓存参数,生效后也仅仅缓解了一段时间就再次出现了类似的问题,严重时双方居然因为socket阻塞而导致链接断开。这时技术支持同事提到主机I/O特别高。I/O高倒是很好的解释了socket未能及时被读取的问题,但是本周明明做了些I/O优化,为什么I/O还是这么高,而且此时该省的业务量相当的小,基本排除因业务量过大而导致I/O高的可能了。但是又是什么导致阵列I/O高呢?甚是疑惑!

究竟是什么问题导致大量磁盘操作呢?无意间在产品运行环境里发现一个Core文件,如果只发现一个core文件倒不足意外,但是发现这个core文件有上G的容量,而且一直在不断被刷新。难道就是这个core的不断刷新导致了I/O特高?遂尝试写了个脚本每个2秒尝试rm一次该core文件。果然经过这一处理,I/O降了下来,上面的问题也不再出现了。停掉脚本,I/O又攀升了上来,上面的问题就又出现了。“罪魁祸首”终于找到了!

虽然使用脚本可以临时解决问题,但是这样解决问题显然是不负责任的。到底是什么导致Core的出现呢? 停掉脚本,让程序产生core,对core文件进行分析。通过pstack和gdb打开core文件,core文件输出的信息很少,很多信息都成了“???”,似乎栈被破坏了。不过可以获得出core文件的进程号以及dump core的接口函数名字。通过进程号和程序日志共同定位,发现出core的进程都是在处理同一个客户端提交的消息。让技术支持同事封掉该客户端的IP,果然再没有Core产生,看来是我们的程序在处理这家客户端提交的消息时出了问题。

到目前为止已经大有收获了。继续!利用snoop工具获得了该客户端提交的消息包的信息。经过对比分析发现,该客户端提交的包信息与协议中定义的格式不符合。但是我们的程序居然没有发现这样的非法格式包,进一步结合代码、包信息和core信息进行分析,终于定位到了问题所在。原来是我们的程序的一个函数实现逻辑有误,而这种错误在处理正常格式包时是不会发生的,但是处理这种非法格式包时,会导致严重的栈上缓冲区溢出,直至进程运行混乱,dump core并退出。

这时想起周五同事发来的一封邮件,说的是我们的另一个产品在另外一个省也遇到了类似情况,core的输出与今天处理的情况几乎相同。想必是一个问题。因为出问题的函数是很久以前的代码了,而且是复用库中的一处代码。估计所有复用了该库的产品都要做一次升级了。

解决完问题已是日落时分,虽然身体感觉一丝疲乏,但是心情还是不错的,一天的努力终于有了成果,程序员的成就感就是由此而来的。




这里是Tony Bai的个人Blog,欢迎访问、订阅和留言!订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您喜欢通过微信App浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:



本站Powered by Digital Ocean VPS。

选择Digital Ocean VPS主机,即可获得10美元现金充值,可免费使用两个月哟!

著名主机提供商Linode 10$优惠码:linode10,在这里注册即可免费获得。

阿里云推荐码:1WFZ0V立享9折!

View Tony Bai's profile on LinkedIn


文章

评论

  • 正在加载...

分类

标签

归档











更多