成为VIP
了解内部基本原理，是我们分析问题和解决问题的根本。通过原理分析可以帮助我们快速定位问题解决问题，才能使我们在解决问题时少走弯路，透过现象发现问题的本质，从而在根本上解决问题。
问题
某省移动现场曾出由于数据库有一个实例出问题时，引起系统权限等服务报大量的“otlexception:ORA-03113:end-of-fileoncommunicationchannel”错误并core 导致很多业务无法办理，在解决这一问题时发现即使数据在正常情况下数据库连接，很多服务如SysMgnt_svr、AccPayFee_svr等服务的日志中在整点的时候都会产生10多条““otlexception:ORA-03113:end-of-fileoncommunicationchannel”的错误。为了消除隐患，需要将产生ORA-03113的错误原因找到并解决。
1问题分析
1、为了分析“ORA-03113”出现的原因，我们只启了一个productintf_svr，并且MIN=MAX=1,发现压力测试并不会报错；
2、将MAX改为2，恢复CLOPT选项，发现错误又重现了，去除”-p 2,12
0:5,6″，错误没有重现；
3、怀疑ubb配置或自动启服务有问题，检查ubb并没有发现有什么问题，将MAX改为2，仍保留CLOPT=”-A -p 2,120:5,6 — -i../config/productintf.cfg -mproductintf”参数，发现当server数增加到2时，开始报ORA-03113的错误，通过现场ULOG和服务日志分析进一步验证每当出现“ORA-03113: end-of-fileon communication channel”时数据库连接，都会在对应的时间点上出现服务启动的相关日志。这也可以解释，在日志中有时可以看到服务进程在成功执行完一次调用后，隔一断时间后才报错。
4、进一步查看UBB配置和服务日志发现只有配置了-p选项的服务才会报ORA-03113的错误，这就更进一步验证了，ORA-03113错误和自动spawn server之间的相关性。
5、去除”-p2,120:5,6″，在压力测试时用tmboot方法手工启server，也不会报错，说明有可能和tuxedo的自动增加server的功能相关；
6、由于DBPOOL是全局变量，且在没有启动自动回收功能情况下，只有当进程退出析构时才会主动断开连接。为了进一步确认问题，采用gdb跟踪调试服务,在DBPOOL析构函数里设置断点。发现服务里竟然有产生新进程的信息，采用gdb调试。
7、采用gdb并catch fork系统调用，看看gdb具体信息。由于gdb当时的进程信息没有copy下来，故用ps查看重新测试生成的数据，发现新产生的server的父进程就是原server，而且是fork了3次。没过一会再次用ps查看，发现只有2个进程存在，而且父进程都变成了系统进程。分析原因，这可能是TUXEDO采用了脱离终端的实现方法。
至此进一步确认了tuxedo在自动产生新server时是采用server自身fork一个进程的方法实现的。
8、为了验证fork进程是否能造成数据库连接中断，写了一个测试程序来验证，发现一但调用了fork后，当子进程退出后，父进程执行SQL操作时程序就会报ORA-03113: end-of-file on communication channel。由于子进程会复制父进程的全局变量和文件句柄，当子进程退出时会将复制的全局变量析构。为了提高性能、降低数据库连接消耗，openboss采用DBPool来管理数据库连接且DBPool为全局变量，所以当子进程退出时会调用DBPool的析构函数，DBPool的析构函数会执行断开数据库连接的操作。
2结论
造成“ORA-03113: end-of-file on communicationchannel”错误的原因是由于TUXEDO负载均衡自动增加server造成的。TUXEDO自动增加server是采用让server自身fork子进程的方法来实现，这样做对全局的变量和句柄的使用带来了一定的影响和限制。
想要更完整的程序和测试数据，请直接主页留言技术君哦，留下你的公司邮箱，技术君速速送达 @all
点击文章底部“评论”，交流才能碰撞出更多火花！
如果您喜欢本篇分享，请记得点“赞”
限时特惠：本站每日持续更新海量设计资源，一年会员只需29.9元，全站资源免费下载
站长微信：ziyuanshu688
htebazile
