最近在做线上oracle11g thin链接升级的时候，搞出一个线上故障，原因是增加的oracle.jdbc.ReadTimeout参数设置有问题。
系统中一个以前配置了以下几个参数：
1.blocking-timeout-millis 500ms
2.query-timeout180s
3.idle-timeout-minutes 30m
升级后增加了2个参数：
1.oracle.jdbc.ReadTimeout 60000ms
.CONNECT_TIMEOUT 10000ms
先来解释下这几个参数的作用：
blocking-timeout-millis ：是应用获取数据库链接的等待时间。一般数据库链接都是一个池子，当链接数已经达到了最大链接数的时候，应用如果还要获取链接就会出现等待的现象，等待链接释放并回到链接池，如果等待的时间过长就应该踢掉这个等待，不然应用很可能出现雪崩现象。而这个blocking-timeout-millis就是控制这个等待时间的。
query-timeout：是一个sql执行的时间，如果该sql执行的时间超过它配置的时间就会出现ora01013,用户取消请求操作的异常。
idle-timeout-minutes：是一个数据库链接在多久没有被使用彻底销毁的时间。如果对于资源的要求不是那么高的话，一般配置30m就行了。配置久一点无非是没有使用的链接占用一点内存而已。
oracle.jdbc.ReadTimeout 这个参数实际上是从socket读取数据的时间，总体上说这个时间应该包含了query-timeout的时间。如果这个时间配置得比query-timeout短的话就会出现query-timeout的设置值无效，变为更短的oracle.jdbc.ReadTimeout的值。我搞出的故障也是这个值设得太短导致。
.CONNECT_TIMEOUT 是应用去获取数据库链接的时候，发现还没有达到最大链接数，还需要重新创建链接的创建时间。这个时间一般10s也足够了，如果10s还没有创建好链接，该请求尽早的滚蛋也好，免得应用僵死。
如果觉得《oracle 11G 链接超时 oracle 11g thin链接的超时参数设置》对你有帮助，请点赞、收藏，并留下你的观点哦！
