Phone:18180207355 提供专业Oracle&MySQL数据恢复、性能优化、迁移升级、紧急救援等服务

某个朋友公司的客户,友情帮忙分析的。客户使用的是oracle 12c(12.1.0.1),应用通过jdbc访问发现时快时慢。但是通过sqlplus访问发现一切正常。
开始以为是防火墙问题,检查发现防火墙什么的都是禁用掉了,甚至我还修改了selinux=disable,发现问题依旧。

由于之前处理过几个类似的case,都是jdbc版本的问题,因此开始我让他们换几个jdbc版本测试下,发现问题依旧。类似如下结果:

后面我通过strace 跟踪发现了一些蛛丝马迹,如下的跟踪的结果:

到futex 这里一直timeout,大概10多秒。其中的open(“/dev/random”, O_RDONLY) 引起了我的注意,google搜了一下,还真有不少人遇到过。

Oracle 从11g开始,对于jdbc这块儿安全上进行了加强,大概是这样的一个解释:
The JDBC 11g needs about 40 bytes of secure random numbers, gathered from /dev/random, to encrypt its connect string.

那么解决方法就是将java_home下面的 Java.security文件中的如下内容进行修改:
securerandom.source=file:/dev/random 修改为:securerandom.source=file:/dev/urandom

当我客户检查时,发现这个配置文件已经是securerandom.source=file:/dev/urandom 了。到这里我似乎感觉是jdbc版本的问题了或者是12c本身的问题。

将客户的jar把传到自己的12.1.0.1和12.1.0.2环境中进行测试,发现现象一样,时快时慢。

通过strace跟踪了一下,发现信息跟之前在客户环境中的strace结果类似,这是很怪异的。

后面我怀疑可能是这个配置文件并没有起作用,最后搜了下mos发现有一篇文档:

How To Configure Database JVM (JavaVM) To Use /dev/urandom (In Order To Avoid JDBC Connection Delays Due To Lack Of Random Number Entropy) (ID 1594701.1)

里面的建议是直接修改配置文件,如下:

根据这个docs进行修改之后,再次测试,我发现一切正常了。。。。 如下是测试过程:

这个case本身是并不复杂,比较简单,跟大家分享一下,欢迎交流!

注意:这里最好是使用oracle自己的java,保持版本一致,我这里测试发现如果使用os自己的java,版本较低,连接仍然会比较慢。

这个版本很明显是低于Oracle 12.1.0.1 官方文档中的要求的,必须是1.6.0_37以上版本。

    分享到:
18180207355
加Q咨询